Change:
As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are expected to send an acknowledgement immediately on receiving a <del> reordered ack-eliciting packet.  This extension modifies this behavior. </del> <ins> reordered ack-eliciting packet.  This extension modifies that behavior when an ACK_FREQUENCY frame with a Reordering Threshold value other than 1 is received. </ins> <del> In order to ensure timely loss detection, the Reordering Threshold provided in the ACK_FREQUENCY frame SHOULD NOT be larger than the re- ordering threshold used by the data sender for loss detection. (Section 18.2 of QUIC-RECOVERY) recommends a default packet threshold for loss detection of 3. </del> <ins> The largest packet number among all received ack-eliciting packets. </ins> <del> An endpoint, that receives an ACK_FREQUENCY frame with a Reordering Threshold value other than 0x00, SHOULD immediately send an ACK frame when the packet number of largest unacknowledged packet since the last detected reordering event exceeds the Reordering Threshold. </del> <ins> The Largest Acknowledged value sent in an ACK frame. Packets with packet numbers between the Largest Unacked and Largest Acked that have not yet been received. An endpoint that receives an ACK_FREQUENCY frame with a non-zero Reordering Threshold value SHOULD send an immediate ACK when the gap between the smallest Unreported Missing packet and the Largest Unacked is greater than or equal to the Reordering Threshold value. In order to ensure timely loss detection, it is optimal to send a Reordering Threshold value of 1 less than the packet threshold used by the data sender for loss detection.  If the threshold is smaller, an ACK_FRAME is sent before the packet can be declared lost based on the packet threshold.  If the value is larger, it causes unnecessary delays.  (Section 18.2 of QUIC-RECOVERY) recommends a default packet threshold for loss detection of 3, equivalent to a Reordering Threshold of 2. </ins> If the most recent ACK_FREQUENCY frame received from the peer has a <del> "Reordering Threshold" value of 0x00, the endpoint does not make this exception.  That is, the endpoint SHOULD NOT send an immediate acknowledgement in response to packets received out of order, and instead continues to use the peer's "Ack-Eliciting Threshold" and </del> <ins> "Reordering Threshold" value of 0, the endpoint SHOULD NOT send an immediate acknowledgement in response to packets received out of order, and instead rely on the peer's "Ack-Eliciting Threshold" and </ins> "max_ack_delay" thresholds for sending acknowledgements. <ins> 6.1.1. When the reordering threshold is 1, any time a packet is received and there is a missing packet, an immediate ACK is sent. If the reordering theshold is 3 and ACKs are only sent due to reordering: Receive 1 Receive 3 -> 2 Missing Receive 4 -> 2 Missing Receive 5 -> Send ACK because of 2 Receive 8 -> 6,7 Missing Receive 9 -> Send ACK because of 6, 7 Missing Receive 10 -> Send ACK because of 7 If the reordering threshold is 5 and ACKs are only sent due to reordering: Receive 1 Receive 3 -> 2 Missing Receive 5 -> 2 Missing, 4 Missing Receive 6 -> 2 Missing, 4 Missing Receive 7 -> Send ACK because of 2, 4 Missing Receive 8 -> 4 Missing Receive 9 -> Send ACK because of 4 </ins> 6.2. An endpoint SHOULD send an immediate acknowledgement when a packet

Discussion:
and provides two simple examples Written as an alternative to
This PR still does not clarify if the re-ordering threshold only sends one additional ACK (and only if the there was no earlier ACK send because of other thresholds or timers) or if the intention is to frequently send ACK as long as the re-ordering exists. I believe the former would be in line with RFC9000. Let discuss this first in issue and then make sure this is clear in the PR.
The intent is to send at most one extra ACK for each missing packet, but let me know if I've made a mistake.
I just added another example for a reordering threshold of 5 in case that helps clarify.
We merged PR but without much text about how exactly the reordering threshold needs to be applied. Based on the amount of discussion in that PR, this will need further clarification.
Actually I realised that the use of the Reordering threshold is not fully clear to me. The intention is to not delay an ACK unnecessarily when loss happen. However, the data sender will not declare a packet as lost before the reordering threshold is reached, which means it doesn't help to send a packet earlier that this. Then, the whole idea of the ack frequency draft is to reduce the ACK rate. So in case of loss I guess there are two options. In both cases you send an ACK when the re-ordering threshold is reached but the question is what to do afterwards. Do you want to keep sending ACKs for all packet you receive (immediately) while loss event is on-going (until the gap is filed) to ensure that the loss info is delivered or you go back to your old ack schedule. RFC9000 says: This means you only send one additional ACK as then the highest-numbered ack-eliciting packet is after the gap as soon as you have sent the ACK. Given gaps can also be created by the data sender which means there are not lost packets and therefore will never be filled, I don't think any other behaviour makes sense for QUIC. I created PR to clarify this. There might be still some word-smithing needed but it would be good if people could confirm this understanding.
The intent is to send an ACK immediately when any missing packets reach the threshold (and presumably can be declared lost). As such, you'd send at most one additional ACK for each missing packet.