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

[Olivier Bonaventure <[e-mail]>]

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