Bells NEW July 11th CRTC Submission in TekSavvy

Bells NEW July 11th CRTC Submission in TekSavvy http://www.dslreports.com/forum/r20780127 en Fri, 27 Nov 2009 06:53:53 EDT Fri, 27 Nov 2009 06:53:53 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20803260 anon : 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. ]]> http://www.dslreports.com/forum/remark,20803260 Wed, 16 Jul 2008 22:14:56 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20803202 globus999 :

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!!!]]> http://www.dslreports.com/forum/remark,20803202 Wed, 16 Jul 2008 22:04:10 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20803110 globus999 :

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!!!]]> http://www.dslreports.com/forum/remark,20803110 Wed, 16 Jul 2008 21:49:47 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20802621 anon : 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.]]> http://www.dslreports.com/forum/remark,20802621 Wed, 16 Jul 2008 20:15:35 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20799388 sbrook : 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.]]> http://www.dslreports.com/forum/remark,20799388 Wed, 16 Jul 2008 10:10:28 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20798866 drjp81 :

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!]]> http://www.dslreports.com/forum/remark,20798866 Wed, 16 Jul 2008 07:51:11 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20798862 mr_hexen :

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.]]> http://www.dslreports.com/forum/remark,20798862 Wed, 16 Jul 2008 07:49:26 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20797282 anon : 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.]]> http://www.dslreports.com/forum/remark,20797282 Tue, 15 Jul 2008 21:43:41 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20796780 jfmezei : 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.]]> http://www.dslreports.com/forum/remark,20796780 Tue, 15 Jul 2008 20:05:23 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20796358 TSI Gabe : 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.]]> http://www.dslreports.com/forum/remark,20796358 Tue, 15 Jul 2008 18:53:47 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20796315 vintagewino :

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.]]> http://www.dslreports.com/forum/remark,20796315 Tue, 15 Jul 2008 18:44:18 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20796234 pnjunction :

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.]]> http://www.dslreports.com/forum/remark,20796234 Tue, 15 Jul 2008 18:23:36 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20796173 anon : 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.]]> http://www.dslreports.com/forum/remark,20796173 Tue, 15 Jul 2008 18:11:51 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20795341 anon :

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?]]> http://www.dslreports.com/forum/remark,20795341 Tue, 15 Jul 2008 15:26:27 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20795156 mr_hexen : why couldn't we?]]> http://www.dslreports.com/forum/remark,20795156 Tue, 15 Jul 2008 14:55:24 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20794865 Cyborg994 : Too bad we can't build a response in a "wiki" way, that would be really nice and complete I think.]]> http://www.dslreports.com/forum/remark,20794865 Tue, 15 Jul 2008 13:57:19 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20794723 mr_hexen : #
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.]]> http://www.dslreports.com/forum/remark,20794723 Tue, 15 Jul 2008 13:31:16 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20794349 jfmezei : 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."
##]]> http://www.dslreports.com/forum/remark,20794349 Tue, 15 Jul 2008 12:08:10 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20792740 jfmezei : A DIFFERENCES utility on VMS sees no differences between the version posted by P2Pnet and the one posted on the CRTC.]]> http://www.dslreports.com/forum/remark,20792740 Tue, 15 Jul 2008 01:24:32 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20792605 Candoo3 : Bell's submission finally made it to the CRTC site:
»www.crtc.gc.ca/PartVII/eng/2008/···5153.htm]]> http://www.dslreports.com/forum/remark,20792605 Tue, 15 Jul 2008 00:46:05 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20791796 ultracat :

said by The Flash

:

JF for MVM, that's what I say.

»Site FAQ »The BBR MVM Tag

Seems only a moderator can nominate him, not any of us regular users. So, who's a moderator? C'mon, someone who's a moderator ought to be reading these incredibly important threads. JF deserves it without a doubt. This throttling issue is of historic importance for Canadian broadband policy and here's JF, the little guy, arguably pumping out more and better analysis than just about anyone on here (with no offense to the many other excellent contributors here).]]> http://www.dslreports.com/forum/remark,20791796 Mon, 14 Jul 2008 21:23:32 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20791404 sbrook : From jf's posts ...

quote:
##
First, slowing the delivery of content does not amount to "controlling" it.
##

Deciding whether a packet should be transmitted to destination or discartded based on what application it is associated with is defrinitely controlling it.

ANALOGY: Bell is dictating what subjects one can discuss on a telephone conversation. Implementing it requires Bell listen to phone conversations to ensure we only speak of subjects Bell has approved.

Let me fix this Analogy ...

ANALOGY: Bell is dictating what languages one can use in a telephone conversation. Implementing it requires Bell listen to phone conversations to ensure we only speak English or French.

Reasoning ... you can discuss what you like, but you just can't do it in P2P. You can transfer movies using the raw language, but you can't do it using the P2P language.

-----

quote:
Rogers has proxy servers used to insert content in HTTP transactions, and those servers would be aware of TCP connections since they need to fake connectivity so that the inserted packets can appear to be "native" to the data stream.

As I understand it this is done with the Cisco pCube service engines. Note that CISCO actually calls them "Service Engines" and not "Network Management Engines"!]]> http://www.dslreports.com/forum/remark,20791404 Mon, 14 Jul 2008 20:07:17 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20791316 anon :

said by jfmezei

:

Thanks for the Kudos folks.
What is interesting is that the Bell submission did not get added to the CRTC web site on monday at noon. Wouldn't it be funny if the CAIP submission were to become public before the Bell submission makes it to the CRTC site ?

Perhaps the delayed submission was a ploy to imply that they delay all data equally, or maybe they torrented it on their own network...

Anyway, the timer for the deadline on CAIP's response should not have started until Bell's submission was posted on the CRTC site and was thereby officially 'available' to CAIP plus a 24-hour extension, n'est ce pas? ;-)]]> http://www.dslreports.com/forum/remark,20791316 Mon, 14 Jul 2008 19:53:31 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20791138 jfmezei : Thanks for the Kudos folks.

Interested parties have no more opportunities to send letters to the CRTC on this matter. All we can do is talk to the media and politicians to help prevent the CRTC from siding with Bell.

Rocky has received a copy of my parsing of Bell's 86 page fiction/fantasy (and additional comments not posted here). Whether they use any of it or not, it is up to them.

What is interesting is that the Bell submission did not get added to the CRTC web site on monday at noon. Wouldn't it be funny if the CAIP submission were to become public before the Bell submission makes it to the CRTC site ?]]> http://www.dslreports.com/forum/remark,20791138 Mon, 14 Jul 2008 19:17:36 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20790431 Vomio :

said by The Flash

:

JF for MVM, that's what I say.

I have to agree, worthy contributions to the forum and the the cause in general.

I tip my tin foil lined, solar powered, propeller beanie in his direction.

Vomio]]> http://www.dslreports.com/forum/remark,20790431 Mon, 14 Jul 2008 16:54:25 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20790260 The Flash : JF for MVM, that's what I say.

»Site FAQ »The BBR MVM Tag]]> http://www.dslreports.com/forum/remark,20790260 Mon, 14 Jul 2008 16:15:45 EDT Re: Food for thought.... http://www.dslreports.com/forum/remark,20790230 anon :

said by tertech

:

I just hope that after all of JF's excellent work debunking Bell's submission, that someone at the CRTC actually gets to read it.

Do you think they look at web sites like DSLReports and p2pnet?

I agree 100%. To me (as a networking technology lay-person), Jean-François's work appears impressive and authoritative. It seems to cut through the b.s. (cough, beaver stuff) obfuscation layer like a hot knife through butter. I found myself mentally pumping my fist in the air and shouting "oh yeah" like a demented Toronto jeweler (you have to have access Toronto area TV commercials to get that one) each time he landed a blow and knocked them back.

I would imagine that CAIP is using these magnificent rebuttal points to help formulate their own response, and also that JF can file one more submission.

If, thanks in part to JF's learned distillation of the issues, good ultimately triumphs over beaver and CAIP does prevail, I think that JF would be due a reward of some sort (perhaps gratis beaver-free Internet for life?).]]> http://www.dslreports.com/forum/remark,20790230 Mon, 14 Jul 2008 16:10:19 EDT Re: Food for thought.... http://www.dslreports.com/forum/remark,20789952 tertech : I just hope that after all of JF's excellent work debunking Bell's submission, that someone at the CRTC actually gets to read it.

Do you think they look at web sites like DSLReports and p2pnet?]]> http://www.dslreports.com/forum/remark,20789952 Mon, 14 Jul 2008 15:16:30 EDT Re: Food for thought.... http://www.dslreports.com/forum/remark,20789199 anon : haha JF is quoted on P2Pnet, »www.p2pnet.net/story/16376

“I went through Bell’s fantastic work of fiction yesterday and commented on it,” Mezei says, pointing to his post on dslreports...."

haha way 2 go JF!]]> http://www.dslreports.com/forum/remark,20789199 Mon, 14 Jul 2008 13:00:49 EDT Re: Food for thought.... http://www.dslreports.com/forum/remark,20788621 anon :

said by Maynard G Krebs :

Somebody at Bell should be charged if only to force the production of all corporate e-mail, memorandum, etc... to show that Bell knows that it is unlawfully accessing/reading user data inside the PPPoE envelope.

I don't see that happening any time soon. One could dream though.]]> http://www.dslreports.com/forum/remark,20788621 Mon, 14 Jul 2008 11:05:21 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20788620 mr_hexen :

said by jfmezei

:

With regards to the deadline. It appearts the Bell drone spoke to the CRTC on the day before the original deadline. It is quite possible that the CRTC agreed.

this is exactly what happened, see the note on the the CRTC's website.

As per my conversation with you earlier today, Bell Canada (or the Company) wishes to inform the Commission that it is unfortunately unable to file its answer in relation to CAIP's application on 10 July 2008 . The Company will file its answer by Friday, 11 July 2008

essentially they called them up and asked for another day, behind everyone's back.]]> http://www.dslreports.com/forum/remark,20788620 Mon, 14 Jul 2008 11:05:17 EDT Food for thought.... http://www.dslreports.com/forum/remark,20788517 anon : Somebody at Bell should be charged if only to force the production of all corporate e-mail, memorandum, etc... to show that Bell knows that it is unlawfully accessing/reading user data inside the PPPoE envelope.

Criminal Code of Canada

Interception of Communications

Interception

184. (1) Every one who, by means of any electro-magnetic, acoustic, mechanical or other device, wilfully intercepts a private communication is guilty of an indictable offence and liable to imprisonment for a term not exceeding five years.

Saving provision
(2) Subsection (1) does not apply to

(a) a person who has the consent to intercept, express or implied, of the originator of the private communication or of the person intended by the originator thereof to receive it; [ I didn't give Bell permission to intercept and look inside my PPPoe packets - did you? ]

c) a person engaged in providing a telephone, telegraph or other communication service to the public who intercepts a private communication,

(i) if the interception is necessary for the purpose of providing the service, [ Provide a pipe, transport data, no need to look at the payload. ]

(ii) in the course of service observing or random monitoring necessary for the purpose of mechanical or service quality control checks, [ DPI/throttling is not necessary to fulfill the allowable purposes in sub-section (c). ]
or

(iii) if the interception is necessary to protect the person’s rights or property directly related to providing the service; [ DPI/throttling is not necessary to fulfill the allowable purposes in sub-section (c). ]

(e) a person, or any person acting on their behalf, in possession or control of a computer system, as defined in subsection 342.1(2), who intercepts a private communication originating from, directed to or transmitting through that computer system, if the interception is reasonably necessary for

(i) managing the quality of service of the computer system as it relates to performance factors such as the responsiveness and capacity of the system as well as the integrity and availability of the system and data, .... [ Delving into PPPoe payload is not necessary to fulfill this otherwise legal purpose. ]

184. (2) and (3) discusses the legal requirements for interception, ie. satisfying a judge with evidence before interception is made. Clearly not done by Bell.

--------------------------

430. (1) Every one commits mischief who wilfully

(a) destroys or damages property;

(b) renders property dangerous, useless, inoperative or ineffective;

(c) obstructs, interrupts or interferes with the lawful use, enjoyment or operation of property; or

(d) obstructs, interrupts or interferes with any person in the lawful use, enjoyment or operation of property.

Mischief in relation to data
(1.1) Every one commits mischief who wilfully

(a) destroys or alters data;

(b) renders data meaningless, useless or ineffective;

(c) obstructs, interrupts or interferes with the lawful use of data; or

(d) obstructs, interrupts or interferes with any person in the lawful use of data or denies access to data to any person who is entitled to access thereto.

Punishment
(2) Every one who commits mischief that causes actual danger to life is guilty of an indictable offence and liable to imprisonment for life.

Punishment
(3) Every one who commits mischief in relation to property that is a testamentary instrument or the value of which exceeds five thousand dollars

(a) is guilty of an indictable offence and liable to imprisonment for a term not exceeding ten years; or

(b) is guilty of an offence punishable on summary conviction.]]> http://www.dslreports.com/forum/remark,20788517 Mon, 14 Jul 2008 10:43:26 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20788102 tertech :

said by jat

:

Although you can't deny that it was pretty underhanded of Bell to do this behind everyone's back, no matter what the reason for the request was.

And your point is what ? :uhh:

