From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 0619621F118 for ; Wed, 18 Dec 2013 03:59:43 -0800 (PST) Received: from u-081-c054.eap.uni-tuebingen.de ([134.2.81.54]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsUDg-1VV0rM22nI-0123O0 for ; Wed, 18 Dec 2013 12:59:40 +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: <52B186BB.9010601@imap.cc> Date: Wed, 18 Dec 2013 12:59:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <78BE7BAD-4886-4AF6-9AA5-6AAFBFC03EB2@gmx.de> References: <34E77F64-739C-49E4-B8A4-6ABBEAE4174B@gmail.com> <8DB84101-C942-49C4-99F0-6C9319961297@gmail.com> <22176178-A50F-48F2-A3A1-D3853764AD0E@gmail.com> <52B186BB.9010601@imap.cc> To: Fred Stratton X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:ZwJxW9UyUAR7azgozJGzQx9tu9L+9u/5S3sSRI0XB0D90kw3pAt jA5Z1t3qydLpaNcZvjwvTJdeD541WwqiTX6QGSxgTRQeYQU1D8Tby9KUei/qPizTRFd6MPw sHtR+kIII0D3v/9NL3zsTmbuIb8FjLz0do1+gmEAsRwponpr5DWYwURB/0DOud2tQfmLSjT lL8QzBgaCO/g9ydWmAVqQ== 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 11:59:43 -0000 Hi Fred, On Dec 18, 2013, at 12:27 , Fred Stratton wrote: > VDSL2 uses PTM. This is what I understand from the available information as = well. Also I think that even VDSL1 typically uses PTM, but my knowledge = in these matters is quite limited, (I am neither a telco nor do I work = for one) > In the UK, the regulator has mandated that VDSL2 must be run over = fibre, normally to an MSAN within 200-300 metres of the user. >=20 > So what is the fibre in your cable and fibre category? Fiber as in 3) of my mail would be fiber to the home FTTH. So = typically a fiber modem at the home that "speaks" ethernet to the = internal network. Sidenote, to keep things cheap these Modems typically = are not set up in a switched fashion, but rather with a hub, each modem = sees several users traffic, but will only transmit traffic for its MAC = (I think) into each home; giving a clear upgrade patch should = residential fiber become too slow :) . The important part is the last mile, basically were the = bottleneck link sits. Even if a VDSL "DSLAM" would be connected to the = ISP backbone via an ATM link (and there is no reason I know why you = could not run ATM over fiber), from the users perspective this would not = make link layer ADSL the correct choice, assuming the DSLAM backbone = connection typically is not the bottleneck. (And even then all users = would need to adapt for ATM for it to be useful; but all of this seems = rather theoretical as there seems to be a push for telcos to consolidate = on ethernet as infrastructure, as I understand it). >=20 > Is it FTTC/FTTH as I describe, or fibre using some other transmission = protocol? What you scribe is FFTC, and as stated above we are mostly = interested in the DSLAM to MODEM link. I hope to have cleared thngs up=85 best Sebastian >=20 >=20 > On 18/12/13 10:33, Sebastian Moeller wrote: >> Hi David, >>=20 >> On Dec 18, 2013, at 05:34 , David Lang wrote: >>=20 >>> 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. >>> 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 >>=20 >> 1) and 2) typically have additional overhead to account for, 3) = may or may not >>=20 >> 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- >>=20 >> 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- >>=20 >> 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 >>=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. >>=20 >> 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). >>=20 >> 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) >> 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) >>=20 >> Best Regards >> Sebastian >>=20 >>> David Lang_______________________________________________ >>> 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 >=20