Hi Christian,
On Tue, 20 Jul 2021, 02:10 Christian Huitema, <[email protected]> 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
