Change:
From a full read en route to Prague.
Thanks Jana, suggestions taken and "Clearer Loss Epoch" rewritten.

Discussion:
Any packet containing only one or more ACK frame(s). <del> Packets are considered in-flight when they have been sent and neither acknowledged nor declared lost, and they are not ACK-only. </del> <ins> 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. </ins> All frames besides ACK or PADDING are considered ack-eliciting.

3.1.3. <ins> QUIC ends a loss epoch when a packet sent after loss is declared is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it correctly once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. 3.1.4. </ins> QUIC ACKs contain information that is similar to TCP SACK, but QUIC does not allow any acked packet to be reneged, greatly simplifying implementations on both sides and reducing memory pressure on the sender. <del> 3.1.4. </del> <ins> 3.1.5. </ins> QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges.  In high loss environments, this speeds recovery, reduces spurious retransmits, and ensures forward progress without relying on timeouts. <del> 3.1.5. </del> <ins> 3.1.6. </ins> QUIC endpoints measure the delay incurred between when a packet is received and when the corresponding acknowledgment is sent, allowing

6.1.2. <del> Once a later packet has been acknowledged, an endpoint SHOULD declare an earlier packet lost if it was sent a threshold amount of time in the past.  The time threshold is computed as kTimeThreshold * max(SRTT, latest_RTT).  If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time. The RECOMMENDED time threshold (kTimeThreshold), expressed as a round-trip time multiplier, is 9/8. </del> <ins> Once a later packet packet within the same packet number space has been acknowledged, an endpoint SHOULD declare an earlier packet lost if it was sent a threshold amount of time in the past.  To avoid declaring packets as lost too early, this time threshold MUST be set to at least kGranularity.  The time threshold is: ~~~ kTimeThreshold * max(SRTT, latest_RTT, kGranularity) ~~~ If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time. </ins> Using max(SRTT, latest_RTT) protects from the two following cases:

sustained increase in the actual RTT, but the smoothed SRTT has not yet caught up. <del> An endpoint might consistently record RTT samples as 0 in extremely low latency networks, leading to a smoothed_rtt of 0.  Consequently, the endpoint could declare all earlier packets as lost immediately upon receiving an acknowledgement for a later packet.  That is, the endpoint would not provide any reordering tolerance.  To avoid declaring packets as lost too early, the time threshold MUST be set to at least kGranularity (defined in ld-consts-of-interest). </del> <ins> The RECOMMENDED time threshold (kTimeThreshold), expressed as a round-trip time multiplier, is 9/8. </ins> Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT

QUIC begins every connection in slow start and exits slow start upon loss or upon increase in the ECN-CE counter.  QUIC re-enters slow <del> start anytime the congestion window is less than ssthresh, which typically only occurs after an PTO.  While in slow start, QUIC increases the congestion window by the number of bytes acknowledged when each acknowledgment is processed. </del> <ins> start anytime the congestion window is less than ssthresh, which only occurs after persistent congestion is declared.  While in slow start, QUIC increases the congestion window by the number of bytes acknowledged when each acknowledgment is processed. </ins> 7.3.