Change:
From URL, minus the question of limiting bursts, which is in Issue Section 2 " are not acknowledged, declared lost, or abandoned along with old keys." --> are not acknowledged, declared lost, or discarded along with old keys." Discarding is the term used in the rest of the doc notably in section 2.4. I see some reference to "abandon packets" in the transport draft as well. Would be good to use the same term for consistency everywhere. Section 4.4. "does not allow any acked packet to be reneged" --> "does not allow any acknowledged packet to be reneged" Section 4.7 "QUIC uses a probe timeout (see Section 6.2)," --> "QUIC uses a Probe Timeout (PTO) (see Section 6.2)," Section 5.2 "If the path's actual RTT increases, the minrtt will not adapt to it, allowing future RTT samples that are smaller than the new RTT be included in smoothedrtt." Would it safer to reset minrtt after persistent congestion is declared. This is important so we can adapt to a consistent spike in RTT as a result of a path change. Section 6.1.1 "Algorithms that increase the reordering threshold after spuriously detecting losses, such as TCP-NCR [RFC4653], have proven to be useful in TCP and are expected to at least as useful in QUIC." It might be better to refer to RACK here which has an optional feature to increase reorder threshold in time. I don't know of any major implementations that do TCP-NCR but maybe I am mistaken. Section 6.2.1 "time threshold Section 6.1.2" --> time threshold (Section 6.1.2) “The life of a connection that is experiencing consecutive PTOs is limited by the endpoint's idle timeout.” Is there any specification of recommended values for idle timeout? Any values lower than 9 seconds could adversely impact preserving of connectivity during VM live migration. Section 6.2.4 "If the sender wants to elicit a faster acknowledgement on PTO, it can skip a packet number to eliminate the ack delay." This adds some unnecessary complexity. Given that endpoint MAY send two full-sized datagrams, isn't that a better technique than skipping packet numbers? Section 7.8 "The congestion period is calculated as the time between the oldest and newest lost packets: (3 - 0) = 3." --> "The congestion period is calculated as the sent time difference between the oldest and newest lost packets: (3 - 0) = 3." It might be worth noting that persistent congestion can be declared without sending a PTO. Particularly because the example assumes PTOs. In the case where app kept on periodically sending new data and no ACKs came back for the threshold and then an ACK came back and declared all packets sent before it as lost. Section 8.2 "Endpoints can use PADDING frames or bundle acknowledgments with other frames to reduce leaked information." A reminder should be added here that PADDING counts towards in-flight so there is a possible impact on performance. Section B.8 The function AreAllPacketsLost does not have any pseudocode.
NAME The last item is pointed out in . As I wrote in , NAME suggested an example implementation. If you think it is reasonable, I will make a PR.
I've addressed the editorial bits in . The rest are addressed below. We don't have a recommended value for Idle timeout, but it the states the following: That said, the peer's is known to both sides. If you find that the peer's timeout is too short for your purposes, you can keep the connection alive through PINGs. On faster acknowledgement when PTO: yes, sending two packets works just fine. Skipping packet numbers is not something you need to do -- so the additional complexity concern is only for those who want to go do it -- it's just something that an implementation can do to get an immediate ack anytime in the connection.On PTOs and persistent congestion, there's text at the top of the section that calls this out explicitly: Nevertheless, I've added a sentence at the end of the example description. AreAllPacketsLost is in .
Marking this editorial, since the design one moved out.
One suggestion We don't do this, but there is a plan. URL shows the plan that we haven't implemented. The idea is that the TLS stack exports an encryption primitive, which then performs nonce generation within the PKCS module according to the TLS rules. PKCS has the necessary interfaces. Decryption can't work that way and so doesn't: the caller has to provide the number. I don't know if FIPS insists on anti-replay tracking within the module, but we don't do that (and likely can't).

Discussion:
Packets are considered in-flight when they are ack-eliciting or contain a PADDING frame, and they have been sent but are not <del> acknowledged, declared lost, or abandoned along with old keys. </del> <ins> acknowledged, declared lost, or discarded along with old keys. </ins> 3.

4.7. <del> QUIC uses a probe timeout (see pto), with a timer based on TCP's RTO computation.  QUIC's PTO includes the peer's maximum expected </del> <ins> QUIC uses a probe timeout (PTO; see pto), with a timer based on TCP's RTO computation.  QUIC's PTO includes the peer's maximum expected </ins> acknowledgement delay instead of using a fixed minimum timeout.  QUIC does not collapse the congestion window until persistent congestion (persistent-congestion) is declared, unlike TCP, which collapses the

If a packet is lost, the QUIC transport needs to recover from that loss, such as by retransmitting the data, sending an updated frame, <del> or abandoning the frame.  For more information, see Section 13.3 of </del> <ins> or discarding the frame.  For more information, see Section 13.3 of </ins> QUIC-TRANSPORT. Loss detection is separate per packet number space, unlike RTT

implementations SHOULD NOT use a packet threshold less than 3; see RFC5681. <del> Some networks may exhibit higher degrees of reordering, causing a sender to detect spurious losses.  Algorithms that increase the reordering threshold after spuriously detecting losses, such as TCP- NCR (RFC4653), have proven to be useful in TCP and are expected to be at least as useful in QUIC.  Re-ordering could be more common with QUIC than TCP, because network elements cannot observe and fix the order of out-of-order packets. </del> <ins> Some networks may exhibit higher degrees of packet reordering, causing a sender to detect spurious losses.  Additionally, packet reordering could be more common with QUIC than TCP, because network elements that could observe and fix the order of reordered TCP packets cannot do it with QUIC.  Algorithms that increase the reordering threshold after spuriously detecting losses, such as RACK RACK, have proven to be useful in TCP and are expected to at least as useful in QUIC. </ins> 6.1.2.

Packets that carry only ACK frames can be heuristically identified by observing packet size.  Acknowledgement patterns may expose <del> information about link characteristics or application behavior. Endpoints can use PADDING frames or bundle acknowledgments with other frames to reduce leaked information. </del> <ins> information about link characteristics or application behavior.  To reduce leaked information, endpoints can bundle acknowledgments with other frames, or they can use PADDING frames at a potential cost to performance. </ins> 8.3.