Draft: draft-ietf-quic-ack-frequency

Commentary: and provides two simple examples  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 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 does n'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 .  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 do n'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 .
As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are
expected to send an acknowledgement immediately on receiving a
reordered ack-eliciting packet.  This extension modifies this
behavior.
As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are
expected to send an acknowledgement immediately on receiving a
reordered ack-eliciting packet.  This extension modifies that
behavior when an ACK_FREQUENCY frame with a Reordering Threshold
value other than 1 is received.
The largest packet number among all received ack-eliciting
packets.
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.
If the most recent ACK_FREQUENCY frame received from the peer has a
"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
"max_ack_delay" thresholds for sending acknowledgements.
When the reordering threshold is 1, any time a packet is received and
there is a missing packet, an immediate ACK is sent.