Re: [quicwg/base-drafts] Limit RCID state (#3547)

[Kazuho Oku <[e-mail]>]

@kazuho commented on this pull request.



> @@ -1069,6 +1069,18 @@ 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.
 
+An endpoint MAY elect to only send or retransmit RETIRE_CONNECTION_ID frames
+with sequence numbers greater than or equal to the highest Retire Prior To field
+received minus its advertised active_connection_id_limit. This bounds the

Consider the case where  client has sent an RCID frame. The server has received that frame and has sent an NCID frame carrying a replacement. But that server has not sent an ACK yet, or the ACK it has sent has been lost.

At this moment, the server might decide to update the CID encryption key, and try to retire all the CIDs that has been provided to the client. When the NCID frame carrying the request to retire reaches the client, the client is now required to track retirement of `max_connection_id_limit + 1` CIDs.

I agree that this is a corner case. But our previous consensus has been to allow an endpoint to request retirement of all the CIDs that have been provided at once. Assuming that we want to retain that consensus, requiring endpoints to track *more* than `max_connection_id_limit` is IMO the logical choice.

The effect of *not* requiring that would be that an endpoint that decides to retire the CIDs that it has provided to the peer has to do retirement in multiple phases; e.g., first request retirement of half of them, wait for RCID frames, then retire the other half. That's much more complicated than just saying recommending endpoints to track something like `max_connection_id_limit * 2`.

-- 
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/3547#discussion_r399240482