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

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

Hi, Lucas,

On Fri, Oct 2, 2020 at 12:51 PM Lucas Pardue <[e-mail]>
wrote:

> +1 to the suggestion to discuss use cases, it is helpful for clarity. And
> thanks Christoph for sharing some specific ones.
>
> For the use cases "Siri" and "Apple Music", since I'm not experienced with
> multipath there's a gap in my understanding of how the proposal in
> draft-deconinck-quic-multipath would be used to satisfy these use cases.
> For instance, is the behaviour client-driven, server-driven or does it
> require coordination? Would anyone be so kind as to share _an example_ of
> how uniflows would be used within a QUIC connection that uses a
> request/response paradigm for data exchange.
>
> > Another question, and perhaps this is getting increasingly off-topic,
> but now that we are getting into designing "significant" extensions, I
> think it is worth asking whether this should be an extension at all. I.e.
> should MPQUIC be a core feature of QUICv2?
>
> I tried to spin that out into another thread [1]. IIRC someone previously
> suggested that MP-QUIC could start as an experimental version of it's own.
> I can't find a citation for that though sorry.
>

At a minimum, Martin and I have both been talking about experiments,
experimental drafts, and perhaps even experimental versions, but I think
the clearest citations is Martin's, at
https://mailarchive.ietf.org/arch/msg/quic/FH8JDTD5noAbnsSjr7s4sVuiI5o/.

He also noted that Magnus is the responsible AD for QUIC in his note.

Best,

Spencer


> [1]
> https://mailarchive.ietf.org/arch/msg/quic/p2II8y3y1FXy4kWMSuf1lgAXaFA/
>