Hey Spencer, On Wed, Oct 7, 2020 at 3:30 PM Spencer Dawkins at IETF < [email protected]> 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... > >
