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

Commentary: 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 do n'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 would n'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 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 .
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint can delay an
acknowledgement.  This limit could be based on the receiver's
clock or timer granularity.
A variable-length integer representing the minimum amount of time
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.
Endpoints MUST NOT remember the value of the min_ack_delay transport
parameter they received.  Consequently, ACK_FREQUENCY frames cannot
be sent in 0-RTT packets, as per Section 7.4.1 of QUIC-TRANSPORT.
Endpoints MUST NOT remember the value of the min_ack_delay transport
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.
Draft: draft-ietf-quic-ack-frequency

Commentary: 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 ca n't see a reason not to bump the codepoint , so please merge my PR if you agree 
 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 :   ; we can add a transport parameter ( possible ) if someone really wants this feature .
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 CE-marked packets
(out-of-order).  0 represents 'false' and 1 represents 'true'.
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.
Draft: draft-ietf-quic-ack-frequency

Commentary: I tried to work in what I thought were the important parts of  's suggested text , PTAL if I captured everything . 
 It 's also true that for many RF media , the performance of the forward path can be impacted by the rate of acknowledgment packets when the link bandwidth is shared . 
 “ Severely asymmetric link technologies , such as DOCSIS ,  , and satellite links , connection throughput in the data direction becomes constrained when the reverse bandwidth is filled by acknowledgment packets . When traversing such links , reducing the number of acknowledgments allows connection throughput to scale much further . ” I ’m going to push back again on this as largely wrong . Links such as DOCSIS , LTE , satellite and  are asymmetric . But it ’s not just that the design decisions made for these types of link resulted in asymmetric capacity ( throughput limit ) , the designs also share the capacity , and it is important to mitigate the impact on that sharing of capacity , than purely thinking of it items of bytes / sec of capacity used . A lower feedback rate can help avoid inducing flow starvation to other flows that share resources along the path they use . On mobile devices sending data consumes RF and battery power and is more costly for a host of reasons not just asymmetry when present . 
 -- I do n't follow why you say that the statement is wrong . It seems to me that you think that the statement is inadequate . Would you mind responding here with some text you would prefer instead , and I 'm happy to wordsmith and turn it into a PR ? 
 I suggest some text something like : For some link technologies ( e.g. , DOCSIS ,  ,  , and satellite links ) transmission of acknowledgment packets contribute to link utilization and can incur significant forwarding costs . In some cases , the connection throughput in the data direction can become constrained when the reverse bandwidth is filled by acknowledgment packets . In other cases , the rate of acknowledgment packets can impact link efficiency ( e.g. transmission opportunities or battery life ) . A lower ACK frequency can be beneficial when using paths that include such links . 
 -- Is the text proposal in the issue enough for you to make a PR ? 
 This is much better .
Severely asymmetric link technologies, such as DOCSIS, LTE, and
satellite links, connection throughput in the data direction
becomes constrained when the reverse bandwidth is filled by
acknowledgment packets.  When traversing such links, reducing the
number of acknowledgments allows connection throughput to scale
much further.
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.
Draft: draft-ietf-quic-ack-frequency

Commentary: " 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 .
While it is expected that endpoints will have only one ACK_FREQUENCY
frame in flight at any given time, this extension does not prohibit
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.
While it is expected that endpoints will have only one ACK_FREQUENCY
frame in flight at any given time, this extension does not prohibit
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.
Draft: draft-ietf-quic-ack-frequency

Commentary: Connection Migration .... " it sends or it can simply send an IMMEDIATE_ACK frame " What is the intended difference between the words " it sends " or " it can simply send " ?
To avoid additional delays to connection migration confirmation when
using this extension, a client can bundle an IMMEDIATE_ACK frame with
the first non-probing frame (Section 9.2 of QUIC-TRANSPORT) it sends
or it can simply send an IMMEDIATE_ACK frame, which is a non-probing
frame.
To avoid additional delays to connection migration confirmation when
using this extension, a client can bundle an IMMEDIATE_ACK frame with
the first non-probing frame (Section 9.2 of QUIC-TRANSPORT) it sends
or it can send only an IMMEDIATE_ACK frame, which is a non-probing
frame.
Draft: draft-ietf-quic-ack-frequency

