jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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: <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
Change:
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.

Discussion:
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> <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.
Change:
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?

Discussion:
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> <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.
Change:
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.

Discussion:
9. <del> TBD. </del> <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.
Change:
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?

Discussion:
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> <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.
Change:
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!

Discussion:
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> <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, <del> including transmission opportunities or battery life. </del> <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
Change:
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.

Discussion:
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> <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.
Change:
This clarification is not necessarily needed but I think it would help me. Just a proposal...

Discussion:
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
Change:
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.

Discussion:
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> <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
Change:
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?

Discussion:
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> <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
Change:
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.

Discussion:
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> <ins> reordering: </ins> 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> <ins> reordering: </ins> 6.2.
Change:
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.

Discussion:
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> <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. <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> <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
Change:
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.

Discussion:
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> <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.
Change:
If there's a frame with a larger sequence number, there's no need to retransmit.
Thanks, looks good ;-)

Discussion:
as a connection error of type FRAME_ENCODING_ERROR. ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not <del> require retransmission. </del> <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.
Change:
Use TRANSPORTPARAMETERERROR for communicating errors in TP, rather than using PROTOCOL_VIOLATION.

Discussion:
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> <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 <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> <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.
Change:
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.

Discussion:
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> <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 <del> is invalid. </del> <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). <del> Receipt of invalid values in an ACK_FREQUENCY frame MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del> <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