Re: Take multipath to a BoF

[Lucas Pardue <[e-mail]>]

Hey Spencer,

On Wed, Oct 7, 2020 at 3:30 PM Spencer Dawkins at IETF <
[e-mail]> wrote:

> The other reason a BOF would make sense, IMO, is to find out whether
> people are willing to work on something that's not already chartered, but
> QUIC is already chartered to work on multipath.
>

To tug on this thread a little and speak as an individual. I find the
charter pretty light on detail wrt multipath. Yes it is mentioned but
AFAICT the capability has complexity of implementation and deployment that
is at least on par with any of the other standalone focus areas. Each of
those has a pararaph with some even leaning on other groups' definitions.
In contrast, multipath has scant information for what is in scope of
discussion or not. How can people say decisively what they signed up for?

It is also unclear to me how multipath relates to our other deliverables of
Applicability and Manageability drafts. Do those get held up, or does
MPQUIC get its own equivalent?

Without the WG agreed on the problem statement and use cases, I can forsee
future challenges if divisive topics come up. We've seen instances through
the course of QUIC interop and design iteration where an issue has come up
and there have been multiple competing options. We've been able to overcome
those, in part, because we can fall back on the charter's key goals of
"minimizing connection establishment and overall transport latency for
applications" and "Providing multiplexing without head-of-line blocking",
and the secondary goals or constraints in each paragraph.

Do those key goals apply equally to MP-QUIC? I've asked this in other
threads and the response has seemed to indicate that uptime and bandwidth
is more important...


>
>