The First Network Neutrality Debate

by on May 30, 2007 · 10 comments

I’m reading Janet Abbate’s Inventing the Internet, an excellent history of the Internet starting with its origins as the ARPANET in the 1960s. The most interesting things I’ve learned about so far is the heated battled between the TCP/IP protocol, which was favored primarily by the computer science research community, and the competing X.25 protocol, which was favored by the telecom industry. Embarrassingly, I didn’t know anything about this argument before I picked up Abbate’s book. What’s striking about it is how similar it sounds to arguments today. From page 161:

The operators of public data networks argued that ARPA’s TCP/IP failed to provide adequate control over network operations. For instance, a Telenet spokesman noted that, whereas X.25 was capable of controlling the flow of packets from each individual connection, TCP could only act on an entire host’s output at once. If one of the network connections from a host malfunctioned and flooded a TCP/IP network with packets, the network’s only defense would be to cut off the entire host, thus unfairly penalizing the others users on that host. Users of the research network might accept the inconvenience with resignation, but paying customers of a public data network would certainly protest. With regard to the business of running a network, the [Post, Telephone, and Telegraph Authorities] pointed out that IP had not been designed to allow networks to exchange the type of information that would be required for access control or cost accounting… TCP/IP had not been designed for a network serving as a public utility, with service guarantees and access charges. X.25 had been.

The choice between X.25′s virtual circuits and TCP/IP’s datagrams was not simply a technical matter; it also shifted the distribution of control and accountability between public network providers and private computers owners. For the PTTs, virtual circuits meant they could fuarntee their customers better service and boost their own profits. Some of their customers were glad to be offered reliable data communications service with little effort required on their part. For more expert computer owners, however, virtual circuits raised the cost of network service and interfered with their ability to control their own data communications activities.

Needless to say, I’m not posting this over an X.25 network. I think the advocates of non-neutral networking should be worried about the parallels here. While there were doubtless many factors that contributed to TCP/IP’s near-total in the 1990s, the flexibility, decentralization, and low cost of TCP/IP networks was clearly a decisive factor. The arguments that some proponents of a tiered Internet make today are eerily similar to the pro-X.25 arguments Abbate describes above. While we shouldn’t rule out experimentation with smarter networks at the margin, it strikes me as highly unlikely that a centralized, telco-controlled, “smart” network would work any better today than it did in 1987.

