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

[Mike Bishop <[e-mail]>]

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

 

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 ([e-mail] <mailto:[e-mail]> ) 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:

 

   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: <[e-mail] <mailto:[e-mail]> >
Date: Sun, Dec 6, 2020 at 11:18 PM
Subject: New Version Notification for draft-dawkins-quic-multipath-questions-00.txt
To: Spencer Dawkins <[e-mail] <mailto:[e-mail]> >




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 <http://tools.ietf.org> .

The IETF Secretariat