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

[Olivier Bonaventure <[e-mail]>]

Lucas,
>      > - The complexity involved in making decisions dynamically about
>     which
>      > path to send a given packet on (which could be a research topic,
>     given
>      > certain constraints and goals).
> 
>     The packet scheduling problem is a much simpler problem in multipath
>     transport protocol than congestion control. I would not consider
>     this as
>     a research topic given all the experience we have with MPTCP
> 
> 
> As an individual and co-author on the Extensible Prioirties scheme for 
> HTTP, I am very interested to know how MP-QUIC scheduling would interact 
> with HTTP/3 servers doing HTTP prioiritization scheduling when handling 
> concurrent requests. Are you aware of work that has looked at this in 
> either MP-QUIC or MPTCP+HTTP/2? Is there clear improvement in web 
> browser KPIs, for instance?

The work that I know is Robin Marx's work, but AFAIK he has not studied 
MPTCP or MPQUIC.

Concerning prioritization, MPQUIC exposes streams like QUIC to the 
HTTP/3 application. It could be possible to expose some of the 
characteristics of MPQUIC to HTTP/3, but this is not required. MPTCP 
provides the same socket API to applications and enables them to work as 
if they were using TCP, except that they get better resilience and 
higher throughput for free.

The same is true for MPQUIC. MPQUIC allows the application above to be 
resilient to handovers, lower performance on one path, and benefit from 
bandwidth aggregation when operating over low-speed networks, without 
having to deal with all these problems themselves.

It is possible to expose some information from MPQUIC and the underlying 
paths to the application above, but I'm not convinced that this is 
really required. What worked well for Multipath TCP is the definition of 
policies that are used by the MPTCP implementation and relate to the 
deployment use case. Here are a few deployed examples :

  - on iPhones, some users (e.g. those with an unlimited data plan) want 
to use the best network interface
  - on iPhones, some users (e.g. those with a limited data plan) agree 
to use cellular when Wi-Fi becomes too bad. MPTCP measures the rtt and 
the timeouts and switches to cellular when performance decreases
  - in hybrid access networks, operators want to first use DSL before 
LTE. MPTCP fills the DSL pipe first and only uses LTE when DSL is fully used

I think that MPQUIC deployments would also use similar policies.



Olivier