Re: [Cake] #17

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jonathan,


On Apr 14, 2015, at 12:13 , Jonathan Morton <chromatix99@gmail.com> wrote:

> 
>> On 13 Apr, 2015, at 17:45, Sebastian Moeller <moeller0@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”.

	Ah, good.

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

	This is going to be challenging to keep it simple, as we still need to think about what the kernel does on ethernet interfaces (it accounts for the ethernet header) so for PPPoE, LLC/SNAP, RFC-2684 you already need 3 flags plus a flag for ethernet header (which h the kernel does account for on ethernet devices but not on true ATM devices even if an ethernet header is used on the wire). Also most users do not really know or have a reliable way to figure out the encapsulation used (short of the slow empiric way I have been pushing for some time). But as long as there is a way to specify the overhead numerically, having a nicer symbolic way is not going to hurt.

> “vdsl” would be shorthand for “noatm overhead 16”,

	But, that is only true for my link including PPPoE and VLAN overhead, vdsl2 only drags in an additional 5 bytes:
VDSL (IEEE 802.3-2012 61.3 relevant for VDSL2): 2 Byte PPP + 6 Byte PPPoE + 4 Byte VLAN + 1 Byte Start of Frame (S), 1 Byte End of Frame (Ck), 2 Byte TC-CRC (PTM-FCS), = 16 Byte
	Also I am uncertain whether vdsl2 transmits the ethernet frame check sequence or not… (and unlike with the ATM carrier I have no idea how to measure the actual per packet overhead…)
In my case this really does not matter though, as the BRAS throttle accounts for 16 bytes (dual VLAN tags) so that is the value I need to shape for…



> and “raw” would allow reverting to an unadjusted configuration, ie. “noatm overhead 0”.

	I like raw as simple way to clear all the individual symbolic constants ;)

>  And it’s easy to retrospectively refine the behaviour of those keywords, because they’re in userspace.

	Is it simlper to get a patch into iproute2 than the kernel? and are the iproute2 maintainers open to redefinition of symbolic values?

Best Regards
	Sebastian

> 
> - Jonathan Morton
>