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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> @@ -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.

As there's a chance where a client receives an 1-RTT packet before it receives Initial and Handshake packets, I think it'd be more natural to cover that case too.

Maybe s/When a client receives Handshake packets/When a client receives Handshake or 1-RTT packets/.

> @@ -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.

Am I correct in assuming that this way of setting the PTO is to be used *only until* an endpoint learns the RTT?

Consider the case where the server sends three datagrams (Initial1(CRYPTO+ACK), Initial2(CRYPTO), Handshake1(CRYPTO)) as its first flight. When Initial2 gets dropped but other packets are received by the client, the client would have an RTT estimate (as it processes the ACK in Initial1), but also have an undecryptable Handshake packet too, which this section discusses about.

My intuition is that the provision of this paragraph should not be invoked in such a case, as RTT has already been learnt.

If that is the case, it might be a good idea to clarify that the section is about estimating PTO until an RTT estimation is obtained.

-- 
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-308223551