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

Restructure packetization section #985

Merged
merged 7 commits into from
Dec 13, 2017
Merged
Changes from 1 commit
Commits
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
18 changes: 9 additions & 9 deletions draft-ietf-quic-transport.md
Original file line number Diff line number Diff line change
Expand Up @@ -2776,22 +2776,22 @@ actually lost.

### Special Considerations for Packetization Layer PMTU Discovery

The PADDING frame provides a useful option for PMTU probe packets that does
not exist in other transports. PADDING frames generate acknowledgements, but
their content need not be delivered reliably. PADDING frames may delay the
delivery of application data, as they consume the congestion window. However,
by definition their likely loss in a probe packet does not require delay-
inducing retransmission of application data.

The PADDING frame provides a useful option for PMTU probe packets that does not
exist in other transports. PADDING frames generate acknowledgements, but their
content need not be delivered reliably. PADDING frames may delay the delivery of
application data, as they consume the congestion window. However, by definition
their likely loss in a probe packet does not require delay- inducing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eliminate space after dash.

retransmission of application data.

When implementing the algorithm in Section 7.2 of {{!RFC4821}}, the initial
value of search_low SHOULD be consistent with the IPv6 minimum packet size.
Paths that do not support this size cannot deliver Initial packets, and
therefore are not QUIC-compliant.

Section 7.3 of {{!RFC4821}} discusses tradeoffs between small and large
increases in the size of probe packets. As QUIC probe packets need not
contain application data, aggressive increases in probe size carry fewer
consequences.
increases in the size of probe packets. As QUIC probe packets need not contain
application data, aggressive increases in probe size carry fewer consequences.


# Streams: QUIC's Data Structuring Abstraction {#streams}
Expand Down