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
