From d73bdac4c59a00397606e0672644d20960ae3b2b Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 11 Jan 2021 19:47:35 -0800 Subject: [PATCH] Fix units for pacing and a couple of related nits --- draft-ietf-quic-recovery.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 0e771fcdd0..2673fe3be5 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -1087,16 +1087,17 @@ their delivery to the peer. Endpoints can implement pacing as they choose. A perfectly paced sender spreads packets exactly evenly over time. For a window-based congestion controller, such as the one in this document, that rate can be computed by averaging the -congestion window over the round-trip time. Expressed as a rate in bytes: +congestion window over the round-trip time. Expressed as a rate in units of +bytes per time, where congestion_window is in bytes: ~~~ rate = N * congestion_window / smoothed_rtt ~~~ -Or, expressed as an inter-packet interval: +Or, expressed as an inter-packet interval in units of time: ~~~ -interval = smoothed_rtt * packet_size / congestion_window / N +interval = ( smoothed_rtt * packet_size / congestion_window ) / N ~~~ Using a value for `N` that is small, but at least 1 (for example, 1.25) ensures @@ -1687,7 +1688,7 @@ bytes_in_flight: congestion feedback. congestion_window: -: Maximum number of bytes-in-flight that may be sent. +: Maximum number of bytes allowed to be in flight. congestion_recovery_start_time: : The time when QUIC first detects congestion due to loss or ECN, causing