jiebi/CodeConvo huggingface dataset:
Change:
The fact that PTO doesn't declare losses when it expires is quite important. It at the very end of the section, so I moved it to the first part. Also removed a section heading(pto-loss) which was never referenced.
A reasonable simplification.

Discussion:
A Probe Timeout (PTO) triggers sending one or two probe datagrams when ack-eliciting packets are not acknowledged within the expected <del> period of time or the handshake has not been completed.  A PTO enables a connection to recover from loss of tail packets or acknowledgements. </del> <ins> period of time or the server may not have validated the client's address.  A PTO enables a connection to recover from loss of tail packets or acknowledgements. A PTO timer expiration event does not indicate packet loss and MUST NOT cause prior unacknowledged packets to be marked as lost.  When an acknowledgement is received that newly acknowledges packets, loss detection proceeds as dictated by packet and time threshold mechanisms; see ack-loss-detection. </ins> As with loss detection, the probe timeout is per packet number space. The PTO algorithm used in QUIC implements the reliability functions

Sending different payloads each time reduces the chances of spurious retransmission. <del> 5.2.5. Delivery or loss of packets in flight is established when an ACK frame is received that newly acknowledges one or more packets. A PTO timer expiration event does not indicate packet loss and MUST NOT cause prior unacknowledged packets to be marked as lost.  When an acknowledgement is received that newly acknowledges packets, loss detection proceeds as dictated by packet and time threshold mechanisms; see ack-loss-detection. </del> 5.3. A Retry packet causes a client to send another Initial packet,
Change:
I prefer to have MUSTs towards the top of sections when possible so they're not missed. This is a follow-on from
I'm not a fan of this change -- I think there's value in having that text below where we talk about how bursts can occur. That said, I don't feel strongly about it, so I'm not going to fight for it.

Discussion:
This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the <del> congestion controller.  For example, a pacer might distribute the congestion window over the smoothed RTT when used with a window-based controller, or a pacer might use the rate estimate of a rate-based controller. </del> <ins> congestion controller.  Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations MUST either use pacing or another method to limit such bursts to the initial congestion window; see initial-cwnd. </ins> An implementation should take care to architect its congestion controller to work well with a pacer.  For instance, a pacer might

Practical considerations, such as packetization, scheduling delays, and computational efficiency, can cause a sender to deviate from this rate over time periods that are much shorter than a round-trip time. <del> Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations MUST either use pacing or limit such bursts to the initial congestion window; see initial-cwnd. </del> One possible implementation strategy for pacing uses a leaky bucket algorithm, where the capacity of the "bucket" is limited to the
Change:
This is an update to , so check where it is being merged to carefully.
I'm going to merge this into the other PR.
NAME pointed out to me that when you receive junk (i.e., unauthenticated) packets, the odds are that these will be distributed evenly between the "current" packet protection keys and the "next" packet protection keys, as the key phase bit will be nearly random if they are true forgeries. The result is that an endpoint that approaches the integrity limit on key usage will update to the next packet protection keys and find that those keys will have similar amounts of authentication failures. That might lead to needing two updates in quick succession. That isn't fatal, but if the timing is tight, then more time might be needed for an update. We might say that endpoints shouldn't be calculating the forgery rate and trying to delay updates as late as possible, nor should they be allowing that many forgeries without doing anything but react with key updates. However, as a matter of good hygiene, it's worth saying something about this. Taking this as an editorial follow-on to .
Integrated into .

