Draft: draft-ietf-quic-recovery

Commentary: 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 . 
 Thank you for the review . Would you ming checking if the updated text has what you have suggested ? 
 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 was n't sure if this would be design or not , but now that the PR is complete , I believe it 's editorial , as 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 make the call about whether he thinks this is design then . 
 LGTM - thanks , Can you resolve the merge conflict ?
Paragraph (version A):
On the first RTT sample for a network path, the smoothed_rtt is set
to the latest_rtt.
Paragraph (version B):
smoothed_rtt and rttvar are computed as follows, similar to RFC6298.
Paragraph (version B):
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.
Paragraph (version A):
The RECOMMENDED time threshold (kTimeThreshold), expressed as a
round-trip time multiplier, is 9/8.
Paragraph (version B):
The RECOMMENDED time threshold (kTimeThreshold), expressed as a
round-trip time multiplier, is 9/8.  The RECOMMENDED value of the
timer granularity (kGranularity) is 1ms.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
The first three packets are determined to be lost when the
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.