Subject: Uploaded "Why Multipath QUIC?" for 2020-10 Interim

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 19 Oct 2020 16:15:25 -0500

Dear Chairs,

I uploaded https://github.com/quicwg/wg-materials/pull/160 for Florin.

Please let us know if you have any questions or comments.

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 19 Oct 2020 22:21:29 +0100

Hi Spencer,

Thank you!

Perhaps because it's late in the day here but I don't understand the
mention of in-order delivery requirements wrt ATSSS-LL. Can you elaborate?
*Is that* a requirement of multipath?

Cheers
Lucas

---

From: Florin Baboescu <[email-masked]>
Date: Mon, 19 Oct 2020 14:25:45 -0700

Hi Lucas,

Based on how the ATSSS-LL sender is implemented, in-order delivery of the
packets may not be guaranteed at the receiver side once multiple paths are
used.

-Florin

*From:* Lucas Pardue [mailto:[email-masked]]
*Sent:* Monday, October 19, 2020 2:21 PM
*To:* Spencer Dawkins at IETF <[email-masked]>
*Cc:* WG Chairs <[email-masked]>; IETF QUIC WG <[email-masked]>;
Florin Baboescu <[email-masked]>; Flinck, Hannu (Nokia -
FI/Espoo) <[email-masked]>
*Subject:* Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim

Hi Spencer,

Thank you!

Cheers

Lucas

Dear Chairs,

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 19 Oct 2020 22:31:25 +0100

> packets may not be guaranteed at the receiver side once multiple paths are

What packets are you talking about here? Why does in-order delivery matter?
TCP and QUIC are designed to accommodate reordering. But QUIC specifically
offers no ordering guarantees across different streams.

Cheers
Lucas

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 19 Oct 2020 16:47:59 -0500

Hi, Lucas,

On Mon, Oct 19, 2020 at 4:31 PM Lucas Pardue <[email-masked]>
wrote:

> What packets are you talking about here? Why does in-order delivery
> matter? TCP and QUIC are designed to accommodate reordering. But QUIC
> specifically offers no ordering guarantees across different streams.
>

This is in Mirja's slides (not uploaded yet), but Release 16/Phase 1
ATSSS uses MPTCP to provide multipath support for TCP traffic, and a
different protocol called ATSSS-LL at a lower level of the protocol stack.

We talked about this in
https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00#section-5.3,
which says

   Techniques to provide ATSSS are classified by the 3GPP into two
   flavors: (1) higher-layer techniques which operate above the IP layer
   (e.g., MPTCP), and (2) lower-layer techniques which operate below the
   IP layer.

Most of the Release 17/ Phase 2 conversations I've been involved with have
centered on QUIC-based techniques, analogous to MPTCP, with ATSSS-LL just
carried over from Release 16/Phase 1.

Does that help?

Best,

Spencer

---

From: Florin Baboescu <[email-masked]>
Date: Mon, 19 Oct 2020 14:56:19 -0700

Hi Lucas,

Maybe you may want to rephrase your question as I do not think that we
discuss the use of MPQUIC as a transport for either QUIC or TCP.

The slides that we provided discuss the need of using MP-QUIC as a multi
path transport for both IP and Ethernet traffic. In the context of the 3GPP
ATSSS work the use of multiple accesses is done in the context of a Multi
Access (MA) PDU session. This session may be either of IP type or Ethernet
type. An IP type session may cover all the IP traffic associated with a
specific IP address/prefix at the UE. A PDU session may have multiple QoS
flows. A QoS flow is formed by the set of packets matched by a specific
Traffic Filter template on which a specific QoS profile is applied.

In a 3GPP system it is assumed that all the packets of the same QoS flow
are delivered in order between UPF (a network node, which may be seen by
someone as a “entry point” in the 3GPP core system) and the terminal. This
is done through the GTP tunneling between the core network (represented by
UPF) and access network (represented by gNB) and between the access network
and the terminal (UE) via PDCP layer.

