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. > Would anyone be so kind as to share _an example_ of > how uniflows would be used within a QUIC connection that uses a > request/response paradigm for data exchange. I'm not entirely sure which parts of the MPQUIC-exchange are unclear, but I believe the best description can be found at: https://multipath-quic.org/conext17-deconinck.pdf In principle, the flow would be the following: Assuming the client is on WiFi, whenever the client realizes that WiFi is getting weaker (based on RTT-measurement or congestion-indication or system-wide indicators), it establishes a uniflow on the cellular interface. As soon as that uniflow is in ACTIVE state, it can be used for data transmission. The client can send the request (assuming it fits in a single packet) on either WiFi or Cell, based on - for example - the measured RTT of each of the paths. The server (knowing that both uniflows are active) can then send the reply, scheduling each packet on either WiFi or Cell (e.g., following one of the schedulers I mentioned in the previous email). Christoph > > Another question, and perhaps this is getting increasingly off-topic, but > now that we are getting into designing "significant" extensions, I think it > is worth asking whether this should be an extension at all. I.e. should > MPQUIC be a core feature of QUICv2? > > I tried to spin that out into another thread [1]. IIRC someone previously > suggested that MP-QUIC could start as an experimental version of it's own. > I can't find a citation for that though sorry. > > > [1] https://mailarchive.ietf.org/arch/msg/quic/p2II8y3y1FXy4kWMSuf1lgAXaFA/
