Re: [Cake] #17

[Jonathan Morton <chromatix99@gmail.com>]

> On 13 Apr, 2015, at 03:23, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> Ignore my gibberish below, that is almost all required: ceil(len+additional_per_packet_overhead/48)*53 seems the winner ;) Effectively this is what stab should offer, but its implementation with a table has issues if packets are larger than the table estimated…

The other problem with stab is that the configuration is awfully verbose - pretty much what I was trying to avoid with cake.  I’ll admit that a table lookup can be faster than a calculation (under favourable circumstances), but exposing those sorts of implementation details to userspace is just going to give people headaches while they try to figure out what to put and why.

That’s a recipe for people (and, more seriously, CPE vendors) getting it wrong.

So cake just has that simple “atm” flag, which adds roughly the right amount of overhead for cell-framing already.  Any optimisations to that calculation (which are certainly possible) are an internal matter and not for public consumption.

It could be refined by adding an additional, orthogonal setting for non-cell framing overhead, which would be added before the cell-framing calculation; this would allow adding the 8 bytes of PPPoE framing and/or the 2 bytes of Ethernet VLAN tag, for people who want to get it exactly right.  Whether these are simple, self-descriptive flags which can be combined for the desired effect, or a numeric parameter which must be set up, is open for discussion.

All of this will help with setting cake’s shaper closer to, and eventually perhaps *at* the physical link rate.  The relative lack of bursting from cake’s shaper already allows some of that, since it’s no longer necessary to allow the initial burst from the token bucket to drain from the dumb FIFO downstream.

 - Jonathan Morton