Discussion:
attacker is able to successfully forge a packet; see AEBounds and ROBUST. <ins> Due to the way that header protection protects the Key Phase, packets that are discarded are likely to have an even distribution of both Key Phase values.  This means that packets that fail authentication will often use the packet protection keys from the next key phase.  It is therefore necessary to also track the number of packets that fail authentication with the next set of packet protection keys.  To avoid exhaustion of both sets of keys, it might be necessary to initiate two key updates in succession. </ins> For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on the number of packets that fail authentication is 2^36. Note that the analysis in AEBounds supports a higher limit for the
Change:
As discussed in URL, most of the errors that can occur when authenticating connection IDs should be TRANSPORTPARAMETERERRORs, not PROTOCOL_VIOLATIONs.
This changes the error codes that we require, so it is technically a design change. I think we'll need an issue to track this.
NAME Created .
The guiding principle here (as we apply it for FRAMEENCODINGERRORs) is that if an error is detectable without accessing connection state, we use the more specific error. So for example, since and are required transport parameters, their absence should be responded to with a TRANSPORTPARAMETERERROR. A similar argument applies to the absence of the TP, although I can see how one might use PROTOCOLVIOLATION here (note that this is still valid behavior with this PR, as every more specific error can be replaced with a PROTOCOL_VIOLATION, if an implementation wishes to do so).
Thanks. I think that this is fine. I will make a few editorial comments on the PR, but I think that the application of the agreed principles is correct.
If you take the suggestions here, I will mark this for inclusion in the next consensus call. (Otherwise, we should continue discussion.)

Discussion:
connection ID values in transport parameters and verifying them ensures that that an attacker cannot influence the choice of connection ID for a successful connection by injecting packets <del> carrying attacker-chosen connection IDs during the handshake.  An endpoint MUST treat any of the following as a connection error of type PROTOCOL_VIOLATION: </del> <ins> carrying attacker-chosen connection IDs during the handshake. </ins> <del> absence of the initial_source_connection_id transport parameter from either endpoint, </del> <ins> An endpoint MUST treat absence of the initial_source_connection_id transport parameter from either endpoint or absence of the original_destination_connection_id transport parameter from the server as a connection error of type TRANSPORT_PARAMETER_ERROR. </ins> <del> absence of the original_destination_connection_id transport parameter from the server, </del> <ins> An endpoint MUST treat the following as a connection error of type TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: </ins> absence of the retry_source_connection_id transport parameter from the server after receiving a Retry packet,
Change:
I don't see much point in doing the same for invariants, but I'm willing to take input on that choice.
The chairs just had a question from someone who wanted to cite "QUIC" on what document they should be citing. We responded that they should cite -transport, since we see this as the central document. Should we add brief notes to the documents saying "if you want to cite QUIC, cite -transport"?
That seems reasonable, since we say in there that accompanying documents describe TLS and recovery. Where are you thinking of adding that note?
As early as possible?
If you want to cite QUIC version 1, transport. If you want to cite QUIC all-up, invariants.
, or immediately after it, seems like as good a place as any.
I probably would have made it part of the preceding paragraph, but I don't feel strongly.

Discussion:
This document defines QUIC version 1, which conforms to the protocol invariants in QUIC-INVARIANTS. <ins> To refer to QUIC version 1, cite this document.  References to the limited set of version-independent properties of QUIC can cite QUIC- INVARIANTS. </ins> 1.2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Change:
by reversing the polarity of a SHOULD. Doesn't break interop, but it's always safer to send CANCEL_PUSH than to omit it, so let's not recommend omitting it under any circumstances.
The spec suggest that a server should send a CANCELPUSH to notify a client that it will not fulfill a PUSHPROMISE. The server should send CANCELPUSH before a push stream has been open. The server still can cancel a push stream after it has been created and that will have a similar effect as a CANCELPUSH frame. There is a small problem with that. If the server resets a push stream before client starts reading, the client may have not read the pushid from the stream and that pushid will never be fulfill or cancel for the client point of view. Should there be a sentence in the spec explaining this? Probably suggesting not to cancel a push stream until server is certain that client has read it, which is difficult. Should the spec suggest ot send CANCEL_PUSH even after a push stream has been created?
The server doesn't need to ensure that the push ID is read if CANCELPUSH is used, mostly. If the stream type is read, but not the push ID (which is entirely possible), then the client will know that there was a push and that it didn't happen, but can't connect that with the promise or cancellation. In that case, clients need to handle that. In fact, this highlights the value of CANCELPUSH in the case where the stream is reset.
This will not break interop either way. We can change the recommendation easily.
This issue and its fix has been pretty well discussed already. The proposal is borderline on a design change, so I've marked this as design to get some visibility during the next consensus call.
lgtm

