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

[Olivier Bonaventure <[e-mail]>]

Lucas,
> 
>     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.
> 
> 
> Right. But the opportunities to send STREAM frames are driven by flow 
> control not just congestion. There are some strict mandates there. 
> Approaches such as binding a stream to a uniflow could cause starvation 
> of the related-path due to flow control even when congestion window is 
> open. 

I would suggest to start by not binding a stream to a specific uniflow. 
This might be added later if useful.

> Flow control is driven by applications putting data into the 
> transport, and consuming from it. I suspect HTTP/2 over MPTCP does not 
> have this problem, mainly because TCP's flow control trumps. But maybe 
> I'm wrong.

MPTCP provides the same bytestream as TCP and does not expose anything 
special AFAIK to HTTP/2

> Some implementations like quiche decouple the transport library from 
> UDP. Applications hoping for MP-QUIC with such implementations will have 
> to accommodate some of the complexity, the transport cannot do it all.

Path management (i.e. deciding when to create uniflows) is something 
that MPQUIC applications could do. The Linux MPTCP implementation 
initially included this feature as a set of kernel modules. It involved 
to libraries that interact with the kernel using netlink, see

https://inl.info.ucl.ac.be/publications/smapp-towards-smart-multipath-tcp-enabled-applications.html

> I do agree that we don't have to solve all of these things upfront and 
> in one document. But I think there is a risk of defining mechanisms and 
> ignoring some pathological cases. As a parallel, QUIC provides 
> congestion control mechanisms and does not mandate any algorithms but it 
> has taken care to suggest one that is going to be safe to deploy on the 
> Internet.

This is a reasonable approach

> Lucas
> 
> [1] https://mailarchive.ietf.org/arch/msg/quic/OlwAHMyK2mAuRCRuCP-Lpyb7ntA/
> [2] https://github.com/quicwg/base-drafts/issues/3332


Olivier