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.

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

Split WINDOW_UPDATE #443

Closed
martinthomson opened this issue Apr 18, 2017 · 0 comments
Closed

Split WINDOW_UPDATE #443

martinthomson opened this issue Apr 18, 2017 · 0 comments
Assignees
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@martinthomson
Copy link
Member

The current design has a special carve-out for stream 0, but special semantics for it.

If we split this into two different frame types, we avoid having special logic for the scaling of the connection-level window AND we can reclaim stream 0.

That leads to the possibility of using stream 0 for crypto, stream 1 for HTTP control.

@martinthomson martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Apr 18, 2017
@martinthomson martinthomson self-assigned this Apr 18, 2017
martinthomson added a commit that referenced this issue Apr 20, 2017
This also changes the name of the LIMIT_UPDATE frame to MAX_STREAM_ID to match.

A lot of the text talked about stream offsets and had flow control affect
maximum stream offsets.  This turned out to be unnecessarily obtuse.  The text
in this changeset simply says that there is a limit to the amount of data that
can be sent.  This turns out to be a lot of changes, but I think that it is
easier to understand as a result.

Closes #443.
martinthomson added a commit that referenced this issue Apr 21, 2017
This also changes the name of the LIMIT_UPDATE frame to MAX_STREAM_ID to match.

A lot of the text talked about stream offsets and had flow control affect
maximum stream offsets.  This turned out to be unnecessarily obtuse.  The text
in this changeset simply says that there is a limit to the amount of data that
can be sent.  This turns out to be a lot of changes, but I think that it is
easier to understand as a result.

Closes #443.
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Sep 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Development

No branches or pull requests

2 participants