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

ACK and PADDING #1713

Merged
merged 1 commit into from Aug 31, 2018
Merged

ACK and PADDING #1713

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
22 changes: 11 additions & 11 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -3418,14 +3418,15 @@ ACK Block (repeated):
### Sending ACK Frames

Implementations MUST NOT generate packets that only contain ACK frames in
response to packets which only contain ACK frames. However, they MUST
acknowledge packets containing only ACK frames when sending ACK frames in
response to other packets. Implementations MUST NOT send more than one packet
containing only an ACK frame per received packet that contains frames other than
an ACK frame. Packets containing non-ACK frames MUST be acknowledged
immediately or when a delayed ack timer expires. The delayed ack timer MUST
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.
response to packets which only contain ACK and PADDING frames. However, they
MUST acknowledge packets containing only ACK and PADDING frames when sending
ACK frames in response to other packets. Implementations MUST NOT send more
than one packet containing only an ACK frame per received packet that contains
Copy link
Member

Choose a reason for hiding this comment

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

"containing only ACK or PADDING frames" ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To clarify, are you saying I should replace "ACK and PADDING" with "ACK or PADDING" everywhere or another suggestion?

Copy link
Member

Choose a reason for hiding this comment

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

Just the one instance here that you only have "ACK".

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we mention that Challenge and Challenge response frames have the same treatment? What about extension frames that would be defined using the extension mechanism?

Copy link
Contributor

Choose a reason for hiding this comment

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

@huitema there is already an issue open on extension frames #1487

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think only an ACK is most correct there. If you really wanted to send ACK and PADDING, that would count towards bytes in flight, and then congestion control is involved, which provides a different rate limit.

Copy link
Member

Choose a reason for hiding this comment

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

SGTM

frames other than a ACK and PADDING frames. Packets containing frames
besides ACK and PADDDING MUST be acknowledged immediately or when a delayed
ack timer expires. The delayed ack timer MUST NOT delay an ACK for longer
than an RTT or the alarm granularity. This ensures an ACK frame is sent at
least once per RTT if new packets needing acknowledgement were received.

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 All @@ -3437,9 +3438,8 @@ is only sending ACK frames will only receive acknowledgements for its packets
if the sender includes them in packets with non-ACK frames. A sender SHOULD
bundle ACK frames with other frames when possible.

Endpoints can only acknowledge packets sent in a particular packet
number space by sending ACK frames in packets from the same packet
number space.
Endpoints can only acknowledge packets sent in a particular packet number
space by sending ACK frames in packets from the same packet number space.

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