Re: [Cake] cake shaper vs leaky bucket algorithm

[Jonathan Morton <chromatix99@gmail.com>]

> On 18 Nov, 2015, at 19:12, Greg White <g.white@CableLabs.com> wrote:
> 
> 2) you delay small packets to avoid the 1 MTU "burstiness" that the traditional algorithm would create.
> 
> Change 2 might be more debatable, since it adds latency where (it could be argued) it isn't needed.  The argument might be: if it is acceptable (and it has to be) for the shaper to put an MTU worth of consecutive bytes on the wire, does it matter whether those bytes are one large packet or several small ones?

When a large packet is committed for transmission, the latency it causes (due to serialisation) is unavoidable.

When a series of small packets are available, the situation is more complex.  Committing them all at once is certainly not a win; they must still incur serialisation delay.

Conversely, committing them at the properly scheduled times allows flow-isolation to work better (especially in the not-uncommon case where new packets arrive for another flow while the original series is still being dealt with), and also ensures that the correct sequence of sojourn times is visible to the AQM layer.

But Cake’s shaper doesn’t treat sub-MTU packets specially in any case; in fact, it is unaware of the MTU, and is entirely capable of handling multi-MTU-sized aggregates.  It waits until the next transmission is scheduled, transmits the next available packet, then advances the pointer by the wire-time occupied by that packet.

So treating packets of different sizes differently, as you describe, would actually complicate the algorithm as well as worsening its system-level performance.

 - Jonathan Morton