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

[Christoph Paasch <[e-mail]>]

Hello Lucas,

On 10/03/20 - 00:56, Lucas Pardue wrote:
> 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.

"could hurt end users", you mean consume significant cellular data? Or do
you mean hurt performance?

If it is the former, I agree. And that's why the client should not establish
a uniflow unless it actually is willing to receive data on that uniflow.
Sure, any scheduling-signaling we could add to QUIC could help alleviate
those problems, but one cannot "trust" the server to ever do the right
thing.

If it is the latter, I think that stream prioritization suffers from the
same potential to do severe damage in terms of performance.

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

I doubt there is a specific reason on why the MP-QUIC draft does not have
such an "MP_PRIO"-concept. In any case, that would be a minor point that can
easily be added.


Christoph