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

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Some more small suggestions, but looking close.

> @@ -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,

New_CONNECTION_ID frame(s)?

> @@ -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

I'm a bit vague on "delayed or lost and harm connection performance as the original endpoint might not route those connection IDs optimally after some delay."  Instead, how about "delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route correctly."?

> @@ -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

I still think this MUST is unenforceable and a bit odd.  If my load balancer restarts in 5 seconds and the peer hasn't retired the old CIDs by then, they're still getting retired.

> @@ -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

```suggestion
Prior To field, then it MAY drop state for that connection ID, and respond to
```

> @@ -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

frame(s)

-- 
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-248966981