Hi, Lucas, On Sun, Oct 4, 2020, 18:33 Lucas Pardue <[email protected]> wrote:
> 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. > That would have been unintentional, but I'm glad if I make helpful errors from time to time. ;-) Best, Spencer >
