From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (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 A26B221F636 for ; Sat, 2 Aug 2014 13:17:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E495C20012; Sat, 2 Aug 2014 16:19:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5FDC5638D9; Sat, 2 Aug 2014 16:17:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B523638D7; Sat, 2 Aug 2014 16:17:32 -0400 (EDT) From: Michael Richardson To: Sebastian Moeller In-Reply-To: <00AE9446-35B8-4A09-BA78-840DFC36F1DB@gmx.de> References: <598BFF8C-37B6-4F5B-9F0D-A0D69A1F32B7@gmx.de> <13043.1406868668@sandelman.ca> <00AE9446-35B8-4A09-BA78-840DFC36F1DB@gmx.de> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Wes Felter , cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration. 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: Sat, 02 Aug 2014 20:17:34 -0000 Sebastian Moeller wrote: >> Sebastian Moeller wrote: >>> No idea? How would you test this (any command line to try). The good >>> thingg with the ping is that often even the DSLAM responds keeping >>> external sources (i.e. hops further away in the network) of >>> variability out of the measurement... >> >> With various third-party-internet-access ("TPIA" in Canada), the DSL= AM >> is operated by the incumbent (monopoly) telco, and the layer-3 first >> hop is connected via PPPoE-VLAN or PPP/L2TP. > So they =E2=80=9Cown=E2=80=9D the copper lines connecting each custo= mer to the DSLAM? > And everybody else just rents their DSL service and resells them? Do > they really connect to the DSLAM or to the BRAS? correct, the copper continues to be regulated; the incumbent was given a guaranteed 11-14% profit on that service for the past 75 years... Third parties get an NNI to the incumbent in a data centre. 1) for bridged ethernet DSL service ("HSA" in Bell Canada land), the each customer shows up to the ISP in a VLAN tag. 2) for PPPoE DSL service, the traffic comes in a specific VLAN, over IP (RFC1918) via L2TP. Other parties can put copper in the ground, and in some parts of Canada, th= is has occured. Also worth mentioning that AlbertaGovernmentTelephone/EdmontonTel/BCTel became "TELUS", and then left the Stentor/Bell-Canada alliance, so Bell can be the third party in the wes= t, while Telus is the third party in the centre, and Island/Aliant/NBTel/Saskt= el remain government owned... and they actually do different things as a resul= t. > I think in Germany the incumbent has to either rent out the copper > lines to competitors (who can put their own lines cards in DSLAMs > backed by their own back-bone) or rent =E2=80=9Cbit-stream=E2=80=9D a= ccess that is the > incumbent handles the DSL part on both ends and passes the traffic > either in the next central office or at specific transit points. I > always assumed competitors renting these services would get much bett= er > guarantees than end-customers, but it seems in Canada the incumbent h= as > more found ways to evade efficient regulation. This option exists, but the number of CLECs is large, and the move towards VDSL2 / Fiber-To-The-Neighbourhood (with much shorter copper options!!) mea= ns that this is impractical. >> my incumbent telco's commercial LAN extension salesperson proudly to= ld >> me how they never drop packets, even when their links are congested!= !! > I really hope this is the opinion of a sales person and not the > network operators who really operate the gear in the =E2=80=9Cfield= =E2=80=9D. On the > other hand having sufficient buffering in the DSLAM to never having to > drop a packet sounds quite manly (and a terrible waste of otherwise > fine DRAM chips) ;) I think much of the buffer is the legacy Nortel Passport 15K that ties much of the system together... >> The Third Party ISP has a large incentive to deploy equipment that >> supports whatever "bandwidth measurement" service we might cook up. > As much as I would like to think otherwise, the only way to get a BMS > in the field is if all national regulators require it by law (well > maybe if ITU would bake it into the next xDSL standard that the DSLAM > has to report current line speeds as per SNMP? back to all down stream > devices asking for it). But I am not holding my breath=E2=80=A6 My position is that if there isn't a technical specification, no regulation could possibly follow... -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [