Re: [lisp] Draft-kouvelas-lisp-map-server-reliable-transport WG Adoption

[Robert Raszuk <[e-mail]>]

Hi Dino,

Actually when I said 3 RTTs I meant to say 3 TTs so 1.5 RTT. In any case
the below depends on the end point and recurrence of sessions vs pre copied
keys:

Connection setup… the QUIC way:
○ 0 round-trips to a known server (common)
○ 1 round-trip if crypto keys are not new
○ 2 round-trips if QUIC version negotiation needed

In your case 0.5 RTT seems to be in the case where there is no crypto
security. The draft talks about UDP authentication, but is pretty dry on
the details of it :(

In any case during mobility there is always radio overlap where the new
registration can take place while old is still working fine. This is the
same with mobile networks or wifi etc ... So I am not sure where the
requirement comes from to compromise security with need for speed ?

Best,
Robert


On Fri, Apr 22, 2022 at 10:41 PM Dino Farinacci <[e-mail]> wrote:

> Actually there is, predictive-rlocs. No messaging is better than .5 RTT in
> control-plane. But might not be fair to compare since you have to send data
> to more places that may get dropped.
>
> Dino
>
> > On Apr 22, 2022, at 1:39 PM, Dino Farinacci <[e-mail]> wrote:
> >
> > Nothing is better than .5 RTT.  ;-)
> >
> > Dino
> >
> >> On Apr 22, 2022, at 1:18 PM, Robert Raszuk <[e-mail]> wrote:
> >>
> >> Hi Dino,
> >>
> >>> If you use a transport layer that requires connection setup, it will
> slow down handoff time when EIDs are moving.
> >>
> >> But quic connection setup is just 3 RTTs. Is that an issue ?
> >>
> >> Thx,
> >> R.
> >>
> >> On Fri, Apr 22, 2022 at 8:40 PM Dino Farinacci <[e-mail]>
> wrote:
> >> The others know to add quic, it was part of a discussion on how to open
> sockets using QUIC and which port numbers to use. That text is coming. The
> drfat does intend to support multiple transports. Here is one excerpt that
> proves that:
> >>
> >> <Screen Shot 2022-04-22 at 11.37.47 AM.png>
> >>
> >> QUIC will be added to the list above.
> >>
> >> To answer your second question. If you use a transport layer that
> requires connection setup, it will slow down handoff time when EIDs are
> moving. So in that case, a Map-Reqister should just be sent over UDP. And
> on the Map-Request side you will require an RTT before getting the
> map-cache populated.
> >>
> >> Dino
> >>
> >>
> >>> On Apr 22, 2022, at 11:11 AM, Robert Raszuk <[e-mail]> wrote:
> >>>
> >>> Hi Dino,
> >>>
> >>> Before I hit sent I did search the draft and did not find any match on
> QUIC :(
> >>>
> >>> But to your question - yes. I see no reason why LISP control plane
> could not be running over QUIC.
> >>>
> >>> Best,
> >>> R.
> >>>
> >>> On Fri, Apr 22, 2022 at 7:59 PM Dino Farinacci <[e-mail]>
> wrote:
> >>> The draft indicates QUIC can be used as a reliable transport. But are
> you saying QUIC should be used for all LISP messages?
> >>>
> >>> Dino
> >>>
> >>>> On Apr 22, 2022, at 6:35 AM, Robert Raszuk <[e-mail]> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> May I ask for reasons not to use QUIC instead of home made UDP based
> transport followed by TCP ?
> >>>>
> >>>> Many thx,
> >>>> Robert
> >>>>
> >>>> On Wed, Apr 20, 2022 at 9:42 AM Luigi Iannone <[e-mail]> wrote:
> >>>> All,
> >>>>
> >>>> During the last LISP WG meeting in Vienna/Meetecho the authors of the
> draft:
> >>>>
> >>>> LISP Map Server Reliable Transport
> >>>>
> https://datatracker.ietf.org/doc/draft-kouvelas-lisp-map-server-reliable-transport/
> >>>>
> >>>> Asked for adoption as WG document.
> >>>> Call for adoption during the meeting showed clear consensus.
> >>>> This email is the usual procedure to confirm the consensus on the
> mailing list.
> >>>>
> >>>> If anybody has concerns about adopting this document please state so
> on the mailing list before May 5th 2022.
> >>>> Please also argument the technical reason why you have concerns.
> >>>>
> >>>> Ciao
> >>>>
> >>>> Luigi & Joel
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> lisp mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>> _______________________________________________
> >>>> lisp mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>
> >>
> >
>
>