From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 376E221F19A for ; Wed, 18 Dec 2013 05:24:16 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 26DA320B23; Wed, 18 Dec 2013 08:24:15 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 18 Dec 2013 08:24:15 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imap.cc; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=NGt+MCU8IRnHNjywlO7e9pS0Q1k=; b=JwMEF/a08Ex1KSMQpLJKo2+Scp/M QM/kwr+BTo0kKJooQbZoSfPyoTf/6Y/A7Ar17vNw3hiEGEflYTxDiBImgH5Rtt06 fRQsGXz+eqi93TxOwHpBsvLWTpyXcA+nZX11BPSEPGFS3jXFES4WfaC6R5BxGSz7 IyQGs7VqTecPDfk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=NGt+MCU8IRnHNjywlO7e9p S0Q1k=; b=OQtsix7HTwMWB3udlG2Yv3MQrg3beVxDpsoCiTsS3O5RL57pJKd/N/ n9x3YQo0QNr6JL4kLVi4CFkFGdH47o7c9Z7pbDldpf+cokNz+1lDqJDjU996VRbQ Vhx+4Y5PWoTUW1Etw9mJx8CAypBmP7Xgp1ffYkIIVXooSYqeKeBFI= X-Sasl-enc: Fh9DvzcKe0D3dKFMwYW/HYHJx5yEsuuuuS03U2i5ebmz 1387373054 Received: from [172.30.42.8] (unknown [89.240.239.70]) by mail.messagingengine.com (Postfix) with ESMTPA id 31F0EC00E83; Wed, 18 Dec 2013 08:24:13 -0500 (EST) Message-ID: <52B1A1FB.4050703@imap.cc> Date: Wed, 18 Dec 2013 13:24:11 +0000 From: Fred Stratton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sebastian Moeller , cerowrt-devel@lists.bufferbloat.net 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> <78BE7BAD-4886-4AF6-9AA5-6AAFBFC03EB2@gmx.de> In-Reply-To: <78BE7BAD-4886-4AF6-9AA5-6AAFBFC03EB2@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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 13:24:16 -0000 That does make things clearer. I was conflating FTTC and FTTH, as I was=20 making an incorrect assumption about FTTH terminal equipment. I probably should now run your script at some point to determine which=20 overhead value I should use. On 18/12/13 11:59, Sebastian Moeller wrote: > 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 ma= tters 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 fibr= e, normally to an MSAN within 200-300 metres of the user. >> >> 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 typicall= y a fiber modem at the home that "speaks" ethernet to the internal networ= k. Sidenote, to keep things cheap these Modems typically are not set up i= n a switched fashion, but rather with a hub, each modem sees several user= s traffic, but will only transmit traffic for its MAC (I think) into each= home; giving a clear upgrade patch should residential fiber become too s= low :) . > The important part is the last mile, basically were the bottleneck lin= k 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 ove= r fiber), from the users perspective this would not make link layer ADSL = the correct choice, assuming the DSLAM backbone connection typically is n= ot the bottleneck. (And even then all users would need to adapt for ATM f= or it to be useful; but all of this seems rather theoretical as there see= ms to be a push for telcos to consolidate on ethernet as infrastructure, = as I understand it). > >> 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 > >> >> On 18/12/13 10:33, Sebastian Moeller wrote: >>> Hi David, >>> >>> On Dec 18, 2013, at 05:34 , David Lang wrote: >>> >>>> On Tue, 17 Dec 2013, Rich Brown wrote: >>>> >>>>> - From what you=92ve said, I don=92t have much hope for doing it au= tomagically. But maybe we can provide clues to help the customer do to th= e right thing. Perhaps the first dropdown could be =93Link Layer Adjustme= nts (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 automaticall= y 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, espec= ially 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): lin= k 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 mecha= nism. >>> >>>> forget the GUI or automated settings. If I am configuring a Cerowrt = box mmanually, what should I set differently for the different types of c= onfigs? >>> 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-at= m/ (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/r275652= 51-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based- >>> >>> C) cable, GPON (fiber): >>> 1) Which link layer adaptation mechanism: none, assuming no per pack= et overhead >>> otherwise >>> 1) Which link layer adaptation mechanism: tc_stab >>> 2) link layer: ethernet >>> 3) overhead: unclear but see:http://www.dslreports.com/forum/r275652= 51-Internet-Per-packet-overhead-on-Bell-s-VDSL-ATM-based- >>> >>> There should be no need to fiddle with the advanced link layer option= s, unless you link MTU is >> 1500. Note for link layer ethernet no size t= able is constructed unless MPU > 0. >>> >>> >>>> What is the impact of getting it wrong? (if it's like VPN overhead w= here setting the rate just slightly too high results is lots of wasted 'a= irtime' by setting it too low results is a amall amount of wasted 'airtim= e' 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% wo= rst case, so this is not good.) But note this basically is the "status qu= o" for most users (as far as I know no router/modem sets these options co= rrectly, but I do not claim to know all such systems). ALSO this in theor= y is testable, on such a system buffer bloat/latency increase should be m= ore severe if one tries to fill the nominal transmit rates with small tha= n with large packets. Misjudging the overhead either wastes bandwidth or = also if too large or increases the likelihood to see buffer bloat by over= estimating 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 encapsula= tion into consideration). Plus they will overestimate the effective size = of small packets and will waste up to 50% of the remaining bandwidth ther= e. 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 us= er, ATM users will suffer buffer bloat, but will use all available bandwi= dth (well more actually since that creates the bloat), PTM users will suf= fer 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 t= han people in groups 2) and 3) and just accepted that depending on the pa= cket size mix latencies got more variable. >>> >>> Getting it wrong is not advisable=85 Getting it right requires some = non-obvious information from one's ISP. While VDSL will become more promi= nent 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 (o= r one day a new ADSL might learn to use PTM, but I will not hold my breat= h) >>> >>> Best Regards >>> Sebastian >>> >>>> 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 >>