jiebi/CodeConvo huggingface dataset:
Code change:
In early versions of path validation, there was a requirement that PATH_CHALLENGE be sent on the same path. This is, for various reasons, either unnecessary or harmful, so we no longer have that requirement. But there was some residual text that assumed that property. This removes a paragraph citing symmetry directly, and rewords text that assumes return reachability - a property that QUIC no longer provides mechanisms for.
In , we removed the requirement that PATHRESPONSE be sent/received on the same path that PATHCHALLENGE was sent. However, there is still text in the document that relies on this assumption. In 8.5, it explains that receipt of the PATHRESPONSE on another interface doesn't cause validation to fail, because "It is possible that a valid PATHRESPONSE might be received in the future." But receipt of the PATHRESPONSE, over any interface is valid, and causes the validation to succeed. In 9.2, it suggests using path validation to demonstrate return reachability, but since PATHRESPONSE need not be sent on the same path, path validation doesn't demonstrate that.
Note that sending the response on the old path can lead to failures in "break before make" scenarios. Shall we mention that?

Related discussion:
text: Receiving acknowledgments for data sent on the new path serves as proof of the peer's reachability from the new address.  Note that since acknowledgments may be received on any path, return <del> reachability on the new path is not established.  To establish return </del> <ins> reachability on the new path is not established.  No method is provided to establish return reachability, as endpoints independently determine reachability on each direction of a path.  To establish </ins> reachability on the new path, an endpoint MAY concurrently initiate <del> path validation migrate-validate on the new path or it MAY choose to wait for the peer to send the next non-probing frame to its new address. </del> <ins> path validation migrate-validate on the new path.  An endpoint MAY defer path validation until after a peer sends the next non-probing frame to its new address. </ins> 9.3.
Code change:
These two statements are - to the extent that I can best determine - redundant. One is better.
The first two sentences of QUIC-TLS, Section 4.1.4 clearly intend to say different things, but I can't figure out the distinction. Is there a way we could reword them to make them clearer?
I think that this is not separately at all. Let's reduce that to a single statement.

Related discussion:
text: 4.1.4. <del> As keys for new encryption levels become available, TLS provides QUIC with those keys.  Separately, as keys at a given encryption level become available to TLS, TLS indicates to QUIC that reading or writing keys at that encryption level are available.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </del> <ins> As keys at a given encryption level become available to TLS, TLS indicates to QUIC that reading or writing keys at that encryption level are available.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </ins> TLS provides QUIC with three items as a new encryption level becomes available:
Code change:
We weren't very concrete in saying how endpoints generate packets with CONNECTIONCLOSE, particularly those that throw away keys. We have a rather vague requirement. In short, follow the same rules we established for the handshake. Wording this as an aggregate number allows for stochastic reactions and larger CONNECTIONCLOSE frames. This way, if you get a 25-byte packet and respond with a 200-byte packet, you can do that, but you have to respond to 3 in 8 or fewer in that way. Note that this limit only applies if the endpoint throws away decryption keys. Endpoints with keys aren't blind amplifiers.
closing period ({{draining}}) and send a packet containing a CONNECTIONCLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets. To avoid creating an unwitting amplification attack, such endpoints MUST reduce the frequency with which it sends packets containing a CONNECTIONCLOSE frame. To This seems like a pretty vague requirement for a 2119 MUST. Like, I could only send it 9999/10000 packets and that would be compliant.
I think that it would be good to follow the 3x rule here also, but that's a non-editorial change.
Do folks agree the PR resolves this?
I think the PR resolves this and is a sensible choice.
Yup, the PR resolves this.
OK, labelling as such.

