From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 599EE21F1AC for ; Wed, 18 Dec 2013 02:33:55 -0800 (PST) Received: from u-081-c054.eap.uni-tuebingen.de ([134.2.81.54]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MNZVG-1VrYQE1tHe-007CBp for ; Wed, 18 Dec 2013 11:33: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: Date: Wed, 18 Dec 2013 11:33:51 +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> To: David Lang X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:M5FKehzzPdV4ckd4OcbFVSSfSXAFWalrXNzKTsSiAlJ39Bw3Xaa /ajljDjsjkniCIjhx4AslSwMio9/JZSAxlykpZQfTbpjBL+MJ+gmIWAk4mHM45G23jjNULG Vb6Pj9bW1K+aMBrdLRC/eShEKoe5qLEKz0iCOqwTC+CEmgsfx4G6q91Y5X7NXX6pqF5sl0i oCKdmvrt1i3+cfzXKFp4w== 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 10:33:55 -0000 Hi David, On Dec 18, 2013, at 05:34 , David Lang wrote: > On Tue, 17 Dec 2013, Rich Brown wrote: >=20 >> - =46rom what you=92ve said, I don=92t have much hope for doing it = automagically. But maybe we can provide clues to help the customer do to = the right thing. Perhaps the first dropdown could be =93Link Layer = Adjustments (used on DSL or ATM)=94 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. 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 > Let's start with the first question, what is the difference between = these as far as what the config should be? 1) ATM based carriers (ADSL1, ADSL2, ADSL2+, potentially VDSL1): = link layer has to be set to ADSL 2) PTM based carriers (VDSL2): link layer has to be set to = ethernet 3) cable, GPON (fiber): link layer has to be set to ethernet 1) and 2) typically have additional overhead to account for, 3) = may or may not Only 3) with no overhead is fine with no link layer adaptation = mechanism. >=20 > forget the GUI or automated settings. If I am configuring a Cerowrt = box mmanually, what should I set differently for the different types of = configs? Current GUI settings (might change) A) ATM based transports: 1) Which link layer adaptation mechanism: tc_stab 2) link layer: ADSL 3) overhead: see = http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ (section: = Overhead and MTU Calculations) B) PTM based transports: 1) Which link layer adaptation mechanism: tc_stab 2) link layer: ethernet 3) overhead: unclear but = see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead= -on-Bell-s-VDSL-ATM-based- C) cable, GPON (fiber): 1) Which link layer adaptation mechanism: none, assuming no per = packet overhead otherwise 1) Which link layer adaptation mechanism: tc_stab 2) link layer: ethernet 3) overhead: unclear but = see:http://www.dslreports.com/forum/r27565251-Internet-Per-packet-overhead= -on-Bell-s-VDSL-ATM-based- There should be no need to fiddle with the advanced link layer options, = unless you link MTU is >> 1500. Note for link layer ethernet no size = table is constructed unless MPU > 0. >=20 > What is the impact of getting it wrong? (if it's like VPN overhead = where setting the rate just slightly too high results is lots of wasted = 'airtime' by setting it too low results is a amall amount of wasted = 'airtime' then a low enough value to be reasonalbe everywere is a good = default) User on an ATM based link without link layer adaptation: The = shaper will underestimate the relevant wire seize of each packet and = hence will not shape enough to avoid filling the potentially bloated = buffers of the DSL modem. This effect gets worse the more the packet = length distribution is skewed towards small packet (the estimate can be = off by around 50% worst case, so this is not good.) But note this = basically is the "status quo" for most users (as far as I know no = router/modem sets these options correctly, but I do not claim to know = all such systems). ALSO this in theory is testable, on such a system = buffer bloat/latency increase should be more severe if one tries to fill = the nominal transmit rates with small than with large packets. = Misjudging the overhead either wastes bandwidth or also if too large or = increases the likelihood to see buffer bloat by overestimating the = effective link capacity. Users on a PTM based link, when running with link layer ADSL, = will waste 10% of the bandwidth right there (for taking the 48 in 53 = encapsulation into consideration). Plus they will overestimate the = effective size of small packets and will waste up to 50% of the = remaining bandwidth there. Overhead misjudging has the same effect as on = ATM (except overheads on PTM typically should be smaller I guess so this = effect might not be too relevant). To summarize, using the wrong link layer adaptation will hurt = the user, ATM users will suffer buffer bloat, but will use all available = bandwidth (well more actually since that creates the bloat), PTM users = will suffer severe packet-size-dependent bandwidth decreases. The = "status quo" is more or less fine for groups 2) and 3), not so good for = 1). I think most people in 1) caring enough reduced the shaped rates by = a larger amount than people in groups 2) and 3) and just accepted that = depending on the packet size mix latencies got more variable.=20 Getting it wrong is not advisable=85 Getting it right requires = some non-obvious information from one's ISP. While VDSL will become more = prominent in the future, ADSL variants will not disappear for a long = time, as VDSL only works (well)=20 on short loops, so people far away from the DSLAM will stay on ATM (or = one day a new ADSL might learn to use PTM, but I will not hold my = breath) Best Regards Sebastian >=20 > David Lang_______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel