What's in a name? AQM has been pretty thoroughly defined to equal
active queue *length* management and not packet scheduling.
Overloading "AQM" what cerowrt does is apt to cause even more
confusion in the field than it already does. We discussed using LBO as
a word but that appears hopelessly overloaded with leveraged buy out.
I go back to one I liked a while back:
Smart Queue Management. (SQM)
This got dissed on the aqm list too, but so far a viable alternative
TLA has not appeared. It's sufficiently different to hang a different
definition off of ("Smart queue management is an intelligent
combination of better packet scheduling (flow queuing) techniques
along with with active queue length management (aqm)")
On Thu, Dec 19, 2013 at 5:42 AM, Rich Brown <[email protected]> wrote:
> 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 <[email protected]> wrote:
>
>> Hi Rich,
>>
>>
>> On Dec 19, 2013, at 05:12 , Rich Brown <[email protected]> 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
>>
>
> _______________________________________________
> Cerowrt-devel mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
