RE: Take multipath to a BoF

[Florin Baboescu <[e-mail]>]

Hi Martin,

I'm not sure that we follow the same discussion otherwise I do not know
how you may say " there are only a small number of people who want to
pursue multipath ". As one who regularly attends and contributes in 3GPP
on related topics and also follows the IETF work in QUIC at least for the
last year I can easily say that there is a very wide spread ecosystem of
companies which are interested in the multipath feature to be developed
for QUIC. This includes both network vendors, terminal vendors, operators
and OTT providers. So I believe that your statement is very far away from
reality.

With regard to your proposal for a BoF I believe it to be a waste of time
and I expressed this opinion also while we were still able to meet face to
face. There are few reasons why I consider this to be a waste of time.
	1. We are not starting to do something abstract and various use
cases which are considered to be important by many companies have been
captured and detailed.
	2. There is a draft, which is not perfect but it definitely has a
good amount of goodput on which we may start building on.
	3. There is a vast amount of knowledge and experience accumulated
through the design of MP-TCP and not only which may be used for this
design too.

I believe that both Ian and Christoph made some very constructive
proposals on how to proceed with this work. Also the proposal from Lars
to schedule a WG interim for multipath  is a positive way forward,
although the proposed times are extremely unfriendly for the ones in the
Pacific Time zone. :)

In this context I hope you may understand why I consider your proposal is
nothing else but saying to do it ad calendas graecas.

All the best,
-Florin


-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
Sent: Tuesday, October 6, 2020 7:02 PM
To: [e-mail]
Subject: Take multipath to a BoF

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.