Re: [quicwg/base-drafts] Retransmit server initial upon second Initial (#3080)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Thanks Kazuho, I made some minor updates, but can make further ones if you think they're needed.

> @@ -519,6 +519,26 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake packets prior to obtaining Handshake
+keys it may assume some or all of the server's Initial packets were lost.

True, suggestion taken.

> @@ -519,6 +519,26 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake packets prior to obtaining Handshake
+keys it may assume some or all of the server's Initial packets were lost.
+
+To speed handshake completion, either peer MAY send a packet containing
+unacknowledged Initial CRYPTO data subject to the path validation limits, as
+though the PTO expired. A client MAY send an ack-eliciting packet with no
+CRYPTO data if all Initial data has been acknowledged.  The PTO can only be
+shortened once in this way. Subsequently, the PTO uses the normal calculation
+with exponential backoff.

Good question.  It is aimed at the case when there are no RTT estimates, but I think there are a few cases like the one you're outlining where speeding up retransmission of the Initial2 data from a standard PTO is sensible, even if the server gets an ACK of Initial1.  The PTO in this case is expected to be 3*RTT (SRTT + 4*RTTVar) vs 1*RTT if you follow this optimization.  Given that, any suggestions on changes?

-- 
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/3080#pullrequestreview-356868389