Original text:
a peer to maintain a more accurate round-trip time estimate (see Section 13.2 of QUIC-TRANSPORT).  4. At a high level, an endpoint measures the time from when a packet was

Reviewer comments:
and by documenting the core difference between TCP's RTO and QUIC's PTO.
QUIC: TCP:
Discussed in ZRH. Difference to be explained as an editorial comment.
Specifically, we'll add some text that describes how PTO in QUIC is different than RTO and TLP in TCP.
"When an ACK frame is received that establishes loss of all in-flight packets sent over a long enough period of time, the network is considered to be experiencing persistent congestion." QUIC declares persistent congestion only upon receipt of an ACK for a packet sent after entering loss recovery. This means that the cwnd will remain large and usable even if there is prolonged network silence with packets outstanding. If the state of the transport was application limited, this can cause a large burst on the network. In TCP, an RTO causes immediate drop of the cwnd to min_cwnd. Ideally QUIC should drop the cwnd in the same timescale as TCP would. Typically minrto for the Internet is 200 msec or 300 msec (and larger if the RTT is larger).
I do not want to change the existing algorithm, because the app-limited case is the case when the sender is strictly less aggressive than the congestion controller limits, so I believe it's less likely to cause issues for the network. I can write text pointing out this difference.
Discussed in ZRH. Proposed resolution is to close with no action. Editorial issue to explain the difference to TCP and its safety.
NAME this was in the latest batch of consensus calls, but you didn't mark it has having consensus. Can you review please?
You are correct, I missed this one somehow sorry so moving to has consensus
LGTM

Revised text:
a peer to maintain a more accurate round-trip time estimate (see Section 13.2 of QUIC-TRANSPORT). <ins> 3.1.7. 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 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 congestion window upon expiry of an RTO.  Instead of collapsing the congestion window and declaring everything in-flight lost, QUIC allows probe packets to temporarily exceed the congestion window whenever the timer expires. In doing this, QUIC avoids unnecessary congestion window reductions, obviating the need for correcting mechanisms such as F-RTO RFC5682. Since QUIC does not collapse the congestion window on a PTO expiration, a QUIC sender is not limited from sending more in-flight packets after a PTO expiration if it still has available congestion window.  This occurs when a sender is application-limited and the PTO timer expires.  This is more aggressive than TCP's RTO mechanism when application-limited, but identical when not application-limited. A single packet loss at the tail does not indicate persistent congestion, so QUIC specifies a time-based definition to ensure one or more packets are sent prior to a dramatic decrease in congestion window; see persistent-congestion. </ins> 4. At a high level, an endpoint measures the time from when a packet was