Re: [quicwg/base-drafts] No need for RCID if the peer increases Retire Prior To (#3550)

[Nick Banks <[e-mail]>]

@nibanks commented on this pull request.

I definitely prefer this type of change over changing the wire format of the RCID frame. Though I still think this design here is significantly more complicated to implement than using the ACK, as you've got to track the "new CID sequence number" for every CID you force your peer to retire and then for every packet that comes in that changes CID you're going to have to iterate through all your retired CIDs (that you're forced to track for this) and check if the new CID's sequence number is greater.

For the ACK design, when a packet is acknowledged you look at the metadata for the packet. Oh, it retired CID X? Go clean it up now. There are no look ups, extra tracking state or walking any lists of things.

> @@ -1007,11 +1007,12 @@ initial connection ID.
 When an endpoint issues a connection ID, it MUST accept packets that carry this
 connection ID for the duration of the connection or until its peer invalidates
 the connection ID via a RETIRE_CONNECTION_ID frame
-({{frame-retire-connection-id}}).  Connection IDs that are issued and not
-retired are considered active; any active connection ID is valid for use with
-the current connection at any time, in any packet type.  This includes the
-connection ID issued by the server via the preferred_address transport
-parameter.
+({{frame-retire-connection-id}}) or it invalidates the connection ID by
+increasing the the Retire Prior To field.  Connection IDs that are issued and

I like the "Retired Prior To". I think we should still consider this as retiring the CID, and not introduce a new term/concept like invalid.

> @@ -1056,18 +1057,20 @@ 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.
+IDs until a connection ID greater than or equal to the Retire Prior To value is
+used by the peer.  If the endpoint can no longer process the indicated

I agree with Martin here. The next needs to be updated to refer to the NCID sequence number instead.

>  
 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.  Failure
-to cease using the connection IDs when requested can result in connection
-failures, as the issuing endpoint might be unable to continue using the
-connection IDs with the active connection.
+corresponding connection IDs.  Use of a newly provided connection ID proves

Well, the use of the **newly provided** connection ID is proof but that's not what the text above talks about, as you've pointed out.

-- 
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/3550#pullrequestreview-384799399