jiebi/CodeConvo huggingface dataset:
Change:
From recovery to transport.
currently states: NAME notes that nowhere do we define precisely how a receiver might do this detection. Specifically a receiver could implement this as when a newly received packet is smaller than the largest acked, or as when the packet is larger than largest acked plus one. Doing the former would actually not help with loss detection, since the receiver would not ack immediately on a gap. We should add some text codifying the latter.
That section used to be in recovery, where we have a definition already(which is now unused), so I'd suggest we move it over. "Out-of-order Packets: : Packets that do not increase the largest received packet number for its packet number space by exactly one. Packets arrive out of order when earlier packets are lost or delayed."
Isn't this supposed to be "Packets that increase the largest received packet number ... by more than one." in this case?
Thinking about this some more, there are three possible definitions here for out-of-order: a newly received packet is greater than largest received by more than one, a newly received packet is smaller than the largest received, both (1) and (2). (1) is the obvious case where a loss happens and a subsequent packet is received. (2) is the reordering case, where an earlier packet is delivered later, and while it does not indicate loss, it does indicate that a gap was filled. It's useful to signal (2) as well immediately to prevent a sender from unnecessarily retransmitting what it believes to be a missing packet. The definition we want for "out-of-order" is the one that is most useful for determining when to send an immediate ack. The definition in the PR captures both (1) and (2), and is probably the one we want.
NAME : If you believe we ought to change the definition, please re-open, and we can continue this discussion.
Thank you for working on this.

Discussion:
receiver within the maximum ack delay and are called ack-eliciting packets. <del> Packets that do not increase the largest received packet number for its packet number space by exactly one.  Packets arrive out of order when earlier packets are lost or delayed. </del> 3. All transmissions in QUIC are sent with a packet-level header, which

CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment (see sending-acknowledgements). <ins> A packet that does not increase the largest received packet number for its packet number space by exactly one.  A packet can arrive out of order if it is delayed or if earlier packets are lost or delayed. </ins> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types of endpoint in QUIC: client and server.
Change:
Is "AEAD" a thing, or a descriptor? I read the original as "an AEAD [algorithm]", but this change seems to consider AEAD as a technique which can be applied.
I modeled this on the previous sentence that says (italics added): Note the absence of "an" in front of the italicized text. The "AEAD" in the second sentence is simply another way to write "authenticated encryption with additional data."

Discussion:
All QUIC packets except Version Negotiation packets use authenticated encryption with additional data (AEAD) RFC5116 to provide <del> confidentiality and integrity protection.  Retry packets use an AEAD to provide integrity protection.  Details of packet protection are found in QUIC-TLS; this section includes an overview of the process. </del> <ins> confidentiality and integrity protection.  Retry packets use AEAD to provide integrity protection.  Details of packet protection are found in QUIC-TLS; this section includes an overview of the process. </ins> Initial packets are protected using keys that are statically derived. This packet protection is not effective confidentiality protection.
Change:
Fixes issue .
The wording "between when ... and when..." or "between when ... and ..." is odd. There are two instances of this in .
Fixed by .
Not critical, perhaps, but I agree that this is less awkward.

Discussion:
the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. <del> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is subsequently used.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. </del> <ins> Unlike the token that is created for a Retry packet, which is used immediately, the token sent in the NEW_TOKEN frame might be used after some period of time has passed.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. </ins> A token issued with NEW_TOKEN MUST NOT include information that would allow values to be linked by an on-path observer to the connection on

13.2.5. <del> An endpoint measures the delays intentionally introduced between when the packet with the largest packet number is received and an acknowledgment is sent.  The endpoint encodes this delay in the Ack Delay field of an ACK frame (see frame-ack).  This allows the </del> <ins> An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the time an acknowledgment is sent.  The endpoint encodes this delay in the Ack Delay field of an ACK frame (see frame-ack).  This allows the </ins> receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed.  A packet might be held in the OS kernel
Change:
Just a proposal but I would prefer to remove the advertising slang ("decades of transport and security experience" and "makes it attractive").
Isn't the introduction the right place for ad copy, though? It describes what the document hopes to achieve and why it's worth doing. I think some of the rewording you've done here is an improvement, but I'm not convinced we should edit out the fact that we're trying to incorporate many years of work that hasn't been universally deployable.
I'm fine with this new language.

