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

Prohibit PADDING in response to ACK #3103

Closed
wants to merge 1 commit into from
Closed

Prohibit PADDING in response to ACK #3103

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
15 changes: 8 additions & 7 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2880,7 +2880,7 @@ packet.
expectations about what implementations do with packets that have errors after
valid frames? -->

### Sending ACK Frames
### Sending ACK Frames {#sending-ack-frames}

An endpoint sends ACK frames to acknowledge packets it has received and
processed.
Expand All @@ -2889,12 +2889,13 @@ Packets containing only ACK frames are not congestion controlled, so there are
limits on how frequently they can be sent. An endpoint MUST NOT send more than
one ACK-frame-only packet in response to receiving an ACK-eliciting packet
(one containing frames other than ACK and/or PADDING). An endpoint MUST NOT
send a packet containing only an ACK frame in response to a non-ACK-eliciting
packet (one containing only ACK and/or PADDING frames), even if there are
packet gaps which precede the received packet. Limiting ACK frames avoids an
infinite feedback loop of acknowledgements, which could prevent the connection
from ever becoming idle. However, the endpoint acknowledges non-ACK-eliciting
packets when it sends an ACK frame.
send a packet containing only an ACK frame, or only an ACK and PADDING frame,
in response to a non-ACK-eliciting packet (one containing only ACK and/or
PADDING frames), even if there are packet gaps which precede the received
packet. Limiting ACK frames avoids an infinite feedback loop of
acknowledgements, which could prevent the connection from ever becoming idle.
However, the endpoint acknowledges non-ACK-eliciting packets when it sends an
ACK frame.

Packets containing PADDING frames are considered to be in flight for congestion
control purposes {{QUIC-RECOVERY}}. Sending only PADDING frames might cause the
Expand Down