> Dino, > > In addition to the previous arguments there are particular use-cases where > the use of reliable transport simplified the deployment of LISP.
I understand its advantages. I am examining its costs. > As an example, the moment we started scaling datacenters to support 10s of > thousands of hosts, the use of a reliable transport helped a lot the > management of scale: > On one side it reduces the amount of signaling when nothing changes, since we > use TCP state as an indication that xTRs and the MS are in sync and there is > no need to deal with the optimization of the refresh logic (periodic or > paced). LISP (the application), does not know that itself, the xTR, is in sync with the map-server. The packets can be in flight or being retransmitted due to loss. But if a Map-Register is sent with a nonce and no Map-Notify is returned the xTR knows for sure the two are in sync. I’d argue you may it worse. TCP does provide reliability but so does LISP itself. And the only reason the messages are periodic is because the spec said to send every 1 minute and timeout every 3 minutes. You can make it 1000 minutes and timeout every 3000 minutes. So let’s keep periiodic overhead, reliability, and staying in sync as separate issues. > On the other side, with reliable transport we offload the reliable delivery > of information (and congestion control) I understand that. But you can’t say TCP is keeping you in sync, because you have removed detail from the applicationis. > from LISP to another process (TCP) that is entirely devoted and designed for > this. For example, supporting events like mass VM moves relying purely on > LISP based ACks became very challenging, as we ended up having to deal with > congestion events related to the signaling load generated. The use of the > reliable transport largely simplified the problem. LISP can pack all those EID-records in a Map-Register just like TCP does. And if you want per nonce acks, you pack them in IP packets <= 65535 bytes. TCP will have to do that as well. And guess what. What if there is an RLOC-change and you already gave the last one to TCP and can’t pull it back. If you were waiting for an ack and a new RLOC-change came in (during a lossy case), you wouldn’t have to retransmit the old information wastily. So keep the “retransmission queue” in LISP has its advantages. Dino > > Marc > > On 12/5/17, 12:06 PM, "lisp on behalf of Johnson Leong (joleong)" > <[email protected] on behalf of [email protected]> wrote: > > Hi Dino, > > A large portion of this draft discusses the state machine required for TCP > and how to ensure the MS and xTR are in sync. We literally reuse the entire > UDP map-register code, we just wrap that message around the LISP TCP header > so there's a lot of code reuse. Finally, this draft is not meant to replace > UDP register but in some of our use cases TCP would scale better to avoid the > periodic registration. > > -Johnson > >> On Dec 5, 2017, at 10:52 AM, Dino Farinacci <[email protected]> wrote: >> >>> registration protocol, that might be orthogonal to other transport-related >>> mechanisms. In my experience this has proved to be very effective in >>> scalability of large LISP deployments, especially with the increased volume >>> of registration data. >> >> I agree it’s a point solution for registration. Then why did you need to >> have a general format. >> >> I could support this draft if it was simplified to spec how to use >> Map-Registers in TCP and nothing more. >> >> The only thing I would add is how to use TLS so encryption is supported. >> More and more requirements are coming up for protecting the privacy of >> location information. And since Map-Registers carry RLOCs (and potential >> Geo-Coordnates) that information needs to be protected. >> >> Dino >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
