Ian,
Christoph, thanks for the great information.
Is the lack of MP-QUIC likely to cause QUIC to be disabled for certain
key use cases(ie: Siri and Apple Music), or can existing connection
migration be made to work?
For example, I can imagine working around true multipath by only using
one path at once, but sending PATH_CHALLENGE on the other path to probe
reliability and/or RTT. Or even sending identical packets(ie: a
request) on both paths and the receiver will naturally respond on the
path the packet is received first and drop the other packet as a duplicate.
My key takeaway from the multipath scheduler papers I've read is that
most of the performance gains are obtained by always sending on the
faster of the two available paths, and in a large set of circumstances,
nothing should be sent on the slower path.
This assumes that you have two paths that provide a good and stable
performance. If path performance changes quickly because one of the
hosts moves then it makes sense to use both paths simultaneously. This
is true as well when the bandwidth of a single path is too slow. We've
seen many reports form companies that use MPTCP to aggregate several
low-speed Internet connection, DSL+DSL, DSL+4F, multiple 4G, ...
The most unexpected one was a television broadcaster that placed MPTCP
in the car used by its journalists. With MPTCP, they could aggregate
satellite, WiFi and several 4G interfaces to speed-up the upload of
videos collected by their journalists in the field
https://www.youtube.com/watch?v=JMRWq7aqi9o
There are many situations where a single link is not sufficient to
support the required applications. Multipath allows to address all these
deployments.
Olivier
