+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. [1] https://mailarchive.ietf.org/arch/msg/quic/p2II8y3y1FXy4kWMSuf1lgAXaFA/
