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