Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Exceeding active_connection_id_limit with forced retirement #3422

Closed
martinthomson opened this issue Feb 5, 2020 · 0 comments · Fixed by #3600
Closed

Exceeding active_connection_id_limit with forced retirement #3422

martinthomson opened this issue Feb 5, 2020 · 0 comments · Fixed by #3600
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing

Comments

@martinthomson
Copy link
Member

Upon receipt, the peer MUST first retire the corresponding connection IDs using RETIRE_CONNECTION_ID frames and then add the newly provided connection ID to the set of active connection IDs.

It is not obvious from this, but the intent here is to allow NEW_CONNECTION_ID to exceed the limit from active_connection_id_limit.
@martinthomson martinthomson added editorial An issue that does not affect the design of the protocol; does not require consensus. -transport labels Feb 5, 2020
@MikeBishop MikeBishop mentioned this issue Feb 5, 2020
Closed
@mnot mnot added this to Editorial Issues in Late Stage Processing Feb 5, 2020
martinthomson added a commit that referenced this issue Apr 28, 2020
@martinthomson
Rationale for NEW_CONNECTION_ID processing order
1bba65d 
We already had something here, but I think that it missed the central
reason, which is the combination of:

* wanting to replace all connection IDs
* having used the limit from active_connection_id_limit
* wanting to ensure that there is >= 1 available connection IDs left

This phrasing isn't quite that explicit, but I think that it is clear
enough.

Closes #3422.
@martinthomson martinthomson mentioned this issue Apr 28, 2020
Merged
Late Stage Processing automation moved this from Editorial Issues to Issue Handled Apr 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing
  
Issue Handled
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Rationale for NEW_CONNECTION_ID processing order quicwg/base-drafts
1 participant
@martinthomson