Re: [quicwg/base-drafts] Bundle new client connection ID and path challenge in migration probes (#1730)

[Martin Thomson <[e-mail]>]

martinthomson requested changes on this pull request.

I think that the idea is good, but the first addition needs some tweaking.

> @@ -2074,6 +2074,9 @@ path validation with other frames.  For instance, an endpoint may pad a packet
 carrying a PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a
 PATH_RESPONSE with its own PATH_CHALLENGE.
 
+When probing a new path, an endpoint may want to ensure that the response, if
+any, is sent to a specific connection ID. The endpoint achieves that by bundling
+NEW_CONNECTION_ID and PATH_CHALLENGE frames, in that order.

This implies that order is significant.  It also implies that bundling the two means that this specific connection ID will be used.  We've tried really hard to avoid special inter-frame dependencies like this.  PATH_CHALLENGE is special in the sense that the path it follows is relevant to its processing (which is a necessary evil), but this implies much more than that.  I think that rewording this to suggest that providing NEW_CONNECTION_ID ahead of PATH_CHALLENGE is useful (even necessary if the peer has run out, as they might have) and that having them in the same packet means that the NEW_CONNECTION_ID is guaranteed to be available.  Anything more than might give the wrong impression.

> @@ -2187,7 +2190,10 @@ 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.
+see {{migration-linkability}} for further discussion. An endpoint that uses
+a new local address should include a NEW_CONNECTION_ID frame in the probe,

"SHOULD"? I don't think that we need to be this suggestive here, other than to note that lack of connection IDs will make probing - and responding to probes - impossible.

> @@ -2359,6 +2365,11 @@ genuine migrations.  Changing port number can cause a peer to reset its
 congestion state (see {{migration-cc}}), so the port SHOULD only be changed
 infrequently.
 
+Endpoints could also have their activity correlated if their peers keep using
+the same destination connection id after migration. Nodes that initiate a

s/id/ID

-- 
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/1730#pullrequestreview-153601031