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

MAX_DATA/MAX_STREAM_DATA will also solicit an ACK #478

Merged
merged 2 commits into from May 3, 2017
Merged
Changes from all commits
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
9 changes: 6 additions & 3 deletions draft-ietf-quic-transport.md
Expand Up @@ -1384,9 +1384,12 @@ packets.
To limit ACK blocks to those that have not yet been received by the sender, the
receiver SHOULD track which ACK frames have been acknowledged by its peer. Once
an ACK frame has been acknowledged, the packets it acknowledges SHOULD not be
acknowledged again. To handle cases where the receiver is only sending ACK
frames, and hence will not receive acknowledgments for its packets, it MAY send
a PING frame at most once per RTT to explicitly request acknowledgment.
acknowledged again.

A receiver that is only sending ACK frames will not receive acknowledgments for
its packets. Sending an occasional MAX_DATA or MAX_STREAM_DATA frame as data is
received will ensure that acknowledgements are generated by a peer. Otherwise,
an endpoint MAY send a PING frame once per RTT to solicit an acknowledgment.

To limit receiver state or the size of ACK frames, a receiver MAY limit the
number of ACK blocks it sends. A receiver can do this even without receiving
Expand Down