[Cerowrt-devel] CeroWrt 3.10 AQM page

Sebastian Moeller moeller0 at gmx.de
Fri Dec 20 05:45:51 EST 2013 

Hi Fred,


On Dec 20, 2013, at 11:33 , Fred Stratton <fredstratton at imap.cc> wrote:

> 
> On 20/12/13 10:12, Sebastian Moeller wrote:
>> Hi Fred,
>> 
>> 
>> On Dec 19, 2013, at 16:27 , Fred Stratton <fredstratton at ydl.net> wrote:
>> 
>>> 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.
>> 	I would love to hear from people deeper in the know, but as far as I know, the old telephone system was oversubscribed (the central office had less total line equivalents uplink, than subscriber lines connected). I am pretty sure that in Germany DSLAM are always having more total bandwidth on the user side than o the internet side; I do not want to claim that this typically leads to noticeable congestion, as let's face it, most users have very lean bandwidth usage...
>> 
>>> The point I was making was different to the one you are addressing.
>> 	I thought your point was that iy is not clear which speed to measure; my core point is that it is the speed of the link to the ISP (the DDSLAM not necessarily the BRAS).
> The end user cannot assess the speed pf the link you mention.

Well typically this, what I call link speed is reported either on the invoice/contract or somewhere on the modems status page.

> There is also not necessarily one link only between the telephone exchange equipment and the ISP.

	As far as I understand the situation the only relevant link for AQM is the slowest dedicated link between us and the backbone. On a DSL line that typically is the copper pair between the DSLAM and the "socket" at the users home. The lines after that are typically shared (and hence larger than thus users dedicated payed-for access rates).  For the shared components of the path we have to hope that the ISP manages these well.

> 
> Here, BT, the Deutsche Telekom equivalent, does not have a monopoly. It has 37 per cent of the retail market. Its wholesale arm, OpenReach, operates the infrastructure independently. ISPs only use part of this infrastructure.
> 
> TalkTalk use BT phone lines from here to the exchange 1.4km away. The DSLAM is TalkTalk equipment. The backhaul - fibre along the West Coast Main Line- is owned by TalkTalk.
> 
> Sky use BT phone lines from here to the exchange 1.4km away. The DSLAM is Skyg equipment.The backhaul is owned by BT/OpenReach.
> 
> I am talking about the maximum sync rate for the line versus the actual achieved rate, which varies more. Bith are available to the end user. Both can be used for calculation.

	Ah, we need the actual current sync rate (not the line capacity). The point is we need to know how fast can we actually push bits over to the DSLAM. This is the speed we need to stay below to avoid filling the ample buffers in the DSL modem on the uplink, and to avoid filling the DSLM's buffer on the downlink. I know that earless rate adaptation SRA will make this somewhat more difficult, it is rarely used.
	Heck what we need is a standardized way for routers to acquire the current up and download speeds from dsl/cable-modems...


>> 
>>>>> 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+.
>> 	This price sounds great (is that all or do you have to pay for a mandatory phone line as well). The situation in Germany is not much better.
> 
> The phone line, excluding cash discount, costs about 12 euros per month extra.

	Still a great price.

best
	sebastian

>> 
>>> 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.
>> 	Then the non technical user pretty much is out of luck in getting this information. In that case we might think about defaulting overhead to 40 (the 44 maximum should be really really rare) so that almost all users should be okay… So we are back at needing a reliable robust automatic link layer detection….
>> 
>> best regards
>> 	sebastian
>> 
>> 
>> 
>>>> 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
>

More information about the Cerowrt-devel mailing list