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 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. Lucas >
