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

[Martin Thomson <[e-mail]>]

@martinthomson 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 don't think that is sufficient or necessary.

1. sufficiency: an adversary can send a long sequence of NEW_CONNECTION_ID frames with seq: N and rpt: N-1.  This is both entirely legitimate and completely outside the spirit of the protocol.

2. necessity: 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.  It is an otherwise arbitrary number.  I don't think that we need to optimize for that case.

The only problem arises with this approach is when that gap widens more than you would like.  At which point you can throw down a CONNECTION_CLOSE and walk away.

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