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

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.



> @@ -897,9 +897,33 @@ congestion window, which is recommended to be the minimum of
 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, as long as the rate of bytes

I think this is all too much prescription. I suggest you move this up above the previous paragraph, and lead into the burst paragraphs like so: 

"Endpoints can implement pacing as they choose. A perfectly paced sender spreads 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. More precisely, `pacing rate = N * congestion_window / smoothed_rtt`, where using a small N (for example, 1.25) protects the sender from short-term variations in round-trip time or from scheduler delays.

Further 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 ..."

-- 
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-411429547