Re: What to do about multipath in QUIC

[Lucas Pardue <[e-mail]>]

Hey Olivier,

On Mon, Nov 9, 2020 at 4:31 PM Olivier Bonaventure <
[e-mail]> wrote:

> Lucas,
> >
> > On Mon, Nov 9, 2020 at 3:55 PM Behcet Sarikaya <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi Folks,
> >     I agree with Mikkel's points.
> >     To Lucas: I meant my short mail sometime ago I think it was before
> >     the interim (?) where I explained that connection migration is
> >     mobility support which should (from layering point of view) be in IP
> >     layer. In fact if IP layer has this support then then no need for
> >     connection migration in QUIC, so those procedures in the code do not
> >     get executed.
> >
> >     Multipath is multiple interface support. It seems more and more like
> >     multipath probably better belongs in transport layer. Traffic in
> >     each interface may go over different networks (in my case on over T
> >     Mobile and the other AT&T). I believe a different PN is well
> >     justified in multipath as we have it in the base draft because of
> >     these traffic conditions (no offense to Christian).
> >
> >
> > I still don't see why the current features of connection migration are
> > not in some way a form of multipath.
>
> You are right, connection migration is the weakest form of multipath.
>

Thanks. We heard use cases that would like stronger forms. I think it will
help continue to move the discussion forward if we can establish some
common ground on terms and capabilities.

This paragraph of RFC6824 then continues as follows :
>
>     However, to the network layer, each MPTCP subflow looks
>     like a regular TCP flow whose segments carry a new TCP option type.
>     Multipath TCP manages the creation, removal, and utilization of these
>     subflows to send data.  The number of subflows that are managed
>     within a Multipath TCP connection is not fixed and it can fluctuate
>     during the lifetime of the Multipath TCP connection.
>
> This is not really connection migration and MPTCP provides much more
> multipath capabilities than connection migration.
>

Yeah I follow. As someone coming from QUIC, the first sentence is kind of
easily negated (which is a benefit IIUC). I think the remainder of the
paragraph is partially satisfied by QUIC v1 if we consider
PATH_CHALLENGE/PATH_RESPONSE and NEW_CONNECTION_ID/RETIRE_CONNECTION_ID.
But it starts to fall apart when you want to do more complicated things. I
think understanding the gaps in the transport signalling would be useful to
document in isolation to any specific solution.
draft-deconinck-quic-multipath has done some of that work already but it
gets a little too tied up with the solution IMO.

Cheers
Lucas