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]) wrote: Dear QUIC working group, On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert <[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
