Subject: Next steps for Multipath QUIC

From: Lars Eggert <[email-masked]>
Date: Fri, 20 Nov 2020 11:30:13 +0200

Hi,

Lucas and me got asked what we'd see as the next steps for multipath support for QUIC. Here's our current thinking:

The QUIC WG remains the default venue for continued open discussion of multipath experiments and results. The goal for this discussion is to help steer towards identifying whether a multipath design can emerge that

(1) addresses a number of the use cases discussed during the interim, or new use cases that are similarly motivated

(2) sees implementation and experimentation/deployment interest from a number of production stacks

(3) is (as much as possible) a minimally-scoped extension to QUIC v1 that cleanly integrates with its concepts and other adopted extensions

Until this has happened, we think it'd be premature to adopt one of the individual multipath designs that have been proposed as a WG work item.

We hope this provides some clarification.

Thanks,
Lars and Lucas

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 20 Nov 2020 01:39:59 -0800

I believe it is good to have experimental results as extensions, or
otherwise, fleshing out the various concepts before committing to anything.

One aspect that isn’t clear to me is the symmetri of multipath, and also
for migration post V1.
I for one would like to see more symmetri for data center deployments, at
least for multipath.

Mikkel

On 20 November 2020 at 10.30.39, Lars Eggert ([email-masked]) wrote:

Hi,

Lucas and me got asked what we'd see as the next steps for multipath
support for QUIC. Here's our current thinking:

The QUIC WG remains the default venue for continued open discussion of
multipath experiments and results. The goal for this discussion is to help
steer towards identifying whether a multipath design can emerge that

(1) addresses a number of the use cases discussed during the interim, or
new use cases that are similarly motivated

(2) sees implementation and experimentation/deployment interest from a
number of production stacks

(3) is (as much as possible) a minimally-scoped extension to QUIC v1 that
cleanly integrates with its concepts and other adopted extensions

Until this has happened, we think it'd be premature to adopt one of the
individual multipath designs that have been proposed as a WG work item.

Thanks,
Lars and Lucas

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 23 Nov 2020 09:01:45 +0000

There seems to be three different approaches for multipath support, if I am not missing any:

 https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/ 
https://datatracker.ietf.org/doc/draft-an-multipath-quic/ 
https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/ 

Each of them addressing different use cases. It is not obvious to me that the experimentation would lead into single design rather than debate between the approaches.
I would expect as the outcome of the experimentations  deeper differences between the multipath mechanisms tailored for respective use cases. How can we draw any generic conclusions from such results? How would you compare the outcomes? 

Best regards
Hannu 

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Lars Eggert
Sent: Friday, November 20, 2020 11:30 AM
To: QUIC WG <[email-masked]>
Subject: Next steps for Multipath QUIC 

Hi,

Thanks,
Lars and Lucas

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 23 Nov 2020 08:22:40 -0600

Hannu,

On Mon, Nov 23, 2020 at 3:02 AM Flinck, Hannu (Nokia - FI/Espoo) <
[email-masked]> wrote:

> Each of them addressing different use cases. It is not obvious to me that
> the experimentation would lead into single design rather than debate
> between the approaches.
> I would expect as the outcome of the experimentations  deeper differences
> between the multipath mechanisms tailored for respective use cases. How can
> we draw any generic conclusions from such results? How would you compare
> the outcomes?
>

I agree with you on your question.

I'm working to catalog the various strategies we've talked about in QUIC,
in
https://tools.ietf.org/html/draft-dawkins-quic-what-to-do-with-multipath-02#section-2.3
.

Speaking only for myself, I don't anticipate one approach satisfying all of
the use cases, which I'm thinking of in two categories:

   - The sender needs to control what to send next, and on what path, based
   on more knowledge of the paths and the application than a general-purpose
   transport scheduler can know, or
   - The sender is willing to delegate those decisions to a general-purpose
   transport scheduler, because that will be "good enough".

Of course, I could be wrong about that.

I look forward to hearing more about the experiments as we proceed.

Best,

Spencer

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 23 Nov 2020 09:37:20 -0600

On Mon, Nov 23, 2020 at 8:23 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Speaking only for myself, I don't anticipate one approach satisfying all
> of the use cases, which I'm thinking of in two categories:
>
>    - The sender needs to control what to send next, and on what path,
>    based on more knowledge of the paths and the application than a
>    general-purpose transport scheduler can know, or
>    - The sender is willing to delegate those decisions to a
>    general-purpose transport scheduler, because that will be "good enough".
>

My suggestion is (as suggested by someone already, maybe Jana, I think): go
for a BOF.
I think mpquic community is large enough, prepared enough, good enough to
handle a very successful BOF in IETF 110 which is the next one. Can quickly
form a WG and develop a beautiful mpquic or whatever we want to call it.

Behcet

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Nov 2020 15:52:17 +0000

Hey Hannu, Spencer,

> I look forward to hearing more about the experiments as we proceed.

Speaking as an individual, I think experimental work towards proving or
disproving whether a single multipath QUIC design, within the set
constraints, can solve several multipath use cases is valuable.

Cheers
Lucas

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 23 Nov 2020 11:59:36 -0600

Hi, Lucas,

On Mon, Nov 23, 2020 at 9:52 AM Lucas Pardue <[email-masked]>
wrote:

>>> Each of them addressing different use cases. It is not obvious to me
>>> that the experimentation would lead into single design rather than debate
>>> between the approaches.
>>> I would expect as the outcome of the experimentations  deeper
>>> differences between the multipath mechanisms tailored for respective use
>>> cases. How can we draw any generic conclusions from such results? How would
>>> you compare the outcomes?
>>>
>>

I agree - sorry if I was unclear. My suspicion, to be confirmed or
overturned, is that "several multipath use cases" may not mean "all of the
proposed multipath use cases".

Using my two categories above, I'll be looking especially closely to see if
a single multipath QUIC design can address use cases in both categories.

We'll see, of course.

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Nov 2020 18:28:10 +0000

Hey Spencer,

On Mon, Nov 23, 2020 at 6:00 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Using my two categories above, I'll be looking especially closely to see
> if a single multipath QUIC design can address use cases in both categories.
>

Thanks for the clarification. As an individual, I think you and I are in
general agreement, turning "unknown unknowns" into "known tradeoffs and
demarkations " seems a nice next step to keep the conversation moving.

Cheers
Lucas

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 24 Nov 2020 09:52:32 -0600

Hi Lucas,

I think your offer is a good step forward. Thanks.

But I am unable to understand why you want to restrict the intended status
to Experimental?

BTW I checked all 3 multipath drafts and all of them ask for standards
track status.

What is wrong with multipath that warrants downgrading its status?

Behcet

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 24 Nov 2020 20:43:55 -0800

Behcet,

Lucas isn't talking about the status of the drafts, he's suggesting that
folks experiment with the proposals before we discuss their adoption. I
support this.
The question of which track will only apply when the wg is considering a
draft for adoption, and it can be modified after adoption too. There will
be a time for this bikeshed too, just not yet.

- jana

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Nov 2020 09:50:16 -0600

Hi Jana,

> folks experiment with the proposals before we discuss their adoption. I

That's not how I understood Lucas mail. But I take you word for it even
though not from the chairs :)

> be a time for this bikeshed too, just not yet.
Yes, that is how it should be.
So we are open, standards track is a possibility.

Let me also say that there is good support for mpquic, Apple, Alibaba,
Tencent, all those support it, implement it and use it.
3GPP CT4 is ready to standardize it once we have an RFC.

So what's not to like?

Behcet

>> But I am unable to understand why you want to restrict the intended
>> status to Experimental?
>>
>>>> Using my two categories above, I'll be looking especially closely to
>>>> see if a single multipath QUIC design can address use cases in both
>>>> categories.
>>>>
>>>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 25 Nov 2020 16:11:55 +0000

Hey,

See responses inline:

> though not from the chairs :)

The original chair's statement from Lars said "The QUIC WG remains the
default venue for continued open discussion of multipath experiments and
results.". The subset of the QUIC WG that are interested in multipath QUIC
are free to experiment with one or more of the I-Ds that are floating
around.  Lars also states that adoption of _any_ multipath document is
contingent on the three listed criteria.

>From the interim meeting, I did not take away the impression that multipath
QUIC had been implemented and used by all of these parties. We heard from
Alibaba folks and, as per Lars' instructions, are open to hearing the
results from others if there is any.

Cheers
Lucas