Re: Preparing for discussion on what to do about the multipath extension milestone

[Olivier Bonaventure <[e-mail]>]

Hello,
> 
> On 10/02/20 - 18:51, Lucas Pardue wrote:
>> +1 to the suggestion to discuss use cases, it is helpful for clarity. And
>> thanks Christoph for sharing some specific ones.
>>
>> For the use cases "Siri" and "Apple Music", since I'm not experienced with
>> multipath there's a gap in my understanding of how the proposal in
>> draft-deconinck-quic-multipath would be used to satisfy these use cases.
>> For instance, is the behaviour client-driven, server-driven or does it
>> require coordination?
> 
> MPTCP has some limited coordination capabilities. Namely, it allows to
> signal to the peer if a "subflow" (in QUIC-language "uniflow") is using a
> backup-interface (through the backup-bit in the MP_JOIN establishment or the
> MP_PRIO-option - in case you want to look it up in the RFC).
> 
> That signaling is very limited in MPTCP though. And this is exactly the
> place where MPQUIC can have a significant benefit over MPTCP as it can be more
> descriptive on the scheduling because it does not have limitations that the
> TCP-option space has.
> 
>> Would anyone be so kind as to share _an example_ of
>> how uniflows would be used within a QUIC connection that uses a
>> request/response paradigm for data exchange.
> 
> I'm not entirely sure which parts of the MPQUIC-exchange are unclear, but
> I believe the best description can be found at: https://multipath-quic.org/conext17-deconinck.pdf

The design changed to reflect the changes in QUIC since the publication 
of this paper. Quentin De Coninck describes the evolution of his design 
in his PhD thesis (chapters 5 and 6) :

https://inl.info.ucl.ac.be/publications/flexible-multipath-transport-protocols.html


Olivier