Re: Next steps for Multipath QUIC

[Behcet Sarikaya <[e-mail]>]

On Mon, Nov 23, 2020 at 8:23 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

> Hannu,
>
> On Mon, Nov 23, 2020 at 3:02 AM Flinck, Hannu (Nokia - FI/Espoo) <
> [e-mail]> wrote:
>
>> There seems to be three different approaches for multipath support, if I
>> am not missing any:
>>
>>  https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/
>> https://datatracker.ietf.org/doc/draft-an-multipath-quic/
>> https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/
>>
>> Each of them addressing different use cases. It is not obvious to me that
>> the experimentation would lead into single design rather than debate
>> between the approaches.
>> I would expect as the outcome of the experimentations  deeper differences
>> between the multipath mechanisms tailored for respective use cases. How can
>> we draw any generic conclusions from such results? How would you compare
>> the outcomes?
>>
>
> I agree with you on your question.
>
> I'm working to catalog the various strategies we've talked about in QUIC,
> in
> https://tools.ietf.org/html/draft-dawkins-quic-what-to-do-with-multipath-02#section-2.3
> .
>
> Speaking only for myself, I don't anticipate one approach satisfying all
> of the use cases, which I'm thinking of in two categories:
>
>    - The sender needs to control what to send next, and on what path,
>    based on more knowledge of the paths and the application than a
>    general-purpose transport scheduler can know, or
>    - The sender is willing to delegate those decisions to a
>    general-purpose transport scheduler, because that will be "good enough".
>
> Of course, I could be wrong about that.
>
> I look forward to hearing more about the experiments as we proceed.
>
>

My suggestion is (as suggested by someone already, maybe Jana, I think): go
for a BOF.
I think mpquic community is large enough, prepared enough, good enough to
handle a very successful BOF in IETF 110 which is the next one. Can quickly
form a WG and develop a beautiful mpquic or whatever we want to call it.

Behcet

> Best,
>
> Spencer
>
>
>> Best regards
>> Hannu
>>
>>
>> -----Original Message-----
>> From: QUIC <[e-mail]> On Behalf Of Lars Eggert
>> Sent: Friday, November 20, 2020 11:30 AM
>> To: QUIC WG <[e-mail]>
>> Subject: Next steps for Multipath QUIC
>>
>> Hi,
>>
>> Lucas and me got asked what we'd see as the next steps for multipath
>> support for QUIC. Here's our current thinking:
>>
>> The QUIC WG remains the default venue for continued open discussion of
>> multipath experiments and results. The goal for this discussion is to help
>> steer towards identifying whether a multipath design can emerge that
>>
>> (1) addresses a number of the use cases discussed during the interim, or
>> new use cases that are similarly motivated
>>
>> (2) sees implementation and experimentation/deployment interest from a
>> number of production stacks
>>
>> (3) is (as much as possible) a minimally-scoped extension to QUIC v1 that
>> cleanly integrates with its concepts and other adopted extensions
>>
>> Until this has happened, we think it'd be premature to adopt one of the
>> individual multipath designs that have been proposed as a WG work item.
>>
>> We hope this provides some clarification.
>>
>> Thanks,
>> Lars and Lucas
>>
>>