Lucas,
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.
So maybe I'm still missing it, but the MP-QUIC proposal seems to omit
such a MP_PRIO signal. So the gap I had was wondering if the client
needed to actively bring up or tear down uniflows in order to control
the server sending on a higher-cost cellular network (for however one
measures cost).
The description in the mpquic draft focuses on the basic principles.
Once we agree on them, we can add different extensions such as the
support for backup uniflows...
Although I have drawn parallels with stream prioritization, there is a
difference. The server behaviour of stream prioritization cannot really
do much damage. The server behaviour for the multipath use case seems to
be higher stakes - getting it wrong could hurt end users.
I'm not saying that we have to state a scheduler now, or research one.
But I do wonder why the uniflows proposal does not simply start with
adopting the same/similar signal that MPTCP already has.
Olivier
