Re: [quicwg/base-drafts] active_connection_id_limit interacts poorly with Retire Prior To (#3193)

[Eric Kinnear <[e-mail]>]

>  it seems like the reasonable thing to do would be to silently drop the CID on the floor

That was the previous recommendation if the peer provided too many CIDs and you didn't want to maintain any more, and I think that still applies if the peer doesn't respect the TP.

For context, this came up in several issues, the TP came in via #1994, with the [conclusion from Tokyo](https://github.com/quicwg/base-drafts/issues/1994#issuecomment-458820197) being that it would be advisory only (hence the SHOULD).

PR #1998 actually made the change which included that SHOULD, and also resolved the concerns from #2403. #2428 helped to clarify some rate-limiting around how quickly you should cycle through CIDs.

All that is to say, if you want to use the limit and explicitly communicate it with the TP, then you SHOULD do that. Everyone SHOULD do that.

If not, or if your peer doesn't respect it, you can always dump those extra CIDs on the floor, with all the potential for running out that comes from taking that action. In this case, you end up maintaining as many as you wanted, probably the same value that you sent in the TP that the other side ignored...

If/when the peer sends RetirePriorTo and requests that you retire them, you retire the ones you haven't yet retired and still know about. Generally, that means that you get a replacement for those, so now you still have `active_connection_id_limit` CIDs. (Side note: The place this gets messy is if the peer suddenly decides to respect the value you put in the TP and doesn't replace them. This has always been a potential consequence of dropping them, though.)

For the ones that you discarded, the peer should discard those 3PTO after it sent RetirePriorTo. From [Section 5.1.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#retiring-cids):
```
An endpoint MAY discard a connection ID for which retirement has been requested 
once an interval of no less than 3 PTO has elapsed since an acknowledgement is 
received for the NEW_CONNECTION_ID frame requesting that retirement. Until 
then, the endpoint SHOULD be prepared to receive packets that contain the 
connection ID that it has requested be retired. Subsequent incoming packets 
using that connection ID could elicit a response with the corresponding 
stateless reset token.
```

So the peer that requested retirement can discard any state about them, and you're back to having everyone on the same page about how many are outstanding. 

That generally seems sufficient, although it would be great to cover another scenario or add some text that could be added to explain this better? If the issuing endpoint doesn't use RetirePriorTo then you're fine holding as many as you wanted to maintain forever. If they do use RetirePriorTo, then you're reset back to a good state.

And if you ever get RetirePriorTo indicating an old value, you're also happy since you don't need to do anything.

-- 
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/issues/3193#issuecomment-550197395