Re: Preparing for discussion on what to do about the multipath extension milestone

[Lucas Pardue <[e-mail]>]

On Wed, 30 Sep 2020, 09:07 Olivier Bonaventure, <
[e-mail]> wrote:

> Matt,
> >      >
> >      > On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert <[e-mail]
> >     <mailto:[e-mail]>
> >      > <mailto:[e-mail] <mailto:[e-mail]>>> 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