Re: What to do about multipath in QUIC

[Behcet Sarikaya <[e-mail]>]

On Mon, Nov 9, 2020 at 10:31 AM 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.
>
>

Lucas admitted that connection migration does not support the paths being
used concurrently, possibly going over different networks.

Behcet



> > When I look at RFC 6824 it says:
> >
> >     A Multipath TCP connection provides a bidirectional bytestream
> >     between two hosts communicating like normal TCP and, thus, does not
> >     require any change to the applications.  However, Multipath TCP
> >     enables the hosts to use different paths with different IP addresses
> >     to exchange packets belonging to the MPTCP connection.  A Multipath
> >     TCP connection appears like a normal TCP connection to an
> >     application.
>
>
> 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.
>
> Olivier
>