The popular press and news feeds have been full of stories about advocates of "net neutrality" testifying to congressional committees, lobbying the federal government and railing against the big ISPs over the past while. It's hard to decide whether those arguing in favor of net neutrality are foolish, ignorant or disingenuous.
Let's begin with some definitions. When someone demands "net neutrality", they usually mean that the network must not discriminate between applications being carried in IP packets; that identical transmission characteristics (throughput, delay, number of errors, etc.) are to be provided for all packets regardless of what is being carried in them. They claim (correctly) that this is not the case at present, that the network service provider is "throttling" certain applications, "slowing down" or "shaping" traffic and that this, in their opinion, must stop. They sound the rallying cry "the net should be free".
What a load of hogwash. But are these arguments foolish, ignorant or disingenuous? Hard to decide:
Foolish: The Internet Protocol, IP, does not provide any guarantees. There is no guarantee that a packet will be transmitted, when that might happen, how often that might happen, or how long it will take to reach its destination. Nothing. Nada. Zip. Bupkes. Not a sausage. In IP, there is even no way for a device to which a packet is proposed to be transmitted to report back whether it got the packet, sent it onward or what. Nothing. This is called a connectionless, unreliable network service.
Here's the foolish part: if we are to use an IP network for real-time, delay- and loss-sensitive applications like phone calls and watching television, implementing Quality of Service (QoS) mechanisms to guarantee transmission characteristics is essential... otherwise, there is no way to guarantee quality of the reconstructed signal at the destination. Television pictures would freeze, then jump forward, sometimes have block distortion effects and other artifacts. Clicks, pops, muting, breaking up and similar effects would be heard on phone calls. Saying that we should not take measures to prevent this is foolish. All phone calls and television will happen over IP in the future.
Guaranteeing transmission characteristics is easy if there is no traffic on the network. The difficulty happens when there is contention, either for the use of an outgoing circuit at a network device, or contention for the use of the processor in a network device... and this contention is going to have to be resolved in favor of real-time, delay- and loss-sensitive applications like phone calls and watching television to the detriment of applications that are less sensitive to delay and packet loss like web page downloads, email and file transfers.
Here's the ignorant part: IP network service providers are not operating IP networks as such. They are operating MPLS networks. MPLS is the IP world's implementation of virtual circuits, where we define classes of traffic and pre-determine routes and relative priorities for the classes. A class of traffic is a flow of packets going from the same place to the same place and should experience the same transmission characteristics. We establish multiple classes going from the same place, to the same place but each with a different specified transmission characteristic. This way, the class indicates both the route, and the relative priority of the packet.
At the entrance to the MPLS network, the first MPLS router analyzes the packet to determine what among other things what application is being carried in the packet (voice, video, email, web page, etc.) to determine class it belongs to, and when it decides, pastes a label on the front of the IP packet with a number indicating the class. Intermediate Label Switching Routers in the network do not examine the IP address, they use the number in the label to determine the route and relative priority of the packet. This is how Quality of Service is implemented on packet networks. It's ignorant for these supposedly-well-informed net-neutrality advocates to talk about "IP" networks when they are actually MPLS networks, and one of the main reasons for having implemented MPLS is to be able to prioritize packets based on the application being carried inside them as a mechanism for guaranteeing quality.
"Disingenuous" is usually defined as being not straightforward or candid; giving a false appearance of frankness; being insincere. Here's the disingenuous part: the application that is being "throttled" or traffic that is being "shaped" or "slowed" (the correct term is "policed") is piracy. Theft. In most places, illegal activity. Downloading illegal copies of copyrighted material. Stealing.
The category of application being policed is peer-to-peer file sharing. Examples of this kind of application include bittorrent and limewire. These applications are used 99.999% of the time to download illegally-made copies of Hollywood movies, training videos, software, ebooks, audio books and other copyrighted works without paying the author or publisher. Take a look at one of the bittorrent sites like piratebay dot org and click "browse torrents" to see for yourself. Yes, the advocates can describe how bittorrent was designed for the legitimate delivery of software, and trot out one example of a legitimate use... but this is definitely a case where the exception proves the rule. 99.999% of the use is theft.
In English common law there is a maxim: you can't come to court with dirty hands; in other words, you can't ask for justice if you yourself are obviously breaking the rules. The people whose traffic is being policed have filthy dirty hands. Methinks the lady doth protest too much.
The technical topics in this article are covered in:
Course 101 Telecom, Datacom and Networking for Non-Engineers,
Chapter 3-3 "Bandwidth-On-Demand: Packet Network Services" and following
Course 110 IP, VoIP and MPLS for the Non-Engineering Professional
Chapter 14. Quality of Service in the IP World: NET NON -NEUTRALITY
Video Course DVD-4 "Understanding Networking 1"
Part 3 WANs - Bandwidth On Demand: Packet Network Services
Telecom 101 Textbook
Chapter 18 Bandwidth on Demand