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, <[email protected]> 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
