Lucas,
It's this special sauce that concerns me. > I don't know how I'd objectively
measure that the MP-QUIC design and all
the implementation effort would actual result in improvement. For
instance, more bandwidth via aggregation can still be misused; some
types of streams will be more latency sensitive than others. Putting the
decision making into the transport library could also be seen as black box.
I would suggest that we start by considering MPQUIC as a blackbox as we
did with MPTCP. This worked well and getting the multipath mechanisms
will be easy.
I also want to draw some parallels between uniflows and the HTTP/2
priority tree. The tree was a fully expressive model that allowed a
client to hint to the server about the relationship between streams. The
problem of actioning this signal was left up to the server. Deployment
experience reveals that getting this well-tuned, just for a single TCP
connection, is hard. Some implementers just never got around to fixing
some serious and easily detectable performance problems.
Presenting a bunch of uniflows to a sever and leaving it responsible for
using them properly seems to me quite a similar problem.
That's a policy decision and policy can be very complex. In MPTCP, we
have very limited support for policies:
- clients use a path manager to decide when they create subflows
- servers basically never create subflows (due to NATs and firewalls)
- clients and servers can use the backup bit to indicate that a subflow
should only be used if all the non-backup subflows failed or have problems
We discussed multiple times how to exchange policies over MPTCP. It
turned out that this was very difficult given the middleboxes. In the
end, MPTCP does not support the exchange of policies and the current
deployments embed the policies on the hosts that use MPTCP with a
specific path manager. This works well enough.
For MPQUIC, the situation could be different as there will be no direct
inteference from middleboxes that modify options. We could exchange
information such as the priority of a flow, mapping streams to flows,
rtt preference, capping flows, ... My fear is that if we open this, the
discussion could never stop and result in something similar that is too
complex to implement. I would suggest to focus initially on very simple
policies that are implemented locally (i.e. the application that uses
QUIC would control when and how to advertise addresses and when and how
to create flows, QUIC implementations could include different packet
schedulers) and discuss the possibility of exchanging this policy
information for a revision of MPQUIC.
Olivier
