Original text:
smaller than the min_rtt.  This limits the underestimation that a misreporting peer can cause to the smoothed_rtt. <del> On the first RTT sample for a network path, the smoothed_rtt is set to the latest_rtt. </del> smoothed_rtt and rttvar are computed as follows, similar to RFC6298. <del> On the first RTT sample for a network path: </del>  On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows: 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 <del> least kGranularity.  The time threshold is: </del>  If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time. has not yet caught up. The RECOMMENDED time threshold (kTimeThreshold), expressed as a <del> round-trip time multiplier, is 9/8. </del>  Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT 5.2.2. <del> The initial probe timeout for a new connection or new path SHOULD be set to twice the initial RTT.  Resumed connections over the same network SHOULD use the previous connection's final smoothed RTT value as the resumed connection's initial RTT.  If no previous RTT is available, the initial RTT SHOULD be set to 500ms, resulting in a 1 second initial timeout as recommended in RFC6298. </del>  A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in <del> ld-consts-of-interest) for a new path, but the delay SHOULD NOT be considered an RTT sample. Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no data can be sent, then the PTO alarm MUST NOT be armed until datagrams have been received from the client. Since the server could be blocked until more packets are received 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, the client MUST set the probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. </del>  Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space.  5.2.3. When a server receives an Initial packet containing duplicate CRYPTO other packet number spaces with in-flight data, coalescing packets if possible.  When the PTO timer expires, and there is new or previously sent unacknowledged data, it MUST be sent. can be established by consecutive PTOs, but since the PTO timer is reset when a new ack-eliciting packet is sent, an explicit duration must be used to account for those cases where PTOs do not occur or <del> are substantially delayed.  This duration is computed as follows: </del>  For example, assume: scenario would illustrate persistent congestion: The first three packets are determined to be lost when the <del> acknowlegement of packet 4 is received at t=8.  The congestion period is calculated as the time between the oldest and newest lost packets: (3 - 0) = 3.  The duration for persistent congestion is equal to: (1 * kPersistentCongestionThreshold) = 3.  Because the threshold was reached and because none of the packets between the oldest and the newest packets are acknowledged, the network is considered to have experienced persistent congestion. </del>  When persistent congestion is established, the sender's congestion window MUST be reduced to the minimum congestion window

Reviewer comments:
As pointed out in , I think that we should assume same amount of RTT variance when there is no RTT sample and when there is one sample, because variance is unknown in both cases. This PR makes that change while keeping the initial PTO being the same (i.e. 1 second), and slightly simplifies the timeout logic.
NAME Thank you for the review. Would you ming checking if the updated text has what you have suggested?
NAME NAME Thank you for the suggestions. I've applied them.
For each connection, the loss detection timeout is defined as 2 InitialRTT. I wonder if this should be 3 InitialRTT instead, because, once you have one RTT sample, PTO is calculated as 3 * InitialRTT. I do not think we have a reason to believe that the variance of RTT (which applies as a multiplier here) increases when we obtain the first sample? PS. The other benefit of making these two consistent is that we can get rid of in SetLossDetectionTimer. It would be possible to always rely on PTO calculation.
I wasn't sure if this would be design or not, but now that the PR is complete, I believe it's editorial, as NAME PR changes the pseudocode, but proscribes exactly the same behavior as the existing text.
To be precise, there is one thing that does change, and that is the initial timeout when a connection is resumed on the same path. At the moment, the only variable we recommend to remember is SRTT, and when resuming a connection on the same path, use 2 SRTT as the initial timeout. The proposed change increases that to 3 SRTT. I think this is better than status-quo, assuming that we agree that RTTVAR should be 2 * sample when there is only one known sample.
Thanks for pointing that out, I noticed that the first time around and then forgot. I'll let NAME make the call about whether he thinks this is design then.
LGTM - thanks, NAME Can you resolve the merge conflict?

Revised text:
smaller than the min_rtt.  This limits the underestimation that a misreporting peer can cause to the smoothed_rtt.  smoothed_rtt and rttvar are computed as follows, similar to RFC6298.  <ins> When there are no samples for a network path, and on the first RTT sample for the network path: Before any RTT samples are available, the initial RTT is used as rtt_sample.  On the first RTT sample for the network path, that sample is used as rtt_sample.  This ensures that the first measurement erases the history of any persisted or default values. </ins> On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows: 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  <ins> least the local timer granularity, as indicated by the kGranularity constant.  The time threshold is: </ins> If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time. has not yet caught up. The RECOMMENDED time threshold (kTimeThreshold), expressed as a  <ins> round-trip time multiplier, is 9/8.  The RECOMMENDED value of the timer granularity (kGranularity) is 1ms. </ins> Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT 5.2.2.  <ins> Resumed connections over the same network MAY use the previous connection's final smoothed RTT value as the resumed connection's initial RTT.  When no previous RTT is available, the initial RTT SHOULD be set to 333ms, resulting in a 1 second initial timeout, as recommended in RFC6298. </ins> A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in  <ins> pto-handshake) for a new path, but the delay SHOULD NOT be considered an RTT sample. </ins> Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. <ins> 5.2.2.1. Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO alarm MUST NOT be armed until datagrams have been received from the client, because packets sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. Since the server could be blocked until more packets are received 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, the client MUST set the probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. </ins> 5.2.3. When a server receives an Initial packet containing duplicate CRYPTO other packet number spaces with in-flight data, coalescing packets if possible. <ins> If the sender wants to elicit a faster acknowledgement on PTO, it can skip a packet number to eliminate the ack delay. </ins> When the PTO timer expires, and there is new or previously sent unacknowledged data, it MUST be sent. can be established by consecutive PTOs, but since the PTO timer is reset when a new ack-eliciting packet is sent, an explicit duration must be used to account for those cases where PTOs do not occur or  <ins> are substantially delayed.  The rationale for this threshold is to enable a sender to use initial PTOs for aggressive probing, as TCP does with Tail Loss Probe (TLP) RACK, before establishing persistent congestion, as TCP does with a Retransmission Timeout (RTO) RFC5681. The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is approximately equivalent to two TLPs before an RTO in TCP. This duration is computed as follows: </ins> For example, assume: scenario would illustrate persistent congestion: The first three packets are determined to be lost when the  <ins> acknowledgement of packet 4 is received at t=8.  The congestion period is calculated as the time between the oldest and newest lost packets: (3 - 0) = 3.  The duration for persistent congestion is equal to: (1 * kPersistentCongestionThreshold) = 3.  Because the threshold was reached and because none of the packets between the oldest and the newest packets are acknowledged, the network is considered to have experienced persistent congestion. </ins> When persistent congestion is established, the sender's congestion window MUST be reduced to the minimum congestion window