Re: [quicwg/base-drafts] Allow endpoints to generate traffic keys asynchronously (#3874)

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.



> @@ -518,14 +518,22 @@ or when Initial or Handshake keys are discarded. This ensures the PTO is always
 set based on the latest RTT information and for the last sent packet in the
 correct packet number space.
 
+When setting the PTO timer, the ApplicationData packet number space (Section
+4.1.1 of {{QUIC-TLS}}) MUST be ignored until the handshake completes. Not arming
+the PTO for ApplicationData prevents unnecessary transmissions on a PTO
+expiration, such as:
+
+* an endpoint sending probe packets before obtaining the keys to process an
+  acknowledgement,
+
+* a client sending 0-RTT probe packets before confirming that the server is able
+  to decrypt 0-RTT packets, or

Maybe this can be made more generic: 

A receiver might lack the keys necessary to process packets, or the sender might lack the keys necessary to process acknowledgments.  This occurs when the client sends 0-RTT packets as the server might not accept 0-RTT and the client will not have 1-RTT keys for processing acknowledgments until the handshake completes.  This occurs for 1-RTT packets as either endpoint might not have the ability to read until the handshake is complete.

Though this made me realize: we say "complete", but if you need to know that you have keys AND you peer has keys, you need to wait for "confirmed".

-- 
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/3874#pullrequestreview-445236854