Re: Next steps for Multipath QUIC

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

Hi, Lucas,

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

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

I agree - sorry if I was unclear. My suspicion, to be confirmed or
overturned, is that "several multipath use cases" may not mean "all of the
proposed multipath use cases".

Using my two categories above, I'll be looking especially closely to see if
a single multipath QUIC design can address use cases in both categories.

We'll see, of course.

Best,

Spencer