Discussion:
or MAY take no action. When a server sends CANCEL_PUSH, it is indicating that it will not be <del> fulfilling a promise and has not created a push stream.  The client should not expect the corresponding promise to be fulfilled. </del> <ins> fulfilling a promise.  The client cannot expect the corresponding promise to be fulfilled, unless it has already received and processed the promised response.  A server SHOULD send a CANCEL_PUSH even if it has opened the corresponding stream. </ins> Sending CANCEL_PUSH has no direct effect on the state of existing <del> push streams.  A server SHOULD NOT send a CANCEL_PUSH when it has already created a corresponding push stream, and a client SHOULD NOT send a CANCEL_PUSH when it has already received a corresponding push stream.  If a push stream arrives after a client has sent CANCEL_PUSH, this MAY be treated as a stream error of type H3_STREAM_CREATION_ERROR. </del> <ins> push streams.  A client SHOULD NOT send a CANCEL_PUSH when it has already received a corresponding push stream.  A push stream could arrive after a client has sent CANCEL_PUSH, because a server might not have processed the CANCEL_PUSH.  The client SHOULD abort reading the stream with an error code of H3_REQUEST_CANCELLED. </ins> A CANCEL_PUSH frame is sent on the control stream.  Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be
Change:
The longer the draft sits in my edit buffer, the more opportunities I have to see this sort of thing.

Discussion:
RFC3629. The application-specific variant of CONNECTION_CLOSE (type 0x1d) can <del> only be sent using 0-RTT or 1-RTT packets (QUIC-TLS, Section 4). </del> <ins> only be sent using 0-RTT or 1-RTT packets; see Section 4 of QUIC-TLS. </ins> When an application wishes to abandon a connection during the handshake, an endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error code of APPLICATION_ERROR in an Initial or a Handshake
Change:
An attempt to make this slightly easier to read, based on feedback that this was hard to read and follow.
Looks good, but I think the paragraph on lines 1574 to 1582 might be best split too, into sub-paragraphs for each TP and how it's used.

Discussion:
fig-auth-cid-retry shows a similar handshake that includes a Retry packet. <del> For the handshakes in fig-auth-cid and fig-auth-cid-retry the client sets the value of the initial_source_connection_id transport parameter to "C1".  In fig-auth-cid-retry, the server sets original_destination_connection_id to "S1", </del> <ins> In both cases (fig-auth-cid and fig-auth-cid-retry), the client sets the value of the initial_source_connection_id transport parameter to "C1". When the handshake does not include a Retry (fig-auth-cid), the server sets original_destination_connection_id to "S1" and initial_source_connection_id to "S3".  In this case, the server does not include a retry_source_connection_id transport parameter. When the handshake includes a Retry (fig-auth-cid-retry), the server sets original_destination_connection_id to "S1", </ins> retry_source_connection_id to "S2", and initial_source_connection_id <del> to "S3".  In fig-auth-cid, the server sets original_destination_connection_id to "S1", initial_source_connection_id to "S3", and does not include retry_source_connection_id.  Each endpoint validates the transport parameters set by their peer, including the client confirming that retry_source_connection_id is absent if no Retry packet was processed. </del> <ins> to "S3". Each endpoint validates transport parameters set by the peer.  The client confirms that the retry_source_connection_id transport parameter is absent if it did not process a Retry packet. </ins> 7.4.
Change:
Section: Stream Final Size /An endpoint MUST NOT send data on a stream at or beyond the final size./ It seems reasonable not to send after the Final Size , but why is this a “MUST NOT”? The need to require this is not stated, and the reaction of the receiver appears to be ignore. Is this requirement justified?
Because the Final Size is used to synchronize flow control consumption. If the Final Size is not, in fact, the last data ever sent on a stream, the two sides will disagree about how much flow control credit has been consumed. The reaction of the receiver isn't to ignore; in the very next paragraph:
Aha, I knew there must be a reason - could we add something like this sentence? "This is used to synchronize flow control consumption between the endpoints."
:+1: LGTM modulo a nitpick.Some suggestions

