But I still say, if the CAIP is claiming Bell is violating the terms of their contract, a court of law would be a better place.
However, we'll make do with what we've got.
The above link is a letter from the CRTC to Bell and the CAIP asking them to prove their claims. Simply, for the CAIP to prove that Bell is unjustly throttling their customers content, and Bell to prove that it is managing its network and not picking on select customers.
I find it interesting that Bell has to provide very detailed information to 9 questions, and that the CAIP has to only answer 5, and those questions are less stringent. It seems that the onus is on the accused to prove their defense while the burden of proof for the accusation is much less. I would think a court of law would not allow this inequity.
I find some of the questions show that the CRTC doesn't completely understand the nuance of networks and bandwidth. So, I am going to put on my network admin hat and go through the questions, highlighting concerns I have. This is probably going to be quite long and involved, so grab a beer and free some time. Or close this posting now and find something less mind numbingly boring.
Question 1 asks Bell to clarify its statement that 5% of users were generating 60% of total traffic and 60% of that traffic was P2P traffic, and how did they arrive at that conclusion.
That's a fair question. I would point out that when managing network bandwidth, and ensuring uptime, average usage as asked in Subsection 1b) does not mean much. You can have 10% network utilization over an hour, but if the network hits 100% for 10 minutes, you have congestion during those 10 minutes. So the average over the hour is irrelevant, as for 10 minutes the network was congested, where traffic was failing to get through. If that happens, everything dies, P2P, video streaming, e-mail, etc. The only traffic getting through is what is causing the congestion (so if the 5% BitTorrent users spiked during that 10 minutes, the other 95% of users would be unable to use the network for that duration. The fact that during the other 50 minutes, the network was fine, is not really relevant).
Subsection 1c) is useless as well. Any network is only as fast as its slowest point. On the Internet, that is generally at the edge, closest to the users. So if an edge router is congested, but the core is clear, all customers on that edge router are experiencing difficulties, regardless of the fact that the core has gobs of bandwidth available. It works the same way if a core router is congested, but each edge router is clear. Congestion at any point on the path of a network packet will grind all traffic along that path to a halt. Its like water through a hose, pinch that hose at any point and you get a trickle of water out the end.
Question 2 starts off reasonably as well. Again asking for clarification of where the congestion happens. 2c) is another idiotic one. When managing traffic, you have two options, block it altogether or shape it (there are many types of shaping). There are no other options, so asking what other options were considered, is like asking why we breathe oxygen, and not radon gas. The part asking Bell to outline what conditions it would augment capacity is ludicrous. Bell is under no obligation to expand their network to meet customer expectations. It might be good business practice, but if Bell decided it wanted to provide crappy service, it is well within its rights to do so (to a point, you can't lie about your capabilities to your customers or stop meeting contract provisions). It would go bankrupt fairly quickly, but that's beside the point. You are under no obligations to provide more service than what the contract for service lays out.
Question 2d) is fair, but tricky. Network devices can be congested without a lot of traffic going through. In hacking parlance, its known as a DoS, or Denial of Service situation. You flood the capabilities of the router on some other aspect, other than total traffic. The irony is that network bandwidth is at or near 0% utilization, but no traffic gets through. DoS can happen with poorly formed legitimate traffic, it doesn't require a hacker being malicious. This is an unlikely cause, but not improbable one.
2e) is restating 1b) in another way. Again, long term averages don't matter. Its when periods of congestion (which is what Bell is contending is happening) that the traffic mix matters.
Question 3 gets to the meat of the matter, and it is here that Bell's case will succeed or fail. Though asking Bell to total traffic from peak periods with traffic from non peak periods is bizarre. Its like asking me what speed I was driving at 8am on my drive to work, and at 5pm on my drive home, and then adding them..... That number is worse than useless.
Question 7 is a head scratcher. They ask if Bell's DPI technology can identify the sender or intended recipient of a packet. Uhhh, you don't need DPI to do that. Every single packet that goes across the internet carries the IP addresses of the sender and the recipient. It is publicly available in the header of the packet. I will assume that this question isn't completely moronic, and is asking if any identifiable information could be found in the data section of the packet (such as e-mail address, username, password etc.) But even that is still somewhat moronic. DPI traffic management products don't store the information they find, they just use it to enact a rule. No human ever looks at it, its all done by a computer processor. And anyway, this is why you should encrypt sensitive information, because if you don't your data is being sent in the clear, and anyone can read it. Its not Bell you should be worried about, its the kid next door voraciously reading up on hacking techniques.
In all reality, it boils down to this. Bell only should have to prove that congestion happens (whether frequently or occasionally), and that P2P traffic is causing it. If they can prove that, everything else is moot.