(cid:55)(cid:75)(cid:76)(cid:86) (cid:80)(cid:68)(cid:87)(cid:72)(cid:85)(cid:76)(cid:68)(cid:79) (cid:80)(cid:68)(cid:92) (cid:69)(cid:72) (cid:83)(cid:85)(cid:82)(cid:87)(cid:72)(cid:70)(cid:87)(cid:72)(cid:71) (cid:69)(cid:92) (cid:38)(cid:82)(cid:83)(cid:92)(cid:85)(cid:76)(cid:74)(cid:75)(cid:87) (cid:79)(cid:68)(cid:90) (cid:11)(cid:55)(cid:76)(cid:87)(cid:79)(cid:72) (cid:20)(cid:26) (cid:56)(cid:17)(cid:54)(cid:17) (cid:38)(cid:82)(cid:71)(cid:72)(cid:12)
`
`SAP 1011
`IPR2014-00414
`Page 1 of 9
`
`

`

`networks to interconnect. although the local area network
`had not yet emerged.
`
`S.Thc lntemet architecture must be cost
`effective.
`
`to interconnecting existing networks
`An alternative
`would have been to design a unified system which
`incorporated a variety of different transmission media. a
`multi-media network. While this might have permitted a
`higher degree of integration, and thus better performance,
`it was felt that it was necessary to incorporate 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 oftltis project to come to grips with the problem
`of integrating a number of separately administrated
`entities into a common utility.
`
`The technique selected for multiplexing was packet
`swrtching. An alternative such as circuit switching could
`have been considered, but
`the
`applications being
`supported, such as remote login, were naturally served by
`the packet switching paradigm, and the networks which
`were to be integrated together in this project were packet
`switching networks. So packet switching was accepted
`as a fundamental component of the lntemet architecture.
`
`the
`fundamental goal was
`The final aspect of this
`assumption of the particular technique for interconnecting
`these networks. Since the technique of store and forward
`packet
`switching.
`as demonstrated in the previous
`DARPA project, the ARPANET, was well understood,
`the top level assumption was that networks would be
`interconnected by a layer of Internet packet switches,
`which were called gateways.
`
`From these assumptions comes the fundamental stmcture
`of the lntemet:
`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.
`
`3. Second Level Goals
`
`The top level goal stated in the previous section contains
`the word "effective," without offering any definition of
`what an effective interconnection must achieve. The
`following list summarizes a more detailed set of goals
`which were established for the lntemet architecture.
`
`I. lntemet
`
`communication must
`
`continue
`
`despite loss of networks or gateways.
`
`2. The lntemet must support multiple types of
`communications service.
`
`3. The
`
`lntemet
`
`architecture
`
`must
`
`accommodate a variety of networks.
`
`permit
`architecture must
`lntemet
`4. The
`distributed management of its resources.
`
`6. The lntemet architecture must permit host
`attachment with a low level of effort.
`
`the
`in
`used
`resources
`7.'l'he
`architecture must be accountable.
`
`intemet
`
`This set of goals might seem to be nothing more than a
`checklist of all
`the desirable network features.
`It
`is
`
`important to understand that these goals are in order of
`importance. and an entirely different network architecture
`would result if the order were changed. For example,
`since this network was designed to operate in a military
`context. which implied the possibility of a hostile
`environment. survivability was put as a first goal, and
`accountability as a last goal. During wartime. one is less
`concerned with detailed accounting of resources used
`than with mustering whatever resources are available and
`rapidly deploying them in an operational manner. While
`the
`architects
`of
`the
`lntemet were mindful
`of
`accountability, the problem reeeived very little attention
`during the early stages of the design. and is only now
`being considered.
`An
`architecture
`primarily
`for
`commercial deployment would clearly place these goals
`at the. opposite end of the list
`
`Similarly. the goal that the architecture be cost effective
`is clearly on the list. but below certain other goals, such
`as distributed management. or support of a wide variety
`of networks. Other protocol suites, including some of the
`more popular commercial
`architectures.
`have been
`optimized to a particular kind of network. for example a
`long haul store and forward network built of medium
`speed telephone lines, and deliver a very cost effective
`sotution in
`this
`context.
`in exchange
`IOr dealing
`somewhat poorly with other kinds of nets. such as local
`area 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 design
`decisions within the lntemet architecture. The following
`sections discuss the relationship between this list and the
`features of the lntemet.
`
`4. Survivability in the Face of Failure
`
`The most important goal on the list is that the lntemet
`should continue to supply communications service, even
`though networks and gateways are failing.
`in particular.
`this goal was interpreted to mean that if two entities are
`communicating over the lntemet. and some failure causes
`the lntemet to be temporarily disrupted and reconfigured
`to
`reconstitute
`the
`service.
`then
`the
`entities
`communicating should be able to continue without
`having to reestablish or reset the high level state of their
`conversation. More concretely, at the service interface of
`the transport layer, this architecture provides no facility
`to communicate to the client of the transport service that
`
`[07
`
`SAP 1011
`
`|PR2014-00414
`
`Page 2 of 9
`
`SAP 1011
`IPR2014-00414
`Page 2 of 9
`
`

`

`the synchronization between the sender and the receiver
`may have been lost.
`It was an assumption in this
`architecture that synchronization would never be lost
`unless there was no physical path over which any sort of
`communication could be achieved.
`In other words. at the
`top of transport, there is only one failure, and it is total
`partition. The architecture was to mask completely any
`transient failure.
`
`the state information which
`To achieve this goal,
`describes the on-going conversation must be protected.
`Specific examples of state information would be the
`number of packets transmitted,
`the number of packets
`acknowledged. or the number of outstanding flow control
`pennissions.
`If the lower layers of the architecrure lose
`this information. they will not be able to tell if data has
`been lost. and the application layer will have to cope with
`the loss of synchrony. This architecture insisted that this
`disruption not occur. which meant
`that
`the
`state
`information must be protected from loss.
`
`In some network architectures. this state is stored iii the
`
`In
`intermediate packet switching nodes of the network.
`this case. to protect the.
`information from Ines,
`it must
`replicated. Because of the distributed nature of the
`replication, algorithms to ensure robust replication are
`themselves difficult
`to build. and few networks with
`
`any sort of
`information provide
`distributed state
`protection against failure. The alternative. which this
`architecture chose, is to take this information and gather
`it at the endpoint of the net. at the entity which is utili7ing
`the service of the network.
`I call
`this approach to
`reliability
`"fate-sharing."
`The
`fate-sharing model
`suggests that it is acceptable to lose the state information
`associated with an entity if, at the same time. the entity
`itself is lost. Specifically, information about transport
`level synchronization is stored in the host which is
`attached to the net and using its communication service.
`
`There are two important advantages to fate-sharing over
`replication.
`First,
`fate-sharing protects against any
`number of intermediate failures, whereas replication can
`only protect against a certain number (less than the
`number of replicated copies).
`Second, fate-sharing is
`much easier to engineer than replication.
`
`"there are two consequences to the late-sharing approach
`to survivability. First. the internrethate packet switching
`nodes. or gateways, must not have any essential 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 host machine than in an
`architecture where the network ensures
`the reliable
`delivery of data.
`If the host resident algorithms that
`ensure the sequencing and acknowledgment of data fail.
`applications on that machine
`are prevented
`from
`operation.
`
`Despite the the fact that survivability is the hrst goal in
`the list,
`it
`is still
`second to the top level goal of
`interconnection of existing networks. A more survivable
`
`technology might have resulted from a single multi-
`media network design. For example, the Internet makes
`very weak assumptions about the ability of a network to
`report that it has failed.
`Internet is thus forced to detect
`network failures using Internet level mechanisms. with
`the potential for a slower and less specific error detection.
`
`5. Types of Service
`
`The second goal of the lntemet architecture is that it
`should support, at the transport service level, a variety of
`types of
`service.
`Different
`types of service
`are
`distinguished by differing requirements for such things as
`speed, latency and reliability. The traditional
`type of
`service is the bidirectional reliable delivery of data. This
`service, which is sometimes called a "virtual circuit"
`service,
`is appropriate for such applications as remote
`login or file transfer.
`It was the first service provided in
`the lntemet architecture, using the Transmission Control
`Protocol (TCP)”.
`It was early recognized that even this
`service had multiple variants. because remote login
`required a service with low delay in delivery, but low
`requirements for bandwidth, while file transfer was less
`concerned with delay, but very concerned with high
`throughput. TCP attempted to provide both these types
`of service.
`
`The initial concept of TCP was that it could be general
`enough to support any needed type of service. However,
`as the run range of needed services became clear,
`it
`seemed too difficult to build support for all of them into
`one protocol.
`
`The first example of a service outside the range of TCP
`was support for MT”, the cross-Internet debugger.
`TCP did not seem a suitable transport for XNET for
`several reasons. First, a debugger protocol should not be
`reliable.
`This conclusion may seem odd, but under
`conditions of stress or failure (which may be exactly
`when a debugger
`is needed)
`asking for
`reliable
`communications may prevent any communications at all.
`It is much better to build a service which can deal with
`
`whatever gets through, rather than insisting that every
`byte sent be delivered in order. Second. if TCP is general
`enough to deal with a broad range of clients,
`it
`is
`presumably somewhat complex. Again, it seemed wrong
`to expect support for this complexity in a debugging
`environment. which may lack even basic
`services
`expected in an operating system (e. g. support for timers.)
`So XNET was designed to run directly on top of the
`daragram service provided by Internet.
`
`Another service which did not fit TCP was real
`
`time
`
`delivery of digitized speech. which was needed to Support
`the teleconferencing aspect of command and control
`applications.
`In real
`time digital speech,
`the primary
`requirement is not a reliable service, but a service which
`minimizes and smooths the delay in the delivery of
`packets.
`'nie application layer is digitizing the analog
`speech. packetizing the resulting hits, and sending them
`out across the network on a regular basis. They must
`SAP 1011
`
`|PR2014-00414
`
`Page 3 of 9
`
`108
`
`SAP 1011
`IPR2014-00414
`Page 3 of 9
`
`

