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

A tiny nit: the ClientHello is not subject to MAX_STREAM_DATA. #803

Merged
merged 5 commits into from
Oct 10, 2017
Merged

A tiny nit: the ClientHello is not subject to MAX_STREAM_DATA. #803

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
fc31b7e
A tiny nit: the ClientHello is not subject to MAX_STREAM_DATA.
ekr Sep 28, 2017
617dc33
Nits from Jana
ekr Sep 28, 2017
8cf389d
Jana's comments plus bonus editorial fix
ekr Sep 29, 2017
4d99794
Reflow
martinthomson Oct 10, 2017
cbe9dbd
Merge branch 'master' into stream_0_flow_control_nit
martinthomson Oct 10, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 6 additions & 5 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2745,11 +2745,12 @@ limits.
An endpoint MUST NOT send data on any stream without ensuring that it is within
the data limits set by its peer. The cryptographic handshake stream, Stream 0,
is exempt from the connection-level data limits established by MAX_DATA. Data on
stream 0 other than the TLS ClientHello is still subject to stream-level data
limits and MAX_STREAM_DATA. The TLS ClientHello is exempt from flow control
because it needs to be sent in a single packet regardless of the server's flow
control state. This rule applies even for 0-RTT handshakes where the remembered
value of MAX_STREAM_DATA does not permit sending a full ClientHello.
stream 0 other than the initial cryptographic handshake message is still subject
to stream-level data limits and MAX_STREAM_DATA. This message is exempt
from flow control because it needs to be sent in a single packet regardless of
the server's flow control state. This rule applies even for 0-RTT handshakes
where the remembered value of MAX_STREAM_DATA would not permit sending a full
initial cryptographic handshake message.

Flow control is described in detail in {{flow-control}}, and congestion control
is described in the companion document {{QUIC-RECOVERY}}.
Expand Down