2. the Design Philosophy of the DARPA Internet Protocols | Computer Network | Network Packet

Please download to get full document.

View again

of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Others

Published:

Views: 3 | Pages: 10

Extension: PDF | Download: 0

Share
Related documents
Description
research paper
Transcript
  ACM SIGCOMM-1-Computer Communication Review The Design Philosophy of the DARPA Internet Protocols David D. Clark * Massachusetts Institute of TechnologyLaboratory for Computer ScienceCambridge, MA. 02139 (Originally published in Proc. SIGCOMM ‘88, Computer Communication Review Vol. 18, No. 4,August 1988, pp. 106–114)   * This work was supported in part by the Defense Advanced Research Projects Agency (DARPA) under Contract No. N00014-83-K-0125  Abstract  The Internet protocol suite, TCP/IP, was first proposedfifteen years ago. It was developed by the DefenseAdvanced Research Projects Agency (DARPA), andhas been used widely in military and commercialsystems. While there have been papers andspecifications that describe how the protocols work, it issometimes difficult to deduce from these why theprotocol is as it is. For example, the Internet protocol isbased on a connectionless or datagram mode of service.The motivation for this has been greatly misunderstood.This paper attempts to capture some of the earlyreasoning which shaped the Internet protocols. 1. Introduction For the last 15 years 1 , the Advanced Research ProjectsAgency of the U.S. Department of Defense has beendeveloping a suite of protocols for packet switchednetworking. These protocols, which include the InternetProtocol (IP), and the Transmission Control Protocol(TCP), are now U.S. Department of Defense standardsfor internetworking, and are in wide use in thecommercial networking environment. The ideasdeveloped in this effort have also influenced otherprotocol suites, most importantly the connectionlessconfiguration of the ISO protocols 2 , 3 , 4 .While specific information on the DOD protocols isfairly generally available 5 , 6 , 7 , it is sometimes difficult todetermine the motivation and reasoning which led to thedesign.In fact, the design philosophy has evolved considerablyfrom the first proposal to the current standards. Forexample, the idea of the datagram, or connectionlessservice, does not receive particular emphasis in the firstpaper, but has come to be the defining characteristic of the protocol. Another example is the layering of thearchitecture into the IP and TCP layers. This seemsbasic to the design, but was also not a part of thesrcinal proposal. These changes in the Internet designarose through the repeated pattern of implementationand testing that occurred before the standards were set.The Internet architecture is still evolving. Sometimes anew extension challenges one of the design principles,but in any case an understanding of the history of thedesign provides a necessary context for current designextensions. The connectionless configuration of ISOprotocols has also been colored by the history of theInternet suite, so an understanding of the Internet designphilosophy may be helpful to those working with ISO.This paper catalogs one view of the srcinal objectivesof the Internet architecture, and discusses the relationbetween these goals and the important features of theprotocols. 2. Fundamental Goal The top level goal for the DARPA Internet Architecturewas to develop an effective technique for multiplexedutilization of existing interconnected networks. Someelaboration is appropriate to make clear the meaning of that goal.The components of the Internet were networks, whichwere to be interconnected to provide some largerservice. The srcinal goal was to connect together thesrcinal ARPANET 8 with the ARPA packet radionetwork  9 , 10 , in order to give users on the packet radionetwork access to the large service machines on theARPANET. At the time it was assumed that there wouldbe other sorts of networks to interconnect, although thelocal area network had not yet emerged.An alternative to interconnecting existing networkswould have been to design a unified system whichincorporated a variety of different transmission media, a  ACM SIGCOMM-2-Computer Communication Review multi-media network. While this might have permitted ahigher degree of integration, and thus betterperformance, it was felt that it was necessary toincorporate the then existing network architectures if Internet was to be useful in a practical sense. Further,networks represent administrative boundaries of control, and it was an ambition of this project to cometo grips with the problem of integrating a number of separately administrated entities into a common utility.The technique selected for multiplexing was packetswitching. An alternative such as circuit switching couldhave been considered, but the applications beingsupported, such as remote login, were naturally servedby the packet switching paradigm, and the networkswhich were to be integrated together in this project werepacket switching networks. So packet switching wasaccepted as a fundamental component of the Internetarchitecture.The final aspect of this fundamental goal was theassumption of the particular technique for inter-connecting these networks. Since the technique of storeand forward packet switching, as demonstrated in theprevious DARPA project, the ARPANET, was wellunderstood, the top level assumption was that networkswould be interconnected by a layer of Internet packetswitches, which were called gateways.From these assumptions comes the fundamentalstructure of the Internet: a packet switched communica-tions facility in which a number of distinguishablenetworks are connected together using packet communi-cations processors called gateways which implement astore and forward packet forwarding algorithm. 3. Second Level Goals The top level goal stated in the previous sectioncontains the word effective, without offering anydefinition of what an effective interconnection mustachieve. The following list summarizes a more detailedset of goals which were established for the Internetarchitecture.1.   Internet communication must continue despite lossof networks or gateways.2.   The Internet must support multiple types of communications service.3.   The Internet architecture must accommodate avariety of networks.4.   The Internet architecture must permit distributedmanagement of its resources.5.   The Internet architecture must be cost effective.6.   The Internet architecture must permit hostattachment with a low level of effort.7.   The resources used in the internet architecture mustbe accountable.This set of goals might seem to be nothing more than achecklist of all the desirable network features. It isimportant to understand that these goals are in order of importance, and an entirely different network architecture would result if the order were changed. Forexample, since this network was designed to operate ina military context, which implied the possibility of ahostile environment, survivability was put as a firstgoal, and accountability as a last goal. During wartime,one is less concerned with detailed accounting of resources used than with mustering whatever resourcesare available and rapidly deploying them in anoperational manner. While the architects of the Internetwere mindful of accountability, the problem receivedvery little attention during the early stages of the design,and is only now being considered. An architectureprimarily for commercial deployment would clearlyplace these goals at the opposite end of the list.Similarly, the goal that the architecture be cost effectiveis clearly on the list, but below certain other goals, suchas distributed management, or support of a wide varietyof networks. Other protocol suites, including some of the more popular commercial architectures, have beenoptimized to a particular kind of network, for example along haul store and forward network built of mediumspeed telephone lines, and deliver a very cost effectivesolution in this context, in exchange for dealingsomewhat poorly with other kinds of nets, such as localarea nets.The reader should consider carefully the above list of goals, and recognize that this is not a motherhood list,but a set of priorities which strongly colored the designdecisions within the Internet architecture. The followingsections discuss the relationship between this list andthe features of the Internet. 4. Survivability in the Face of Failure The most important goal on the list is that the Internetshould continue to supply communications service, eventhough networks and gateways are failing. In particular,this goal was interpreted to mean that if two entities arecommunicating over the Internet, and some failurecauses the Internet to be temporarily disrupted andreconfigured to reconstitute the service, then the entitiescommunicating should be able to continue withouthaving to reestablish or reset the high level state of theirconversation. More concretely, at the service interfaceof the transport layer, this architecture provides no  ACM SIGCOMM-3-Computer Communication Review facility to communicate to the client of the transportservice that the synchronization between the sender andthe receiver may have been lost. It was an assumption inthis architecture that synchronization would never belost unless there was no physical path over which anysort of communication could be achieved. In otherwords, at the top of transport, there is only one failure,and it is total partition. The architecture was to mask completely any transient failure.To achieve this goal, the state information whichdescribes the on-going conversation must be protected.Specific examples of state information would be thenumber of packets transmitted, the number of packetsacknowledged, or the number of outstanding flowcontrol permissions. If the lower layers of the archi-tecture lose this information, they will not be able to tellif data has been lost, and the application layer will haveto cope with the loss of synchrony. This architectureinsisted that this disruption not occur, which meant thatthe state information must be protected from loss.In some network architectures, this state is stored in theintermediate packet switching nodes of the network. Inthis case, to protect the information from loss, it mustreplicated. Because of the distributed nature of thereplication, algorithms to ensure robust replication arethemselves difficult to build, and few networks withdistributed state information provide any sort of protection against failure. The alternative, which thisarchitecture chose, is to take this information and gatherit at the endpoint of the net, at the entity which isutilizing the service of the network. I call this approachto reliability fate-sharing. The fate-sharing modelsuggests that it is acceptable to lose the stateinformation associated with an entity if, at the sametime, the entity itself is lost. Specifically, informationabout transport level synchronization is stored in thehost which is attached to the net and using itscommunication service.There are two important advantages to fate-sharing overreplication. First, fate-sharing protects against anynumber of intermediate failures, whereas replication canonly protect against a certain number (less than thenumber of replicated copies). Second, fate-sharing ismuch easier to engineer than replication.There are two consequences to the fate-sharingapproach to survivability. First, the intermediate packetswitching nodes, or gateways, must not have anyessential state information about on-going connections.Instead, they are stateless packet switches, a class of network design sometimes called a datagram network.Secondly, rather more trust is placed in the hostmachine than in an architecture where the network ensures the reliable delivery of data. If the host residentalgorithms that ensure the sequencing andacknowledgment of data fail, applications on thatmachine are prevented from operation.Despite the fact that survivability is the first goal in thelist, it is still second to the top level goal of interconnection of existing networks. A more survivabletechnology might have resulted from a single multi-media network design. For example, the Internet makesvery weak assumptions about the ability of a network toreport that it has failed. Internet is thus forced to detectnetwork failures using Internet level mechanisms, withthe potential for a slower and less specific errordetection. 5. Types of Service The second goal of the Internet architecture is that itshould support, at the transport service level, a varietyof types of service. Different types of service aredistinguished by differing requirements for such thingsas speed, latency and reliability. The traditional type of service is the bi-directional reliable delivery of data.This service, which is sometimes called a virtualcircuit service, is appropriate for such applications asremote login or file transfer. It was the first serviceprovided in the Internet architecture, using theTransmission Control Protocol (TCP) 11 . It was earlyrecognized that even this service had multiple variants,because remote login required a service with low delayin delivery, but low requirements for bandwidth, whilefile transfer was less concerned with delay, but veryconcerned with high throughput. TCP attempted toprovide both these types of service.The initial concept of TCP was that it could be generalenough to support any needed type of service. However,as the full range of needed services became clear, itseemed too difficult to build support for all of them intoone protocol.The first example of a service outside the range of TCPwas support for XNET 12 , the cross-Internet debugger.TCP did not seem a suitable transport for XNET forseveral reasons. First, a debugger protocol should notbe reliable. This conclusion may seem odd, but underconditions of stress or failure (which may be exactlywhen a debugger is needed) asking for reliablecommunications may prevent any communications atall. It is much better to build a service which can dealwith whatever gets through, rather than insisting thatevery byte sent be delivered in order. Second, if TCP isgeneral enough to deal with a broad range of clients, itis presumably somewhat complex. Again, it seemedwrong to expect support for this complexity in adebugging environment, which may lack even basic  ACM SIGCOMM-4-Computer Communication Review services expected in an operating system (e.g. supportfor timers.) So XNET was designed to run directly ontop of the datagram service provided by Internet.Another service which did not fit TCP was real timedelivery of digitized speech, which was needed tosupport the teleconferencing aspect of command andcontrol applications. In real time digital speech, theprimary requirement is not a reliable service, but aservice which minimizes and smoothes the delay in thedelivery of packets. The application layer is digitizingthe analog speech, packetizing the resulting bits, andsending them out across the network on a regular basis.They must arrive at the receiver at a regular basis inorder to be converted back to the analog signal. If packets do not arrive when expected, it is impossible toreassemble the signal in real time. A surprisingobservation about the control of variation in delay isthat the most serious source of delay in networks is themechanism to provide reliable delivery. A typicalreliable transport protocol responds to a missing packetby requesting a retransmission and delaying the deliveryof any subsequent packets until the lost packet has beenretransmitted. It then delivers that packet and allremaining ones in sequence. The delay while this occurscan be many times the round trip delivery time of thenet, and may completely disrupt the speech reassemblyalgorithm. In contrast, it is very easy to cope with anoccasional missing packet. The missing speech cansimply be replaced by a short period of silence, whichin most cases does not impair the intelligibility of thespeech to the listening human. If it does, high level errorcorrection can occur, and the listener can ask thespeaker to repeat the damaged phrase.It was thus decided, fairly early in the development of the Internet architecture, that more than one transportservice would be required, and the architecture must beprepared to tolerate simultaneously transports whichwish to constrain reliability, delay, or bandwidth, at aminimum.This goal caused TCP and IP, which srcinally had beena single protocol in the architecture, to be separated intotwo layers. TCP provided one particular type of service,the reliable sequenced data stream, while IP attemptedto provide a basic building block out of which a varietyof types of service could be built. This building block was the datagram, which had also been adopted tosupport survivability. Since the reliability associatedwith the delivery of a datagram was not guaranteed, but best effort, it was possible to build out of thedatagram a service that was reliable (by acknowledgingand retransmitting at a higher level), or a service whichtraded reliability for the primitive delay characteristicsof the underlying network substrate. The User DatagramProtocol (UDP) 13 was created to provide a application-level interface to the basic datagram service of Internet.The architecture did not wish to assume that theunderlying networks themselves support multiple typesof services, because this would violate the goal of usingexisting networks. Instead, the hope was that multipletypes of service could be constructed out of the basicdatagram building block using algorithms within thehost and the gateway. For example, (although this is notdone in most current implementations) it is possible totake datagrams which are associated with a controlleddelay but unreliable service and place them at the headof the transmission queues unless their lifetime hasexpired, in which case they would be discarded; whilepackets associated with reliable streams would beplaced at the back of the queues, but never discarded,no matter how long they had been in the net.It proved more difficult than first hoped to providemultiple types of service without explicit support fromthe underlying networks. The most serious problem wasthat networks designed with one particular type of service in mind were not flexible enough to supportother services. Most commonly, a network will havebeen designed under the assumption that it shoulddeliver reliable service, and will inject delays as a partof producing reliable service, whether or not thisreliability is desired. The interface behavior defined byX.25, for example, implies reliable delivery, and thereis no way to turn this feature off. Therefore, althoughInternet operates successfully over X.25 networks itcannot deliver the desired variability of type service inthat context. Other networks which have an intrinsicdatagram service are much more flexible in the type of service they will permit, but these networks are muchless common, especially in the long-haul context. 6. Varieties of Networks It was very important for the success of the Internetarchitecture that it be able to incorporate and utilize awide variety of network technologies, including militaryand commercial facilities. The Internet architecture hasbeen very successful in meeting this goal; it is operatedover a wide variety of networks, including long haulnets (the ARPANET itself and various X.25 networks),local area nets (Ethernet, ringnet, etc.), broadcastsatellite nets (the DARPA Atlantic SatelliteNetwork  14 , 15 operating at 64 kilobits per second and theDARPA Experimental Wideband Satellite Net, 16 operating within the United States at 3 megabits persecond), packet radio networks (the DARPA packetradio network, as well as an experimental British packetradio net and a network developed by amateur radiooperators), a variety of serial links, ranging from 1200
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x