We see high relevance for multipath-quic for the use cases we are developing. The timing is of importance so that quic can be used in the traffic steering use cases from the beginning (see ATSSS draft for details). Unnecessarily delaying multipath quic work will lead to use of MPTCP which we know cannot meet fully the requirements set for 5G. There is a high cost migration cost if starting with MPTCP and then swapping later to multipath-quic impacting the industry at large.
Similarly to Spencer I would like to understand the rational why to consider to drop multipath-quic. If such a decision is made it should be clear why. All those arguments that Spencer mentioned below have been faced and overcome with MPTCP. What makes quic so different that they cannot be solved (in a same way as with MPTCP)? Best regards Hannu From: QUIC <[email protected]> On Behalf Of Mikkel Fahnøe Jørgensen Sent: Sunday, September 27, 2020 7:38 PM To: Spencer Dawkins at IETF <[email protected]>; QUIC WG <[email protected]> Subject: Re: Preparing for discussion on what to do about the multipath extension milestone (was: Re: IETF Last Call for QUIC) At least I’d like to see multi-path with non-migration, for example to take advantage of multiple network cards, and to prioritize a VPN link but with WAN fallback at full capacity, or during service degradation. This especially so for long running connections server to server in order to avoid dealing with this at the application layer. Of course, it is non-trivial to state preferences, and QoS / latency / loss must be evaluated per link. Kind Regards, Mikkel Fahnøe Jørgensen On 27 September 2020 at 18.08.21, Spencer Dawkins at IETF ([email protected]<mailto:[email protected]>) wrote: Dear QUIC working group, On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert <[email protected]<mailto:[email protected]>> wrote: In parallel to progressing the "base drafts" towards RFC publications, the WG should now also begin to pick up the pace on our other adopted work items (ops drafts, extensions, etc.) One important other discussion item is what to do about the multipath extension milestone, which some have suggested should be dropped, while others still show interest to pursue it. So, I'd like to understand the suggestion to drop this milestone, before I start trying to discuss that suggestion :-). In conversations with individual folk, I've heard these concerns about QUIC multipath: - Whether it will be possible to evaluate multipath performance at scale, both for evaluating proposals and testing implementations. - The complexity involved in making decisions dynamically about which path to send a given packet on (which could be a research topic, given certain constraints and goals). If I've misunderstood or misquoted, my apologies, of course. Please correct me. What other concerns do people have? I'd like to get all the objections out at the beginning of the discussion. Thanks! Spencer
