Network Working Group
`Request for Comments: 
`Category: Informational
`
`R. Braden
`ISI
`D. Clark
`MIT
`S. Shenker
`Xerox PARC
`July 
`
`Integrated Services in the Internet Architecture: an Overview
`
`Status of this Memo
`
`This memo provides information for the Internet community. This memo does not
`specify an Internet standard of any kind. Distribution of this memo is unlimited.
`
`Abstract
`
`This memo discusses a proposed extension to the Internet architecture and protocols
`to provide integrated services, i.e., to support real-time as well as the current non-real-
`time service of IP. This extension is necessary to meet the growing need for real-time
`service for a variety of new applications, including teleconferencing, remote seminars,
`telescience, and distributed simulation.
`
`This memo represents the direct product of recent work by Dave Clark, Scott Shenker,
`Lixia Zhang, Deborah Estrin, Sugih Jamin, John Wroclawski, Shai Herzog, and Bob
`Braden, and indirectly draws upon the work of many others.
`
`Contents
`
` Introduction
`
` Elements of the Architecture
`
`.
`
`Integrated Services Model
`
`: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
`
`. Reference Implementation Framework : : : : : : : : : : : : : : : : : : : : : : : : : :
`
` Integrated Services Model
`
`
`
`
`
`
`
`
`
`
`
` . Quality of Service Requirements
`
`: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 1
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
` . Resource-Sharing Requirements and Service Models
`
`: : : : : : : : : : : : : : : : : : 
`
` . Packet Dropping : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 
`
` . Usage Feedback : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 
`
` . Reservation Model
`
`: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 
`
` Trac Control Mechanisms
`
` 
`
`. Basic Functions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 
`
`. Applying the Mechanisms : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 
`
`. An example: The CSZ scheme
`
`: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 
`
` Reservation Setup Protocol
`
`
`
`. RSVP Overview : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 
`
`. Routing and Reservations : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 
`
` ACKNOWLEDGMENTS
`
`
`
`
`
`Introduction
`
`The multicasts of IETF meetings across the Internet have formed a large-scale experiment in
`sending digitized voice and video through a packet-switched infrastructure. These highly-visible
`experiments have depended upon three enabling technologies.
`  Many modern workstations
`now come equipped with built-in multimedia hardware, including audio codecs and video frame-
`grabbers, and the necessary video gear is now inexpensive.  IP multicasting, which is not yet
`generally available in commercial routers, is being provided by the MBONE, a temporary multicast
`backbone".   Highly-sophisticated digital audio and video applications have been developed.
`
`These experiments also showed that an important technical element is still missing: real-time
`applications often do not work well across the Internet because of variable queueing delays and
`congestion losses. The Internet, as originally conceived, oers only a very simple quality of ser-
`vice QoS, point-to-point best-eort data delivery. Before real-time applications such as remote
`video, multimedia conferencing, visualization, and virtual reality can be broadly used, the Internet
`infrastructure must be modied to support real-time QoS, which provides some control over end-
`to-end packet delays. This extension must be designed from the beginning for multicasting; simply
`generalizing from the unicast point-to-point case does not work.
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 2
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`Real-time QoS is not the only issue for a next generation of trac management in the Internet.
`Network operators are requesting the ability to control the sharing of bandwidth on a particular
`link among dierent trac classes. They want to be able to divide trac into a few administrative
`classes and assign to each a minimum percentage of the link bandwidth under conditions of overload,
`while allowing "unused" bandwidth to be available at other times. These classes may represent
`dierent user groups or dierent protocol families, for example. Such a management facility is
`commonly called controlled link-sharing. We use the term integrated services IS for an Internet
`service model that includes best-eort service, real-time service, and controlled link sharing.
`
`The requirements and mechanisms for integrated services have been the subjects of much discussion
`and research over the past several years the literature is much too large to list even a representative
`sample here; see the references in CSZ , Floyd , Jacobson , JSCZ , Partridge , SCZ ,
`RSVP a for a partial list. This work has led to the unied approach to integrated services
`support that is described in this memo. We believe that it is now time to begin the engineering
`that must precede deployment of integrated services in the Internet.
`
`Section  of this memo introduces the elements of an IS extension of the Internet. Section discusses
`real-time service models SCZ a, SCZ b. Section  discusses trac control, the forwarding
`algorithms to be used in routers CSZ . Section  discusses the design of RSVP, a resource setup
`protocol compatible with the assumptions of our IS model RSVP a, RSVP b.
`
` Elements of the Architecture
`
`The fundamental service model of the Internet, as embodied in the best-eort delivery service of IP,
`has been unchanged since the beginning of the Internet research project  years ago CerfKahn.
`We are now proposing to alter that model to encompass integrated service. From an academic
`viewpoint, changing the service model of the Internet is a major undertaking; however, its impact
`is mitigated by the fact that we wish only to extend the original architecture. The new components
`and mechanisms to be added will supplement but not replace the basic IP service.
`
`Abstractly, the proposed architectural extension is comprised of two elements:   an extended
`service model, which we call the IS model, and  a reference implementation framework, which
`gives us a set of vocabulary and a generic program organization to realize the IS model.
`It is
`important to separate the service model, which denes the externally visible behavior, from the
`discussion of the implementation, which may and should change during the life of the service
`model. However, the two are related; to make the service model credible, it is useful to provide an
`example of how it might be realized.
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 3
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`. Integrated Services Model
`
`The IS model we are proposing includes two sorts of service targeted towards real-time trac:
`guaranteed and predictive service. It integrates these services with controlled link-sharing, and it
`is designed to work well with multicast as well as unicast. Deferring a summary of the IS model to
`Section , we rst discuss some key assumptions behind the model.
`
`The rst assumption is that resources e.g., bandwidth must be explicitly managed in order to
`meet application requirements. This implies that resource reservation and admission control are
`key building blocks of the service. An alternative approach, which we reject, is to attempt to
`support real-time trac without any explicit changes to the Internet service model.
`
`The essence of real-time service is the requirement for some service guarantees, and we argue that
`guarantees cannot be achieved without reservations. The term guarantee" here is to be broadly
`interpreted; they may be absolute or statistical, strict or approximate. However, the user must
`be able to get a service whose quality is suciently predictable that the application can operate
`in an acceptable way over a duration of time determined by the user. Again, suciently" and
`acceptable" are vague terms. In general, stricter guarantees have a higher cost in resources that
`are made unavailable for sharing with others.
`
`The following arguments have been raised against resource guarantees in the Internet.
`
` Bandwidth will be innite."
`
`The incredibly large carrying capacity of an optical ber leads some to conclude that in the
`future bandwidth will be so abundant, ubiquitous, and cheap that there will be no commu-
`nication delays other than the speed of light, and therefore there will be no need to reserve
`resources. However, we believe that this will be impossible in the short term and unlikely
`in the medium term. While raw bandwidth may seem inexpensive, bandwidth provided as a
`network service is not likely to become so cheap that wasting it will be the most cost-eective
`design principle. Even if low-cost bandwidth does eventually become commonly available, we
`do not accept that it will be available everywhere in the Internet. Unless we provide for the
`possibility of dealing with congested links, then real-time services will simply be precluded in
`those cases. We nd that restriction unacceptable.
`
` Simple priority is sucient."
`
`It is true that simply giving higher priority to real-time trac would lead to adequate real-
`time service at some times and under some conditions. But priority is an implementation
`mechanism, not a service model. If we dene the service by means of a specic mechanism,
`we may not get the exact features we want. In the case of simple priority, the issue is that as
`soon as there are too many real-time streams competing for the higher priority, every stream
`is degraded. Restricting our service to this single failure mode is unacceptable.
`In some
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 4
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`cases, users will demand that some streams succeed while some new requests receive a busy
`signal".
`
` Applications can adapt."
`
`The development of adaptive real-time applications, such as Jacobson’s audio program VAT,
`does not eliminate the need to bound packet delivery time. Human requirements for inter-
`action and intelligibility limit the possible range of adaptation to network delays. We have
`seen in real experiments that, while VAT can adapt to network delays of many seconds, the
`users nd that interaction is impossible in these cases.
`
`We conclude that there is an inescapable requirement for routers to be able to reserve resources,
`in order to provide special QoS for specic user packet streams, or ows. This in turn requires
`ow-specic state in the routers, which represents an important and fundamental change to the
`Internet model. The Internet architecture was been founded on the concept that all ow-related
`state should be in the end systems Clark. Designing the TCPIP protocol suite on this concept
`led to a robustness that is one of the keys to its success. In section  we discuss how the ow state
`added to the routers for resource reservation can be made soft", to preserve the robustness of the
`Internet protocol suite.
`
`There is a real-world side eect of resource reservation in routers. Since it implies that some users are
`getting privileged service, resource reservation will need enforcement of policy and administrative
`controls. This in turn will lead to two kinds of authentication requirements: authentication of
`users who make reservation requests, and authentication of packets that use the reserved resources.
`However, these issues are not unique to IS; other aspects of the evolution of the Internet, including
`commercialization and commercial security, are leading to the same requirements. We do not
`discuss the issues of policy or security further in this memo, but they will require attention.
`
`We make another fundamental assumption, that it is desirable to use the Internet as a common
`infrastructure to support both non-real-time and real-time communication. One could alternatively
`build an entirely new, parallel infrastructure for real-time services, leaving the Internet unchanged.
`We reject this approach, as it would lose the signicant advantages of statistical sharing between
`real-time and non-real-time trac, and it would be much more complex to build and administer
`than a common infrastructure.
`
`In addition to this assumption of common infrastructure, we adopt a unied protocol stack model,
`employing a single internet-layer protocol for both real-time and non-real-time service. Thus, we
`propose to use the existing internet-layer protocol e.g., IP or CLNP for real-time data. Another
`approach would be to add a new real-time protocol in the internet layer ST- . Our unied stack
`approach provides economy of mechanism, and it allows us to fold controlled link-sharing in easily.
`It also handles the problem of partial coverage, i.e., allowing interoperation between IS-capable
`Internet systems and systems that have not been extended, without the complexity of tunneling.
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 5
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`We take the view that there should be a single service model for the Internet. If there were dier-
`ent service models in dierent parts of the Internet, it is very dicult to see how any end-to-end
`service quality statements could be made. However, a single service model does not necessarily
`imply a single implementation for packet scheduling or admission control. Although specic packet
`scheduling and admission control mechanisms that satisfy our service model have been developed,
`it is quite possible that other mechanisms will also satisfy the service model. The reference imple-
`mentation framework, introduced below, is intended to allow discussion of implementation issues
`without mandating a single design.
`
`Based upon these considerations, we believe that an IS extension that includes additional ow state
`in routers and an explicit setup mechanism is necessary to provide the needed service. A partial
`solution short of this point would not be a wise investment. We believe that the extensions we
`propose preserve the essential robustness and eciency of the Internet architecture, and they allow
`ecient management of the network resources; these will be important goals even if bandwidth
`becomes very inexpensive.
`
`. Reference Implementation Framework
`
`We propose a reference implementation framework to realize the IS model. This framework in-
`cludes four components: the packet scheduler, the admission control routine, the classier, and the
`reservation setup protocol. These are discussed briey below and more fully in Sections  and .
`
`In the ensuing discussion, we dene the ow" abstraction as a distinguishable stream of related
`datagrams that results from a single user activity and requires the same QoS. For example, a ow
`might consist of one transport connection or one video stream between a given host pair. It is the
`nest granularity of packet stream distinguishable by the IS. We dene a ow to be simplex, i.e.,
`to have a single source but N destinations. Thus, an N-way teleconference will generally require N
`ows, one originating at each site.
`
`In today’s Internet, IP forwarding is completely egalitarian; all packets receive the same quality of
`service, and packets are typically forwarded using a strict FIFO queueing discipline. For integrated
`services, a router must implement an appropriate QoS for each ow, in accordance with the service
`model. The router function that creates dierent qualities of service is called trac control".
`Trac control in turn is implemented by three components: the packet scheduler, the classier,
`and admission control.
`
` Packet Scheduler
`
`The packet scheduler manages the forwarding of dierent packet streams using a set of queues
`and perhaps other mechanisms like timers. The packet scheduler must be implemented at
`the point where packets are queued; this is the output driver level of a typical operating
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 6
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`system, and corresponds to the link layer protocol. The details of the scheduling algorithm
`may be specic to the particular output medium. For example, the output driver will need
`to invoke the appropriate link-layer controls when interfacing to a network technology that
`has an internal bandwidth allocation mechanism.
`
`An experimental packet scheduler has been built that implements the IS model described in
`Section and SCZ ; this is known as the CSZ scheduler and is discussed further in Section
`. We note that the CSZ scheme is not mandatory to accomplish our service model; indeed for
`parts of the network that are known always to be underloaded, FIFO will deliver satisfactory
`service.
`
`There is another component that could be considered part of the packet scheduler or separate:
`the estimator Jacobson . This algorithm is used to measure properties of the outgoing
`trac stream, to develop statistics that control packet scheduling and admission control.
`This memo will consider the estimator to be a part of the packet scheduler.
`
` Classier
`
`For the purpose of trac control and accounting, each incoming packet must be mapped into
`some class; all packets in the same class get the same treatment from the packet scheduler.
`This mapping is performed by the classier. Choice of a class may be based upon the contents
`of the existing packet headers andor some additional classication number added to each
`packet.
`
`A class might correspond to a broad category of ows, e.g., all video ows or all ows at-
`tributable to a particular organization. On the other hand, a class might hold only a single
`ow. A class is an abstraction that may be local to a particular router; the same packet
`may be classied dierently by dierent routers along the path. For example, backbone
`routers may choose to map many ows into a few aggregated classes, while routers nearer the
`periphery, where there is much less aggregation, may use a separate class for each ow.
`
` Admission Control
`
`Admission control implements the decision algorithm that a router or host uses to determine
`whether a new ow can be granted the requested QoS without impacting earlier guarantees.
`Admission control is invoked at each node to make a local acceptreject decision, at the time
`a host requests a real-time service along some path through the Internet. The admission
`control algorithm must be consistent with the service model, and it is logically part of trac
`control. Although there are still open research issues in admission control, a rst cut exists
`JCSZ .
`
`Admission control is sometimes confused with policing or enforcement, which is a packet-
`by-packet function at the edge" of the network to ensure that a host does not violate its
`promised trac characteristics. We consider policing to be one of the functions of the packet
`scheduler.
`
`In addition to ensuring that QoS guarantees are met, admission control will be concerned with
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 7
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`enforcing administrative policies on resource reservations. Some policies will demand authen-
`tication of those requesting reservations. Finally, admission control will play an important
`role in accounting and administrative reporting.
`
`The fourth and nal component of our implementation framework is a reservation setup protocol,
`which is necessary to create and maintain ow-specic state in the endpoint hosts and in routers
`along the path of a ow. Section  discusses a reservation setup protocol called RSVP for ReSer-
`Vation Protocol" RSVP a, RSVP b. It may not be possible to insist that there be only one
`reservation protocol in the Internet, but we will argue that multiple choices for reservation protocols
`will cause confusion. We believe that multiple protocols should exist only if they support dierent
`modes of reservation.
`
`The setup requirements for the link-sharing portion of the service model are far less clear than
`those for resource reservations. While we expect that much of this can be done through network
`management interfaces, and thus need not be part of the overall architecture, we may also need
`RSVP to play a role in providing the required state.
`
`In order to state its resource requirements, an application must specify the desired QoS using a
`list of parameters that is called a owspec Partridge . The owspec is carried by the reservation
`setup protocol, passed to admission control for to test for acceptability, and ultimately used to
`parametrize the packet scheduling mechanism.
`
`Figure shows how these components might t into an IP router that has been extended to provide
`integrated services. The router has two broad functional divisions: the forwarding path below the
`double horizontal line, and the background code above the line.
`
`The forwarding path of the router is executed for every packet and must therefore be highly
`optimized.
`Indeed, in most commercial routers, its implementation involves a hardware assist.
`The forwarding path is divided into three sections:
`input driver, internet forwarder, and output
`driver. The internet forwarder interprets the internetworking protocol header appropriate to the
`protocol suite, e.g., the IP header for TCPIP, or the CLNP header for OSI. For each packet, an
`internet forwarder executes a suite-dependent classier and then passes the packet and its class
`to the appropriate output driver. A classier must be both general and ecient. For eciency, a
`common mechanism should be used for both resource classication and route lookup.
`
`The output driver implements the packet scheduler. Layerists will observe that the output driver
`now has two distinct sections: the packet scheduler that is largely independent of the detailed
`mechanics of the interface, and the actual IO driver that is only concerned with the grittiness
`of the hardware. The estimator lives somewhere in between. We only note this fact, without
`suggesting that it be elevated to a principle..
`
`The background code is simply loaded into router memory and executed by a general-purpose CPU.
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 8
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`_____________________________________________________________
`____________
`____________
`___________
`|
`|
`|
`|
`| Reservation|
`|
`|
`|
`|
`|
`Routing |
`|
`Setup
`|
`| Management|
`|
`|
`|
`Agent
`|
`|
`Agent
`|
`|
`Agent
`|
`|
`|
`|______._____|
`|______._____|
`|_____._____|
`|
`|
`.
`.
`|
`.
`|
`|
`.
`.
`_V________ .
`|
`|
`.
`.
`| Admission| .
`|
`|
`.
`.
`| Control | .
`|
`|
`V
`.
`|__________| .
`|
`|
`Routing 
`V
`V
`|
`|
`Database
`Traffic Control Database
`|
`|
`|=============================================================|
`|
`|
`|
`_______
`|
`__________
`|
`|
`|
`|_|_|_|_| = o
`|
`_____
`|
`|
`| |
`|
`Packet
`|
`|
`|
`==== |Classifier| =====
`Scheduler
`|=== |_|_|_| ===
`|
`| |__________|
`|
`_______
`|
`|
`|
`|
`|
`|_|_|_|_| = o
`|
`Internet
`| Input |
`|
`|
`D r i v e r
`O u t p u t
`Forwarder
`| Driver |
`|
`|
`|________|__________________|_________________________________|
`
`Figure : Implementation Reference Model for Routers
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 9
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`These background routines create data structures that control the forwarding path. The routing
`agent implements a particular routing protocol and builds a routing database. The reservation
`setup agent implements the protocol used to set up resource reservations; see Section . If admission
`control gives the OK" for a new request, the appropriate changes are made to the classier and
`packet scheduler database to implement the desired QoS. Finally, every router supports an agent
`for network management. This agent must be able to modify the classier and packet scheduler
`databases to set up controlled link-sharing and to set admission control policies.
`
`The implementation framework for a host is generally similar to that for a router, with the addition
`of applications. Rather than being forwarded, host data originates and terminates in an application.
`An application needing a real-time QoS for a ow must somehow invoke a local reservation setup
`agent. The best way to interface to applications is still to be determined. For example, there
`might be an explicit API for network resource setup, or the setup might be invoked implicitly as
`part of the operating system scheduling function. The IP output routine of a host may need no
`classier, since the class assignment for a packet can be specied in the local IO control structure
`corresponding to the ow.
`
`In routers, integrated service will require changes to both the forwarding path and the background
`functions. The forwarding path, which may depend upon hardware acceleration for performance,
`will be the more dicult and costly to change. It will be vital to choose a set of trac control
`mechanisms that is general and adaptable to a wide variety of policy requirements and future
`circumstances, and that can be implemented eciently.
`
`
`
`Integrated Services Model
`
`A service model is embedded within the network service interface invoked by applications to dene
`the set of services they can request. While both the underlying network technology and the overlying
`suite of applications will evolve, the need for compatibility requires that this service interface remain
`relatively stable or, more properly, extensible; we do expect to add new services in the future but
`we also expect that it will be hard to change existing services. Because of its enduring impact,
`the service model should not be designed in reference to any specic network artifact but rather
`should be based on fundamental service requirements.
`
`We now briey describe a proposal for a core set of services for the Internet; this proposed core
`service model is more fully described in SCZ a, SCZ b. This core service model addresses
`those services which relate most directly to the time-of-delivery of packets. We leave the remaining
`services such as routing, security, or stream synchronization for other standardization venues. A
`service model consists of a set of service commitments; in response to a service request the network
`commits to deliver some service. These service commitments can be categorized by the entity to
`whom they are made: they can be made to either individual ows or to collective entities classes
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 10
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`of ows. The service commitments made to individual ows are intended to provide reasonable
`application performance, and thus are driven by the ergonomic requirements of the applications;
`these service commitments relate to the quality of service delivered to an individual ow. The service
`commitments made to collective entities are driven by resource-sharing, or economic, requirements;
`these service commitments relate to the aggregate resources made available to the various entities.
`
`In this section we start by exploring the service requirements of individual ows and propose a
`corresponding set of services. We then discuss the service requirements and services for resource
`sharing. Finally, we conclude with some remarks about packet dropping.
`
` . Quality of Service Requirements
`
`The core service model is concerned almost exclusively with the time-of-delivery of packets. Thus,
`per-packet delay is the central quantity about which the network makes quality of service commit-
`ments. We make the even more restrictive assumption that the only quantity about which we make
`quantitative service commitments are bounds on the maximum and minimum delays.
`
`The degree to which application performance depends on low delay service varies widely, and we can
`make several qualitative distinctions between applications based on the degree of their dependence.
`One class of applications needs the data in each packet by a certain time and, if the data has not
`arrived by then, the data is essentially worthless; we call these real-time applications. Another
`class of applications will always wait for data to arrive; we call these elastic applications. We now
`consider the delay requirements of these two classes separately.
`
` . . Real-Time Applications
`
`An important class of such real-time applications, which are the only real-time applications we ex-
`plicitly consider in the arguments that follow, are playback applications. In a playback application,
`the source takes some signal, packetizes it, and then transmits the packets over the network. The
`network inevitably introduces some variation in the delay of the delivered packets. The receiver
`depacketizes the data and then attempts to faithfully play back the signal. This is done by buer-
`ing the incoming data and then replaying the signal at some xed oset delay from the original
`departure time; the term playback point refers to the point in time which is oset from the original
`departure time by this xed delay. Any data that arrives before its associated playback point can
`be used to reconstruct the signal; data arriving after the playback point is essentially useless in
`reconstructing the real-time signal.
`
`In order to choose a reasonable value for the oset delay, an application needs some a priori
`characterization of the maximum delay its packets will experience. This a priori characterization
`
`Braden, Clark & Shenker
`
`Page 
`
`CISCO Exhibit 1006
`Cisco v. Bockstar
`Trial IPR2014 - 11
`
`

`

`RFC 
`
`Integrated Services in the Internet Architecture: an Overview
`
`July 
`
`could either be provided by the network in a quantitative service commitment to a delay bound, or
`through the observation of the delays experienced by the previously arrived packets; the application
`needs to know what delays to expect, but this expectation need not be constant for the entire
`duration of the ow.
`
`The performance of a playback application is measured along two dimensions: latency and delity.
`Some playback applications, in particular those that involve interaction between the two ends of
`a connection such as a phone call, are rather sensitive to the latency; other playback applications,
`such as transmitting a movie or lecture, are not. Similarly, applications exhibit a wide range
`of sensitivity to loss of delity. We will consider two somewhat articially dichotomous classes:
`intolerant applications, which require an absolutely faithful playback, and tolerant applications,
`which can tolerate some loss of delity. We expect that the vast bulk of audio and video applications
`will be tolerant, but we also suspect that there will be other applications, such as circuit emulation,
`that are intolerant.
`
`Delay can aect the performance of playback applications in two ways. First, the value of the oset
`delay, which is determined by predictions about the future packet delays, determines the latency of
`the application. Second, the delays of individual packets can decrease the delity of the playback
`by exceeding the oset delay; the application then can either change the oset delay in order to
`play back late packets which introduces distortion or merely discard late packets which creates
`an incomplete signal. The two dierent ways of coping with late packets oer a choice between
`an incomplete signal and a distorted one, and the optimal choice will depend on the details of the
`application, but the important point is that late packets necessarily decrease delity.
`
`Intolerant applications must use a xed oset delay, since any variation in the oset delay will
`introduce some distortion in the playback. For a given distribution of packet delays, this xed
`ose