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

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.

A few comments, but pretty close.

>  
 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
 from a migrating peer do not carry a spoofed source address.
 
 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
 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

```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
```

>  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.

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

> -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.

Removing this is fine now I think.

> @@ -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.

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