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

[ianswett <[e-mail]>]

@ianswett commented on this pull request.

I'd like to better understand the recovery change you're making and it's motivation.

>  When ack-eliciting packets in multiple packet number spaces are in flight,
-the timer MUST be set for the packet number space with the earliest timeout,
-with one exception. 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 a client from retransmitting a 0-RTT
-packet on a PTO expiration before confirming that the server is able to
-decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on
-a PTO expiration before it has the keys to process an acknowledgement.
+the timer MUST be set to the earlier value of the Initial and Handshake packet
+number spaces.

I think this is a behavior change and I don't think it's always correct, since it causes the timer to never be armed for ApplicationData anytime anything in Handshake is in flight.  There are cases the Handshake keys have been dropped by the server and the Handshake data will never be acknowledged.

> @@ -518,14 +518,20 @@ 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

Can you clarify what the goal of changing this section is?  I feel it was clearer before, but I suspect there's something you're trying to improve.

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