And just to avoid misunderstanding: the technical question of whether a non-neutral network is a good idea is separate from the policy question of whether mandating neutral networks is a good idea. In my opinion, neutral networks are a good idea, but laws mandating them aren’t so great.

  • Chris

    Telephones almost always work. The Internet does not, it just usually works. From a technical standpoint, this is a big difference. If you wish to mix telephones with the Internet, you will need an Internet that almost always works. Why is this? Much traditional Internet traffic is TCP based and not latency sensitive whereas real time traffic such as two way voice or video is latency sensitive (and UDP).

    Your neutrality vs. non-argument is abstract enough to gloss over the fact that two completely types of network are merging into what is known as next generation networks and a new cumulative requirement for the network will result.

  • Chris

    Telephones almost always work. The Internet does not, it just usually works. From a technical standpoint, this is a big difference. If you wish to mix telephones with the Internet, you will need an Internet that almost always works. Why is this? Much traditional Internet traffic is TCP based and not latency sensitive whereas real time traffic such as two way voice or video is latency sensitive (and UDP).

    Your neutrality vs. non-argument is abstract enough to gloss over the fact that two completely types of network are merging into what is known as next generation networks and a new cumulative requirement for the network will result.

  • http://enigmafoundry.wordpress.com/ enigma_foundry

    Telephones almost always work. The Internet does not, it just usually works. From a technical standpoint, this is a big difference. If you wish to mix telephones with the Internet, you will need an Internet that almost always works. Why is this? Much traditional Internet traffic is TCP based and not latency sensitive whereas real time traffic such as two way voice or video is latency sensitive (and UDP).

    I don’t agree with that analysis, because you are using the criteria of one network (the telephone system) to judge another network (the internet) which was in fact designed with different criteria.

    So if I said my sailboat didn’t work because it didn’t drive like my car, that would be silly.

  • http://enigmafoundry.wordpress.com eee_eff

    Telephones almost always work. The Internet does not, it just usually works. From a technical standpoint, this is a big difference. If you wish to mix telephones with the Internet, you will need an Internet that almost always works. Why is this? Much traditional Internet traffic is TCP based and not latency sensitive whereas real time traffic such as two way voice or video is latency sensitive (and UDP).

    I don’t agree with that analysis, because you are using the criteria of one network (the telephone system) to judge another network (the internet) which was in fact designed with different criteria.

    So if I said my sailboat didn’t work because it didn’t drive like my car, that would be silly.

  • Chris

    enigma,

    Thank you for reinforcing my point. Next generation networks are packetized networks in which both the traditional Internet (packets) and the traditional phone system (circuits) are merging into one single packetized network, with the cumulative requirements of performance that existed in both previous networks.

    As far as your sailboat, the comparison would be: Sailboats float on the sea and cars drive on land, then we create a personal transportation device that can both float on sea and travel on land. Therefore the capabilities and requirements for the new personal transportation device are both for land and sea travel.

  • Chris

    enigma,

    Thank you for reinforcing my point. Next generation networks are packetized networks in which both the traditional Internet (packets) and the traditional phone system (circuits) are merging into one single packetized network, with the cumulative requirements of performance that existed in both previous networks.

    As far as your sailboat, the comparison would be: Sailboats float on the sea and cars drive on land, then we create a personal transportation device that can both float on sea and travel on land. Therefore the capabilities and requirements for the new personal transportation device are both for land and sea travel.

  • http://enigmafoundry.wordpress.com/ enigma_foundry

    As far as your sailboat, the comparison would be: Sailboats float on the sea and cars drive on land, then we create a personal transportation device that can both float on sea and travel on land.

    It shold be obvious that we would end up with something that would neither be a good car or a good sailboat.

    As someone who designs stuff for a living, I would call your attention to one of the most important steps in a design process: developing criteria. So the internet was designed with a certain criteria for latency, a criteria which it meets.

  • http://enigmafoundry.wordpress.com eee_eff

    As far as your sailboat, the comparison would be: Sailboats float on the sea and cars drive on land, then we create a personal transportation device that can both float on sea and travel on land.

    It shold be obvious that we would end up with something that would neither be a good car or a good sailboat.

    As someone who designs stuff for a living, I would call your attention to one of the most important steps in a design process: developing criteria. So the internet was designed with a certain criteria for latency, a criteria which it meets.

  • Chris

    Perhaps the sailboat and car comparison doesn’t hold up well for personal transportation. I merely wanted to highlight the need to merge two sets of design criteria in the merging of two types of communication networks. The Internet Protocol world and the public switch telephone network world.

    The assumption that the internet was designed with a certain criteria for latency which it meets disregards a basic design fact. Things change. The domain model developed in the past at some time will no longer apply. A new model with new criteria will come about. The traditional circuit based model for telephony (real time communication) is merging with the traditional packet based model for file transfer. Together there is a need for both file transfer and real time information on one network. Some groups call this model Next Generation Networks (see International Telecommunications Union), some groups call this Converged Networks.

    This is the cumulative requirements (or criteria) I mentioned in my first post.

  • Chris

    Perhaps the sailboat and car comparison doesn’t hold up well for personal transportation. I merely wanted to highlight the need to merge two sets of design criteria in the merging of two types of communication networks. The Internet Protocol world and the public switch telephone network world.

    The assumption that the internet was designed with a certain criteria for latency which it meets disregards a basic design fact. Things change. The domain model developed in the past at some time will no longer apply. A new model with new criteria will come about. The traditional circuit based model for telephony (real time communication) is merging with the traditional packet based model for file transfer. Together there is a need for both file transfer and real time information on one network. Some groups call this model Next Generation Networks (see International Telecommunications Union), some groups call this Converged Networks.

    This is the cumulative requirements (or criteria) I mentioned in my first post.

Previous post:

Next post: