Retransmit server initial upon second Initial

draft-ietf-quic-recovery.md

@@ -521,14 +521,15 @@ removed from bytes in flight when the Initial and Handshake keys are discarded.
 
 ### Speeding Up Handshake Completion
 
-When a server receives an Initial packet containing duplicate data in a CRYPTO frame, it can assume the client
-did not receive all of the server's CRYPTO data sent in Initial packets, or the client's estimated RTT is too
-small. When a client receives Handshake or 1-RTT packets prior to obtaining
-Handshake keys it may assume some or all of the server's Initial packets were
-lost.
-
-To speed up handshake completion under these conditions, an endpoint MAY send a packet containing
-unacknowledged CRYPTO data, subject to path validation limits, earlier than the PTO period.
+When a server receives an Initial packet containing duplicate CRYPTO data,
+it can assume the client did not receive all of the server's Initially
+encrypted CRYPTO data, or the client's estimated RTT is too small. When a
+client receives Handshake or 1-RTT packets prior to obtaining Handshake keys,
+it may assume some or all of the server's Initial packets were lost.
+
+To speed up handshake completion under these conditions, an endpoint MAY send
+a packet containing unacknowledged CRYPTO data earlier than the PTO expiry,
+subject to address validation limits. (see Section 8.1 of {{QUIC-TRANSPORT}})
 
 Peers can also use coalesced packets to ensure that each datagram elicits at least
 one acknowledgement.  For example, clients can coalesce an Initial packet