Re: [quicwg/base-drafts] Server's preferred address (#1251)

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.

High-order comment: I think this should be called something else, since the parallel with Client Connection Migration might be misleading.

> @@ -1485,6 +1505,11 @@ 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.
 
+Differences in routing on the Internet might cause the same destination address
+and connection ID to reach a different server instance which does not posses the
+necessary connection state. Receiving a Stateless Reset in response to a probing
+packet SHOULD NOT terminate the connection, but MUST cause the endpoint to
+consider path validation to have failed.

nice catch.

> +QUIC allows servers to accept connections on one IP address and attempt to
+transfer these connections to a more preferred address shortly after the
+handshake.  This section describes the protocol for migrating a connection to a
+new server address.
+
+Migrating a connection to a new server address mid-connection is left for future
+work. If a client receives packets from a new server address not indicated by
+the preferred_address transport parameter, the client SHOULD discard these
+packets.
+
+### Initiating Connection Migration
+
+A server initiates connection migration by including the preferred_address
+transport parameter in the TLS handshake.
+
+Once the handshake is finished, the client MUST initiate path validation (see

Requiring the client to use the server's preferred address seems unnecessary.

> +Migrating a connection to a new server address mid-connection is left for future
+work. If a client receives packets from a new server address not indicated by
+the preferred_address transport parameter, the client SHOULD discard these
+packets.
+
+### Initiating Connection Migration
+
+A server initiates connection migration by including the preferred_address
+transport parameter in the TLS handshake.
+
+Once the handshake is finished, the client MUST initiate path validation (see
+{{migrate-validate}}) of the server's preferred IP address using the connection
+ID provided in the preferred_address transport parameter.
+
+If path validation succeeds, the client SHOULD immediately begin sending all
+non-probe packets to the new server address using the new connection ID and

s/non-probe/non-probing/

> +ID provided in the preferred_address transport parameter.
+
+If path validation succeeds, the client SHOULD immediately begin sending all
+non-probe packets to the new server address using the new connection ID and
+discontinue use of the old server address.  If path validation fails, the client
+MUST continue sending all future packets to the server's original IP address.
+
+### Responding to Connection Migration
+
+A server might receive a packet addressed to its preferred IP address at any
+time during the connection after the handshake is completed.  If this packet
+contains a PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per
+{{migrate-validate}}, but the server MUST continue sending all other packets
+from its original IP address.
+
+Once the server has received a non-probing packet on its preferred address which

Fixed in #1253 

> +If path validation succeeds, the client SHOULD immediately begin sending all
+non-probe packets to the new server address using the new connection ID and
+discontinue use of the old server address.  If path validation fails, the client
+MUST continue sending all future packets to the server's original IP address.
+
+### Responding to Connection Migration
+
+A server might receive a packet addressed to its preferred IP address at any
+time during the connection after the handshake is completed.  If this packet
+contains a PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per
+{{migrate-validate}}, but the server MUST continue sending all other packets
+from its original IP address.
+
+Once the server has received a non-probing packet on its preferred address which
+is the largest packet number seen so far, the server begins sending to the
+client exclusively from its preferred IP address.

What should the server do if a subsequent packet from the client appears on the old address?

> +time during the connection after the handshake is completed.  If this packet
+contains a PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per
+{{migrate-validate}}, but the server MUST continue sending all other packets
+from its original IP address.
+
+Once the server has received a non-probing packet on its preferred address which
+is the largest packet number seen so far, the server begins sending to the
+client exclusively from its preferred IP address.
+
+
+## Interaction of Client and Server Migration
+
+A client might need to perform a connection migration before the server's
+connection migration has completed.  In this case, the client SHOULD perform
+path validation to both the original and preferred server address from the
+client's new address concurrently.

This is tricky. Where should the client send data if its old address is unusable?
(I want to spend more cycles thinking about this, but I'll be out. Do make sure that all corner cases are covered; I worry that there are more here.)

> @@ -1791,6 +1811,64 @@ number. "packet_number_secret" is derived from the TLS key exchange,
 as described in Section 5.6 of {{QUIC-TLS}}.
 
 
+## Server Connection Migration {#migration-server}

I don't think this should be called Server Connection Migration. There's a symmetry with Client Connection Migration that this name suggests, but that's not true, since the assumptions are quite different. How about "Using a Preferred Server Address"?

Along the same lines, I think you should state any assumptions here clearly, since these have implications. I can think of at least one: The server is not actually changing network attachment points. I believe this assumption is implicit in this design.

> @@ -1791,6 +1811,64 @@ number. "packet_number_secret" is derived from the TLS key exchange,
 as described in Section 5.6 of {{QUIC-TLS}}.
 
 
+## Server Connection Migration {#migration-server}
+

I would add a short description of where this is expected to be used.

-- 
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/1251#pullrequestreview-107516729