initial RTO comparison

Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
quicwg · Oct 30, 2020 · a9d9aeb · a9d9aeb
1 parent ec93558
commit a9d9aeb
Showing 1 changed file with 2 additions and 2 deletions.
diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md
@@ -633,8 +633,8 @@ 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.  This
-results in handshakes starting with a PTO of 1 second, as recommended in
-{{?RFC6298}}.
+results in handshakes starting with a PTO of 1 second, as recommended
+for TCP's initial retransmission timeout; see Section 2 of {{?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