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