Commentary: Although I understand what minackdelay represents it 's not clear to me what an implementation should do with that value . Is the purpose to make sure that stacks sufficiently wait enough time before triggering PTO ? There 's no guidance on this in the draft . Perhaps there should be . 
 represents the minimum time that the receiver can delay for . In the common case , this would be the receiver 's clock or timer granularity . This is for the receiver to indicate that the sender can not reduce below this value . So a receiver implementation can simply use its granularity for this value , and a sender must ensure that its is not below the received . Does this help , We can add some text to clarify this . 
 Thanks . Yes , I think this should be explained in the draft like you said .
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint can delay an
acknowledgement.
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint can delay an
acknowledgement.  This limit could be based on the receiver's
clock or timer granularity.
Draft: draft-ietf-quic-ack-frequency

Commentary: The draft does n't mention anything about ACK frequency and connection migration . What should we do , for example , when a client has migrated and now sends a PING to force the server to use a new path ? Should it send PING+IMMEDIATE_ACK ? 
 That seems sensible . Mind writing a PR ? 
 There 's nothing odd about an immediate ACK ! Perhaps the text should start by saying that the spec allows a receiver to do this anyway ? However , the current text does n't explain why the Immediate ACK might be useful . I could see three places that might benefit from an IMMEDIATE_ACK : Two cases relevant to SCTP [ RFC7053 ] are : When the rate of transmission was very low and packets might be lost and not detected ( something not uncommon in some SCTP uses ) ; as an alternative to detect connectivity failure and trigger path failover . I 'm not sure how important these specific cases are for QUIC , because the discussion at the time in TSVWG appeared to centre around use for signalling traffic ? There could also be real opportunity to use this to get more precise timing / congestion information . A set of per - packet ACKs might be useful while a CC is probing to confirm available capacity , etc . Have I missed a killer application for the method - it would be helpful to me to understand /some example for how the WG think this could be used . ( aside : I am actually uncertain whether this would really be a good change to TCP , especially with the heterogeniety of TCP middleboxes and senders , ... that 's another story , but I 'd think it might be nice to not rely on draft - gomez - tcpm - ack - pull as a reference . I could suggest RFC7053 , where people might recall there was quite some discussion in TSVWG about whether SCTP would benefit from being able to trigger an immediate response . ) 
 We use an immediate ACK to support CC by delayed ACKs . 
 adds two use cases that uses IMMEDIATE_ACK . 
 These changes both look good to me .
An endpoint's congestion controller and RTT estimator are reset upon
confirmation of migration (Section 9.4 of QUIC-TRANSPORT), which can
impact the number of acknowledgements received after migration.  An
endpoint that has sent an ACK_FREQUENCY frame earlier in the
connection SHOULD update and send a new ACK_FREQUENCY frame
immediately upon confirmation of connection migration.
Draft: draft-ietf-quic-ack-frequency

Commentary: “ As discussed in Section 9 however , there are undesirable consequences to congestion control and loss recovery if a receiver uniltaerally reduces the acknowledgment frequency . “ This is a harsh statement . I do n’t think it is true for smaller changes . There is much experience of using TCP where stretch ACKs cover more than two packets . This is a matter of scale . For instance : I ’m confident that stretched TCP ACKs covering 4 segments ( maybe more ... I ’d love to say up to IW ) would not break TCP CC , so I do n’t see why the editors want to suggest it could break QUIC CC ! This really does need a less obfuscated explanation . 
 I 'd be happy to reword this to " there can be undesirable consequences ... " , but were you looking for a larger change ? 
 Thanks - yes , /can be/ would seem fair , since they are enumerated later . 
 This seems an improvement , thanks .
As discussed in implementation however, there are undesirable
consequences to congestion control and loss recovery if a receiver
uniltaerally reduces the acknowledgment frequency.  A sender's
constraints on the acknowledgement frequency need to be taken into
account to maximize congestion controller and loss recovery
performance.
As discussed in implementation however, there can be undesirable
consequences to congestion control and loss recovery if a receiver
uniltaerally reduces the acknowledgment frequency.  A sender's
constraints on the acknowledgement frequency need to be taken into
account to maximize congestion controller and loss recovery
performance.
Draft: draft-ietf-quic-ack-frequency

Commentary: You are n't using , so remove it . I updated the links so that the text rendering does n't include them twice .
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic [1].
Source code and issues list for this draft can be found at
https://github.com/quicwg/ack-frequency [2].
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>.  Source
code and issues list for this draft can be found at
<https://github.com/quicwg/ack-frequency>.
Working Group information can be found at <https://github.com/
quicwg>.
TBD.
Draft: draft-ietf-quic-ack-frequency

