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

[Olivier Bonaventure <[e-mail]>]

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