From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CA26A21F1FC for ; Fri, 20 Dec 2013 02:45:54 -0800 (PST) Received: from u-081-c022.eap.uni-tuebingen.de ([134.2.81.22]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MWT8s-1W1BVV45dK-00Xb11 for ; Fri, 20 Dec 2013 11:45:52 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: <52B41CF4.1090604@imap.cc> Date: Fri, 20 Dec 2013 11:45:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47567C2C-BD19-4055-8ED0-53D24C80C5B3@gmx.de> References: <34E77F64-739C-49E4-B8A4-6ABBEAE4174B@gmail.com> <8DB84101-C942-49C4-99F0-6C9319961297@gmail.com> <22176178-A50F-48F2-A3A1-D3853764AD0E@gmail.com> <0E267F91-3CC8-48F4-92C0-AD8BACA98FCC@gmail.com> <1FA2FD44-D715-4B50-BB5A-BAF61070970B@gmx.de> <31B5B61B-4E58-4C5E-8F33-710CCE0918F4@gmail.com> <52B30194.10600@ydl.net> <7C502EB9-697E-4466-9669-2D61AFAA7382@gmx.de> <52B3106B.9010405@ydl.net> <52B41CF4.1090604@imap.cc> To: Fred Stratton X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:OzLL8ePbhllE50iXNMDgWdmNKsRR38GwII+yfxNjur/Jx+ShhGm y00qClkK0UZjdFWZDz2/sbhIVEHX6TyqfZe11lHaDE66UBX3wmdB7HUr7v1Tymp2UdyL9CS XyJDluh1cjuAWpU+8fbLbE5hjiNuil8HTE5GixNxeGPMCiaGgUXJbX8LXqCEN6VcAFaT+XM IH9MVhdv3b45fU17d8/2w== Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] CeroWrt 3.10 AQM page X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 10:45:55 -0000 Hi Fred, On Dec 20, 2013, at 11:33 , Fred Stratton wrote: >=20 > On 20/12/13 10:12, Sebastian Moeller wrote: >> Hi Fred, >>=20 >>=20 >> On Dec 19, 2013, at 16:27 , Fred Stratton = wrote: >>=20 >>> On 19/12/13 15:07, Sebastian Moeller wrote: >>>> Hi All, >>>>=20 >>>>=20 >>>> On Dec 19, 2013, at 15:24 , Fred Stratton = wrote: >>>>=20 >>>>> 2 comments: >>>>>=20 >>>>> You talk about link speed. This has 2 meanings: >>>>>=20 >>>>> the rate at which the link syncs; >>>>>=20 >>>>> 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=85) >>>> 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. = >>> 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... >>=20 >>> 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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... >>=20 >>>>> 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=85 >>> 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. >=20 > The phone line, excluding cash discount, costs about 12 euros per = month extra. Still a great price. best sebastian >>=20 >>> 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. >>>=20 >>> 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=85 So we are back at needing a reliable = robust automatic link layer detection=85. >>=20 >> best regards >> sebastian >>=20 >>=20 >>=20 >>>> Best Regards >>>> Sebastian >>>>=20 >>>>> On 19/12/13 13:42, Rich Brown wrote: >>>>>> Hi Sebastian and Fred, >>>>>>=20 >>>>>> [I=92m changing the subject line of this thread=85] >>>>>>=20 >>>>>> Great comments. I knew my glib assertions and fuzzy explanations = would bring out cogent thoughts. I=92ll give the rest of the list a = chance to peruse the draft page and then work on it tonight. >>>>>>=20 >>>>>> = http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWr= t_310 >>>>>>=20 >>>>>> Rich >>>>>>=20 >>>>>>=20 >>>>>> On Dec 19, 2013, at 5:49 AM, Sebastian Moeller = wrote: >>>>>>=20 >>>>>>> Hi Rich, >>>>>>>=20 >>>>>>>=20 >>>>>>> On Dec 19, 2013, at 05:12 , Rich Brown = wrote: >>>>>>>=20 >>>>>>>> Hi Sebastian, >>>>>>>>=20 >>>>>>>>>> Perhaps we could extend the Interface configuration page to = add a =93Link uses DSL/ADSL:=94 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=92d 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! :-) >>>>>>>>=20 >>>>>>>> = http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWr= t_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. >>>>>>>=20 >>>>>>>> Please send me comments (or edit the page directly, if you have = permissions.) >>>>>>> I do not have edit permissions, so I just comments here. >>>>>>>=20 >>>>>>> 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? >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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). >>>>>>>=20 >>>>>>> What=92s 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)). >>>>>>>=20 >>>>>>> Best Regards >>>>>>> Sebastian >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Thanks. >>>>>>>>=20 >>>>>>>> Rich >>>>>> _______________________________________________ >>>>>> Cerowrt-devel mailing list >>>>>> Cerowrt-devel@lists.bufferbloat.net >>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>> _______________________________________________ >>>>> Cerowrt-devel mailing list >>>>> Cerowrt-devel@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20