Is PATH_CIDS_BLOCKED frame really needed?

[mirjak]

We discussed today in the interop call if the PATH_CIDS_BLOCKED frame is really needed because usually the peer should provide at least one unused CID for all active paths, otherwise this seems to be rather an implementation error. Also there is no really good reason to not just provide at least one CID for all paths up to the max path id limit. If you want to limit the number of paths, just set a lower max path id limit. This could be clarified in the draft.

However, the use case to send PATH_CIDS_BLOCKED frame when you want to open a new path but are not blocked by the max path id but instead by the fact that you didn't get any CID for an unused path ID seemed still relevant as this behaviour is allowed and therefore might not be an implementation error.

Also as we have now already specified it, there is no real harm in keeping it. A client can choose to not implement and a server can choose to ignore the frame.

[mirjak]

I created PR #495 to at least hint at the point that it's good to issue CIDs for all paths up to the max path id limit.

[flub]

I landed here while wondering what to do with PATH_CIDS_BLOCKED... I've tried to read the previous information about this in the issues here [0]. Receiving this frame doesn't really help you in practice I think. I'd rather REQUIRE that at least one CID is issued for each un-opened path up the max PathId limit. And maybe even REQUIRE to issue up to max_connection_id_limit CIDs for those unopened paths, at least RECOMMEND.

This mostly because I don't see the value of limiting those: you can already limit the number of paths. Keeping track of a few more CIDs really doesn't bring much value.

On the other hand I could see that the number of round-trips required to open a new path would be increased if implementations could hold off issuing more CIDs.

[0] references I found:

• original issue: Clarify interaction between PATHS_BLOCKED and PATH_NEW_CONNECTION_ID #459
• introduced: https://github.com/quicwg/multipath/pull/468/files
• a proposed clarification: https://github.com/quicwg/multipath/pull/468/files (issue: Provide more guidance when to send PATH_CID_BLOCKED frame #496)
• another proposed tweak: Note that issuing CIDs for all paths might be beneficial #495

[mirjak]

This was discussed at IETF-122 and decided to keep it. BLOCKED frames are also useful for debugging.