Re: Preparing for discussion on what to do about the multipath extension milestone

[Matt Joras <[e-mail]>]

Two replies inline.

On Tue, Sep 29, 2020 at 1:12 PM Olivier Bonaventure <
[e-mail]> wrote:

> Spencer,
> >
> > On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert <[e-mail]
> > <mailto:[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 :-).
>
> I'd like to understand this as well.
>
I want to echo Jana's reply from the original discussion here
<https://mailarchive.ietf.org/arch/msg/quic/R-uJhzzXBz-93OTmYupXu8ooJdA/>.
Everyone agrees multi-path transports are an interesting problem, and IETF
participants love to solve interesting problems. It's not clear, however,
that it should be a primary milestone of the working group at this time.

> >
> > 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.
>
> We already have plenty of experience with MPTCP with several large
> deployments, including :
>
> - MPTCP on all iPhones since 2013 with a growing number of applications
> - MPTCP on Android smartphones in South Korea for WiFi/4G offload
> - MPTCP in hybrid access networks that are used by different network
> operators to combine xDSL and LTE
>
> Multipath extensions to QUIC would be applicable in these different use
> cases
>
There is a difference between "Someone is doing these things with MP-TCP",
and "Someone has shown interest and intent in doing these things with
MP-QUIC". Additionally, the first example can, as I understand it, largely
be replicated with QUIC connection migration. The other two I would like to
hear more about, because it would surprise me if they amounted to a
significant deployment. Support for MP-TCP in Android is virtually
nonexistent, for example.

We have deployment experience with pre-IETF QUIC, and growing deployment
experience with IETF QUIC itself. However, even things like connection
migration in the base drafts have been fully exercised in the real world
yet. As far as I know there have not been any major implementers or
"championing" applications showing a lot of interest in deploying MP-QUIC
in the near future, with the exception of the 3GPP's desire to integrate it
into the ATSSS specification. As I understand it, this interest does not in
itself even imply a deployment in the near future. I would rather we not
endeavor on tackling what is certainly going to be a difficult design
problem simply under the hope that "If you build it, applications will turn
up".

>
> > - 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).
>
> The packet scheduling problem is a much simpler problem in multipath
> transport protocol than congestion control. I would not consider this as
> a research topic given all the experience we have with MPTCP
>
> > 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.
>
> Same for me
>
>
> Olivier
>
> Matt Joras