Article View: comp.dcom.modems.cable
Article #497Re: cable guy "vapor"-izes DSL 3X cable TV troll!
From: Lawrence Baldwin
Date: Sat, 03 Feb 2001 15:52
Date: Sat, 03 Feb 2001 15:52
91 lines
5386 bytes
5386 bytes
> > I don't think so. Upstream oversubscription is really an issue only on > > cable, since (1) DSL has dedicated upstream to the DSLAM, and (2) > > backhaul links are symmetric (as compared to asymmetric subscriber > > connections). I disagree on one finer point. This is where I think we agree: * TCP itself will limit downstream throughput when the upstream channel becomes saturated * Cable upstream saturation (between customer and CMTS) is highly likely because of the shared nature of the link User A can be degraded because B, C, D, and E are uploading at max rate. -or- User A can be degradged because just the cumulative affect of all users ACK traffic causes saturation. (this would seem to occur only where *many* users share the same local segment). * ADSL upstream saturation (between the customer and the DSLAM) is highly unlikely because it is a private link. (Though the customer could saturate it himself with some kind of outbound datastream...e.g. UDP broadcast video). It's NOT going to saturate just due to his outbound ACK traffic. Assuming download rate of 150,000Bytes/sec, with 1500 bytes packets...that's about 100packets/sec. That should result in upstream 50packets/sec of 64byte ACKs...that's 25Kbps, far less than the 256Kbps typical ADSL upstream bandwidth. Here is where I disagree: Downstream degradation occurs WHENEVER the uplink is saturated. Granted the more limited (and shared) upstream bandwidth of cable makes this an easy choke point. However, ANY uplink that saturates can have the same affect. Even though bandwidth between the DSLAM and aggregation router is assymetric (e.g. 45Mbps full-duplex), you could still saturate upstream before downstream, depending on what users are doing. For example, if 5% (175) of the ~4000 ADSL users aggregated into a DS3 ran active web servers (uploading at constant 256Kbps), you'd saturate the upstream. I'm not saying that this is extremely likely, but I believe the best way to quantify the probablility is to quantify: upstream oversubscription rate To do an apples to apples comparison, you need to compare both technologies at the same layers: Customer to Local Aggregation (I think we agree cable and ADSL infrastructure upstream from the aggregation layer use similar architectures). ADSL: Subscriber to Aggregation router Cable: Subscriber to CMTS router I suspect the upstream oversubscription rate (at the local aggregation layer) of cable is 10x-20x more than ASDL. I think this is a more generic way to quantify the probability of upstream saturation and provide metric to compare different technologies on equal ground. In fact we already know that the way to compare different ISPs to each other is to understand their downstream oversubscription policies. What I find intriguing, is that you need to look at upstream as well...this is a real eye-opener for me. Taking this concept a bit further, my real suspicion is the oversubscription at the *backbone* layer is what is causing the most differences in experienced throughput variances between different providers (whether ADSL or cable, or whatever). Wish I had the data to back that up though. Upstream saturation might actually be an even bigger issue at backbone interconnect layer. Think about it, how many ISPs merge ADSL traffic (downstream traffic) with commercial T1 traffic (primarily upstream) at the backbone layer. I suspect that few considered the impacts of upstream saturation on ADSL throughput...or ADSL downstream traffic saturating the reverse channel of their T1 customers...hmmmmm. lb. -- ------------------------- Lawrence Baldwin Protocol Scientist 678-624-0924 http://www.mynetwatchman.com - I'm under attack, now what?
Technical Details
Message-ID:
<3A7C2957.6083F801@mynetwatchman.com>Path:
arc1-ca.pugleaf.net!supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.atl.bellsouth.net.MISMATCH!newsfeed.atl!news3.atl.POSTED!not-for-mailReferences:
<3A648E27.6A7029EF@erols.com> <20010116192016044.AAA95@adsl-209-204-185-87.sonic.net@john.navasgroup.com> <3A64B680.2A79F24D@erols.com> <3A76B6CA.73B36B26@mynetwatchman.com> <4OGd6.100$mW6.5202@typhoon.sonic.net> <3A776B57.C495242C@mynetwatchman.com> <R3Ld6.144$mW6.6010@typhoon.sonic.net> <3A782325.2538A5E2@mynetwatchman.com> <diEe6.142$Tf1.5347@typhoon.sonic.net> <3A7B357B.3C2C1C79@ufl.edu>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1122a6,2145df83169cbbc6 X-Google-Attributes: gid1122a6,public X-Google-Thread: 113850,916316de6f72ceb X-Google-Attributes: gid113850,public X-Google-Thread: f5dc1,916316de6f72ceb X-Google-Attributes: gidf5dc1,public X-Google-ArrivalTime: 2001-02-03 07:53:03 PST Path: arc1-ca.pugleaf.net!supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.atl.bellsouth.net.MISMATCH!newsfeed.atl!news3.atl.POSTED!not-for-mail Message-ID: <3A7C2957.6083F801@mynetwatchman.com> From: Lawrence Baldwin <baldwinlSPAMMENOT@mynetwatchman.com> X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.dcom.modems.cable,bellsouth.net.support.adsl,comp.dcom.xdsl Subject: Re: cable guy "vapor"-izes DSL 3X cable TV troll! References: <3A648E27.6A7029EF@erols.com> <20010116192016044.AAA95@adsl-209-204-185-87.sonic.net@john.navasgroup.com> <3A64B680.2A79F24D@erols.com> <3A76B6CA.73B36B26@mynetwatchman.com> <4OGd6.100$mW6.5202@typhoon.sonic.net> <3A776B57.C495242C@mynetwatchman.com> <R3Ld6.144$mW6.6010@typhoon.sonic.net> <3A782325.2538A5E2@mynetwatchman.com> <diEe6.142$Tf1.5347@typhoon.sonic.net> <3A7B357B.3C2C1C79@ufl.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 91 Date: Sat, 03 Feb 2001 10:52:55 -0500 NNTP-Posting-Host: 208.61.191.103 X-Trace: news3.atl 981215577 208.61.191.103 (Sat, 03 Feb 2001 10:52:57 EST) NNTP-Posting-Date: Sat, 03 Feb 2001 10:52:57 EST