[Cerowrt-devel] CeroWrt 3.10 AQM page

[Rich Brown <richb.hanover@gmail.com>]

Hi Sebastian and Fred,

[I’m changing the subject line of this thread…]

Great comments. I knew my glib assertions and fuzzy explanations would bring out cogent thoughts. I’ll give the rest of the list a chance to peruse the draft page and then work on it tonight. 

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310

Rich


On Dec 19, 2013, at 5:49 AM, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Rich,
> 
> 
> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover@gmail.com> wrote:
> 
>> Hi Sebastian,
>> 
>>>> Perhaps we could extend the Interface configuration page to add a “Link uses DSL/ADSL:” checkbox right below the Protocol dropdown. Default would be off, but when customers go to the GE00 interface to enter their PPPoE/PPPoATM/ISP credentials, they’d see this additional checkbox. Checking it would feed that info to the AQM tab. (And perhaps there could be a link there either to the AQM tab, or to the wiki for more information.)
>>> 
>>> 	I am happy to include a link to a wiki, but I guess we first need a wiki page :) 
>> 
>> Is this a challenge? Well, I accept! :-)
>> 
>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310 is a draft. I recycled the images from a previous message and wrote the least amount that I could that is likely to be true.
> 
> 	This is great, thanks a lot. I have made a few changes to the GUI yesterday, which hopefully improve the usability, so if the new GUI passes muster with the cerowrt crowd, the screenshots will need to change as you note on top.
> 
>> 
>> Please send me comments (or edit the page directly, if you have permissions.)
> 
> 	I do not have edit permissions, so I just comments here.
> 
> Basic settings:
> 	Why 85% as starting point? And can we give instructions how to measure "degradation in performance", so that non-technical users have a chance to actually optimize their own system?
> 
> Queueing Discipline:
> 	Maybe we can add a link to the mail list page (https://lists.bufferbloat.net/listinfo/cerowrt-devel)?
> 	Also can we note that it is recommended to turn ECN off for the egress, as we handle packets before the bottleneck and dropping packets actually allows us to send other more urgent packets , while on ingress it is recommended to turn ECN on, as the packets have cleared the bottleneck already, and hence dropping has no bandwidth advantage anymore. Both dropping and ECN should have the same effect on TCP adaptation to the path capacity.
> 
> Link Layer Adaptation:
> 	I think the first question is: Do I have an ATM carrier between your modem and your ISP's DSLAM? This typically is true for all ADSL variants.
> 	The second question is: Do I have overhead on the link outside of Ethernet framing? This typically is true for users of PPPoE and PPPoATM and even Bridging I think.
> 
> 	If the answer to any of these questions is yes, one needs to activate the link layer adaptations. 
> 	In case of pure overhead select ethernet, in case of ADSL select ATM.
> 	Fill in the per packet overhead in byte (see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/20100527024520/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html). If the overhead truly is zero and no ATM carrier is used, then select "none" for link layer adaptation. (I changed this page, so the tc_stab htb_private selection is under advanced options, and there is a selection of "none", "ethernet", and "none" in the first drop down box, "none" disables the link layer adaptation. Also the drop down box contains some information which selection is relevant for which cases).
> 
> What’s going on here? Why do I need this?:
> 	I think we should mention that only with the proper link layer selected and the overhead specified cerowrt is able to assess how large each packet is on the link to the ISP, and only then the shaping is deterministic. (For ATM users without the adaptations the shaper is stochastically too optimistic about the link capacity (which is too say the shaper is too optimistic about the effective packet sizes)).
> 
> Best Regards
> 	Sebastian
> 
> 
> 
>> Thanks.
>> 
>> Rich
>