Neutral traffic management
Maintaining a network is hard: too much capacity, and you’ve wasted money. Too little, and customers complain. It’s a balancing act, and a relatively small proportion of your users can tip the scales in a particular direction by making heavier-than-normal use.
So, how do you deal with it?
One way, which has become popular of late (and is the way corporate networks tend to deal with it), is to throttle or block specific applications, either based on simplistic rules—i.e., filtering based upon protocol and port—or through the use of deep-packet inspection technology which can take a guess at the kind of traffic it’s seeing thanks to complex fingerprinting rules.
This has three big problems, depending upon who you are and your point of view.
First, it’s by no means infallible. If it’s modern peer-to-peer traffic, it may well be designed to evade detection, so the filtering won’t actually be that effective.
Second, it’s by no means infallible. Yes, I’m repeating myself, but that’s because there’s a flip side to the same coin: just as traffic you want to filter goes unnoticed, perfectly reasonable traffic can get snared and becomes a “false positive”—in other words, it gets filtered even though it’s something completely different to the traffic you intended to filter.
Third, if a user is paying you for Internet access, with no specification that this is just limited to web and e-mail traffic, it’s reasonable to expect that all packets are, in effect, treated equally. In other words, you’re just a (paid) neutral carrier.
The management of many ISPs claim that per-protocol traffic management is necessary to maintain that balance between usage and capacity, but that’s not strictly true. If a group of people started using up significantly more than average bandwidth via HTTP, you wouldn’t start throttling HTTP—you wouldn’t see your customers for dust.
There’s an alternative, though, and it’s one which lets everybody win all at once: ISPs get even more effective traffic management, users get control, and regulators get a neutral, level, playing-field.
Not only that, but it’s exceedingly simple:
When a user starts using disproportionate amounts of bandwidth, you throttle back their whole connection—not massively, but enough to drag them back near the mean. You don’t need to touch latency, either, just the available bandwidth. You can do this at any time, or just at specific times of the day (“peak time”). All you need to do is make sure that this throttling is responsive enough to revert to normal once they stop.
The user, on the other hand, has a choice: stop using the bandwidth-intensive application, put up with a slow connection, or prioritise the traffic so that the slower connection doesn’t impact the things they expect to be responsive (such as ordinary web browsing).
Perhaps they’re downloading a multi-DVD set of Linux packages and want it to arrive as quickly as possible, but don’t want it to slow down GMail? As an ISP, you don’t need that knowledge: you just pare back the connection and let them make the choice.
Almost every router sold within the last 5-10 years supports QoS—short for “Quality of Service”, a fancy name for what would be more usefully just called “prioritisation”. QoS settings lets a user tell their router that they want access to their e-mail to be as fast as possible, but that they don’t care about anything else. Or perhaps those Linux packages coming down via BitTorrent are actually most important because they’re building a new machine this afternoon.
The kicker is this: connection-wide bandwidth reduction is child’s play compared to deep packet inspection-triggered protocol throttling, and it doesn’t attempt to second-guess the user’s intentions. There are no false-positives, nor false-negatives.
Even better that, though, it’s more effective at maintaining the balancing act which makes up your network, and it gives regulators absolutely nothing to complain about.
