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
