Re: [quicwg/base-drafts] Another pacing algorithm (#3655)

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.

This is again too prescriptive to me. I've made a big suggestion to #3630 instead.

> +A `pacing_gain` multiplier greater than 1 allows senders to increase the rate
+of sending. The value of `pacing_gain` might be larger in slow start than
+congestion avoidance to ensure the sender is able to double its congestion
+window every round trip.

To clarify what I said: pacing rate is cwnd/rtt (approximately, for window-based senders). In this world, on each ack, the cwnd increases, and your pacing rate therefore increases. At the end of the first RTT in slow start, your window is 2x the IW, and your pacing rate is 2 x IW / rtt. That is as it should be. Now, to compensate for border conditions, it's a good idea to use a multiplier, and that does not need to be any more than a small delta (say 1.25), and it doesn't need to be higher for slow start.

At any rate, this is way more than you need to be saying in this definition.

> +Timers are not ideal, so intervals will need to be adjusted to ensure the
+average pacing rate is maintained.  Not doing so will result in a decrease
+in average sending rate when timers consistently fire late.

I think what you want to say is that timers usually run with some granularity. I _think_ what you're trying to say is that timers might fire late and that future computations will need to account for that. 

-- 
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/3655#pullrequestreview-411420877