The Design Philosophy of the DARPA Internet Protocols
http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-clark.pdf
What are the key strengths / contributions of this paper?
The paper does a great job in
presenting the design goals (ordered in priority) of development of Internet protocols (TCP/IP) when they were first created
revealing the rationale behind the protocols' design decisions
discussing what design goals are met, what remains unmet and why
pointing out changes to the architecture from the point where they were created till the paper was written, comparing and reasoning about these changes
Weakness?
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
Were there different protocol designs considered back then? If so, how were those satisfying the goals listed?
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?
Yes!
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
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?
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