jiebi/TextFlow huggingface dataset:
Original text:
out-of-order, congestion, and batch describe exceptions to this strategy. <del> An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all counters and timers related to delaying of acknowledgments are reset. The receiver of an ACK_FREQUENCY frame can continue to process multiple available packets before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. </del> 7.1. As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are to be sent. To avoid sending multiple acknowledgements in rapid succession, an <del> endpoint MAY process all packets in a batch before determining whether a threshold has been met and an acknowledgement is to be sent in response. </del>  8.

Reviewer comments:
Also moves text about batch processing of packets into an existing section.
Section 7 "Sending Acknowledgments" says: I'm not sure what this means... like sending the same ACK twice in the same QUIC packet? Or generally sending two different ACK frames in the same QUIC packet? Does that really make sense in any case? Can't you always just send the more recent ACK or create one combined ACK frame with all information?

Revised text:
out-of-order, congestion, and batch describe exceptions to this strategy.  7.1. As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are to be sent. To avoid sending multiple acknowledgements in rapid succession, an  <ins> endpoint can process all packets in a batch before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. </ins> 8.
Original text:
intensive, and reducing acknowledgement frequency reduces this cost at a data sender. <del> For severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the forward path can become constrained when the reverse path is filled by acknowledgment packets.  When traversing such links, reducing the number of acknowledgments can achieve higher connection throughput. </del>  The rate of acknowledgment packets can impact link efficiency, <del> including transmission opportunities or battery life. </del>  As discussed in implementation however, there can be undesirable consequences to congestion control and loss recovery if a receiver

Reviewer comments:
This is an alternative to with the intent of fixing
There's a concrete example of one way you can arrange ACKs that has benefit in: URL This likely helps in many common scenarios. We could make a pull-request based on summarising some of this into an annexe?
Gorry -- can you point to the concrete example in the draft? I couldn't find it. Generally, I'd prefer not to spend a lot more text in the draft motivating its value; I think we've got enough in Section 2 already.
What I was hoping for was something that unpicks a little how an ACK Ratio of (say) 10 (8 if we prefer, ?) impacts the traffic. I don't see the draft body needing to specify numbers, but I know there is experience by some implementations with this approach, so a short (<1 page) explanation might be good guidance for anyone who has not worked out something better ... but I'd prefer it to be in an annexe, because such things can, and will, change as well as new CCs emerging that can have new requirements, etc.
Discussion at IETF 114: Don't need to fix. (Do we need to write some better guard rails?)
I motivated at IETF-114 that we should be able to construct an example based on this.... and that a least that would give use some guard rails to guide use.
We now merged PR which adds the references as proposed in PR . We will close this issue for now. Please open a new issue if there is something left that needs to be further addressed!

Revised text:
intensive, and reducing acknowledgement frequency reduces this cost at a data sender.  <ins> For asymmetric link technologies, such as DOCSIS, LTE, and satellite, connection throughput in the forward path can become constrained when the reverse path is filled by acknowledgment packets RFC3449.  When traversing such links, reducing the number of acknowledgments can achieve higher connection throughput, lower the impact on other flows or optimise the overall use of transmission resources Cus22. </ins> The rate of acknowledgment packets can impact link efficiency,  <ins> including transmission opportunities or battery life, as well as transmission opportunities available to other flows sharing the same link. </ins> As discussed in implementation however, there can be undesirable consequences to congestion control and loss recovery if a receiver
Original text:
packets into the network.  If a sender is designed to rely on the timing of peer acknowledgments ("ACK clock"), delaying acknowledgments can cause undesirable bursts of data into the <del> network.  A sender MUST limit such bursts.  In keeping with Section 7.7 of QUIC-RECOVERY, a sender can either employ pacing or cause a receiver to send an acknowledgement for at least each initial congestion window of received data. </del>  8.3.

Reviewer comments:
Another attempt to Removes an unnecessary MUST.
This draft says: RFC9002 only has a SHOULD on pacing. Is it appropriate to change this require in this draft? If not, no normative language should be used here at all.

Revised text:
packets into the network.  If a sender is designed to rely on the timing of peer acknowledgments ("ACK clock"), delaying acknowledgments can cause undesirable bursts of data into the  <ins> network.  In keeping with Section 7.7 of QUIC-RECOVERY, a sender can either employ pacing or limit bursts to the initial congestion window. </ins> 8.3.
Original text:
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

Reviewer comments:
This clarification is not necessarily needed but I think it would help me. Just a proposal...

Revised text:
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. <ins> Sending this additional ACK will reset the "max_ack_delay" timer and "Ack-Eliciting Threshold" counter as any ACK would do. </ins> In order to ensure timely loss detection, it is optimal to send a Reordering Threshold value of 1 less than the packet threshold used
Original text:
On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO) <del> period; see Section 5.2.1 of QUIC-RECOVERY.  The endpoint MUST however wait until the ACK_FREQUENCY frame that carries this new value is acknowledged by the peer. </del>  Until the frame is acknowledged, the endpoint MUST use the greater of the current "max_ack_delay" and the value that is in flight when

Reviewer comments:
Not sure I fully understand why this is unnecessary.
The following paragraph has a MUST that I believe makes this one redundant. Thoughts?
Ah, maybe.
The text says: /The endpoint MUST however wait until the ACKFREQUENCY frame that carries this new value is acknowledged by the peer./ I found this a little hard on the reader, could this be easier to read as: /The endpoint MUST however wait for an acknowledgment by the peer of the ACKFREQUENCY frame that carries this new value./ and then I ask what does MUST mean here as a requirement to wait? I suspect it would be covered by saying /The endpoint needs to wait.../, because I suspect the required action is specified in the next para.
Yes, actually there is a mother MUST in the next sentence: So I think it would probably be better to remove the normative language in this sentence. As we are taking about changing normative language, I will label this as design now, but I think it otherwise mostly editorial.

Revised text:
On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO)  <ins> period; see Section 5.2.1 of QUIC-RECOVERY. </ins> Until the frame is acknowledged, the endpoint MUST use the greater of the current "max_ack_delay" and the value that is in flight when
Original text:
do not elicit an immediate ACKs. ACK_FREQUENCY frames are ack-eliciting.  When an ACK_FREQUENCY frame <del> is lost, it is encouraged to send another ACK_FREQUENCY frame, unless an ACK_FREQUENCY frame with a larger Sequence Number value has already been sent.  However, it is not forbidden to retransmit the lost frame (see Section 13.3 of QUIC-TRANSPORT), as the receiver will ignore duplicate or out-of-order ACK_FREQUENCY frames based on the Sequence Number. </del>  An endpoint can send multiple ACK_FREQUENCY frames with different values within a connection.  A sending endpoint MUST send

Reviewer comments:
This adds a SHOULD, but it seems sensible given the implications on PTO.
I thought we purposefully decided to not use normative language here.
I think we were trying to avoid normative language, though I can't remember why? But in practice, it probably doesn't matter, so I can remove the SHOULD.
ACKFREQUENCY frames are ack-eliciting. When an ACKFREQUENCY frame is lost, it is encouraged to send another ACKFREQUENCY frame, unless an ACKFREQUENCY frame with a larger Sequence Number value has already been sent. Is /it/ the sender?

Revised text:
do not elicit an immediate ACKs. ACK_FREQUENCY frames are ack-eliciting.  When an ACK_FREQUENCY frame  <ins> is lost, the sender is encouraged to send another ACK_FREQUENCY frame, unless an ACK_FREQUENCY frame with a larger Sequence Number value has already been sent.  However, it is not forbidden to retransmit the lost frame (see Section 13.3 of QUIC-TRANSPORT), as the receiver will ignore duplicate or out-of-order ACK_FREQUENCY frames based on the Sequence Number. </ins> An endpoint can send multiple ACK_FREQUENCY frames with different values within a connection.  A sending endpoint MUST send
Original text:
there is a missing packet, an immediate ACK is sent. If the reordering theshold is 3 and ACKs are only sent due to <del> 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 " </del>  If the reordering threshold is 5 and ACKs are only sent due to <del> 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 " </del>  6.2.

Reviewer comments:
apparently not...
Yeah unfortunately this ain't regular markdown, tilde is needed to instruct the RFC tooling of the correct artwork type (which, FYI, you can theoretically tweak with additional labels but that you shouldn't need here).
Aren't backticks and tildes equivalent? Either way, this looks fine.

Revised text:
there is a missing packet, an immediate ACK is sent. If the reordering theshold is 3 and ACKs are only sent due to  <ins> reordering: </ins> If the reordering threshold is 5 and ACKs are only sent due to  <ins> reordering: </ins> 6.2.
Original text:
Starting a connection up quickly without inducing excess queue is important for latency reduction, for both short and long flows. <del> The sender often needs frequent acknowledgments during this phase; see slow start and hystart. </del>  Congestion controllers that are purely window based and strictly adherent to packet conservation, such as the one defined in QUIC- flows, congestion controllers that are not window-based, such as BBR, can perform well with very few acknowledgements per RTT. <del> New sender startup mechanisms, such as paced chirping, will need a way for the sender to increase the frequency of acknowledgements when fine-grained feedback is required. </del>  QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every