In the ATSSS solution, MPQUIC is proposed as a transport solution between
the UPF and the terminal UE operating over multiple paths that may be
established between the UE and UPF. A multipath QUIC connection is
associated with a QoS flow as described above. In this context the
multipath QUIC connection needs to be able to provide in order delivery of
the packets associated with the same QoS flow.

The slides that we provide are supposed to describe a couple of use cases
in which multipath access is needed. A description of the current ATSSS
architecture is provided from what I’ve seen in Mirja’s presentation.

I hope this clarifies.

-Florin

*From:* Lucas Pardue [mailto:[email-masked]]
*Sent:* Monday, October 19, 2020 2:31 PM
*To:* Florin Baboescu <[email-masked]>
*Cc:* Spencer Dawkins at IETF <[email-masked]>; WG Chairs <
[email-masked]>; IETF QUIC WG <[email-masked]>; Flinck, Hannu (Nokia -
FI/Espoo) <[email-masked]>
*Subject:* Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim

Hi Lucas,

Cheers

Lucas

---

From: Florin Baboescu <[email-masked]>
Date: Mon, 19 Oct 2020 15:08:30 -0700

Also, please note that a MPQUIC based solution for ATSSS may be
complemented with MPTCP for example. In other words for a MA PDU session
one may setup a QoS flow all the TCP traffic. This traffic may be
associated with a MPTCP component. The default QoS flow of the MA PDU
session (associated with match *) may use the MPQUIC tunnel.

-Florin

*From:* Florin Baboescu [mailto:[email-masked]]
*Sent:* Monday, October 19, 2020 2:56 PM
*To:* 'Lucas Pardue' <[email-masked]>
*Cc:* 'Spencer Dawkins at IETF' <[email-masked]>; 'WG
Chairs' <[email-masked]>; 'IETF QUIC WG' <[email-masked]>; 'Flinck,
Hannu (Nokia - FI/Espoo)' <[email-masked]>
*Subject:* RE: Uploaded "Why Multipath QUIC?" for 2020-10 Interim

Hi Lucas,

I hope this clarifies.

-Florin

*From:* Lucas Pardue [mailto:[email-masked]
<[email-masked]>]
*Sent:* Monday, October 19, 2020 2:31 PM
*To:* Florin Baboescu <[email-masked]>
*Cc:* Spencer Dawkins at IETF <[email-masked]>; WG Chairs <
[email-masked]>; IETF QUIC WG <[email-masked]>; Flinck, Hannu (Nokia -
FI/Espoo) <[email-masked]>
*Subject:* Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim

Hi Lucas,

Cheers

Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 19 Oct 2020 23:08:40 +0100

Hey Florin,

> architecture is provided from what I’ve seen in Mirja’s presentation.

Thanks for the elaboration. So to cut to the chase, what are your
requirements here. Is it the intention to map QoS flows to QUIC streams?
That would provide in-order delivery within the stream, and reliability. Or
do you have something else in mind?

Cheers
Lucas

-Florin
> [email-masked]>; IETF QUIC WG <[email-masked]>; Flinck, Hannu (Nokia
> - FI/Espoo) <[email-masked]>

---

From: Florin Baboescu <[email-masked]>
Date: Mon, 19 Oct 2020 17:41:12 -0700

Hi Lucas,

When you say “Is it the intention to map QoS flows to QUIC streams?” In
short I can say yes. If it is available.  I consider though this to be an
orthogonal discussion to the multipath one and I believe it to be dependent
onto the current progress with the QUIC tunneling draft.

-Florin

*Sent:* Monday, October 19, 2020 3:09 PM

Hey Florin,

Hi Lucas,

I hope this clarifies.

Cheers

Lucas

-Florin

Hi Lucas,

Cheers

Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 20 Oct 2020 01:51:00 +0100

Hi,

> onto the current progress with the QUIC tunneling draft.

It can't be orthogonal. We need to understand what your requirements  of
the QUIC transport are. QUIC presently defines two methods to carry data in
a connection streams and datagrams. How those map to multipath for your
needs is the question here.

