jiebi/TextFlow huggingface dataset:
Original text:
case of re-boots.  This document RECOMMENDS the exchange of 64 bit random nonces.  Considering the birthday paradox, the average collision for each nonce will happen after 2^32 messages, which is <del> considerably more token provisioned than would be expected for </del>  intended applications.  If applications use something else, such as a counter, they need to guarantee that reboot and loss of state on either node does not provoke reuse.  If that is not guaranteed, nodes

Reviewer comments:
This part got reworded a bit in response to IESG comments and this (admittedly unusual) grammatical construction got changed to something that doesn't make sense.
Thanks. "which is considerably more token provisioned" is clearly not right. I think the intent was "tokens provisioned" but "token provisionings" is more accurate. Unless there are any objections I will merge on Monday.

Revised text:
case of re-boots.  This document RECOMMENDS the exchange of 64 bit random nonces.  Considering the birthday paradox, the average collision for each nonce will happen after 2^32 messages, which is  <ins> considerably more token provisionings than would be expected for </ins> intended applications.  If applications use something else, such as a counter, they need to guarantee that reboot and loss of state on either node does not provoke reuse.  If that is not guaranteed, nodes
Original text:
Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed. <del> loss and batch section describes exceptions to this strategy. </del>  An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all 6.1. <del> To expedite loss detection, endpoints SHOULD send an acknowledgement immediately on receiving an ack-eliciting packet that is out of order.  Endpoints MAY continue sending acknowledgements immediately on each subsequently received packet, but they SHOULD return to using delay thresholds as specified above within a period of 1/8 x RTT, unless more ack-eliciting packets are received out of order. </del>  <del> Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events. </del>  6.2.  For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This batch can contain enough packets to cause multiple acknowledgements

Reviewer comments:
merging.
Endpoints expect the connection to encounter reordering might want to indicate that the receiver should not send immediate acks on receiving a reordered packet.

Revised text:
Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed.  <ins> reordering, congestion, and batch describe exceptions to this strategy. </ins> An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all 6.1.  <ins> As specified in Section 13.3.1 of QUIC-TRANSPORT, endpoints SHOULD send an acknowledgement immediately on receiving a reordered ack- eliciting packet, unless the peer has sent a "disable_ack_on_reordering" transport parameter, described below: </ins>  <ins> This optional transport parameter is sent by an endpoint that is reordering tolerant or expects reordering in the connection.  An endpoint that receives this transport parameter MUST NOT send an immediate acknowledgement when reordering is observed, and MUST continue delaying acknowledgements as per sending.  This parameter is a zero-length value. </ins> 6.2. <ins> As specified in Section 13.3.1 of QUIC-TRANSPORT, an endpoint SHOULD immediately acknowledge packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header.  Doing so reduces the peer's response time to congestion events. 6.3. </ins> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This batch can contain enough packets to cause multiple acknowledgements
Original text:
While it is expected that endpoints will have only one ACK_FREQUENCY frame in flight at any given time, this extension does not prohibit <del> having more than one in flight.  Generally, when using "max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. </del>  When the number of in-flight ack-eliciting packets is larger than the ACK-Eliciting Threshold, an endpoint can expect that the peer will

Reviewer comments:
"Generally, when using maxackdelay for PTO computations, endpoints MUST use the maximum of the current value and all those in flight." I think the words generally and MUST do not sit well together, and it would be better to say what is the requirement.

Revised text:
While it is expected that endpoints will have only one ACK_FREQUENCY frame in flight at any given time, this extension does not prohibit  <ins> having more than one in flight.  When using "max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. </ins> When the number of in-flight ack-eliciting packets is larger than the ACK-Eliciting Threshold, an endpoint can expect that the peer will
Original text:
at a data receiver.  Experience shows that this cost reduction can be significant for high bandwidth connections. <del> Similarly, receiving UDP packets can also be CPU intensive, and reducing acknowledgement frequency reduces this cost at a data sender. </del>  Severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the data direction QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every <del> other packet, and for every packet (for a short while) when reordering is observed.  This simple mechanism does not allow a sender to signal its constraints, which in turn limits what a receiver can do to delay acknowledgements and reduce acknowledgement frequency.  This extension provides a mechanism to solve this problem. </del>  3. 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^14 or greater are invalid, and </del>  receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION. following fields: A variable-length integer representing the sequence number <del> assigned to the ACK-FREQUENCY frame by the sender, see multiple- frames. </del>  A variable-length integer representing the maximum number of ack- eliciting packets after which the receiver sends an

Reviewer comments:
Plus fixing one spot where it said 2^14, but I think it should have been 2^24

Revised text:
at a data receiver.  Experience shows that this cost reduction can be significant for high bandwidth connections.  <ins> Similarly, receiving and processing UDP packets can also be CPU intensive, and reducing acknowledgement frequency reduces this cost at a data sender. </ins> Severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the data direction QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every  <ins> other packet, and for every packet when reordering is observed.  This simple mechanism does not allow a sender to signal its constraints, which in turn limits what a receiver can do to delay acknowledgements and reduce acknowledgement frequency.  This extension provides a mechanism to solve this problem. </ins> 3. A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an  <ins> acknowledgement.  Values of 0 and 2^24 or greater are invalid, and </ins> receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION. following fields: A variable-length integer representing the sequence number  <ins> assigned to the ACK-FREQUENCY frame by the sender to allow receivers to ignore obsolete frames, see multiple-frames. </ins> A variable-length integer representing the maximum number of ack- eliciting packets after which the receiver sends an
Original text:
A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an <del> immediate acknowledgement when the peer receives CE-marked packets (out-of-order).  0 represents 'false' and 1 represents 'true'. A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an </del> immediate acknowledgement when the peer receives a packet out of order (out-of-order). 0 represents 'false' and 1 represents 'true'. RFC8257 or other congestion controllers that mark more frequently than classic ECN RFC3168. <del> If the most recent ACK_FREQUENCY frame an endpoint has received from the peer has an "Ignore CE" value of "true" (0x01), receipt of a CE marked packet SHOULD NOT cause an endpoint to send an immediate acknowledgement.  The endpoint still sends an immediate acknowledgement if it would have for a non CE marked packet.  If an immediate acknowledgement is not sent, the CE marks are reported in the next acknowledgement. The Ignore-CE bit SHOULD NOT be set if the sender sets ECT(1) in its outgoing packets, such as with L4S, because it delays the congestion controller's ability to quickly respond to congestion. </del> 7.3. For performance reasons, an endpoint can receive incoming packets

Reviewer comments:
With the last draft(-03), there is a change on ACKFREQUENCY frame format (Remove Ignore CE and Reordering Threshold ) may be need change minack_delay value for detect what frame format do you need to use for decode ?
I think we should change the minackdelay Transport Param codepoint, which is currently 0xff03de1a, maybe to 0xff04de1a.
yes, I also thought about this and then forgot to bring it up. Maybe we should even submit a new version with a different number right tomorrow.
Submitting and then revving the version SGTM. I can't see a reason not to bump the codepoint, so please merge my PR if you agree NAME
Following up on discussion in issue and . It is not clear if this signal is needed at all. CE should always be provided as soon as possible. Only follow-up CE in the same RTT might be deployed. However, this seem to be part of the ECN specification (e.g. as discussed for AccECN) and not necessarily in scope for this document, as it is not clear why a sender signal for this is needed.
Thanks for filing this, I'll plan to include this in slides for Philadelphia.
Discussion at IETF 114: Remove Ignore_CE; we can add a transport parameter (possible) if someone really wants this feature.

Revised text:
A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an  immediate acknowledgement when the peer receives a packet out of order (out-of-order). 0 represents 'false' and 1 represents 'true'. RFC8257 or other congestion controllers that mark more frequently than classic ECN RFC3168.  7.3. For performance reasons, an endpoint can receive incoming packets
Original text:
QUIC-TRANSPORT): A variable-length integer representing the minimum amount of time <del> in microseconds by which the endpoint can delay an acknowledgement.  This limit could be based on the receiver's clock or timer granularity. </del>  An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat does not cause the endpoint to change its acknowledgement behavior. Endpoints MUST NOT remember the value of the min_ack_delay transport <del> parameter they received.  Consequently, ACK_FREQUENCY frames cannot be sent in 0-RTT packets, as per Section 7.4.1 of QUIC-TRANSPORT. </del>  This Transport Parameter is encoded as per Section 18 of QUIC- TRANSPORT.