Reviewer comments:
by removing references to slow start, hystart, and paced chirping. Slow start and BBR startup aren't quite the same as NAME mentioned, hystart isn't specified for QUIC, and paced chirping is not an IETF draft to my knowledge.
"Starting a connection up quickly without inducing much queue is important for latency reduction, for both short and long flows. The sender often needs frequent acknowledgments during this phase; see slow start and hystart." There's no description of them in this doc. Slow start is in the recovery draft, but hystart is not, so we'd have to reference a non-QUIC RFC?
Maybe paced chirping too.
An added nit to this: congestion controllers like BBR do not have a slow start / hystart phase exactly, but are still sensitive to ACKs early in the flow during "Startup". With a BBR congestion controller the ACKing interval early in the flow has a measurable effect on the time it takes to find the bottleneck bandwidth. More generally I suspect this is true of pretty much every congestion controller that's trying to find an optimal congestion window. Given that, perhaps we need more general language here about the benefit of ACKs early in a flow, and then referencing slow start and hystart specifically?
BBR has 'Startup', which is quite similar to slow start, so maybe flow startup a better general purpose term? I think we can remove the reference to hystart entirely, since I wouldn't expect decreasing ACK frequency to have a negative impact on it, particularly given QUIC's explicit ack delay.

Revised text:
Starting a connection up quickly without inducing excess queue is important for latency reduction, for both short and long flows.  <ins> The sender often needs more frequent acknowledgments during this phase. </ins> Congestion controllers that are purely window based and strictly adherent to packet conservation, such as the one defined in QUIC- flows, congestion controllers that are not window-based, such as BBR, can perform well with very few acknowledgements per RTT.  <ins> New sender startup mechanisms will need a way for the sender to increase the frequency of acknowledgements when fine-grained feedback is required. </ins> QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every
Original text:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an <del> acknowledgement.  Values of 0 and 2^24 or greater are invalid, and </del>  receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION.

Reviewer comments:
I think minackdelay=0 should be allowed? It means there is no delay sending ack, which is a current behavior.
0 is equivalent to 1 as a value for the "Packet Tolerance" field I believe, so I agree that declaring it invalid seems unnecessary. Also, 0 and 1 are extremely similar given this is in microseconds, and 1 is valid.
0 and 1 are different, since 0 is immediate, and 1 involves a timer. Though, yeah, it seems silly to disallow immediate.

Revised text:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an  <ins> acknowledgement.  Values of 2^24 or greater are invalid, and </ins> receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION.
Original text:
as a connection error of type FRAME_ENCODING_ERROR. ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not <del> require retransmission. </del>  An endpoint MAY send ACK_FREQUENCY frames multiple times during a connection and with different values.

Reviewer comments:
If there's a frame with a larger sequence number, there's no need to retransmit.
Thanks, looks good ;-)

Revised text:
as a connection error of type FRAME_ENCODING_ERROR. ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not  <ins> require retransmission if an ACK_FREQUENCY frame with a larger Sequence Number value has been sent. </ins> An endpoint MAY send ACK_FREQUENCY frames multiple times during a connection and with different values.
Original text:
in microseconds by which the endpoint can delay an acknowledgement.  Values of 2^24 or greater are invalid, and receipt of these values MUST be treated as a connection error of <del> type PROTOCOL_VIOLATION. </del>  An endpoint's min_ack_delay MUST NOT be greater than the its max_ack_delay.  Endpoints that support this extension MUST treat receipt of a min_ack_delay that is greater than the received <del> max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in milliseconds (Section 18.2 of QUIC-TRANSPORT), min_ack_delay is specified in microseconds. </del>  This Transport Parameter is encoded as per Section 18 of QUIC- TRANSPORT.

Reviewer comments:
Use TRANSPORTPARAMETERERROR for communicating errors in TP, rather than using PROTOCOL_VIOLATION.

Revised text:
in microseconds by which the endpoint can delay an acknowledgement.  Values of 2^24 or greater are invalid, and receipt of these values MUST be treated as a connection error of  <ins> type TRANSPORT_PARAMETER_ERROR. </ins> An endpoint's min_ack_delay MUST NOT be greater than the its max_ack_delay.  Endpoints that support this extension MUST treat receipt of a min_ack_delay that is greater than the received  <ins> max_ack_delay as a connection error of type TRANSPORT_PARAMETER_ERROR.  Note that while the endpoint's max_ack_delay transport parameter is in milliseconds (Section 18.2 of QUIC-TRANSPORT), min_ack_delay is specified in microseconds. </ins> This Transport Parameter is encoded as per Section 18 of QUIC- TRANSPORT.
Original text:
eliciting packets after which the receiver sends an acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0 <del> is invalid. </del>  A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC- TRANSPORT).  The value of this field is in microseconds.  Any value smaller than the "min_ack_delay" advertised by this endpoint <del> is invalid. </del>  An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01 (representing "true").  This field can be set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer observes reordering (reordering). <del> Receipt of invalid values in an ACK_FREQUENCY frame MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del>  ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger

Reviewer comments:
At the moment, the specification requires the use of FRAMEENCODINGERROR when an endpoint receives an ACKFREQUENCY frame with the value of Update Max Ack Delay field being smaller than . That contradicts from the practice of the core draft, that restricts the use of FRAMEENCODINGERROR to syntactic (i.e. encoding) errors. This PR fixes the problem by changing the error code to be used in that case to PROTOCOLVIOLATION.

Revised text:
eliciting packets after which the receiver sends an acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0  <ins> is invalid.  Receipt of an invalid value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC- TRANSPORT).  The value of this field is in microseconds.  Any value smaller than the "min_ack_delay" advertised by this endpoint  <ins> is invalid.  Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01 (representing "true").  This field can be set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer observes reordering (reordering).  <ins> Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger
Original text:
using an ACK_FREQUENCY frame, shown below: Following the common frame format described in Section 12.4 of QUIC- <del> TRANSPORT, ACK_FREQUENCY frames have a type of 0xAF, and contain the </del>  following fields: A variable-length integer representing the sequence number

Reviewer comments:
We don't need to change the frame type on each draft version, but I figured that it'd be safer.

Revised text:
using an ACK_FREQUENCY frame, shown below: Following the common frame format described in Section 12.4 of QUIC-  <ins> TRANSPORT, ACK_FREQUENCY frames have a type of 0xaf, and contain the </ins> following fields: A variable-length integer representing the sequence number
Original text:
On the first received ACK_FREQUENCY frame in a connection, an endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence <del> number.  The new ACK-eliciting Threshold and Update Max Ack Delay </del>  values MUST be immediately used for delaying acknowledgements; see sending. acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. On receiving an ACK_FREQUENCY frame and updating its recorded <del> "max_ack_delay" and "ACK-eliciting threshold" values (multiple- </del>  frames), the endpoint MUST send an acknowledgement when one of the following conditions are met: Since the last acknowledgement was sent, the number of received ack-eliciting packets is greater than or equal to the recorded <del> "ACK-eliciting threshold". </del>  Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed. "Ignore Order" value of "true" (0x01), the endpoint does not make this exception.  That is, the endpoint MUST NOT send an immediate acknowledgement in response to packets received out of order, and <del> instead continues to use the peer's "ACK-eliciting threshold" and </del>  "max_ack_delay" thresholds for sending acknowledgements. 6.2.

Reviewer comments:
Part of We still need to decide whether to change 'Update Max Ack Delay' to 'Max Ack Delay'.

Revised text:
On the first received ACK_FREQUENCY frame in a connection, an endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence  <ins> number.  The new Ack-Eliciting Threshold and Update Max Ack Delay </ins> values MUST be immediately used for delaying acknowledgements; see sending. acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. On receiving an ACK_FREQUENCY frame and updating its recorded  <ins> "max_ack_delay" and "Ack-Eliciting Threshold" values (multiple- </ins> frames), the endpoint MUST send an acknowledgement when one of the following conditions are met: Since the last acknowledgement was sent, the number of received ack-eliciting packets is greater than or equal to the recorded  <ins> "Ack-Eliciting Threshold". </ins> Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed. "Ignore Order" value of "true" (0x01), the endpoint does not make this exception.  That is, the endpoint MUST NOT send an immediate acknowledgement in response to packets received out of order, and  <ins> instead continues to use the peer's "Ack-Eliciting Threshold" and </ins> "max_ack_delay" thresholds for sending acknowledgements. 6.2.