Re: [quicwg/base-drafts] Remove timing guidance (#3474)

[Eric Kinnear <[e-mail]>]

erickinnear approved this pull request.

Thanks for writing this up! 

> -An endpoint MAY discard a connection ID for which retirement has been requested
-once an interval of no less than 3 PTO has elapsed since an acknowledgement is
-received for the NEW_CONNECTION_ID frame requesting that retirement.  Until
-then, the endpoint SHOULD be prepared to receive packets that contain the
-connection ID that it has requested be retired.  Subsequent incoming packets
-using that connection ID could elicit a response with the corresponding
-stateless reset token.
+An endpoint might need to stop accepting previously issued connection IDs in
+certain circumstances.  Such an endpoint can cause its peer to retire connection
+IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
+field.  The endpoint SHOULD continue to accept the previously issued connection
+IDs until they are retired by the peer.  If the endpoint can no longer process
+the indicated connection IDs, it MAY close the connection.
+
+Upon receipt of an increased Retire Prior To field, the peer MUST first stop
+using the corresponding connection IDs using RETIRE_CONNECTION_ID frames and

How about: 
```
Upon receipt of an increased Retire Prior To field, the peer MUST stop using the 
corresponding connection IDs and retire them with RETIRE_CONNECTION_ID frames 
before adding the newly provided connection ID to the set of active connection IDs. 
This ordering allows an endpoint that has already supplied its peer with as many 
connection IDs as allowed by the active_connection_id_limit transport parameter 
to replace those connection IDs with new ones as necessary.
```

We'd discussed adding some extra text making it very obvious the point about the ordering enabling replacing a full limit, and having that text might make it easier to reword the first sentence further.

This still loses the idea that it may take a little while to stop using the CIDs (FWIW, I don't think we need to care about that part, the only real requirement here is that you retire them, and if you generate R_CID then you must have drained your outbound processing by the time the frame gets there).

> -connection ID that it has requested be retired.  Subsequent incoming packets
-using that connection ID could elicit a response with the corresponding
-stateless reset token.
+An endpoint might need to stop accepting previously issued connection IDs in
+certain circumstances.  Such an endpoint can cause its peer to retire connection
+IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
+field.  The endpoint SHOULD continue to accept the previously issued connection
+IDs until they are retired by the peer.  If the endpoint can no longer process
+the indicated connection IDs, it MAY close the connection.
+
+Upon receipt of an increased Retire Prior To field, the peer MUST first stop
+using the corresponding connection IDs using RETIRE_CONNECTION_ID frames and
+then add the newly provided connection ID to the set of active connection IDs.
+Failure to retire the connection IDs promptly can cause failure of the
+connection, either because the endpoint closed the connection or can no longer
+associate these connection IDs with the active connection.

+1 this seems to capture it, otherwise I'd be a bit unsure what "because the endpoint closed the connection" meant and why that was my fault.

-- 
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/3474#pullrequestreview-363065290