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

[Kazuho Oku <[e-mail]>]

@kazuho commented on this pull request.



> @@ -1069,6 +1069,15 @@ 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 SHOULD limit the number of outstanding RETIRE_CONNECTION_ID frames
+to bound the necessary state. In order to allow a peer to retire all previously
+issued connection IDs, the limit on the number of outstanding
+RETIRE_CONNECTION_IDs SHOULD be at least the active_connection_id_limit. An

I agree that we do not need to care about sufficiency.

> if you track min(unacknowledged RCID) and max(RPT) then you can track as few RCID frames as you like. It might be nice if people used active_connection_id_limit*2, but that number only optimizes for a complete turnover of connection IDs every round trip.

This observation is what I disagree with. The intent of the change I proposed right above is to allow an endpoint to retire all the CID at once, without being concerned about the peer losing track of some sequence numbers carried by CID frames already inflight, or the peer considering the endpoint to be doing something malicious.

Assuming that an endpoint that retires CIDs track each of the RCID frame it sends, the safe number is _active_connection_id_limit_ (the number of CIDs that might be retired at once by RPT) plus _the number of retirements that that endpoint might initiate at once_.

To give a specific example, consider the following case.
* A client, with max_connection_id_limit = 2, is using CID<sub>0</sub> for the main path, and is probing a new path using CID<sub>1</sub>.
* Server sends NCID(CID<sub>2</sub>, RPT=2), NCID(CID<sub>3</sub>, RPT=2).
* Client receives these NCID frames, and assigns CID<sub>2</sub> to the main path, CID<sub>3</sub> to the path being probed. The client sends RCID(CID<sub>0</sub>), RCID(CID<sub>1</sub>).
* Before receiving ACK for the two RCID frames, the client decides to abandon the path being probed. It needs to send RCID(CID<sub>2</sub>).

At this point, the client is required to track the flight of RCID frames carrying *three* CIDs. And it has to make sure that RCID(CID<sub>2</sub>) reaches the peer, otherwise it would not receive a CID that substitutes CID<sub>2</sub>.

The recommendation in this PR now (i.e. "the limit on the number of outstanding RETIRE_CONNECTION_IDs SHOULD be at least the active_connection_id_limit") fails to cover this case.

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