Bell doing something underhanded behind everyone's back? I'm shocked!]]> http://www.dslreports.com/forum/remark,20788102 Mon, 14 Jul 2008 09:15:53 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20788004 jat : I agree that it would've been fair to give Bell a one day extension. I just think it's unfair that, presuming the request was accepted, it was a back door deal done with someone at the CRTC, and not done in public with CAIP's approval.

If the CRTC never approved of the extension, then Bell would have no right to argue the CRTC decision if they ignored the document. I mean, would CAIP be able to argue they weren't heard out if they filed their submission a month after the deadline? How many days late does a submission have to be before the CRTC can ignore it? I would've guessed zero.

In any case, regardless of the contents of the document, I don't really think CAIP should ask the CRTC to reject the submission. That would just be stooping to Bell's level. I was only pointing it out as an option.

Although you can't deny that it was pretty underhanded of Bell to do this behind everyone's back, no matter what the reason for the request was.]]> http://www.dslreports.com/forum/remark,20788004 Mon, 14 Jul 2008 08:48:03 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20785933 davidbrown : They already had it done they just wanted to avoid the press.

Up tell now nothing anyone has done was going to change the crtc bending over and taking it like always.

With the giant Google stepping into the ring though things may have changed since the one thing the crtc and bell don't want is press.

Google has the knowledge and massive press power to make the crtc look like total idiots.
It would be child's play for them to explain what bell is doing in a way everyone understands and to get it out to everyone.]]> http://www.dslreports.com/forum/remark,20785933 Sun, 13 Jul 2008 19:40:44 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20784915 jfmezei : With regards to the deadline. It appearts the Bell drone spoke to the CRTC on the day before the original deadline. It is quite possible that the CRTC agreed.

It is also quite possible that the document was actually filed on the 10th on time, but they faked having it done on the 11th so that they would skip the friday news cycle.

Either way, I think thatthe dealy is inconsequential. If the CRTC were to refuse the document, Bell could *always* argue that the CRTC's decision against Bell wass unfair and did not take into account Bell's only arguments on the matter.

Remember that 1st submission was solely for the injunction. Second submission was solely to answer specific questions from the CRTC. This is Bell's only "free form" answer where they could deal with any/all subjects.

Arguing on whether Bell's submission should be accepted or not is a waste of time. ]]> http://www.dslreports.com/forum/remark,20784915 Sun, 13 Jul 2008 15:16:13 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20784816 anon : I'd just like to post a snippet from my own submission, as I feel that it is quite significant:
---------------
Bell Quote: “The closest identifier to an individual subscriber that the DPI currently does maintain and store is a "subscriber id" which is actually Bell Canada's user ID assigned by network authentication in order to bind a user ID to an assigned IP address. “

Response: What does this mean for 3rd party DSL customers? My Teksavvy login ID (self-selected) is quite personally identifiable. Other ISPs may very well assign logins by firstname.lastname or firstinitial.lastname.
---------------

Perhaps the CAIP would like to address this in one of their own submissions, or are they only allowed to respond to Bell's latest interrogatory?]]> http://www.dslreports.com/forum/remark,20784816 Sun, 13 Jul 2008 14:51:50 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20784491 drjp81 : JF's gotta be a kickass analyst for some big firm. If not, should be.

Nice work bro.
--
Cheers!]]> http://www.dslreports.com/forum/remark,20784491 Sun, 13 Jul 2008 13:18:57 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20784246 ultracat :

said by jat

:

Who said the CRTC accepted Bell's request for a extension? I haven't seen them make any statements about it, and you can't say they implicitly accepted it as the submission still hasn't appeared on the CRTC website.

Just because Bell sent p2pnet and, presumably, the CRTC a copy of the document doesn't mean the submission will be accepted. For all we know, the CRTC will ignore it completely as it was submitted after the deadline.

Considering how juicy this document is, it may not be a wise idea, but CAIP could always ask the CRTC to refuse the submission because it was not filed on time according to the rules the CRTC set out.

Oh they should ABSOLUTELY do that. Bell's submission was a day late, isn't that correct. This is the legal world we're talking about people. CAIP's lawyers should be ALL OVER that. Bell failed to respect the CRTC's deadline. The submission should be rejected, plain and simple. It's like saying "objection" in a courtroom and having that testimony "thrown out". Legal games, but Bell's been playing them (can anyone say "unnecessary redaction"?) so CAIP should most definitely. Otherwise you have 1 party playing fair and the other playing unfair, and that's well, just plain unfair ; )]]> http://www.dslreports.com/forum/remark,20784246 Sun, 13 Jul 2008 12:08:05 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20784179 vintagewino :

said by jat

:

Who said the CRTC accepted Bell's request for a extension? ... Considering how juicy this document is, it may not be a wise idea, but CAIP could always ask the CRTC to refuse the submission because it was not filed on time according to the rules the CRTC set out.

Before getting bent out of shape, let's ascertain the delivery date and time of this document. BEFORE or AFTER the deadline? Was there an extension granted? If there was, why?

In the business I'm in, if a customer makes an RFP or RFQ to a group of vendors, a common deadline is automatically given. NO EXTENSIONS TO ANYBODY. If the requested document does not make it before the deadline, it is automatically disqualified and makes the short list directly into the garbage can without even being opened, and that particular vendor is automatically disqualified from any future negotiations; favouritism notwithstanding.

Since the CTRC stated a time deadline, they would be very wise to stick to the aforementioned deadline. Late = never sent. Otherwise, it sets a dangerous precedent in future procedures they will not be able to backtrack from.

Agreed, this is a very juicy document, the contents which should be followed up in Parliament, by the Privacy Commissioner, and criminal lawyers.]]> http://www.dslreports.com/forum/remark,20784179 Sun, 13 Jul 2008 11:46:28 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20784140 Black Moon : JF, you're superb. I take it you save your posts for your next reply to the CRTC?

I see that you are constantly repeating yourself and it appears to be necessary because Bell is trying to fool us and you constantly bring them back to the GAS/PPPoE aspect.

Well done!]]> http://www.dslreports.com/forum/remark,20784140 Sun, 13 Jul 2008 11:35:04 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20784057 jat : Who said the CRTC accepted Bell's request for an extension? I haven't seen them make any statements about it, and you can't say they implicitly accepted it as the submission still hasn't appeared on the CRTC website.

Just because Bell sent p2pnet and, presumably, the CRTC a copy of the document doesn't mean the submission will be accepted. For all we know, the CRTC will ignore it completely as it was submitted after the deadline.

Considering how juicy this document is, it may not be a wise idea, but CAIP could always ask the CRTC to refuse the submission because it was not filed on time according to the rules the CRTC set out.]]> http://www.dslreports.com/forum/remark,20784057 Sun, 13 Jul 2008 11:09:45 EDT Bell's game plan in this http://www.dslreports.com/forum/remark,20784001 anon : I'll have to hunt for it, but I think it was in Bell's last annual report where they stated that they wanted to move towards 'usage based pricing' for internet service.

First, they throttle their own customers - to establish a new 'base' service level.

Second, they throttle GAS customers - to establish a new base service level.

Third, they begin to 'offer' faster, more responsive internet service to Sympatico customers for a higher fee by using their Ellacoya boxes to selectively not interfere (or interfere less) to those who have paid extra money to Bell.

Fourth, they continue to throttle GAS (if the CRTC lets them), thereby making CAIP member internet speeds pathetic compared to the 'new' Sympatico service. Or they apply to the CRTC for MUCH higher charges on GAS to force CAIP customer costs to rise. Or both these things.]]> http://www.dslreports.com/forum/remark,20784001 Sun, 13 Jul 2008 10:53:58 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783829 Capharnaum : I tried P2P the other day and it slowed down everything on my connection. HTML pages were taking minutes to load up. Did the CRTC state anything about Bell's throttling affecting other protocols because their DPI boxes start dropping packages for everything sent from the "detected IP"?]]> http://www.dslreports.com/forum/remark,20783829 Sun, 13 Jul 2008 09:53:16 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783787 fourboxers : • CAIP may file with the Commission, serving a copy on Bell Canada , a reply by 17 July 2008.

Is the original date not taking into account Bells time extension.]]> http://www.dslreports.com/forum/remark,20783787 Sun, 13 Jul 2008 09:33:32 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783720 anon : When does CAIP have to reply to this?

Also, CAIP should file now for an extention of one day like bell did.]]> http://www.dslreports.com/forum/remark,20783720 Sun, 13 Jul 2008 09:02:21 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783435 Angelo_ : P4P improves average completion time by 23%. Most of P4P clients (in Verizon network) complete downloading the data from the other clients in Verizon network. However, none of Native clients (in Verizon network) complete downloading the data only from others in Verizon.

from »www.openp4p.net/front/fieldtests

this does not solve the "very real bandwidth issues" Bell Canada claims as they are just replacing external routing traffic with internal routing traffic. One can also argue this will cause increase load on the so called taxed nodes as being claimed by Bell Canada.

more to come...

]]> http://www.dslreports.com/forum/remark,20783435 Sun, 13 Jul 2008 04:29:17 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783426 Angelo_ : edit]]> http://www.dslreports.com/forum/remark,20783426 Sun, 13 Jul 2008 04:16:57 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783421 Angelo_ : also to be noticed i also seen that bell loosely states their own privacy policy on sympatico... this is very unclear whena user is a continued offender... (is taht magic number 30gb a month+???)

they seem to hint 3rd party wholesalers are also under bells policies... (which is not actually the case).

This hints that they continue to think wholesalers still as resellers.

and of course more to come :)]]> http://www.dslreports.com/forum/remark,20783421 Sun, 13 Jul 2008 04:13:09 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783412 Angelo_ : alot of bells answers seemed to leave you scratching your head as it didn't seem to come from the right people in the "know".

hopefully the CRTC calls Bell on this BS. it's a spin of what they orginally stated... prob rev 200 knowing bell =p. I love their cell phone quotes, as i was telling JF i bet bell thinks bell mobility is ip based since they can compare mb for mb... =p.

That also should be a easy win for CAIP as it is easily proven not the case.

DS3 was mentioned, i raise the question in todays bandwidth demands.... why is bell still purchasing ds3 links which are now very out dated and insuffiencient. It is like purchasing 14.4k dial up while trying to load a flash web page. For those of you who don't know what flash it. Web pages made up of flash content is usally 5mb+ so on 14.4k it would take you many hours to view a single page.

In this example a DSL connection would be ideal like that offered by Bell Canada prior to the throttling. I say prior because at this point Bell has never stated their plans for throttling and where their policies actually start and end.

Throughout this document they have proven the dpi boxes where orginally installed to ONLY MONITOR BANDWIDTH USAGE. but with user acceptance they are now also used to THROTTLE USERS. If this trend was to continue it is most likely Bell Canada will introduce more restrictive and privacy invassive measures in the future, when it please, and as it please with total disregard to laws of Canada and taht of the world respectively.

Bell Canada should not be allowed to argue fowl with DPI installations compared to other ISPS since every country has a different measure of calculations of bandwidth and laws which protect users for monopolic actions taken from Bell Canada.

more to come soon]]> http://www.dslreports.com/forum/remark,20783412 Sun, 13 Jul 2008 04:01:23 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783258 Candoo3 : Wasn't there something mentioned in another article (non-CRTC), that Bell already got their knuckles rapped, for installing out-dated equipment, as an upgrade?]]> http://www.dslreports.com/forum/remark,20783258 Sun, 13 Jul 2008 01:57:47 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783215 Angelo_ : i found this quote odd from bell

the Company is required to invest in legacy technology to support the ATM network.

considering the atm "upgrades" would be free since the old atm nodes (which are "fibre loosely quoted") those atm links are no longer needed. Or does Bell plan to buy the ATM equipment from themselves?]]> http://www.dslreports.com/forum/remark,20783215 Sun, 13 Jul 2008 01:41:44 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20783054 Candoo3 :

said by Vomio

:

Good work once again JF.
Your eyeballs must be dried out from looking at the monitor so its time to step away from the console and get yourself a drink.

Definitely .. but he's on a roll !! ;)

JF Formulating Bell Rebuttal

]]> http://www.dslreports.com/forum/remark,20783054 Sun, 13 Jul 2008 00:36:31 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782893 Vomio : Good work once again JF.
Your eyeballs must be dried out from looking at the monitor so its time to step away from the console and get yourself a drink.

Cheers,

Vomio

]]> http://www.dslreports.com/forum/remark,20782893 Sat, 12 Jul 2008 23:50:45 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782857 jfmezei : continuation from previous email, statying at about paragraph 124

paragraph 125: 125. Very surprisingly, in response to the interrogatory, CAIP has relied solely on anecdotal evidence without any reference to hard evidence

This is significant. The nature of a PPPoE service meanst that there is no expectation of any manipulation of the packets while in transit through a Point to Point Link. Regular IP based tools are therefore not applicable nor usable because this is not an IP link.

It is therefore next to impossible whithout resorting to sphisticated network tracing tools AND with full understanding of how Bell's DPI equipment works (which we can only deduce since Bell won't release details) to analyse this situation.

And because Bell cripples packets after they have left the ISP, the ISP cannot analyse the problems from its end.

----------

Paragraph 126 : A serious test program would include placing test equipment at the end-user's premises.

