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

[Olivier Bonaventure <[e-mail]>]

Lucas,
> 
>      >
>      > Personally, I think starting on a basis of ignoring QUIC transport's
>      > core method of exchanging application data is a bad idea.
> 
>     I'm not suggesting that. I suggest that we first agree on the basic
>     multipath mechanisms without taking too much time to discuss different
>     and diverging application requirements. These mechanisms obviously need
>     to take into account the core characteristics of QUIC. One example is
>     that in contrast with MPTCP, MPQUIC acknowledgements do not necessarily
>     need to be transmitted over the same "path" as the data that they
>     acknowledge. This gives more freedom to an MPQUIC implementation
>     than an
>     MPTCP one. Another example are the flow control frames. Once we
>     agree on
>     these application-independent mechanisms, then we can start to discuss
>     about policies and how to handle them.
> 
> Seems like tail wagging the dog? If an "integrated assembly of 
> application and MPQUIC" as a whole has no clue how to send stream data 
> then deciding the best way to send ACKs is an afterthought. >
> To put it a different way, the problem is about packetization over time 
> windows, before worrying about path selection. 

In a single-path QUIC implementation, the implementation sends the next 
frames according to the congestion control scheme. When the congestion 
window is open, new frames can be sent. The QUIC protocol does striclty 
not mandate how different frames from different streams will be sent. 
Robin's measurements show that different implementations use very 
different strategies. The same will be true for multipath, expect that 
there will be one congestion controller per path. Each of these 
congestion controllers will open opportunities to transmit frames and 
the QUIC implementation will send frames when any of the underlying 
congestion window is open. This can be further optimised depending on 
the policies that are function of the considered use case.

> I get worried when I read 
> draft-deconinck-quic-multipath and it says
 >
>  > TODO: Add a companion document discussing the packet scheduling and 
> path management considerations.

I'm glad to see that there are now technical discussions on mpquic and 
would be happy to incorporate in the next revision of the draft the 
result of the ongoing discussion.

> I appreciate that could be a placeholder, so I'm trying to find out if 
> the knowledge and experience of MPTCP does actually help in anyway 
> bootstrap understanding of independent streams in a transport.
> 

Packet schedulers and path managers do not need to be precisely defined 
inside IETF documents. Based on discusions about MPTCP, we have 
summarised some of the used packet schedulers in

https://datatracker.ietf.org/doc/html/draft-bonaventure-iccrg-schedulers-00

We can write a similar informational document for path management if 
there is interest


Olivier