[Cake] cake shaper vs leaky bucket algorithm
g.white at CableLabs.com
Wed Nov 18 12:41:15 EST 2015
agreed. (and I hope you understand I was speaking of the black-box
behavior rather than describing an implementation of it, your
implementation approach is clearly the appropriate one)
On 11/18/15, 10:30 AM, "Jonathan Morton" <chromatix99 at gmail.com> wrote:
>> On 18 Nov, 2015, at 19:12, Greg White <g.white at 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
> - Jonathan Morton
More information about the Cake