[Cake] #17

[Jonathan Morton]

> On 13 Apr, 2015, at 17:45, Sebastian Moeller <moeller0 at gmx.de> wrote:
> 
>> 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.  
> 
> I fully endorse this, actually this “overhead” parameter should work independent of the “atm” flag (on my VDSL link I have 16 bytes overhead that needs accounting on top of the ethernet header). For non-atm carriers getting the per-packet overhead wrong is not as terrible, but it will make the shaper suck with small packets…

Well yes, that’s what I meant by “orthogonal”.

>> 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.
> 
> 	Have a look at http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ and http://www.faqs.org/rfcs/rfc2684.html (neither of which deals with potential VLAN tags between BRAS and Modem, that are “invisible” to packet captures as they never reach the endusers network, but still cost bottleneck bandwidth); the whole encapsulation issue is a mess that will most likely not lend it self to a small enumeration of encapsulations

What I propose is that I add a numeric overhead parameter to cake’s configuration API, and then in iproute2 I can provide keywords as a more user-friendly way of specifying the common cases, as well as offering direct access to the numeric.  So specifying “pppoa vcmux” would be shorthand for “atm overhead 10”, “vdsl” would be shorthand for “noatm overhead 16”, and “raw” would allow reverting to an unadjusted configuration, ie. “noatm overhead 0".  And it’s easy to retrospectively refine the behaviour of those keywords, because they’re in userspace.

 - Jonathan Morton