Does the Internet Work?

Does the Internet work?  Is it a success?

There are a few ways to answer these questions.  It might seem obvious that it is a success, since the whole world is connected or about to be connected.  Global domination is the very definition of success, isn't it?  We could try other definitions, such as happiness.  Does the Internet make us happier?  This would be hard to answer in a blog post.

Another approach is to use the original goals of the architects of the Internet as a benchmark.  In 1987, David Clark wrote a retrospective paper describing these goals.  Clark was the Chief Protocol Architect for the Internet in 1981, and he remains an Internet visionary today.

Goals:

0. Develop an effective technique for multiplexed utilization of existing interconnected networks.
1. Internet communication must continue despite loss of networks or gateways.
2. The Internet must support multiple types of communications service.
3. The Internet architecture must accommodate a variety of networks.
4. The Internet architecture must permit distributed management of its resources.
5. The Internet architecture must be cost effective.
6. The Internet architecture must permit attachment with a low level of effort.
7. The resources used in the Internet architecture must be accountable.

Some reflections:

1. Though it's hard to remember today, the Internet was originally a military program.  It was designed to withstand nuclear attack.  This goal (1 and 4), coupled with the desire to interconnect existing networks and networking protocols (0, 2, 3, and 5), led to the design choices of 1) a packet-switched network of dumb routers with 2) the datagram as its base messaging unit. 
   
   A packet-switched network transmitting datagrams meets many of the goals of the Internet architects, but it has some serious trade-offs.  Because the Internet is stateless, error detection, retransmissions, and security must be handled at the end hosts.  The network just does the best it can to transmit datagrams.  There are no other perks.
   
   In many ways, this was a pragmatic decision: there was a large installed based of existing hardware, and it would have been difficult to convince people to start again with specs designed by the military.  The architects had no idea how widespread the Internet would become.  Still, it was a military application.  You would think that security, at least, would need to be baked into the network.
   
   Interestingly, decentralization led to many social, political, commercial, and economic consequences that typically are not high on the list of military priorities.  I have never worked in defense, but I understand that there is an emphasis on chains of command and accountability.  I can't think of anything less hierarchical or accountable than the Internet.
   
   
2. Speed is not a goal.  Isn't it funny that a communications protocol using telephony cannot transmit real-time voice communication?  The packet-switched network was designed to route around network failures.  There is no guarantee that packets arrive in any order or within any period of time.  For this reason, packets have a lot of overhead in the form of message headers.  The packet-switched datagram is a relatively slow form of communication.  It wasn't until broadband was widely available that VOIP became feasible. 
   
   Much traffic today is composed of message headers, retransmissions, and flow control information, all of which could be better handled by a stateful network.  A stateful network would be more like the phone system, in which dedicated lines handle streams of information.  These lines would have to be easily reroutable to handle interruptions to the system (such as nuclear attack), but packet-switching is not the only way to do this.
   
   
3. Accountability (i.e., monitoring) dropped off the list.  Since it was a military application, the Internet Architects wanted to be able to account for its uses and abuses.  However, it would have been very difficult to develop monitoring systems in a stateless network.  After all, the monitoring system AT&T uses for billing is about as complex as the telephonic network itself, and that is a stateful system.  For this reason, accountability was quickly dropped from the list of goals.
   
   Since there is no monitoring within the network itself, all accounting must be handled at the application layer.  TCP has to figure out what speed it should transmit by monitoring dropped packets.  Denial-of-service attacks have to be handled by firewalls.  Routers can simply declare what addresses they can handle.  And, of course, speed can't be a goal if there is no way to measure performance.

In short, the Internet is not a perfect system.  It meets many of its goals, but its architects faced a trade-off between stateful and stateless systems.  Stateful systems are good for speed, error-handling, security, and accountability, but a stateful Internet would require more expensive hardware and a reworking of the entire system.  A stateless system is cheap and simple, but it is slow and requires hosts to handle any advanced features.  At the end of his paper, Clark suggests that the packet-switched datagram was a compromise and that a 'soft state' system composed of streams may have been better.

Like the Internet architects, however, we have to be pragmatic.  The ubiquity of Network Address Translators (NATs) forces us to stick with TCP/IP.  Because NATs read and rewrite message headers, there has to be agreement on the protocols in use.  If we wanted to change protocols, we would have to throw out all our routers and modems.  Of course, new protocols could be created on top of TCP/UDP/ICMP, but these would have the same shortcomings as the layers below.