There are many QUIC tunneling drafts. Can you be more specific?

Cheers
Lucas

---

From: Florin Baboescu <[email-masked]>
Date: Mon, 19 Oct 2020 18:07:23 -0700

Lucas,

There are currently three MPQUIC based proposals which are in discussion
with different variations in regard to what is transported and how it is
transported. This is why I’m not commiting to clearly indicating one mode
of transport or another.

>From my side we are happy in advancing the work in draft-piraux-quic-tunnel
and use it as base of our solution.

-Florin

*Sent:* Monday, October 19, 2020 5:51 PM

Hi,

Hi Lucas,

Cheers

Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 20 Oct 2020 02:26:18 +0100

Hey Florin,

On Tue, 20 Oct 2020, 02:07 Florin Baboescu, <[email-masked]>
wrote:

> From my side we are happy in advancing the work in
> draft-piraux-quic-tunnel and use it as base of our solution.
>
>
>
Nominating any draft as a solution is solutionizing. We've asked for clear
requirements and non-requirements of the QUIC transport. The slides that
Spencer submitted have use cases but no clear requirements.

The reason this is important is because the IETF MASQUE WG is already
working on tunneling with QUIC.

We need to unpick the layers of overlap to understand what work the QUIC WG
is being asked to consider taking on.

Cheers
Lucas

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 20 Oct 2020 13:13:48 +0000

Hi Lucas, hi all,

I think the question on how to realize the tunnelling/proxying itself (with is mostly in cope for masque) and if a use case would benefit from support for handling of simultaneous use of multiple path are two orthogonal questions (also in 3GPP). E.g. Ericsson proposed a solution for ATSSS in 3GPP that uses MASQUE but all solutions under discussion in 3GPP would benefit from/require MP-QUIC support.

I though we are at the step where we collect use cases in order to understand if there is a need and support for MP support in QUIC (rather than going into requirement for how multipath support would be realized). We could also talk more about requirement but I think that’s better for a later discussion and would maybe need more than 5 minutes.

Mirja

From: QUIC <[email-masked]> on behalf of Lucas Pardue <[email-masked]>
Date: Tuesday, 20. October 2020 at 03:26
To: Florin Baboescu <[email-masked]>
Cc: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>, IETF QUIC WG <[email-masked]>, Spencer Dawkins at IETF <[email-masked]>, WG Chairs <[email-masked]>
Subject: Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim

Hey Florin,
On Tue, 20 Oct 2020, 02:07 Florin Baboescu, <[email-masked]<mailto:[email-masked]>> wrote:
Lucas,

There are currently three MPQUIC based proposals which are in discussion with different variations in regard to what is transported and how it is transported. This is why I’m not commiting to clearly indicating one mode of transport or another.
From my side we are happy in advancing the work in draft-piraux-quic-tunnel and use it as base of our solution.

Nominating any draft as a solution is solutionizing. We've asked for clear requirements and non-requirements of the QUIC transport. The slides that Spencer submitted have use cases but no clear requirements.

The reason this is important is because the IETF MASQUE WG is already working on tunneling with QUIC.

We need to unpick the layers of overlap to understand what work the QUIC WG is being asked to consider taking on.

Cheers
Lucas

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Oct 2020 16:23:00 +0300

Hi,

On 2020-10-20, at 16:13, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> I though we are at the step where we collect use cases in order to understand if there is a need and support for MP support in QUIC

exactly. But in order to have a discussion on this, we need to hear from the proponents of those use cases what functionality they are missing in QUICv1.

> (rather than going into requirement for how multipath support would be realized).

But requirements are not about the "how" - that was exactly Lucas' point. Requirements are about "what". So statements along the lines of "my use case requires the ability to fail over a connection to a different path", etc. would be informative. Saying "my use case requires draft-deconinck" less so (for example).

> We could also talk more about requirement but I think that’s better for a later discussion and would maybe need more than 5 minutes.

I'd hope not? Because if there is a long shopping list of requirements for new QUIC functionality to support a particular use case, that'd look to some as a pretty convincing case that maybe QUIC isn't really a suitable starting technology.

Thanks,
Lars

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 20 Oct 2020 13:46:58 +0000

Hi Lars,

Spencer, Florin, and I are about to figure out how to handle the different slides we have now. Sorry for the hassle. There is parallel discussion in 3GPP so we are a bit last minute here.

In ATSSS one of the Ses stands for Splitting where the general idea is to be able to split traffic of one e2e flow over an 3GPP and a non-3GPP network path. There is a mode for traffic aggregation with would require simultaneous use of both paths. All proposed solutions in 3GPP are based in some way on the use of QUIC tunnels on each network path. If only QUICv1 without MP support would be available and two independent tunnels would be used, some reordering logic in the tunnel endpoints would be needed. This is currently not in scope for 3GPP. Therefore a QUICv1 solution without support for using multiple paths simultaneously would not support Splitting. Current view in 3GPP is that this is not sufficient and therefore solutions that reply on MP-QUIC to support reordering between multiple paths are preferred.

I guess the requirement for this are that QUIC can use two paths simultaneously and that data send within one stream but transmitted over two paths are delivered in order. Not sure what other requirements you would expect to see at this stage?

Mirja

On 20.10.20, 15:23, "Lars Eggert" <[email-masked]> wrote:

    Hi,

    Thanks,
    Lars

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 20 Oct 2020 08:52:34 -0500

Chiming in with Mirja,

On Tue, Oct 20, 2020 at 8:46 AM Mirja Kuehlewind <
[email-masked]> wrote:

> Hi Lars,
>
> Spencer, Florin, and I are about to figure out how to handle the different
> slides we have now. Sorry for the hassle. There is parallel discussion in
> 3GPP so we are a bit last minute here.
>
> In ATSSS one of the Ses stands for Splitting where the general idea is to
> be able to split traffic of one e2e flow over an 3GPP and a non-3GPP
> network path. There is a mode for traffic aggregation with would require
> simultaneous use of both paths. All proposed solutions in 3GPP are based in
> some way on the use of QUIC tunnels on each network path. If only QUICv1
> without MP support would be available and two independent tunnels would be
> used, some reordering logic in the tunnel endpoints would be needed. This
> is currently not in scope for 3GPP. Therefore a QUICv1 solution without
> support for using multiple paths simultaneously would not support
> Splitting. Current view in 3GPP is that this is not sufficient and
> therefore solutions that reply on MP-QUIC to support reordering between
> multiple paths are preferred.
>
> I guess the requirement for this are that QUIC can use two paths
> simultaneously and that data send within one stream but transmitted over
> two paths are delivered in order. Not sure what other requirements you
> would expect to see at this stage?
>

That's certainly the point of my slides on steering modes, and that's more
obvious because of the edits I made after feedback from the chairs.

At 20km view, two of the four Phase 1 steering modes *could* be handled
using QUICv1 with migration, but the third needs simultaneous paths in some
cases, and the fourth needs it in all cases.

All four of the additional Phase 2 steering modes need simultaneous paths.

So, there are probably details, but that's the requirement from my
perspective.

Best,

Spencer

>     > I though we are at the step where we collect use cases in order to
> understand if there is a need and support for MP support in QUIC
>
>     exactly. But in order to have a discussion on this, we need to hear
> from the proponents of those use cases what functionality they are missing
> in QUICv1.
>
>     But requirements are not about the "how" - that was exactly Lucas'
> point. Requirements are about "what". So statements along the lines of "my
> use case requires the ability to fail over a connection to a different
> path", etc. would be informative. Saying "my use case requires
> draft-deconinck" less so (for example).
>
>     > We could also talk more about requirement but I think that’s better
> for a later discussion and would maybe need more than 5 minutes.
>
>     I'd hope not? Because if there is a long shopping list of requirements
> for new QUIC functionality to support a particular use case, that'd look to
> some as a pretty convincing case that maybe QUIC isn't really a suitable
> starting technology.
>
>     Thanks,
>     Lars
>
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Oct 2020 16:53:25 +0300

