M Ewan
@teksavvy.com
| reply to oh LOOK
Re: Bells NEW July 11th CRTC Submission
My evening internet surfing, file transfers, VPN connection, and the like have all become noticeably slower beginning with Bell's throttle/DPI, and I don't do ANY torrents at all.
The slowness of the connection and lack of responsiveness to even major sites like HP, IBM, and other make me feel like throwing my damn computer out the window. |
|
globus999
join:2008-05-15
| reply to Bellus_x
said by Bellus_x :
What is fair and what seems fair/just/ideal/right isn't necessarily what the CRTC can act on. Here, the question is does Bell treat GAS clients differently than it's own in terms of the throttling. The answer is no. Does the GAS tariff have specific allowances or guarantees of bandwidth? No. Have they broken the laws regarding intercepts and data/computer trespass? Likely not... Bell doesn't act now, think later. It consults inside and outside counsel. Its next generation product won't have an AGAS equivalent... so even if they can offer 30/10 sync speeds with FTTN, they'll only offer whatever portion of that is available for internet for use by GAS/PPPoE service, and even that will be on a best effort basis because of the priority that realtime (IPTV, HSA with QoS and IPVPN) services over GAS/PPPoE which is a best effort service with no guarantees on packet loss or latency in the tariff. (For clarity, I mean that if the max internet pipe on a triple-play Bell client is 7Mbps of the 30Mbps to the house, that is the most GAS will offer. Even that 7Mbps is going to vary, because of the priority IPTV has over internet, just like Telus internet slows down when all the STB's are active.)
Your argument is disgusting, to say the least! Spin, spin, spin. Look it IS easy: What Bell is doing is arbitrarily defeating the capacity to freely compete in a free market. THAT SIMPLE! Bell can't compete therefore Bell reduces the competition to ashes by SCREWING EVERYBODY! THAT, is the definiton of MONOPOLY! Oh... yeah... FYI for your cue cards: ABUSING MONOPOLY BAD, FREE MARKET GOOD!
Wrt "best effort" GIMME A BREAK! More spun BS! So, there are no "guarantees" in the trarifs? Well then WHY IS BELL CONTRACTING A FIXED BANDWIDTH WITH ISP's????? THIS IS BS!!!
Lastly, WHO IN HECK! gave Bell the right to decide that real or near-real time applications have to receive priority???? BELL IS A COMMON CARRIER!!! NOT AN ISP (wrt throtling). BELL SHOULD HAVE NO SAYING WHATSOEVER!!
Spoiled BRAT! That's ALL that Bell is!!! |
|
globus999
join:2008-05-15
| reply to Bellus_x
said by Bellus_x :
Very overdue, but Bell was capex starved during the period around the teleglobe debacle and thereafter, limiting certain much needed projects. These eat up capital later when people actually got their heads out of the sand (or posterior) and realised they needed to happen. They also didn't do much with their Joint Ventures like Certen (Did migration of 160+ billing systems into 1 application, now @ Amdocs) and Emergis (Now @ Telus) which they got rid of instead of fixing and growing.
Oh.... puleeese... cry me a river!
Look, it IS simple. For whatever reason Bell has been and continue to be arrogant. Bell has continualy made BAD decisions and screwed-up. Don't blame other debacles! It was Bell's decision. Funny thing though.... unlike ANY other company, instead of biting the bullet, eating crow, do a mea-culpa and FIX THE DARN PROBLEM! they simply pass the buck to the customer! How friggin nice! NOT!
Bottom line? I have no patience nor sympaty any more!
Bell???
DROP DEAD!!! |
|
Bellus_x
@cia.com
| reply to mr_hexen
I agree... as customer uptake increases, Bell has an obligation both as a service provider and under the laws of the market to respond and increase capacity. But there are limits to how much expansion is possible... the Stinger has a finite expansion capability because it is a remote unit... maximum uplink is 2X Gig-E with a portion of that reserved for management and dedicated services.
That said, like any shared facility, there is no guarantee. Phones, POTS or Cell, can sometimes get a fast busy (network busy) so you can't call. Consumer and business GAS is much the same... no ISP provides enough bandwidth at the edge for each of their clients to max out their connections.
Lastly, no service provider will not expand the capabilities of their network if they have any ambition for growth. Right now, I understand that Bell has 2 priority tracks for xDSL, both of which are roads to IPTV: increase overall carrying capacity both in terms of sync rate and at the aggregation layer + improve reliability of service by implementing redundant links to all DSLAMS, edge aggregation units, etc.
Very overdue, but Bell was capex starved during the period around the teleglobe debacle and thereafter, limiting certain much needed projects. These eat up capital later when people actually got their heads out of the sand (or posterior) and realised they needed to happen. They also didn't do much with their Joint Ventures like Certen (Did migration of 160+ billing systems into 1 application, now @ Amdocs) and Emergis (Now @ Telus) which they got rid of instead of fixing and growing. |
|
sbrook
Premium,Mod
join:2001-12-14
H0H 0H0
 ·Rogers Hi-Speed
