> Dino, > > What we're trying to convey is that by using TCP it allows us to achieve > reliability which significantly simplifies the code and error handling. One > can achieve the same with UDP with ack and retry but it would be > reimplementing what TCP already offers and this added complexity typically > makes the code error prone.
I know what you are trying to do and your assertion is simply not true. > Another benefit with TCP is congestion control, with UDP if we send a > map-register and we don't get an ack then we retry. What if the MS is fully > subscribed then this can lead to constant retry. You can impose backoff > mechanism but ultimately this would affect convergence. And you think in this condition that TCP won’t be retrying. THe arguments are weak. In fact, if TCP is retrying there is a greater window of time where old RLOC-set data is in the pipeline. Dino > > -Johnson > >> On Dec 6, 2017, at 11:17 AM, Dino Farinacci <[email protected]> wrote: >> >>> Dino, >>> >>>> 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. >>> >>> An application (and LISP in this case) should always be able to know the >>> state of a (TCP) socket that it has opened with a server. I’m not entirely >>> sure why we would not want to use this information. >> >> All an app knows is the socket it has opened and any port it has bind()’ed >> to. It doesn’t know the connection state in terms of what packets have been >> sent and what has been ack’ed. There IS NOT enough information to do >> anything useful. >> >>> Besides, the reliable transport session does not invalidate the use of >>> nonces and Map-Notifies as an indication that the MS has completely >>> received the information, the just rely on the TCP state to know that >>> nothing has changed. >> >> Right, so you have duplicate functionality. That isn’t efficient. >> >>>> 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. >>> >>> And this sounds as we would make the protocol very complicated to use (or >>> code), as this would lead us to have to code/configure a specific >>> registration pattern/logic for every use case that we want to support. Not >>> saying we cannot, but it sounds like re-implementing TCP ;) >> >> You already have that code or you aren’t implementing Map-Register acks >> corrrectly. And changing a timer is really a constant change in the code. >> And what is spec’ed today in LISP proper is much simpler than TCP, it is not >> reimplementing it. >> >> But let's not drift from the point. The spec is written in a general way to >> solve only sending Map-Registers reliably. I suggest the text not mislead >> the reader to think this is a general new packet format for anything. >> >> When people judge which protocols they want to deploy, the people that do >> the due diligence will look at the protocol specs and see how much mechanism >> is designed in. And they make judgement decisions about using the protocol. >> >> I know of at least 2 vendors that said “I implemented pages 47-50 of the >> EVPN spec”. ;-) >> >> In LISP. we want to make sure what we spec is what is used and not ignored >> or considered optional. So please document the specific use-case you want to >> implement. And I’d suggest making the draft name >> draft-*-lisp-reliable-registers. >> >>>> 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 o that as well. >>> >>> This is exactly the point, while LISP signaling allows it we don’t need to >>> re-implement every TCP feature in LISP, as TCP can already provide it. >> >> You don’t need to. >> >>>> 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. >>> >>> I’m not sure this is so easy. UDP, just like TCP uses the RLOC (IP) as part >>> of the “session identifier” and the nonce is per-packet, not per-session. >>> The moment the RLOC changes on the xTR, the MS does not know that the xTR >>> is the same so we’d need a retransmission process. >> >> I’m not talking about when the xTR changes, I’m talking about an address on >> an interface on the same xTR changes since it was DHCP’ed to the xTR or >> behind a NAT. But for the LISP-MN case, the xTR is moving and its RLOCs are >> changing. You couple this with pubsub and the extra Map-Registers with old >> RLOCs has a ripple effect where then the Map-Server sends Map-Notify >> messages to all the subscribers, then followed by another set of >> Map-Notifies with the new RLOC-set. That is a lot of (unnecessary) messaging >> and processing. >> >> We have to think about the implications of any one draft on the ENTIRE LISP >> architecture. It must work efficiently as one holistic distributed system. >> >> Dino >> >>> >>> Marc >>> >>> On 12/5/17, 5:57 PM, "Dino Farinacci" <[email protected]> wrote: >>> >>>> 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. >>> >>> 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
