Re: [Cake] cake shaper vs leaky bucket algorithm

[Greg White <g.white@CableLabs.com>]

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@gmail.com> wrote:

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