Related discussion:
text: CONNECTION_CLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets.  To avoid creating an unwitting <del> amplification attack, such endpoints MUST reduce the frequency with which it sends packets containing a CONNECTION_CLOSE frame.  To minimize the state that an endpoint maintains for a closing </del> <ins> amplification attack, such endpoints MUST limit the cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the packets that cause those packets to be sent. To minimize the state that an endpoint maintains for a closing </ins> connection, endpoints MAY send the exact same packet. Allowing retransmission of a closing packet is an exception to the
Code change:
This uses positive framing for the recommendation to use frames rather than packets. And it makes that recommendation directly, rather than implying it.
Here are three quasi-nits about S 12.2. Handshake, 1-RTT; see Section 4.1.4 of {{QUIC-TLS}}) makes it more likely the receiver will be able to process all the packets in a single pass. A packet with a short header does not include a length, so it can only be the last packet included in a UDP datagram. An endpoint SHOULD NOT coalesce multiple packets at the same encryption level. Is the implication here that you should instead pack all the frames into one packet? UDP datagram. Senders MUST NOT coalesce QUIC packets for different connections into a single UDP datagram. Receivers SHOULD ignore any subsequent packets with a different Destination Connection ID than the first packet in the datagram. Is there a valid reason to have different SCIDs? ({{packet-version}}), and packets with a short header ({{short-header}}) do not contain a Length field and so cannot be followed by other packets in the same UDP datagram. Note also that there is no situation where a Retry or Version Negotiation packet is coalesced with another packet. Should this be a MUST NOT?
Yes. See . I don't see why. It's just a fact, not a conformance requirement.
For (1) I think it would be helpful to say that.
LGTM, one suggestion.

Related discussion:
text: likely the receiver will be able to process all the packets in a single pass.  A packet with a short header does not include a length, so it can only be the last packet included in a UDP datagram.  An <del> endpoint SHOULD NOT coalesce multiple packets at the same encryption level. </del> <ins> endpoint SHOULD include multiple frames in a single packet if they are to be sent at the same encryption level, instead of coalescing multiple packets at the same encryption level. </ins> Receivers MAY route based on the information in the first packet contained in a UDP datagram.  Senders MUST NOT coalesce QUIC packets
Code change:
This should resolve some parts of .
NAME If you wish, I will split this PR into small ones.
I have dropped the commit of "in flight".
I also changed into .
NAME The commit for "towards" has been dropped.
Thanks. BTW, that thing is an another odd English quirk.
Unfortunately, this PR bundles a bunch of unrelated changes. Some of them I like, some of them I don't.Thanks for the PR, NAME !

Related discussion:
text: the PTO expiry, subject to address validation limits; see Section 8.1 of QUIC-TRANSPORT. <del> Peers can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, clients can </del> <ins> Endpoints can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, a client can </ins> coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight.
Code change:
It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.

Related discussion:
text: be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to include an ACK frame with outgoing frames. <ins> A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </ins> 13.2.2. A receiver determines how frequently to send acknowledgements in
Code change:
It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.

Related discussion:
text: value than what was included in a previous ACK frame could cause ECN to be unnecessarily disabled; see ecn-validation. <ins> ack-tracking describes an exemplary approach for determining what packets to acknowledge in each ACK frame.  Though the goal of this algorithm is to generate an acknowledgment for every packet that is processed, it is still possible for acknowledgments to be lost. 13.2.4. When a packet containing an ACK frame is sent, the largest acknowledged in that frame may be saved.  When a packet containing an ACK frame is acknowledged, the receiver can stop acknowledging packets less than or equal to the largest acknowledged in the sent ACK frame. </ins> A receiver that sends only non-ack-eliciting packets, such as ACK frames, might not receive an acknowledgement for a long period of time.  This could cause the receiver to maintain state for a large
Code change:
It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.

Related discussion:
text: send a PING or other small ack-eliciting frame occasionally, such as once per round trip, to elicit an ACK from the peer. <del> A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </del> <ins> In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT of reordering.  In cases with ACK frame loss and reordering, this approach does not guarantee that every acknowledgement is seen by the sender before it is no longer included in the ACK frame. Packets could be received out of order and all subsequent ACK frames containing them could be lost.  In this case, the loss recovery algorithm could cause spurious retransmissions, but the sender will continue making forward progress. </ins> <del> 13.2.6. </del> <ins> 13.2.5. </ins> An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the
Code change:
It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.

Related discussion:
text: packets, the ACK Delay field in acknowledgements for those packet types SHOULD be set to 0. <del> 13.2.7. </del> <ins> 13.2.6. </ins> ACK frames MUST only be carried in a packet that has the same packet number space as the packet being acknowledged; see packet-protected.
Code change:
It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.

Related discussion:
text: Note that the same limitation applies to other data sent by the server protected by the 1-RTT keys. <del> 13.2.8. </del> <ins> 13.2.7. </ins> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Packets containing only