These are some excellent observations and please file an issue. I'm not sure we want to make substantial changes, but we might want to at least call this out.
If the peer is accurately communicating their packet threshold in the ACK_FREQUENCY frame, then I believe you're correct that this requirement to immediately send an ACK is useless, at least for the purposes of packet threshold loss detection. Time threshold is much more difficult to reason about, particularly because transmission delays are variable and timers aren't perfect. Currently the peer's ack delay is included in PTO timer, but not time threshold loss detection, because this immediate ACK behavior is assumed. There are some potential interactions with congestion control, particularly when first entering recovery when the CWND might have decreased substantially and/or you're doing packet conservation. You might be able to declare a number of packets lost, but only send one or two, so getting an ACK earlier could prevent some spurious retransmissions. Or it might not because the ACKs you're getting might be exactly the packets you've already spuriously retransmitted. Thanks, Ian On Thu, May 15, 2025 at 10:37 AM Martin Duke <[email protected]> wrote: > I'm finally turning my attention to updating our ack-frequency > implementation from draft-iyengar-quic-delayed-ack-01 (!!!) to the current > draft. > > *TL;DR **The ack-frequency draft defers to RFC 9000 by saying that any > packet < largest_acked is acked immediately regardless of any of the > ACK_FREQUENCY frame fields. Maybe that's suboptimal?* > > I stumbled across issue 304 > <https://github.com/quicwg/ack-frequency/issues/304>, which clarifies > that RFC 9000 rules about ACKing packets < largest_acked still apply: > > When an ack-eliciting packet is received with a packet number less than >> Largest Acked, this still triggers an immediate acknowledgement in an >> effort to avoid the packet being spuriously declared lost. > > > To be clear: this totally works, and in no case makes things worse than > the baseline. In the "normal" case when packet gaps are loss, not > reordering, it has no effect at all. > > However, I wonder if this rule is far less than optimal in cases with a > lot of reordering, and may add little to no value in more common cases. > Loss and reordering both manifest as a sudden jump in sequence number; if a > reordering case, the gap packets will arrive later. The reordering_thresh > field can suppress the ack of this first jump, but not the followon packets > with lower numbers. > > For example, Say that ack_eliciting_threshold is 1 (the default) but > reordering_threshold is zero (meaning, ignore reordering). If the pattern > of packet arrival is 10, 11, 1, 2, 3, 4, 5, 6, 7, 8, 9, then there will be > 10 ACKs: one for 11, as the second packet to arrive, and then one for each > of 1:9 because they are all less than largest_acked. In this case, network > reordering has caused the ack rate to be roughly double what the receiver > requested. Without the text in question, one would expect an ack for 11, 2, > 4, 6, and 8. > > In the issue, the stipulation is that acking these packets will prevent > spurious retransmits. If true, that would be valuable. However: > > - If the sender is using RFC 9002 time-based recovery, the important thing > is that the ack arrives before the timeout. IIUC, this is best ensured via > requested_max_ack_delay rather than through this mechanism. > > - If the sender is using packet-based recovery, the additional acks don't > really help. If ack_eliciting_threshold is set correctly, there won't be a > retransmission until another ACK arrives. If the ACK is delayed till > another packet arrives, the sender's state for the early packet won't > change in the meantime. > > I find this hard to reason about, and am happy to be told I'm holding it > wrong. There are second-order considerations about lost acks, etc. But if > others think the text is suboptimal, I'm happy to file an issue. > > Martin >
