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

[Jana Iyengar <[e-mail]>]

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