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

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.

The recovery piece is much clearer, but I think we need a different solution for the TLS stuff.

>  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 for the packet number space with the earliest timeout.

It probably pays to be precise in this case.  You could instead say that you set the Initial or Handshake PTO timer based on which space has the earliest timeout.

> @@ -501,9 +501,11 @@ handshake, new data is requested from TLS after providing received data.
 As keys for new encryption levels become available, TLS provides QUIC with those
 keys.  Separately, as keys at a given encryption level become available to TLS,
 TLS indicates to QUIC that reading or writing keys at that encryption level are
-available.  These events are not asynchronous; they always occur immediately
-after TLS is provided with new handshake bytes, or after TLS produces handshake
-bytes.
+available.  While waiting for TLS to provide these keys, an endpoint SHOULD
+buffer the received packets marked as protected by the keys yet to be provided,
+and process them once those keys become available.  If the keys are generated
+asynchronously, an endpoint MAY continue responding to the received packets that
+are processable while waiting for TLS to provide these keys.

I think that this fixates on the wrong aspect of the problem.  This text can instead just say "if keys are not yet available, and endpoint MAY continue to process those packets for which it has keys".  Or similar.

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