From eb72c66ba0089d0673a9fcc983c9ede3f0c65ad7 Mon Sep 17 00:00:00 2001 From: mirjak Date: Thu, 30 Nov 2023 17:05:58 +0100 Subject: [PATCH 1/2] ACK_FREQUENCY frame not this fixes #241 --- draft-ietf-quic-ack-frequency.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-ack-frequency.md b/draft-ietf-quic-ack-frequency.md index 8e48cf74..f8dab676 100644 --- a/draft-ietf-quic-ack-frequency.md +++ b/draft-ietf-quic-ack-frequency.md @@ -434,7 +434,7 @@ On sending an update to the peer's `max_ack_delay`, an endpoint can use this new value in later computations of its Probe Timeout (PTO) period; see {{Section 5.2.1 of QUIC-RECOVERY}}. -Until the packet carrying this frame is acknowledged, the endpoint MUST use the +Until the packet carrying the ACK_FREQUENCY frame is acknowledged, the endpoint MUST use the greater of the current `max_ack_delay` and the value that is in flight when computing the PTO period. Doing so avoids spurious PTOs that can be caused by an update that decreases the peer's `max_ack_delay`. From 4e5b466d586d9ff03542caef265da89071ffe543 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 10 Dec 2023 21:44:43 -0500 Subject: [PATCH 2/2] Reflow --- draft-ietf-quic-ack-frequency.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-ack-frequency.md b/draft-ietf-quic-ack-frequency.md index f8dab676..870085db 100644 --- a/draft-ietf-quic-ack-frequency.md +++ b/draft-ietf-quic-ack-frequency.md @@ -434,10 +434,10 @@ On sending an update to the peer's `max_ack_delay`, an endpoint can use this new value in later computations of its Probe Timeout (PTO) period; see {{Section 5.2.1 of QUIC-RECOVERY}}. -Until the packet carrying the ACK_FREQUENCY frame is acknowledged, the endpoint MUST use the -greater of the current `max_ack_delay` and the value that is in flight when -computing the PTO period. Doing so avoids spurious PTOs that can be caused by an -update that decreases the peer's `max_ack_delay`. +Until the packet carrying the ACK_FREQUENCY frame is acknowledged, the endpoint +MUST use the greater of the current `max_ack_delay` and the value that is in flight +when computing the PTO period. Doing so avoids spurious PTOs that can be caused by +an update that decreases the peer's `max_ack_delay`. While it is expected that endpoints will have only one ACK_FREQUENCY frame in flight at any given time, this extension does not prohibit having more than one