Re: Multi-path QUIC Extension Experiments

[Christian Huitema <[e-mail]>]

On 7/19/2021 3:36 PM, Lucas Pardue wrote:

> Interesting thread. There's a lot of stuff here.
>
> Speaking as an individual, I'm reminded that congestion control and path
> scheduling is an important factor for implementation of (the various)
> multipath QUIC proposals that have been floated. But IIRC the view was that
> these factors are not a core part of multipath QUIC protocol
> specifications. Therefore, I'm keen to understand if there is something
> that the QUIC transport protocol should or could provide to accommodate
> these concerns. E.g. new or different forms of signalling to avoid or
> improve on extant constraints.

In first order, you can split the multipath issue in two. On one hand, 
the mechanics of setting up paths, acknowledging path specific data, 
etc. On the other hand, the fine art of setting path at the right time, 
scheduling the right amount of packets on these paths, sensing the 
properties of the paths, etc.

I think that the mechanics of multipath are well covered in 
https://datatracker.ietf.org/doc/draft-liu-multipath-quic/, and I think 
we know enough about the problem to adopt that in the WG and drive it to 
publication.

I also think that we have ample opportunities to learn more about the 
fine arts of multipath scheduling. I love the idea of sharing as much of 
that experience as possible between implementers, and I appreciate that 
the Ali Baba team has been doing just that. But we probably are still 
going to learn more about all that for several years.

If we really need to publish something, we might be able to publish some 
kind of basic scheduling algorithm, with known limitations and known 
applicability. A bit  like we published a Reno specification for QUIC 
and pretended that was good enough.

-- Christian Huitema