Retransmitting an ACK frame warning #3049
Conversation
It can result in an inflated RTT, as well as being a waste of bytes. Fixes #2748
ianswett
added
editorial
draft-ietf-quic-transport.md
Outdated
| @@ -3183,7 +3183,8 @@ containing that information is acknowledged. | |||
|
|
|||
| * The most recent set of acknowledgments are sent in ACK frames. An ACK frame | |||
| SHOULD contain all unacknowledged acknowledgments, as described in | |||
| {{sending-ack-frames}}. | |||
| {{sending-ack-frames}}. Retransmitting an ACK frame can result in an | |||
There was a problem hiding this comment.
This para is not great. That second sentence totally doesn't belong here. Suggested rewrite:
"ACK frames carry the most recent set of acknowledgements and the current Ack Delay estimate. Retransmitting an old ACK frame with stale Ack Delay can cause the peer to generate an inflated RTT sample."
Then in 13.2.1 (sending-ack-frames), add this as the first paragraph:
"ACK frames SHOULD acknowledge both ack-eliciting and non-ack-eliciting packets that have been received but not yet acknowledged."
There was a problem hiding this comment.
There is already text that says "When only non-ACK-eliciting packets need to be acknowledged, an endpoint MAY wait until an ACK-eliciting packet has been received to bundle an ACK frame with outgoing frames." I'm not sure that's sufficient, but your suggestion adds a SHOULD, which makes this change no longer editorial. The ACK generation text needs a full rewrite, and I'd rather tackle that suggestion as part of that PR.
There was a problem hiding this comment.
I worked part of your first suggestion in.
The latter suggestion is now present(from a different PR).
draft-ietf-quic-transport.md
Outdated
| * ACK frames are sent containing the most recent set of acknowledgements and | ||
| Ack Delay, as described in {{sending-ack-frames}}. Retransmitting an old ACK | ||
| frame with stale Ack Delay can cause the peer to generate an inflated RTT | ||
| sample. |
There was a problem hiding this comment.
Here's my alternative:
ACK frames always contain an acknowledgement for the highest packet number that has been processed and an Ack Delay that is updated to the time that the packet is sent. Note that delaying the transmission of packets containing ACK frames or sending copies of old ACK frames will cause problems for a peer, including inflated RTT estimates or unnecessary disabling of ECN.
There was a problem hiding this comment.
I took part of this, but the first statement is incorrect: ACK frames do not have to contain the highest packet number that has been processed(there was an issue about this).
It can result in an inflated RTT, as well as being a waste of bytes.
Fixes #2748