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

[moeller0 <moeller0@gmx.de>]

Dear Jonathan,


> On Jun 2, 2016, at 19:40 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 2 Jun, 2016, at 18:42, moeller0 <moeller0@gmx.de> wrote:
>> 
>> I stopped believing this is “simple” a long time ago; I also failed to come up with a method to measure the actual overhead on VDSL links…
> 
> If it’s impossible to measure, then by definition it doesn’t have a significant performance impact,

	That is unfortunately not really true… it really is just that, hard to measure. And that might be more a statement about my methodological/creative gaps than anything else.

> and thus it doesn’t matter if it is sloppily estimated.  In that context an overestimate of overhead is safe.

	Safe, only if over-estimated; I would prefer if the user would specify the bandwidth “sacrifice” once when he sets the shapers brutto rate ;)

> 
> This is really a user-interface problem.  I think it would be very helpful for LuCI to get a basic, easy “conservative overhead compensation” button that simply turns on the “conservative” keyword for both ingress and egress.  That’s the bare minimum.

	That will, as currently implemented, drag in the ATM 48/53 cell compensation for all users, eating roughly 9% bandwidth, not sure we would do our users a favor with such a default policy. 


> 
> We can discuss details of improving granularity of that setting at greater leisure, preferably in the context of a proper redesign of the SQN configuration.
> 
> And let’s be absolutely clear: I will NOT drop the shortcut keywords from tc.

	So far I have tried to raise a number of in-detail issues (in other mails and postings) that seem to indicate that our assumptions about per-packet-overheads are not as robust and complete as they should be if we want to use them to justify changing the defaults.
	So, if you do not want to drop the keywords then please make sure they are well-documented and consistent. Currently it is not self-evident which numerical overhead corresponds to which keyword and that mapping should be crystal clear. And I would like to add that “conservative”-keyword needs special care in documentation as it is the only keyword that compounds per-packet-overhead and specific framing (ATM in this case, we simply ignore PTM’s 64/65 encoding (and rightly so)), this should be obvious from the documentation (man page and the output of “tc qdisc add cake help”) and in my opinion the keyword itself. I would propose as first half-measure “conservative_adsl” or “conservative_atm” to signify the compound nature.
	

Best Regards
 	Sebastian

> 
> - Jonathan Morton
>