Reviewer comments:
and provides some further clarification as it was easy to wrongly read to which endpoint the minackdelay applies to. I guess to avoid confusing this could be even called something like capableminack_delay but not sure if that makes a bug difference.
Not remembering it at all would be rather pointless :) I think the authors intended to add, " for use in a subsequent connection."
Yes, this sentence also confused me a lot!
I don't believe the draft says which takes precedence if the Ack-Eliciting Threshold results in the data receiver having to send an ACK sooner than the minackdelay. I believe the draft ought to say that minackdelay takes precedence over Ack-Eliciting Threshold if the two conflict. My reasoning is that a processor needs time before it thinks about a threshold, similar to the reasoning behind §7.3 on Batch Processing of Packets, which says: But I wouldn't fight hard, if someone has better reasoning against this order of precedence.
The minackdelay is an indication from the sender of this information that it practical is not able to send acks faster, e.g. because of the timer granularity. I tried to clarify this in PR NAME does this resolve this issue?
Closing as was merged. Please reopen or open new issue if still not clear!
Looks good, with a few minor textual improvements suggested.

Revised text:
QUIC-TRANSPORT): A variable-length integer representing the minimum amount of time  <ins> in microseconds by which the endpoint that is sending this value is able to delay an acknowledgement.  This limit could be based on the receiver's clock or timer granularity. 'min_ack_delay' is used by the peer to avoid requesting too small a value in the Request Max Ack Delay field of the ACK_FREQUENCY frame. </ins> An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat does not cause the endpoint to change its acknowledgement behavior. Endpoints MUST NOT remember the value of the min_ack_delay transport  <ins> parameter they received for use in a subsequent connection. Consequently, ACK_FREQUENCY frames cannot be sent in 0-RTT packets, as per Section 7.4.1 of QUIC-TRANSPORT. </ins> This Transport Parameter is encoded as per Section 18 of QUIC- TRANSPORT.
Original text:
value smaller than the "min_ack_delay" advertised by this endpoint is invalid. <del> Receipt of an empty ACK-FREQUENCY frame or invalid values in an ACK- FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del>  ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission. check if this is a more recent frame than any previous ones, as follows: <del> If the enclosing packet number is not greater than the largest one seen so far, the endpoint MUST ignore this frame. </del> If the sequence number in the frame is greater than the largest one seen so far, the endpoint MUST immediately replace old recorded state with values received in this frame.  The endpoint

Reviewer comments:
Changed the error code to FRAMEENCODINGERROR and removed a condition for update which I think may end up causing correctness issues.
I removed the comment you thought was unnecessary, and we can discuss it and any other changes to the section separately.

Revised text:
value smaller than the "min_ack_delay" advertised by this endpoint is invalid.  <ins> Receipt of invalid values in an ACK-FREQUENCY frame 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. check if this is a more recent frame than any previous ones, as follows:  If the sequence number in the frame is greater than the largest one seen so far, the endpoint MUST immediately replace old recorded state with values received in this frame.  The endpoint
Original text:
Threshold and Request Max Ack Delay values to be no more than a congestion window and an estimated RTT, respectively. <del> A sender might use timers to detect loss of PMTUD probe packets.  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMUD probes to avoid triggering such timers. </del>  9.4.

Reviewer comments:
originally created by NAME in URL (but not PR was created)
A sender might use timers to detect loss of PMTUD probe packets. A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMUD probes to avoid triggering such timers. This seems also valuable for DPLPMTUD.
QUIC loss detection doesn't use timers to detect loss, it uses acknowledgement of subsequently sent packets. In RFC9000, we indicate that a timer is not necessary for DPLPMTUD. URL One could include an IMMEDIATE_ACK with a probe to speed up Path MTU, though I'm not sure if that's a useful optimization or not? It doesn't seem harmful, but I'm just not sure if we should comment on it. What do you think?
NAME it seems your commit didn't make it to a PR. Can you check that? Also does your commit address this issue fully (by adding a reference to RFC9000). To be honest, after your discussion it sounds to me that this sentence should rather be a MAY than a SHOULD (as it is currently written in the draft). However, no strong opinion from my side to change that.
Looks good as a concrete example of immediately acknowledging.

Revised text:
Threshold and Request Max Ack Delay values to be no more than a congestion window and an estimated RTT, respectively.  <ins> A sender might use timers to detect loss of PMTU probe packets (Section 14 of QUIC-TRANSPORT).  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMU probes to avoid triggering such timers. </ins> 9.4.
Original text:
flight.  A sender can accomplish this by sending an IMMEDIATE_ACK frame once per round-trip time (RTT), or it can set the Ack-Eliciting Threshold and Request Max Ack Delay values to be no more than a <del> congestion window and an estimated RTT, respectively. </del>  9.2.