Discussion:
generally, this is one higher than the offset of the byte with the largest offset sent on the stream, or zero if no bytes were sent. <del> For a stream that is reset, the final size is carried explicitly in a RESET_STREAM frame.  Otherwise, the final size is the offset plus the length of a STREAM frame marked with a FIN flag, or 0 in the case of incoming unidirectional streams. </del> <ins> The final size of a stream is always signaled to the recipient.  The final size is the sum of the Offset and Length fields of a STREAM frame with a FIN flag, noting that these fields might be implicit. Alternatively, the Final Size field of a RESET_STREAM frame carries this value.  This ensures that all ways that a stream can be closed result in the number of bytes on the stream being reliably transmitted.  This guarantees that both endpoints agree on how much flow control credit was consumed by the stream. </ins> An endpoint will know the final size for a stream when the receiving part of the stream enters the "Size Known" or "Reset Recvd" state
Change:
We didn't really need to use a new "term" for the concept of including multiple frames in a packet. The use of "bundle" implied more than what was really happening. Using plain words is probably better.
What does “bundling” refer to? I think I might now understand coalescing, but I don’t understand if bundling is subtly different?
Several instances I see in the draft refer to the situation where an endpoint is required to send a packet containing certain frames. The endpoint might opportunistically add other frames, not mandated to be sent, as long as it's doing the work of generating and sending a packet anyway. These opportunistically added frames are "bundled" with the mandatory frames. More generally, the term refers to selecting a collection of frames waiting to be sent when generating an outgoing packet.
(Versus coalescing, which is putting more than one packet in a single UDP datagram.)
tbh, I think the text reads a lot better with bundling.Thanks! Clearer is better.

Discussion:
A sender bundles one or more frames in a QUIC packet; see frames. A sender can minimize per-packet bandwidth and computational costs by <del> bundling as many frames as possible within a QUIC packet.  A sender MAY wait for a short period of time to bundle multiple frames before </del> <ins> including as many frames as possible in each QUIC packet.  A sender MAY wait for a short period of time to collect multiple frames before </ins> sending a packet that is not maximally packed, to avoid sending out large numbers of small packets.  An implementation MAY use knowledge about application sending behavior or heuristics to determine whether

across multiple streams.  When a packet loss occurs, only streams with data in that packet are blocked waiting for a retransmission to be received, while other streams can continue making progress.  Note <del> that when data from multiple streams is bundled into a single QUIC </del> <ins> that when data from multiple streams is included in a single QUIC </ins> packet, loss of that packet blocks all those streams from making <del> progress.  Implementations are advised to bundle as few streams as </del> <ins> progress.  Implementations are advised to include as few streams as </ins> necessary in outgoing packets without losing transmission efficiency to underfilled packets.
Change:
I think that this can be this simple.
section: Address Validation for Future Connections The following RFC2119 keyword appears within a note, which seems wrong, could the RFC2119 recommendation be moved outside of the note?: /A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly./

Discussion:
token, it MUST attempt to validate the token, unless it has already completed address validation.  If the token is invalid then the server SHOULD proceed as if the client did not have a validated <del> address, including potentially sending a Retry.  If the validation succeeds, the server SHOULD then allow the handshake to proceed. </del> <ins> address, including potentially sending a Retry.  A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly.  If the validation succeeds, the server SHOULD then allow the handshake to proceed. </ins> The rationale for treating the client as unvalidated rather than discarding the packet is that the client might have received the token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if the packet is <del> discarded.  A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly. </del> <ins> discarded. </ins> In a stateless design, a server can use encrypted and authenticated tokens to pass information to clients that the server can later
Change:
I did not add a citation for MAX_PLPMTU as that is subtly different and that seems like it would be more of a liability than a help in this case.
Text looks OK.
In maxudppayloadsize (0x03) the following text seems good: /This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the endpoint and not the path./ could it refer to the appropriate section in the QUIC spec? In DPLPMTUD the same value is known as “MAXPLPMTU”, Section 5.3.1 - in case you wish to cite that.
MAX_PLPMTU is slightly different as it refers to the IP layer, but you are right that it constrains the same underlying variable. I'll add a cross-reference though.

Discussion:
This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the <del> endpoint and not the path.  It is expected that this is the space an endpoint dedicates to holding incoming packets. </del> <ins> endpoint and not the path; see packet-size.  It is expected that this is the space an endpoint dedicates to holding incoming packets. </ins> The initial maximum data parameter is an integer value that contains the initial value for the maximum amount of data that can