Re: [quicwg/base-drafts] enforce the active_connection_id_limit (#3201)

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.



> @@ -999,8 +999,10 @@ retired are considered active; any active connection ID can be used.
 An endpoint SHOULD ensure that its peer has a sufficient number of available and
 unused connection IDs.  Endpoints store received connection IDs for future use
 and advertise the number of connection IDs they are willing to store with the
-active_connection_id_limit transport parameter.  An endpoint SHOULD NOT provide
-more connection IDs than the peer's limit.
+active_connection_id_limit transport parameter.  An endpoint MUST NOT provide
+more connection IDs than the peer's limit.  An endpoint that receives more
+connection IDs than its advertised active_connection_id_limit MUST close the
+connection with an error of type CONNECTION_ID_LIMIT_ERROR.

@huitema That doesn’t work well with Retire Prior To, since you still MUST retire that connection ID. So you need to track at least the sequence number of the CID.
It seems like you’re trying to build a way for a peer to (silently) revoke the limit it announced in its transport parameters. Building such a mechanism is possible (we’d need something like a MAX_CID frame), but we decided to not do this, mostly because we assumed that the number of requested connection IDs will be small (O(10)). If that argument still holds, I don’t think it’s too much to ask for to keep track of O(10) CID sequence numbers.

-- 
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/3201#discussion_r352262691