Hi,

On 2020-10-20, at 16:46, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> 
> I guess the requirement for this are that QUIC can use two paths simultaneously and that data send within one stream but transmitted over two paths are delivered in order.

I think this is exactly at the level of detail that is useful at this stage, and nicely identifies what QUICv1 can and cannot do.

> Not sure what other requirements you would expect to see at this stage?

I don't expect anything :-) It's up the proponents of the different use cases to state their requirements in this  way. If ATSSS required nothing else than what you stated above, you'd be done.

Thanks,
Lars

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 20 Oct 2020 13:56:06 +0000

Okay, great. We can make this more explicit in the slides!

On 20.10.20, 15:53, "Lars Eggert" <[email-masked]> wrote:

    Hi,

    Thanks,
    Lars

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 20 Oct 2020 15:28:39 +0100

On Tue, Oct 20, 2020 at 2:53 PM Lars Eggert <[email-masked]> wrote:

> two paths are delivered in order.
>
> I think this is exactly at the level of detail that is useful at this
> stage, and nicely identifies what QUICv1 can and cannot do.
>

+1. That requirement is clear and makes it obvious you are not asking for
strict ordering of QUIC packets or DATAGRAM frames that are sent across
different paths belonging to the same connection.

Cheers
Lucas

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 20 Oct 2020 09:35:36 -0500

So, just to let everyone know, we are working on a merged slide deck.
Expect a new PR Real Soon Now.

Best,

Spencer

---

From: Roberto Peon <[email-masked]>
Date: Tue, 20 Oct 2020 16:18:02 +0000

I believe that the mailserver is swallowing my emails to the mailing list, and has since April, so we’ll see if this makes it anywhere.

I’d love to have conversations about why we’d be doing multipath in the transport, as opposed to at some higher layer.
There are some good reasons, but listing them out (and determining which are requirements vs just where it has been done in the past) would be good.

-=R

From: QUIC <[email-masked]> on behalf of Spencer Dawkins at IETF <[email-masked]>
Date: Tuesday, October 20, 2020 at 6:54 AM
To: Mirja Kuehlewind <[email-masked]>
Cc: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>, Florin Baboescu <[email-masked]>, WG Chairs <[email-masked]>, Lucas Pardue <[email-masked]>, Lars Eggert <[email-masked]>, IETF QUIC WG <[email-masked]>
Subject: Re: Uploaded "Why Multipath QUIC?" for 2020-10 Interim

Chiming in with Mirja,

On Tue, Oct 20, 2020 at 8:46 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lars,

That's certainly the point of my slides on steering modes, and that's more obvious because of the edits I made after feedback from the chairs.

At 20km view, two of the four Phase 1 steering modes *could* be handled using QUICv1 with migration, but the third needs simultaneous paths in some cases, and the fourth needs it in all cases.

So, there are probably details, but that's the requirement from my perspective.

Best,

Spencer

Mirja

On 20.10.20, 15:23, "Lars Eggert" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi,

    Thanks,
    Lars

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 20 Oct 2020 11:50:35 -0500

Roberto,

On Tue, Oct 20, 2020 at 11:18 AM Roberto Peon <[email-masked]> wrote:

> I believe that the mailserver is swallowing my emails to the mailing list,
> and has since April, so we’ll see if this makes it anywhere.
>

Your email made it to me :-)

> I’d love to have conversations about why we’d be doing multipath in the
> transport, as opposed to at some higher layer.
> There are some good reasons, but listing them out (and determining which
> are requirements vs just where it has been done in the past) would be good.
>

I think that's a good conversation to have. Maybe we can start it during
the discussion period at the interim meeting?

(I almost typed "maybe we can start it on the mailing list", but that seems
extremely passive-aggressive!)

Best,

Spencer