Host:
Rogers
Bell Canada
| reply to drjp81
There's truth in both arguments.
It IS an as is best effort service with no service guarantees. It's an "oversold" service with the hope that it's not so oversold to cause major problems.
And Bell, like so many companies today is driven solely improving the bottom line.
These two arguments fight each other because it means if there's no benefit to the bottom line by improving service, then it won't get done, but if no improvements in service happen, the bottom line won't improve. |
|
drjp81
join:2006-01-09
canada
 ·TELUS
·TekSavvy Solutions..
1 edit | reply to Bellux_x
said by Bellux_x :
...Either way, what it boils down to is that 5Mbps is a best effort service with no guarantees...
I sincerely doubt that. Like most major corporations these days it's not: "how can we innovate , improve service or entice the consume into spending more?" It's: "how can we screw them in our vice, so they have no choice but pay upto get the minimum the law will allow?"
So all the techno babble about bell's links and the capacity of their network means diddly squat, in this context.
--
Cheers! |
|
mr_hexen
join:2007-08-02
Brampton, ON
| reply to Bellux_x
said by Bellux_x :
I guess I am too simple in my approach on things. Even if you could saturate your connection with a single inbound tcp connection, it isn't always going to happen. Lots of downloads are slower than my max throughput. Either way, what it boils down to is that 5Mbps is a best effort service with no guarantees. Want to pay less beause you have less than 1Mbps? Move to the basic GAS. What consumer ISP in the area can promise 5Mbps all the time without restrictions? Cogeco shapes and cuts ppl off, rogers also uses DPI, so does Shaw. I was just as pissed as the next person when the retail product was throttled, and more so when my alternative PPPoE service was. But I learned to deal with it, and leave things to download overnight and I know it will be a few hours to download something during peak periods. And now MLPPP and PerVices are viable workarounds. I applaud these people for their ingenuity, and I love that this has lit a fire beneath some inside and outside the ILEC sphere. I do not believe Bell actively sabotages GAS clients with bad pairs or refusing transfers to remotes with free capacity, but I could be wrong. Either way, it is strictly prohibited to treat wholesale clients any differently than the retail clients.
this best effort deal is meant to the provisioning of the aDSL link, not throughput once the link has been provision. Users getting UP TO 5mbps may only get 3mbps, you're right, but shouldn't they expect to be able to use that full 3mbps when and how they please?
said by Bellux_x :
I am also very critical of Bell. It has been poorly managed and things like the Shareholder Value Initiative did nothing for the company and simply starved some really important Capex projects. But it's not like nothing was done... Nationwide DWDM on Nortel CPL (no optical repeaters!, and 40G soon), stingers for which Bell is the only remaining major user, IP/MPLS core, and major migration away from legacy networks and systems (the software that provisions stuff TODAY is only slightly younger than me). But lots of ATM still exists, mostly in the DSLAM/edge/CO/DMS space. And even GigE uplinks to/from stingers won't give users (144 ports per stinger) crazy bandwidth. What's 1GE/144? 6.94Mbps. And if the FS+ control shelf is setup with the latest IP control cards, it only has.... 2 Gig-E links for unicast data traffic to the BRAS. And the FS+ has 14 slots that serve between 3 and 10 Stingers (software limit of 46 stingers per FS+). That is not a whole lot of bandwidth for that many subs. So that is why things suck and DPI is here to stay. This is a gamble providers take. assuming that users will not all be on the service at once and running at full throughput. If they lose that gamble then they should add another Gig-e Link rather then punishing everyone else for their mistakes. |
|
Bellux_x
@cia.com
| reply to TSI Gabe
I guess I am too simple in my approach on things. Even if you could saturate your connection with a single inbound tcp connection, it isn't always going to happen. Lots of downloads are slower than my max throughput. Either way, what it boils down to is that 5Mbps is a best effort service with no guarantees. Want to pay less beause you have less than 1Mbps? Move to the basic GAS. What consumer ISP in the area can promise 5Mbps all the time without restrictions? Cogeco shapes and cuts ppl off, rogers also uses DPI, so does Shaw. I was just as pissed as the next person when the retail product was throttled, and more so when my alternative PPPoE service was. But I learned to deal with it, and leave things to download overnight and I know it will be a few hours to download something during peak periods. And now MLPPP and PerVices are viable workarounds. I applaud these people for their ingenuity, and I love that this has lit a fire beneath some inside and outside the ILEC sphere. I do not believe Bell actively sabotages GAS clients with bad pairs or refusing transfers to remotes with free capacity, but I could be wrong. Either way, it is strictly prohibited to treat wholesale clients any differently than the retail clients.
I am also very critical of Bell. It has been poorly managed and things like the Shareholder Value Initiative did nothing for the company and simply starved some really important Capex projects. But it's not like nothing was done... Nationwide DWDM on Nortel CPL (no optical repeaters!, and 40G soon), stingers for which Bell is the only remaining major user, IP/MPLS core, and major migration away from legacy networks and systems (the software that provisions stuff TODAY is only slightly younger than me). But lots of ATM still exists, mostly in the DSLAM/edge/CO/DMS space. And even GigE uplinks to/from stingers won't give users (144 ports per stinger) crazy bandwidth. What's 1GE/144? 6.94Mbps. And if the FS+ control shelf is setup with the latest IP control cards, it only has.... 2 Gig-E links for unicast data traffic to the BRAS. And the FS+ has 14 slots that serve between 3 and 10 Stingers (software limit of 46 stingers per FS+). That is not a whole lot of bandwidth for that many subs. So that is why things suck and DPI is here to stay.
The only reason video is viable and higher syncs put in place are for multicast IPTV (where the IGMP proxy will reside on the VDSL2 blade in the remote) and to a limited extent (16Mbps ADSL2+ w/ Annex M)for new IP Dedicated, which both get around the uplink BW problem because between 2 and 4 of the Gig-E ports on each of the line cards in the FS+ control shelf are dedicated to Multicast and dedicated IPoXDSL services (NON-BRAS/PPPoE). This gets them around the rather lame 2 Gig-E uplinks in the IP2100 card that as noted earlier is powering an entire FS+ shelf of OLT/OLIM's. |
|
jfmezei
Premium
join:2007-01-03
Beaconsfield, QC
·ELECTRONICBOX
| reply to Bellus_x
Mr/Mrs Bellus_X,
I strongly suggest you read the RFCs for IP and TCP (791 and 793) to learn the very basics about networking before starting to attempt to propagate Bell's fiction/fantasy concepts.
And remember that this is a PPPoE service, not a IP service.
I can understand Bibik having to lie to the CRTC to try to convince them to let Bell do as it wants, but I don't accept that other Bell employees would have to toe those lies.
In fact, considering the purge that Teachers is and will do, I suggest that those who do speak out to show incompetance within bell stand a greater chance of surviving. |
|
TSI Gabe
Premium,VIP
join:2007-01-03
Chatham, ON
| reply to vintagewino
In fact, the more TCP sessions you have, the more overhead. Resulting in less actual throughoutput.
A 5Mbps line cannot send more than 5 million bits per second, no matter what you do.
--
TSI Gabe - TekSavvy Solutions Inc. |
|
vintagewino
join:2003-07-22
Grimsby, ON
·TekSavvy Solutions..
 ·magicjack.com
·Look Communications
1 edit | reply to Bellus_x
said by Bellus_x :
Lastly, on the matter of releasing the data that has been obscured: unlike the previous congestion data, detailed information on network deployments and upgrades cannot be made public for competitive reasons.
Would you please be as kind as to tell us what competition are you talking about in Ontario or Quebec? I certainly have no other choice if I want to use POTS.
The more you try to hide behind shaded data, the weaker your stance. |
|
pnjunction
Teksavvy Premium
Premium
join:2008-01-24
Toronto, ON
·TekSavvy Solutions..
1 edit | reply to Bellus_x
said by Bellus_x :
-People say the the amount of simultaneous sessions has no impact on BW use and/or on load to Bell equipment. YES, IT DOES! In the same way those download acccelerators do, BT and other P2P open more and more connections until their downstream pipe is saturated (ie. not limited by what 1 server can provide), provided there are enough peers. This increases the utilization of every element in the path, DSLAM, uplink, aggregation, BAS/ERX, etc.
Fail. If the server has the capacity to saturate your link you're NOT limited by it. The reason you need to many peers in P2P is because most people have less upload than they do download. Also, people limit their upload to a rate they are comfortable with.
Bell's equipment is (or at least should be) blind to how many connections a Teksavvy user needs to open to get max throughout (edit: the throughput that we pay for, if we can't get it, what's the point?).
5 Mbps is 5 Mbps.
If they have a problem with connections being saturated, just come out and say it, and admit that MANY applications can saturate the connection instead of blaming the ones thay don't like. |
|
Bellus_x
@cia.com
| reply to oh LOOK
Ok, so a few things need to be questioned:
-People say the the amount of simultaneous sessions has no impact on BW use and/or on load to Bell equipment. YES, IT DOES! In the same way those download acccelerators do, BT and other P2P open more and more connections until their downstream pipe is saturated (ie. not limited by what 1 server can provide), provided there are enough peers. This increases the utilization of every element in the path, DSLAM, uplink, aggregation, BAS/ERX, etc.
-"We have no dealings with Bell!/Not a bell client" Well, I guess in a direct way, no, you are not a Bell client. But indirectly, the ISP you buy from, acting on your behalf, acquires a GAS link for you. Someone has contracted to Bell and in that Tariff there are terms and conditions which TSI/ISP accepts and you are therefore subject to.
-"They can't look inside my packets!!/What about my privacy?" Bell says that for its retail clients, is collects the userID info... this makes sense. They currently use Arbor Ellacoya e30's (over 100 of them now in use), which also collect usage information for use in billing sympatico clients. Other provider's clients are not associated with their PPPoE login (I'm guessing here), but rather with a random identifier that knows where you are connecting from (CO/POP) and perhaps for statistical purposes, to which AGAS destination.
What is fair and what seems fair/just/ideal/right isn't necessarily what the CRTC can act on. Here, the question is does Bell treat GAS clients differently than it's own in terms of the throttling. The answer is no. Does the GAS tariff have specific allowances or guarantees of bandwidth? No. Have they broken the laws regarding intercepts and data/computer trespass? Likely not... Bell doesn't act now, think later. It consults inside and outside counsel. Its next generation product won't have an AGAS equivalent... so even if they can offer 30/10 sync speeds with FTTN, they'll only offer whatever portion of that is available for internet for use by GAS/PPPoE service, and even that will be on a best effort basis because of the priority that realtime (IPTV, HSA with QoS and IPVPN) services over GAS/PPPoE which is a best effort service with no guarantees on packet loss or latency in the tariff. (For clarity, I mean that if the max internet pipe on a triple-play Bell client is 7Mbps of the 30Mbps to the house, that is the most GAS will offer. Even that 7Mbps is going to vary, because of the priority IPTV has over internet, just like Telus internet slows down when all the STB's are active.)
Lastly, on the matter of releasing the data that has been obscured: unlike the previous congestion data, detailed information on network deployments and upgrades cannot be made public for competitive reasons. |
|
oh LOOK
@videotron.ca
| reply to Cyborg994
said by Cyborg994  :Too bad we can't build a response in a "wiki" way, that would be really nice and complete I think. Actually thats a VERY good idea.
Whose willing to take it on? |
|
mr_hexen
join:2007-08-02
Brampton, ON | reply to Cyborg994
why couldn't we? |
|
Cyborg994
join:2005-04-18
Montreal, QC | reply to oh LOOK
Too bad we can't build a response in a "wiki" way, that would be really nice and complete I think. |
|
mr_hexen
join:2007-08-02
Brampton, ON
3 edits | reply to oh LOOK
#
ES19. Bell's DPI traffic shaping activity does not "control the content or influence the meaning or purpose of telecommunications" for two key reasons. First, slowing the delivery of content does not amount to "controlling" it. Second, Bell is not involved in any way with the editorial control of content being transmitted through P2P file sharing applications nor is it creating or preventing access to such content. The shaping technique is content and content provider agnostic. Bell cannot influence the meaning or purpose of the telecommunications because Bell has no knowledge of the content itself.
#
Control: To exercise influence over, to suggest or dictate the behavior of. »en.wiktionary.org/wiki/control
Influence: The power to affect, control or manipulate something or someone; the ability to change the development of fluctuating things such as conduct, thoughts or decisions; the status of being able to dictate the actions or behaviors of an object or person; moral or political power over a person or group; ascendancy. »en.wiktionary.org/wiki/influence
Behavior (US Spelling):
1. The way an animal or human behaves or acts.
2. The way a device or system operates.
they are excercising influence over the behaviour of P2P. |
|
jfmezei
Premium
join:2007-01-03
Beaconsfield, QC
·ELECTRONICBOX
| reply to oh LOOK
Article in the Montreal Gazette:
»www.canada.com/montrealgazette/n···90ec85d6
Fairly neutral in tone. But more on our side than Bell's side.
##
Though it can be hard to distill the facts from the back-and-forth claims, Surtees is more inclined to side with the small Internet providers. He calls P2P throttling a "knee-jerk response" that tries to "deflect the blame, as opposed to doing intellectual, sophisticated network management."
## |
|
jfmezei
Premium
join:2007-01-03
Beaconsfield, QC
1 edit | reply to Candoo3
A DIFFERENCES utility on VMS sees no differences between the version posted by P2Pnet and the one posted on the CRTC. |
|
Candoo3
join:2005-01-24 | reply to oh LOOK
Bell's submission finally made it to the CRTC site:
»www.crtc.gc.ca/PartVII/eng/2008/···5153.htm |
|
