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

[Olivier Bonaventure <[e-mail]>]

Hello Martin,

> On 2 Apr 2020, at 05:44, Martin Thomson <[e-mail]> wrote:
> 
> 
> On Thu, Apr 2, 2020, at 13:05, Spencer Dawkins at IETF wrote:
>> Multipath has been in the QUIC charter since the first proposed version 
>> (see https://datatracker.ietf.org/doc/charter-ietf-quic/00-00/), at my 
>> urging, because I couldn't imagine chartering a new transport protocol 
>> in 2016 without multipath, given that we'd had to retrofit that into 
>> both TCP and SCTP. So this might have been a mistake, but it's not a 
>> recent one, and I made it (and achieved IETF consensus, of course :-)
> 
> 
> I don't think that this is about blame.  It's about learning that sometimes you aspire to achieve things that are out of your reach.
> 
> Like you, I thought that at least someone understood this problem well enough for us to do the work.  I didn't have that expertise myself, but I could see SCTP and MP-TCP.  I've used SCTP multipath myself, many years ago.  What I didn't know then was how narrow that usage was and how difficult the problem is in the general case.  I suspect that many people reached a similar conclusion.
> 
> We could absolutely set out to do multipath for failover, and we basically have already.  

We should not stop at connection migration. Multipath allows to use two paths during the connection migration, which brings benefits on smartphones based on the lessons learned from using MPTCP on Apple phones.

> Similarly, multipath for maximizing throughput (what most people seem to want to measure in a lot of testing), seems like it might be achievable.  

We can leverage all the work done with MPTCP. QUIC simplifies the problem because we do not need to take care of any kind of middlebox interference. Many research papers have tried to maximise throughput because this fits well in lab environments, but deployments have different objectives :
- on smartphones, deployments try to minimise the utilisation of the cellular network when the Wi-Fi is good enough (with different definitions of good enough depending on the application)
- in hybrid access networks that combine xDSL and 4G, deployments try to only use the 4G network when the DSL is full  

These objectives are reached by using packet schedulers and path managers that are specific to each use case but have not been standardised within the IETF. Concerning the packet schedulers, we started to document them in a generic manner in 
https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-00 <https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-00>
and planned to present the draft in Vancouver

> This sort of general purpose usage is the most difficult without having a good set assumptions backing the work.
> If this is truly desirable, I would suggest that some of those companies listed as supporting the liaison statement could send some people to feed in requirements, refine the scope, make proposals, and work on solutions.  The IETF is unlikely to magically create something that will meet 3GPP needs and the speed of interaction via liaison statement isn't conducive to working through this.

I’m ready to work on such a document. Feel free to contact me if you’d like to participate.

> We do have other history here: the failed BANANA BoF at IETF 97 covered this exact topic: https://datatracker.ietf.org/doc/minutes-97-banana/  That's at a different layer, but the same challenges exist.


Two different approaches have been discussed around IETF97. A network layer based solution in BANANAS and an MPTCP solution. The network layer solution did not gain enough interest. 

The MPTCP solution has been included in the first version of ATSSS and is used in Hybrid Access Networks. It has been initially developed in the mptcp working group and then moved to the tcpw working group. See https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ <https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/>


Olivier


-- 


Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>