Note that issue #306 was also related to this: https://github.com/quicwg/ack-frequency/issues/306
As I said there, you could probably further optimize this but it would be a mistake if you don’t send ACK for packets that arrive late at all (which wasn’t clearly explicitly covered in the draft before). However, I think your example below is also not the super likely case. In your examples it’s basically that packets 10 and 11 arrive earlier, while a whole range of packets would get delayed. So not sure how important it is to optimize for that case. I would expect it is more likely to see single packets re-ordered. Do you happen to have any data on re-ordering patterns? Mirja From: Ian Swett <ianswett=40google....@dmarc.ietf.org> Date: Thursday, 15. May 2025 at 17:34 To: Martin Duke <martin.h.d...@gmail.com> Cc: IETF QUIC WG <quic@ietf.org>, Ian Swett <ianswett=40google....@dmarc.ietf.org> Subject: Re: Old packets in draft-ietf-quic-ack-frequency-11 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 <martin.h.d...@gmail.com<mailto:martin.h.d...@gmail.com>> 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
