Re: [Cake] cake/tc - removal of atm/ptm/ethernet specific overhead keywords

[moeller0 <moeller0@gmx.de>]

Hi Jonathan,

> On Jun 2, 2016, at 16:22 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 2 Jun, 2016, at 12:37, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>> 
>> I'd be sort of interested to know if anyone is actually using those keywords: ipoa-vcmux, ipoa-llcsnap, bridged-vcmux, bridged-llcsnap, ppoa-vcmux, pppoa-llc, pppoe-vcmux, pppoe-llcsnap, pppoe-ptm, bridged-ptm, via-ethernet, ether-phy, ether-all, ether-fcs, ether-vlan.
>> 
>> How many actually knew they even existed?
> 
> Since they are poorly documented, probably not many.  But I’d rather improve the documentation than delete them.

My take is that if you write a comprehensive description of per packet overhead that remains readable and interesting you would do a great thing, But it would be too much for just being a section in the cake man page. 

> 
> In principle, the existence and naming of these keywords is a potential clue to the uninitiated user of the overhead feature’s purpose.  

	In practice actual overheads are a) more complex than the keywords implied and b) less invariant as one would hope (in that ISPs change their composition without noticing their users).

> The concept of protocol overhead affecting shader function is not an obvious one outside of networking specialists; making users look up a number in a cryptic table will simply result in nobody doing it at all.

	Making people pick potentially wrong values from a set of (under-documented) keywords will have similar results.

> 
> Having shortcut keywords for this purpose in tc also helps to avoid the trap of other UI layers doing their own (incomplete or inaccurate) research on the correct compensation to apply.  

	Yeah, but this only is an improvement if the keywords are complete and accurate, the last batch was not…

> Currently LuCI is extremely clumsy at handling SQM configuration, and the general quality of vendor firmware doesn’t give me confidence.

	Thanks for the kind words ;).

> 
> I’ve just pushed an update which makes all the keywords incremental, rather than some of them being absolute.  Existing correct examples of how to use these keywords remain correct.
"
	This still does not fix the fact that it is quite unclear what exactly “pppoe-llcsnap" should expand to, and whether “pppoe-llcsnap vlan vlan” really is that much user friendlier than “overhead NN”.

> 
> It would be nice if LuCI could infer information about the likely overheads from the rest of the configuration, and apply (or suggest & default) the correct keywords in sqm-scripts.  That would make the feature much more widely used.

	Yes, if reality was less complex life would be easier, I agree. In reality ISPs are beginning to implement their own policers/shapers at the BRAS/BNG level making the whole thing even more difficult, as at that level the shapers sits on top of ethernet with an unknown per-packet overhead that is difficult to measure remotely…

Best Regards
	Sebastian

> 
> - Jonathan Morton
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake