From owner-freebsd-questions@FreeBSD.ORG Mon Sep 10 07:37:32 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EFF716A419 for ; Mon, 10 Sep 2007 07:37:32 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id D68A313C442 for ; Mon, 10 Sep 2007 07:37:31 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from TEDSDESK (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.13.8/8.13.8) with SMTP id l8A7bTh5094545; Mon, 10 Sep 2007 00:37:31 -0700 (PDT) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "RW" , Date: Mon, 10 Sep 2007 00:37:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Importance: Normal In-Reply-To: <20070909223523.55df5779@gumby.homeunix.com.> Cc: Subject: RE: ADSL Bandwidth Monitoring X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 07:37:32 -0000 > -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of RW > Sent: Sunday, September 09, 2007 2:35 PM > To: freebsd-questions@freebsd.org > Subject: Re: ADSL Bandwidth Monitoring > > > On Sat, 8 Sep 2007 23:16:35 -0700 > "Ted Mittelstaedt" wrote: > > > ... > > However, the thing that most people (who don't work at telcos) do not > > understand is that the telcos found very quickly that they cannot put > > contention into an ATM network comprised of a DSL atm circuits for a > > very simple reason. > > > > ... > > SO, the cost of discarding a single 56 byte ATM cell means the ATM > > cloud will have to get another 1400 bytes of data retransmitted > > through it. > > > > It doesen't take a rocket scientist to see that introducing contention > > into an ATM circuit carrying a DSL circuit will cause a massive > > increase in traffic in the switch, and wipe out any gains from > > contention. > > > > I don't know much about DSLAMS, but ATM switches have been able to drop > whole AAL5 frames for a long time. Do DSLAMS really not have EPD/PPD? > Why would they need it? The DSLAM doesen't need to control the traffic with ATM policing. It has control of the DSL circuit, remember. The modems aren't allowed to train at any old speed. They can only train up to the circuit speed the DSLAM port is configured to let them so the ATM circuit in the DSLAM is never going to see more traffic than what the port was contracted at. And, in any case, most of the DSL in the United States is asymmectrical - the customer receives far more bandwidth than they can transmit. Most of the RADSL modems out there in the US have chipsets that max at 7MB down and 1MB up. So, the DSLAM is going to be connected to an upstream link that can service the traffic coming FROM the upstream TO the DSLAM and TO the remote customers. When the DSLAM gets the traffic it's already been rate-limited. The only time the DSLAM would possibly need to rate-limit traffic is received traffic FROM the customer TO the upstream - and it is going to very likely be using an upstream pipe that is symmectrical, with gobs of available traffic - so a scenario where the DSLAM would need to rate limit traffic sent into the upstream pipe is difficult to imagine. It's also difficult to imagine that a telco would use ATM policing on the ATM switch that the ISP is connected to. That switch isn't going to see the rest of the telco's ATM network, and the ISP is going to be traffic limiting the VC's they are sending into the telco. Remember the telcos charge the ISP's for the privilege of interconnecting, and their charges are based on bandwidth. If an ISP contracts with a telco for, say 10MB of bandwidth, and the Telco starts policing at the ATM switch the ISP is connected to that limits it down to 5MB, then I would imagine it would be quite quick that the ISP's lawyers would be suing the telco. Hardly the way for a telco to entice the ISP to buy even more bandwidth on their DSL feed. To use EPD/PPD to police aal5 you would have to do it in the central ATM switch that all your remote DSLAMS are plugged into and that is also plugged into all the ATM switches that are feeding your ISP customers. But then the question becomes - how are you going to do it? Set fixed policing on all the DSL pvc's that are going through the ATM switch? To what end? If your going to fix-limit it, you might as well limit the individual DSLAM port that the customer is using and then free up more bandwidth that your going to burn up transferring the cells from the ISP through the first hop switch and into your main master atm switch. No you would have to dynamically limit it somehow. While I'm sure that these kinds of schemes exist, it seems to me just as easy to just buy a bigger ATM switch. > However the contention is done, it definitely happens in the UK. > Well, they drive on the wrong side of the road there too. ;-) Keep in mind I am not saying it is impossible for a telco to introduce contention into a DSL network. It is just a motive thing. Think of how their DSL network is put together and you can see that if you police in a central switch your going to be chewing up bandwidth in the rest of your network, and if you police at the fringes your going to have a lot of coordination issues to handle. To me the incentive doesen't seem to exist at the Telco to do it. It seems much more incentive exists at the ISP to do it. Ted