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

[Gorry Fairhurst <[e-mail]>]

A couple of words on SCTP and DCCP... as a TSVWG Chair...


First, I'm also really grateful for sharing this vision with the IETF. 
It will help to know, and discuss, what other SDOs would like to do.

The IETF has indeed worked on transport support for failover between 
different paths. SCTP has specified path failover, and as recently as 
2016, published RFC7829.   I agree that failover seems close to 
something that QUIC mechanisms can offer, and I wonder if there is value 
in explicitly writing something short that calls out path failover as 
one service offered by QUIC?

Over the years, SCTP has also considered concurrent multipath sharing. 
There are interesting and many useful papers on this, with data and 
considerations of interactions with congestion control, but no IETF work 
was adopted. That isn't to say that couldn't happen, far from it. I'm 
just noting that so-far the concurrent use of multiple paths remains 
something where TSVWG is looking to understand the general requirements 
for the service and protocol mechanisms.

There were recent requests to work on DCCP with multipath, these 
continue to be discussed in TSVWG as individual contributions. (MP-TCP 
work moved to the TCPM WG).

Finally, I'll observe (with no "hat") that the forwarding of latency 
sensitive and real time traffic along a different path to other traffic 
(or to a different endpoint) is work where the IETF could likely help, 
although that may not necessarilly imply a need for work on concurrent 
multipath sharing of capacity.

Gorry Fairhurst

(One of several TSVWG Co-Chairs)


On 02/04/2020 04:44, Martin Thomson 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 :-)
> Hi Spencer,
>
> 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.  Similarly, multipath for maximizing throughput (what most people seem to want to measure in a lot of testing), seems like it might be achievable.  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.
>
> 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.