Network Policies Should Be Open, Not Neutral

Opinion: The BitTorrent-Comcast dispute is a great example of how net neutrality advocates get out of control.

So it turns out that Comcast is slowing down BitTorrent traffic. The term often used is "rate-limiting."

In fact there are some claims that Comcast is flat-out blocking the service, but it says it is only rate-limiting, and I believe it. I have had readers contact me to say that they run BitTorrent on Comcast and purposely rate-limit it themselves in order to maintain a low profile. Comcast leaves them alone. Makes sense to me, in the sense that I believe that rate-limiting is basically what's going on here.

I have a very hard time liking the big telecom companies, including Comcast, but I'm somewhat sympathetic to them with respect to this issue. Too much of the rhetoric on network neutrality is ideological nonsense uninformed by technical expertise. What is the argument against rate-limiting?

28571.gif

BitTorrent's creators agreed to ban the trading of unauthorized copies of protected movie content. Click here to read more.

In fact, rate-limiting is a common-sense practice with a service like BitTorrent, which can create a constant baseline of traffic across a network. Worse, it creates upstream traffic in networks that are designed with the assumption that traffic is overwhelmingly downstream.

Do Comcast customers have the "right" to use their pipe for whatever they please to its full advertised capacity? There are plenty of reasons why different applications on a network should be treated differently.

As I've already mentioned, a service that can clog bandwidth for others—and cable bandwidth is to a degree shared with immediate neighbors—is a good candidate. E-mail sending is another good candidate. One way you can control the ability of bots to be used for spam is to rate-limit SMTP; in other words, limit the amount of e-mail that can be sent from an individual system on the network. I don't know if Comcast is doing this, but if it does I applaud it. Sending 100 messages in an hour is probably a lot for a regular user, but it's small potatoes for a bot.

And then there's just the whole banning of services. Comcast's consumer ISP service might not permit you to set up a Web server on your system, for example. If it blocked inbound port 80 traffic, would that be evil? OK, here I'm not so sure. On the one hand, if you're violating the terms of service why shouldn't it be able to stop you? On the other hand, not every little Web server is abusive of bandwidth on the network.

108654.jpg

Many years ago I noticed that a lot of Web hosting services advertised plans with "unlimited bandwidth," while others would cap your bandwidth at some number, generally in the low single gigabytes per month. I dug and pressed the companies and got some to admit, not that it was anywhere in their agreements, that if you really used a hell of a lot of bandwidth they would "help you to use less." I never got a straight answer, but I think this means they find some reason to dump you or make life unpleasant for you until you either leave or pony up for a more expensive plan. The problem here isn't limiting bandwidth, it's dishonesty and a failure to disclose procedures.

That's why, in the end, I think the most important rule for network providers like Comcast is disclosure, not some strange form of network egalitarianism. If it's throttling down BitTorrent it should be volunteering the fact and do it in a place where people can look up current rules for such things. And it should do so in detail, even to the extent of saying which network segments have this policy, assuming it's not global to the Comcast network. This is a rule I could support from the FCC.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

More from Larry Seltzer

28571.gif

Check out eWEEK.com's Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's blog Cheap Hack