Does SYMPATICO ever do that to retail customers ????????

Paragraphs 135 (legal issues):

It is one thing to have temporary network congestion a few minutes a day, but another to see certain types of customer data discriminated and crippled 9.5 hours of EVERY DAY OF THE YEAR.

136: The reasons for giving Cable that ability and not ADSL is that Cable has a shared liast mile and the CRTC ruling was focused on teh alst mile aspect. So it doesn't apply to Bell's underprovisioned aggregation network.

-------------------------
Appendix 2 – Internet Use Policies

1. Rules While using the Service, you may not … or otherwise use the Service in a manner which is contrary to law or would serve to restrict or inhibit any other user from using or enjoying the Service or the Internet;

Since GAS/5410 is not an internet service, this should be rules inapplicable.

And of the problems is caused by Bell undprovisioning links while ISPs are paying in full for a service that exceeds Bell's capacity, then Bell Canada is knoingly selling a service which it knows it cannot provide and this would be considered theft.

Bell uses "fair and proportionate". Unless Bell
Bell defines this, independant ISPs cannot know how to "police" Bell's undefined policies. When an ISP buys X amount of bandwith to serve its customers, it expects that usiong up to X would be considered fair and proportionate.

re: paragraph 140: I wasted much time on this stupid thing. Some unemployed guy kept calling a governmen'ts 800 number. The GOVERNMENT (novascotia) asked Bell if it was possible to prevent this guy from calling them constantly BECAUSE HE WAS COSTING THE GOVERNMENT MONEY (not because he was blocking service).

paragraph 141: again, this is because Cable companies have assigned very very little bandwidth for upstream, so it becomes very to get the uplink for a whole neighbourhood congested with a single person doing a long of uploading. Servers tend to move a lot of data upstream, which is why CRTC agreed that ISps uising Cable would have to have a "no servers" policy to please the cable operator.

paragraphs 143: crippling EVERYONE's internet is far worse than finding the couple of abusers. And unless Bell defines exactly what is "fair" use, ISPs cannot be expected to find out who the abusers are.

Paragraph 146:

Item A- Bell's action are akin to only allowing a person to speak one work per minute on a voice converstiona. This doesn't technically prevent the person from using the phone, but cripples the service to a point where it is useless.

Item B- Since Bell gives itself the freedom to change its configs and not tell anyone, it becomes very very difficult for ISPs to find out exactly what changes from day to day. The fact that there is a lot fo confision already on what exactly is throttled and what isn't throttled will only get worse and Bell "fine tunes" its DPI equipment and start to implement additional policies.

re: discrimination: It isn't a discrimination between ISPs and Sympatic, it discriminates based on what private data is being exchanged by end users.

Order 2000-789 that:

There is a VERY important distinction between cable and ADSL servce providers.

ADSL uses PPPOE to transparently carry whatever packets between the end user and his service provider.

CABLE provides IP connectivity, and DHCP services ( the cable company is the one that gives the end user an IP address, from a pool that the independnat IS has given). As a result, the traffic sent by the end user to his ISP is treated as an IP packet and managed as such while in transit through the cable company's network on its way to the independant ISP.

A reminder here that ADSL consists of a dedicated line for the last mine, and purchased bandwidth to carry PPPoE packets to the ISP. If the ISP buys sufficient bandwidth, there is no excuse for Bell not providing it. 1-It will not affect other usres if Bell has a aggregation/backbone that has been upgraded to suppport the amount of bandwitdh pourchased by the independnt providers.

Paragrah 168 (bottleneck):

The healthy competition exists because until now, a large numebr of service providers were fully able to define their won service and buy bandwitdh from bell without Bell trying to manage their service. However, without the GAS infrastructure, the competition would be non-existant with a duopoly of cable and Sympatico.

Maintaining the ability of of servoice providers to fully define their service and buy and get the bandwdith necessarty for delivery of the service is essential for a competitive environment.

Bell's DPI prevents this. Bell's refusal to make public its exact filters for its DPI equipment also prevent independant providers from defining what service they are offering today or tomorrow.

ISPs that were advertising themselves as "we do not throttle" are now at risk of being accused of false advertising because Bell has unilaterally decided to impose service management policies on competitors to Sympatico.

ALSO: in the earlier CRTC decisions that did conclude there was competition, the competition came from the dial-up services. Those services are no longer competitive because they are too slow to access modern media-rich internet.

Ok, paragraphs 176 (the need to notify).

What Bell is doing is not network management, they are doing service or application management and they are defining services which the independnat ISPs can and cannot provide and thus can or cannot advertise.

While it is true that ISPs need not change equipment or update their software because the interface between Bell and ISPs remains the same, the service itself has been changed and ISPs have lost the freedom to define their own service because Bell Canada has decided to drop a large number of packets associated with certain applictaion signatures contained in the data.

GENERAL:

Bell claims the DPI equipment does not store data. This is technically correct. IT SENDS IT TO THE CENTRAL MANAGEMENT CONSOLE WHERE IT IS STORED.

paragraphs 194: The IP addresses are part of data poayload which is private on the Bell network because Bell's envelope stops at the PPPoE header.

paragraph 197: looking for user data would take exactly the same amount of resources since the "application header" that Bell talks about is user data.

paragraph 199: CAIP must ask the CRTC to consider the implication of application based accounting on independant service providers who buy a point to point transparent link. There are serious privacy implicatiosn of Bell canada spying on its competitors usage patterns.

If Bell Canada was unwilling to divulge Sympatico customers average bandwidth usage numbers, why should Bell canada have access to the equivelent information of its competitors broken down to different applications used by individuals ?

200. For the purpose of understanding aggregate trends in Internet usage, the DPI is capable of sampling HTTP packets for URLs. The DPI then logs and counts the "hits" in order to generate a read-only "top URL" report which shows the most popular URLs by access for all of the HTTP traffic in aggregate, but never for a single session, individual user or specific group of users.

The Ellacoya docs say otherwise. It can be done on a per user basis. And again, sampling URLs in HTTP transaction implicitely and explicitely requires looking into the payload of a packet.

Furthermore, and more importantly, the HTTP request contains extremely private information contained in the transaction such as username, passwords etc.

The use of DPI on a network requires all customers use HTTPS (encripted HTTP) transactions ONLY.

Furthermore, What gives Bell Canada the right to spy on comeptitor's HTTP transactions to compile statistics or do whatever Bell really intends to do ?

If Sympatico wants to see main usage patterns it can log IP addresses of transactiosn destined to port 80 and make statistics of what web sites are being visited. DPI goes much deeper by going down to provcate data in a URL.

201. However, under certain circumstances, such as legal intercept of traffic pursuant to a court order or for network testing diagnostics, the DPI may be configured to copy specific application or user traffic to an "auxiliary" interface where an external capture device can be connected.

This contradicts an earlier statementr that these boxes have no ability to copy user data. (I think it was in my first message).

##
Furthermore, many free software-based tools, such as WireShark, are available to capture network data.
##

Wireshark can be used by the end user to debug his own network, or by the ISP to debug their network, The iSP has a relationship with the end user and if capturing specific user information, the ISP can contact the end user for permission (usually the reverse happens with end user calling ISP to help debug a problem).

In the case of Bell Canada, there is no relationship between end user and Bell cannot obtain permission to examine one's private bits. Firthermore, because the user's IP address belongs to the ISP and not to Bell, law enforcement would be contacting the ISP should there need to be a wiretap on the line.

203: GAS/AHSSPI does not connect users to the Internet. It connects them via PPPoE to their ISP.

##
Therefore, the DPI can identify either the IP address of a sender or a receiver when they are on the Bell Canada access network, but not when they are on the Internet.
##

Bell Canada has no business looking beyond the PPPoE header in a PPPoE service. And the IP addreses do not change while in trasit thorugh the GAS service because GAS service is a PPPoE service and Bell is not allowed to look at the PPPoE packet contents.

paragraph 204: This is definitely an example of service management. Bell Canada has no right to impose such service management on its competitors.

papagraphs 205: gobledeegook. Of note is the ellacoya document that clearly states that the DPI box is fully capable of implementing user-specific filters by querying a RADIUS authentication server.
Thsi contradicst what Bell probably was trying to say.

paragraph 206: Bell Canada does not assign IP addresses to customers of ISPs. But it does need to look at the initial authentification packet to determine to which ISP this users wishes to connect. So Bell does have the userid and ISP name of each user available to it.

paragraph 207: the userid captured by Bell contains a user/id and ISP name (for instance john_doe@teksavvy.com ) It is not specific to a specific phone line, but Bell can obtain that information because the BAS must be able to send packets to the specific DSLAM port associated to a specific phone line.

paragraphs 208: Since Bell Canada argues that it need not tell anyone of changes it makes, Bell promises of what it does not currently doe are totally meaningless and without any trust.

paragraph 211: There is no such thing as "application header". It is part of usert data. In fact in the context of PPPoE , the IP and TCP headers are part of the payload and Bell Canada has no business knowong what IP addresses users have and to what IP address they are connecting.

Secondly, even if Bell Canada does not look for "names, birth days or other personally identifiable information it does not grant it any more the right to look and discriminate based on the data than it has the right to listen to telephone conversations where correspondants do not exchange any names/birthdates.

paragraph 212: Bell Canada has repeatedly confirmed that it does access the IP address in this very document.

Paragraph 213: this is CRITICAL.
##
Thus the headers of the application are part of the IP payload just as the IP header forms part of the TCP/UDP payload. Therefore, looking beyond the PPPoE header to headers of other layers does not equate to looking at the end-user data or content
##

This MUST be destroyed. The payload of the PPPOE packet is private and sacred. Bell has no business looking into it. period. This has to be a inviolable principle in telecom.

##
Furthermore, the GAS Tariff states that GAS supports PPPoE across the Company's backbone network. The word "supports" in no way means that Bell will limit its network management at the PPPoE level.
##

If Bell can go beyond PPPoE header on this service, does this mean that it can start to manage links used by Banks by going beyond the protocol header for that service and looking into the payload for other headers including looking for application data ?

217:The shaping technique is content and content provider agnostic.

Ask BitTorrent Corp or Vuze if they feel it is provider agnostic. Bell has repeatedly stated that it has decided that certain types of large files need to be slowed down. This means that transfering many small files using HTTP protocol is not treated the same as stransfering one large file of equal size as the combination of all the small files using a different protcool.

##
As a common carrier, Bell does not look at the content of P2P file sharing packets.
##

YES IT DOES ! At least Bell admits it is a common carrier.

223: For GAS/5410, Bell Canada acts as a common carrier, not an internet service provider, so the debate on whether to regulate ISPs does not apply here. However, the CRTC must not let a common carrier unilaterally regulate competiting ISPs. market forces lose strength if you allow a monipoly such as Bell Canada to limit/discate service features of independnat service providers.

231:
As the Commission has stated: "a carrier should be free to implement the standards and specifications of its choice within its network. To require otherwise could be costly and inefficient to some carriers, while possibly decreasing opportunities for product differentiation."

Interesting closing statement because Bell's imposition of service features on all ISPs is in fact reducing the ability for product differentiation.

Yippeee ! I've gone through 86 pages of Bell Lies. ]]> http://www.dslreports.com/forum/remark,20782857 Sat, 12 Jul 2008 23:42:00 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782845 Vomio : I like Bell's graphs and traffic projections. ;-)

It would be interesting to see them taken back to 199x or whenever Bell started the HighSpeed offering and then look at the curve in that context.

The other thing that strikes me is if they are blocking p2p now on a relatively flat portion of the graph and assuming the projections are accurate, what the (expletive deleted) are they going to block when the (expletive deleted) hits the fan and the graph goes vertical in four years time.

To reach this projected rate I think the Teachers are going to have to quickly drag fibre to the porch or get the (expletive deleted) out of the business and let someone else provide the connectivity required to keep Canada relevant in this century. The connected world won't wait for us.

Vomio]]> http://www.dslreports.com/forum/remark,20782845 Sat, 12 Jul 2008 23:38:53 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782600 jfmezei : Oh yeah that !

Heck, I was pleased that there even refered to me ! The word "cripples" is mine... not CAIP :-)

Well let see, you get between 25 and 30 KB/s instead of a max of roughly 520.

So you are right, 10% is ridiculous... I apologize,. It really needs to be 95.2% because you are only getting 4.8% of the speed you're paying for.

]]> http://www.dslreports.com/forum/remark,20782600 Sat, 12 Jul 2008 22:42:39 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782598 mazhurg : What really bothers me throughout this is that it really never touches the issue at hand; namely that this is not about IP but a dispute about PPPoE management.

For anyone with a modicum of understanding, this document is so full of mistake that it almost scares me that our telecommunications are managed by such gents. Makes one really confident. Heck, so much so that one should really read this »ARRGH! False 911 Calls as a perfect example of the level of knowledge and expertise herein... :uhh:]]> http://www.dslreports.com/forum/remark,20782598 Sat, 12 Jul 2008 22:42:15 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782551 tertech : 19.According to CAIP and Vaxination: i) “The purpose of GAS is to create a pipe or pathway that runs from the premises of each end-user customer through Bell’s central offices (COs) and then on to a physical interface point in Bell’s local network where competitors must interconnect in order to gain access to their customer’s traffic”12, and ii) “A service provider pays a GAS/HSA for each individual ADSL line. The service provider should have full and unqualified access to the bandwidth of each ADSL line the service provider pays for. A service provider also buys sufficient capacity in the “Aggregated High-Speed Service Provider Interface” (AHSSPI) to support the link between itself and the Bell ADSL cloud. Bell is therefore already compensated on the number of customers as well as the total bandwidth generated by those customers.”13

