Hi, Lucas, On Fri, Oct 2, 2020 at 12:51 PM Lucas Pardue <[email protected]> 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/ >
