Jay Daley, an Internet address registrar in New Zealand, offers an interesting “net-head view” of Internet traffic management:

Traffic management by definition is about protocols and pipes, about balancing services at the protocol level within the resource constraint of the transmission media. So a goal of traffic management might be to ensure that a real time service like VoIP is delivered well, or it might be to ensure that other real time services like IPTV do not saturate a link.

On the face of it this might seem entirely reasonable. It is apparently non-discriminatory as it works at the protocol level and it seems to be geared towards providing a better service for customers.

However, there are strong arguments against this form of traffic management based on the end-to-end principle, namely that true innovation has demonstrably come from end points managing the traffic themselves and the moment that someone starts to manage the traffic in the middle the protocols get ‘frozen’ and innovation stops or diverts. What if ISPs had managed traffic to strongly support HTTP just a few years ago, would YouTube or Skype ever have got off the ground? Unfortunately these arguments take a long time to recognise and internalise, as evidenced by the age of their proponents (Vint Cerf et al), and new generations are unaware of their impact.

Like many ideologically-driven viewpoints, this one is less than consistent with the facts. Daley should familiarize himself with RFC 2475, “An Architecture for Differentiated Services.” The RFC says:

This document defines an architecture for implementing scalable service differentiation in the Internet. A “Service” defines some significant characteristics of packet transmission in one direction across a set of one or more paths within a network. These characteristics may be specified in quantitative or statistical terms of throughput, delay, jitter, and/or loss, or may otherwise be specified in terms of some relative priority of access to network resources. Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service.

DiffServ doesn’t violate any principles of Internet architecture, or it would not have been approved by the IETF and implemented in all IP routers of any note. Since DiffServ is in conflict with Mr. Daley’s understanding of the Internet, I’ll have to take the IETF’s side rather than his. The IETF represents the true “net-heads” of the world. The correct and productive way to manage traffic is for the endpoints and the network to do it cooperatively. There is no black-and-white dichotomy here.

One of the means by which we can achieve meaningful Internet openness – full support for all applications – is to actively manage traffic as RFC 2475 describes. This behavior is “non-neutral” but it’s “pro-openness.” This is a place where the common understanding between net-heads and other tribes is not only possible, but necessary.