jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-ack-frequency

Commentary: Defer to RFC9000 . 
 The text says : " For performance reasons , an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets . " is this the network layer ... or something else ? 
 It could be the OS or the hardware . 
 I think the sentence needs some work - I can believe the network ; interface ; operating system ; etc . Are examples of reasons why there is bunching of packets so that a batch of packets arrive at the receiver . The current text does n't really say quite what I 'd expect .
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
to be sent.
Draft: draft-ietf-quic-ack-frequency

Commentary: 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 ca n't remember why ? But in practice , it probably does n'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 ?
ACK_FREQUENCY frames are ack-eliciting.  When an ACK_FREQUENCY frame
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.
ACK_FREQUENCY frames are ack-eliciting.  When an ACK_FREQUENCY frame
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.
Draft: draft-ietf-quic-ack-frequency

Commentary: 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 .
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)
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.
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)
period; see Section 5.2.1 of QUIC-RECOVERY.
Draft: draft-ietf-quic-ack-frequency

Commentary: This clarification is not necessarily needed but I think it would help me . Just a proposal ...
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.
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.
Sending this additional ACK will reset the "max_ack_delay" timer and
"Ack-Eliciting Threshold" counter as any ACK would do.
Draft: draft-ietf-quic-ack-frequency

Commentary: A few editorial suggestions in the first part of the document .
A receiver acknowledges received packets, but it can delay sending
these acknowledgements.  The delaying of acknowledgements can impact
connection throughput, loss detection and congestion controller
performance at a data sender, and CPU utilization at both a data
sender and a data receiver.
Sending UDP packets can be noticeably CPU intensive on some
platforms.  Reducing the number of packets that only contain
acknowledgements can therefore reduce the amount of CPU consumed
at a data receiver.  Experience shows that this cost reduction can
be significant for high bandwidth connections.
A receiver acknowledges received packets, but it can delay sending
these acknowledgements.  Delaying acknowledgements can impact
connection throughput, loss detection and congestion controller
performance at a data sender, and CPU utilization at both a data
sender and a data receiver.
Sending UDP packets can be very CPU intensive on some platforms.
Reducing the number of packets that only contain acknowledgements
reduces the CPU consumed at a data receiver.  Experience shows
that this reduction can be critical for high bandwidth
connections.
QUIC-TRANSPORT currently specifies a simple delayed acknowledgement
mechanism that a receiver can use: send an acknowledgement for every
other packet, and for every packet that is received out of order
(Section 13.2.1 of QUIC-TRANSPORT).  This simple mechanism does not
allow a sender to signal its constraints.  This extension provides a
mechanism to solve this problem.
QUIC-TRANSPORT specifies a simple delayed acknowledgement mechanism
that a receiver can use: send an acknowledgement for every other
packet, and for every packet that is received out of order
(Section 13.2.1 of QUIC-TRANSPORT).  This does not allow a sender to
signal its preferences or constraints.  This extension provides a
mechanism to solve this problem.
Draft: draft-ietf-quic-ack-frequency

Commentary: 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 .
Receiving an acknowledgement can allow a sender to release new
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
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.
Receiving an acknowledgement can allow a sender to release new
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
network.  In keeping with Section 7.7 of QUIC-RECOVERY, a sender can
either employ pacing or limit bursts to the initial congestion
window.
Draft: draft-ietf-quic-ack-frequency

Commentary: MUSTs become SHOULD to align better with ACK behavior test in RFC9000 .
A variable-length integer that indicates how many out of order
packets can arrive before eliciting an immediate ACK.  If no
ACK_FREQUENCY frames have been received, the endpoint immediately
acknowledges any subsequent packets that are received out of
order, as specified in Section 13.2 of QUIC-TRANSPORT, as such the
default value is 1.  A value of 0 indicates immediate ACKs SHOULD
never be sent due to receiving an out-of-order packet.
A variable-length integer that indicates how many out of order
packets can arrive before eliciting an immediate ACK.  If no
ACK_FREQUENCY frames have been received, the endpoint immediately
acknowledges any subsequent packets that are received out of
order, as specified in Section 13.2 of QUIC-TRANSPORT, as such the
default value is 1.  A value of 0 indicates out-of-order packets
do not elicit an immediate ACKs.
An endpoint, that receives an ACK_FREQUENCY frame with a Reordering
Threshold value other than 0x00, MUST immediately send an ACK frame
when the packet number of largest unacknowledged packet since the
last detected reordering event exceeds the Reordering Threshold.
If the most recent ACK_FREQUENCY frame received from the peer has a
"Reordering Threshold" value of 0x00, 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
instead continues to use the peer's "Ack-Eliciting Threshold" and
"max_ack_delay" thresholds for sending acknowledgements.
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.
If the most recent ACK_FREQUENCY frame received from the peer has a
"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
"max_ack_delay" thresholds for sending acknowledgements.
Draft: draft-ietf-quic-ack-frequency

