Bell must not only stop throttling the independants, but their data MUST NOT flow through those boxes that can still collect personnal usage data.

Consider Sympatico’s telemarketing efforts. They could be targetted at potential customers whose usage patterns with other ISPs would be well within the restricted Sympatico offerings. (for instance, if you are with Teksavvy and using only 30 gigs per month, Bell could offer you 60gigs and tell you that your usage wouldn’t exceed this). And if you use 100 gigs per month, Bell wouldn’t bother calling you since they know your usage does not ball within the Synmpatico offering.

Similarly, if you download a lot of P2P unthrottled, then Sympatico wouldn’t call you because they know theyr offering essentially blocks BitTorrent (without physically blocking it).

CAIP also failed to ask how Bell came to decide how “30KB/s” was to be the limit (CAIP also fails to mention that throughput is more between 20 and 30 than at 30 when throttling is in effect).

And CAIP could have mentioned that while 30KB/s may have been considered “high speed” 10 years ago, it is no longer the case and that the service shoudl be repriced as a non-high-speed service if Bell insists on continued throttling.

There were a few packets that did have the “RESET” bit set, but those came from ISPs known to throttle. Bell’s Ellacoya satanic boxes seem to be programmed to simply drop packets alltogether (over 20% of packets once it has determined it doesn’t like you.)

The Sandvine boxes used by Compcast do use the RESET bit mechanism. This bit is used to signal the other end that this node has no knowledge of this TCP connection. Consider a computer that crashes while doing a data transfer and reboots quickly. The sender will continue to be sending to that IP and port number, but the rebooted computer will have no knowledge of that TCP connection and will respond with a packet containing the RESET bit. This tells the sender that this TCP connection/session no longer exists.

So, by inserting the reset bit in packets, Sanvine effectively closes connections before they have transfered their data and forces the peer to re-establish new connections. This is quite different from Bell just dropping packets alltogether. This is an accepted network management practice ***FOR AN IP NETWORK*** and **FOR TEMPORARY SURGES***. Bell does it consistently for 10 hours a day, so that is clearly abusive.

They stole my “service management” without attribution…. I am mad

I am disapointed that they did not clearly state that Bell Canada has invented the non-existent concept of “application header”. Bell used this to avoid admitting it is looking at the payload of a packet. By not being specific on Bell using non-existent “application header”, it leaves the door opened for the CRTC to belive Bell’s fictional existance of application headers and agree that Bell isn’t looking into the payload. CAIP could have asked the CRTC to require Bell Canada to provide it with “application header” formats and provide which RFC defines those non-existant headers.

The document relies almost exclusively on the CRTC judging there is no congestion problem.

However, because of changing internet usage patterns, the demand on networks WILL grow. And if there is no congestion today, there might be tomorrow, and this leaves the door opened for the CRTC to claim that even though there is no real problem today, Bell was acting pro-actively to manage the huge growth that will happen when that 5% grows to 50% and then to 75%. Heck, even grand mothers and aunts will eventually want to download programs and movies on the net.

CAIP should have discussed this and solved the problem with a simple: as usage patterns changes, it forces ISPs to buy more AHSSPI bandwidth and thus Bell Canada gets more money and can pay for the network upgrades needed to deliver the purchased bandwidth.

It is also a shame that because they focused on “there is no congestion”, they could not argue the HUGE gaping hole Bell left for them: the fact that the aggregation capacity grew by only a small fraction compared to DSLAM speeds and backbone speeds. Since the independants are paying for their bandwithd, Bell Canada should have been upgrading the DSLAM-BAS links at a faster pace.

CAIP could have then argued that it was unethical for Bell Canada to raise DSLAM speeds offered to Sympatico customers when the DSLAM-BAS links had nowhere near the same capacity.

Lets just pray the CRTC doesn’t start its ruling with “while CAIP is right that there is no real congestion problem at this point, there might be in the future and Bell is right in installing this equipment proactively. It was a BIG risk for CAIP to rely solely on the “there is no congestion” argument since it prevented them from discussing many aspects (since it woudl be tantamount to admitting to a potential congestion problem).

A few things were repeated in the document. Been there done that. It took me a number of days of rewriting the first 5 pages of my submission in order to condense, re-organise and remove duplication of arguments. So handling a 91 page document to condense it would have taken much longer time.

In fact CAIP also missed a possible good argumnent: When mentioning Bell admits that since throttling, other types of applicatiosn started to grow in bandwithd use, CAIP could have argued many things: How long before Bell throttles those without telling anyone ? And more importantly: DPI is just a short term solution that prevents use of the internet. A real long term approach is for Bell to grow capacity to match usage patterns and especially match the bandwidth that is purchased and paid for by the ISPs.

Another issue which CAIP failed to address is that some ISPs may have customers on contract and that at the time of the signing, the ISP had promised no throttling, and Bell’s actions are putting the ISP in a breach of contract.

What is also interesting is that the final Bell submission (86) pages was obviously started a long time ago since much text was common with previous documents, and only here and there did Bell add more stuff based on actual interested party submissions.

Rocky and Kristen and any others involved in the all-nighters this would have required deserve a couple of good night’s sleep. Despite the tone of my above comments, I know how long and difficult it is to organise/write such a document.

What is a real shame is that the CRTC is very much a “submit your documents, and we’ll decide later” process instead of having a real debate in a round table with the CRTC asking questions to both sides and then providing preliminary rulings to help steer the debate.
(for instance, if the CRTC had, very early on, indicated that it knew that Bell was looking into the packet payloads, I wouldn’t have had to spend so much time proving it in my document.

Nice Job putting this up for everyone Jon.

I appreciate all the effort you put in to keep the public informed.

Your site in on my daily must reads for a reason.