Design Philosophy of the DARPA Internet Protocols

[Paper link]

This paper explains the rationale behind DARPA design decisions of TCP/IP. The main point of the paper is to explain how the military's priorities and application suite influenced the design of the Internet. Since many of these goals are no longer applicable to the widespread commercial Internet, their choices may be worth reconsidering in future designs. If you can identify the priorities and goals that have changed, you might be able to find areas of improvement in modern contexts. They place a very high priority on survivability and the ability to support mixed media networks, and give very low priority to accountability and cost effectiveness. This clearly reflects a military mindset rather than the modern commercial one. Since survivability was a #1 priority, stateless packet switching was chosen as the core architecture of the Internet; if parts of the Internet died and had to be replaced or restarted, no state would need to be restored.

Their original goal was to give users of a packet radio network access to the resources of the main network. This had three important ramifications:
(1) These were two separate administrative domains, hence the idea of the Internet being locally rather than universally administered.
(2) They needed to support both rlogin and voice over these different types of networks (with their different speed and reliability constraints). To do this, they moved reliability up the network stack to TCP (rlogin and its like) and UDP (voice and the like). IP provides flexible, "best effort" transmission of datagrams, and TCP and UDP can handle reliability (or not) however they like. The fact that networks only need to support the switching of datagram packets means that lots of different network types of varying quality can support the Internet.
(3) Since the specifications and requirements of networks are so minimal, every time a new portion of Internet is set up, a lot of re-engineering is done.

For context, this paper was published in 1988, 15 years after the inception of TCP/IP.

-- Since they were a military network, survivability was their #1 goal and accountability was #7. This has interesting implications in terms of network security. In the original threat model, all threats were physically external (trying to damage the infrastructure of the network). In a modern threat model, network threats are internal to the Internet, and accountability would be very useful (e.g., for tracing and discouraging DOS attacks). They just saw accountability as a resource allocation detail. Accountability is hard with the stateless datagram model because packets contain all their own state and the packet switches are stateless. This is a problem because there is no place in a packet's header for recording accounting information except the source field, and the creator of a packet can lie about the source field when building the packet. We need EGRESS/INGRESS filtering to detect these lies but that requires ISP cooperation. Related paper: Network support for IP traceback.

-- In section 7, the author writes: "In the large Internet being currently operated, routing decisions need to be constrained by policies...Today this can be done only in a very limited way, which requires manual setting of tables." Is this manual setting of tables what BGP now does?

-- In section 8, the author talks about how simulators can/should be used to figure out the "best" design of a network. He seems chagrined that most actual designs are "best guesses" rather than supported by simulated data. However -- it's my understanding that simulating realistic network traffic is a very hard problem that still hasn't been solved.

-- Are flows implemented now? I am sort of confused by his discussion in the conclusion. I thought a network flow was just, generally, the packets traveling from one host to another over a multiplexed connection...and therefore still packet-based. Is the difference that, in his model of "flows", intermediate switches & routers maintain state about the flow?

-- I liked this paper a lot. Definitely should keep in the syllabus. It's nice to know the rationale behind past design decisions.

FIRST POST

FIRST POST!