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

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.



> @@ -1232,10 +1255,7 @@ OnAckReceived(ack, pn_space):
       IncludesAckEliciting(newly_acked_packets)):
     latest_rtt =
       now() - newly_acked_packets.largest().time_sent
-    ack_delay = 0
-    if (pn_space == ApplicationData):
-      ack_delay = ack.ack_delay
-    UpdateRtt(ack_delay)
+    UpdateRtt(ack.ack_delay)

Done.

> @@ -337,29 +337,47 @@ samples, and rttvar is the variation in the RTT samples, estimated using a
 mean variation.
 
 The calculation of smoothed_rtt uses path latency after adjusting RTT samples
-for acknowledgement delays. These delays are computed using the ACK Delay field
-of the ACK frame as described in Section 19.3 of {{QUIC-TRANSPORT}}. For packets
-sent in the Application Data packet number space, a peer limits any delay in
-sending an acknowledgement for an ack-eliciting packet to no greater than the
-value it advertised in the max_ack_delay transport parameter. Consequently, when
-a peer reports an acknowledgment delay that is greater than its max_ack_delay,
-the delay is attributed to reasons out of the peer's control, such as scheduler
-latency at the peer or loss of previous ACK frames.  Any delays beyond the
-peer's max_ack_delay are therefore considered effectively part of path delay and
-incorporated into the smoothed_rtt estimate.
+for acknowledgement delays. These delays are computed using the ACK Delay
+field of the ACK frame as described in Section 19.3 of {{QUIC-TRANSPORT}}.
+
+A peer MUST immediately acknowledge all ack-eliciting Initial packets.

The text in the transport draft is weak. I'm moving this there and making it stronger.

> +available. When this is not the case, the peer MUST immediately acknowledge all
+ack-eliciting Handshake packets, and MUST NOT delay acknowledgement of
+ack-eliciting 0-RTT, or 1-RTT packets for any longer than the period that it
+advertised in the max_ack_delay transport parameter (Section 18.2 of
+{{QUIC-TRANSPORT}}).

I've restructured the text a bit differently, see what you think.

> -for acknowledgement delays. These delays are computed using the ACK Delay field
-of the ACK frame as described in Section 19.3 of {{QUIC-TRANSPORT}}. For packets
-sent in the Application Data packet number space, a peer limits any delay in
-sending an acknowledgement for an ack-eliciting packet to no greater than the
-value it advertised in the max_ack_delay transport parameter. Consequently, when
-a peer reports an acknowledgment delay that is greater than its max_ack_delay,
-the delay is attributed to reasons out of the peer's control, such as scheduler
-latency at the peer or loss of previous ACK frames.  Any delays beyond the
-peer's max_ack_delay are therefore considered effectively part of path delay and
-incorporated into the smoothed_rtt estimate.
+for acknowledgement delays. These delays are computed using the ACK Delay
+field of the ACK frame as described in Section 19.3 of {{QUIC-TRANSPORT}}.
+
+A peer MUST immediately acknowledge all ack-eliciting Initial packets.
+
+Prior to handshake confirmation, a peer might not have the packet protection

We use the term "packet protection keys" for both encryption and decryption keys, but I've made the "decrypting" more explicit now.

-- 
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#discussion_r466018540