Olivier, Many thanks for these resources. I'm slowly reading and digesting. Quentin's Thesis I think has some good discussion about consideration factors for an MP-QUIC abstract design, such as consideration of path validation etc. I don't know if uniflow is the correct design but it definitely helps to understand the motivation for it.
MP-QUIC appears to offer some things that conventional QUIC might not be able to do*. But it, to me, also presents some problems that don't exist today. As an individual commenter, not having an in-band signal for uniflow prioritisation gives me cause for concern. If I were to deploy an MP-QUIC general-purpose server, I don't have much confidence that I could meet the use cases that clients want. Cheers Lucas * Spencer occasionally mentions muticast in this thread, which I think is the autocorrect kicking in. But it's mention is relevant because the asymmetry of uniflows, and separation of data and control channels could solve some of the problems that draft-pardue-quic-http-mcast goes to length to design around.
