Packets containing only ACK frames are not congestion controlled, so there are limits on how frequently the can be sent. An endpoint MUST NOT send more than one packet containing only an ACK frame per received 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. This prevents an indefinite feedback loop of acknowledgements, which may prevent the connection from ever becoming idle. The endpoint MUST however acknowledge non-ACK-eliciting packets when sending ACK frames in response to other packets.
+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 packet containing only an ACK frame per received 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. This prevents an indefinite feedback loop of acknowledgements, which may prevent the connection from ever becoming idle. The endpoint MUST however acknowledge non-ACK-eliciting packets when sending ACK frames in response to other packets.
Packets containing PADDING frames are considered to be in flight for congestion control purposes [QUIC-RECOVERY]. Sending only PADDING frames might cause the sender to become limited by the congestion controller (as described in [QUIC-RECOVERY]) with no acknowledgments forthcoming from the receiver. Therefore, a sender SHOULD ensure that other frames are sent in addition to PADDING frames to elicit acknowledgments from the receiver.
The receiver’s delayed acknowledgment timer SHOULD NOT exceed the current RTT estimate or the value it indicates in the max_ack_delay transport parameter. This ensures an acknowledgment is sent at least once per RTT when packets needing acknowledgement are received. The sender can use the receiver’s max_ack_delay value in determining timeouts for timer-based retransmission.
Strategies and implications of the frequency of generating acknowledgments are discussed in more detail in [QUIC-RECOVERY].
diff --git a/ianswett-ack-ack/draft-ietf-quic-transport.txt b/ianswett-ack-ack/draft-ietf-quic-transport.txt index 888c761cb6..2c2ea8ea44 100644 --- a/ianswett-ack-ack/draft-ietf-quic-transport.txt +++ b/ianswett-ack-ack/draft-ietf-quic-transport.txt @@ -3825,8 +3825,8 @@ Internet-Draft QUIC Transport Protocol June 2019 13.1.1. Sending ACK Frames Packets containing only ACK frames are not congestion controlled, so - there are limits on how frequently the can be sent. An endpoint MUST - NOT send more than one packet containing only an ACK frame per + there are limits on how frequently they can be sent. An endpoint + MUST NOT send more than one packet containing only an ACK frame per received 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 diff --git a/index.html b/index.html index 8cb6b02533..baa570cf1a 100644 --- a/index.html +++ b/index.html @@ -73,1316 +73,1243 @@