Reviewer comments:
Thank you for adding the guidance on a sender's choice of acknowledgment frequency. In the below text, I think we need to be careful about one more scenario - app limited sending behavior. If the sender is sending in a stop and go manner, and it creates ACKFREQUENCY such that it receives one ACK per cwnd (ack-eliciting threshold) or an estimated RTT (Request Max Ack Delay), then it could take a total of 2 RTT for the ACK to come back. A sender can accomplish this by sending an IMMEDIATEACK frame once per round-trip time (RTT), or it can set the Ack-Eliciting Threshold and Request Max Ack Delay values to be no more than a congestion window and an estimated RTT, respectively. For example, if RTT = R sender sends after long idle period at time t (there are no outstanding bytes in flight) receiver receive packet at t + R/2 (one way propagation time) receiver waits for 1R and then sends ACK sender will receive ACK at (t+R/2) + 1R ( Max ack delay) + R/2 Perhaps, we could handle the app-limited scenario in guidance by saying, An app-limited sender SHOULD send an IMMEDIATE_ACK frame at the start of a new send cycle OR (More generic solution) The receiver SHOULD send an ACK after, MIN( time equivalent to Request Max Ack Delay has elapsed from the last ACK, Request Max Ack Delay from when it received data) I like option 2 as this covers the different sending behaviors.
Yes, in the case you describe, it could take 2 RTTs to get feedback for sending a single packet. Are there problems you expect this to cause? The same is true of RFC9000 if peer's maxackdelay is >= RTT. I can imagine recommending sending an IMMEDIATE_ACK at the end of a send cycle to mitigate this, but I'm not sure what the goal of sending one at the beginning is?
I created PR Does this guidance make sense?

Revised text:
flight.  A sender can accomplish this by sending an IMMEDIATE_ACK frame once per round-trip time (RTT), or it can set the Ack-Eliciting Threshold and Request Max Ack Delay values to be no more than a  <ins> congestion window and an estimated RTT, respectively.  If the sender is application-limited, a large ack delay can delay acknowledgement information unnecessarily when entering idle periods.  Therefore, if no further data is buffered to be sent, a sender can send an IMMEDIATE_ACK frame with the last data packet before an idle period to avoid waiting for the ack delay. </ins> 9.2.
Original text:
9. <del> TBD. </del>  10.

Reviewer comments:
The document uses MUST in multiple places, however, as discussed in the new proposed text for the security considerations (see PR ) the requester cannot enforce any ACK strategy and there might be reason like practical limitation or an overload situation where the ACK sender simply decides to send less ACKs. So the question is really can to requirements be MUSTs or is SHOULD more realistic and correct?
I believe a data sender can attack a data receiver's resources by using ack-frequency to make the receiver ACK more frequently than it can cope with. For instance, a data sender could set Ack-Eliciting Threshold low, then send small packets at high rate. Multiple data senders (eg. a bot net) could adopt this strategy to force a server to spend a large proportion of its resources receiving small packets and sending out QUIC ACKs. So I think the draft ought to say that a QUIC data receiver treats the Ack-Eliciting Threshold as a polite request, and it can ACK less frequently if its resources are limited. Currently §7 of the draft says: This is where I suggest it ought to say SHOULD, and explain why it is not a MUST. Unfortunately, this means a genuine data sender cannot deterministically rely on the receiver complying with an ack-frequency request, e.g. a sender cannot use ack-frequency to reduce the time it has to wait before it deems there must have been a loss. But, I guess a sender that is not being unreasonable will usually be able to rely on the receiver doing as requested. There's probably a similar line of argument to this whole issue for minackdelay.
The client does not know very much about the sensibility of a particular request. e.g. a request trying to force a high ACK rate - or a request reducing the ACK frequency to a very long period - using up cwnd to reach flow-control limits and stall. I think this totally relies on the server requesting sensible values. But that's fine - we could say what is sensible if we wish.

Revised text:
9.  <ins> An improperly configured or malicious data sender could cause a data receiver to acknowledge more frequently than its available resources permits.  However, there are two limits that make such an attack largely inconsequential.  First, the acknowledgement rate is bounded by the rate at which data is received.  Second, ACK_FREQUENCY and IMMEDIATE_ACK frames can only request an increase in the acknowledgment rate, but cannot force it. In general, with this extension, a sender cannot force a receiver to acknowledge more frequently than the receiver considers safe based on its resource constraints. </ins> 10.