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

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.



>  
-- MUST use the lesser of the value reported in ACK Delay field of the ACK frame
-  and the peer's max_ack_delay transport parameter.
+- MAY ignore the peer's max_ack_delay until the handshake is confirmed,

MAY is in recognition of the fact that an attacker can already tilt the calculation for RTT using Initial ACK, so we allow people to ignore that information, but we don't need to recommend it.

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

Good catch.

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

Sounds reasonable.

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