Re: [quicwg/base-drafts] A pacing algorithm (#3630)

[ianswett <[e-mail]>]

@ianswett commented on this pull request.

Some small suggestions, but this seems close.

> @@ -889,17 +889,36 @@ 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
+bytes exactly evenly over time. For a window-based congestion controller, such

```suggestion
packets exactly evenly over time. For a window-based congestion controller, such
```

Given overheads, spreading bytes evenly is impractical.

> +bytes 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 short-term variations in round-trip time or scheduler delays don't result

```suggestion
that variations in round-trip time don't result
```

I'd address the scheduler delay issue separately(also, 1.25x may not be enough to fix scheduler delay) and the variations in round trip time may not be short term(ie: a buffer draining).

> +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 short-term variations in round-trip time or scheduler delays don't result
+in under-utilization of the congestion window.

```suggestion
in under-utilization of the congestion window.  Values of 'N' larger than 1 result
in the sender being ack-clocked when the window is fully utilized and
acknowledgements arrive smoothly.
```

-- 
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/3630#pullrequestreview-413102330