Lucas,
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
MPQUIC would provide the same streams abstraction as QUIC, no changes
are required to [2]. To support multiple streams a QUIC sender needs to
include an algorithm to decide which data frame (from which stream)
needs to be sent when there is a transmission opportunity (congestion
window is open). MPQUIC is similar, except that it needs to decide on
which path the data will be sent. We could expose some information about
the different paths to the applications, but I don't think that this is
required. A MPQUIC implementation will select the utilisation of the
different paths based on policies that typically depend on the use case
and the deployment model.
Different policies can be defined as different QUIC implementations
might use different congestion control schemes or different stream
schedulers.
Considering your HTTP server use case, here are a few possible policies
and their impact on MPQUIC.
1. Consider a dual-stack HTTP server that wants to use the best
performing path between IPv6 and IPv4. When a client connects over IPv4,
the server advertises its IPv6 address and MPQUIC automatically starts
to use the two path. If one is significantly better, traffic will move
to that path without any involvment of the HTTP server
2. Consider again a HTTP server that serves customers in rural areas
where DSL and 4G are slow and in cities where fiber is deployed. When
smartphones connect, they advertise to MPQUIC their WiFi (attached to
DSL/fiber) and 4G addresses. MPQUIC can be configured to only accept a
second subflow over the 4G if the primary one does not perform
correctly. With MPQUIC, the HTTP server would aggregate the 4G and DSL
bandwidth in rural areas while only using fiber in cities.
The main benefit of putting multipath inside the transport is that the
application does not need to handle the problems that occur on any of
these paths. The transport has access to round-trip-times and loss
measurements and has all the information required to manage the
different paths efficiently.
Olivier
