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

[Martin Thomson <[e-mail]>]

@martinthomson requested changes on this pull request.

This seems like a perfectly good change.  The endpoint is no longer requesting retirement; it is unilaterally declaring that it will not honour the connection IDs.  That's consistent with the existing design.

I do have some problems with the specifics of the proof of receipt structure you describe, however.  It might be sufficient to just keep the existing squishy text about keeping state for "a while" as the only language on the subject.

We should also say something about RETIRE_CONNECTION_ID frames that target sequence numbers before the cutoff.  I think that it is safe to say that they can be ignored.

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

If the intent of this PR is to say "I'm retiring these connection IDs, whether you like it or not", then maybe a name change is in order.  As this is a declaration, maybe "Retired Prior To" or "Invalid Prior To".

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

"until a connection ID greater than or equal to the Retire Prior To value" doesn't work.

Say you have 10 active.  You can still issue up to 15  before you send "Retire Prior To" with a value of 10.  So use of connection ID 15 is no good signal that the retirement was accepted.

I think that what you meant to say here is "until the peer uses a connection ID with a sequence number greater than the one included in the NEW_CONNECTION_ID that invalidated the previous connection ID" or some such.  Noting of course that you can send NEW_CONNECTION with seq 16 and RPT of 0 followed by NEW_CONNECTION_ID { seq 16, RPT 10 } totally legitimately; in which case you can't rely on use of CID[16] to mean anything.

It would also not be entirely wise to drop connection IDs at the point that you see the new ones being used, even if your assumption was true.  Though you might have confirmation that a stateless reset won't kill the connection, you would still be dropping perfectly good packets that are still totally usable.

>  
 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

This is not proof.  See above.

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