Re: [quicwg/base-drafts] Request to Retire Locally Issued CIDs (#2769)

[Eric Kinnear <[e-mail]>]

erickinnear requested changes on this pull request.

Thanks for writing this up! 
This seems like a pretty good start if we're adding a "Please Retire" field to a NEW_CONNECTION_ID. A few comments and some wording suggestions. I think we also need the requirement to replace all of the retired ones, otherwise we risk closing down to just a single CID every time we retire.

> @@ -5018,6 +5042,28 @@ sequence number, or if a sequence number is used for different connection
 IDs, the endpoint MAY treat that receipt as a connection error of type
 PROTOCOL_VIOLATION.
 
+The Retire Prior To field is a request for the peer to retire all connection IDs
+with a sequence number less than the specified value.  This includes the initial
+and preferred_address transport parameter connection IDs.  The peer SHOULD
+retire the corresponding connection IDs and send the corresponding
+RETIRE_CONNECTION_ID frame in a timely manner

Editorial nit: Missing `.`
```suggestion
RETIRE_CONNECTION_ID frame in a timely manner.
```

> @@ -994,6 +994,22 @@ 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.
 
+An endpoint can request that its peer retire connection IDs by sending a
+NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt,

For readability, I might make a few editorial changes to this paragraph: 
```
The issuer of a connection ID can request that its peer retire that 
connection ID by sending a NEW_CONNECTION_ID frame with a 
non-zero Retire Prior To field.
```

```
Upon receipt of such a frame, an endpoint SHOULD retire active connection IDs 
with sequence numbers lower than that specified in the Retire Prior To field 
by sending a RETIRE_CONNECTION_ID frame for each retired connection ID 
in a timely manner.
```

```
Failure to retire connection IDs in a timely manner when requested can 
harm connection performance by causing packets to be delayed or lost, 
since the issuer of the connection IDs might no longer have the ability 
to route packets using those connection IDs correctly.
```

Minor, but this also helps to align with the language here -- referring to "issuers" of connection IDs, and behavior specific to each endpoint, etc.

> @@ -5018,6 +5042,28 @@ sequence number, or if a sequence number is used for different connection
 IDs, the endpoint MAY treat that receipt as a connection error of type
 PROTOCOL_VIOLATION.
 
+The Retire Prior To field is a request for the peer to retire all connection IDs
+with a sequence number less than the specified value.  This includes the initial
+and preferred_address transport parameter connection IDs.  The peer SHOULD
+retire the corresponding connection IDs and send the corresponding
+RETIRE_CONNECTION_ID frame in a timely manner
+
+The sender of the NEW_CONNECTION_ID frame MAY remove the connection IDs after 3
+PTO, even if the peer has not retired them with RETIRE_CONNECTION_ID yet.  The
+3-PTO timer starts on acknowledgement of the packet containing the
+NEW_CONNECTION_ID frame.  Continued use of the retired connection IDs after this
+point will likely result in a stateless reset being sent.

This is slightly conflicting with the text above -- do we really want to have the same (but not quite) text in two places vs. just keeping it above and describing the field down here?
We could just remove this paragraph.

> +RETIRE_CONNECTION_ID frame in a timely manner
+
+The sender of the NEW_CONNECTION_ID frame MAY remove the connection IDs after 3
+PTO, even if the peer has not retired them with RETIRE_CONNECTION_ID yet.  The
+3-PTO timer starts on acknowledgement of the packet containing the
+NEW_CONNECTION_ID frame.  Continued use of the retired connection IDs after this
+point will likely result in a stateless reset being sent.
+
+The Retire Prior To field MUST be less than or equal to the Sequence Number
+field.  Values greater than the Sequence Number MUST be treated as a connection
+error of type PROTOCOL_VIOLATION.
+
+The sender cannot reduce the value of the Retire Prior To field in subsequent
+NEW_CONNECTION_ID frames.  That is, once a sender indicates a Retire Prior To
+value, it MAY indicate a smaller value, but it has no effect.  A receiver MUST
+ignore any Retire Prior To fields that do not increase.

Sounds good. A slight rewording perhaps: 
```
Once a sender indicates a Retire Prior To value, smaller values sent 
in subsequent NEW_CONNECTION_ID frames have no effect. A receiver 
MUST ignore any Retire Prior To fields that do not increase the largest 
received Retire Prior To value.
```

> @@ -4984,6 +5002,12 @@ Sequence Number:
 : The sequence number assigned to the connection ID by the sender.  See
   {{issue-cid}}.
 
+Retire Prior To:
+
+: A variable-length integer specifying the limit, for which all connection IDs

Editorial nit
```suggestion
: A variable-length integer specifying the limit for which all connection IDs
```

> @@ -994,6 +994,22 @@ 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.
 
+An endpoint can request that its peer retire connection IDs by sending a
+NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt,
+the peer SHOULD retire the corresponding connection IDs and send the
+corresponding RETIRE_CONNECTION_ID frame in a timely manner.  Failing to do so
+can cause packets to be delayed or lost and harm connection performance as the
+original endpoint might not route those connection IDs optimally after some
+delay.
+
+The sender of the Retire Prior To field MUST keep track of the connection IDs it
+wishes to retire until it has received a corresponding RETIRE_CONNECTION_ID
+frame, with one exception: if the sender of the Retire Prior To field has used
+distinct stateless reset tokens for all of their issued connection IDs, and 3
+times the PTO has elapsed since it received an acknowledgment for its Retire
+Prior To field, then it MAY lose track of that connection ID, and respond to
+packets with that connection ID with the corresponding stateless reset token.

I would still prefer to avoid tracking ACKs of packets, but if we're going to do it, then can we condense this down into a sentence or two? 

Something along the lines of: 
```
An endpoint MAY discard a connection ID for which retirement has been requested 
once an interval of not less than 3 PTO has elapsed since an ack is received for 
the NEW_CONNECTION_ID frame requesting that retirement. Subsequent incoming 
packets using that connection ID will elicit a response with the 
corresponding stateless reset token.
```

This depends on preventing reuse of SRTs, but I think that's a good thing to do anyways.

> @@ -994,6 +994,22 @@ 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.
 
+An endpoint can request that its peer retire connection IDs by sending a
+NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt,
+the peer SHOULD retire the corresponding connection IDs and send the
+corresponding RETIRE_CONNECTION_ID frame in a timely manner.  Failing to do so
+can cause packets to be delayed or lost and harm connection performance as the
+original endpoint might not route those connection IDs optimally after some
+delay.
+
+The sender of the Retire Prior To field MUST keep track of the connection IDs it
+wishes to retire until it has received a corresponding RETIRE_CONNECTION_ID
+frame, with one exception: if the sender of the Retire Prior To field has used
+distinct stateless reset tokens for all of their issued connection IDs, and 3
+times the PTO has elapsed since it received an acknowledgment for its Retire
+Prior To field, then it MAY lose track of that connection ID, and respond to
+packets with that connection ID with the corresponding stateless reset token.

Also noting here that we still need some text about requiring that they be replaced.

-- 
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/2769#pullrequestreview-248485443