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

[Marten Seemann <[e-mail]>]

@marten-seemann approved this pull request.



> @@ -3688,11 +3694,13 @@ 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.
+ACK Delay field in an ACK frame, but endpoints SHOULD include buffering delays
+caused by unavailability of decryption keys.

Do we need to explain why this is a SHOULD? We could say that if a packet containing CRYPTO data from the previous PN was lost, the buffering delay will be > 1 RTT. That should be a very good motivation to follow this SHOULD.

> -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}}.
+
+As the peer might report acknowledgement delays that are larger than the peer's
+max_ack_delay during the handshake (Section 13.2.1 of {{QUIC-TRANSPORT}}), the
+endpoint SHOULD ignore max_ack_delay until the handshake is confirmed (Section
+4.1.2 of {{QUIC-TLS}}). Since these large acknowledgement delays, when they
+occur, are likely to be non-repeating and limited to the handshake, the endpoint
+can use them without limiting them to the max_ack_delay and avoid unnecessarily
+inflating the smoothed_rtt estimate.

It's not only smoothed_rtt, but also rttvar.
```suggestion
inflating the RTT estimate.
```

> +field of the ACK frame as described in Section 19.3 of {{QUIC-TRANSPORT}}.
+
+As the peer might report acknowledgement delays that are larger than the peer's
+max_ack_delay during the handshake (Section 13.2.1 of {{QUIC-TRANSPORT}}), the
+endpoint SHOULD ignore max_ack_delay until the handshake is confirmed (Section
+4.1.2 of {{QUIC-TLS}}). Since these large acknowledgement delays, when they
+occur, are likely to be non-repeating and limited to the handshake, the endpoint
+can use them 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
+peer that are greater than the peer's max_ack_delay are attributed to
+unintentional but potentially repeating delays, such as scheduler latency at the
+peer or loss of previous acknowledgements. Therefore, these extra delays are
+considered effectively part of path delay and incorporated into the smoothed_rtt
+estimate.

Not sure where to put this, but do we need to recommend something along these lines:
If you set an ack timer for `x ms`, you should advertise a max_ack_delay for `x ms + timer_granularity` in your transport parameters?

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