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

Endpoint MAY discard CIDs #1992

Merged
merged 3 commits into from Nov 12, 2018
Merged

Endpoint MAY discard CIDs #1992

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
cc4861d
endpoint MAY discard CIDs
janaiyengar Nov 12, 2018
af65127
nit
martinthomson Nov 12, 2018
c4d3a83
reflow
janaiyengar Nov 12, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 2 additions & 2 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -939,8 +939,8 @@ the connection ID via a RETIRE_CONNECTION_ID frame

Endpoints store received connection IDs for future use. An endpoint that
receives excessive connection IDs MAY discard those it cannot store. An
endpoint that issues connection IDs cannot expect its peer to store
and use all issued connection IDs.
endpoint that issues connection IDs cannot expect its peer to store and use all
issued connection IDs.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Belated question: when you discard them, it seems you should not send a RETIRE_CONNECTION_ID frame, otherwise you may just get more?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is that you can have an uncoordinated negotiation: I'm willing to issue 64, you only need 8. You take the 8 you want, let the remaining 56 fall on the floor, and then I'll replace the 8 you kept as you RETIRE them. If you RETIREd the 56 you didn't need, I'd replace those, and we'd get into an endless RETIRE/NEW drop for no purpose.


An endpoint SHOULD ensure that its peer has a sufficient number of available and
unused connection IDs. While each endpoint independently chooses how many
Expand Down