General pacing considerations

[mwelzl]

We could have a list of pro's and con's of pacing (yes there are also con's).

[mwelzl]

Some pro's of pacing:

• less likely to provoke spontaneous loss from bursts
• less likely to cause sudden, ephemeral delay increase
• more likely to really saturate the available capacity, especially when queues are short

Some con's of pacing:

• more sustained delay growth
• slight (miniscule, perhaps negligible) delays due to delaying packets
• perhaps some more from this old well-known paper - but the last time I looked, the negative effects seemed to be tied to the combination of adding pacing and using an old TCP version. I don't remember if this is the case for all problems identified in this paper, though.

[mwelzl]

Just to report this here, in emails we agreed that yes, this should be a draft on pacing in general, and con's shouldn't be phrased as "con's" but rather "consequences" which aren't necessarily all bad.

[mwelzl]

So we don't forget, a to-do item: @wesley-eddy suggested to also discuss dynamics with AQM.

[mwelzl]

Probably, the need for fine-grain timers should also be a "general consideration" - this will explain the reader why implementations diverge (e.g., Linux limiting itself to 1ms granularity).

[mwelzl]

Generally, this issue is related to Issue #17.

From Eduard Vasilenko:

When I explained pacing’s importance, I stressed that the biggest problem is a bump of the high-speed path into the low-speed access (5G or WiFi). Something like: “Example: If a 15Mbps client is 20ms away. Then CUBIC on the server could burst up to 77kB (BDP) of data, it is a 5.9us burst on the 100GE link. That is an additional 20ms burst for the client’s shaper on BRAS or wireless AP that may be already loaded close to the maximum.”

IMHO: this fact is not stressed well enough in section 3. The story of how 5.9us becomes 20ms is very important story.