Network Policies Should Be Open, Not Neutral

By Larry Seltzer  |  Posted 2007-11-06 Print this article Print

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?

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.

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 Check out's Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at Security Center Editor Larry Seltzer's blog Cheap Hack
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel