Stop using initial timeout

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 doesn't incorporate.

Closes #4261.
Closes #4262.

draft-ietf-quic-recovery.md

@@ -632,8 +632,9 @@ in most cases and is less likely to spuriously retransmit data.
 
 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}}.
+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 in
+{{?RFC6298}}.
 
 A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a
 PATH_RESPONSE to set the initial RTT (see kInitialRtt in

draft-ietf-quic-transport.md

@@ -2284,11 +2284,11 @@ abandons its attempt to validate the path.
 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 initial timeout (that is, 2*kInitialRtt) as
-defined in {{QUIC-RECOVERY}} is RECOMMENDED.  That is:
+current Probe Timeout (PTO) or the PTO for the new path (that is, using
+kInitialRtt as defined in {{QUIC-RECOVERY}}) is RECOMMENDED.  That is:
 
 ~~~
-   validation_timeout = max(3*PTO, 6*kInitialRtt)
+   validation_timeout = 3*max(PTO_current, PTO_new)
 ~~~
 
 This timeout allows for multiple PTOs to expire prior to failing path