2. The Design Philosophy of the DARPA Internet Protocols

• 1. This paper attempts to capture some of the early reasoning which shaped the Internet protocols developed by DARPA.
• datagram / connectionless service, no emphasis in the first paper
• 2. Fundamental Goal: top level goal for DARPA: multilexed ultilization of existing interconnected networks (ARPANET <-> ARPA packet radio network) (LAN not emerged)
• technique selected: packet switching, instead of circuit switching.
• Top level assumption: connected by Internet packet switches, also called gateways.
• 3. Second level goals: clearer definitions of "effective": (priority)
• 1) communication must continue despite loss of networks or gateways, (military)
  
• 2) support multiple services,
• 3) accommodate a variety of networks,
• 4) permit distributed management,
• 5) cost effective,
• 6) permit host attachment easily,
• 7) resources used must be accountable
• 4. Survivability in the face of failure: transport layer provides no facility to communicate to the client. sync never lost unless there was no physical path
• state info of the on-going conversatoin must be protected from loss. if lower layers lost this info, they won't be able to tell if data were lost.
• 5. Types of service: suould support a variety of types of service at the transport service level, distinguished by speed, latency, reliability, etc.
• traditional type of service is bi-directional reliable delivery of data, "virtual circuit" service. remote login or file transfer was the first service provided in Internet architecture, using TCP. (delay / throughput requirements)
• impossible to support all services into one protocol. e.g. 1) XNET (cross-Internet debugger) -- shouldn't be reliable, 2) live voice chat, smooths the delay, missing packet replaced by silence
• TCP provides reliable sequenced data streams; IP provides basic building block, the datagram (UDP: User Datagram Protocol)
• 6. Varieties of networks: long haul (ARPANET, X.25), short haul (Ethernet, ringnet), boradcast satellite nets (DARPA Altantic Satelite Network), packet radio networks, etc
  
• flexibility achieved by making a minimum set of assumptions about the functions the net will provide. packet or datagram.
• 7. Other goals: distributed management, gateways.
• Problems of Internet today: lack of sufficient tools for distributed management, esp routing.
• headers of Internet packets are long (40 bytes). e.g. remote login packets, only one byte of data with 40 bytes of header.
• problem of host-resident machanisms -- poor implementation may hurt the network and the host
• accountability: the Internet contains few tools for accounting for packet flows
• 8. Architecture and implementation: the architecture tried very hard not to limit the services the Internet could provide.
• 9. Datagrams: 1) eliminate the need for connection state, i.e. Internet can be reconstituted after a failure, 2) provides a basic building block
  
• 10. TCP: window management, port address structure. original ARPANET provided flow control both on bytes and packets. TCP - only bytes. reasons: 1) to permit the insertion of control info, 2) permit TCP packet to be broken up in to smaller packets if necessary, 3) permit a number of small packets to be gathered into one larger packet
• EOL / Push changes
• 11. Conclusion: datagram solves the most important goals, but not so well when addressing some goals durther down the priority list. there may be a better building block than the datagram for newer generations of architecture.