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
