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

[ianswett <[e-mail]>]

@ianswett commented on this pull request.

A few more comments, but this is looking good.

> @@ -1225,17 +1249,15 @@ OnAckReceived(ack, pn_space):
   if (newly_acked_packets.empty()):
     return
 
-  // If the largest acknowledged is newly acked and
-  // at least one ack-eliciting was newly acked, update the RTT.
+  // Update the RTT if the largest acknowledged is newly acked
+  // and at least one ack-eliciting was newly acked.
+

```suggestion
```

> @@ -499,9 +499,12 @@ handshake, new data is requested from TLS after providing received data.
 ### Encryption Level Changes
 
 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.
+QUIC that reading or writing keys at that encryption level are available.  While
+generating these keys, an endpoint SHOULD buffer received packets marked as
+protected by the keys being generated, and process them once those keys become
+available.  If the keys are generated asynchronously, an endpoint MAY continue

I think we expect implementations to do this typically, unless there's a reason not to?

```suggestion
available.  If the keys are generated asynchronously, an endpoint SHOULD continue
```

> @@ -3685,14 +3691,18 @@ packet with the largest packet number is received and the time an acknowledgment
 is sent.  The endpoint encodes this acknowledgement delay in the ACK Delay field
 of an ACK frame; see {{frame-ack}}.  This allows the receiver of the ACK frame
 to adjust for any intentional delays, which is important for getting a better
-estimate of the path RTT when acknowledgments are delayed.  A packet might be
-held in the OS kernel or elsewhere on the host before being processed.  An
-endpoint MUST NOT include delays that it does not control when populating the
-ACK Delay field in an ACK frame.
-
-Since the acknowledgement delay is not used for Initial and Handshake
-packets, the ACK Delay field in acknowledgements for those packet types
-SHOULD be set to 0.
+estimate of the path RTT when acknowledgments are delayed.
+
+A packet might be held in the OS kernel or elsewhere on the host before being

I'd still like to strike the word 'intentionally' from above, since I don't think it's helpful.

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