Re: Multipath (was: Re: Re-chartering for extension work)

[Mirja Kuehlewind <[e-mail]>]

Hi all,

see below.

From: QUIC <[e-mail]> on behalf of Jana Iyengar <[e-mail]>
Date: Saturday, 21. December 2019 at 02:49
To: Tommy Pauly <[e-mail]>
Cc: Olivier Bonaventure <[e-mail]>, Quentin De Coninck <[e-mail]>, Ryan Hamilton <[e-mail]>, Mark Nottingham <[e-mail]>, Christian Huitema <[e-mail]>, Lars Eggert <[e-mail]>, Mikkel Fahnøe Jørgensen <[e-mail]>, IETF QUIC WG <[e-mail]>
Subject: Re: Multipath (was: Re: Re-chartering for extension work)


Fundamentally, the capabilities that “full” multipath enable on top of migration are:
- Bandwidth aggregation
- Separated congestion control
- The ability to split traffic (such as on a stream basis) across paths to take advantage of different link characteristics

These are all good to enable, but these are not the core benefits that devices right now are gaining from multipath, as much as the ability to migrate with agility. We should absolutely work on multipath, but it may be good to see how shipping migration (the first half of multipath) goes first.

Yep. This has been my experience as well.

I appreciate that there are some cases where simple bandwidth aggregation is useful, but there is a real question about the amount of effort required to not just standardize but also build a multipath extension for those specific use cases.

The relevant question I would be looking for answers to is how many implementers will commit to implementing a multipath extension if one were to be standardized.

FWIW: I also don't believe MPTCP has solved all multipath problems, not in the general case anyways. There are real ones that make actual deployment super difficult. Specifically, scheduling is a real issue. Deciding when to use multiple paths and how to use them remains an open question. The answer in my experience ends up being very application-dependent, which means that you need an application to buy in before you develop a scheduler. And without this buy-in, I couldn't justify spending the time and energy to spend time on building multipath into our implementation at least.

As Tommy said, migration is already the first half of multipath support for QUIC. So I expect it will be easier to add it to QUIC than it was for TCP. I would at least be curious to spend some time on figuring out how much (or how less) effort it would be. Maybe there is also another step before going to full multipath support that could support the handover use case better, e.g. sending redundant data on multi paths or something. I think it worth think about it. However, while I would like to see this discussion starting now, I think it’s fine to wait for adoption of any draft until v1 is done.

Mirja