Discussion:
1. <del> QUIC is a new multiplexed and secure transport atop UDP.  QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport.  The QUIC protocol is described in QUIC-TRANSPORT. QUIC implements the spirit of existing TCP congestion control and </del> <ins> QUIC is a new multiplexed and secure transport protocol atop UDP, specified in QUIC-TRANSPORT.  This document describes congestion control and loss recovery for QUIC.  Mechanisms described in this document follow the spirit of existing TCP congestion control and </ins> loss recovery mechanisms, described in RFCs, various Internet-drafts, <del> and also those prevalent in the Linux TCP implementation.  This document describes QUIC congestion control and loss recovery, and where applicable, attributes the TCP equivalent in RFCs, Internet- drafts, academic papers, and/or TCP implementations. </del> <ins> or academic papers, and also those prevalent in TCP implementations. </ins> 2.
Change:
ACK-only was only even used in the definition part and in-flight can also be defined using ack-eliciting.
I just realised that padding is the "complicating" thing here. I still don't think we need to define "act-only" just for that but can rather be explicit about padding frames because otherwise this is easy to miss (as I did initially).
While the defined term is not used elsewhere, the phrases "Packets containing only ACK frames" and "Packets only containing ACK frames" are used. We should either eliminate the definition or explicitly use the defined term in those places.
Of Mike's options, I think that this makes sense. Fewer defined terms means lower fixed cognitive load when reading this. Less jargon = good.I re-read the other spots NAME mentioned and I believe the text is still correct, so I'm going to accept this. Thanks for the simplification.

Discussion:
Definitions of terms that are used in this document: <del> Any packet containing only one or more ACK frame(s). Packets are considered in-flight when they have been sent and are not ACK-only, and they are not acknowledged, declared lost, or abandoned along with old keys. </del> All frames other than ACK, PADDING, and CONNECTION_CLOSE are considered ack-eliciting.

receiver within the maximum ack delay and are called ack-eliciting packets. <ins> Packets are considered in-flight when they are ack-eliciting or contain a PADDING frame, and they have been sent but are not acknowledged, declared lost, or abandoned along with old keys. </ins> 3. All transmissions in QUIC are sent with a packet-level header, which
Change:
So here is an alternative proposal. However I also wonder why this paragraph is a MUST requirement while the previous statement (avoiding multiple samples of the same packet) is only a SHOULD? I would see it rather the other way around or both MUSTs.
This is a great improvement, thanks. One additional suggestion (for existing text) below.

Discussion:
An RTT sample MUST NOT be generated on receiving an ACK frame that does not newly acknowledge at least one ack-eliciting packet.  A peer <del> does not send an ACK frame on receiving only non-ack-eliciting packets, so an ACK frame that is subsequently sent can include an arbitrarily large Ack Delay field.  Ignoring such ACK frames avoids </del> <ins> usually does not send an ACK frame when only non-ack-eliciting packets are received.  Therefore an ACK frame that contains acknowledgements for only non-ack-eliciting packets could include an arbitrarily large Ack Delay value.  Ignoring such ACK frames avoids </ins> complications in subsequent smoothed_rtt and rttvar computations. A sender might generate multiple RTT samples per RTT when multiple
Change:
I proposed to remove this sentence here because all these values have actually been just defined in the previous sections. If a pointer to the appendix is desired, I think that should be mentioned earlier (e.g. in the intro already) that these lists existing in the appendix.
This seems fine to me, but I'd like NAME opinion as well.

Discussion:
When an ack-eliciting packet is transmitted, the sender schedules a timer for the PTO period as follows: <del> kGranularity, smoothed_rtt, rttvar, and max_ack_delay are defined in ld-consts-of-interest and ld-vars-of-interest. </del> The PTO period is the amount of time that a sender ought to wait for an acknowledgement of a sent packet.  This time period includes the estimated network roundtrip-time (smoothed_rtt), the variation in the
Change:
I think this statement should be normative. Not sure if this is a design issue or not.
I'm comfortable with this being editorial.

Discussion:
The life of a connection that is experiencing consecutive PTOs is limited by the endpoint's idle timeout. <del> The probe timer is not set if the time threshold time-threshold loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to </del> <ins> The probe timer MUST NOT be set if the time threshold time-threshold loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to </ins> spuriously retransmit data. 5.3.
Change:
Can someone please verify my work? I've written two implementations here and the values match, but I value independent validation.
NAME The value matches what quic-go is calculating. Will add this test vector as a unit test to my implementation.
Woo! I'm not as bad at this as I thought. Thanks NAME
I can also confirm that it verifies in Wireshark. (Likewise for the samples in Appendix A.)
The Retry integrity check is different than the protection for other packets, so it would make sense to include an example in the document. We need code for it in addition to the sample so that it can be updated more readily.
I also tested these vectors and it works fine. Thanks!

Discussion:
packet; the client has to rely on the exchange that included the Retry packet for that property. <del> test-vectors-initial contains test vectors for the initial packet encryption. </del> <ins> test-vectors contains test vectors for packet encryption. </ins> 5.3.
Change:
URL What are these "both conditions"? Also, can there be made a clear statement such that: all packets prior to Application PN space use long headers, and all packets in application PN space uses short headers? And, the table of frames with section references, would it make sense to add PN space columns with an X where a frame is applicable?
Multiple issues listed here. Please consider opening separate issues rather than lumping them all together. (1) This is old language we agreed to in Chicago. The requirement to shift to short headers was 1-RTT key availability and version agreement, to accommodate versions where the final keys might be available immediately (i.e. out-of-band agreement) but version negotiation still had to complete. However, that's a principle for the invariants or such a version, not a requirement of this QUIC version -- and the version negotiation language this referenced is gone now. (2) What is "Application PN space"? 0-RTT and 1-RTT? If so, then no -- 0-RTT packets carry application data but are long-header packets. (3) Unrelated editorial suggestion -- please open a separate issue.
(3) see

Discussion:
17.2. Long headers are used for packets that are sent prior to the <del> establishment of 1-RTT keys.  Once both conditions are met, a sender </del> <ins> establishment of 1-RTT keys.  Once 1-RTT keys are available, a sender </ins> switches to sending packets using the short header (short-header). The long form allows for special packets - such as the Version Negotiation packet - to be represented in this uniform fixed-length
Change:
The description here was a little over enthusiastic: it only enters the "Send" state when something is sent.
From -transport section 3.1: The event causing transition Ready->Send is the host initially having data to send on the stream, which is not the case when the receiving part has just been created in its initial Recv state. I think the send stream should stay in Ready until it has data. This also aligns better with similar text in 3.2. I suggest: p.s. see also , but which is more about being explicit about frames that cause stream creation... rather than this issue, which is about the state the new sending part starts in.
This issue can be closed -- see NAME commit above.
That commit hasn't been merged, and is sitting in a branch that doesn't appear to have an associated PR.
Oh -- sorry about that. I should have checked.
Wow, that sat there for ages. I made a PR.

Discussion:
which can allow for better stream prioritization. The sending part of a bidirectional stream initiated by a peer (type <del> 0 for a server, type 1 for a client) enters the "Ready" state then immediately transitions to the "Send" state if the receiving part enters the "Recv" state (stream-recv-states). </del> <ins> 0 for a server, type 1 for a client) starts in the "Ready" state when the receiving part is created. </ins> In the "Send" state, an endpoint transmits - and retransmits as necessary - stream data in STREAM frames.  The endpoint respects the
Change:
Unlike the other transport parameter definitions, there is no type specified for the parameter. I will assume that the type is an integer (like the other numeric-like transport parameters) and submit a PR to adjust the wording so that it is in line with the other transport parameter descriptions, if that's ok? Thanks for all the great work that you are all doing on getting QUIC specified!
Good catch! Looks like all the other values have a type either implicitly or explicitly stated. is indeed intended to be an integer, a PR to that effect would be great.
Thanks NAME

