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

Clarify flow control issues on stream 0 #1082

Merged
merged 5 commits into from Feb 2, 2018
Merged

Clarify flow control issues on stream 0 #1082

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
33d62fc
Clarify flow control issues on stream 0
MikeBishop Jan 29, 2018
2fa05ac
Really, not zero
MikeBishop Jan 29, 2018
eca60b8
Extract amplification mitigation
MikeBishop Feb 1, 2018
26521a1
Clarify handshake exemption
MikeBishop Feb 1, 2018
ee3909c
Just to be perfectly clear....
MikeBishop Feb 1, 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
27 changes: 13 additions & 14 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -650,11 +650,6 @@ described in {{packet-numbers}}. The client increments the packet number from
its previous packet by one for each Handshake packet that it sends (which might
be an Initial, 0-RTT Protected, or Handshake packet).

Servers MUST NOT send more than three Handshake packets in response to a
client's Initial packet without validating the client's ownership of the
address, either via a Retry packet or by receiving packets from the client
in response to the server's Handshake packets.

The payload of this packet contains STREAM frames and could contain PADDING and
ACK frames.

Expand Down Expand Up @@ -3433,15 +3428,19 @@ implementations.

### Handshake Exemption

During the initial handshake, a server could need to send a larger message than
would ordinarily be permitted by the client's initial stream flow control
window. Since MAX_STREAM_DATA frames are not permitted in Handshake packets, the
client cannot respond to server requests for additional flow control window in
order to complete the handshake.

Servers MAY exceed the flow control limits on stream 0 prior to the completion
of the cryptographic handshake. However, once the handshake is complete,
servers MUST NOT send data beyond the client's permitted offset.
During the initial handshake, an endpoint could need to send a larger message on
stream 0 than would ordinarily be permitted by the peer's initial stream flow
control window. Since MAX_STREAM_DATA frames are not permitted in these early
packets, the peer cannot provide additional flow control window in order to
complete the handshake.

Endpoints MAY exceed the flow control limits on stream 0 prior to the completion
of the cryptographic handshake. (That is, in Initial, Retry, and Handshake
packets.) However, once the handshake is complete, endpoints MUST NOT send
additional data beyond the peer's permitted offset. If the amount of data sent
during the handshake exceeds the peer's maximum offset, the endpoint cannot send
additional data until the peer has sent a MAX_STREAM_DATA frame indicating a
larger maximum offset.

## Stream Limit Increment

Expand Down