[Infowarrior] - Did Internet founders foresee future filled with paid, prioritized traffic?

[Richard Forno]

Did Internet founders foresee future filled with paid, prioritized traffic?

By Matthew Lasar | Last updated about 3 hours ago
       
http://arstechnica.com/telecom/news/2010/09/did-internet-founders-foresee-future-filled-with-paid-prioritized-traffic.ars

AT&T has set off yet another net neutrality firestorm, claiming that a crucial Internet standards-making body gave its blessing to ISP priority access deals way back at the beginning of it all. In the late 1990s, the Internet Engineering Task Force (IETF) added the "DiffServ" field to Internet Protocol (IP), AT&T insists, "to facilitate paid prioritization as a means for encouraging the further growth and development of the Internet."

Paid priority access "was fully contemplated" and even "expressly contemplated" by the IETF decades ago, the telco has told the Federal Communications Commission, and is "fully consistent" with that body's standards-making discussions.

Baloney, insists the IETF's current chairman. "AT&T's characterization is misleading," Russ Housley told National Journal  several days later. "IETF prioritization technology is geared toward letting network users indicate how they want network providers to handle their traffic, and there is no implication in the IETF about payment based on any prioritization."

Obviously this is a hot historical debate, given that limiting content prioritization is central to the FCC's proposed net neutrality rules, as well as the Google/Verizon open Internet manifesto. AT&T and various reform groups have been going at it for weeks over the issue.

So who is right here? And what is this DiffServ talk anyway?

One protocol to rule them all

When most people think of inventing, they usually conjure up big corporate labs with lots of equipment or, in earlier times, tinkerers at their basement tables. One of the more interesting aspects of Internet history is how much of the 'Net was invented at meetings—literally people in nice little rooms sitting around talking, with someone taking notes.

By 1973, some of the creators of the ARPANET held one of these gatherings at Stanford University, and they were worried. There were already 15 "nodes" in the network, mostly university based extensions. Each was busy experimenting with their own little terminal computer offshoot subnetworks. How would this ever-expanding octopus retain a single, coherent nervous system?

The answer they came up with was TCP—Transfer Control Protocol. The P-word is borrowed from diplomacy. Protocols are basically agreed upon standards for how information will be exchanged. TCP would be the master—adopted by all ARPANET connectors.

As summarized by Internet historian Janet Abbate, TCP "did much more than just set up a connection between two hosts: it verified the safe arrival of packets using acknowledgements, compensated for errors by re-transmitting lost or damaged packets, and"—pay attention—"controlled the rate of data flow between the hosts by limiting the number of packets in transit."

As the discussions continued through 1978, critics argued that TCP as originally envisioned required all portions of the network to do too much work. So they added another: Internet Protocol, which would just move packets from node to node—all of them labeled with numeric IP addresses.

IP functions would be performed on packet routing "gateway" machines. TCP would perform the verification tasks on hosts. Together, they would be known as TCP/IP.

"We wanted to have a common protocol and a common address space so that you couldn't tell, to first order, that you were actually talking through all these different kinds of nets," recalled Internet pioneer Vinton Cerf.

The primary goal

As the Internet exploded with users and networks, the future of TCP/IP and the challenge of handling Internet flows became part of the same conversation. By 1998, IETF engineers were pondering generally agreed upon standards for prioritizing IP traffic. In 1998 a small group of Cisco engineers put out two IETF Request for Comments documents (RFC 2474 and RFC 2475) which suggested adding a new feature to the IP protocol for the purpose of "Differentiated Services" or DiffServ.

"The primary goal of differentiated services is to allow different levels of service to be provided for traffic streams on a common network infrastructure," RFC 2474 explained. "A variety of techniques may be used to achieve this, but the end result will be that some packets receive different (e.g., better) service than others."

This was a concern from the get-go. "The history of the Internet has been one of continuous growth in the number of hosts," RFC 2475 added, "the number and variety of applications, and the capacity of the network infrastructure, and this growth is expected to continue for the foreseeable future. A scalable architecture for service differentiation must be able to accommodate this continued growth."

The document proposed to introduce this by replacing an old IP header data field with a new one. Out the door would go an earlier field, known as the Type of Service (TOS) and proposed by RFC 2474, and in would come DS, or "DiffServ" as it came to be called. The latter would facilitate software that could grab "codepoint" data to evaluate the "packet experiences at each node," then prioritize.

How would DiffServ users decide how to use the new field? Not our department, these RFC writers explained.

"The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document," they noted early on in RFC 2474.

But the docs did acknowledge that DiffServ could be used for a variety of purposes.

"Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service," 2475 explained.

Who is responsible?

That last sentence is pretty much AT&T's historical gold mine, but was that reference to "differentiated pricing" a recommendation or just an observation? And what did these RFC writers mean by it? And for whom?

For business enterprise customers whose users want certain kinds of traffic fast-tracked within an Intranet? Or did they mean AT&T telling The New York Times that if the newspaper pays the carrier a regular fee, the telco will make sure that its DSL and U-Verse customers can access the nytimes.com online edition more quickly and easily?

Beyond the quote, AT&T's missive to the FCC doesn't offer much, so it keeps tunneling back into the past, as if adding more words will bolster the point. AT&T notes that RFC 2474 cited RFC 791, legendary Internet architect John Postel's Internet Protocol specification guide, which outlined IP's Type of Service parameters.

"If the actual use of these precedence designations is of concern to a particular network," RFC 791 explained, "it is the responsibility of that network to control the access to, and use of, those precedence designations."

And in the DiffServ environment, service providers "are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives," 2474 adds.

Misguided projections

But it's unclear how telling system administrators that they were free to use TOS or DiffServ as they wished indicates what these RFC writers thought about generating money from Internet services. That's the point that the Center for Democracy and Technology makes in its response to AT&T's claims.

"AT&T's projection of the RFC authors' intent is misguided," CDT argues. "While differential pricing may certainly be used in conjunction with DiffServ, other than the single phrase selected by AT&T, the entirety of RFC 2475 is dedicated to describing the technical architecture needed to deploy differential services—not the payment schemes that may be associated with it."

True—but there's something else going on here. When societies can't resolve difficult questions like net neutrality via the law, legislation, or negotiations, they often turn to history for guidance. That's clearly what is happening now regarding the priority access fight.