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

Commentary: Fixes the remainder of not fixed by 
 This is good enough . You have a conflict to resolve , but let 's merge this .
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 larger than 16,383,000 microseconds is invalid, as specified
for the "max_ack_delay" transport parameter.  Any value smaller
than the "min_ack_delay" advertised by this endpoint is invalid.
Receipt of an invalid value MUST be treated as a connection error
of type PROTOCOL_VIOLATION.
A variable-length integer representing the value to which the
endpoint requests the peer update its "max_ack_delay"
(Section 18.2 of QUIC-TRANSPORT).  The value of this field is in
microseconds, unlike the 'max_ack_delay' transport parameter,
which is in milliseconds.  Sending a value smaller than the
"min_ack_delay" advertised by the peer is invalid.  Receipt of an
invalid value MUST be treated as a connection error of type
PROTOCOL_VIOLATION.
An endpoint will have committed a "max_ack_delay" value to the peer,
which specifies the maximum amount of time by which the endpoint will
delay sending acknowledgments.  When the endpoint receives an
ACK_FREQUENCY frame, it MUST update this maximum time to the value
proposed by the peer in the Update Max Ack Delay field.
An endpoint will have committed a "max_ack_delay" value to the peer,
which specifies the maximum amount of time by which the endpoint will
delay sending acknowledgments.  When the endpoint receives an
ACK_FREQUENCY frame, it MUST update this maximum time to the value
proposed by the peer in the Request Max Ack Delay field.
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
number.  The new Ack-Eliciting Threshold and Update Max Ack Delay
values MUST be immediately used for delaying acknowledgements; see
sending.
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
number.  The new Ack-Eliciting Threshold and Request Max Ack Delay
values MUST be immediately used for delaying acknowledgements; see
sending.
Draft: draft-ietf-quic-ack-frequency

Commentary: Copy of , applied to new draft filename .
As specified in Section 13.3.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 this
behavior.
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.
As specified in Section 13.2.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.
Draft: draft-iyengar-quic-delayed-ack

Commentary: At the moment , the specification requires the use of FRAMEENCODINGERROR when an endpoint receives an ACKFREQUENCY frame with the value of Update    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 .
A variable-length integer representing the maximum number of ack-
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
is invalid.
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
is invalid.
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).
Receipt of invalid values in an ACK_FREQUENCY frame MUST be treated
as a connection error of type FRAME_ENCODING_ERROR.
A variable-length integer representing the maximum number of ack-
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
is invalid.  Receipt of an invalid value MUST be treated as a
connection error of type FRAME_ENCODING_ERROR.
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
is invalid.  Receipt of an invalid value MUST be treated as a
connection error of type PROTOCOL_VIOLATION.
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).
Receipt of any other value MUST be treated as a connection error
of type FRAME_ENCODING_ERROR.
Draft: draft-iyengar-quic-delayed-ack

Commentary: Use TRANSPORTPARAMETERERROR for communicating errors in TP , rather than using PROTOCOL_VIOLATION .
A variable-length integer representing the minimum amount of time
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
type PROTOCOL_VIOLATION.
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
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.
A variable-length integer representing the minimum amount of time
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
type TRANSPORT_PARAMETER_ERROR.
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
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.
Draft: draft-iyengar-quic-delayed-ack

Commentary: If there 's a frame with a larger sequence number , there 's no need to retransmit . 
 Thanks , looks good ;-)
ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not
require retransmission.
ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not
require retransmission if an ACK_FREQUENCY frame with a larger
Sequence Number value has been sent.
Draft: draft-iyengar-quic-delayed-ack

Commentary: 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 .
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint can delay an
acknowledgement.  Values of 0 and 2^24 or greater are invalid, and
receipt of these values MUST be treated as a connection error of
type PROTOCOL_VIOLATION.
A variable-length integer representing the minimum amount of time
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
type PROTOCOL_VIOLATION.
Draft: draft-iyengar-quic-delayed-ack

Commentary: by removing references to slow start , hystart , and paced chirping . Slow start and BBR startup are n't quite the same as mentioned , hystart is n'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 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 would n't expect decreasing ACK frequency to have a negative impact on it , particularly given QUIC 's explicit ack delay .
Starting a connection up quickly without inducing excess 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.
Starting a connection up quickly without inducing excess queue is
important for latency reduction, for both short and long flows.
The sender often needs more frequent acknowledgments during this
phase.
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.
New sender startup mechanisms will need a way for the sender to
increase the frequency of acknowledgements when fine-grained
feedback is required.
Draft: draft-iyengar-quic-delayed-ack

Commentary: and reflow some text .
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
MUST start using the new values immediately for delaying
acknowledgements; see sending.  The endpoint MUST also replace the
recorded sequence number.
If the frame's sequence number is not greater than the largest one
seen so far, the endpoint MUST ignore this frame.
If the frame's sequence number 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 MUST start
using the new values immediately for delaying acknowledgements;
see sending.  The endpoint MUST also replace the recorded sequence
number.
Draft: draft-iyengar-quic-delayed-ack

Commentary: Small readability tweaks
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.
Starting a connection up quickly without inducing excess 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.
New sender startup mechanisms, such as paced chirping, and
congestion controllers will need a way for the sender to increase
the frequency of acknowledgements when fine-grained feedback is
required.
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.
Draft: draft-iyengar-quic-delayed-ack

Commentary: 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 .
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.
Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated
as a connection error of type FRAME_ENCODING_ERROR.
If the enclosing packet number is not greater than the largest one
seen so far, the endpoint MUST ignore this frame.
Draft: draft-iyengar-quic-delayed-ack

Commentary: Plus fixing one spot where it said 2 ^ 14 , but I think it should have been 2 ^ 24
Similarly, receiving UDP packets can also be CPU intensive, and
reducing acknowledgement frequency reduces this cost at a data
sender.
Similarly, receiving and processing UDP packets can also be CPU
intensive, and reducing acknowledgement frequency reduces this
cost at a data sender.
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 (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.
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 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.
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint can delay an
acknowledgement.  Values of 0 and 2^14 or greater are invalid, and
receipt of these values MUST be treated as a connection error of
type PROTOCOL_VIOLATION.
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint can delay an
acknowledgement.  Values of 0 and 2^24 or greater are invalid, and
receipt of these values MUST be treated as a connection error of
type PROTOCOL_VIOLATION.
A variable-length integer representing the sequence number
assigned to the ACK-FREQUENCY frame by the sender, see multiple-
frames.
A variable-length integer representing the sequence number
assigned to the ACK-FREQUENCY frame by the sender to allow
receivers to ignore obsolete frames, see multiple-frames.
Draft: draft-iyengar-quic-delayed-ack

Commentary: 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 .
loss and batch section describes exceptions to this strategy.
reordering, congestion, and batch describe exceptions to this
strategy.
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.
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.
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.
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.
Draft: draft-iyengar-quic-delayed-ack

Commentary: ... and some editorializing . 
 merging .
Since the last acknowledgement was sent, the number of received
ack-eliciting packets is greater than or equal to "Packet
Tolerance".
Prior to receiving an ACK-FREQUENCY frame, endpoints send
acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT.
Since the last acknowledgement was sent, the number of received
ack-eliciting packets is greater than or equal to the recorded
"Packet Tolerance".
Draft: draft-iyengar-quic-delayed-ack

Commentary: merging . 
 We currently use PNs for ordering , but that runs afoul of requirements at the receiver specified in .
A variable-length integer representing the sequence number
assigned to the ACK-FREQUENCY frame by the sender, see multiple-
frames.
On receiving an ACK-FREQUENCY frame, an endpoint will have an updated
maximum delay for sending an acknowledgement, and a packet threshold
as well.  The endpoint MUST send an acknowledgement when either of
the two thresholds are met. loss and batch section describes
exceptions to this strategy.
Since the last acknowledgement was sent, the number of received
ack-eliciting packets is greater than or equal to "Packet
Tolerance".
Since the last acknowledgement was sent, "max_ack_delay" amount of
time has passed.
loss and batch section describes exceptions to this strategy.
An endpoint can send multiple ACK-FREQUENCY frames, and each one of
them can have different values.
If a received ACK-FREQUENCY frame is the first one in this
connection, the endpoint MUST immediately record any values from the
frame and start using them.  The endpoint MUST also record the packet
number of the enclosing packet.
If the enclosing packet number is greater than the recorded one,
the endpoint MUST immediately replace old recorded state with
values received in this frame.  The endpoint MUST also replace the
value of the recorded packet number with that of the enclosing
packet.
If the enclosing packet number is not greater than the recorded
one, the endpoint MUST ignore this ACK-FREQUENCY frame.
An endpoint can send multiple ACK-FREQUENCY frames, and each one of
them can have different values.  An endpoint MUST use a sequence
number of 0 for the first ACK-FREQUENCY frame it constructs and
sends, and a strictly increasing value thereafter.
An endpoint MUST allow reordered ACK-FREQUENCY frames to be received
and processed, see Section 13.3 of QUIC-TRANSPORT.
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
number.  The new Packet Tolerance and Update Max Ack Delay values
MUST be immediately used for delaying acknowledgements; see sending.
If the enclosing packet number is not greater than the largest one
seen so far, the endpoint MUST ignore this frame.
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
MUST start using the new values immediately for delaying
acknowledgements; see sending.  The endpoint MUST also replace the
recorded sequence number.