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

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.

I'm ok with either this or the other one.

> +exceed a small multiple, `pacing_gain`, of the congestion window. Larger
+bursts can reduce CPU utilization at the risk of increased retransmits rates.

This last sentence seems a little disconnected from the rest.  A small tweak might might help:

```suggestion
exceed a small multiple, `pacing_gain`, of the congestion window. Endpoints can
trade off sending packets in bursts, which might be done to reduce CPU
utilization, against even pacing, which has a lower risk of inducing packet
loss.
```

> +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.

There are two reasons.  As the window increases, the rate increases, so you only really need this gain to a) anticipate future increases and b) avoid having scheduling delays eat into your send rate.

The future increases thing is worth noting.  Pacing causes packets to be spaced out over time, and you won't be able to realize an increase in congestion window until an entire round trip has passed if pacing_gain is 1.  Whereas if pacing_gain is matched to the rate of increase in the window, you are already sending at the increased rate, so you never have to worry about the pacer being the cause of you not sending enough.

@janaiyengar argued that you don't need to worry about this effect.  I think that it's worth compensating for, at least partially.  With pacing, increases to the window will be continuous, or at least multiple times per round trip time, so the degree to which your pacer drags your send rate down is based on the rate of updates (i.e., ACKs) you get.

This is a stair-step function bounded by a straight line (well, a logarithm, but just change conceptually to a log vertical scale).  The steps happen as you get ACKs (or timer pops), so the amount you shade is bounded by how often the updates are.  You get closer to shading the area under the line if you update more often.  The realization here is that you can shade a similar area if you are willing to shade above the line :)  If you set pacing_gain == multiplicative increase, you are not keeping the steps below the diagonal, you are putting them on top by assuming that you will get an increase.  Choosing a value between 1 and m hedges a little.

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