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

[Olivier Bonaventure <[e-mail]>]

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