Merge pull request #3630 from quicwg/pacing-dfn

A pacing algorithm

draft-ietf-quic-recovery.md

@@ -893,17 +893,39 @@ Timely delivery of ACK frames is important for efficient loss recovery. Packets
 containing only ACK frames SHOULD therefore not be paced, to avoid delaying
 their delivery to the peer.
 
-Sending multiple packets into the network without any delay between them
-creates a packet burst that might cause short-term congestion and losses.
-Implementations MUST either use pacing or limit such bursts to the initial
-congestion window, which is recommended to be the minimum of
-`10 * max_datagram_size` and `max(2 * max_datagram_size, 14720))`, where
-max_datagram_size is the current maximum size of a datagram for the connection,
-not including UDP or IP overhead.
-
-As an example of a well-known and publicly available implementation of a flow
-pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
-in Linux (3.11 onwards).
+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:
+
+~~~
+rate = N * congestion_window / smoothed_rtt
+~~~
+
+Or, expressed as an inter-packet interval:
+
+~~~
+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
+that variations in round-trip time don't result in under-utilization of the
+congestion window.  Values of 'N' larger than 1 ultimately result in sending
+packets as acknowledgments are received rather than when timers fire, provided
+the congestion window is fully utilized and acknowledgments arrive at regular
+intervals.
+
+Practical considerations, such as packetization, scheduling delays, and
+computational efficiency, can cause a sender to deviate from this rate over time
+periods that are much shorter than a round-trip time.  Sending multiple packets
+into the network without any delay between them creates a packet burst that
+might cause short-term congestion and losses.  Implementations MUST either use
+pacing or limit such bursts to the initial congestion window; see
+{{initial-cwnd}}.
+
+One possible implementation strategy for pacing uses a leaky bucket algorithm,
+where the capacity of the "bucket" is limited to the maximum burst size and the
+rate the "bucket" fills is determined by the above function.
 
 ## Under-utilizing the Congestion Window