Re: Next steps for Multipath QUIC

[Lucas Pardue <[e-mail]>]

Hey Hannu, Spencer,


On Mon, Nov 23, 2020 at 2:23 PM 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.
>

Speaking as an individual, I think experimental work towards proving or
disproving whether a single multipath QUIC design, within the set
constraints, can solve several multipath use cases is valuable.

Cheers
Lucas