From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 DEF1E21F1F0 for ; Fri, 20 Dec 2013 02:12:41 -0800 (PST) Received: from u-081-c022.eap.uni-tuebingen.de ([134.2.81.22]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MTSKd-1W2aTB3xu3-00SRgX for ; Fri, 20 Dec 2013 11:12:39 +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: <52B3106B.9010405@ydl.net> Date: Fri, 20 Dec 2013 11:12:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Fred Stratton X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:yvDZI4pYgGG6rWv2sOhLoUImYgY9pgu1qJEyIMR7KmMNBjfwtw3 y3zr+qKvKcVRGOAD0TA+mbGYpMHp6/TRgHpfrPGNcSvyM/3j2NNGFp0sdpOgda3ce2Cd9dK 9JMqcazU7jFidxsUWJNX92yMP4cy6oISyHodmU+fj4tdGu0KnPiB3J+4bHbKx2YDRAQUY6k jAohQnVTDSwwYxIQXBoxw== 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:12:42 -0000 Hi Fred, 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. = >=20 > 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). >>=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 > 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. best regards sebastian >>=20 >> Best Regards >> Sebastian >>=20 >>>=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