Discussion:
encoded in network byte order.  The CID Length field contains the length of the Connection ID field. <del> The maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes the connection ID received during the handshake, that received in the preferred_address transport parameter, and those received in NEW_CONNECTION_ID frames.  Unless a zero-length connection ID is being used, the value of the active_connection_id_limit parameter MUST be no less than 2.  If this transport parameter is absent, a default of 2 is assumed.  When a zero-length connection ID is being used, the active_connection_id_limit parameter MUST NOT be sent. </del> <ins> The active connection ID limit is an integer value specifying the maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes the connection ID received during the handshake, that received in the preferred_address transport parameter, and those received in NEW_CONNECTION_ID frames.  Unless a zero-length connection ID is being used, the value of the active_connection_id_limit parameter MUST be no less than 2.  If this transport parameter is absent, a default of 2 is assumed.  When a zero-length connection ID is being used, the active_connection_id_limit parameter MUST NOT be sent. </ins> If present, transport parameters that set initial flow control limits (initial_max_stream_data_bidi_local,
Change:
I'm happy to merge this as is, but I'll give it 24hrs in case others have comments.
This is weird in that it assumes some context that isn't provided: Perhaps instead: This "Because QUIC does not retransmit packets" thing is unnecessary. I'll open a PR.

Discussion:
6.4. <del> Recovery is a period of time beginning with detection of a lost packet or an increase in the ECN-CE counter.  Because QUIC does not retransmit packets, it defines the end of recovery as a packet sent after the start of recovery being acknowledged.  This is slightly different from TCP's definition of recovery, which ends when the lost packet that started recovery is acknowledged. </del> <ins> A recovery period is entered when loss or ECN-CE marking of a packet is detected.  A recovery period ends when a packet sent during the recovery period is acknowledged.  This is slightly different from TCP's definition of recovery, which ends when the lost packet that started recovery is acknowledged. </ins> The recovery period limits congestion window reduction to once per round trip.  During recovery, the congestion window remains unchanged
Change:
This text was pretty good and more or less covered the problem already, but I think that this might be slightly better. NAME if you don't like this, close this AND .
From a discussion on : We should probably have a conversation about the trade-offs with padding. Transport-layer padding is in some ways superior, like in how it can be granular to a single byte, which reserved streams and frames cannot do. But PADDING frames at the transport aren't retransmitted when lost, which could lead to some interesting attacks if packets can be suppressed by an attacker. If retransmissions aren't padded, boom. Originally posted by NAME in URL

Discussion:
HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in frame-reserved and stream-grease.  These methods of padding produce different results in <del> terms of the granularity of padding, the effect of packet loss and recovery, and how an implementation might control padding. </del> <ins> terms of the granularity of padding, how padding is arranged in relation to the information that is being protected, whether padding is applied in the case of packet loss, and how an implementation might control padding. </ins> 10.2.
Change:
The SHOULD is guidance for future extensions; if we'd like to downgrade that to non-normative, that's also fine.
I'm going to merge this.
Resolution of was to have no design change, but consider a "here be dragons" warning in the extension section paralleling what was added to HTTP/3 in . (The reasons, and therefore the guidance, are different at the transport layer -- we can't directly steal the text.)

Discussion:
receive one or more extension frame types with the one transport parameter. <ins> Extensions that modify or replace core protocol functionality (including frame types) will be difficult to combine with other extensions which modify or replace the same functionality unless the behavior of the combination is explicitly defined.  Such extensions SHOULD define their interaction with previously-defined extensions modifying the same protocol components. </ins> Extension frames MUST be congestion controlled and MUST cause an ACK frame to be sent.  The exception is extension frames that replace or supplement the ACK frame.  Extension frames are not included in flow
Change:
This goes most of the way to solving my perceived problem. I do wonder if we should also add a little bit more text to section 8 in this paragraph under certain circumstances. Implementations need to consider the impact on outstanding requests before making this choice. Perhaps just a reference e.g. "Implementations need to consider the impact on outstanding requests before making this choice, see {immediate-application-closure}."
But that section doesn't discuss the impact on outstanding requests, and it seems irrelevant to this topic. Can you expand on the connection you see?
to me, the choice to promote a stream error to a connection error is the choice to promote it to an immediate application close. Therefore the present statement about "impact on outstanding requests" is really about how to do/decide on graceful close with GOAWAY. If that is not the case, then I don't understand what other consierations my endpoint should make
That text was added as a compromise, basically reminding implementations that choosing to blow up their connection will lose any requests in flight, so you should have a good reason.
NAME I'm going to go ahead and merge this, since it addresses the original issue and stands by itself. If you think we need additional text elsewhere, can you open a separate issue?
Sure thing, I'll review again
Draft 25 section 5.3 says: any time. This results in sending a QUIC CONNECTIONCLOSE frame to the peer; the error code in this frame indicates to the peer why the connection is being closed. This doesn't specifically tie down H3-initiated closure to only use the application variant of CONNECTIONCLOSE (0x1d). This gets a bit strange when combined with later guidance to use H3 error codes or treat unknown error codes as

Discussion:
An HTTP/3 implementation can immediately close the QUIC connection at any time.  This results in sending a QUIC CONNECTION_CLOSE frame to <del> the peer; the error code in this frame indicates to the peer why the connection is being closed.  See errors for error codes which can be used when closing a connection. </del> <ins> the peer indicating that the application layer has terminated the connection.  The application error code in this frame indicates to the peer why the connection is being closed.  See errors for error codes which can be used when closing a connection in HTTP/3. </ins> Before closing the connection, a GOAWAY MAY be sent to allow the client to retry some requests.  Including the GOAWAY frame in the