Re: Take multipath to a BoF

[Marten Seemann <[e-mail]>]

To me, what matters more than people just interested in QUIC multipath, are
people who’re actually willing to put in the work to implement it,
experiment with it on an internet-wide scale and gather data to inform
future specification work.

Given the current status of most QUIC implementations, I'm not sure if
we're at the point where standardizing MPQUIC makes sense yet: Most code
that is getting deployed now is still experimental, only enabled for a
small fraction of end users and will likely undergo very heavy work to
fulfil the performance promises of QUIC as compared to TCP. Therefore, it
will probably take some time until we have a solid baseline to compare an
even more experimental multipath implementation to.

If there are applications that rely on MPTCP and for that reason can't be
migrated to QUIC (even with connection migration), that's not the end of
the world, for now. Actually, this would be an excellent starting point to
experiment with MPQUIC outside of the IETF, come up with a design that
actually improves the relevant metrics, and later on inform the
standardization work on MPQUIC, if the results are convincing.

On Wed, Oct 7, 2020 at 11:22 Florin Baboescu <florin.baboescu=
[e-mail]> wrote:

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