Bandwidth shaping with Bell
It's funny how people are jumping on the bandwidth throttling bandwagon with Bell. And I would be one of them if I was one of their clients. I'm not, however, blaming them in the sense that everyone seems to do.
If every user were using their system sporadically, sometimes heavily, sometimes casually, there would never be any problem. The problem arises when some clients are constantly using their connections 24/7.
If a provider was advertising 10 megabits per second bandwidth for all their clients, and if they were purchasing upstream bandwidth for 10 megabits per second per client, their costs would be prohibitive for a mostly unused upstream pipe. I know I am using maybe 5% of the potential of my connection everyday. I know most users are at that level, but I also know some users are constantly uploading and downloading stuff, using 100% of their potential connection.
This is the same problem with plumbing. If every home were using 100% of their drainage system at the same time, there would be a giant problem for sanitation services and there would be overflows everywhere. What you do is make an estimated guess and you buy what's required, adding some more leeway.
Looking at it this way, one can only say to Bell "you saw too large, and don't have enough upstream to keep all users happy". Too bad for them, and customers shouldn't be penalized.
However, when that limit is reached, how do you survive. You can either take drastic measures to make certain this limit is not reached ever (like they are doing, by capping users at their peak hours)… or you can add prioritization for services and users.
The former (throttling) has the advantage of being easy to implement, it's fairly inexpensive and reduces the quantity of bandwidth required with their upstream providers, making certain they are not obligated to pay premium for the excess of bandwidth. This can be graphically represented as a bottleneck with a small filter before, making the big bits passing through at very low speed, while keeping the smaller bits churning along all the time. The bottleneck itself is not the problem anymore, it's the filter in the bottle. All good reasons.
The latter (shaping) is harder to implement, only occurs in crisis management, and every people will see some kind of slowdown instead of a few people. A fair system is harder to get with this kind of bottleneck. This can be represented as a bottleneck shaped to make things go through at different speeds when it's full. It's harder to make the filter right, but then, no one is left in the cold.
I do believe all such systems should implement proper bandwidth shaping anyways, and what's remaining is to see how much utilization they are reaching at peak hours. A 100% utilization is perfect, if it reaches 120%, a proper shaping algorithm is adequate. If it reaches 200%, then they seriously have to up their ante a little bit, and I would see why they would use throttling algorithms, as a shaping system is clearly not good enough anymore.
The future will bring more and more bandwidth-hungry usages, and such throttling will only angry the customers, it's merely a temporary solution. In the meantime, they should try to find a way to make things happen correctly, even if it means bringing twelve more OC-768 from the backbone, because not only is it temporary, but it has very negative impact on their image.
