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

[Christoph Paasch <[e-mail]>]

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/