20.Based on these premises, parties throughout their submissions compare the theoretical speed of the GAS service with the reduced speed applicable to a single type of application (i.e., P2P file sharing applications) during peak periods when traffic shaping takes place. These parties then draw the ridiculous conclusion that Bell “cripples the ADSL by approximately 90%”14 or “Since Bell throttles downstream speeds to 30 KB/s (or 240 kbps)15, this represents only 4.8% of the Basic - Residence downstream speed of 5 Mbps referenced in Bell’s GAS tariff.”16

21.The incorrect premises lead to invalid calculations and comparisons, which only serves to confuse the relevant issues. ]]> http://www.dslreports.com/forum/remark,20782551 Sat, 12 Jul 2008 22:29:11 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782541 Omr :

quote:
20.Based on these premises, parties throughout their submissions compare the theoretical speed of the GAS service with the reduced speed applicable to a single type of application (i.e., P2P file sharing applications) during peak periods when traffic shaping takes place. These parties then draw the ridiculous conclusion that Bell “cripples the ADSL by approximately 90%”14 or “Since Bell throttles downstream speeds to 30 KB/s (or 240 kbps)15, this represents only 4.8% of the Basic - Residence downstream speed of 5 Mbps referenced in Bell’s GAS tariff.”16

WTF is that supposed to mean? Is it me or is that just a play on word designed to spin? How ridiculous we don't cripple by 90% but rather cripple you to 5% (in other words by 95%). Bell has lost it they are all a bunch of fucking sleazeball assholes. A boardroom full of douches so out of touch with reality that they need to feel a corporate bitch slap. If you smell what the Rocky is cooking ;) .]]> http://www.dslreports.com/forum/remark,20782541 Sat, 12 Jul 2008 22:26:58 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782530 jfmezei : >Did you see the part where they called one of your statements "ridiculous"? I nearly fell off the chair.

Hey, you should have prexied it with "SPOILER ALERT"... It ruins the entertainment value of this 86 page ordeal !

I am only up to page 73. I suspect any comments about my submission would be todards the end since Bell obviously had aboilerplate of this document long ago. It includes much previously released material.]]> http://www.dslreports.com/forum/remark,20782530 Sat, 12 Jul 2008 22:23:09 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782511 tertech :

said by jfmezei

:

Man, this document is long.

Reading is makes you lose focus. I can see Bell's tactics now. They "sort of" tackle all aspects and give an imporession that they have dealt and won each issue. And you tend to forget the original arguments.

Damned, and I thought my documeht was long at 29 pages ! At least I had a few pretty pictures :-)

BTW, a lot of the bell document is a rehash of previous documents.

CAIP's people will be pretty busy in the next few days.

Did you see the part where they called one of your statements "ridiculous"? I nearly fell off the chair.]]> http://www.dslreports.com/forum/remark,20782511 Sat, 12 Jul 2008 22:16:18 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782465 jfmezei : Man, this document is long.

Reading is makes you lose focus. I can see Bell's tactics now. They "sort of" tackle all aspects and give an imporession that they have dealt and won each issue. And you tend to forget the original arguments.

Damned, and I thought my documeht was long at 29 pages ! At least I had a few pretty pictures :-)

BTW, a lot of the bell document is a rehash of previous documents.

CAIP's people will be pretty busy in the next few days.]]> http://www.dslreports.com/forum/remark,20782465 Sat, 12 Jul 2008 22:01:46 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20782256 jfmezei : Damned this is long !

Re: paragraphs 50 to 57.

YEP, the internet is growing. If this is news to Bell, then Bell is incompetant, and it has no excuse to not have been proactive and updated its infrastructure at greater pace.

The current GA/5410 tariffs alrteady provide for revenus based on usage since ISPs must purchase sufficient AHSSPI capacity to cope with user demand. As usage increases, ISPs buy more capacity from Bell and Bell should upgrade its network accordingly. Period.

Internet transit providers are more than happy to sell more bandwidth to their customers. Why isn't Bell ?

Paragraph 58: Mobile data usage is inconsequential to GAS/5410 and the amounts transfered are microscopic due to high data package costs in Canada.

RFID is not related to the internet. This is just filler to make document longer.

Paragraph 59 is filler. Web based applications are just data abeing transfered over the wire.

Paragraph 60: Yes, remote backup is to be another big user of data transfer. Will Bell throttle it when data rates exceed 30kbps ?

Paragraph 62: If congestion happens only at the Bell network, and ISPs have been able to upgrade their own facilities and internet connection capacity, then shoudln't Bell be blaming itself instead of blaming others ?

In recent years, Bell has upper the default ADSL speed from 1.3 to 7 mbps. This represents a 530% speed increase. Did Bell Canada also increase its backbone capacity by 530%. For every ADSL speed increase Bell Canada wants to be able to advertise against Cable, Bell must also increase backbone capacity to be able to deliver those speeds.

Paragraph 67: Yep, dropped packets force retransmissions and end up reducing network throughput. So why is Bell dropping over 20% of BitTorrent packets in its PPPoE service ?

Paragraph 71: Bell does not mention ethernet links. Since the GAS/AHSSPI is moving towards Gigabit Ethernet, this is the primary consideration for the future. One should not look at antique links that are scheduled to be replaced in the near term to determine whether long term DPI equipment should be allowed.

Paragraph 79 (congestion).

Of the congested links, what percentage were ATM based versus Gigabit ethernet based ? AKA: if congestion happens only on legacy equipment scheduled to be replaced, then the push would be to acceleratethe replacement instead of installing DPI.

And if they thottle BitTorrent, then they already admit other applications will also cause problems. The solution is to match access network capacity to the ADSL speeds that end users are given and let ISPs buy what they need.

Paragraph 87: Only increasing capacity applies to GAS/AHSSPI. The rest of the elements mentioned in paragrpah 87 are Sympatico's jurisdiction.

Paragraph 88: How much of the 3 billion was invested in the GAS/AHSSPI network versus Bell's backbone vs Bell's Internet network (AS577). And how much of that did Bell spend to hire Microsoft to run Sympatico's mail and web sites ?

Figure 14 is interesting. Does backbone refer to AHSSPI, or to some other network (such as its internet AS577 network which is not connected to GAS/AHSSPI) ?

estimated numbers based on figure 14:
DSLAM AGGREGATION BACKBONE

2003 215 110 x
2004 277 117 115
2005 317 140 170
2006 380 150 260
2007 425 165 530

DSLAM capacity grew by 97.6%, or average of 24.4% per year
Aggregation grew by 50% or average of 12.5% per year
backbone grew by 415% or average of 138.3% per year

It is VERY VERY clear that Bell has not invested in the aggregation network as it should have.

Looking at another way:
2003: DSLAM was 195% of aggregation.
2004: DSLAM was 236% of aggregation. BACKBONE was 95% of aggregation
2005: DSLAM was 226% of aggregation. backbone was 121% of aggregation
2006: DSLAM was 253% of aggregation. backbone was 173% of aggregation
2007: DSLAM was 257% of aggregation. backbone was 321% of aggregation

Since we don't know what "backbone" means, we can't judge it except to say that it grew by 415% and this is where Bell evidently put more of the money.

No matter whether the DSLAM capacity represents actual capacity (number of users * average speed given to users), or whether it represents max capacity (theoretical ADSL-1 limit of 8mbps down and 1mbps up * number of installed ports), it is clear that the aggregation network did not get an investment that is commisurate with the DSLAM and backbone networks.

So during this time, Bell increased its DSLAM speeds from 1.7 to 5.0mbps (nearly 200% increase in speed, and thus potential capacity requirement), and did not match the aggregation speed.

One would have to ask wehther the very modest investment in aggregation capacity even matched the increase in number of users.

It is also very clear that Bell has allowed the disparity between aggregation and DSLAM/backbone to get worse, creating an even greater inability to deliver the services that are being sold.

THEORETICALLY, aggregation should have same capacity as DSLAMS.
In practice, Bell can get away with less by studying usage patterns, BUT when usage patterns change, Bell MUST adapt and not complain.

Up to now, Bell got away with an underprovisionned aggregation network. Now, it is failing to deliver advertised services which are also regulated by the CRTC.

The installation of DPI equipment is making things even worse since Bell delivers even less capacity at the aggregation point.

Paragraph 91: IMPORTANT: Why is this technique of network management not acceptable ? (increase capacity when they see links that are close to congestion).

Paragraph 95: Bell should be made to provide % of DSLAMS that are on ethernet vs those that are on legacy ATM, and provide year by year estimate of progression of conversion to GigE links. This should be a high priority since aggregation is clearly underprovisioned compared to DSLAM.

Paragraphs 101: why is Bell increasing ADSL speeds at a faster rate than it can upgrade DSLAMs and the links to support them ?

Patagraph 102: it is the cost of mobile text which is exhorbitant and far more expensive than Bell's old Datapac network. The comparison is meaningless. Rocky can probably provide internet transit costs as a base reference to what todays "wireline" costs really are.

Paragraph 103: This would have to be Sympatico and totally irrelevant to GAS/AHSSPI.

Paragraph 104: As a result, in addition to expanding capacity, Bell Canada uses pricing-based mechanisms to manage network traffic such as bandwidth caps and usage-based pricing. This type of differential pricing is beneficial to both consumers and carriers because it matches prices to use, which provides the appropriate incentives for optimal network use and expansion.

This is not applicable to GAS/AHSSPI tariff since 5410 is based on a flat fee per user for the ADSL link, and the AHSSPI bandwidth purchases to cover the conveyance of packets from ADSL line to the ISP's premises.
If users consume more bandwidth, ISPs have to purchase more AHSSPI from Bell so Bell should not try to prevent delivery of this purchased bandwidth.

Bell has not stated (so far) that the GAS/AHSSPI rates are insufficient to pay for the network upgrades necessary to provide the purchased services.

Paragrpah 105: again the mention of usage based billing. Not applicable to GAS/5410.

Paragraph 110: The Company has observed that non P2P traffic has significantly increased since it deployed traffic shaping during peak periods. This increase is likely a result of two main events: 1) non P2P traffic is now able to use up and flow more freely using the bandwidth previously occupied by P2P traffic,

This is absolutely BOGUS. With BitTorrent uncrippled, people were still accessing the web unhindred and not aware for the extreme vast majority of any congestion. Crippling BitTorrent did not magically allow people to use aopplications that they could not use in the past.

##
A full year of data would be needed to better understand the benefits to non P2P file sharing traffic that are directly associated with the implementation of traffic shaping.
##

Don't let Bell get away with this one. We don't want the CRTC to allow the DPI equipment to stay in place for a full year. That is tantamount to accepting it permanently.

114: 114. Before the introduction of DPI, network equipment or routers only looked at the destination IP addresses to determine where to send data, and in order to preserve network integrity (such as protecting the network against viruses).

BELL CANADA HAS NO BUSINESS LOOKING AT IP ADDRESSES SINCE IT THIS IS A PPPOE SERVICE. It does not IP routing of user packets.

Paragraph 115: Since Bell Canada will not divuilge the extact filters that they apply, the CRTC is not in a position to judge exactly what Bell is doing to what sort of private data, and neither are the independant ISPs who cannot define what service they are really offering to their customers.

One important question to ask: Since BiTtorrent has the ability to use encrypted links which means that Bell may not see a "signature" in the data, how does Bell find out that an encrypted link is BitTorrent and not something else ? (conclusion, it is likely that bell is throttling anythng that is encrypted unless it is on a specific well known port for certain types of VPN)

paragraph 117: this is why more and more consumer grade routers support QoS sertvice where the customer can give priority to packets coming from a certain device or using a certain port. This is the customer responsability to define which applications have priority for the bandwidth. It is none of Bell's business.

More in part 2 cont2 :-)]]> http://www.dslreports.com/forum/remark,20782256 Sat, 12 Jul 2008 21:11:07 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20781954 HoboJ : It definitely wouldn't surprise me if Bell hasn't greased some influential palms in the CRTC. Unless Bells bullshit gets refuted in the mainstream media I have little faith the CRTC will side with us; regardless of the overwhelming evidence in support of our cause.]]> http://www.dslreports.com/forum/remark,20781954 Sat, 12 Jul 2008 19:38:56 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20781933 davidbrown : Don't be certain the crtc is going to side with us on this because of the paper.

Whats needed is a public display were they get caught lieing or a highly regarded expert who can publicly and professional tear this bs apart.

If it can't be kept hidden and the proof is undeniable the crtc is going to have little choice but side against bell.

If the laymen knows he getting hosed and in a way that he can understand bell is toast.

If bell gets its wish and keeps this out of the public there is little chance the crtc is going to side against bell in any meaningful way.]]> http://www.dslreports.com/forum/remark,20781933 Sat, 12 Jul 2008 19:33:34 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20781706 Ikarasu : It did happen... with Comcast, and theyre not being charged a fee :P

