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

[Lucas Pardue <[e-mail]>]

Thanks Christoph, this is very useful!


On Sat, 3 Oct 2020, 00:20 Christoph Paasch, <[e-mail]> wrote:

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


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

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.

Cheers
Lucas


>