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

clarify how to handle in increase in initial_max_{stream_}data_{uni, bidi} #4834

Closed
marten-seemann opened this issue Mar 12, 2021 · 3 comments · Fixed by #4835
Closed

clarify how to handle in increase in initial_max_{stream_}data_{uni, bidi} #4834

marten-seemann opened this issue Mar 12, 2021 · 3 comments · Fixed by #4835
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@marten-seemann
Copy link
Contributor

If the client has opened a stream in 0-RTT with initial_max_stream_data_uni = N, and the server increases initial_max_stream_data_uni to M, does this apply to this stream as well, or only to streams opened after handshake completion?

Consensus in Slack seems to be that the limit should apply to all streams. The text should be explicit about that.

@kazuho
Copy link
Member

kazuho commented Mar 12, 2021

Isn't that already clear enough? Section 7.4.1 of the transport draft states:

Remembered transport parameters apply to the new connection until the handshake completes and the client starts sending 1-RTT packets. Once the handshake completes, the client uses the transport parameters established in the handshake.

@marten-seemann
Copy link
Contributor Author

@kazuho This is what the definition of the TP says:

initial_max_stream_data_bidi_remote (0x06): This parameter is an integer value specifying the initial flow control limit for peer-initiated bidirectional streams. This limit applies to newly created bidirectional streams opened by the endpoint that receives the transport parameter.

Arguably, the stream used in 0-RTT is not a "newly created" stream.

@martinthomson
Copy link
Member

Yeah, let's just be really clear about this. Though @kazuho quotes the section that is most important, this has proven to be a mistake common enough to spend text on.

@martinthomson martinthomson added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Mar 12, 2021
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Mar 12, 2021
Late Stage Processing automation moved this from Editorial Issues to Issue Handled Mar 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing
  
Issue Handled
Development

Successfully merging a pull request may close this issue.

4 participants