Re: [quicwg/base-drafts] Better describe the use of Preferred Address (#3354)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

Thanks for doing this.  This text certainly needed a few refinements.

> @@ -2194,11 +2194,13 @@ linked by any other entity.
 At any time, endpoints MAY change the Destination Connection ID they send to a
 value that has not been used on another path.
 
-An endpoint MUST use a new connection ID if it initiates connection migration as
-described in {{initiating-migration}} or probes a new network path as described
-in {{probing}}.  An endpoint MUST use a new connection ID in response to a
-change in the address of a peer if the packet with the new peer address uses an
-active connection ID that has not been previously used by the peer.
+An endpoint MUST use a new connection ID when it initiates connection migration
+as described in {{initiating-migration}} or {{preferred-address}}, or when it
+probes a new network path as described in {{probing}}, and MUST NOT reuse

The run-on sentence here could be two sentences.

```suggestion
probes a new network path as described in {{probing}}. Endpoints MUST NOT reuse
```

...but I'm not seeing what the new content here does.  It appears to just be a restatement of the previous clause.

> @@ -1036,9 +1036,9 @@ be used again and requests that the peer replace it with a new connection ID
 using a NEW_CONNECTION_ID frame.
 
 As discussed in {{migration-linkability}}, each connection ID MUST be used on
-packets sent from only one local address.  An endpoint that migrates away from a
-local address SHOULD retire all connection IDs used on that address once it no
-longer plans to use that address.
+packets sent from only one local address, and MUST NOT be used across multiple
+paths that are opened intentionally.  An endpoint SHOULD retire connection IDs
+as they become unusable.

This new text is less accurate.  It is potentially always possible to reuse connection IDs, but what matters is whether the endpoint forsees use of the connection ID.  The original text is probably not as good as it could be, but that seems unrelated to the stated goal of the PR.

As this is a restatement of the original text in another section, I would prefer to keep this terse.  In fact, I would not use normative language and instead say:

> As discussed in {{blah}}, endpoints limit the use of a connection ID to a single network path where possible.  Endpoints SHOULD retire connection IDs when no longer actively using the network path on which the connection ID was used.

>  
+When the client finishes migrating to the preferred address, it retires the
+connection ID that was used for the original path ({{retiring-cids}}).
+Similarly, a client that continues using the original server address SHOULD
+retire the connection ID provided by the preferred_address transport parameter.
+Retirement of either of these connection IDs notifies the server of the
+address the client has chosen.

This creates a much stronger inference than I think we ever formally documented, though it is a reasonable one for sure.  If your intent is that the server never see data on the old path, then say that instead:

> Once a client has migrated successfully to a network path that uses a server preferred address, it MUST NOT migrate to a path using the address that was used during connection establishment.

Otherwise, the inference you are giving the server to make here is without any support.  Once you say this, you can drop this text.

> @@ -4635,8 +4642,12 @@ preferred_address (0x000d):
   transport parameter is only sent by a server. Servers MAY choose to only send
   a preferred address of one address family by sending an all-zero address and
   port (0.0.0.0:0 or ::.0) for the other family. IP addresses are encoded in
-  network byte order. The CID Length field contains the length of the
-  Connection ID field.
+  network byte order. The Connection ID field and the Stateless Reset Token

New paragraph here please.
```suggestion
  network byte order.
  
  The Connection ID field and the Stateless Reset Token
```

> @@ -4635,8 +4642,12 @@ preferred_address (0x000d):
   transport parameter is only sent by a server. Servers MAY choose to only send
   a preferred address of one address family by sending an all-zero address and
   port (0.0.0.0:0 or ::.0) for the other family. IP addresses are encoded in
-  network byte order. The CID Length field contains the length of the
-  Connection ID field.
+  network byte order. The Connection ID field and the Stateless Reset Token
+  field contain the alternative connection ID that is assigned the sequence

```suggestion
  field contain an alternative connection ID that has a sequence
```

> @@ -4635,8 +4642,12 @@ preferred_address (0x000d):
   transport parameter is only sent by a server. Servers MAY choose to only send
   a preferred address of one address family by sending an all-zero address and
   port (0.0.0.0:0 or ::.0) for the other family. IP addresses are encoded in
-  network byte order. The CID Length field contains the length of the
-  Connection ID field.
+  network byte order. The Connection ID field and the Stateless Reset Token
+  field contain the alternative connection ID that is assigned the sequence
+  number of one ({{issue-cid}}). Having them bundled with the preferred address

```suggestion
  number of 1 ({{issue-cid}}). Having these values bundled with the preferred address
```

> @@ -4635,8 +4642,12 @@ preferred_address (0x000d):
   transport parameter is only sent by a server. Servers MAY choose to only send
   a preferred address of one address family by sending an all-zero address and
   port (0.0.0.0:0 or ::.0) for the other family. IP addresses are encoded in
-  network byte order. The CID Length field contains the length of the
-  Connection ID field.
+  network byte order. The Connection ID field and the Stateless Reset Token
+  field contain the alternative connection ID that is assigned the sequence
+  number of one ({{issue-cid}}). Having them bundled with the preferred address
+  ensures that there will be at least one unused active connection ID when the
+  client initiates migration to the preferred address. The CID Length field
+  contains the length of the Connection ID field.

I'd drop the last sentence.

> @@ -2251,16 +2253,21 @@ transport parameter in the TLS handshake.
 Servers MAY communicate a preferred address of each address family (IPv4 and
 IPv6) to allow clients to pick the one most suited to their network attachment.
 
-Once the handshake is finished, the client SHOULD select one of the two
+Once the handshake is confirmed, the client SHOULD select one of the two

👍 Do we need a citation here too?

-- 
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/3354#pullrequestreview-345085453