Re: What to do about multipath in QUIC

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Lucas,

On Fri, Nov 6, 2020 at 11:17 AM Lucas Pardue <[e-mail]>
wrote:

> Hey Spencer,
>
> What I'm seeing (as an individual) is that the term multipath is too
> nebulous.
>

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


> There's a spectrum of use cases that can benefit from the use of
> independent paths while using the same logical QUIC connection. On one end,
> multiple paths are used during the lifetime of a single QUIC connection. On
> the other end multipaths paths are kept alive (albeit maybe quiescent) for
> redundancy or bandwidth aggregation.
>
> If the connection migration feature can satisfy some part of the use case
> range, then I think it's fair to say that QUIC supports "multipath use
> cases", even if we don't  explicitly say there is a multipath protocol
> feature. Maybe we didn't make this observation earlier but that doesn't
> change the fact that path independence and migration is in the DNA of QUIC.
>
> If folks want stuff on the other end of the spectrum, then it can help to
> map how the additional possible technological solutions satisfy the use
> cases. We should probably define some more precise terminology; getting
> clarity now will help avoid "no true Scotsman" scenarios if people start
> writing I-Ds and experimenting. This is especially important if any
> proposals end up substituting or supplanting the existing connection
> migration feature in the core QUIC.
>
> I think this aligns with some of your thinking Spencer. Others could
> disagree on some of my points. I just think there's a lot of shades of grey
> in this topic.
>

I think that last part is exactly right.

Best,

Spencer


> Cheers
> Lucas
>
>
> On Fri, Nov 6, 2020 at 4:42 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> For what it's worth,
>>
>> On Fri, Nov 6, 2020 at 10:16 AM Lucas Pardue <[e-mail]>
>> wrote:
>>
>>> Hi Behcet,
>>>
>>> There is no existing multipath mechanisms in QUICv1. Period.
>>>> Please refer to my mail.
>>>>
>>>
>>> That's a strong assertion. I'm not sure if members of the QUIC WG would
>>> agree. I don't know what email you are referring to, for the sake of
>>> discussion have you got a link or could you expand on why you think that
>>> QUIC v1 doesn't support multiple paths?
>>>
>>
>> I don't remember anyone characterizing connection migration as "support
>> for multipath", before Jana's post on October 27, at
>> https://mailarchive.ietf.org/arch/msg/quic/AhDWbrNYsdevwq9COGeGc2YK168/,
>> but I could certainly have missed that - extracting from Jana's post:
>>
>> "We have multipath in QUIC. It may not be enough, but we agreed in this wg
>> that this would be a good first cut to have. I believe this satisfies the
>> charter text as we have it right now. We've just finished building the use
>> of multipath in QUIC, and I'd like us to get some experience with it
>> before
>> considering how to expand its scope or how to improve it further."
>>
>> So, at least, I think that's what we're talking about - connection
>> migration from one path to another, as a type of "support for multipath" in
>> QUIC.
>>
>> From my to Jana in this thread:
>>
>> As an aside - I submitted a quick -00 draft from the Github repo at
>> https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath
>> on Monday (I-D cutoff), and posted a pointer on this mailing list, but I've
>> continued typing, and the current version in the repo now says this in
>> Section 2.2.4.
>>
>>    One important output from the QUIC interim meeting was the
>>    recognition that some participants view "Traffic Switching" as
>>    something like "protection switching" from an active path to a
>>    standby path, that doesn't happen often, while other participants
>>    view QUIC connection migration as a way of responding frequently to
>>    changing path conditions.  This will be an important part of the
>>    conversation about multipath QUIC.
>>
>>    If a QUIC endpoint opens and validates two or more connections, no
>>    additional setup or signaling is required for a sender to switch
>>    paths - that can begin with the next packet queued for transmission.
>>    This would allow "Traffic Splitting" for unordered QUIC datagram
>>    packets [I-D.ietf-quic-datagram], with an upper-layer mechanism
>>    providing flow ordering if that is needed.
>>
>> That's an example of the kind of discussion I'm hoping that we continue
>> to have.
>>
>>
>> Best,
>>
>> Spencer
>>
>