Either way... wow, a lot of useless, inacurate facts from bell. I was worried how CRTC would decide, but after this... it should be a clear choice for them.]]> http://www.dslreports.com/forum/remark,20781706 Sat, 12 Jul 2008 18:45:19 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20781690 anon : Traffic shaping is not a notifiable change??!! I hope bell gets sued to the bull's tits over this one. The small claims court of Ontario apparently is as clueless as the general public when it comes to the internet or they'd award the subscribers the maximum under Ontario law over bell's illegal 100 dollar fee. I think the maximum is something like 50,000 dollars in Ontario. If such a thing like this happened in America the FCC would have slapped any isp with a fine the very same day.]]> http://www.dslreports.com/forum/remark,20781690 Sat, 12 Jul 2008 18:39:31 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20781578 jfmezei : ##
7. It must be noted that the Company, as a Canadian Carrier, is in control of its own network and is free to implement the standards and specifications of its choice within its network
##

Once implemented and regulated by CRTC, changes to the above require CRTC discussion and approval. Bell argues that it can change anything at whim and decide whether it has any impact on customers or not. This must not be tolerated.

----------------------------------------

##
10. In order for readers to fully understand the issues, the Company will follow with a description of the technologies involved including: a description of how traffic is routed on the Internet, how devices and applications on the Internet handle congestion followed by a description of peer-to-peer (P2P) technology.
##

This is about GAS/5410, not IP or TCPIP or about the internet.

-----------------------------------------

##
21. The incorrect premises lead to invalid calculations and comparisons, which only serves to confuse the relevant issues. At the outset, because of the nature of DSL services, it is impossible for the Company to promise a specific bandwidth to high-speed service end-users (retail or wholesale GAS). Therefore, these services are marketed with an "up to" speed (such as 5 Mbps in the case of GAS). This is a fact that all ISPs are aware of, including CAIP:
##

This is about the copper loop line quality which does not garantee the actual sync speeds capable of being achieved, But once sync has been achieved at a speed of up to 5mbps, there is every expectation of being able to use that speed due to the dedicated nature of each ADSL loop.

--------------------------------------------------------

##
22. Furthermore, the traffic shaping that Bell applies is limited to P2P file sharing applications during peak periods, and does not impact the speed for other applications such as web browsing or video streaming such that simultaneous use of other non P2P file sharing applications is not affected.
##

GAS is not sold as a web browsing or video streaming service. It is to be a transparent logical path between an end user and its service provider and Bell Canada has no business deciding what type of data flows at what speed. It is not correct for it to state that some data is time sensitive and others is not. A doctor expecting to receive a large animated 3D cat-scan via BitTorrent would not be happy to be throttled at 30KB/s when a patient is awaiting diagnosis.

----------------------------------------------------------

##
25 ...
Competitors will likely continue to select an AHSSPI based on the lower tariff rates for GigE links and use the peak utilization as an additional factor in their decision process irrespective of fluctuations in traffic.
##

Competitors will adjust the amount of AHSSPI capacity the buy from Bell based also on the average utilisation of their customers. As internet usage patterns change, they will purchase more AHSSPI bandwidth per customer. Bell attributes increase in purchased AHSSPI only to grown in number of customers, when increased AHSSPI is the result of both increased number of customers, AND increased average use.

So competitors fully pay for the bandwidth generated by their customers and Bell must be made to provide this bandwidth without any discrimination on data type.

----------------------------------------------------------

##
26. In addition, CAIP notes that its "members typically plan for additional capacity when peak AHSSPI utilisation rates hover between 50 and 60 percent of the total capacity of the AHSSPI". The table shows that even after shaping the utilization level surpasses the level where additional capacity should be planned for.
##

Bell's current limited AHSSPI load balancing technology may result in individual links to an ISP to have high utilisation rates for a period of time while the other links to the same ISP are lower. Bell cannot look at individual events of indiviudual links, it must look at a big picture of what an ISP pays versus what is being used on average for the combination of all purchased links.)

aka: 1 of 2 links at 100% while the second one is at 0% means an average of 50% which should be achieved over time as disconnected PPPoE sessions reconnect to the second link.

-------------------------------------------------------------------

GENERAL

Bell makes multiple allusions that HSA is to provided a fixed IP. This is not the case. HSA is just a permanent virtual circuit between the end user and the ISP while GAS is a switched virtual circuit using different protocol.

The types of IP assigned (fixed or dynamic) is irrespecive of whether it is on GAS or HSA and both types can be provisioned by the service provider on either services. This is beyond the scope of GAS/5410 which deals with PPPoE service. (HSA deals with transport of ethernet frames).

##
Bell Canada also estimated that in Ontario and Québec, 95% of the SMB customers were in the footprint of a cable operator
##

Cable wholesalers are not allowed to have customers run servers due to the sensitive nature of the upload on shared cable. (as per the tariff with videotron, don't remember the exact number, but I send a private DSLR-IM to ebox on that).

Therefore, for SMBs, cable is not really a viable alternative unless they just use the srevice to browse the web.

--------------------------------------------------------------
29...
HSA is an alternative to business end-users

Because HSA has an artificially inflated price and lack of modern management software to make its management simpler, Bell clearly does not wish HSA to become popular (whereas HSA is standard in Telus territory)

If the majority of customers moved to HSA, would Bell install DPI equipment on HSA links as well to prevent use of whatever applications Bell has decided take up too much bandwidth ?

------------------------------------------------------------------

32...
Internet applications use well defined protocols to communicate between parties. In order to get data (i.e., content) to another party on the Internet, the application will first format the data and header information (e.g. the recipient’s email address in the case of an email application) will be added

For email (SMTP), the application protocol, RFC 821, and the email headers, RFC822 are all fully within the DATA (payload) portion of packets. The email destination is NOT inside the envelope of the TCPIP packets.

RFC821 does not define an application "header". It defines a dialogue between 2 hosts to negotiate delivery of data. This dialogue happens 100% within the data portion of packets, defines SMTP server, the sender and recipient email addresses and is followed by the a stream of bytes that contain textual representation of the message structure (RFC822) and textual contents of the message.

THERE IS NO SUCH THING AS APPLICATION HEADER

----------------------------------------------------------------------
34...
These application specific protocols are described via a set of protocol headers that are typically transferred at the initial setup phase of the communication between the two end-points.

False.

Applications define how they work. The analogy would be close to record formats than to "application headers" since a whole record may have a series of protocol bytes followed by a number of data bytes, or it may have on large control structure in a specific location in the record that defines where the data is on that record.

This is no different than an ATM transation record layout which defined in which bytes the card number, pin, transaction type and transaction amount should be placed and how large each field is. This is very private information of the payload and Bell Canada has absolutely no business knowing about this for in links such as GAS.

----------------------------------------------------------------------

First part of paragraph 36 is correct. However, having over 20% packet loss over a 9.5 hour period is way above network congestion handling. The TCP congestion handling was designed to handle short period of congestion, and in the case of ISPs, if a transit provider has significant and consistent periods of congested links, the ISP will choose another transit provider.

ISPs do not have the choice of selecting another ADSL access provider, so Bell must be made to manage its network to keep dropped packest to a minumum.

And since this is a PPPoE network, Bell Canada must have no knowledge of what their contents are. Since PPPoE packets can contains data which does not handle loss of packets gracefully (such as IP-UDP or other protocols), Bell Canada has no right to unilaterally decided to drop 20% of certain packets because it muct not have the right to inspect the payload of the PPPoE packet.

Paragraph 36 again: Discussion of jitter. It is muy experience that the jitter on the link between end user and ISP was less than 1ms and was pretty stable. Bell has not made public any numbers that show jitter to be a significant and pervasive problem throughout its network.

---------------------------------------------------------------
##
37. Therefore, different web applications have, by necessity, different Quality of Service (QoS) requirements.
##

"web" implies HTTP application protocol. Shows that Bell doesn't quite understand what it is talking about. This is an important issue and Bell should be using precise terminology.

-----------------------------------------------------------------
##
38: Bell provides a PPPoE service. It has no business deciding what applications are time sensitive and which are not. As stated before, there are time sensitive P2P applications being crippled by Bell.
##

And even for a file transfer, Bell's crippling makes a 1 hour file transfer can take over 11 hours. Not everyone has the luxury of waiting until 02:00 to get a file transfer started.

------------------------------------------------------------------

##
39. ... But what happens when applications behave differently, such as P2P?
##

BitTorrent uses no special TCP techniques. It uses the same TCP throughput management as any other TCP application. The Bittorrent protocol definition clearly states that. In fact, BitTorrent uses additional techniques to detect congested links, declare them as "choked" and focus on using uncongested links instead.

--------------------------------------------------------------------

GENERAL:

If Bell Canada can pronounce Skype and Joost and HTTP protocols, why can't it define its throttling be limited to BitTorrent ?

Because if it were to use "BitTorrent", it would be accused and sued by BitTorrent corp. of discrimination and causing harm to a competitor. BitTorrent is not only a protocol, but it is also a commercial operation that competes against the Bell Video Store.

------------------------------------------------------------

42: It is not up to Bell to decide which files are "time sensitive" or which one should be throttled to day days to transfer. Data is data and whether it is coming from the Bell Video Store or some Bittorrent Peers makes no difference at the PPPoE level: the same number of packets are being transmitted.

---------------------------------------------------------------

##
44.
Chief Strategist, Mike Lee, P2P is "actually designed to overwhelm other traffic." A P2P application, rather than opening up only one stream or session, will open up 40 to 100 TCP sessions in an effort to transfer data as fast as possible using multiple sources and can therefore grab dozens to 100s times more bandwidth than a traditional single-stream application such as email or Internet banking applications (see Figure 4 below).
##

THIS IS FALSE. First and foremost, GAS deals at the PPPoE level. It is fully unaware of the number of TCP sessions currently opened.

Secondly, at the ISP and transit provider level, the number of outstanding TCP sessions is not known. They deal with routing of packets at the IP level and do not follow how many "opened sesssions" at the TCP level exist.

Third, the big difference resides at the customer premise equipment, notably the computer which maintains the data structures to remember the multiple sessions, as well as the NAT router which must remember how each TCP session is mapped between the internet side and the LAN side.

Fourth, whether you have 1 , 2 or 100 TCP sesions running, THE PIPE REMAINS THE SAME SIZE AND YOU CANNOT USE MORE SPEED THAN THE PIPE ALLOWS NO MATTER HOW MANY TCP SESSIONS YOU HAVE.

The TCP "session" is a virtual concept that exists between 2 computers and is not maintained nor managed by an internet network provider in any way.

Rogers has proxy servers used to insert content in HTTP transactions, and those servers would be aware of TCP connections since they need to fake connectivity so that the inserted packets can appear to be "native" to the data stream.

##
By initiating more and more P2P applications on powerful computers, the user will continue to expand the number of active streams eventually consuming all available bandwidth.
##

If you have one peer giving you 4.5mbps of data, it is no different than 10 peers giving you 450kbps each, or 100 peers giving you 45kbps. They will all give you data as fast as the slowest link between them and you allows.

THERE IS NOTHING WRONG WITH USING A PIPE'S CAPACITY. ALL APPLICATIONS TRY TO DO THAT. BitTorrent simply distributes the load between many peers instead of focusing on a mega central server. But at each end point, there is no difference.

---------------------------------------------------------------------------

##
45. Second, once all the available bandwidth is being consumed, TCP, through its windowing technique mentioned above will use a queuing technique for additional requests until more bandwidth becomes available
##

This is false. TCP allows the sender to send a certain amount of data that is not yet acknowledged by the receiver. (window size). If there is a lost packet, the recipient will stop acknowledging at the last byte in the packet preceding the lost packet. The sender will eventually stop once it has sent "window size" bytes after that last acknoledged byte and realise it needs to resend the lost packet again. This introduces a gap between packets which reduces throughput.

There is no "queueing until more bandwidth becomes available".

The windowing exists to cope with the fact that it can take a signifiacnt amount of time for packets to reach destination and an equal amount of time for their acknoledgement to reach the sender.

##
In addition, P2P applications typically have slots for the total number of downloads. Once the total number of slots is consumed, the P2P application will use a queuing technique for additional file downloads until additional slots become available.
##

This is correct.

##
The P2P application queuing of multiple requests combined with TCP windowing and the inherent application persistence of P2P enable it to sustain a continuous maximum network traffic load, 24 hours a day, 7 days a week and 365 days a year, as long as there are queued requests.
##

The queueing is done purely at the application level and is irrelevant to the network. What counts in the context of GAS is how much data goes through the ADSL modem and how the application on a computer processes that data is absolutely irrelevant to this service.

The TCP protocol was designed to allow continuous sending of data over long links by having an appropriately sized window. If Bell Canada is unhappy with the design of TCP and IP, it should get out of the business. A network oprovider is expected to HELP customers carry data from point A to point B as fast as possible instead of HINDER the use of the service.

-=---------------------------------------------------------
##
46. Finally, it is not enough to simply manage the traffic of the network's users. Some P2P file sharing applications constantly look for the fastest node available, and thus any increase in capacity to one network node will attract increased P2P file sharing upload requests from other P2P file sharing applications resident on other networks
##

NEVER does BitTorrent or any application exceed the speed which was assigned to the link. With whom a BitTorrent user exchanges data is none of Bell Canada business. If BitTorrent connects to a remote peer that has spare bandwidth, it makes absolutely no difference to Bell. Bell is given the responsibility of providing the ADSL link and carry PPPoE packets between the end user and the ISP and there is absolutely no knowledge at the PPPoE level of what is going on inside the packets or with whom an end user has connected. This is private data. Bell connects the user to his ISP. It does not connect users to users.

-------------------------------------------------------------
##
47. Thus, P2P file sharing applications not only generate considerably more traffic volume in the long run because it runs for a lengthy amount of time,
##

DOWNLOADING A MOVIE VIA UNTHROTTLED BITTORRENT WILL TAKE THE SAME AMOUNT OF TIME AS DOWNLOADING IT FROM BELL'S VIDEO STORE.
THE ABOVE STATEMENT IS PATENTLY FALSE.

##
it also uses up the major share of the available bandwidth at any given point in time because it uses so many concurrent TCP sessions
##

This is patently FALSE. It will use as much bandwidth as is available, just like any other application. And at the Bell Canada (GAS/5410) level, this is ABSOLUTELY inconsequential since Bell just carries PPPOE packet and is unaware of whether the user is using IP, IP_TCP, IP-UDP or whatever protocols.

The issue of multiple TCP sessions has been debunked already.

##
Therefore, hundreds of TCP sessions generated by a single user, or users from other networks, will negatively impact the experience of many others
##

THIS IS ABSOLUTELY FALSE. It will use the same amount of bandwdith that is available, namely the speed of the ADSL link and no more. This is no different from the amount of data/bandwidth generated when downloading a movie from the Bell Video Store.

##
This is compounded by the fact that P2P file sharing users tend to initiate multiple large file downloads and simply leave the application downloading and/or uploading pieces of content.
##

This is lore unsupported by any facts or statistics. People dowload what they need, and they purchase a service that provides for monthly download limits that they need. In return, the ISP buys sufficient bandwithd to support its customers' type of usage.

BitTorrent can be used to transfer small or large files. Just because it *can* be used to transfer multiple large files at the same time (taking a longer time to complete) does not mean that this is what people do in practice.

However, since Bell has begun to cripple BitTorrent, many transfers are now measured in days instead of hours, but this is because one is unable to achieve speeds during the periods of time when the data is most available.

OUF ! that was a long paragraph to comment !

-----------------------------------------------------------------

48...
P2P file sharing does not diminish costs, rather it offloads the hosting and server costs from a content provider to the ISP's network

No. It moves costs to each peer on the network. Since each peers pays his ISP to use the network to a certain amount, then it is the peer which pays for it.

This allows the information provider to be more competitive since its own bandwidth costs are much lower since purchasers of the products end up paying for the bandwdith.

This is not different from the NNTP protocol as originally envisaged where it was also in a peer-to-peer exchange of posts and each NNTP server was expected to serve other servers, thus distributing the tramnsmission costs of all of the worldwide content.

##
In other words, P2P file sharing creates a negative externality for facilities based ISPs.
##

These ISPs buy more bandwdith from internet transit providers, as well as more AHSSPI/GAS bandwidth to support this type of activity and Bell shoudl just provide the purchased bandwdith. The ISP is the one who decides how much to charge each of its customers and how much data each customer can exchange each month.

##
One could argue that content providers need to be motivated to develop a more efficient method of distribution that takes into account network operator concerns.
##

The developpers of BitTorrent adhered to the IP and TCP protocols to the letter and designed their application to make the most efficient use of these protocols.

If Bell Canada sets Sympatico users to 7mbps ADSL speeds but has not upgraded its underlying access capacity, then the fault lies with Bell Canada and only with Bell Canada.

Bell Canada advertises a 5mbps product to the indepedant ISPs. The independant ISPs are perfectly capable and willing to handle the load at their end, and have paid Bell Canada to handle that load. It is Bell Canada which in unable to provide the service which it advertises and which was paid for by the ISPs. Bell Canada has nobody but itself to blame.

BELL CANADA MUST ONLY ADVERTISE SPEEDS WHICH IT CAN SUPPORT. It cannot blame any one application that makes legitimate use of purchased bandwidth.

And there is no definition within the GAS/5410 tariff of what "acceptable speed" is. Bell Cannot pull some random number out of a hat and unilaterallly declate that anything above 30kb/s is considered "abuse" when it continue to advertise 7mbps speeds to the public. (while only giving 5mbps to competitors)

----------------------------------------------------------------

Paragraph 49:

***ALL*** applications are designed to use all of the available bandwidth.

BitTorrent is no different. The advent of high speed internet access has enabled new applications which have seen the need to transfer much larger files than before. It has also seen richer HTML content with web pages filled with unnecessary images, and megabytes of unnecessary javascript to please the marketing departments.

There is no question that demand on networks is increasing as more and more people start to consume richer media files. Internet transit networks are coping quite well and are happy with the extra business. Bell Canada should be happy to see ISPs purchase more AHSSPI bandwidth and shoudl strive to be ahead of demand. Bell is now admitting that they have fallen behind the demand, despite ISPs having been paying for the bandwidth.

--------------------------------------------------------------

(continued in next email)

-----------------------------------------------------------------------------]]> http://www.dslreports.com/forum/remark,20781578 Sat, 12 Jul 2008 18:09:04 EDT Re: ES12 comments http://www.dslreports.com/forum/remark,20781539 jfmezei : Oh man, Bell has certaintly given us a LOT to chew on.

