Subject: Take multipath to a BoF

From: "Martin Thomson" <[email-masked]>
Date: Wed, 07 Oct 2020 13:02:04 +1100

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.

---

From: David Schinazi <[email-masked]>
Date: Tue, 6 Oct 2020 20:15:23 -0700

I agree with Martin here. I would personally attend the BoF
and commit to reviewing drafts, but I think that separating
multipath from other work items that are more critical to the
success of QUICv1 is the right thing to do.

David

On Tue, Oct 6, 2020 at 7:02 PM Martin Thomson <[email-masked]> wrote:

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 7 Oct 2020 13:07:45 +0900

My +1 goes to MT too.

While I do not have a strong opinion (or knowledge) of the IETF process, I
think it would be better to talk about what MT mentioned: supporting use
cases, credible solutions, and interested participants.

Let's agree on where the goal is, before starting to discuss how we should
reach the goal.

2020年10月7日(水) 12:15 David Schinazi <[email-masked]>:

>> The original charter for QUIC included multipath, partial reliability,
>> and FEC.  Multipath was definitely firmer than the others, but it was still

-- 
Kazuho Oku

---

From: Florin Baboescu <[email-masked]>
Date: Tue, 6 Oct 2020 21:21:50 -0700

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:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, October 6, 2020 7:02 PM
To: [email-masked]
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.

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.

Deciding whether the IETF should design a multipath QUIC needs to go to a
BoF.

---

From: Marten Seemann <[email-masked]>
Date: Wed, 7 Oct 2020 16:39:53 +0700

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.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 7 Oct 2020 12:35:23 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Oct 2020 09:29:22 -0500

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=
[email-masked]> 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" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     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
>     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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Oct 2020 16:35:30 +0200

On 2020-10-07, at 14:35, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> 
> 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.

How much of the current discussion is essentially about QUIC people covertly telling us they wouldn’t want to participate in the multipath-QUIC discussion any more?

Grüße, Carsten

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 7 Oct 2020 16:15:04 +0100

Hey Spencer,

On Wed, Oct 7, 2020 at 3:30 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

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

To tug on this thread a little and speak as an individual. I find the
charter pretty light on detail wrt multipath. Yes it is mentioned but
AFAICT the capability has complexity of implementation and deployment that
is at least on par with any of the other standalone focus areas. Each of
those has a pararaph with some even leaning on other groups' definitions.
In contrast, multipath has scant information for what is in scope of
discussion or not. How can people say decisively what they signed up for?

It is also unclear to me how multipath relates to our other deliverables of
Applicability and Manageability drafts. Do those get held up, or does
MPQUIC get its own equivalent?

Without the WG agreed on the problem statement and use cases, I can forsee
future challenges if divisive topics come up. We've seen instances through
the course of QUIC interop and design iteration where an issue has come up
and there have been multiple competing options. We've been able to overcome
those, in part, because we can fall back on the charter's key goals of
"minimizing connection establishment and overall transport latency for
applications" and "Providing multiplexing without head-of-line blocking",
and the secondary goals or constraints in each paragraph.

Do those key goals apply equally to MP-QUIC? I've asked this in other
threads and the response has seemed to indicate that uptime and bandwidth
is more important...

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Oct 2020 10:51:03 -0500

Hi, Lucas,

> discussion or not. How can people say decisively what they signed up for?

Let me emphasize strongly that I have no hat to wear in this discussion ...

In discussions about the QUIC charter in 2016, my opinion was that it was
silly to charter a major transport protocol with no mention of multipath,
because we kept chartering work on transport protocols to retrofit
multipath (with MP-TCP being only one example, but it was the one freshest
in my mind).

But adding it to the charter without a lot of details was fine with me. My
overarching consideration was whether we could deliver a transport protocol
that worked well enough for Google to use it for HTTP, and if the answer to
that had been "no", we wouldn't be having this conversation.

With my encouragement as then-AD, the chairs focused on getting QUICv1
finished, and that seems to have been the case after Magnus replaced me,
until fairly recently (the datagram extension is probably the biggest
exception to my statement).

I hear you, on complexity of implementation and deployment, and that's one
of the reasons I was speaking in favor of Experimental status.

> It is also unclear to me how multipath relates to our other deliverables
> of Applicability and Manageability drafts. Do those get held up, or does

We asked similar questions about the relationship of what
became draft-ietf-quic-recovery and what became draft-ietf-quic-transport,
but the working group Did The Right Thing (IMO). I've seen at least one
person asking why multipath isn't part of the core QUIC protocol, but I
think that's a conversation better had later, after there's experience with
an Experimental draft.

