Re: Take multipath to a BoF

[Spencer Dawkins at IETF <[e-mail]>]

This is an interesting thread to wake up to (in the US, of course). Thanks
for starting it, Martin.

Top-posting, because I agree with Mirja, but just to add one point - I
thought one of the things we were discussing was taking whatever multipath
QUIC turns out to be, to Experimental.

The reason a BOF would make sense, IMO, would be if we didn't have a venue
for discussion - but I'm told by the QUIC chairs that it's appropriate for
QUIC.

The other reason a BOF would make sense, IMO, is to find out whether people
are willing to work on something that's not already chartered, but QUIC is
already chartered to work on multipath.

I'd encourage us to start on multipath in QUIC, targeting Experimental if
the working group thinks that's a plan, as guided by the chairs, and see
what happens.

If no one works on it, problem solved.

 If the Experimental is deployed in walled gardens and turns out to be
problematic, problem solved.

If too many people work on it, and it crowds out other essential QUIC work,
the ADs can charter a working group without going through a BOF, problem
solved.

If you're hoping for a Spencer rant-free day, please stop reading here :-)

Best,

Spencer

P.s. I'm not going to rant on what people would expect me to rant on, but I
do have a rant.

<rant>

Our experience with MP-TCP is that people do use multiple paths,
simultaneously, when a transport protocol offers them.

As Mirja says, there are use cases, and I think there are more use cases,
once we aren't limited to TCP-based applications, so more people will be
willing to use them, and the use cases won't magically disappear if we
don't work on multipath QUIC in the IETF.

So, what I'm seeing in 3GPP SA2, is people are realizing that if they're
going to use QUICv1 for their applications, something is going to have to
handle multipath, and if it's not whatever multipath QUIC turns out to be,
it isn't likely to turn out to be useful for the broader internet.

I won't speculate on the ability of people outside the IETF to come up with
multipath solutions using QUICv1 that don't have problems, but I will note
that when we had applications that couldn't handle everything that came
with TCP, our answer was "well, your other choice is UDP", and that's been
a consistent thorn in the side of every protocol that went that direction
(I'm looking at you, SIP), and the IETF has had to produce BCPs for UPD
usage guidelines (RFC 5405, obsoleted by RFC 8085) and a host of other RFCs
on Circuit Breakers and other mechanisms. But our overarching answer, for a
decade or two, was "you'll probably end up adding so many mechanisms that
are already in TCP, that you might as well have used TCP". And that was
true until we did SCTP and, now, QUIC.

I'd expect a similar result with multipath, if it's done outside the IETF.

</rant>

On Wed, Oct 7, 2020 at 7:35 AM Mirja Kuehlewind <mirja.kuehlewind=
[e-mail]> wrote:

> Hi Martin, hi all,
>
> I've been just catching up on this discussion after holidays and reading
> it all at ones, I actually did see a good set of common and reasonable use
> cases, and there is a plausible solution which is a good starting point,
> plus there is clearly a group of interested participants.
>
> I understand the worry that this work will of course take some effort
> (even though there are different views about how much effort it will take)
> and that it could take resources away from those items we have already
> agreed to work on. However, I also see that multipath support where
> multiple paths can be used simultaneously is a fundamental feature that
> generates interest. So far we have been able to work on various things in
> parallel, because there are subgroups in the wg that are more interested
> and are more experienced in e.g. http and maybe less in congestion control
> or the other way around. I think this is also doable in future. For
> multipath support I'd be more worried to move that work into a separate
> group as it is a fundamental feature and what we have seen for the MPTCP wg
> is that we at the end had a split of people where some of the usual TCP
> expert would not participate in the MPTCP discussion anymore which I think
> was also not ideal.
>
> I think at this point we should start the technical discussion on MP-QUIC
> based on what is specified in the individual draft we have around for a
> while. I was actually happy to see this kind of started (even though I
> think it would be more helpful if people could also state why they don't
> agree with a certain approach). Maybe we should also discuss if we want to
> update the charter and scope down what multipath capabilities we want to
> work on e.g. explicitly exclude scheduling and path management but focus on
> the signaling and transport features to simultaneous use multiple paths.
> Further we should prioritize the work where we have already adopted wg
> documents, however, I also see that at least 3 of those 5 documents are in
> good shape and can hopefully go to last call soon. As soon as those last
> calls for most of the current items are done, that's the time for me to run
> an adoption call for an multipath extension (or even a new version that has
> full multipath support), but it would be really good to have made progress
> on the technical discussion until then to get some common understand on the
> base principles we want to take to enable full multipath support.
>
> Mirja
>
>
> On 07.10.20, 04:03, "QUIC on behalf of Martin Thomson" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>     I know that this subject line might be taken to be inflammatory, but
> no point in burying the lede.
>
>     The original charter for QUIC included multipath, partial reliability,
> and FEC.  Multipath was definitely firmer than the others, but it was still
> aspirational.  As part of a larger package deal, it seemed OK at the time.
>
>     What has become clear to me over time is that there are only a small
> number of people who want to pursue multipath.  And I don't know whether
> those people have common use cases or even if a single solution is
> appropriate for all of those use cases.
>
>     Right now, it is not clear to me that we have the right combination of
> problem statements (or use cases), plausible solutions, and participants to
> successfully drive toward a design.  I've followed the discussion recently
> and this has become increasingly apparent.
>
>     The IETF processes for deciding whether to take on new work are
> designed to prove that there is a need for a standard.  That need depends
> on proof of three things: supporting use cases, credible solutions, and
> interested participants.  That process, by which I mean BoFs, is imperfect,
> but they are the best we have.  And it looks like this working group is on
> a path to avoid that process.  That would be a mistake.  By coasting into a
> decision here, we risk confusing enthusiasm for QUIC as a whole for
> interest in this one feature.
>
>     I appreciate that some people believe that there was an understanding
> reached on this topic.  I know we've talked about this a number of times.
> But discussion was always about deferral in the past.  We're now talking
> about concretely committing time to this.
>
>     If the group had nothing else to do, then I'd be less concerned about
> the time being spent on this.  I have no real interest, but I could go
> elsewhere.  But QUICv1 is hardly done.  We have more deployment experience
> to learn from, version negotiation, datagrams, performance tuning, and
> enough stuff to keep this community busy.
>
>     If this community is not committed to building multipath capabilities,
> then forcing that upon them would be counterproductive.  If the community
> is indeed committed, then a demonstration of that commitment should not be
> difficult to muster.
>
>     Deciding whether the IETF should design a multipath QUIC needs to go
> to a BoF.
>
>
>