Net neutrality is a bunch of different issues that get incorrectly lumped together.
The first issue is prioritizing traffic based on endpoints. An example of that is where ISP A contacts example.com and offers to speed up its customers’ connections to example.com, in exchange for money. The problem is that example.com isn’t a customer of ISP A, but of a competing ISP. The full graph of business relationships is
The end user pays ISP A to use its portion of the network, example.com pays ISP B to use its portion of the network, and they split the cost of the link that connects the two ISP’s networks. If ISP A goes after example.com, then it’s trying to bill its competitor’s customers. This is probably in violation of its peering agreement with ISP B, and it would cause a total nightmare for anyone trying to run a web site, as they would have to negotiate with every ISP instead of just the one they get their connectivity from. So with respect to traffic endpoints, net neutrality is extremely important.
The second issue is prioritizing traffic based on type. This is reasonable and sometimes necessary, because some protocols such as telephony only use a small amount of bandwidth but are badly disrupted if they don’t get any for a fraction of a second, while other protocols like ftp use tons of bandwidth but can be paused for several seconds without disrupting anything. The problem there is that protocol prioritization is more often used as a cover story for anti-competitive behavior; eg, ISP A wants to drive ISP B out of business, so they configure their network so that ISP A’s expensive VoIP service gets high priority, ISP B’s VoIP service gets low priority, and everything else gets medium priority. You end up with telephone companies setting the priority on VoIP services that directly compete with their own voice services, cable television setting the priority on streaming video services that directly compete with their own television services, and so on.
Net neutrality is a bunch of different issues that get incorrectly lumped together.
The first issue is prioritizing traffic based on endpoints. An example of that is where ISP A contacts example.com and offers to speed up its customers’ connections to example.com, in exchange for money. The problem is that example.com isn’t a customer of ISP A, but of a competing ISP. The full graph of business relationships is
End user—ISP A—ISP B—example.com
The end user pays ISP A to use its portion of the network, example.com pays ISP B to use its portion of the network, and they split the cost of the link that connects the two ISP’s networks. If ISP A goes after example.com, then it’s trying to bill its competitor’s customers. This is probably in violation of its peering agreement with ISP B, and it would cause a total nightmare for anyone trying to run a web site, as they would have to negotiate with every ISP instead of just the one they get their connectivity from. So with respect to traffic endpoints, net neutrality is extremely important.
The second issue is prioritizing traffic based on type. This is reasonable and sometimes necessary, because some protocols such as telephony only use a small amount of bandwidth but are badly disrupted if they don’t get any for a fraction of a second, while other protocols like ftp use tons of bandwidth but can be paused for several seconds without disrupting anything. The problem there is that protocol prioritization is more often used as a cover story for anti-competitive behavior; eg, ISP A wants to drive ISP B out of business, so they configure their network so that ISP A’s expensive VoIP service gets high priority, ISP B’s VoIP service gets low priority, and everything else gets medium priority. You end up with telephone companies setting the priority on VoIP services that directly compete with their own voice services, cable television setting the priority on streaming video services that directly compete with their own television services, and so on.