From 9ed9536d298e87d76293802588a1f01d533c3c6f Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 3 Aug 2020 11:34:24 -0400 Subject: [PATCH] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index e59b06d2a5..a01806e91a 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -348,11 +348,11 @@ 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. -The first ACK frame in the Handshake and ApplicationData packet number spaces can -be greatly delayed due to a lack of decryption keys at the time they're received. -For these two ACK frames, the max_ack_delay MAY be ignored if the sender chooses. -Note that if there are no prior RTT samples, ignoring max_ack_delay has no -impact. +The first ACK frame in the Handshake and ApplicationData packet number spaces +can be greatly delayed due to a lack of decryption keys at the time they're +received. For these two ACK frames, the max_ack_delay MAY be ignored if the +sender chooses. If the delayed ACK frame is the first RTT sample, ignoring +max_ack_delay has no impact. When adjusting an RTT sample using peer-reported acknowledgement delays, an endpoint: