Re: Preparing for discussion on what to do about the multipath extension milestone

[Robin MARX <[e-mail]>]

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 <[e-mail]>
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 [phone] - GSM [phone]

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05