Reordering in initial paragraph of Sending Acknowledgments
Closed this issue · 8 comments
The initial text on Sending Acknowledgements does not discuss the reordering threshold. Even if it in practice also needs to be updated based on the value received. The reorder threshold also do not change either of the bulleted reasons for sending ACK. Thus, 6.2 is also not an exception to the rules. If just provides an additional rule.
I think some consideration for how reordering is handled in this section. I think it should be listed as one that is being updated on receiving and that it a third criteria for acking that needs to be accounted for.
Not sure if it really matter if it is called an "exception" or an "additional rule". I think the same is true for section 6.4.
The original intention was to described the "regular behaviour" in alignment with 13.2.1. Sending ACK Frames of RFC9000.
The regular behavior for reordering is this:
From Section 13.2.1 of RFC 9000:
when the packet has a packet number larger than the highest-numbered ack-eliciting packet that has been received and there are missing packets between that packet and this packet.
That behavior as also described in 6.2 the reordering behavior is changed. However, this clearly does not mandate a criteria for when to send an ACK, instead it suppresses an ack. I think it is worth being clear here that Reordering Threshhold is modifying the behavior. I think that should be clearer rather than the additional rules given in 6.4 and 6.5. Thus I suggest something like this for this paragraphs:
On receiving an ACK_FREQUENCY frame and updating its
max_ack_delayand
Ack-Eliciting Threshold` values ({{ack-frequency-frame}}), the endpoint sends an
acknowledgment when one of the following conditions are met:
-
Since the last acknowledgment was sent, the number of received ack-eliciting
packets is greater than theAck-Eliciting Threshold
. -
Since the last acknowledgment was sent,
max_ack_delay
amount of time has
passed.
The 'Reordering Threshold' impacts the immediate acking when encountering a missing packet by requiring more missing packets before acking (Threshold > 1) or turns off immediate acking to missing packets (Threshold = 0), see {{out-of-order}}. {{congestion}}, and {{batch}} describe exceptions to this strategy.
`
No this is actually not correct. The Reordering threshold will never suppress an ACK. It might only lead to additional ACKs if the ack frequency is otherwise too low.
Well compared to threshold = 1 it will at least delay the ack or fall back to other triggers of ACKs that may not trigger an ACK at a given packet reception. Is that not suppressing of a trigger at least?
not sure which threshold you are talking about now but if you set a reordering threshold that is larger than the ack-eliciting threshold it will have no impact.
The reordering threshold larger than ack-eliciting threshold has no effect if I understand things correct. My point is that if one sets the reordering threshold to something else than 1, then one is changing the behavior compared to RFC 9000, and ACK that would be sent in response to reordering for threshold = 1 would not be sent for threshold = 3 for example, assuming ack-eliciting > 3. My issue with the text is simply that you current text is poor at making the reader aware that also the reordering threshold can change the normal behavior both to reordering, as well as potentially to what might be loss.
Okay, got it. Yes, I guess we can add one more sentence there.