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