Re: Multi-path QUIC Extension Experiments

[Lucas Pardue <[e-mail]>]

Hi Christian,



On Tue, 20 Jul 2021, 02:10 Christian Huitema, <[e-mail]> wrote:

>
> 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.
>

As an individual: could you qualify a bit more about what you mean by "know
enough"? For instance, the draft contains things like path priority and QoE
control signals. I'm unsure if those are the solution to put on a standards
track document, it seems like we are still figuring things out. Placing
those aside, the proposal in the I-D does seem like it would allow
interoperable experimentation of multipath QUIC, which is a good way to
flush out the things we don't know. In the past, we've seen other
proposals, like draft-deconinck,  that seem like they allow similar
experimentation too. Has there been any progress on aligning/combining
proposals?


> 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.
>

Agree. Thanks for sharing the results. As above, do the findings help
towards defining what interoperable QoE signals might be needed?


> 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.


One important thing there was to provide a default congestion controller
that was known to be safe on the Internet. That way, QUIC implementations
could bootstrap everything else they needed. Are there such safety concerns
with multipath scheduling?

Cheers
Lucas