Re: Preparing for discussion on what to do about the multipath extension milestone (was: Re: IETF Last Call for QUIC)

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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 (
[e-mail]) wrote:

Dear QUIC working group,

On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert <[e-mail]> 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