`

`anive at the receiver at a regular basis in order to be
`convened back to the analog signal.
`If packets do not
`arrive when expected, it is impossible to reassemble the
`signal in real time. A surprising observation about the
`control of variation in delay is that
`the most serious
`source of delay in networks is the mechanism to provide
`reliable delivery. A typical reliable transport protocol
`responds
`to
`a missing
`packet
`by
`requesting
`a
`retransmission and delaying
`the delivery of
`any
`subsequent packets until
`the
`lost packet has been
`retransmitted.
`It
`then delivers
`that packet and all
`remaining ones in sequence. The delay while this occurs
`can be many times the round trip delivery time of the net.
`and may completely disnrpt
`the speech reassembly
`algorithm.
`In contrast,
`it
`is very easy to cope with an
`occasional missing packet.
`The missing speech can
`simply be replaced by a short period of silence. which in
`most cases does not
`impair the intelligibility of the
`speech to the listening human. If it does, high level error
`correction can occur. and the listener can ask the speaker
`to repeat the damaged phrase.
`
`It was thus decided, fairly early in the development of the
`Intemet architecture, that more than one transport service
`would be required, and the architecture must be prepared
`to tolerate simultaneously transports which wish to
`constrain reliability. delay. or bandwidth. at a minimum.
`
`This goal caused TCP and IP. which originally had been
`a single protocol in the architecture, to be separated into
`two layers. TCP provided one particular type of service,
`the reliable sequenced data stream, while [P attempted to
`provide a basic building block out of which a variety of
`types of service could be built. This building block was
`the datagram. which had also been adopted to support
`survivability. Since the reliability associated with the
`delivery or a datagrarn was not guaranteed, but "best
`effort." it was possible to build out of the datagram a
`service
`that was
`reliable
`(by
`acknowledging and
`retransmitting at a higher level). or a service which traded
`reliability for the primitive delay characteristics of the
`underlying network substrate.
`The User Datagram
`Protocol (UDP)'3 was created to provide a application-
`level interface to the basic datagram service of Internet.
`
`The architecture did not wish to assume that
`
`the
`
`underlying networks themselves support multiple types of
`services. because this would violate the goal of using
`existing networks.
`Instead. the hope was that multiple
`types of service could be constructed out of the basic
`datagram building block using algorithms within the host
`and the gateway. For example, (although this is not done
`in most current implementations) it
`is possible to take
`datagrams which are associated with a controlled delay
`but unreliable service and place them at the head of the
`transmission queues unless their lifetime has expired, in
`which case they would be discarded; while packets
`associated with reliable suearns would be placed at the
`back of the queues, but never discarded, no matter how
`long they had been in the net.
`
`than first hoped to provide
`It proved more difficult
`multiple types of service without explicit support from
`the underlying networks. The most serious problem was
`that networks designed with one particular type of service
`in mind were not
`flexible enough to support other
`services. Most commonly, a network will have been
`designed under the assumption that
`it should deliver
`reliable service, and will
`inject delays as a part of
`producing reliable service, whether or not this reliability
`is desired. The interface behavior defined by X.25, for
`example, implies reliable delivery, and there is no way to
`turn this
`feature off.
`Therefore, although Internet
`operates
`successfully over X25 networks
`it cannot
`deliver the desired variability of type service in that
`context.
`Other networks which have an intrinsic
`datagram service are much more flexible in the type of
`service they will permit. but these networks are much less
`common, especially in the long-haul context.
`
`6. Varieties of Networks
`
`It was very important for the success of the Internet
`architecture that it be able to incorporate and utilize a
`wide variety of network technologies. including military
`and commercial facilities. The Internet architecture has
`been very successful in meeting this goal: it is operated
`over a wide variety of networks, including long haul nets
`(the ARPANET itself and various X25 networks), local
`area nets (Ethernet, ringnet, etc.), broadcast satellite nets
`(the DARPA Atlantic Satellite Network" '5 operating at
`64 kilobits per second and the DARPA Experimental
`Wideband Satellite Net,” operating within the United
`States at 3 megabits per second), packet radio networks
`(the DARPA packet
`radio network,
`as well as an
`experimental British packet radio net and a network
`developed by amateur radio operators), a variety of serial
`links. ranging from 1200 bit per second asynchronous
`connections to T1 links. and a variety of other ad hoc
`facilities,
`including intercomputer busses
`and
`the
`transport service provided by the higher layers of other
`network suites, such as IBM's HASP.
`
`The Internet architecture achieves this flexibility by
`making a minimum set of assumptions about the function
`which the net will provide. The basic assumption is that
`network can transport a packet or datagram. The packet
`must be of reasonable size, perhaps [00 bytes minimum,
`and should be delivered with reasonable but not perfect
`reliability. The network must have some suitable form of
`addressing if it is more than a point to point link.
`
`There are a number of services which are explicitly not
`assumed from the network. These include reliable or
`sequenced delivery, network level broadcast or iiiultieast.
`priority ranking of
`transmitted packet.
`support
`for
`multiple types of service. and internal knowledge of
`failures, speeds. or delays.
`If these services had been
`required. then in order to accommodate a network within
`the lntemet. it would be necessary either that the network
`support
`these services directly. or
`that
`the network
`interface software provide enhancements to simulate
`
`l09
`
`SAP 1011
`
`|PR2014-00414
`
`Page 4 of 9
`
`SAP 1011
`IPR2014-00414
`Page 4 of 9
`
`

`

`It was felt
`these services at the endpoint of the network.
`that
`this was an undesirable approach. because these
`services would
`have
`to
`be
`re-engineered
`and
`reimplemented for every single network and every single
`host interface to every network. By engineering these
`services at the transport, for example reliable delivery via
`TCP. the engineering must be done only once, and the
`implementation must be done only once for each host.
`After that, the implementation of interface software for a
`new network is usually very simple.
`
`7. Other Goals
`
`The three goals discussed so far were those which had the
`most profound impact on the design on the architecture.
`The
`remaining goals, because they were lower
`in
`importance. were perhaps less effectively met. or not so
`completely
`engineered.
`The
`goal
`of permitting
`distributed management of the lntemet has certainly been
`met
`in certain respects.
`For example, not all of the
`gateways in the Internet are implemented and managed
`by the same agency.
`There are several different
`management centers within the deployed lntemet, each
`operating a subset of the gateways, and there is a two-
`tiered routing algorithm which permits gateways from
`different administrations to exchange routing tables, even
`though they do not completely trust each other and a
`variety of private routing algorithms used among the
`gateways in a single adminisrration.
`Similarly,
`the
`various organizations which manage the gateways are not
`necessarily the same organizations that manage the
`networks to which the gateways are attached.
`
`On the other hand, some of the most significant problems
`with the lntemet today relate to lack of sufficient tools for
`distributed management. especially in the area of routing.
`In the large intemet being currently operated. routing
`decisions need to be constrained by policies for resource
`usage. Today this can be done only in a very limited
`way, which requires manual setting of tables. This is
`error-prone and at
`the
`same time
`not
`sufficiently
`powerful. The most
`important change in the lntemet
`architecture over the next few years will probably be the
`development
`of
`a
`new generation
`of
`tools
`for
`management of resources in the context of multiple
`administrations.
`
`the lntemet
`in certain circumstances.
`is clear that
`It
`architecture does not produce
`as cost effective
`a
`utilization of expensive communication resources as a
`more tailored architecture would. The headers of Internet
`packets are fairly long (a typical header is 40 bytes), and
`if short packets are sent, this overhead is apparent. The
`worse case. of course, is the single character remote login
`packets. which carry 40 bytes of header and one byte of
`data. Actually. it is very difficult for any protocol suite to
`claim that these sorts of interchanges are carried out with
`reasonable efficiency.
`At
`the other extreme,
`large
`packets for file transfer. with perhaps 1,000 bytes of data,
`have an overhead for the header of only four percent.
`
`Another possible source of inefficiency is retransmission
`of lost packets. Since Internet does not insist that lost
`packets be recovered at
`the network level. it may be
`necessary to retransmit a lost packet from one end of the
`Imemet to the other. This means that the retransmitted
`packet may cross several intervening nets a second time,
`whereas recovery at the network level would not generate
`this repeat traffic. This is an example of the tradeoff
`resulting from the decision, discussed above, of providing
`services from the end-points. The network interface code
`is much simpler, but the overall efficiency is potentially
`less. However, if the retransmission rate is low enough
`(for example, 1%) then the incremental cost is tolerable.
`As a rough rule of thumb for networks incorporated into
`the architecture, a loss of one packet in a hundred is quite
`reasonable, but a loss of one packet in ten suggests that
`reliability enhancements be added to the network if that
`type of service is required.
`
`The cost of attaching a host to the lntemet is perhaps
`somewhat higher than in other architectures, because all
`of the mechanisms to provide the desired types of service,
`such as acknowledgments and retransmission strategies.
`must be implemented in the host
`rather than in the
`network. Initially, to programmers who were not familiar
`with protocol
`implementation,
`the effort of doing this
`seemed somewhat daunting.
`lmplementors tried such
`things as moving the transport protocols to a front end
`processor, with the idea that
`the protocols would be
`implemented only once. rather than again for every type
`of host. However, this required the invention of a host to
`front end protocol which some thought almost as
`complicated to implement as the original
`transport
`protocol. As experience with protocols increases,
`the
`anxieties associated with implementing a protocol suite
`within
`the
`host
`seem to
`be
`decreasing,
`and
`implementations are now available for a wide variety of
`machines,
`including personal
`computers
`and other
`machines with very limited computing resources.
`
`A related problem arising from the use of host-resident
`mechanisms
`is
`that
`poor
`implementation of
`the
`mechanism may hurt the network as well as the host. This
`problem was tolerated, because the initial experiments
`involved a limited number of host implementations which
`could be controlled. However, as the use of Internet has
`grown,
`this problem has occasionally surfaced in a
`seriOus way. In this respect, the goal of robustness, which
`led to the method of fate-sharing. which led to host-
`resident algorithms, contributes to a loss of robustness if
`the host this-behaves.
`
`In fact, accounting was
`The last goal was accountability.
`discussed in the first paper by Cerf and Kahn as an
`important
`function of the protocols and gateways.
`However. at the present time the Internet architecture
`contaim few tools1)for accountrn for packet flows. This
`problem is only now being studgied, as the scope of the
`architecture is being expanded to include non-military
`consumers who
`are
`seriously
`concerned with
`understanding and monitoring the usage of the resources
`within the intemet.
`
`“0
`
`SAP 1011
`
`|PR2014-00414
`
`Page 5 of 9
`
`SAP 1011
`IPR2014-00414
`Page 5 of 9
`
`

`

`8. Architecture and Implementation
`
`The previous discussion clearly suggests that one of the
`goals of the Internet architecture was to provide wide
`flexibility in the service offered. Different
`transport
`protocols could be used to provide different types of
`service, and different networks could be incorporated.
`Put another way, the architecture tried very hard not to
`constrain the range of service which the Internet could be
`engineered to provide.
`This.
`in turn. means that
`to
`understand the service which can be offered by a
`particular implementation of an Internet, one must look
`not to the architecture, but to the actual engineering of the
`software within the particular hosts and gateways, and to
`the particular networks which have been incorporated.
`I
`will use the term "realization" to describe a particular set
`of networks. gateways and hosts which have been
`connected together
`in the context of
`the
`Internet
`architecture.
`Realizations can differ by orders of
`magnitude in the service which they offer. Realizations
`have been built out of 1200 bit per second phone lines,
`and out of networks only with speeds greater than I
`megabit per second. Clearly. the throughput expectatiom
`which one can have of these realizations differ by orders
`of magnitude. Similarly, some Internet realizations have
`delays measured in tens of milliseconds. Where others
`have delays [treasured in seconds. Certain applications
`such as real time speech worlr fundamentally differently
`across these two realizations. Some Internets have been
`
`redundancy in the
`there is great
`engineered so that
`These Internets are survivable,
`gateways and paths.
`because resources exist which can be reconfigured after
`failure. Other lntemet realizations, to reduce cost, have
`single points of connectivity through the realization, so
`that a failure may partition the Internet into two halves.
`
`variety of
`this
`tolerates
`architecture
`Internet
`The
`realization by design. However. it leaves the designer of
`a particular realization with a great deal of engineering to
`do. One of the major struggles of this architectural
`development was to understand how to give guidance to
`the designer of a realization, guidance which would relate
`the engineering of the realization to the types of service
`which would result.
`For example,
`the designer must
`answer the following sort of question. What sort of
`bandwidths musr be in the underlying networks, if the
`overall service is to deliver a throughput of a certain rate?
`Given a certain model of possible failures within this
`realization. what
`sorts of
`redundancy ought
`to be
`engineered into the realization?
`
`Most of the known network design aids did not seem
`helpful in answering these sons of questions. Protocol
`verifiers. for example, assist in confirming that protocols
`meet specifications. However. these tools almost never
`deal with performance issues, which are essential to the
`idea of the type of service.
`Instead, they deal with the
`much more restricted idea of logical conectness of the
`protocol with respect
`to specification. While tools to
`verify logical
`correctness
`are useful, both
`at
`the
`specification and implementation stage. they do not help
`with the severe problems that often arise related to
`
`implementation experience is
`performance. A typical
`that even after logical correctness has been demonstrated,
`design
`faults
`are
`discovered that may
`cause
`a
`performance degradation of an order of magnitude.
`Exploration of this problem has led to the conclusion that
`the difficulty usuauy arises, not in the protocol itself, but
`in the operating system on which the protocol runs. This
`being the case,
`it
`is difficult to address the problem
`within the context of the architectural specification.
`However. we still strongly feel
`the need to give the
`implementor guidance. We continue to struggle with this
`problem today.
`
`The other class of design aid is the simulator, which takes
`a particular realization and explores the service which it
`can deliver under a variety of loadings. No one has yet
`attempted to construct
`a simulator which take into
`account
`the wide
`variability
`of
`the
`gateway
`implementation,
`the
`host
`implementation,
`and the
`network performance which one sees within possible
`Internet realizations.
`It is thus the case that the analysis
`of most Internet realizations is done on the back of an
`
`It is a comment on the goal structure of the
`env.elope
`Internet architecture that a back of the envelope analysis,
`if done by a sufficiently knowledgeable person is usually
`sufficient
`The designer of
`a particular
`Internet
`realization is usually less concerned with obtaining the
`last five percent possible in line utilization than knowing
`whether the desired type. of service can be achieved at all
`given the resources at hand at the moment.
`
`The relationship between architecture and performance is
`an extremely challenging one. The designers of the
`Internet architecture felt very strongly that
`it was a
`serious mistake to attend only to logical correctness and
`ignore
`the
`issue of performance.
`However.
`they
`experienced great difficulty in formalizing any aspect of
`performance constraint within the architecture. These
`difficulties arose both because the goal of the architecture
`was not
`to constrain performance, but
`to permit
`variability,
`and
`secondly
`(and
`perhaps more
`fundamentally). because there seemed to be no useful
`formal tools for describing performance.
`
`This problem was particularly aggravating because the
`goal of the Internet project was to produce specification
`documents which were to become military standards
`It
`is a well knOwn problem with government contracting
`that one cannot expect a contractor to meet any criteria
`which is not a part of the procurement standard.
`If the
`lntemet is concerned about performance, therefore, it was
`mandatory that performance requirements be put into the
`procurement specification.
`It was uivial
`to invent
`specifications which constrained the performance.
`for
`example to specify that
`the.
`implementation must be.
`capable of passing 1.000 packets a second. However, this
`sort of constraint could not be part of the architecture,
`and it was therefore up to the individual performing the
`procurement
`to
`recognize
`that
`these
`performance
`constraints must be added to the specification, and to
`specify them properly to achieve a realization which
`provides the required types of service. We do not have a
`
`rrr
`
`SAP 1011
`
`|PR2014-00414
`
`Page6of9
`
`SAP 1011
`IPR2014-00414
`Page 6 of 9
`
`

`

`good idea how to offer guidance in the architecture for
`the person performing this task.
`
`the history of TC? itself would
`complete revrew oi
`require another paper of this length.
`
`9. Datagrams
`
`The fundamental architectural feature of the Intemet is
`
`the use of datagrams as the entity which is transported
`across the underlying networks.
`As this paper has
`suggested, there are several reasons why datagrams are
`important within the architecture. First, they eliminate
`the need for connection state within the intermediate
`
`switching nodes, which means that the Internet can be
`reconstituted after a failure without concern about state.
`
`Secondly. the datagram provides a basic building block
`out of which a variety of types of service can be
`implemented.
`In contrast to the virtual circuit. which
`usually implies a fixed type of service,
`the datagram
`provides a more elemental service which the endpoints
`can combine as appropriate to build the type of service
`needed. Third,
`the dalagram represents the. minimum
`network service assumption, which has permitted a wide
`variety of networks to be incorporated into various
`Internet realizations.
`'l’he decrsron to use the datagram
`was an extremely successful one, which allowed the
`Internet
`to meet
`its most
`important
`goals
`very
`successfully.
`
`There is a mistaken assumption often associated with
`datagrams. which is that the motivation for datagrams is
`the support of a higher level servrce which is essentially
`equivalent
`to the datagram.
`In other words,
`it has
`sometimes been suggested that the datagmm is provided
`because the transport
`service which the application
`requires is a datagiam service.
`In fact. this is seldom the
`case. While some applications in the Internet, such as
`simple Queries of date servers or name sewers, use an
`access method owed on an unreliable datagram. most
`services within
`the
`[ntemet w0uld like
`a more
`sophistic