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

Add max_bytes_before_ack to transport #1715

Closed
wants to merge 3 commits into from
Closed

Add max_bytes_before_ack to transport #1715

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
98961b0
Add max_bytes_before_ack to transport
ianswett Aug 30, 2018
110e7ec
Update draft-ietf-quic-transport.md
ianswett Aug 30, 2018
6978efe
Update draft-ietf-quic-transport.md
ianswett Aug 30, 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
7 changes: 5 additions & 2 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -3434,8 +3434,11 @@ NOT delay an ACK for longer than an RTT, which ensures an ACK frame is sent
at least once per RTT if new packets needing acknowledgement were received.

If the max_bytes_before_ack transport parameter has been received, the
receiver SHOULD send an ACK frame immediately once that many octets of packets
containing frames besides ACK or PADDING have been received.
receiver SHOULD send an ACK frame immediately when at least that many octets
of packets containing frames besides ACK or PADDING have been received since
sending the previous ACK frame. If a receiver sends ACK frames less frequently,
it risks causing the sender to send more slowly, which may lower the delivery
rate at the receiver.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is not free. It comes in addition to existing logic which is already designed to prevent sender starvation. It requires at least one additional counter in the connection state, i.e., "max bytes sent at the last ACK time", and of course additional tests in the ACK sending logic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed, but it is simple to implement.

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
Expand Down