[Cerowrt-devel] CeroWrt 3.10 AQM page

Thu Dec 19 10:27:39 EST 2013

On 19/12/13 15:07, Sebastian Moeller wrote:
> Hi All,
>
>
> On Dec 19, 2013, at 15:24 , Fred Stratton <fredstratton at ydl.net> wrote:
>
>> 2 comments:
>>
>> You talk about link speed. This has 2 meanings:
>>
>> the rate at which the link syncs;
>>
>> the download speed as measured by speedtest.net, or similar site. The text should be more specific.
> 	So what we need is the link speed (ideally already reduced by the link bandwidth dedicated to forward error correction, as that is not availably to us…)
> 	There is a large number of reasons why  speedtest.net might return variable speeds, but AQM should be tuned to the typical bottleneck link rate minus a few %. All links after the bottleneck (best case with cable already the first link is shared) are basically out of our control, assuming that the other links are at least as wide as the "home link". Think about it that way, all DSLAMs are oversubscribed, so will not guarantee full concurrent payed for bandwidth to all connected lines. If we shape to the reduced fraction we get under congestion conditions we always waste a lot of bandwidth.
> 	As I understood we can only hope to control our next link reasonably well, so we should only aim for that link. Congestion inside the ISPs network or say overloaded peering connections on the way to speediest.net are outside of the scope of what we can solve with AQM. <end of "rant">

I do not think the assertion that all DSLAMs are oversubscribed is 
correct. The point I was making was different to the one you are addressing.
>
>> The phrase 'contact your ISP' is in the text.  This should be removed.  Such contact is a traumatic exercise to which no users of ceroWRT should be subjected.
> 	I assume this is ISP contact is about the ADSL encapsulation; the alternatives are either trying to deduce this information from the del modems satays page (not all modems show this) from the ISPs website or by Googling, or empirically by measuring it. Calling the ISP should be the quickest…
The ISPs I use have contract support, which changes. They work according 
to a fault-finding script. Even if you are asking a question and do not 
have a fault, they go through the script. I have been through 3 levels 
of tech support, 'gurus', and ISP network support. None can answer 
simple questions.
Germany may be different, but I am paying circa 5 euros a month for 
unlimited internet access by ADSL2+.

I could use a boutique ISP, and get native ipv6 with a /48, and 
intelligent customer support. Downloads are limited to 40GiB per month 
for circa 50 euros.

So here, talking to customer support is not viable.
>
> Best Regards
> 	Sebastian
>
>>
>> On 19/12/13 13:42, Rich Brown 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 <moeller0 at gmx.de> wrote:
>>>
>>>> Hi Rich,
>>>>
>>>>
>>>> On Dec 19, 2013, at 05:12 , Rich Brown <richb.hanover at 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
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel