Re: What to do about multipath in QUIC

[Behcet Sarikaya <[e-mail]>]

Hi Lucas, Olivier,


On Mon, Nov 9, 2020 at 10:51 AM Lucas Pardue <[e-mail]>
wrote:

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

I don't think Olivier would wish to undermine the most important feature of
multipath: multiple paths going over concurrently possible over different
networks.
Then he can not justify many features in draft-deconinck-quic-multipath.

Behcet

> Cheers
> Lucas
>
>