Commentary: Fixes issue . 
 Thanks for the PR ! 
 Section 4 explains what all the fields are mean first and then explains the exception cases . It seems like this was done the opposite way for  order . I propose we change the current text : To : 
 SGTM , want to send me a PR or should I ?
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.
An 8-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 observes reordering
(reordering).  The value of this field MUST be 0x00 (representing
"false") or 0x01 (representing "true").  Receipt of any other
value MUST be treated as a connection error of type
FRAME_ENCODING_ERROR.
Draft: draft-ietf-quic-ack-frequency

Commentary: by allowing implementations to not add maxackdelay to the PTO calculation if enough ack - eliciting packets are in flight . 
 Does  's longer explanation help or would you like more clarification ? 
 With this extension , an immediate ACK is expected if more than the " Packet Tolerance " ack - eliciting packets are outstanding . Given that , it may be a worthwhile optimization to allow the maxackdelay to not be included in the PTO computation in some cases . If we 're not going to allow that , I think we should explain why . This split off , but I think the question of whether maxackdelay always needs to be included in PTO should be separate from whether QUIC would benefit from an ACK - pull mechanism of some sort . That being said , if a mechanism did exist , we add details about when ACK - pull allowed maxackdelay to not be included . 
 This is a clever optimization , I agree it 's worth some text . 
 I 'm not sure I understand the motivation for this ( I 'm also having trouble following the issue ) . Can we add some more explanation here?one suggestion , but lgtm otherwise .
When the number of in-flight ack-eliciting packets is larger than the
ACK-Eliciting Threshold, an endpoint can expect that the peer will
not need to wait for its "max_ack_delay" period before sending an
acknowledgement.  In such cases, the endpoint MAY therefore exclude
the peer's 'max_ack_delay' from its PTO calculation.  Note that this
optimization requires some care in implementation, since it can cause
premature PTOs under packet loss when "ignore_order" is enabled.
Draft: draft-ietf-quic-ack-frequency

Commentary: Does it make sense to specify any maximum values for any of the ACK frequency frame fields , such as for Packet Tolerance ? Does a value of 4 billion make sense ? Can I use a in my implementation to store this locally ? Is there any expectation around the sizes of these fields ? If there is no explicit max , what if I implicitly apply one ? I 'm working on implementing this and I 'm trying to figure out how small ( byte size ) I can make the variables I use to store the values on the connection . 
 Update    will be limited by the    limit once lands . That leaves Packet Tolerance , which I agree is reasonable to limit to a value smaller than 2 ^ 62 - 1 locally . We could add a comment like " Implementations that have a lower limit than 2 ^ 62 - 1 on the Packet Tolerance MUST set treat it as though the maximum supported Packet Tolerance value has been received . " 
  tweak : " If an endpoint receives a Packet Tolerance value that is larger than the maximum value it can represent , the endpoint MUST use the largest representable maximum value instead . "
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 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.  If an endpoint
receives an ACK-eliciting threshold value that is larger than the
maximum value it can represent, the endpoint MUST use the largest
representable value instead.
Draft: draft-ietf-quic-ack-frequency

Commentary: Also updates the transport parameter codepoint to 0xff03de1a from 0xff02de1a . 
 While reading the latest ack - frequency draft , I am confused with the wording that was in If I have ack - eliciting threshold = 1 , to me it means that I can receive 1 ack - eliciting packet before sending an ACK , i.e. I have to send ACK after receiving 1 packet . But looking at the example of 0 , this interpretation looks wrong . suggested , maybe the " before " needs to be " without " and an additional sentence : " An immediate acknowledgement is sent when more than this number of packets have been received . " I agree with his suggestion . 
 Thanks for the issues , this is a bit unclear . PTAL at 
 The definition that I use internally is " the number of packets you can receive without sending an immediate acknowledgment " . This is different than saying " please acknowledge every N packets " . The main benefit of this definition is that there are no invalid values for the number . I recommend making this adjustment in the frame definition : it will be more efficient ( by a tiny amount ) , but it also removes the need to validate the value . 
 This seems like a good change , it 's just a matter of writing the text .
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.  If an endpoint
receives an ACK-eliciting threshold value that is larger than the
maximum value it can represent, the endpoint MUST use the largest
representable value instead.
A variable-length integer representing the maximum number of ack-
eliciting packets the recipient of this frame can receive before
sending an immediate acknowledgment.  A value of 0 will result in
an immediate acknowledgement whenever an ack-eliciting packet
received.  If an endpoint receives an ACK-eliciting threshold
value that is larger than the maximum value it can represent, the
endpoint MUST use the largest representable value instead.
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.