Matt,
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).
I want to start by saying this is a real usecase, and a problem we see
very obviously through quality of experience outliers for people using
our products.
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.
This somewhat hand-waves away the scheduling problem. Most Internet
traffic flows in the direction of server -> client, where typical mobile
clients are obviously the ones with potentially multiple interfaces to
the Internet. The client also has the most information about the likely
quality of the first radio hop into the access network (e.g. signal
quality). The client also _may_ know about things like data pricing.
Agreed
However, the server is the one which is responsible for scheduling most
data across these paths. To make good, proactive (rather than reactive)
scheduling decisions the server needs to be fed this information as
input to its scheduler. This seems a difficult thing to achieve in
practice, and without it I wonder whether the complexity of "full"
multipath will be worth it until we solve the signalling problem.
There are several techniques that allow the server to learn about the
different performance of the paths with MPTCP. Those can be applied to
MPQUIC as well.
If the application uses short requests and short responses, then a
simple heuristic for the server is to send the response on the path
where the last packet (data or ack) has been received. The reception of
a packet is a good indication that a link works.
If the application uses longer responses, then the congestion control
used by the server over the two paths will enable it to easily find the
best way to spread the load. If one path has a longer rtt or losses,
then its congestion window will be slower than the other one and packets
will naturally flow on the best path, but not only on this path. This
does not require a specific scheduler and would work better than a
strict weighted-round-robin scheduler where the client would indicate
that it wants to receive 2/5 of the bytes over WiFi and 3/5 over cellular.
What
Ian is suggesting above, I think, is essentially an Active/Passive
extension to the existing connection migration mechanisms we have today.
What are your thoughts on this as an initial direction? It would allow
operators a way to solve this particular problem with only mild
modifications to the core protocol. Said another way, I think in theory
an omniscient packet scheduler can make very intelligent decisions which
would definitely benefit application quality. In practice though I have
concerns about how effective these schedulers will be versus the naive
approach which could be thought of as "Active/Passive" or "Failover",
eschewing bandwidth aggregation entirely. I'd also like to echo what
Kazuho said, which is that "Multipath" can mean many things, and I'd
prefer we narrow down the problem we want to solve in the WG, which will
drive our design direction.
When coupled with congestion control, a simple packet scheduler such as
lowest-rtt first (if paths have the same cost) or priority (for the
lowest cost path) works well with MPTCP. The same would apply for MPQUIC
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
For these usecases, are you imagining that they would largely be used
internally for Internet operators? I always struggle with the hybrid
access examples, as they seem to assume a lot of knowledge about the
underlying networks that typical endpoints can't simply intuit from the
ether. The linked paper seems to suggest MPTCP as a proxy solution,
Yes, that's deployed with MPTCP proxies running on home routers.
which I gather is largely the usecase things like ATSSS have for MPQUIC.
However, as a mobile application how do I know the DSL link is "full"
and thus that I should create a uniflow over the LTE path? The same
question applies to the server. It would be awesome if clients and
servers had more active information about the underlying network's state
rather than being reactive, but beyond things like ECN this seems
difficult to achieve in practice. If the Hybrid Access Network usecase
of multipath presupposes a deployment in an operator's network then I
would argue it is somewhat antithetical to the goals of QUIC, which
deliberately puts more control at the endpoints.
On endpoints, you can get the same result by having a target bandwidth
on the Wi-Fi interface. For example, a smartphone application could
assume that if the current Wi-Fi bandwidth is below x Mbps then it
should enable the LTE interface to boost a long download. Similarly, a
videostreaming application could have a target that corresponds to the
default quality chosen by the user and enable the LTE when it cannot
receive video at the expected quality. The same applies for a radio
streaming application.
Olivier
