Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]

[Gorry Fairhurst <[e-mail]>]

On 03/04/2020 08:55, Olivier Bonaventure wrote:
> Lars,
>>
>> what we have done with MPTCP is build a system that is reasonably 
>> good at pooling the capacity of multiple paths for one connection, 
>> *if* these paths have reasonably similar characteristics, esp. RTT.
> >
>> With paths with dissimilar RTTs, we can still pool the capacity, but 
>> only make it available for use to the application at pretty much the 
>> maximum of the individual RTTs. That’s still somewhat useful if you 
>> care about bulk throughput. It’s basically useless if you care about 
>> small-transfer latencies, which the web has been gravitating to for 
>> years. (Remember that the MPTCP design is ten years old - from a 
>> different world. Bandwidths have gone up a lot, making capacity 
>> pooling less urgent, but late cues have not decreased much.)
>
> This corresponds to the hybrid access network case that pools bandwidth.
>
>> To make multi path useful to today’s mostly latency-sensitive 
>> applications, we need a path scheduler that can pool (some of) the 
>> capacity of multiple dissimilar paths at some effective RTT that is 
>> much lower than the maximum of the individual ones. I am not aware of 
>> any proposed scheduler - for MPTCP or otherwise - that achieves that.
>
> AFAIK, this is exactly what Apple is doing with MPTCP. They call this 
> the "interactive mode" and the stack dynamically selects the path 
> (wifi or cellular) having the best performance (rtt, losses) for 
> interactive applications. See 
> https://developer.apple.com/videos/play/wwdc2017/707/
>
>> Even if we change the argument from pooling latency to increasing 
>> resilience, I still doubt that increased resilience at the cost of 
>> much-increased late zu is a worthwhile trade off for many apps.
>
> AFAIK, Apple calls that the "handover mode", it is probably less 
> useful that the interactive one. Maybe Apple engineers who are on this 
> list can comment and provide more details.
>
> I don't think that Apple uses MPTCP to pool bandwidth. They use MPTCP 
> to improve user experience and mainly latency.
>
>
> Olivier

When you says "select" do you mean "change to send data using the new 
path"?

I f so, I think this is close in operation to a "path failover", even if 
it uses a trigger metric that isn't just a loss of connectivity, but the 
result of some other path metric - e.g. significantly lower RTT, 
availanility of PvD information, ... . In my mind, this is quite 
different to a proposal for somehow "sharing" traffic/capacity between 
several paths, which means understanding capacity and the impacts of 
variability in path characteristics, the impact of traffic on pooled 
bandwidth, etc.

It still does pose some issues in estimating the capacity on the "new" 
path, but ... The mechanisms to do this seem to exist within the design 
expected of QUIC.

Gorry