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

[ianswett <[e-mail]>]

@ianswett commented on this pull request.

Thanks for adding more to the PR, some initial comments.

> @@ -338,27 +338,41 @@ 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 ApplicationData 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 Ack 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.
+
+When 0-RTT or 1-RTT ack-eliciting packets are received, a peer does not delay
+acknowledging them any longer than the period it advertised in the max_ack_delay
+transport parameter; see Section 18.2 of {{QUIC-TRANSPORT}}.
+
+However, an endpoint SHOULD use ignore max_ack_delay until the handshake is

```suggestion
However, an endpoint SHOULD ignore max_ack_delay until the handshake is
```

> -part of path delay and incorporated into the smoothed_rtt estimate.
+
+When 0-RTT or 1-RTT ack-eliciting packets are received, a peer does not delay
+acknowledging them any longer than the period it advertised in the max_ack_delay
+transport parameter; see Section 18.2 of {{QUIC-TRANSPORT}}.
+
+However, an endpoint SHOULD use ignore max_ack_delay until the handshake is
+confirmed (Section 4.1.2 of {{QUIC-TLS}}). Prior to handshake confirmation, the
+peer's reported acknowledgement delays might exceed the peer's max_ack_delay
+because it might buffer undecryptable packets and acknowledge them when the
+requisite keys become available to it. Since these delays, when they occur, are
+measurable and limited to the handshake, the endpoint can use the delays without
+limiting them to the max_ack_delay and avoid unnecessarily inflating the
+smoothed_rtt estimate.
+
+After the handshake is confirmed, any acknowledgement delays reported by the

Handshake confirmed only works for 1-RTT packets.  But Handshake packets suffer from the same problem as 1-RTT packets.

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