We'll get very fat dining on all those arguments against Bell.

I am up to paragraph 50 and it isn't even midway though. ]]> http://www.dslreports.com/forum/remark,20781539 Sat, 12 Jul 2008 18:01:11 EDT ES12 comments http://www.dslreports.com/forum/remark,20781440 anon : Bell says in ES12,
"GAS service is not offered over a separate and distinct network. The GAS service offered to wholesale ISPs and the retail Sympatico Internet service offered by the Company share and have always shared the same access network and therefore will experience the same benefits and the same problems. As the Company is applying the same treatment to traffic of its own retail Internet access service end-users and GAS end-users, the Commission cannot find that the Company is conferring unto itself a preference, let alone an undue preference."

1) Bell is conflating "GAS end users" with Sympatico users. GAS end users are in fact CAIP customers, who have no business relationship with Bell. CAIP members sell access to GAS indirectly under different T&C's than Bell does to Sympatico customers. Bell has no knowledge of CAIP 'end users'. This has ALWAYS been the intent of the CRTC wrt GAS services.

2) GAS service is a tariffed service, whereas Sympatico retail service is not, and as such the constant reference to Sympatico users is irrelevant. Again another misdirection by Bell.

3) Were retail internet services in fact tariffed, then no CAIP member could have EVER offered something different than something identical to those services and T&C's as Sympatico's. The CRTC clearly intended that independent ISP's were free to set their own T&C's when using tariffed GAS when they set forth the GAS service tariff in the first place.

4) Bell continually misdirects and misunderstands that CAIP is not reselling Sympatico services, otherwise we'd all be required to suffer the indignities of Sympatico Hotmail and other such garbage provided by Bell with their Sympatico service (connection managers, BLnnn numbers, etc....).

5) Bell has no 'ownership' of the activities, nor 'interest' in the data of any CAIP customer who uses GAS services provided by CAIP members as *their* ISP.

------

What Bell is trying to assert is analogous to a trucking company hired to deliver a washing machine to a Futureshop customer stating that it has has the unilateral right to use a Smart car to deliver the washing machine to the end user in disassembled form, in multiple deliveries, and to lose pieces of the washing machine along the way, and to not be responsible for any damages or loses incurred. Any reputable common carrier company, should they be unable to deliver in accordance with their agreement with Futureshop, would 'buy' additional capacity in order to deliver on-time as contracted. Not so Bell.

Another absurd but effective way to look at it is an office analogy. Bell owns an office building and leases a floor to Teksavvy under contract. During the term of the contract Bell unilaterally decides that not only does Teksavvy have to force its employees to wear suits and ties (and not play baskeketball in the office) but that Teksavvy's customers also have to wear suits and ties between the hours of 4:30pm and 2am (because Bell employees and customers are forced to do so by Bell).

----------------------

The CRTC has to be made to understand that I, as a Teksavvy customer, have NO contractual arrangement with Bell Canada in any way, shape, or form, and as such cannot be forced to comply with any demands of Bell Canada with respect to my use of the internet service I purchase from Teksavvy, nor can any T&C's be forced upon me by Bell.

Any attempt by Bell to force any T&C's on me is abusive, coercive, and is most likely an offence under the Criminal Code of Canada - Part IX Offences Against Rights of Property, S.322, S.326, S.342

Section 326 is the section famously added to the Criminal Code years ago when telephone 'phreaking' was first beginning.

Theft of Telecommunication Service
326. (1) Every one commits theft who fraudulently, maliciously, or without colour of right,

(a) abstracts, consumes or uses electricity or gas or causes it to be wasted or diverted;

Throttling, by definition, causes the waste of electricity by each person upon each occurrence of throttling. Bell is by definition liable under S.326(1)(a) for billions of instances of theft.

Don't think that S326(1)(a) is toothless - there have been convictions under this.

Also,

Unauthorized use of computer
342.1 (1) Every one who, fraudulently and without colour of right,

(b) by means of an electro-magnetic, acoustic, mechanical or other device, intercepts or causes to be intercepted, directly or indirectly, any function of a computer system, [DPI anyone?]

(c) uses or causes to be used, directly or indirectly, a computer system with intent to commit an offence under paragraph (a) or (b) or an offence under section 430 in relation to data or a computer system, ]]> http://www.dslreports.com/forum/remark,20781440 Sat, 12 Jul 2008 17:33:02 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20781158 MisawaGQ : It's hard to believe a multi-billion dollar corporation would be so lax and sloppy in dealing with the government. But, I guess this document is legitimate, and the proof is in the pudding. Do they seriously believe such blatant lies and half-truths are going to be taken at face value? The CAIP is going to have no trouble at all totally debunking this nonsense. It really is puzzling, but also hilarious.
--
"Let them hate, so long as they fear" -- Lucius Accius]]> http://www.dslreports.com/forum/remark,20781158 Sat, 12 Jul 2008 16:15:15 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20781139 Robrr :

said by Guspaz

:

My favourite bit of bullshit:

quote:
It is called “Deep Packet Inspection” because it looks beyond the routing and transport headers, deeper into the application packet headers, to determine the type of application that is communicating, but not the content itself (see figure below).

That's nice, except APPLICATION HEADERS ARE PART OF THE CONTENT ITSELF. As in, they are the payload of the TCP packet. You need to look at the CONTENT to get the application headers.

This document better be legit because this alone is the smoking gun that will give CAIP, CIPPIC, the Privacy Commissioner, the CRTC and probably a LOT of other people more than enough ammo to destroy Bell in its FULL ENTIRETY.

That single statement is more than enough cause the complete removal of that equipement.

Once again if this document is legit CAIP should seriously push to for the IMMEDIATE CEASE AND DESIST of the throttling. This is the exact same as the post office reading your mail.]]> http://www.dslreports.com/forum/remark,20781139 Sat, 12 Jul 2008 16:09:37 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20781103 The Flash : Nice breakdown, must have worked out a sweat to take all that BS.]]> http://www.dslreports.com/forum/remark,20781103 Sat, 12 Jul 2008 15:58:26 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20781066 jfmezei : this is long, comments just for the executive summary....

will hope to avoid duplication of arguments in what follows.

text between ## denotes quotes from Bell's letter.

----------------------------------

Since the letter was posted on the p2pnet.net web site, it is now public document. (even of not on the CRTC web site yet) I assume someone within your group got a copy and sent it to the p2pnet folks)

Some comments:

##
a. Since 2001, the Company has invested over $3 billion in capital investments on its high-speed Internet service.
##
In an interview on CBC's Spark (.MP/ available on the spark web site), Bibic mention the "3 billion invested", but was asked "was that all on the internet" and he had to say "hundreds of millions on internet".

Not sure if this is all for the same timeframe as the current Bell document. Something to check.

-----

As Bell upgrades links to ethernet, it should be able to use legacy ATM equipment freed on those links to tempoeraily upgrade remaining ATM links, so the argument of continued purchase of expensive ATM equipment shows bad management on Bell's part. If it is cheaper to upgrade to ethernet, the Bell should simply be accelerating upgrades to ethernet.

And Bell has not demonstrated in its statistics whether congestion occurs only at ATM links or both ATM and ethernet. If congestion is only at ATM links, this should be viewed as a temporary problem to be solved by accelerated upgrade programme.

--------------

##
a. The Company initiated the transition to usage-based billing in December 2006 when it ceased offering its “unlimited traffic” plan to any new subscribers. However, the transition to usage-based pricing cannot be the sole solution to network congestion, nor is it an instant "fix" for three principal reasons:
##

We are talking about GAS/5410 CRTC regulated tariff, and not about Sympatico's retail pricing. GAS$5410 is NOT usage based and there has not been any process initiated by Bell to change that tariff.

Usage based pricing is easily accomplished with normal existing routers, and thus do not need DPI equipment. Independant ISPs already accomplish this with their routers and Bell does not need to put any equipment between them and their customers to do that job.

-----------------------------

i. terminating or managing the service of users who consistently breach the Company's Acceptable Use Policy; and

