Original text:
4.7. QUIC uses a probe timeout (PTO; see pto), with a timer based on TCP's <del> RTO computation; see RFC6297.  QUIC's PTO includes the peer's maximum expected acknowledgment delay instead of using a fixed minimum timeout. </del>  Similar to the RACK-TLP loss detection algorithm for TCP (RACK), QUIC does not collapse the congestion window when the PTO expires, since a retransmissions and may result in degraded performance due to the actions of the congestion controller upon detecting loss. Implementations can detect spurious retransmissions and increase the <del> reordering threshold in packets or time to reduce future spurious </del>  retransmissions and loss events.  Implementations with adaptive time thresholds MAY choose to start with smaller initial reordering thresholds to minimize recovery latency. constants-of-interest) for a new path, but the delay SHOULD NOT be considered an RTT sample. <del> Initial packets and Handshake packets could be never acknowledged, but they are removed from bytes in flight when the Initial and Handshake keys are discarded, as described below in discarding- packets.  When Initial or Handshake keys are discarded, the PTO and loss detection timers MUST be reset, because discarding keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. </del>  6.2.2.1. from the client, it is the client's responsibility to send packets to unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, <del> the client MUST set the probe timer if the client has not received an </del>  acknowledgment for any of its Handshake packets and the handshake is not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no packets in flight.  When the PTO fires, the client MUST send a arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. <del> It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost.  However, Initial and Handshake secrets are discarded as soon as handshake and 1-RTT keys are proven to be available to both client and server; see Section 4.9.1 of QUIC-TLS. </del>  7. When bytes in flight is smaller than the congestion window and sending is not pacing limited, the congestion window is under- <del> utilized.  When this occurs, the congestion window SHOULD NOT be increased in either slow start or congestion avoidance.  This can happen due to insufficient application data or flow control limits. </del>  A sender that paces packets (see pacing) might delay sending packets and not fully utilize the congestion window due to this delay.  A

Reviewer comments:
Addresses comments 2, 4, 7, 8, 9, and 11.
one tiny suggestion, but lgtm -- thanks for doing this!

Revised text:
4.7. QUIC uses a probe timeout (PTO; see pto), with a timer based on TCP's  <ins> retransmission timeout (RTO) computation; see RFC6298.  QUIC's PTO includes the peer's maximum expected acknowledgment delay instead of using a fixed minimum timeout. </ins> Similar to the RACK-TLP loss detection algorithm for TCP (RACK), QUIC does not collapse the congestion window when the PTO expires, since a retransmissions and may result in degraded performance due to the actions of the congestion controller upon detecting loss. Implementations can detect spurious retransmissions and increase the  <ins> packet or time reordering threshold to reduce future spurious </ins> retransmissions and loss events.  Implementations with adaptive time thresholds MAY choose to start with smaller initial reordering thresholds to minimize recovery latency. constants-of-interest) for a new path, but the delay SHOULD NOT be considered an RTT sample.  <ins> When the Initial keys and Handshake keys are discarded (discarding- packets), any Initial packets and Handshake packets can no longer be acknowledged, so they are removed from bytes in flight.  When Initial or Handshake keys are discarded, the PTO and loss detection timers MUST be reset, because discarding keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. </ins> 6.2.2.1. from the client, it is the client's responsibility to send packets to unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is,  <ins> the client MUST set the PTO timer if the client has not received an </ins> acknowledgment for any of its Handshake packets and the handshake is not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no packets in flight.  When the PTO fires, the client MUST send a arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent.  <ins> It is expected that keys are discarded at some time after the packets encrypted with them are either acknowledged or declared lost. However, Initial and Handshake secrets are discarded as soon as handshake and 1-RTT keys are proven to be available to both client and server; see Section 4.9.1 of QUIC-TLS. </ins> 7. When bytes in flight is smaller than the congestion window and sending is not pacing limited, the congestion window is under-  <ins> utilized.  This can happen due to insufficient application data or flow control limits.  When this occurs, the congestion window SHOULD NOT be increased in either slow start or congestion avoidance. </ins> A sender that paces packets (see pacing) might delay sending packets and not fully utilize the congestion window due to this delay.  A