One of the pillars of standardization work at the IETF is running code. Aside from some proof-of-concept implementations of multipath, I'm not aware of any implementation supporting any kind of MPQUIC, let alone any internet-wide experiments / deployments. From what I've seen on the interop runner, a large number implementations are still struggling with connection migration at the moment.
As others have said before, I do agree that multi-path is an intellectually challenging problem. It's not a problem we're in a hurry to solve at the current moment though: Given that QUIC is end-to-end encrypted, rolling out MPQUIC should be a lot easier than rolling out MPTCP, as we won't have to deal with ossified middleboxes. Before devoting a significant amount of working group resources on this particular problem, I'd like to see: 1. one (or multiple) big players driving experimentation and internet-wide deployment and 2. measurements that show that MPQUIC provides substantial benefits for real-world application protocols compared to vanilla QUIC with connection migration. On Wed, Sep 30, 2020 at 4:14 PM Lucas Pardue <[email protected]> wrote: > > 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 >
