From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 9718621F13F for ; Wed, 18 Dec 2013 01:17:02 -0800 (PST) Received: from u-081-c054.eap.uni-tuebingen.de ([134.2.81.54]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M9s8K-1VmZPu3cRU-00B1bH for ; Wed, 18 Dec 2013 10:16:58 +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: <22176178-A50F-48F2-A3A1-D3853764AD0E@gmail.com> Date: Wed, 18 Dec 2013 10:16:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <458CF588-9E8B-4C59-ABD3-D573C1FB1436@gmx.de> References: <34E77F64-739C-49E4-B8A4-6ABBEAE4174B@gmail.com> <8DB84101-C942-49C4-99F0-6C9319961297@gmail.com> <22176178-A50F-48F2-A3A1-D3853764AD0E@gmail.com> To: Rich Brown X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:Qoc4bkk5nvsiFduIAAPHx4Jlq5q2iM0hQEeYh19TL3p8OeylitK ZsaGFBU3nrU8GNCQp4ytXK36wDHb/lnN8yfizZigAbKDt1Vy7EV4cUmvShoDZNQ0LX7+3jn TzBgcTk8++aeZN9S+eryKTushEeQin0AVev6+pgwnkvTu1Z+GV604VZWB1zyBgVA0uk+5mO oTELfZd8o30NumPFEvW4g== Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released 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: Wed, 18 Dec 2013 09:17:03 -0000 Hi Rich, On Dec 18, 2013, at 04:06 , Rich Brown wrote: > Hi Sebastian, >=20 >>> And while trying to make an intelligent guess, I wonder how to map = none/tc_stab into DSL and/or ATM; if adsl is the same as DSL; >>=20 >> No ADLS is one out of a family of xDSLs (digital subscriber = lines). As far as I know SDSL does not use ATM, VDSL1 might use ATM and = all ADSL variants use ATM. >>=20 >>> and where ethernet fits into the scheme of things. >>=20 >> Ethernet is also a link layer, one that does typically not show = quantization as ATM does, selecting the ethernet link layer allows to = still specify an overhead, and that is somewhat useful for VDSL (since = VDSL often still uses PPPoE). >=20 > ... and ... >=20 >>> - (I believe) Only two =93protocols=94 (above) require =93link layer = adaptation": PPPoE (DSL/ADSL) and PPPoATM (PPP over ATM). All the others = seem to be some variation on Ethernet. (Please correct me if I=92m = wrong.)=20 >>=20 >> Well for PPPoATM I agree, but PPPoE is also used with VDSL which = uses PTM in stead of ATM and has no quantization issues, but still = profits from setting the overhead correctly so needs the link layer = adaptation as well. Now, as far as I know PPPoATM is quite rare so I = have no idea of how to deal with the common case automagically. >=20 > So basically, if I understand what you=92re saying, it=92s a big mess. = :-) At least as far as I understand it; there might be simple and = elegant solution to this, I just do not see it... >=20 > Even though my desires conflict, I still hold out for the two goals of = "working well enough for random people=94 and =93providing a platform = for research=94.=20 >=20 > I hunger for the first, because we want people to be able to use = CeroWrt right away and not be scared off. (Rich=92s Rule of Trial = Software: Each hurdle that you place in someone=92s way reduces the = potential audience by half. :-) I am hopeful that we can find default = settings that are =93good enough=94 for all link layers so that new = people can see an improvement with CeroWrt. I am also mindful that the = features will likely wind up in OpenWrt unchanged; it=92s worth = struggling a bit with the GUI so that we minimize the folklore and = misinformation surrounding its use. >=20 > The tester in me also is rooting for the second goal. We need to be = able to test and tweak the entire queueing system. Making some of it = accessible via the GUI will make it easier to experiment, but of course, = limits the kinds of changes that could be made. (The lua scripts, = though, do give a lot of flexibility.) Well the biggest problem I see is that people on an ATM link = really really need the link layer adaptation so that the shaper actually = can work properly at all (otherwise they need to shape down a lot from = the nominal link speed to reduce the probability of filling the modems = buffers by underestimating the wire size/transfer time of packets). All = other people would rather not do this as the 48 in 53 encapsulation = reduces the rate to ~90% of the link speed and this is without thinking = about the last cell padding. In short there is not one link layer = setting that will be satisfactory for all users. (One could argue that = to give the ATM users a good out of box experience the default should be = link layer ADSL, and everyone else (vdsl2, cable, fiber) just sacrifices = some bandwidth; compared to everyone being happy out of the box except = the ADSL users=85). I guess, this is something that the user will need = to configure=85 (Also the overhead can not be really predicted so either = we take the maximum possible, 44 bytes, or risk bad out-of-box = experience for some users=85) Automatic detection of the link layer as implemented it takes a = link time (several hours) during which the internet connection must not = be loaded, so seems infeasible to run from the GUI for technically naive = users; think "a modal box saying: please wait 3 hours until the link = layer detection has finished". (The trick is to repeatedly measure the = RTT at 3 different packet sizes, N, N + 24, N+ 48, so that two of these = are guaranteed to have the same atm cell count, while the third is = either once atm cell shorter or longer. Then statistically test for = significance of differences and declare it ATM based if really two = measurement sizes are significantly different from the third. The catch = is that at the higher end of DSL say 16Mbit/s down (2097152 byte/s), = 2.8Mbit/s up (367001.6)) the amount of RTT added by a single atm cell is = quite small (around 0.15ms) compared to the RTT variance you typically = get with say ping so it takes a lot of measurements to get the = significance high... >=20 > On to more concrete ideas: >=20 > - =46rom what you=92ve said, I don=92t have much hope for doing it = automagically. I concur ... > But maybe we can provide clues to help the customer do to the right = thing. We can and should try. Since the whole issue is a mess any = recommendations will not be terrible concise though. > Perhaps the first dropdown could be =93Link Layer Adjustments (used on = DSL or ATM)=94=20 Technically the ATM part is the relevant part, the ADSL name is = only in there as too few people know about the actually carrier (and = they should not need to, ATM on ADSL links should just be phased out and = forgotten, but I digress) > with options for =93None/ADSL/SDSL/VDSL over PTM/VDSL over = ATM/PPPoATM=94 and maybe others > . CeroWrt could automatically set the proper link layer adaptations = for each. \ Would be nice, but people typically do not know the link layer = their internet connection uses as ISPs do not mention this as far as I = know. But as a first approximation we could say: ADSL users need to set = the link layer, cable, fiber, vdsl2 users do not. But once people have = too look up the relevant overhead it gets complicated no matter what... > We could also include a link to the wiki for a flow chart for setting = each of these cases, especially the questions they should ask their ISP. >=20 > - Would it be possible to keep from mentioning tc_stab in the GUI?=20 Well, I am going to hide the selection between tc_stab and = htb_private behind and "advanced details" checkbox, sounds okay? >=20 > Thanks! >=20 > Rich >=20 > PS That was a nice discussion of the (wackiness of) ATM framing.