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 handshake packets #535

Merged
merged 2 commits into from May 17, 2017
Merged
Changes from 1 commit
Commits
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
6 changes: 3 additions & 3 deletions draft-ietf-quic-recovery.md
Expand Up @@ -98,8 +98,8 @@ important to the loss detection and congestion control machinery below.
* Retransmittable frames are frames requiring reliable delivery. The most
common are STREAM frames, which typically contain application data.

* Crypto handshake data is sent as STREAM data on stream 0, and uses the
reliability machinery of QUIC underneath.
* Crypto handshake data is sent on stream 0, and uses the reliability
machinery of QUIC underneath.

* ACK frames contain acknowledgment information. QUIC uses a SACK-based
scheme, where acks express up to 256 ranges. The ACK frame also includes a
Expand Down Expand Up @@ -196,7 +196,7 @@ An unacknowledged QUIC packet is marked as lost in one of the following ways:
lost when a packet larger than it is acknowledged and a threshold amount of
time has passed since the packet was sent.

* Handshake packets, which contain stream frames for stream 0, are
* Handshake packets, which contain STREAM frames for stream 0, are
critical to QUIC transport and crypto negotiation, so a separate alarm
period is used for them.

Expand Down