Subject: Fwd: New Version Notification for draft-dawkins-quic-multipath-questions-00.txt

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 6 Dec 2020 23:26:23 -0600

Dear QUIC working group,

We've exchanged a lot of e-mail about what support for multiple paths in
QUIC might look like on the mailing list, and talked about this at the
October virtual interim meeting and at the QUIC session at IETF 109, and it
seemed good to me, to try to summarize the discussions we've had so far.

Because this topic is of interest outside the IETF, I thought it better to
put the summary in an Internet Draft, than somewhere in Github issues or
Slack, or on the mailing list.

I also want to apologize in advance if I've misstated things - if so,
please let me know. I'd point out this text in the draft:

   Please note well that this document reflects the author's current
   understanding of working group discussions.  It is likely that there
   are more questions than currently included in the document, and it is
   even more likely that some of the suggested answers are incomplete or
   (unlike the people in Section 1.1) completely wrong.  Contributions
   that add or improve questions and answers are welcomed, as described
   in Section 1.4.

As always, Do The Right Thing.

Best,

Spencer

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, Dec 6, 2020 at 11:18 PM
Subject: New Version Notification for
draft-dawkins-quic-multipath-questions-00.txt
To: Spencer Dawkins <[email-masked]>

A new version of I-D, draft-dawkins-quic-multipath-questions-00.txt
has been successfully submitted by Spencer Dawkins and posted to the
IETF repository.

Name:           draft-dawkins-quic-multipath-questions
Revision:       00
Title:          Questions for Multiple Paths In QUIC
Document date:  2020-12-06
Group:          Individual Submission
Pages:          13
URL:
https://www.ietf.org/archive/id/draft-dawkins-quic-multipath-questions-00.txt
Status:
https://datatracker.ietf.org/doc/draft-dawkins-quic-multipath-questions/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dawkins-quic-multipath-questions
Htmlized:
https://tools.ietf.org/html/draft-dawkins-quic-multipath-questions-00

Abstract:
   The IETF QUIC working group has been chartered to produce extensions
   that would "enable ... multipath capabilities" since the working
   group was formed in 2016, but because multipath was an extension,
   work on multipath, and the other extensions named in the charter,
   waited while work proceeded on the core QUIC protocol specifications.

   After the QUIC working group chairs requested publication for the
   core QUIC protocol specifications, they scheduled a virtual interim
   meeting to understand the use cases that various groups inside and
   outside the IETF were envisioning for multipath with QUIC.

   As part of that discussion, it became obvious that people had a
   variety of ideas about how multiple paths would be used, because they
   weren't looking at the same use cases, and so had different
   assumptions about how applications might use QUIC over multiple
   paths.

   This document is intended to capture questions that have come up in
   discussions, with some suggested answers, to inform further
   discussion in the working group.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 7 Dec 2020 00:09:26 -0800

Thanks for working on this.

I’m still looking for a discussion on symmetric vs assymmetric multipath.

Today in QUIC v1 only the client can migrate.
Is multipath going to be the same, or can both endpoints initiate multiple
paths?

Kind Regards,
Mikkel Fahnøe Jørgensen

On 7 December 2020 at 06.27.12, Spencer Dawkins at IETF (
[email-masked]) wrote:

Dear QUIC working group,

Best,

Spencer

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, Dec 6, 2020 at 11:18 PM
Subject: New Version Notification for

Abstract:

The IETF Secretariat

---

From: Lars Eggert <[email-masked]>
Date: Mon, 7 Dec 2020 10:40:58 +0200

Hi,

> Today in QUIC v1 only the client can migrate.

that's not fully accurate. The server can try to migrate exactly one, early during the handshake, by sending the client a preferred_address transport parameter. This capability is very limited, in that it can only happen once and the client might not actually migrate, but it's not nothing.

Lars

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 7 Dec 2020 09:05:57 -0600

Mikkel and Lars,

On Mon, Dec 7, 2020 at 2:41 AM Lars Eggert <[email-masked]> wrote:

> that's not fully accurate. The server can try to migrate exactly one,
> early during the handshake, by sending the client a preferred_address
> transport parameter. This capability is very limited, in that it can only
> happen once and the client might not actually migrate, but it's not nothing.
>
> Lars
>

This is exactly the kind of discussion I'm hoping for! Thank you both.

We really need to push down a level, or two, about current QUIC
capabilities to make progress, in addition to the excellent suggestions to
experiment and report back.

The draft is in github, so I'll add an issue for this, and start thinking
about words.

Best,

Spencer

---

From: Mike Bishop <[email-masked]>
Date: Mon, 7 Dec 2020 15:46:57 +0000

The additional wrinkle is that depending on network infrastructure, successful migration might require one party to speak first before the other is able to migrate.  That’s the point of SPA’s current design – in typical client deployments, the client must be the one to initiate contact even though it’s the server changing address.  In other layouts (including one that Nick has talked about), the server might also be behind a NAT and need to speak first to enable the client to reach it or even to discover its own address.

From: QUIC <[email-masked]> On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Monday, December 7, 2020 3:09 AM
To: Spencer Dawkins at IETF <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Fwd: New Version Notification for draft-dawkins-quic-multipath-questions-00.txt

Is multipath going to be the same, or can both endpoints initiate multiple paths?

Kind Regards,

Mikkel Fahnøe Jørgensen

On 7 December 2020 at 06.27.12, Spencer Dawkins at IETF ([email-masked] <mailto:[email-masked]> ) wrote:

Dear QUIC working group, 

We've exchanged a lot of e-mail about what support for multiple paths in QUIC might look like on the mailing list, and talked about this at the October virtual interim meeting and at the QUIC session at IETF 109, and it seemed good to me, to try to summarize the discussions we've had so far. 

Because this topic is of interest outside the IETF, I thought it better to put the summary in an Internet Draft, than somewhere in Github issues or Slack, or on the mailing list. 

I also want to apologize in advance if I've misstated things - if so, please let me know. I'd point out this text in the draft:

Best,

Spencer

---------- Forwarded message ---------
From: <[email-masked] <mailto:[email-masked]> >
Date: Sun, Dec 6, 2020 at 11:18 PM
Subject: New Version Notification for draft-dawkins-quic-multipath-questions-00.txt
To: Spencer Dawkins <[email-masked] <mailto:[email-masked]> >

Name:           draft-dawkins-quic-multipath-questions
Revision:       00
Title:          Questions for Multiple Paths In QUIC
Document date:  2020-12-06
Group:          Individual Submission
Pages:          13
URL:            https://www.ietf.org/archive/id/draft-dawkins-quic-multipath-questions-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dawkins-quic-multipath-questions/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dawkins-quic-multipath-questions
Htmlized:       https://tools.ietf.org/html/draft-dawkins-quic-multipath-questions-00

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> .

The IETF Secretariat

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Dec 2020 10:44:06 -0600

> Is multipath going to be the same, or can both endpoints initiate multiple
I think symmetric vs asymmetric makes some difference. For example in
ATSSS, maybe we can assume UPF does not move. Maybe we can even assume UE
also does not move because then it would be difficult to access the fixed
network path.

Even in symmetric scenarios, I don't see much value of migration because in
case of migration, it will no longer be multipath, i.e. UE can no longer
access WiFi.

Behcet
Behcet

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 7 Dec 2020 09:18:07 -0800

It is not only a question of moving.

Server to server communication can happen via multiple networks though
public and privatel IPs.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 7 December 2020 at 17.44.18, Behcet Sarikaya ([email-masked])
wrote:

Behcet
Behcet