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.
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.
> 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 ;)
> 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.
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.
> 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.
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
