Bell Canada Offers 'Proof' Throttling Was NecessaryResponds to Canadian regulator demand for hard data... 06:19PM Tuesday Jun 24 2008 by Karl Bodetags: competition · business · bandwidth · world · net-neutrality · Bell Sympatico · TekSavvy Solutions Inc.Bell Canada recently decided it would be a good idea to throttle P2P traffic before it hit independent wholesale ISP networks, without telling anyone about it. While it's fairly clear the move was aimed at ensuring that nobody could offer higher quality service than Bell Canada's Sympatico unit, Bell Canada proclaimed that the move was made necessary by out-of-control P2P traffic hijacking capacity. Smaller Canadian ISPs turned to the Canadian Radio-television and Telecommunications Commission (CRTC) for help. While the CRTC did not grant the requested immediate relief to ISPs from Bell's throttling, the commission did request that Bell Canada provide proof that congestion made the move necessary. In filings, Bell Canada simply repeated talking points, claiming that actual network data constituted confidential trade secrets. Last week the CRTC demanded the release of that data, and Bell complied this week via these filings (zipped .doc). In these latest filings, Bell offers a chart that proclaims to show the percentage of congested links (central office DSLAMs, aggregation network, BAS and backbone network). Though the data doesn't appear to show serious congestion, Bell insists it's all how you read it: As can be observed in the table above, the total percentage of all four types of congested network links during a given month in the period in question has varied between 2.6% and 5.2%. While these numbers may seem low to the average lay person, they are significant to network traffic engineers such that it is important to consider the number of congested links in the proper context. I'm still reading through the filings, but initial reaction to the filing among users and competitors in our forums range somewhere between a chortle and a guffaw. "I'm Just surprised they considered this "Confidential Trade Secrets"," says one user. "I guess the only secret they wanted hidden is that they have an under-used network capacity re-branded as congested beyond repair." I'd be interested in seeing some opinions in our comment section from real network engineers in the industry. Related:- Remember How The Net Neutrality Fight Began
- CRTC Debates Bell Canada Throttling
- Canadians Plan Net Neutrality Protest May 15
- Bell Canada Fires Up The Spin Doctors
- Industry Laughs Off Bell Canada Congestion Claims
- Bell Canada: Throttling Aids Innovation
- Bell Canada Devises Backup Plan To Kill Wholesale Competitors
- Bell Outlines Plan To Cap Wholesalers
|
page: 1 · 2  |
  punker deleted by moderator Premium join:2004-06-21 Palmdale, CA clubs: edit: June 24th, @11:48PM
| i can just type an bunch of numbers  | |
|  |  james1
join:2001-02-26 antarctica | Re: i can just type an bunch on numbers ME TOO!
12ST 16PE 09EN 18CH 08IN 08AG 18LU
Wait! That's not my line's stats! That's my Fallout char's stats! | |
|  |  |  |  |   r81984 Tough to beat. Premium join:2001-11-14 Morgan City, LA | I love the title "network traffic engineers".
It seems like any job can be called an engineer. -- »www.ryanoneill.us | |
|  |  |   DanPure
@teksavvy.com
| Re: i can just type an bunch on numbers I've actually questioned this in my own submission to the CRTC. Are these credentialed, licensed & bonded Professional Engineers, or are they improperly (and perhaps illegally) using the title of "engineer"?
One would think lawyers would know better than to get in the titles mess. | |
|  |  |  |   Maynard G Krebs
@teksavvy.com
| Re: i can just type an bunch on numbers said by DanPure :
I've actually questioned this in my own submission to the CRTC. Are these credentialed, licensed & bonded Professional Engineers, or are they improperly (and perhaps illegally) using the title of "engineer"?
One would think lawyers would know better than to get in the titles mess. In Ontario it is illegal to represent yourself as an engineer (as a person or as a firm engaged in engineering) unless you are degreed from an accredited school of engineering, have practiced engineering for at least 2 years under supervision of a licensed engineer, and have passed the relevant licensing exam. Then and only then may you add P.Eng to your business card.
Microsoft and Redhat have both been slapped around in Ontario for advertising their Windows/Linux administrator training courses as having anything to do with 'engineering'. Neither Microsoft or Redhat can mention the word 'engineer' in any of their materials used for advertising these courses, nor in the course material itself.
People who pass those courses are NOT permitted to represent themselves as engineers in any written materials, nor in conversation. Doing so is an offense under the relevant legislation - much the same as purporting to be a police officer when you aren't. | |
|  |  |  |  |   ERTW
@cgocable.net
| Re: i can just type an bunch on numbers ...and it's a complaint based system that's mostly useless. Until I see accredited engineers going to prison for life on a regular basis (there's plenty of civil/criminal/scientific/economic evidence to convict under current legislation), I'll continue to view the APEO as outdated and useless...except to artificially inflate undeserved wages. You know, useless, just like that old chain they like to impress new members with. I should know, I've taught some of the imbeciles and had to lug that chain around more than once.
The IEEE still does something useful with its' myriad of working groups. Sometimes.
Signed, a card carrying, iron pinky ring in the garbage, EE P.Eng (with a stamp, too!) | |
|   Jahntassa What, I can have feathers
join:2006-04-14 Conyers, GA
| Which numbers are relevant? Okay, so they separated the numbers by where the congestion happened on what part of the networks. Is there anything besides the DSLAM that would affect the independents?
They show it as a percentage of connections that are congested, but without a base number that doesn't really help. 5% of what? 10? 20? 1,000?
I guess I can see the congestion on the one part of the network, but doesn't that suggest that they should work on, perhaps, expanding that part of their network?
Also, did they throttle themselves? | |
|  james1
join:2001-02-26 antarctica | I figured it out I know what happened, they mixed their percentages of congested lines up with their percentages of satisfied customers. | |
|   stoopid
@photothera.com | Can I get a dictionary....
How is "Congestion" defined? Dropped packets, 100% capacity or some new marketing term to sell this BS? | |
|  cooldude9919
join:2000-05-29 Cape Girardeau, MO clubs: | Graphs Real "network traffic engineers" would have supplied mrtg graphs with some sort of description for each link. | |
|  |   TK Junk Mail Go ahead, make my day Premium join:2002-03-03 Margate City, NJ clubs:
·Comcast
| Re: Graphs said by cooldude9919 :Real "network traffic engineers" would have supplied mrtg graphs with some sort of description for each link. The data they are supplying is going to convince politicians and bureaucrats and not other network engineers. -- My BLOG .. .. Internet News .. .. My Web Page | |
|  |  |   NetAdmin
join:2008-05-22
| Re: Graphs said by TK Junk Mail :The data they are supplying is going to convince politicians and bureaucrats and not other network engineers. Yeah, but everybody loves graphs, especially technically clueless politicos and bureaucrats... As well, graphs usually make information easier to read. Their percentages, for example, are pretty vague and the fact that they say that it depends on how you look at it just confirms that they are overly vague and presented that way on purpose. Concrete information should be presented. -- --- Over ten plus years of carrying The Clue Bat... | |
|  |  |  |   KrK Heavy Artillery For The Little Guy Premium join:2000-01-17 Tulsa, OK
·Cox HSI
·AT&T Southwest
| Re: Graphs said by NetAdmin :are pretty vague and the fact that they say that it depends on how you look at it just confirms that they are overly vague and presented that way on purpose. Concrete information should be presented. Um if they presented concrete information, they'd lose their argument that they must throttle 3rd party ISP's. -- "Regulatory capitalism is when companies invest in lawyers, lobbyists, and politicians, instead of plant, people, and customer service." - former FCC Chairman William Kennard (A real FCC Chairman, unlike the current Corporate Spokesperson in the job!) | |
|  |  |  |  |  cooldude9919
join:2000-05-29 Cape Girardeau, MO clubs:
| Re: Graphs said by KrK :said by NetAdmin :are pretty vague and the fact that they say that it depends on how you look at it just confirms that they are overly vague and presented that way on purpose. Concrete information should be presented. Um if they presented concrete information, they'd lose their argument that they must throttle 3rd party ISP's. We all basicly know this to be true. They are intentionally being vague to further their cause, why else would they release such information? With the internet expanding at an ever increasing rate of course wan links are going to need upgrading its just a matter of when and how much. If they can get away with delaying the upgrades its just more profits for them so they are going to try to get away with whatever possible. | |
|  |  |  |  |  |  |  |  |   Guspaz Guspaz Premium,MVM join:2001-11-05 Montreal, QC
·Colbanet
·TekSavvy Solutions..
| Re: Graphs These graphs, of course, show that their estimated cell loss is a percentage too low to calculate on most calculators. Seriously, they move enormous amounts of data (a single GigE could push 20TB in a day, their network pushes a lot more than a gigabit per second), ATM cells have a 48-byte payload, so if we consider that they must be pushing around hundreds of terabytes per day, we're looking at multiple trillions of cells per day.
Losing 4500 cells out of trillions is unbelievably low. | |
|  |  |  |  |  |  |  |  |  |  |   NetAdmin
join:2008-05-22 | I must have missed those when I glanced over the document... | |
|  |  |   Maynard G Krebs
@teksavvy.com
| said by TK Junk Mail :said by cooldude9919 :Real "network traffic engineers" would have supplied mrtg graphs with some sort of description for each link. The data they are supplying is going to convince politicians and bureaucrats and not other network engineers. At a minimum, real engineers would have supplied raw data and a complete description of their control and sampling methodologies, along with a discussion of the techniques they used to reduce the data to tabular form. | |
|  |  |  |  |   Capt Cap
@sonnet.com
| This is Telco's equivalent to Cable node overload The %'s are significant, because they are congestion on ATM ports. ATM doesn't mean money; it is a telco protocol similar to IP that does not deal well with congestion. A 1500-byte TCP/IP packet might be split into 32 53-byte(48-byte payload) ATM cells.. Losing one cell means the other 31 cells are toast, even if they are delivered.
What this effort by Bell Canada shows is that the changing utilization rates of DSL customers vs. the backhaul bandwidth to DSLAMS is putting the squeeze on Bell and they want to curtail it, rather than try to keep up with it. Keeping up with it means higher wholesale DSL line charges, or higher costs for ISPs backhaul circuits to connect to the DSLAMs.
As you might recall, British Telecom has been screeching about the same thing because of BBC iPlayer.
Say hello to metering! | |
|  |   ohreally
@enta.net
| Re: This is Telco's equivalent to Cable node overload said by Capt Cap :
As you might recall, British Telecom has been screeching about the same thing because of BBC iPlayer.
Say hello to metering! I haven't seen BT complain about iPlayer (indeed, their own IPTV service now includes iPlayer content, but at a price). If they did, it would be in the context of their own retail network, not the wholesale ADSL network that other ISPs also use (and that'll change when they get their IP network up and running).
Nor have they floated the idea of traffic shaping on the wholesale level.
The only ISPs I have seen complaining are the likes of Tiscali which cut costs everywhere and their customers wonder why dialup is faster. | |
|   baineschile1
@comcast.net
| throttle me for saying it... heres the biggest problem i see with ISP throttling; yes they shouldnt do it, yes its wrong for them to advertise unlimited access when it is limited, but...most bittorrent throttle was....PIRATED MATERIAL!!! it stinks for the people who use it for legit reasons, but for us to complain that i had packet loss when downloading Iron Man...its tough to complain. | |
|  |   sbrook Premium,Mod join:2001-12-14 H0H 0H0
·Rogers Hi-Speed
Host: Rogers Bell Canada
| Re: throttle me for saying it... That's not the point. It's the thin edge of the wedge. What will they decide to throttle with absolutely no technical basis? You're on Comcast ... so say they throttle traffic that originates from a Qwest, Verizon, Charter IP address whether business level or not. Say they have an agreement with MSN (which Bell does), so say they decide to throttle Yahoo! content provisions.
There are thousands of other non-net neutral scenarios that can lead from this.
Telcos throttling VoIP
It's the ISP telling you what they want to you to do with the internet connection.
The matter of pirated material is another one altogether and should be dealt with in its own arena ... not this one where the focus is net neutrality. | |
|  |  |  |  |   Maynard G Krebs
@teksavvy.com
| said by baineschile1 :
heres the biggest problem i see with ISP throttling; yes they shouldnt do it, yes its wrong for them to advertise unlimited access when it is limited, but...most bittorrent throttle was....PIRATED MATERIAL!!! it stinks for the people who use it for legit reasons, but for us to complain that i had packet loss when downloading Iron Man...its tough to complain. Do you have *hard* numbers which can support your claim that the majority of torrent material d/l via Bell circuits is pirated?
With an increasing number of legitimate content providers moving to torrent distribution models, nobody has any idea - especially if the torrent content is encrypted - which it may be for legitimate reasons. | |
|  NOCMan Verizon Fios User Premium join:2004-09-30 Flower Mound, TX
| It's Clear Bell Canada was selling a product and failed to deliver on it.
I'm sure those ISP's who bought lines wholesale had SLA agreements and I'm sure BC violated it. I could not for the life of me think that a corportion would oversubscribe the services they sell to their customers.
Oh wait.. Sprint Frame Relay. -- Mac Chatter »www.macchatter.net | |
|  |  ivan69
join:2004-01-30 99999 | Re: It's Clear You forgot TWC. | |
|  |  espaeth Misanthrope Premium join:2001-04-21 Minneapolis, MN | Every carrier out there oversubscribes their Frame / ATM / MPLS clouds. What's your point? | |
|  |  |  |   tater_gunz Shoot to kill Premium join:2003-08-22 Toledo, OH
·buckeye cable
| said by NOCMan :I could not for the life of me think that a corportion would oversubscribe the services they sell to their customers. Oh wait.. Sprint Frame Relay. ALL telecom services are over-subscribed. That's just how it works. I don't disagree with what you're saying, I'd just like others to understand that the over-subscription model is more widespread than folks realize.
- Tate
-- Happiness is an OC-768 in your basement... | |
|  |  |   Guspaz Guspaz Premium,MVM join:2001-11-05 Montreal, QC | Re: It's Clear They're all oversubscribed, but when you buy a dedicated service like the AHSSPI links, they're not supposed to tell you that it's congested. They're supposed to at least pretend that they're not oversubscribed. | |
|  |  |  |   Jcan87
@bell.ca
| Re: It's Clear Remember that the PSTN is built to handle 10% of overall potential load. Meaning if everyone tried to dial at the same time only 10% would get a line. Perhaps the issue is that the telecoms and cablecos are building their internet networks with the same mentality. In a world of P2P, this is not going to cut it.
Not saying they are right or wrong, but surely have to shift mindset if we want always on, always fast, always used internet. | |
|   TK Junk Mail Go ahead, make my day Premium join:2002-03-03 Margate City, NJ clubs:
·Comcast
edit: June 24th, @07:22PM
| Low % congestion #'s could still indicate problem though
As can be observed in the table above, the total percentage of all four types of congested network links during a given month in the period in question has varied between 2.6% and 5.2%. While these numbers may seem low to the average lay person, they are significant to network traffic engineers such that it is important to consider the number of congested links in the proper context. Those numbers are relevant in the context of interactive traffic. Also the percentages can be additive as a packet traverses different sections of the network. They are no problem if we are talking about batch file transfers.
see: »www.usenix.org/events/lisa00/ful···dex.html
Congestion and Circuit Capacity Planning
Like many organizations, we collect router statistics via SNMP every five minutes. While five-minute averages are a useful measure of how a circuit is doing in relationship to its bandwidth limit, they do not tell a lot about the instantaneous (one second, or smaller, time scale) state of a circuit that governs interactive performance. If a circuit is saturated for several ten-second bursts during a single five-minute period the average utilization might appear to be quite reasonable. An interactive user, however, would likely say that the network was slow while his packets were waiting in a router buffer. Since Bell of Canada was using 15 min snapshots and not even the inadequate 5 min snapshots, the low percentages could still mean that congestion is occurring and that interactive traffic is suffering.
It would be interesting to know if Bell also took shorter snapshots(say every second for short periods of time) to get a finer look at suspected congested links, thereby determining if interactive traffic had unusually high latency. Without that kind of data, the supplied stats aren't very persuasive.
But they are probably just supplying what the CRTC demanded and nothing more. Bell's network engineers would have performed other studies with shorter snapshot periods for their own use and the info they supplied to the CRTC also provided latency measurements(another measure of congestion).
This graph that Bell supplied the CRTC was much better at indicating the growing problem than the chart headlined in the BBR story:

-- My BLOG .. .. Internet News .. .. My Web Page | |
|  |  See 9 replies to this post | |
  Maggs Premium join:2002-11-29 Woodside, NY clubs:
·RCN CABLE
| No Network Engineer will touch this! Karl, you know people need a job. If you want your job, you tow the line, and STFU and obey your master. That's why they call common law employment, a master servant relationship. I know for damn sure you wouldn't badmouth BBR, since you would be out of a job in a heartbeat. -- NIL ILLEGITIMUS CARBORUNDUM! | |
|  |  |  |  |   Maggs Premium join:2002-11-29 Woodside, NY clubs: | Re: No Network Engineer will touch this! every network engineer works for an employer. Mike if you were to tell your boss go froogle yourself, how long do you would have a job? -- NIL ILLEGITIMUS CARBORUNDUM! | |
|  |  |  |  |  espaeth Misanthrope Premium join:2001-04-21 Minneapolis, MN | Summarizing data until it means nothing... I'm sure there's good data they can present, but this certainly isn't it. x% of their links were congested -- when? One day in the month for 5 minutes? Every day for 12 hours a day? | |
|   phoneboy3
@shawcable.net
| Let the market decide I'm not a network engineer but I know enough about it that I do believe there is a valid technical argument from the Telco's. They are ALL starting to bring up this problem. Network management or throttling is definitely the best answer.
That is the easy part. The hard part is deciding what if any rules need to be followed to keep everything on an even playing field in the interest of net neutrality.
Favoring certain kinds of traffic and penalizing certain other kinds that could be considered as in their best business interest should be under a microscope. There needs to be some way for 3rd parties to monitor things to keep everyone honest.
Lastly and most importantly, let the market decide. So, for example they should only be allowed to throttle traffic coming from sources that have alternative network choices. Chances are most of their congestions comes from the larger urban areas that already have alternative networks.
If they have a problem with that they should be given the option of opening up those monopolistic parts of their network to 3rd party providers under some sort of regulated pricing structure. | |
|   sporkme drop the crantini and move it, sister Premium,MVM join:2000-07-01 Netcong, NJ
| Step 1: Define congestion.
Without that, all these percentages are totally meaningless.
Not to mention that any "traffic engineer" can create congestion through inaction. Internet traffic is increasing. If you don't build your network at the same pace as everyone else, you will end up with overstuffed tubes. You might call that self-imposed congestion when you are a telco that owns the tubes.
This whole report looks like a total crock. Maybe they hired Arthur Andersen to do the numbers. -- with every mistake we must surely be learning | |
|  |  hoyleysox
join:2003-11-07 Long Beach, CA
·Time Warner Telecom
| Re: Step 1: I just looked at the Ontario-Quebeck graph. It is unclear how 'congestion' is defined bsed on the graph displayed by BBR. Pipe utilization fluctuates. It is not clear what metric the graph displays. Max? Average? There is a possibility of misplaced attribution: congestion could result from an increase in the number of subscribers, not necessarily in the amount of traffic each subscriber consumes. | |
|   Bellus_today
@cia.com
from: TK Junk Mail 
| The issue is everywhere. If you look at this data and combine it with some telecom knowledge, you understand BC's major projects that impact xDSL services: A remote or subtended shelf is linked with 1 or 2 155Mbps OC-3 links. If one of these can have up to 144 ports, you see the issue. Back when speeds where 1.5Mbps, this wasn't an issue, and not all shelves or RT's will have high subscription rates, and those that do will more likely have been upgraded with the sort-of-fix: Dual gig-e fed Stingers with VDSL2 LIM's (3X48 Ports, I9450 chipset). But the issue here is that much of this extra bandwidth will be reserved for IPTV, so DPI/QoS will still be used. At least they will all have the Gige uplinks in a LAG that can gracefully fail over to a single link.
Next the aggregation: this is simple... the upstream Al-Lu equipment that most dslams connect to is ATM based with a pair of relatively slow OC-12 uplinks, and these can feed 48 subtended stingers. This is also being upgraded for the future that has multicast/IGMP and ethernet rather than ATM to support IPTV. The aggregation layer also goes from OC-12/48 to Gige that probably go to a Nortel 8600 edge router, then onto core routers.
**DPI by ellacoya/arbor is now inserted here before or after the BAS. Has slow Gige interfaces considering how much traffic there is, so 10GE upgrades are coming**
Finally, the BAS/SMS servers after which traffic exits onto the 3rd party networks (Gateway Access Service, Teksavvy, etc.). These are servings thousands of clients and aren't exactly crazy fast... Juniper 1410/1440. These will also likely move to E320's which have better throughput, faster interfaces and backplanes and best of all, more redundancy and better failover.
So yes, DPI sucks, especially since the system doesn't apply it only to the clients from congested elements, but to any PPPoE xDSL user. But it is needed to alleviate congestion to a degree, especially until next generation infrastructure is implemented. | |
|  |   R0CKY TSI Rocky Premium,VIP join:2005-05-19 Chatham, ON
edit: June 24th, @10:36PM
| Re: The issue is everywhere. said by Bellus_today :
If you look at this data and combine it with some telecom knowledge, you understand BC's major projects that impact xDSL services: A remote or subtended shelf is linked with 1 or 2 155Mbps OC-3 links. If one of these can have up to 144 ports, you see the issue. Back when speeds where 1.5Mbps, this wasn't an issue, and not all shelves or RT's will have high subscription rates, and those that do will more likely have been upgraded with the sort-of-fix: Dual gig-e fed Stingers with VDSL2 LIM's (3X48 Ports, I9450 chipset). But the issue here is that much of this extra bandwidth will be reserved for IPTV, so DPI/QoS will still be used. At least they will all have the Gige uplinks in a LAG that can gracefully fail over to a single link.
Next the aggregation: this is simple... the upstream Al-Lu equipment that most dslams connect to is ATM based with a pair of relatively slow OC-12 uplinks, and these can feed 48 subtended stingers. This is also being upgraded for the future that has multicast/IGMP and ethernet rather than ATM to support IPTV. The aggregation layer also goes from OC-12/48 to Gige that probably go to a Nortel 8600 edge router, then onto core routers.
**DPI by ellacoya/arbor is now inserted here before or after the BAS. Has slow Gige interfaces considering how much traffic there is, so 10GE upgrades are coming**
Finally, the BAS/SMS servers after which traffic exits onto the 3rd party networks (Gateway Access Service, Teksavvy, etc.). These are servings thousands of clients and aren't exactly crazy fast... Juniper 1410/1440. These will also likely move to E320's which have better throughput, faster interfaces and backplanes and best of all, more redundancy and better failover.
So yes, DPI sucks, especially since the system doesn't apply it only to the clients from congested elements, but to any PPPoE xDSL user. But it is needed to alleviate congestion to a degree, especially until next generation infrastructure is implemented. One could agree with some parts of this if first off we, TekSavvy, weren't on AGAS circuits (Ethernet, which was not part of the disclosure for some reason) and second, if Bell had put a timeline on this. They planned on leaving this in permanently. This wasn't a temporary situation but rather a permanent control mechanism............. Two much different situations.
Edit: Maybe see these discussions to get an appreciation for the situation: »The Bell Disclosure! -- TSI Rocky - TekSavvy Solutions Inc. | |
|   Froggy
@teksavvy.com | The graph is malareky It's all bollocks to me. All the cell loss (packet loss) came as a result of their throttle boxes. If you don't believe this it coincided with their capping subscribers at 30 and 60 gigabytes a month when they previously were unlimited. | |
|   dnoyeB Ferrous Phallus
join:2000-10-09 Southfield, MI
| CRTC's fault If I were to ask for proof and be given something which purports to be proof but is in fact not... I would not ask again. That is what you submitted as proof and thus you have submitted no proof. Case closed. -- dnoyeB "Then said I, Wisdom [is] better than strength: nevertheless the poor man's wisdom [is] despised, and his words are not heard. " Ecclesiastes 9:16
| |
|  |   a333 A hot cup of integrals please
join:2007-06-12 Corona, NY
·Verizon Online DSL
| Re: CRTC's fault ISP's like TekSavvy are paying for their own bandwidth here, so what am I missing? As far as I know, they only purchase the last mile and the GigE's to their own POP's, to backhaul the data. Where's the congestion here? With cable, there IS a point in throttling, as both indie ISP's and cableco subs share the same physical cable loop, and can both equally help deteriorate the traffic flow during peak hrs. But that argument is moot in the telco's case... | |
|  |  |  psydfx
join:2002-12-20 Canada
| Re: CRTC's fault They use their own backbone but share the same BAS, aggregators and DSLAMs as all of Bell's customers and wholesale providers. So congestion on the backbone isn't a valid claim when throttling the wholesalers but the other congestion spots still play a part. -- the opinions expressed herein are my own and do not represent my employer in any way | |
|  DJMASACRE
join:2008-05-27 Nepean, ON
| Average Lay Person ? Not noticeable to the average lay person ?
this issue as a whole, is not even recognized by the average lay person, which makes it even worse ...
but doesn't mean it is right.
trying to pass this and say its valid from their perspective, while believing that it can stand since most people will not understand the data, does not really work when your dealing in computer/internet technology.
There is enough educated/geeks/nerds/IT/real engineers who can see right through this lame disclosure...
Nice try though Bell. Who do you think you are.
you get marketing VP's to talk about things they dont understand... ... .
anyway ... you picked the wrong area to bullshit your way through ... real experts will testify against it.
hopefully. i cant wait. | |
|  daveberstein
join:2002-07-15 New York, NY
| Dave Burstein First Thank you Karl for carefully reporting a story others missed.
The data from Bell Canada is amazing. For years, essentially all commercial DSLAMs - including the Stingers Bell uses - are designed to be non-blocking (not congested.) Significant congestion therefore implies
1) Massive incompetence on the part of Bell Canada engineers. That's highly unlikely, because they have an excellent engineering staff.
2) They underprovisioned the DSLAM backhaul. By 2002 or thereabouts, major carriers including BellSouth and Softbank were routinely provisioning Gig-E's, often four to a CO.
(this is the likely cause, because they have referred to OC 3 155 meg links in some of their filings. The industry norm for years has been 8 times as high in any busy exchange.)
3) They are running wildly obsolete DSLAMs whose capacity their own engineers knew years ago would need replacing by now. This makes sense, because three years ago they spoke publicly of quickly replacing most of their existing DSLAMs with remote terminals closer to the customer (fiber to the node). That would replace most of the connections on the existing DSLAMs, allowing the old gear to handle the (presumably few) customers not switched to the new equipment. Similarly, they wouldn't have upgraded the backhaul links on DSLAMs they intended to most bypass. -----------------
Bell Canada cut their capital spending 25% this quarter. I will now review all their postings to found specifics.
This is treating customers like the Romans treated the Sabine Women.
Dave Burstein, Editor, DSL Prime | |
|  |   Maynard G Krebs
@teksavvy.com
| Re: Dave Burstein said by daveberstein :Bell Canada cut their capital spending 25% this quarter. I will now review all their postings to found specifics. Don't forget to factor in the rationale for this -- the 'window dressing' that Bell management probably demanded in order to make the long-running takeover battle seem that much more appealing to the suitors and reduce the likelihood of the takeover price being re-negotiated downwards - which benefits management and their stock options.
Look for the new owners to further cut capital spending. | |
|  |
|
|