Re: Preparing for discussion on what to do about the multipath extension milestone

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Lucas,

On Sun, Oct 4, 2020, 18:33 Lucas Pardue <[e-mail]> 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

>