Bell Canada has no right to decide to terminate customers of its competitors. This is not a submission about Sympatico, it is a submission about GAS/5410.

------------------------------------
##
The Company does not block any form of P2P file sharing applications nor does it shape non P2P file sharing applications.
##

The speed at which Bell cripples certain communicatiosn makes them unusable during the hours where they are crippled and thuse this is similar to blocking them even if technically they still run.

Putting a 5km/h speed limit on the 401 in Toronto between 16:30 and 02:00 would not close it, but would make it ususable and force people to use other routes.

MORE IMPORTANTLY: SINCE BELL REFUSES TO DEFINE EXACTLY WHAT IT DOES THROTTLE' PEOPLE CAN'T KNOW WHAT WILL AND WILL NOT BE THOTTLES AND SERVICE PROVIDERS CANNOT ADJUST THEIR SERVICE OFFERING TO REFLECT THIS SERVICE DEGRADATION.

EVEN MORE IMPORTANTLY: SINCE BELL RESERVES THE RIGHT TO CHANGE ITS CONFIGS ANYIME IT WANTS WITHOUT WARNING ANYONE: SERVICE PRODIDERS ARE IN EVEN WORSE SITUATION SINCE THEIR SERVICE OFFERING CAN BE CHANGED BY BELL WITHOUT WARNING. THIS IS A **VERY** VISIBLE CHANGE THAT MATERIALLY EFFECTS END USERS AND ISPs.

----------------------------------------

##
i) P2P file sharing traffic is designed to open several sessions in an effort to transfer data as fast as possible, thus overwhelming other forms of traffic.
##

FALSE. A single PPPoE session exists between end users and their service providers and the number or IP/TCP/UDP links is totally irrelevant to Bell in the GAS/AHSSPI service since Bell only sees PPPoE packets.

------------------------------------------------

##
ii) Because of the possibility of queuing file requests, P2P file sharing can sustain a continuous maximum network traffic load, 24 hours a day, 7 days a week and 365 days a year, as long as there are queued requests.
##

Solved by monthly download limits which many ISPs have had for many years. And for those who still provide unlimited, then they simply need to buy sufficient bandwdith from bell to support those activities.

---------------------------------------------------

##
iii) Some P2P file sharing applications look for the fastest node available, and thus any increase in capacity to one network node will attract increased P2P file sharing upload requests from other P2P file sharing applications resident on other networks.
##

BitTorrent/P2P cannot exceed the speeds of the ADSL links. They cannot abuse those links. They operate at whatever speed the link is, just as any other bandwidth intensive application including the Bell Video store.

And from GAS' point of view, it only manages a single PPPoE session between the user and the ISP. Whatever *internet* networks may be used beyond the ISP is totally irrelevant to the GAS service.

(remind CRTC that this is about GAS/5410 and not Sympatico service)

Remind CRTC that ADSL is not like Cable (re: Roger's comments). ADSL provides *DEDICATED* bandwidth (leased lines) on the "last mile" and full use of the 800kbps give on ADSL lines does not impact neighbours, contrary to Cable. and 800kbps is very small speed for upload and shouldn't be a problem for Bell to handle in its backbone.

-----------------------------------------------------------

##
ES8. As P2P file sharing applications are designed to use all of the bandwidth that is available, additional capacity cannot, on its own, resolve this issue.
##

The ADSL last mile speed is the real bottle neck. No application can exceed that speed. It is a given that increasing the ADSL speed will increase the load on the backbone, but this happens with any application whereher it be viewing you tube, downloading from Bell Video Store etc.

ALL applications will use maximum speed of the slowest portion of a network (aka: the ADSL link).

-------------------------------------------------------------

##
Because P2P file sharing applications are non time-sensitive, these can be "slowed down" during peak hours of traffic without interrupting service
##

Who decided they were not time sesnitive ? And why is the Bell Video Store considered time sensitive and given full access to the ADSL line while BitTOrrent isn't ?

---------------------------------------------------------------

##
"…allow them to suspend or terminate service where a customer uses or permits others to use services so as to prevent fair and proportionate use by others."
##

In this case, since the GAS customer is an ISP, Bell is refereing to suspending an ISP and not an ISP's customers. In the case of GAS, the end users are not Bell Customers. (remind CRTC again that we are not talking about Sympatico)

Another point of view on this issue: What happens if Bell Canada mismanages a service such that fair use by customers negatively impacts other customers ? Would Bell then be allowed to terminate those customers who, despite having made fair use of facilities, have cause's Bell's mismanaged network to be congested ?

AKA: just because Bell delayed upgrade of its legacy ATM stuff doesn't mean that customers are to be blamed for any small congestion issues.

----------------------------------------------------------------

re: QoS issue with Cybersurf/Shaw:

Again, check with your expert Mr Gabe, but this would normally be implemented in the customer premise equipment which would priorituze which packets go over the link first. The involvment of the ISP or carrier would be less important. (and in the case of Bell, since this is a PPPoE service, there is no concept of prioriity of packets since this is to be a transparent Point to Point service, not a managed IP network.

----------------------------------------------------------------

##
248. The Commission considers it appropriate that each cable carrier be provided the ability to manage the potential negative outcome of high-consuming bandwidth end-users in a manner that does not degrade the Q of S to all end-users, whether it is the cable carrier's end-user or the competitor's end-user. The Commission considers, however, that regardless of
##

Cable is a shared medium on the coax compared to the dedicated links on ADSL for the last mile. And here the use of "Q of S" refers to a generic quality of the service, as opposed to the technical QoS packet prioritisation capabilities at the IP level.

-----------------------------------------------------------------

##
GAS service is not offered over a separate and distinct network. The GAS service offered to wholesale ISPs and the retail Sympatico Internet service offered by the Company share and have always shared the same access network and therefore will experience the same benefits and the same problems
##

While the business relationship between Sympatico and Bell is unknown, it si known that independant ISPS, through GAS/AHSSPI fully pay for the bandwidth that their customers use and as such Bell must be made to provide it.

Secondly, Bell's own graphics in its first intervention in April clearly showed AHSSPI as a separate snetwork from that used by Sympatico.

The fact that Bell underprivisioned the DSLAMBAS links because it underestimated average use is Bell's problem and Bell should be made to solve it by providing adequate bandwidth on those links.

Secondly, if GAS customers were given equal treatment to Sympatico, how come Bell doesn't raise ADSL profiles for GAS end users to 7mbps and give them equal access to remote ADSL ports ?

And what if GAS customer end up paying more per end user and end up buying more bandwidth for aggregation than Sympatico ? Shouldn't they get better service than Sympatico ?

------------------------------------------------------------

##
ES14. Finally, there is no ulterior motive attached to the Company's management of network congestion; it was not launched in order to i) launch usage-based billing,
##

Contradiction with their May 15th filing where they stated the exact opposite. And Bell even mentions in this very docunment they want to use DPI for usage based billing.

----------------------------------------------------------

##
ES15. Despite the many claims by CAIP and other parties, the evidence clearly demonstrates that there is no ulterior motive or any basis for a claim of unjust discrimination.
##

The evidence clearly shows that Bell is not being honest, is refusing to divulge the exact nature of what it thorttles and how it does it, so Bell is in no position to claim that speculation about its true intentions are unwarranted.

This is especially true since Bell has categorically stated that it feels no obligation to inform GAS customers of any changes it makes to its DPI equipment.

------------------------------------------------------------

##
If there is, indeed, any gatekeeping activity on the Internet, which is questionable, the gatekeeping is being performed by the Internet search engines, which are typically the users’ “window” to the near-infinite content available worldwide.
##

Google doesn't prevent anyone from starting a competing search engine with new features which could eventually overthow Google. Google's arguments are about the need to NOT prevent any new application from emerging.

-Google is not a network, it is an application/service provider. -Bell Canada is a network.
-We can use any search engine. We have no choice for ADSL.
-Bell is in no position to decide what apps we can and cannot use.

----------------------------------------------------------------

##

First, the Notification Requirements do not apply to GAS service (as it is not a bottleneck service); second, traffic management is not a notifiable change because it does not require ISPs to make adjustments in their network.
##

"Not a bottleneck service". Interesting terminology. Could this mean that if it is not a bottleneck service, Bell has no right to treat it as such by managing packets to prevent bottlenecks ?

Secondly, ISPs must be able to fully define to their customer what service they provide. If Bell blocks certain applications (making them so slow as to be unusable is equal to blocking them), then this is definitely impacting ISPs and theur customers and ISPs need to be aware of the full details of the throttling in order to have an honest description of what service they can and cannot offer.

--------------------------------------------------------------------

##
ES17. The Company's use of DPI technology as part of its traffic management practices is such that the actual contents of the communication exchange are not examined. Rather, only the protocol headers are examined and the DPI equipment does not retain the information reviewed in the packet headers.
##

My submission has proven this to be wrong. From a network popint of view, anything in tye packet payload is to be considered user data, even control bytes used by an application.

A PPPoE network has no business knowing whether a packet transports email, BitTorrent, raw UDP, DNS requests or web traffic.

------------------------------------------------
##
- use any personal identification information of an individual user;
- store or log any personally identifiable information;
- have specific knowledge of a user's real identity;
##

If Bell wants to use this for usage based accounting, collection of this data would be required in order to be able to send usage data to the billing system.

- have knowledge of a user's content;
- have knowledge of a user's URL browsing history;
- have knowledge of a user's Internet search activity;

By definition, DPI equipment looks at this. And the DPI equipment capabilities list prominently the ability to turn on a feature that will capture browsing history and associate it on a per user basis, as well as provide user-specific throttling profiles.

Since serach activity is transmistted as part of HTTP requests, then collecting URL browsing history implicitely includes search requests.

-------------------------
##
- capture and playback any communications exchange; or
##

The Ellacoya equipment is capable of doing this. As per CAELA requirements.

---------------------------------------------------

##
First, slowing the delivery of content does not amount to "controlling" it.
##

Deciding whether a packet should be transmitted to destination or discartded based on what application it is associated with is defrinitely controlling it.

ANALOGY: Bell is dictating what subjects one can discuss on a telephone conversation. Implementing it requires Bell listen to phone conversations to ensure we only speak of subjects Bell has approved.

-------------------------------------------------------

##
Bell cannot influence the meaning or purpose of the telecommunications because Bell has no knowledge of the content itself.
##

Knowledge of what application is being use explicitely requires knowledge of the content. I have proven that Bell must look beyond the PPPoE, IP and TCP headers to decided which packets are associated with an application.

Analogy: If Bell listens for a female "Oh My God" on a telephone conversation to decided whether to "Throttle" that conversation or not, Bell may claim that "Oh My God" may not contain personal information such as birth date, social insurance number etc, but this is still part of a personal and private conversation and Bell legally requires a warrant to listen to any part of this conversation.

------------------------------------------------------------

##
Unwarranted policymaking and/or regulatory measures could hurt innovation, impede competition and decrease the efficiency of Canadian telecommunications
##

Allowing a monopoly to unilaterally decide what regulatiosn it should implement, what packets it should let through and which it should cripple is abuse of power. GAS/5410 is regulated by CRTC to prevent abuse of power.

--------------------------------------------------------------

##
The Company is confident, however, that competition and market forces will encourage, as it has already done, the development of new, better and fairer P2P file sharing applications.
##

Any application designed to avoid being throttled will end up making use of available bandwidth and Bell can then unilaterally decide to throttle it without telling anyone since it has stated it doesn't need to tell anyone about its throttling.

-------------------------------------------------------------

##
Until that time, the Company has endeavoured to limit its traffic shaping
##

Limit to what ? Since Bell won't fully define exactly what it is crippling, the use of the word "limit" is wrong since those limits are not defined, and Bell reserves the right to change those limits without warning.

Secondly, crippling traffic down to below 30KB/s is not traffic shaping, it is crippling of applications at a speed so slow that it makes them ususable for 9.5 hours per day.

--------------------------------------------------------------

##
Outside of that one concern, the Company submits it is not for the regulator to second guess the Company's engineering decisions.
##

DPI is not a network management solution, it is a service management solution which defines what types of uses of internet are to be allowed and what parts are not allowed. This is not an "engineering" decision, it is a management decision.

If congestion were a problem, Bell Canada would have delayed Sympatico 40% speed increases from 5 to 7mbps until the backbone was able to support it. That would have been an engineering solution to manage the network. The ADSL speed is the only variable that Bell can control under GAS tariffs. ISPs control how much AHSSPI capacity they purchase to support the type of uses their customers make at the speeds Bell as decided to supply on the ADSL loops.

Management at the application level is not network management, it is service management.

-------------------------------------------------------------------
-----------------------------------------]]> http://www.dslreports.com/forum/remark,20781066 Sat, 12 Jul 2008 15:46:05 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780971 Candoo3 : This IS the last response that Bell has the opportunity to make before arbitration, yes?

CAIP et al really need to tear this apart.]]> http://www.dslreports.com/forum/remark,20780971 Sat, 12 Jul 2008 15:25:22 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780951 DSL_Ricer : I found this section fairly bad:

