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

[Olivier Bonaventure <[e-mail]>]

Lucas,

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


Let me try with a simple example on a moving smartphone. The application 
will send small amounts of data and receive variable amounts of data 
(depending on the type of requests).

We create a sending and a receiving uniflow on both the Wi-Fi and the 
cellular interface. The smartphone has two sending uniflows and the 
server as well.

To send a short request, the client duplicates it over its two sending 
uniflows since it does not know which of the two uniflows will be the best.

To return the response, the server could use the same scheduler if the 
response is short. However, if the response is long, this is not very 
efficient since data is sent over two paths. It could then use both 
paths to send the data and get the lowest delay to deliver the response.
This could be modulated by policies if the user pays on a per volume 
basis over one path and not over the other.

Another example is the hybrid access network scenario with a DSL and an 
LTE path. There, the objective is to send data over the LTE path only 
when the DSL is full.

In this case, the solution would differ. The client would first create 
sending and receiving uniflows over the DSL path. It then monitors the 
usage of this path. As long as the DSL is not fully used for some period 
of time (e.g. one or a few seconds), all data flows over the DSL path. 
Once the DSL path is saturated, the client creates a receiving uniflow 
(and possibly a sending one if the DSL upstream is saturated) over the 
LTE path. The second path can be used to offload traffic. In practice, 
the client and the server use a priority scheduler to always prefer the 
DSL over the LTE path, see

https://inl.info.ucl.ac.be/publications/increasing-broadband-reach-hybrid-access-networks.html

Another usecase is a device that has a high-speed satellite downlink 
(but very slow upling) and a low-speed cellular connection. In this 
case, it can use two receiving uniflows (one cellular and one satellite) 
and one sending one (over the cellular). Requests are sent over the 
cellular path and responses are received over the satellite uniflow and 
acks are sent over the cellular uniflow.


There is a generic discussion on schedulers in

https://datatracker.ietf.org/doc/html/draft-bonaventure-iccrg-schedulers-01



Olivier

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