On Wed, 30 Sep 2020, 09:07 Olivier Bonaventure, < [email protected]> wrote:
> Matt, > > > > > > On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > In parallel to progressing the "base drafts" towards RFC > > > publications, the WG should now also begin to pick up the > pace on > > > our other adopted work items (ops drafts, extensions, etc.) > > > > > > One important other discussion item is what to do about the > > > multipath extension milestone, which some have suggested > > should be > > > dropped, while others still show interest to pursue it. > > > > > > > > > So, I'd like to understand the suggestion to drop this milestone, > > before > > > I start trying to discuss that suggestion :-). > > > > I'd like to understand this as well. > > > > I want to echo Jana's reply from the original discussion here > > <https://mailarchive.ietf.org/arch/msg/quic/R-uJhzzXBz-93OTmYupXu8ooJdA/>. > > > Everyone agrees multi-path transports are an interesting problem, and > > IETF participants love to solve interesting problems. It's not clear, > > however, that it should be a primary milestone of the working group at > > this time. > > I think that the main question is whether the working group wants to > have a generic transport protocol which can support a variety of > applications or wants a transport that is only tuned to the requirements > of HTTP. Given QUIC's architecture and clean design, it is possible to > do a generic and future proof transport that includes clean multipath > support that is much better than MPTCP. > As an HTTP/3 implementer, I believe it to be the best example we have of a protocol that exercises the generic transport capabilities. Particularly stream multiplexing, HoL avoidance, synchronisation across independent streams, sensitivity to iwnd and cwnd, and large transfers in both directions. Yes, there are other application protocols. But I am not aware of ones that can so clearly demonstrate impacts of stream interactions. This can be in the form of user-perceived performance or industry metrics such as Web Vitals [1]. HTTP is also a good example of a widely deployed application semantic that has been implemented across different libraries that have different design choices. This is an important consideration for the prioiritzation work because we need to consider what information an application is able to access from the transport, and how the application may/may not govern over transport behaviour. QUIC transport defines a set functions on streams that an application can rely upon [2], how does MP-QUIC augment that? I'm concerned about generic transport capabilities that cannot be reasonably used by applications without deep integration or layering violations. So it would be very useful for me to understand how a piece of HTTP server software (as an example of a real, complex application) would leverage MP-QUIC. [1] - https://web.dev/vitals/ [2] - https://tools.ietf.org/html/draft-ietf-quic-transport-31#section-2.4
