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

[Olivier Bonaventure <[e-mail]>]

Gorry,
>>>
>>> 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"?

This is a packet scheduler decision. When new data needs to be sent and 
there are two subflows, the scheduler selects the most suitable one. I 
think that Apple uses its WiFi assist monitor to inform the packet 
scheduler of the most suitable path on the client. On paper that 
describes a similar approach is

https://inl.info.ucl.ac.be/publications/tuning-multipath-tcp-interactive-applications-smartphones.html

In MPTCP, it is difficult for the client and the server to easily 
exchange information about the quality of the paths due to middlebox 
interference and a set of heuristics are used. For example, the server 
replies on the subflow chosen by the smartphone to send the request.

With MPQUIC, we can use ping frames to measure the quality of paths and 
react accordingly. In MPTCP, this would require a complex machinery.


> 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, ... .

Apple's deployment shows that maintaining the two paths is useful 
because there are situations where latency sensite applications can use 
both paths, e.g. during the handover when the connectivity is weak but 
not yet broken.

> 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.

The same techniques apply in these different cases.
> 
> 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.

QUIC is clearly both cleaner and more powerful than MPTCP for this. You 
can find a detailed discussion on this in Quentin De Coninck's PhD 
thesis which is available from https://www.multipath-quic.org


Olivier