I think that the discussion around prioritization might be showing the problem behind how we have framed the dabate.
Multipath is a vague phrase, and to me it seems that people are referring to different features of it. It could be symmetric path migration, bandwidth aggregation, latency reduction by path selection, ... In case of prioritization, maybe it does not matter a lot if what people have in mind bandwidth aggregation. But if people want to run a latency-sensitive application on aggregate paths that gave varying RTTs, then path selection becomes a critical part of the application protocol. I think it would be much more fruitful to discuss about each specific feature of "multipath", what the use-case is, why it should be a WG item. If we are to make changes to the milestones, I'd prefer the milestones to clarify those specific features (and problems) that we will be solving, rather than talking about "multipath" which IMO is a vague term that people might disagree about the scope. 2020年9月30日(水) 22:39 Robin MARX <[email protected]>: > Hello all, > > I don't want to get too deep into this, as I don't have enough experience > with multipath to have a well-founded opinion. > > With regards to Lucas' questions on interfacing HTTP2/3 priorities with > multipath TCP/QUIC, I am aware of several recent works that have looked at > this problem (e.g., [1], [2], [3]). > I'm not entirely convinced of their results, methodology or conclusions > myself, but they all claim to see benefits for the Web page loading use > case. > I share the concern that this specifically is a generally difficult and > largely unsolved (research) problem and that APIs/interfaces for exposing > the full power of multipath to the application layer will be difficult to > create. > Then again, the same can be said for exposing QUIC-layer scheduling to the > application layer, and we seem to be happy to stick our heads in the sand > for that... > > I also feel it's important to make the clear distinction between general > multipath scheduling (what I feel is mostly what Olivier is describing) and > "stream-aware" scheduling (what I'd call "prioritiy-driven", and my remarks > above allude to), > where I get the impression the first is a generally solved problem for > MPTCP with a large body of research (and deployment experience) that can be > relatively directly re-used for MP-QUIC. > > > As a personal critical remark on the use of multipath for the Web browsing > use case, I feel that the wider Web performance community in general is of > the opinion that the network itself matters less these days, > and that the (ab)use of e.g., JavaScript frameworks, loading of (too) > large images, etc. has a much more profound impact on the observed user > performance than (limited) network bandwidth, > especially on slow mobile devices with limited processing capabilities. > > As such, I too posit that we should not consider Multipath just or > primarily for the HTTP use case (or hinge it on its application in that > area), but as a property of the general purpose transport that QUIC aims to > be. > In this context, like Olivier, I feel most of the lessons learned from > MPTCP can be transposed to QUIC, including its deployment experience. > If true, the question of the usefulness of MPQUIC devolves into the > usefulness of MPTCP, which I think the past decade of research and > implementation has shown to be considerable. > As such, I wonder if the amount of work necessary for MPQUIC isn't being > overestimated, as well as if (some of) the "outstanding questions" really > are unanswered. > > Robin > > [1] : A stream-aware multipath quic scheduler for heterogeneous paths - > Rabitsch et al. - https://dl.acm.org/doi/pdf/10.1145/3284850.3284855 > [2] : SRPT-ECF: challenging Round-Robin for stream-aware multipath > scheduling - Jonglez et al. - https://hal.inria.fr/hal-02570686/document > [3] : PriorityBucket: A Multipath-QUIC Scheduler on Accelerating First > Rendering Time in Page Loading - Shi et al. - > https://dl.acm.org/doi/pdf/10.1145/3396851.3402923 > > > On Wed, 30 Sep 2020 at 12:50, Lucas Pardue <[email protected]> > wrote: > >> It's this special sauce that concerns me. >> I don't know how I'd objectively measure that the MP-QUIC design and all >> the implementation effort would actual result in improvement. For instance, >> more bandwidth via aggregation can still be misused; some types of streams >> will be more latency sensitive than others. Putting the decision making >> into the transport library could also be seen as black box. >> >> I also want to draw some parallels between uniflows and the HTTP/2 >> priority tree. The tree was a fully expressive model that allowed a client >> to hint to the server about the relationship between streams. The problem >> of actioning this signal was left up to the server. Deployment experience >> reveals that getting this well-tuned, just for a single TCP connection, is >> hard. Some implementers just never got around to fixing some serious and >> easily detectable performance problems. >> >> Presenting a bunch of uniflows to a sever and leaving it responsible for >> using them properly seems to me quite a similar problem. >> >> Lucas >> >> >>> > > -- > > Robin Marx > PhD researcher - web performance > Expertise centre for Digital Media > > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > > > -- Kazuho Oku
