Great Myths of Networking, Part 1

The FCC has closed its comments period on the bogus net neutrality issue. I’d like to see them throw the comments in the trash because it’s an idiotic issue manufactured for nefarious reasons. I’ve been enraged by the network neutrality movement because it thrives on extreme misstatements of network engineering principles. I create network architectures and protocols for a living, so this is a subject matter that I’ve got cold. You’re probably using some technologies that I had a hand in designing, standardizing, and implementing when nobody else knew what they were: Ethernet over twisted-pair wiring, the WiFi MAC protocol, and elements of the TCP/IP stack.

So this post will be the first in a series to list some of the egregious errors of fact that have emerged around the net neutrality debate, in the interest of correcting some major misunderstandings.

Myth: Network bandwidth is abundant and free, or nearly free.

One argument that I’ve heard from several quarters goes like this:

Once the cables and routers are in place, the operational cost of the network is virtually nil, just the electricity and maybe a little labor to replace stuff that breaks. So it makes no difference if a user sends or receives a little bit of stuff or a lot of stuff, it’s all the same.

Nothing could be further from the truth. The assumption here is that our requirement for network bandwidth is constant, so it simply takes one build-out to satisfy us. You have to do nothing more than remember how you’ve personally used the Internet over the past several years to see how silly this is. Bandwidth is an elastic resource, but user demand for it always goes up. While it may have been sufficient some years ago for your network connection to handle a few e-mails, it soon because necessary for it to handle basic web pages, then graphics-intensive web pages, and then Skype, BitTorrent, and whatever’s to follow, such as Joost.

Fact: Demand for bandwidth always increases, so bandwidth is neither abundant nor cheap for long.

More to follow.

Leave a Reply

Your email address will not be published. Required fields are marked *