Re: Multi-path QUIC Extension Experiments

[Mikkel Fahnøe Jørgensen <[e-mail]>]

> On 20 Jul 2021, at 11.28, Robin MARX <robin.marx=[e-mail]> wrote:
> 
> It is however utterly strange to me that this approach would continue for QUIC (at least in endpoint multipath, not things like in-network aggregators that have been discussed),
> where we have clear splits between streams and (hopefully) already some type of prioritization information for each stream. 
> For QUIC, I'd expect one-path-per-stream to be the default, with multiple-paths-per-stream to be an edge case if you have a single, high-traffic stream (which I do assume is your situation with a video stream). 

Already with QUIC v1 there is a lot unsaid about the scheduling and stream prioritisation. As I understand, it is expected that certain application level protocols can place demands on the QUIC transports they support, but specifying a specific API for the transport would be very hard, and limiting. H3 naturally implies certain features in the transport API.

We did try being more elaborate with H3 stream priorities, even though this was only at application level, and even that proved too complex.

Thus, I doubt that tying the application layer closer to the transport layer will be verysuccessfull, but there will be some API features expected for the most successful MP app protocols, and it is certainly worth discussing what these should be, just as for H3, but it does not imply a tight coupling at the transport specification level.

Mikkel