Subject: [quicwg/base-drafts] Clarify path validation and connection migration (#4102)

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 19:35:58 -0700

I tried to be conservative about changes, but there were a few paragraphs I thought should be moved.  Otherwise, the changes are minimal.

Fixes #3932
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4102

-- Commit Summary --

  * Clarify path validation and connection migration

-- File Changes --

    M draft-ietf-quic-transport.md (62)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4102.patch
https://github.com/quicwg/base-drafts/pull/4102.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 19:41:16 -0700

@ianswett pushed 1 commit.

7dc91a1b8a5810c1a6f1f51cdba95a1d3a9d347c  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/c7633d4a5155510283f2f451af316db34c04591d..7dc91a1b8a5810c1a6f1f51cdba95a1d3a9d347c

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 19:48:16 -0700

d0d6a074be1e80718d2eea06891cf686dfcd43ea  Remove some redundant text

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/7dc91a1b8a5810c1a6f1f51cdba95a1d3a9d347c..d0d6a074be1e80718d2eea06891cf686dfcd43ea

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 19:51:58 -0700

74b4347add097154792f6c2fcf283fedd9e53751  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/d0d6a074be1e80718d2eea06891cf686dfcd43ea..74b4347add097154792f6c2fcf283fedd9e53751

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 19:55:22 -0700

2dc030281ed17de85c964d59a87501a5d84b86fd  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/74b4347add097154792f6c2fcf283fedd9e53751..2dc030281ed17de85c964d59a87501a5d84b86fd

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 20:12:23 -0700

e4b8d3ea3e48d9c8e7ea0ed91f16df7dc310df15  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/2dc030281ed17de85c964d59a87501a5d84b86fd..e4b8d3ea3e48d9c8e7ea0ed91f16df7dc310df15

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 20:13:58 -0700

@ianswett commented on this pull request.

> @@ -2152,11 +2152,10 @@ receive packets without first having sent a packet on that path. Effective NAT
 traversal needs additional synchronization mechanisms that are not provided
 here.
 
-An endpoint MAY include PATH_CHALLENGE and PATH_RESPONSE frames that are used
-for path validation with other frames.  In particular, an endpoint can pad a
-packet carrying a PATH_CHALLENGE for Path Maximum Transfer Unit (PMTU)
-discovery (see {{pmtud}}), or an endpoint can include a PATH_RESPONSE with its
-own PATH_CHALLENGE.
+An endpoint MAY include other frames with the PATH_CHALLENGE and PATH_RESPONSE
+frames used for path validation.  In particular, an endpoint can include
+PADDING with a PATH_CHALLENGE for Path Maximum Transfer Unit (PMTU) discovery
+(see {{pmtud}}), and/or include a PATH_RESPONSE with its own PATH_CHALLENGE.
 
 When probing a new path, an endpoint might want to ensure that its peer has an

This paragraph is very duplicative of a paragraph in "Probing a new path" under connection migration, so I think we should drop one of them, but I'm not clear on which.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-489243255

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 20:20:53 -0700

e41f0f9705b8970bee9627aa40148c2e84604d06  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/e4b8d3ea3e48d9c8e7ea0ed91f16df7dc310df15..e41f0f9705b8970bee9627aa40148c2e84604d06

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 20:24:54 -0700

d60deed7cfb55a8efda4ff4c8e624a2816e07a8c  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/e41f0f9705b8970bee9627aa40148c2e84604d06..d60deed7cfb55a8efda4ff4c8e624a2816e07a8c

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 20:27:21 -0700

b5819c8b9896d15f54bde7f6e510b41233d3816d  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/d60deed7cfb55a8efda4ff4c8e624a2816e07a8c..b5819c8b9896d15f54bde7f6e510b41233d3816d

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2020 20:53:24 -0700

@martinthomson commented on this pull request.

Is there a specific problem that you think these changes help with?  I can't see anything particular, though the removal of duplication and reordering is good.

I've identified one lost piece that I would prefer to keep.  And one that I don't think we need, based on your note.

Thanks for working through this.  This was less disruptive than I feared.

> -path.  Acknowledgments cannot be used for path validation as they contain
-insufficient entropy and might be spoofed.  No method is provided to establish
-return reachability, as endpoints independently determine reachability on each
-direction of a path.

I think that the two latter sentences are still worth keeping.  However, I would be happier if it were moved higher though.

 

The latter can probably go.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-489252053

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2020 20:55:35 -0700

Something to look into...
```
draft-ietf-quic-transport.md:2315: Line contains HTAB
To establish reachability on the new path, an endpoint initiates path	
draft-ietf-quic-transport.md:2316: Line contains HTAB
validation ({{migrate-validate}}) on the new path.  An endpoint MAY defer path	
draft-ietf-quic-transport.md:2317: Line contains HTAB
validation until after a peer sends the next non-probing frame to its new	
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#issuecomment-693154149

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 20:59:01 -0700

da6ab2ceb429a684d66906d0841ef193f7f006f1  Remove a duplicative paragraph

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/b5819c8b9896d15f54bde7f6e510b41233d3816d..da6ab2ceb429a684d66906d0841ef193f7f006f1

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 20:59:21 -0700

Done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r489147023

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 21:03:52 -0700

519a0bbf0daa1486c0b543910f104411cb2f76ea  Move two sentences up

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/da6ab2ceb429a684d66906d0841ef193f7f006f1..519a0bbf0daa1486c0b543910f104411cb2f76ea

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 21:04:26 -0700

SG, moved to the third paragraph of "Path Validation {#migrate-validate}", PTAL

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r489148244

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 21:06:35 -0700

d9fbe09bf7bf8a1f4e30f44a337036bfcd93ed99  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/519a0bbf0daa1486c0b543910f104411cb2f76ea..d9fbe09bf7bf8a1f4e30f44a337036bfcd93ed99

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 21:11:07 -0700

@martinthomson I was previously finding the text confusing and potentially contradictory.

When I read it all at once, I believe I understand the intent, but hopefully this change makes each portion clearer and less dependent upon adjacent sections.

There's probably a bit more worth doing, but at some point I'm willing to call it good enough.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#issuecomment-693157972

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 21:12:49 -0700

b8a37edfad590982414acccd24cdace09d5d6f75  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/d9fbe09bf7bf8a1f4e30f44a337036bfcd93ed99..b8a37edfad590982414acccd24cdace09d5d6f75

---

From: ianswett <[email-masked]>
Date: Tue, 15 Sep 2020 21:19:05 -0700

850e7934bc9a921494d66587839f8e20088e4ef6  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/b8a37edfad590982414acccd24cdace09d5d6f75..850e7934bc9a921494d66587839f8e20088e4ef6

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2020 21:56:58 -0700

@martinthomson approved this pull request.

Thanks.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-489274451

---

From: ianswett <[email-masked]>
Date: Wed, 16 Sep 2020 04:29:25 -0700

2aa215be07922b5dca5b0abbc04d04db57f413fc  Clarify what limits the number of paths to probe

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/850e7934bc9a921494d66587839f8e20088e4ef6..2aa215be07922b5dca5b0abbc04d04db57f413fc

---

From: David Schinazi <[email-masked]>
Date: Wed, 16 Sep 2020 15:55:27 -0700

@DavidSchinazi commented on this pull request.

Overall I think this PR clarifies thing (and is purely editorial). I've added some minor comments inline.

> +entropy and might be spoofed. No method is provided to establish return
+reachability, as endpoints independently determine reachability on each
+direction of a path.

I found `No method is provided to establish return reachability` confusing. How about:

```suggestion
entropy and might be spoofed. Endpoints independently determine reachability
on each direction of a path, and therefore return reachability can only be
established by the peer.
```

> +peer. Path validation ensures that packets received from a migrating peer do
+not carry a spoofed source address.

I personally found `is used to ensure` clearer than `ensures`

```suggestion
peer. Path validation is used to ensure that packets received
from a migrating peer do not carry a spoofed source address.
```

> @@ -2152,35 +2155,40 @@ receive packets without first having sent a packet on that path. Effective NAT

This last bit sounded backwards to me in the original text. I think as a server I expect to commonly receive an unprompted PATH_CHALLENGE, and will therefore have to send PATH_RESPONSE. The performance optimization is to include a PATH_CHALLENGE with that PATH_RESPONSE, not the other way around.

```suggestion
(see {{pmtud}}), and/or include a PATH_CHALLENGE with its own PATH_RESPONSE.
```

 When probing a new path, an endpoint might want to ensure that its peer has an
 unused connection ID available for responses. The endpoint can send
 NEW_CONNECTION_ID and PATH_CHALLENGE frames in the same packet. This ensures
 that an unused connection ID will be available to the peer when sending a
 response.
 
+The number of new paths an endpoint can probe is limited by the number of
+extra Connection IDs the peer has previously supplied.

I would add the following clarification:

```suggestion
extra Connection IDs the peer has previously supplied. Supplying a peer with enough
Connection IDs allows it to simultaneously probe multiple paths.
```

>  In response to such a packet, an endpoint MUST start sending subsequent packets
 to the new peer address and MUST initiate path validation ({{migrate-validate}})
-to verify the peer's ownership of the unvalidated address.
+to verify the peer's ownership of the address if it has not already.

This sounds backwards to me. Don't we need to validate the path *before* sending all subsequent packets on it?

How about:

```
In response to such a packet, an endpoint MUST initiate path validation ({{migrate-validate}})
to verify the peer's ownership of the address if it has not already. Once the address is
validated, the endpoint MUST start sending subsequent packets to the new peer address.
```

(sorry the GitHub suggestion UI seems to have choked on this one)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-490069491

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 07:19:27 -0700

49efc7a8d57dc701747ece891e5958ccbb931cc5  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/2aa215be07922b5dca5b0abbc04d04db57f413fc..49efc7a8d57dc701747ece891e5958ccbb931cc5

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 07:20:22 -0700

> +Path validation tests that packets sent on a path to a peer are received by that
+peer. Path validation is used to ensure that packets received

```suggestion
Path validation tests that packets sent on a path to a peer are
received by that peer. Path validation is used to ensure that packets received
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-490646977

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 07:20:24 -0700

534da7481876b010b7d6edae6ab159e0bd9df75c  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/49efc7a8d57dc701747ece891e5958ccbb931cc5..534da7481876b010b7d6edae6ab159e0bd9df75c

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 10:16:45 -0700

710ccc11dffc5b4bfb3d288419d95a7a263dc59f  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/534da7481876b010b7d6edae6ab159e0bd9df75c..710ccc11dffc5b4bfb3d288419d95a7a263dc59f

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 10:17:25 -0700

b5b490cc30da16e353c7aa3b9099f35cfdeb28c7  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/710ccc11dffc5b4bfb3d288419d95a7a263dc59f..b5b490cc30da16e353c7aa3b9099f35cfdeb28c7

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 10:18:41 -0700

8eadab37bbc145099d31b96bfdce122b5f0646fa  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/b5b490cc30da16e353c7aa3b9099f35cfdeb28c7..8eadab37bbc145099d31b96bfdce122b5f0646fa

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 10:19:00 -0700

> +extra Connection IDs the peer has previously supplied. Supplying a peer with enough
+Connection IDs allows it to simultaneously probe multiple paths.

```suggestion
extra Connection IDs the peer has previously supplied. Supplying a peer with
multiple Connection IDs allows it to simultaneously probe multiple paths.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-490822303

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 10:19:02 -0700

92c1332b6dd250b2847a2793c51eb801f42d10a4  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/8eadab37bbc145099d31b96bfdce122b5f0646fa..92c1332b6dd250b2847a2793c51eb801f42d10a4

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 10:26:26 -0700

I think your suggestion is not quite right, see the next paragraph which talks about the limits on sending packets to unvalidated peer addresses.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r490433208

---

From: David Schinazi <[email-masked]>
Date: Thu, 17 Sep 2020 14:17:03 -0700

Thanks, I hadn't read that. I think the current text (with or without this PR) is therefore confusing. Saying that you MUST start sending then that you MAY send before validating is strange.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r490566996

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 14:22:39 -0700

Would it help to move the paragraph below up some?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r490569530

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 14:22:56 -0700

## Responding to Connection Migration {#migration-response}
 
 Receiving a packet from a new peer address containing a non-probing frame
 indicates that the peer has migrated to that address.
 
+An endpoint only changes the address that it sends packets to in response to the
+highest-numbered non-probing packet. This ensures that an endpoint does not send
+packets to an old peer address in the case that it receives reordered packets.
+
 In response to such a packet, an endpoint MUST start sending subsequent packets

```suggestion
In response to such a packet, an endpoint MUST send all subsequent packets
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-490998342

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 14:22:58 -0700

6c104923f2c8dae14bb521f2100537c4e92c9651  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/92c1332b6dd250b2847a2793c51eb801f42d10a4..6c104923f2c8dae14bb521f2100537c4e92c9651

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 14:23:41 -0700

I changed it to "send all" from "start sending" because I believe that is the intent.  Does that help?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r490569971

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Sep 2020 17:13:40 -0700

> @@ -2331,7 +2335,7 @@ An endpoint only changes the address that it sends packets to in response to the
 highest-numbered non-probing packet. This ensures that an endpoint does not send
 packets to an old peer address in the case that it receives reordered packets.
 
-In response to such a packet, an endpoint MUST start sending subsequent packets
+In response to such a packet, an endpoint MUST send all subsequent packets

```suggestion
In response to such a packet, an endpoint MUST send subsequent packets
```

"all" might require more commitment than we need here.  There might be another migration later.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-491068827

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 18:07:20 -0700

28bc0a21234c1d085e74f81e6db0fde12bf9bc6b  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/6c104923f2c8dae14bb521f2100537c4e92c9651..28bc0a21234c1d085e74f81e6db0fde12bf9bc6b

---

From: ianswett <[email-masked]>
Date: Thu, 17 Sep 2020 18:07:53 -0700

now just "send"

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r490643295

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Sep 2020 10:27:39 -0700

@MikeBishop approved this pull request.

Looks like an overall improvement.  We do seem to be losing some text, though I'm not sure if it's critical.

> -An endpoint uses a new connection ID for probes sent from a new local address;
-see {{migration-linkability}} for further discussion. An endpoint that uses
-a new local address needs to ensure that at least one new connection ID is
-available at the peer. That can be achieved by including a NEW_CONNECTION_ID
-frame in the probe.

I initially thought this text was essential to retain, but in fact, it stems from the assumption that the peer is required to reply on the new path (and therefore with a fresh CID).  That's not a bad thing for the peer to do and therefore including the NCID frame in a probe is also worth recommending, but it's not as critical as it used to be.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-491652495

---

From: ianswett <[email-masked]>
Date: Fri, 18 Sep 2020 10:58:52 -0700

Re-reading this, I think I should retain the first sentence.  I'm not sure if I need to retain the second two, given this is only about probing a new path?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r491106901

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Sep 2020 14:03:34 -0700

@MikeBishop commented on this pull request.

The first sentence is probably duplicative, but it leads into the second -- if the peer is to respond *on the same path*, they will need an extra CID, so bundling a NCID frame is a good idea.  (That's actually why NCID is allow in probing packets, IIRC.)  But on the other hand, the peer isn't required to respond on the same path any longer, so no harm done if omitted.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r491189434

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 21 Sep 2020 09:13:11 -0700

@ekinnear approved this pull request.

Looking good, only minor wording nits, thanks @ianswett!

> @@ -2152,35 +2155,41 @@ receive packets without first having sent a packet on that path. Effective NAT
 
+(see {{pmtud}}), and/or include a PATH_CHALLENGE with its own PATH_RESPONSE.

Wording nit: Do we use `and/or` anywhere else here?
```suggestion
(see {{pmtud}}); it can also include a PATH_CHALLENGE with its own PATH_RESPONSE.
```

> +The number of new paths an endpoint can probe is limited by the number of
+extra Connection IDs the peer has previously supplied. Supplying a peer with
+multiple Connection IDs allows it to simultaneously probe multiple paths.

It's important to note that multiple paths may be probed, but I don't think we want to imply that this is the only reason to supply a peer with multiple connection IDs. How about something similar to
```suggestion
An endpoint can choose to simultaneously probe multiple paths. The number
of simultaneous paths used for probes is limited by the number of extra 
Connection IDs its peer has previously supplied, since each new local address 
used for a probe requires a previously unused Connection ID.
```

It might still be worth suggesting including NCID somewhere, even if not in the same place as before, I think.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-491754336

---

From: ianswett <[email-masked]>
Date: Mon, 21 Sep 2020 17:44:11 -0700

482014592a4ef6b105b7dd7474ab7e80637cb2b5  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/28bc0a21234c1d085e74f81e6db0fde12bf9bc6b..482014592a4ef6b105b7dd7474ab7e80637cb2b5

---

From: ianswett <[email-masked]>
Date: Mon, 21 Sep 2020 17:44:54 -0700

f33028f2b010b5a1d8816f1fb79a7127ff4772db  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/482014592a4ef6b105b7dd7474ab7e80637cb2b5..f33028f2b010b5a1d8816f1fb79a7127ff4772db

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 06:49:51 -0700

01d5680762cc741387ef4151ac1aaba6c92277ed  Restore the paragraph and make a tweak

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/f33028f2b010b5a1d8816f1fb79a7127ff4772db..01d5680762cc741387ef4151ac1aaba6c92277ed

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 06:50:40 -0700

I restored this paragraph and made one tweak to clarify that the reason the peer needs a new CID is if you expect to receive packets on the new local address.  PTAL.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r492749709

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 06:57:49 -0700

026e0e31841b7d39df40658360cd358584d4a9f0  Found the mostly duplicative paragraph in "Path Validation"

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/01d5680762cc741387ef4151ac1aaba6c92277ed..026e0e31841b7d39df40658360cd358584d4a9f0

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 06:59:52 -0700

acb5e7a57021ae992d192a088f46bdf16a1d3ad0  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/026e0e31841b7d39df40658360cd358584d4a9f0..acb5e7a57021ae992d192a088f46bdf16a1d3ad0

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 14:00:59 +0000 (UTC)

And then I found the paragraph that I thought was duplicative up above in Path Validation, so I removed this paragraph and made some adjustments to the one above, most notably adding the first sentence of this paragraph.  PTAL(again)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r492758152

---

From: Marten Seemann <[email-masked]>
Date: Tue, 22 Sep 2020 14:19:18 +0000 (UTC)

@marten-seemann commented on this pull request.

> @@ -2288,15 +2298,11 @@ local address.  Failure of path validation simply means that the new path is not
 usable for this connection.  Failure to validate a path does not cause the
 connection to end unless there are no valid alternative paths available.
 
-An endpoint uses a new connection ID for probes sent from a new local address;
-see {{migration-linkability}} for further discussion. An endpoint that uses
-a new local address needs to ensure that at least one new connection ID is
-available at the peer. That can be achieved by including a NEW_CONNECTION_ID
-frame in the probe.
-
-Receiving a PATH_CHALLENGE frame from a peer indicates that the peer is probing
-for reachability on a path. An endpoint sends a PATH_RESPONSE frame in response,
-as per {{migrate-validate}}.
+An endpoint uses a new connection ID for probes sent from a new local address;	

I think this would be clearer if we say that the "endpoint" we're talking about here is a client.

> @@ -2314,33 +2320,31 @@ Therefore, a migrating endpoint can send to its peer knowing that the peer is
 willing to receive at the peer's current address. Thus an endpoint can migrate
 to a new local address without first validating the peer's address.
 
+To establish reachability on the new path, an endpoint initiates path
+validation ({{migrate-validate}}) on the new path.  An endpoint MAY defer path
+validation until after a peer sends the next non-probing frame to its new
+address.

Why? Wouldn't that mean that there's a 1-RTT delay when the client switches to the new path, as the server now has to first verify the path?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-493509300

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 08:46:10 -0700

This is the path validation section, not the connection migration section, FYI.  I think the intent is that path validation not be client or server specific?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r492843815

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 08:47:50 -0700

That's correct, it incurs a 1-RTT delay.  But it is a bit simpler to implement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r492845113

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 08:51:21 -0700

8e05bf5a6c2739fafc6c5302e7fb176d6a2844c7  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/acb5e7a57021ae992d192a088f46bdf16a1d3ad0..8e05bf5a6c2739fafc6c5302e7fb176d6a2844c7

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 08:52:50 -0700

This was moved from line 2324 FYI

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r492848698

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 22 Sep 2020 09:51:18 -0700

@ekinnear commented on this pull request.

Yeah, I'd really hope that people _not_ do that and immediately validate in response (since state usage is still governed by how many CIDs they handed out) so that a client can pre-warm the validation a few RTTs before we need to migrate. Perhaps we should call out that delay as a reason to avoid deferring unless the server is out of resources?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r492888148

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 22 Sep 2020 15:02:15 -0700

@janaiyengar commented on this pull request.

A few comments, but pretty close.

 Path validation does not validate that a peer can send in the return direction.
-The peer performs independent validation of the return path.
+Acknowledgments cannot be used for path validation as they contain insufficient

```suggestion
Acknowledgments cannot be used for return path validation as they contain insufficient
```

> @@ -2152,35 +2155,44 @@ receive packets without first having sent a packet on that path. Effective NAT

```suggestion
PADDING frames with a PATH_CHALLENGE frame for Path Maximum Transfer Unit (PMTU) discovery
```

> +(see {{pmtud}}); it can also include a PATH_CHALLENGE with its own
+PATH_RESPONSE.

```suggestion
(see {{pmtud}}); it can also include a PATH_CHALLENGE frame with its own
PATH_RESPONSE frame.
```

> +An endpoint uses a new connection ID for probes sent from a new local address
+(See {{migration-linkability}}).  So when probing a new path, an endpoint

```suggestion
An endpoint uses a new connection ID for probes sent from a new local address;
see {{migration-linkability}}.  When probing a new path, an endpoint
```

+An endpoint can choose to simultaneously probe multiple paths. The number
+of simultaneous paths used for probes is limited by the number of extra
+Connection IDs its peer has previously supplied, since each new local address

```suggestion
connection IDs its peer has previously supplied, since each new local address
```

+An endpoint can choose to simultaneously probe multiple paths. The number
+of simultaneous paths used for probes is limited by the number of extra
+Connection IDs its peer has previously supplied, since each new local address
+used for a probe requires a previously unused Connection ID.

```suggestion
used for a probe requires a previously unused connection ID.
```

 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
 containing an unpredictable payload on the path to be validated.
 
 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against packet
 loss. However, an endpoint SHOULD NOT send multiple PATH_CHALLENGE frames in a
-single packet.  An endpoint SHOULD NOT send a PATH_CHALLENGE more frequently
-than it would an Initial packet, ensuring that connection migration is no more
-load on a new path than establishing a new connection.
+single packet.
+
+An endpoint SHOULD NOT probe a new path with packets containing a
+PATH_CHALLENGE more frequently than it would send an Initial packet. This

```suggestion
PATH_CHALLENGE frame more frequently than it would send an Initial packet. This
```

 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
 containing an unpredictable payload on the path to be validated.
 
 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against packet
 loss. However, an endpoint SHOULD NOT send multiple PATH_CHALLENGE frames in a
-single packet.  An endpoint SHOULD NOT send a PATH_CHALLENGE more frequently
-than it would an Initial packet, ensuring that connection migration is no more
-load on a new path than establishing a new connection.
+single packet.
+
+An endpoint SHOULD NOT probe a new path with packets containing a
+PATH_CHALLENGE more frequently than it would send an Initial packet. This
+ensures connection migration is no more load on a new path than establishing a

```suggestion
ensures that connection migration is no more load on a new path than establishing a
```

```suggestion
to verify the peer's ownership of the address if validation is not already underway.
```

Removing this is fine now I think.

This is fine, it's just moving text around.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#pullrequestreview-493873573

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 15:05:45 -0700

Agreed. @ekinnear if you have text in mind, would you mind writing a PR to add your preferred clarification?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#discussion_r493060202

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Sep 2020 15:08:04 -0700

@martinthomson pushed 1 commit.

2f0bf6fa9455f8b319ebfe51d16d441fe10a1549  Apply suggestions from Jana's code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/8e05bf5a6c2739fafc6c5302e7fb176d6a2844c7..2f0bf6fa9455f8b319ebfe51d16d441fe10a1549

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Sep 2020 15:09:28 -0700

f6177499eb1101a89e5a568580a09957da7c7a24  Wrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102/files/2f0bf6fa9455f8b319ebfe51d16d441fe10a1549..f6177499eb1101a89e5a568580a09957da7c7a24

---

From: ianswett <[email-masked]>
Date: Tue, 22 Sep 2020 15:15:33 -0700

Merged #4102 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4102#event-3795391366