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/
