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

[Ian Swett <[e-mail]>]

I'm very receptive to Jana's arguments, but I think it's also worth
understanding how much work we believe this will be for the QUIC WG.

Many fairly complex multipath problems have already been dealt with by
supporting connection migration in QUIC v1, such as path validation and
linkability between flows.  Multiple packet number spaces during the
handshake means that implementations already have some ability to have
multiple loss recovery contexts, though they may not be easily adaptable to
multipath.

Scheduling seems like a big problem, but it's not clear to me that the QUIC
working group should be attempting to solve that.  I'd argue we should make
that explicitly out of scope if we took on this work.

The existing draft(draft-deconinck-quic-multipath-05
<https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) adds
ADD_ADDRESS/REMOVE_ADDRESS frames and modifies the ACK, NEW_CONNECTION_ID,
and RETIRE_CONNECTION_ID frames.  It also adds what appears to be a
debugging frame(UNIFLOWS) and a single transport parameter to indicate
support and indicate the max number of uniflows.  Having sets of CIDs per
path seems an unfortunate complication to me, but I haven't thought about
it enough.  The two new frames and modifications to the ACK frame are
simple enough.

Is there MORE work QUIC WG would have to do than what's described in the
draft?  If so, can people outline that work?

I certainly think MP-QUIC is a cleaner solution than MP-TCP.

I lean towards keeping multipath in scope, and I'd be willing to spend time
improving a proposal if it was adopted.  One reason is that I never want to
be forced to support MP-TCP because there is no MP-QUIC.  I also don't
think this has to be designed with HTTP in mind, even if that was the focus
of QUIC v1.  MASQUE/VPNs are a more compelling use case to me.

Ian

PS: It'd be good if someone from Apple could share their perspective on
whether MP-QUIC is necessary, since they have quite a bit of experience
with MP-TCP.

On Tue, Sep 29, 2020 at 4:31 PM Matt Joras <[e-mail]> wrote:

> 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
>