Commentary: 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 : This likely helps in many common scenarios . We could make a pull - request based on summarising some of this into an annexe ? 
  -- can you point to the concrete example in the draft ? I could n'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 do n'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 : Do n'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 !
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.
The rate of acknowledgment packets can impact link efficiency,
including transmission opportunities or battery life.
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.
The rate of acknowledgment packets can impact link efficiency,
including transmission opportunities or battery life, as well as
transmission opportunities available to other flows sharing the
same link.
Draft: draft-ietf-quic-ack-frequency

Commentary: This PR makes the text shorter and tightens the normative requirements around handling of multple ACK_FREQUENCY frames . This PR makes one normative change : Sequence Number value is no longer required to start at zero .
A variable-length integer representing the sequence number
assigned to the ACK_FREQUENCY frame by the sender to allow
receivers to ignore obsolete frames.
An endpoint can send multiple ACK_FREQUENCY frames with different
values within a connection.  A sending endpoint MUST send
monotonically increasing values in the Sequence Number field, since
this field allows ACK_FREQUENCY frames to be processed out of order.
A receiving endpoint MUST ignore a received ACK_FREQUENCY frame if
the Sequence Number value in the frame is not greater than the
largest processed thus far.
Draft: draft-ietf-quic-ack-frequency

Commentary: 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 ? Ca n't you always just send the more recent ACK or create one combined ACK frame with all information ?
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.
To avoid sending multiple acknowledgements in rapid succession, an
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.
To avoid sending multiple acknowledgements in rapid succession, an
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.
Draft: draft-ietf-quic-ack-frequency

Commentary: Sec # ack - frequency - frame says : and  # out - of - order says : 
 It seems optimal to default it to 3 , because that 's the default packet threshold , but the principle of least surprise argues for 1 ( ie : no behavior change until an ACK_FREQUENCY frame is received ) , so I lean toward 1 . 
 This PR adds a SHOULD NOT , but it seems sensible .
A variable-length integer that indicates how many out of order
packets can arrive before eliciting an immediate ACK.  If no
ACK_FREQUENCY frames have been received, this value defaults to 3,
which is the recommended packet threhold for loss detection in
(Section 18.2 of QUIC-RECOVERY).  A value of 0 indicates immediate
ACKs SHOULD never be sent due to receiving an out-of-order packet.
A variable-length integer that indicates how many out of order
packets can arrive before eliciting an immediate ACK.  If no
ACK_FREQUENCY frames have been received, the endpoint immediately
acknowledges any subsequent packets that are received out of
order, as specified in Section 13.2 of QUIC-TRANSPORT, as such the
default value is 1.  A value of 0 indicates immediate ACKs SHOULD
never be sent due to receiving an out-of-order packet.
If an endpoint has not yet received an ACK_FREQUENCY frame, the
endpoint immediately acknowledges any subsequent packets that are
received out of order, as specified in Section 13.2 of QUIC-
TRANSPORT.  An endpoint, that receives an ACK_FREQUENCY frame with a
Reordering Threshold value other than 0x00, MUST immediately send an
ACK frame when the packet number of largest unacknowledged packet
since the last detected reordering event exceeds the Reordering
Threshold.
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.
An endpoint, that receives an ACK_FREQUENCY frame with a Reordering
Threshold value other than 0x00, MUST immediately send an ACK frame
when the packet number of largest unacknowledged packet since the
last detected reordering event exceeds the Reordering Threshold.
Draft: draft-ietf-quic-ack-frequency

Commentary: The document uses MUST in multiple places , however , as discussed in the new proposed text for the security considerations ( see PR ) the requester can not 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 can not deterministically rely on the receiver complying with an ack - frequency request , e.g. a sender can not 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 .
TBD.
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.
Draft: draft-ietf-quic-ack-frequency

Commentary: 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 (     ) , 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     values to be no more than a congestion window and an estimated RTT , respectively . For example , if RTT = R sends after long idle period at time t ( there are no outstanding bytes in flight ) receive packet at t + R/2 ( one way propagation time ) waits for 1R and then sends ACK will receive ACK at ( t+R/2 ) + 1R (  ack delay )   Perhaps , we could handle the app - limited scenario in guidance by saying , 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     has elapsed from the last ACK ,     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 ?
To enable a sender to respond to potential network congestion, a
sender SHOULD cause a receiver to send an acknowledgement at least
once per RTT if there are unacknowledged ack-eliciting packets in
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
congestion window and an estimated RTT, respectively.
To enable a sender to respond to potential network congestion, a
sender SHOULD cause a receiver to send an acknowledgement at least
once per RTT if there are unacknowledged ack-eliciting packets in
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
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.
Draft: draft-ietf-quic-ack-frequency

Commentary: originally created by in ( 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 does n'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 . 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 does n't seem harmful , but I 'm just not sure if we should comment on it . What do you think ? 
 it seems your commit did n'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 .
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.
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.