Subject: Fwd: New Version Notification for draft-dawkins-quic-what-to-do-with-multipath-03.txt

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 6 Jan 2021 21:26:23 -0600

Dear QUIC WG,

I'ave gotten some feedback on this draft from several people, including
several presenters at the QUIC multipath virtual interim last October.

See the diffs for details.

Just to be clear on something that's probably confusing - I'm trying to
capture what people are trying to do with multipath, based largely, but not
completely, on the presentations available at
https://datatracker.ietf.org/meeting/interim-2020-quic-02/session/quic. So
I'm trying to capture the state of play as we started having a serious
discussion about multipath.

I'm also working on a draft that tries to identify the questions we've had
come up in working group discussions. I'll probably submit an update on
that draft tomorrow or Friday.

I hope these are helpful as we move things along.

Best,

Spencer

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, Jan 6, 2021 at 9:18 PM
Subject: New Version Notification for
draft-dawkins-quic-what-to-do-with-multipath-03.txt
To: Spencer Dawkins <[email-masked]>

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

Name:           draft-dawkins-quic-what-to-do-with-multipath
Revision:       03
Title:          What To Do With Multiple Active Paths in QUIC
Document date:  2021-01-06
Group:          Individual Submission
Pages:          14
URL:
https://www.ietf.org/archive/id/draft-dawkins-quic-what-to-do-with-multipath-03.txt
Status:
https://datatracker.ietf.org/doc/draft-dawkins-quic-what-to-do-with-multipath/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dawkins-quic-what-to-do-with-multipath
Htmlized:
https://tools.ietf.org/html/draft-dawkins-quic-what-to-do-with-multipath-03
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dawkins-quic-what-to-do-with-multipath-03

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.

   This document is intended to capture that variety of ideas, 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: Thu, 7 Jan 2021 18:17:03 +0100

Great work.

From a quick read, I believe you have captured many relevant use cases but perhaps the document does not capture the concerns related til NAT translation and firewalls.

There is a diagram showing multiple paths between two QUIC hosts A and B, and I think that is great because traffic between two data center hosts is a great use case IMO. But here hosts can mean anything, also a mobile client or a user at home or at work behind a NAT router.
The use cases and trade-offs differ significantly in these separate configurations, and the problems are also different in that it can be hard to maintain or initiate a path in reverse direction of a NAT.

Apologies if you already made that clear in a section that I missed.

> On 7 Jan 2021, at 04.26, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Dear QUIC WG, 
> 
> I'ave gotten some feedback on this draft from several people, including several presenters at the QUIC multipath virtual interim last October. 
> 
> Just to be clear on something that's probably confusing - I'm trying to capture what people are trying to do with multipath, based largely, but not completely, on the presentations available at https://datatracker.ietf.org/meeting/interim-2020-quic-02/session/quic <https://datatracker.ietf.org/meeting/interim-2020-quic-02/session/quic>. So I'm trying to capture the state of play as we started having a serious discussion about multipath. 
> 
> I'm also working on a draft that tries to identify the questions we've had come up in working group discussions. I'll probably submit an update on that draft tomorrow or Friday. 
> 
> From: <[email-masked] <mailto:[email-masked]>>
> Subject: New Version Notification for draft-dawkins-quic-what-to-do-with-multipath-03.txt
> To: Spencer Dawkins <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            https://www.ietf.org/archive/id/draft-dawkins-quic-what-to-do-with-multipath-03.txt <https://www.ietf.org/archive/id/draft-dawkins-quic-what-to-do-with-multipath-03.txt>
> Status:         https://datatracker.ietf.org/doc/draft-dawkins-quic-what-to-do-with-multipath/ <https://datatracker.ietf.org/doc/draft-dawkins-quic-what-to-do-with-multipath/>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dawkins-quic-what-to-do-with-multipath <https://datatracker.ietf.org/doc/html/draft-dawkins-quic-what-to-do-with-multipath>
> Htmlized:       https://tools.ietf.org/html/draft-dawkins-quic-what-to-do-with-multipath-03 <https://tools.ietf.org/html/draft-dawkins-quic-what-to-do-with-multipath-03>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-dawkins-quic-what-to-do-with-multipath-03 <https://www.ietf.org/rfcdiff?url2=draft-dawkins-quic-what-to-do-with-multipath-03>
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 7 Jan 2021 23:46:09 -0800

Mikkel Fahnøe Jørgensen wrote on 2021-01-07 09:17:
> ...
> 
> From a quick read, I believe you have captured many relevant use cases
> but perhaps the document does not capture the concerns related til NAT
> translation and firewalls.
> 
> ...

i'm not sure enterprise concerns such as NAT or firewalls are important
to this audience. QUIC is policy-immune by design, and those of us who
operate secure private networks (schools, enterprise, military, police,
and many homes) are expecting to simply deny UDP and force the use of an
outbound proxy.

i'd love to be wrong, but section 3 of
https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html seems
clear as to the intended entropy level and that this level really is
intentional. unfortunately for me as a security private network
operator, my needs in this regard are the same as russia's.

see also:

https://slate.com/technology/2020/09/russia-internet-encryption-protocol-ban.html

vixie

-- 
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 8 Jan 2021 15:26:55 -0600

Hi, Paul and Mikkel,

> operator, my needs in this regard are the same as russia's.

My goal in this draft was to focus on strategies for path selection when
you have two or more validated paths available.

I think that in order to have those paths validated, you already have to
have navigated the potentially twisty maze of NATs and firewall policies.

I recognize that actually getting multiple QUIC paths validated across NATs
and firewalls is important to actual deployments, but I think it's
orthogonal to path selection in a scheduler with multiple paths already
available.

Does that make sense?

And thanks for taking a look at this draft. I know there's a lot of mailing
list traffic with all the ballot e-mail going back and forth!

Best,

Spencer