Re: [quicwg/base-drafts] Merge Crypto timeout and PTO (#2806)

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.



> +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, or if the network changes, the initial RTT SHOULD
+be set to 500ms, resulting in a 1 second initial timeout as recommended in
+{{?RFC6298}}.
+
+A connection MAY use the delay between sending a PATH_CHALLENGE and receiving
+a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
+be considered an RTT sample.
+
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
+If not all unacknowledged CRYPTO data can be sent, then all unacknowledged
+CRYPTO data sent in Initial packets should be retransmitted.  If no data can be
+sent, then no alarm should be armed until data has been received from the
+client.

The idle timeout is a transport concept, it has nothing to do with loss recovery.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2806#discussion_r295170421