Draft: draft-ietf-quic-recovery

Commentary: Address validation can use 3*PTO , just taking the maximum of the old and new path PTO . The idea of initial timeout is easily replaced in recovery by instead describing the effect on the PTO . The net effect is the same , except that new paths often have to include the maximum ACK delay , which this does n't incorporate . 
 A quick look in the reference did not show what units of time you are using in the protocol - maybe I missed it ? 
 is set to 333ms . Not sure why a  between two values needs to define the unit in the first place though . 
 is not defined in -transport , and  was ( probably ) only reviewing the document in isolation . 
 a  needs to ensure both values use the same units . But provided that they do , I agree . 
 Maybe it 's easier to say that these are all physical quantities , or numbers with units . In the specification , we use seconds , milliseconds , microseconds . That 's fine , because we know how to align the units when we make calculations ( e.g. ,  ) . 
 PR proposes removing the text in question . Of course , it does n't matter what time units are in use in this case . I 'm fairly confident that where units matter ( i.e. , we base the value on a constant ) , the units are explicit . Here , the units are part of the definition of the variables . 
 As  points out , the offending text was removed . Not seeing anything to be done here , so I 'm closing the issue . 
 says " initial timeout ( that is , ) " . But I do n't think that we have this initial timeout concept in recovery any more ; we . Should this just be now ? The result is that the is meaningless as the PTO is when initialized . Or is this the PTO on the pre - existing path ? 
 I think this is the case . Notice " current . " Therefore I belive that the formula should be . 
 Changing 2kInitialRtt to 3kInitialRtt and 6kInitialRtt to 9kInitialRtt seems like the simplest fix since we do n't define an initial_PTO variable anywhere in the documents . 
 I assume that the choice between and is purely editorial . Either works for me . 
 I prefer with some changes that I 've noted on the PR . 
 I think this is correct . LGTM , but waiting for to take a look .
Paragraph (version A):
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):
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.  This results in handshakes starting with a
PTO of 1 second, as recommended for TCP's initial retransmission
timeout; see Section 2 of RFC6298.
Paragraph (version B):
Endpoints SHOULD abandon path validation based on a timer.  When
setting this timer, implementations are cautioned that the new path
could have a longer round-trip time than the original.  A value of
three times the larger of the current Probe Timeout (PTO) or the PTO
for the new path (that is, using kInitialRtt as defined in QUIC-
RECOVERY) is RECOMMENDED.