Re: Old packets in draft-ietf-quic-ack-frequency-11

[Martin Duke <[e-mail]>]

Compared to acking packets occasionally in accordance with
ack_eliciting_threshold.

On Thu, May 15, 2025 at 10:27 AM Mirja Kuehlewind <
[e-mail]> wrote:

> „accomplishes very little“ compared to what? Not acking is not an option
> and as such we simply apply the rule that is already in RFC9000 without
> further optimization. In other words we simply didn’t consider
> changing/optimizating the “gap filling” logic in the draft. I guess you
> could so something like only sending an ACK for the first packet in a gap
> and if the gap is filled completely but that sounds all complicated.
>
>
>
>
>
> *From: *Martin Duke <[e-mail]>
> *Date: *Thursday, 15. May 2025 at 18:06
> *To: *Mirja Kuehlewind <[e-mail]>
> *Cc: *Ian Swett <ianswett=[e-mail]>, IETF QUIC WG <
> [e-mail]>
> *Subject: *Re: Old packets in draft-ietf-quic-ack-frequency-11
>
>
>
> I agree that not sending acks at all would be a problem.
>
>
>
> I don't have any data. But my contention is that the current rule
> accomplishes very little while making this "not super likely" case
> considerably worse.
>
>
>
> On Thu, May 15, 2025 at 9:01 AM Mirja Kuehlewind <
> [e-mail]> wrote:
>
> 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=[e-mail]>
> *Date: *Thursday, 15. May 2025 at 17:34
> *To: *Martin Duke <[e-mail]>
> *Cc: *IETF QUIC WG <[e-mail]>, Ian Swett <ianswett=
> [e-mail]>
> *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 <[e-mail]>
> 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
>
>