I'd hope the working group would do the right thing then, too.

> threads and the response has seemed to indicate that uptime and bandwidth

I might have opinions, but that's (IMO) the right question for a QUIC Chair
to be asking.

Thanks for tugging on all of this.

Best,

Spencer

p.s. In about 2001, I asked Bob Braden why the IESG was chartering so many
working groups to do use cases, problem statements, and requirements before
they started doing actual protocol work. Bob looked at me and said, quote,
"is it not obvious to you that's to slow people down while we figure out
whether they're crazy?"

I honestly have no idea whether he was kidding, and I can't ask him now,
but ... so I'm hoping experience with Experimental specifications can
inform that, as was the case with Multipath TCP, now Standards Track.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Oct 2020 10:20:13 -0700

Some comments in-line.

On Wed, Oct 7, 2020 at 8:51 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Also speaking with no hats on, I think this is an accurate read of why
multipath was in the original charter.  At the very least, we wanted to be
sure that the QUIC working group thought about concurrent use of multiple
paths while working on the method for path switching.  While it certainly
hasn't been at the top of the list, I do think that it has been present
enough in the discussion that our existing toolkit won't need much
extension to get to concurrent path use.

Unfortunately, that doesn't mean we're a short draft away from success.
There are a bunch of different optimization knobs and levers which
magically appear when you move from one path to multipath (along with a few
new failure modes and privacy pitfalls).  Working out what settings on the
knobs and levers should be for different use cases is a good use of the
Experimental track, at least in my opinion, especially given the privacy
issues and failure modes.

If we had no sense of the use cases, then a  non-wg-forming BoF to discuss
them might be a useful step.  I've seen enough of them on this and other
threads to not believe that's needed, but I also won't object if other
folks want that.  But ultimately, I think the work has to remain part of
the core transport work on QUIC.  Without that, I think you get MP-QUIC as
a distinct transport from QUIC, rather than enabling QUIC to both path
switch and run over concurrent paths.  That's a substantially worse
outcome, at least in my opinion. I don't work for Apple, but I will
champion them for a moment without speaking for them:  I am convinced by
their use cases alone that this work is worth doing in the IETF.

Just my two cents,

regards,

Ted Hardie

>> Without the WG agreed on the problem statement and use cases, I can
>> forsee future challenges if divisive topics come up. We've seen instances
>> through the course of QUIC interop and design iteration where an issue has
>> come up and there have been multiple competing options. We've been able to
>> overcome those, in part, because we can fall back on the charter's key
>> goals of "minimizing connection establishment and overall transport latency
>> for applications" and "Providing multiplexing without head-of-line
>> blocking", and the secondary goals or constraints in each paragraph.
>>
> I might have opinions, but that's (IMO) the right question for a
> QUIC Chair to be asking.
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 7 Oct 2020 14:33:39 -0700

Hi Ted,

(no hats here)

> folks want that.  But ultimately, *I think the work has to remain part of
> the core transport work on QUIC*.  Without that, I think you get MP-QUIC
> as a distinct transport from QUIC, rather than enabling QUIC to both path
Depending on what you mean, I'm not sure I agree with the bolded part.
There is almost certainly some amount of protocol (frame types, etc) that
have to be defined in QUIC, and I agree that this should happen in the WG.

But there are other more interesting problems (scheduling, congestion
control, etc) that are applicable to all the failover-capable transports
(MPTCP, SCTP, QUIC). I could be persuaded otherwise, but I think the latter
is best done not in QUIC, but instead either in TSVWG or a WG purpose-build
to do so.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Oct 2020 14:55:03 -0700

Howdy,

On Wed, Oct 7, 2020 at 2:33 PM Martin Duke <[email-masked]> wrote:

>> folks want that.  But ultimately, *I think the work has to remain part
>> of the core transport work on QUIC*.  Without that, I think you get
>> MP-QUIC as a distinct transport from QUIC, rather than enabling QUIC to
>> both path switch and run over concurrent paths.  That's a substantially
>> worse outcome, at least in my opinion. I don't work for Apple, but I will
> That's the key thing I think we need, so I'm glad we agree at least up to
here.

> is best done not in QUIC, but instead either in TSVWG or a WG purpose-build

I continue to disagree here, largely because what you can do about
scheduling, congestion control, etc. varies among the different
transports.  There are certainly common research topics, and if we were
describing an RG, I'd agree that a dedicated group with a scope that
included all of them would be a good result.  But for a working group, the
engineering constraints and opportunities are sufficiently different that I
don't think any of them are well served by being lumped together.  You
might get a common solution, but there's a real possibility that it would
be the least common denominator.

