The Design Philosophy of the DARPA Internet Protocols

What are the key strengths / contributions of this paper?

The paper does a great job in

  1. presenting the design goals (ordered in priority) of development of Internet protocols (TCP/IP) when they were first created

  2. revealing the rationale behind the protocols' design decisions

  3. discussing what design goals are met, what remains unmet and why

  4. pointing out changes to the architecture from the point where they were created till the paper was written, comparing and reasoning about these changes


  1. There're a long list of goals sorted by priorities, it'll be great if the authors presented a more specific discussions on what requirements / potential designs correspond to achieving each of these goals

  2. Were there different protocol designs considered back then? If so, how were those satisfying the goals listed?

  3. Would like to see more detailed discussions on a complete set of feature changes on TCP/IP and the motivation behinds them. There is a partial presentation on this in Section 10 but a complete review would be great.

Important paper?


When we design or think about the next-gen Internet infrastructure, it is always useful to think about under what context the original Internet was designed, and what assumptions have changed since then that might re-order the priority of the design goals and/or invalidate some of the design decisions of the old infrastructure.

The paper is important as it presents the philosophy on how TCP/IP were designed, and potentially encourages discussions on what things are different now and on revisiting the assumptions behind some of the most commonly used concepts and protocols

Summary of the paper (any surprising things)?

  • This paper attempts to capture the motivations and some of the early reasonings which shaped the Internet protocols, specifically TCP/IP. Specifically, it aims to help provide a necessary connect for current design extensions.

  • Fundamental Goal: develop an effective technique for multiplexed utilization of existing interconnected networks

    • I.e. interconnection of existing networks

    • Original setup: connect ARPANET with the ARPA packet radio network

    • V.s. a unified multi-media system

      • Pro (unified): higher degree of integration, better performance

      • Con (unified): need to integrate the existing network architectures, hard to integrate a # of administrated entities into a common utility

    • Technique for multiplexing: packet switching

      • V.s circuit switching

      • Reasoning: applications (e.g. remote login) were naturally supported, networks were to be integrated in the project were packet switching network

    • Structure of Internet is

      • a packet switched communications facility in which a number of distinguishable networks are connected together using packet communications processors called gateways which implement a store and forward packet forwarding algorithm.

  • Second Level Goals (ranked in priority)

    • Internet communication must continue despite loss of networks or gateways

    • The Internet must support multiple types of communication service

    • The Internet architecture must accommodate a variety of network

    • The Internet architecture must permit distributed management of its resources

    • The Internet architecture must be cost effective

    • The Internet architecture must permit lost attachment with a low level effort

    • The resource used in the Internet architecture must be accountable

  • Context

    • Military context

      • Hostile env --> survivability was put as the first goal, accountability as the last goal

        • Want rapid deployment without detailed accounting of the resources

        • Assumption: at the top of transport, there is only one failure, and it is total partition. The arch was to mask completely any transient failure.

        • "Fate-sharing"

          • Acceptable to lose the state information associated with the entity if, at the same time, the entity itself is lost.

          • V.s. replication in the intermediate packet switch nodes

            • Pro

              • Protect against any intermediate failures

              • Easier to engineer

          • Survivability

            • Intermediate nodes (gateways) stateless --> "datagram" network

            • More trust is placed in the host machine than in an arch where the network ensures reliable delivery of the data

            • Still

      • Second goal: support variety of types of service (at the transport service level)

        • "virtual circuit" service

          • first service provided in the Internet using TCP

          • applications: remote login (low delay in delivery, but low requirement for BW), file transfer (less concerned with delay, concerned with high-tput)

        • Example outside TCP range to support

          • XNET: cross-Internet debugger

            • debugging tool should not be reliable

            • if TCP is presumably complex, which is not expected in a debugging env (e.g. no support for timers)

          • Real time delivery of digitized speech

            • Primary requirement: not reliable service, but minimize and smooth the delay

            • Not retransmit, but just replace by a short period of silence

        • Assumption: more than one transport service would be required, the arch must be prepared --> constraint reliability, delay, or BW

          • Lead to TCP / IP separation

            • TCP: provide one particular type of service (reliable sequenced data stream)

            • IP: basic building block (i.e. datagram) which variety of service could be built

          • UPD: application-level interface to the basic datagram service

          • But hard without underlying network support

            • Problem: networks designed with particular type of service in mind were not flexible enough to support other services

      • Third goal: varieties of networks

        • Long haul (ARPANET, X.25), local area nets, broadcast satellite nets, packet radio networks, different serial links and ad hoc facilities (e.g. intercomputer busses)

        • Minimum set of assumptions

          • Basic: network can transport a packet or datagram

          • Not assume: reliable or sequenced delivery, network level broadcast or multicast, priority ranking of transmitted packet, support for multi-service, internal knowledge of failures, speeds, or delays

      • Other goals

        • Not perfectly engineered

        • Distributed management

          • E.g. not all gateways in the Internet are implemented and managed by the same agency; two-tier routing which permits gw from different administrations to exchange routing tables without trust

          • But still lack of tools for management

            • E.g. routing, decisions constrained by policies for resource usage

            • What was done: manually setting the tables --> error-prone, not powerful

        • Cost-effective

          • --> originally was put below other goals like managements and support for various network

          • Inefficiency

            • headers are long; for short packets, overhead is apparent

            • retransmissions of lost packets (need to be done end-to-end)

            • attaching host (with desired types of service) cost is high

            • poor implementation of the mechanism might hurt the network as well as the host

          • Now: commercial archs were designed for specific networks

        • Accountability

          • few tools for accounting packet flows when the paper was out

          • problem was studied to include non-military customers concerned with understanding and monitoring the usage of resources

  • Architecture and implementation

    • Major struggle: how to give guidance to the designer of a realization (i.e. related the engineering of the realization to the types of service which would result)

    • Aids

      • protocol verifiers: deal with logical correctness

        • Con: never deal with performance issues

      • simulator: takes a particular realization and explores the service which it can deliver under a variety of loadings

    • Hard to tight performance constraint

      • Goal of the arch was not to constrain performance, but to permit variability

      • No useful formal tools for describing performance

  • Datagram

    • Important as

      • Eliminates need for connection state within intermediate nodes

      • Provides a basic building block out of which different types of services can be implemented

      • Represents the minimum network service assumption, which has permitted a wide variety of networks to be incorporated into various Internet realization

  • TCP

    • Regulate delivery of bytes rather than packets

      • Motivations

        • Permit the insertion of control information into the sequence space of the bytes, so the control and the data could be acknowledged (?)

          • Use of sequence space has been dropped because of complexity

        • Permit the TCP packet to be broken up into smaller packets if necessary for fitting through a net with small packet size

          • This function was moved to the IP layer when IP split from TCP, and IP was forced to invent different methods of fragmentation

        • Permit small packets to be gathered together into one larger packet in the sending host if retransmission of the data was necessary

          • Critical

            • UNIX: lots of one byte data in packet, which would arrive must faster than a slow host could process them, this result in lost packets and retransmission

          • But

            • ACK of bytes seem to create this problem at the first place, though also have severe limit on throughput if small packets are sent

    • EOL --> PSH

      • EOL: break byte stream into records

      • Later: only data up to this point in the stream was one or more complete application-level elements

      • "one or more" rather than "exactly one"

Other comments / thoughts

  1. The paper talks about the relationship between architecture and performance, and the great difficulty that the Internet architecture designers experience in formalizing aspect of performance constraints, mainly because there was no useful formal tools for describing performance. Is this kind of tools available now?

  2. It's mentioned that back in the days when the paper was written, there is lack of sufficient tools for distributed management, especially in the area of routing; what are the new status on the development of these tools for resource managements in the context of multiple administrations?

Last updated