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

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.



> @@ -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.

Does this belong in the transport draft too?  And maybe we can include Handshake packets by conditioning this: "acknowledge all ack-eliciting Initial and Handshake packets immediately after processing them"

> +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}}).

With the above change I suggest, you can move this out and talk about acknowledgment within 0 (Initial/Handshake) or max_ack_delay (0-RTT/1-RTT) of processing the packet.  That leaves this paragraph as just "an endpoint might have to delay processing until it has keys".

> -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
+keys for Handshake, 0-RTT, or 1-RTT packets when they are received. It might
+therefore buffer them and acknowledge them when the requisite keys become
+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}}).
+
+Since the peer might report large acknowledgement delays during the handshake,

```suggestion
As the peer might report large acknowledgement delays during the handshake,
```

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