ES21 Several parties have claimed that traffic management will hinder innovation. The Commission should see these [as BS]. [N]ecessity is the mother of invention. Without any regard to network capacity, P2P file sharing application designers could develop applications designed to use all of the bandwidth that is available. It is no coincidence that P4P is emerging as a possible solution with regards to P2P file sharing at a time when ISPs around the world are starting to implement traffic shaping measures.[...]

Except that P4P is a framework to reduce Internet traffic usage. This technology can't and will never substantially decrease the load from ISPs to end users, the segment bell is throttling. This is because the only existing (logical) link in between the the user and network content goes to the ISPs end-user gateways. The data MUST travel over this link. There, therefor, can't be a reduction in load on this link.]]> http://www.dslreports.com/forum/remark,20780951 Sat, 12 Jul 2008 15:22:04 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780911 drjp81 : Holey Mackeral,

So far I've been pretty silent, because I find I am in no way an expert (though interested) on these matters. But when a layman like me can spot questionable stuff like this in their answers, its downright scares me.

Original Bell Answer:

ES2 ....data pulled from extensive studies on the growth of Internet demand, network capacity and congestion, as well as the Company’s more than a decade of experience ...

Studies paid for by your's truly ma Bell of course. And was there ever any doubt the net would grow? So grow with it!

ES19 Bell’s DPI traffic shaping activity does not “control the content or influence the meaning or purpose of telecommunications” ...

If that is so, why don't you limit ALL BANDWITH HUNGRY APPLICATIONS TO "MANAGEABLE LEVELS", like streaming video too?

Argh. They areally burn me up.
--
Cheers!]]> http://www.dslreports.com/forum/remark,20780911 Sat, 12 Jul 2008 15:12:13 EDT Re: A few quick observations http://www.dslreports.com/forum/remark,20780828 anon : Sorry about the loss of formatting on the tabular data.

Data rates used in the examples are down/up, not up/down as originally stated.]]> http://www.dslreports.com/forum/remark,20780828 Sat, 12 Jul 2008 14:51:20 EDT A few quick observations http://www.dslreports.com/forum/remark,20780803 anon : In a quick glance - I have not read it with a fine-tooth comb yet, a few things jump out at me:

1) In section ES6(i)(b) they say, "During this proceeding parties have continuously oversimplified the work required to address network congestion. In paragraphs 98 to 101, the Company notes several inconsistencies and faulty assumptions in an article1 presented by CISP to support its claims. In the article, Mr. David Burnstein, a DSL industry analyst, ignored some very important costs. Contrary to his assertions, simply upgrading DSLAM ports to GigE is not all that is required. This may explain how the author formulated the incorrect conclusion that Bell Canada’s congestion is minimal and easily solved."

2) In section ES23 they say, "GAS customers generally, including the Applicants, have used and continue to use unsubstantiated allegations regarding the facts to then jump to inappropriate conclusions. The Company understands the Commission’s need to examine the detail of this congestion in order to satisfy itself that there is no unjust discrimination or anti-competitive motive underlying the Company’s actions."

*** The answer to both 1) and 2) above is as follows:

a) Restore, by CRTC order, the status quo existing on September 1, 2007 for all CAIP circuits and Sympatico users.

b) Using independent network specialists with obsevers from the CRTC, Bell, and CAIP present, monitor BAS traffic from both Sympatico and CAIP customer for bandwidth consumed, error rates, congestion, etc... for a period of 1 month.

c)Then change the DSLAM aggregation links to GigE and repeat step b) for another month.

d) Execute other tests as required to build a complete profile of network steady-state conditions and to identify any problem areas and test prospective solution.

e) Publish all findings publicly.

f) Then let Bell make formal submissions to the CRTC for any changes, such submission subject to comment by interested parties.

3) In Section 4.1 (17), they say, "At least one party(10) to this proceeding believed that Sympatico retail Internet and GAS services are offered over separate and distinct networks or at least are isolated from one another. This is not the case. The GAS service offered to wholesale ISPs and the retail Sympatico Internet access service offered by Bell Canada share and have always shared the same access network and therefore will experience the same benefits and the same problems. As discussed in the Interim Answer, wholesale traffic from all of the ISPs who use GAS and Bell Canada’s retail Internet traffic traverse the same central office facilities, the same access network and part of the same backbone network. Figure 1 illustrates how GAS and Bell Sympatico retail traffic transit through the same path/equipment from the DSLAM up to the BAS (and the associated DPI), the point in the network where retail and wholesale traffic is aggregated. The GAS and retail traffic also transits through some of the same backbone network links since the wholesale traffic must be sent to the wholesale equipment/facilities before going to the Internet. It is in fact impossible to distinguish traffic from a retail Sympatico end-user from the traffic of a GAS end-user until the two services reach the BAS."

***With respect to Bell's section 4.1 (17) statement, if ISP and Sympatico traffic has ALWAYS been aggregated as Bell claims, how come no DPI/throttle was present on GAS capacity leased by CAIP members between the date Bell first began throttling Sympatico users in 2007 and the end of March 2008 when Bell began to throttle/DPI CAIP traffic? No discernible impairment to CAIP traffic was present prior to March.

This just goes to show Bell's utter contempt for the CRTC and Bell's customers (CAIP), and to the intelligence of Canadians in Quebec and Ontario.

Nothing short of restoring the network to pre-September 2007 status and then having independent scientific-method studies (ie. change one variable at a time and measure its effect) done by independent experts acceptable to all parties in this proceeding, is required to get to the bottom of the quagmire Bell has created. Then, and only then, can the veracity of ANY of Bell's claims to the CRTC be judged.

Until then all Bell's statements can only be viewed as unsubstantiated BS.

--------------------------

One other thing - Bell claims that they can still say "up to 5Mbps" in their sales pitches because on days when it is exactly 13h 16m 27.37s after new moon, somebody, someplace on their network might get 5Mbps throughput if they live right next door to a CO with brand-new copper to the CO.

What the CRTC should be ordering all Common Carriers & ISP's to advertise is a typical Mbps figure (up/down) in the following way (or something close to this):

Residential ADSL Customers (no FTTN)

8am-5pm 5pm-12am 12am-8am
Weekdays 3300/580 30/1DTx 30/1DTx
Weekends 30/1DTx 30/1DTx 30/1DTx
for the period 2008/01/01 - 2008/03/31

Residential ADSL/2+ Customers (FTTN)

8am-5pm 5pm-12am 12am-8am
Weekdays 7300/980 30/1DTx 30/1DTx
Weekends 30/1DTx 30/1DTx 30/1DTx
for the period 2008/01/01 - 2008/03/31

where
DT == DPI spying & Traffic Throttled
x = C (common carrier) or I (ISP) - to identify who is responsible for the spying/throttle

and if ANY DPI/Throttle occurs during any period then that period MUST also bear the DTx designation.

Something similar for should also be done for business customers.

All data must be recomputed quarterly and used in advertising/all claims of performance no later than the 15th of the month following for the next quarter.

Claims of data rates must reflect the technology used, weighted average distances to CO's of all customers, and any other factors like FTTN or not, cable or xDSL.

Only then can there be any intelligent decisions made by customers about the relative merits of one form of service vs. another.]]> http://www.dslreports.com/forum/remark,20780803 Sat, 12 Jul 2008 14:46:42 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780772 pnjunction :

said by ragingwolf

:

What happened to the pppoe layer bell?

No kidding. I didn't read it but looked at the figures. They show the IP, TCP, application and data layers but negelct to mention that they're ALL inside PPPoE packets they they're supposed to deliver unmolested to their customers/competition.

The fact that I didn't know whether to refer to 3rd-party ISPs as customers or competition is really the underlying issue here. Until this conflict of interest is rectified, Bell is going to do whatever they can to screw us over (no ADSL2, no access to RDSLAMs, and so on).]]> http://www.dslreports.com/forum/remark,20780772 Sat, 12 Jul 2008 14:42:10 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780616 Stewy : "The incorrect premises lead to invalid calculations and comparisons, which only serves to confuse the relevant issues."

I've read about 1/4 of it and I can't believe what I'm reading.]]> http://www.dslreports.com/forum/remark,20780616 Sat, 12 Jul 2008 13:58:04 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780529 Candoo3 : With CAIP's last submission, I know Rocky wouldn't say anything until it actually appeared on the CRTC site. That's why I was trying to figure this one.]]> http://www.dslreports.com/forum/remark,20780529 Sat, 12 Jul 2008 13:32:08 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780515 emerald_b : lets go with pitchforks and torches to bells head office :P and point out the error of their ways LMAO]]> http://www.dslreports.com/forum/remark,20780515 Sat, 12 Jul 2008 13:28:20 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780513 milnoc : When you send a submission to the CRTC, you must also email a copy of the submission to the primary interested parties. One of those parties received Bell's Cc and handed it to the media, which is no problem if it's a document intended for public disclosure.]]> http://www.dslreports.com/forum/remark,20780513 Sat, 12 Jul 2008 13:27:45 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780508 ragingwolf : Ya that document is full of BS, they even reference rogers a bunch of times, when cable and dsl are completely different technologies.

The way they conveniently leave out the physical layer to the network is ridiculous. What happened to the pppoe layer bell? Do they honestly think people are dumb enough to think that an entire connection can't be throttled?

And figure 4 makes me want to laugh. Using an isp like teksavvy, at no point in bell's network are data packets in the form of tcp streams, which makes this representation completely, utterly false.]]> http://www.dslreports.com/forum/remark,20780508 Sat, 12 Jul 2008 13:26:52 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780500 Guspaz : My favourite bit of bullshit:

quote:
It is called “Deep Packet Inspection” because it looks beyond the routing and transport headers, deeper into the application packet headers, to determine the type of application that is communicating, but not the content itself (see figure below).

That's nice, except APPLICATION HEADERS ARE PART OF THE CONTENT ITSELF. As in, they are the payload of the TCP packet. You need to look at the CONTENT to get the application headers.]]> http://www.dslreports.com/forum/remark,20780500 Sat, 12 Jul 2008 13:25:27 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780477 Candoo3 : How would they get it, when it's not posted on the CRTC site yet?]]> http://www.dslreports.com/forum/remark,20780477 Sat, 12 Jul 2008 13:17:01 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780476 emerald_b : My personal favorite part was that throttling promotes innovation instead of hindering it... LMAO Basically... cause we don't have p2p we will come up with new things. These documents are so full of it... just like every other document that bell has put forth to date. I couldnt even read through the whole thing.]]> http://www.dslreports.com/forum/remark,20780476 Sat, 12 Jul 2008 13:16:35 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780311 mazhurg : Meaty reply.

Again, they seem to like to try to confuse GAS and internet services.

Ha yes, "nobody else has it right. Only we know the answers and you must trust us to tell it as it is as we are not about to show why they are wrong. They must prove the negative; not us."

Oh oh, here's cable in the corner. It passes more houses than DSL so it's a usable option! -- What do you mean, no access to remotes? We will connect orders to them, honest if there is anything left after we plug our own sympatico folks

We only look at the applications headers.. honest! (wonder if anyone tried to make a spoofed IE header on port 80 on a P2P stream)...

Lots more in there. Rehashing the same old excuses, and easy to pick apart. Perhaps Bell thinks that by putting out a massive DSL dazzle they may bemuse the readers?

bah!]]> http://www.dslreports.com/forum/remark,20780311 Sat, 12 Jul 2008 12:34:25 EDT Re: Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780310 anon : How full of shit can they be? and how stupid do they expect everyone to be?

"Bell respects the privacy of its customers

ES17 The Company’s use of DPI technology as part of its traffic management practices is such that the actual contents of the communication exchange are not examined. Rather, only the protocol headers are examined and the DPI equipment does not retain the information reviewed in the packet headers."

Seriously? You buy this?]]> http://www.dslreports.com/forum/remark,20780310 Sat, 12 Jul 2008 12:34:22 EDT Bells NEW July 11th CRTC Submission http://www.dslreports.com/forum/remark,20780127 anon : Full article and full Bell CRTC submission found at:

»www.p2pnet.net/story/16364

“In accordance with the Commission staff letter of 19 June 2008 and Bell Canada’s (or the Company’s) letter of 9 July 2008, the Company is hereby filing its Answer to the CAIP (Canadian Association of Internet Providers) Application dated 3 April 2008.”

That’s Bell Canada’s Mirko Mr 5% Bibic to Canadian Radio-Television and Telecommunications Commission secretary general Robert A. Morin.

Bell admits it’s, “also in receipt” of 25 comments from such as Google and Per Vices, the company which also provided a way for people to get around Bell’s bandwidth throttling “traffic management” actions. The complete list is in the document below.

Dear Mr Morin, it says >>>

Subject: Application requesting certain orders directing Bell Canada to cease and desist from “throttling” its wholesale ADSL Access Services

In accordance with the Commission staff letter of 19 June 2008 and Bell Canada’s (or the Company’s) letter of 9 July 2008, the Company is hereby filing its Answer to the CAIP Application dated 3 April 2008.

Sent in yesterday, it’s a day late —- Bell asked for, and was granted, an extension —- and considerably more than the dollar short. With a little luck, we’ll be able to give you CAIP’s respoinse on Monday or Tuesday.

But here it is in full, including an interesting dissertation on deep packet inspection (DPI).

Continues at: »www.p2pnet.net/story/16364]]> http://www.dslreports.com/forum/remark,20780127 Sat, 12 Jul 2008 11:45:35 EDT