Re: [quicwg/base-drafts] A more complete connection migration (#1012)

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.

@martinthomson : I'm going to try to unify the mechanisms and make this client/server agnostic, which might resolve some issues. We did that because it was easier to reason about in the earlier designs, but the current version actually lends itself nicely to symmetry, I think. At any rate, let me try that first.

> +
+A server validates a client's address by sending a PATH_CHALLENGE frame
+containing a payload that is hard to guess to that address.  The server
+considers the address to be valid when a PATH_RESPONSE frame containing the same
+payload is received from the client.
+
+Similarly, a client verifies the PMTU of a network path from a new client
+address to the server by sending a PMTU-sized packet carrying a PATH_CHALLENGE
+frame. The client considers the PMTU verified when a PATH_RESPONSE frame
+containing the same payload sent by the server to the new client address is
+received.
+
+
+### Client Behavior {#migration-client}
+
+A client triggers connection migration to a new address by sending a

Oops -- yes it doesn't. Will fix.

> +frame. The client considers the PMTU verified when a PATH_RESPONSE frame
+containing the same payload sent by the server to the new client address is
+received.
+
+
+### Client Behavior {#migration-client}
+
+A client triggers connection migration to a new address by sending a
+PATH_CHALLENGE as a probe or by switching to sending all packets to the new
+address. The client SHOULD do PMTU verification before considering migration
+complete. The client also participates in an address validation that the server
+may initiate to confirm the client's ownership of its address (see
+{{migration-server}}).
+
+A client migrating to a new network might use a new connection ID for packets
+sent from the new address, see {{migration-linkability}} for further discussion.

Probes are just packets, and are not treated any differently, so they follow the same rules for connection ID and packet numbers as specified in the linkability section.

> +can perform more accurate measurements by associating the server's response with
+the causative PATH_CHALLENGE.
+
+When the client receives a PATH_RESPONSE from the server and verifies that the
+included data matches the data it sent in a previous PATH_CHALLENGE, the server
+is considered reachable from the new address and the PMTU of the new network
+path is considered verified.
+
+A client SHOULD abandon the new address if it does not receive a PATH_RESPONSE
+after sending some number of PATH_CHALLENGE frames and/or after some time has
+passed. Note that the client may be receiving data from the server during this
+period, but not receiving a PATH_RESPONSE may be indicative of a PMTU detection
+failure.
+
+
+#### Responding to a Server's Validation

So I chose to structure it like this because it's easier to see how to implement such a thing. If it's useful to contextualize, I can add more text in the common text up at the top of this section. 

Validation can be described separately, but in this description, it's only used for the server to validate a client's new address. 

-- 
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/1012#pullrequestreview-83074498