Just my opinion, of course.

Ted

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 7 Oct 2020 17:53:53 -0700

Thanks, Martin, for this suggestion. While it seems inflammatory, and while
the chairs/ADs may disagree with wanting this to become a BoF, I agree with
your reasoning. A few points.

First, I want to say that multipath is a good thing to have in the long
term. It will take work -- even if you disagree that it will, it would be a
mistake to assume that it won't -- and I think we ought to do the work
necessary to make it happen.

However, the timing of this conversation is poor. In Martin Thomson's words:

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

I find myself questioning the urgency and the timing of this discussion. I
do not want to put aside stuff that we ought to be doing to ensure that
QUICv1 gets out there and is adopted widely, which is where a number of
folks are spending cycles right now (many of the folks deeply engaged in
QUICv1 are now actively trying to deploy and iterate.) The success of
QUICv1 depends on these deployments succeeding, and we need to provide room
in the WG for these discussions.

I'll also re-emphasize that we need strong interest and commitment to
implement and experiment. In Marten Seemann's words: "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".

Even if it's not in a BoF, we ought to be asking the same questions of
starting this work within this WG right now.

On Wed, Oct 7, 2020 at 2:55 PM Ted Hardie <[email-masked]> wrote:

>> If we had no sense of the use cases, then a  non-wg-forming BoF to
>>> discuss them might be a useful step.  I've seen enough of them on this and
>>> other threads to not believe that's needed, but I also won't object if
>>> other folks want that.  But ultimately, *I think the work has to remain
>>> part of the core transport work on QUIC*.  Without that, I think you
>>> get MP-QUIC as a distinct transport from QUIC, rather than enabling QUIC to

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 8 Oct 2020 09:58:54 +0200

Martin,
>     discuss them might be a useful step.  I've seen enough of them on
>     this and other threads to not believe that's needed, but I also
>     won't object if other folks want that.  But ultimately, *I think the
>     work has to remain part of the core transport work on QUIC*. 
>     Without that, I think you get MP-QUIC as a distinct transport from
>     QUIC, rather than enabling QUIC to both path switch and run over
>     concurrent paths.  That's a substantially worse outcome, at least in
>     my opinion. I don't work for Apple, but I will champion them for a
>     moment without speaking for them:  I am convinced by their use cases
>     alone that this work is worth doing in the IETF.
> 
> 
> There is almost certainly some amount of protocol (frame types, etc) 
> that have to be defined in QUIC, and I agree that this should happen in 
> the WG.

Totally agree

> (MPTCP, SCTP, QUIC). I could be persuaded otherwise, but I think the 
> latter is best done not in QUIC, but instead either in TSVWG or a WG 
> purpose-build to do so.

The work on congestion control typically happens within ICCRG. MPTCP 
adopted the coupled congestion control RFC6356 which is a variant of 
NewReno adopted to the multipath scenario. Improvements have been 
proposed in the scientific literature and implemented but not documented 
in RFCs. Some work on ICCRG in making CUBIC multipath ready would make 
sense and would naturally apply to different transport protocols (MPTCP, 
QUIC, SCTP), possibly with minor changes.

For the schedulers and path managers, there are two different points to 
consider: the algorithms and the require protocol messages. It is 
possible to document generic algorithms that are applicable to different 
protocols. A first step in this direction is
https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-01
that was targeted at iccrg in March but could be moved elsewhere
A similar document could be written about path management.
However, in both cases, the protocol messages need to be defined in 
their respective working groups. Given that there are no middlebox 
interferences with MPQUIC, it will be possible to define more precise 
messages in MPQUIC than in MPTCP.

Olivier

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 8 Oct 2020 04:36:40 -0500

Just to chime in here ...

> QUIC, SCTP), possibly with minor changes.

What the QUIC charter says now about this, for single-path QUIC, is

"The first of these is the core transport work, which will describe the
wire format, along with the mechanisms for connection establishment, stream
multiplexing, data reliability, loss detection and recovery, congestion
control, and options negotiation. Work on congestion control will describe
use of a standardized congestion controller as a default scheme for QUIC.
Defining new congestion control schemes is explicitly out of scope for this
group. QUIC is expected to support rapid, distributed development and
testing of features."

That's actually stronger than the initial approved charter, which said the
working group would describe the use of an *existing* congestion controller.

If Experimental is on the table, I note that
https://datatracker.ietf.org/doc/rfc6356/ has been Experimental since 2011,
which shouldn't be a problem.

So I think this argues for doing an Experimental QUIC multipath document.

Best,

Spencer