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

Rationalize stream 0 flow control #1083

Closed
wants to merge 4 commits into from
Closed

Rationalize stream 0 flow control #1083

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
adada50
Rationalize stream 0 flow control
martinthomson Jan 29, 2018
0bf027a
Updates in response to review
martinthomson Jan 30, 2018
2cf3d53
Contributing streams
martinthomson Jan 30, 2018
13ab8ad
More editorial feedback
martinthomson Jan 30, 2018
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
34 changes: 18 additions & 16 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3363,31 +3363,30 @@ one of the packets is lost.
Connection flow control is a limit to the total bytes of stream data sent in
STREAM frames on all streams. A receiver advertises credit for a connection by
sending a MAX_DATA frame. A receiver maintains a cumulative sum of bytes
received on all streams, which are used to check for flow control violations. A
receiver might use a sum of bytes consumed on all contributing streams to
determine the maximum data limit to be advertised.
received on all contributing streams (those other than stream 0), which are used
to check for flow control violations. A receiver might use a sum of bytes
consumed on all contributing streams to determine the maximum data limit to be
advertised.


### Stream 0 Flow Control
## Stream 0 Flow Control

The cryptographic handshake stream, Stream 0, is exempt from the
connection-level data limits established by MAX_DATA. That is, data sent on
stream 0 is not counted against the limit expressed by MAX_DATA. Data on stream
0 is still subject to stream-level data limits and MAX_STREAM_DATA.

Data sent in the Initial and Retry packets do not count toward stream 0 flow
control limits. These packet types do not permit the sending of data in
multiple packets, so there is no opportunity for a peer to send MAX_STREAM_DATA
frames. Note that sending a Retry causes stream offsets and flow control to be
reset for subsequent packets. Thus, the only limit on the size of the
cryptographic handshake messages these packets contain is determined by the MTU.
Data sent in the Initial and Retry packets are allowed to temporarily exceed
flow control limits on stream 0. These packet types do not permit the sending
of data in multiple packets, so there is no opportunity for a peer to send
MAX_STREAM_DATA frames. Note that sending a Retry causes stream offsets and
flow control to be reset for subsequent packets. Thus, the only limit on the
size of the cryptographic handshake messages these packets contain is determined
by the MTU.

Endpoints MUST respect the stream flow control limit set by their peer when
sending STREAM frames for stream 0 in packets other than Initial or Retry. A
client might exceed stream flow control limits when sending an Initial packet
and so might need to await a MAX_STREAM_DATA frame from the server before it can
sent additional STREAM frames. Endpoints MAY send STREAM_BLOCKED frames for
stream 0 if they are unable to send due to flow control limits.
A client might reach or exceed stream flow control limits when sending an
Initial packet and so might need to await a MAX_STREAM_DATA frame from the
server before it can send additional STREAM frames.

Flow control for stream 0 is reset after the handshake is completed. The limit
is set to the greater of the initial_max_stream_data transport parameter and
Expand All @@ -3396,6 +3395,9 @@ that sent in Retry and any Initial packet that caused a Retry packet to be
sent). This prevents an attacker from modifying an unauthenticated
MAX_STREAM_DATA frame to inflate the flow control limit.

Endpoints MAY send STREAM_BLOCKED frames for stream 0 in Handshake packets if
they are unable to send due to flow control limits.


## Edge Cases and Other Considerations

Expand Down