Multimedia and networks
	Network Architectures for Multimedia Delivery
		Networked Multimedia Applications and their Impact on the Network Services
		March 1996
		Marek Podgorny
		NPAC
		Syracuse University
		111 College Place
		Syracuse
		New York 13244-4100
	Abstract of Network Architectures for Multimedia Delivery
		 
		Review of the networked multimedia presentations
		Requirements for the networking infrastructure supporting multimedia applications
			Application categorization
			Relevant network performance parameters
		Network technologies supporting multimedia delivery
			Multicast
			Switching technologies
			Quality of service guarantees (integrated services)
			ATM networks and multimedia
	Networked multimedia applications
		 
		Electronic documents with attached voice and video annotations
			(multimedia electronic mail, workgroup applications).
		Desktop conferencing: 
			two or more participants connected through the (inter)network,
			using audio/video, whiteboard, shared applications...
		Distance-learning courses offered as live broadcasts 
			or as video-on-demand, supported by 
			On-line textual material, on-line assignments, shared project areas etc.
	Networked multimedia applications (Continued)
		Television broadcasts over local-area networks (LANs).
		Interactive kiosks with multimedia product information and demonstrations.
		Multimedia databases that store traditional text as well as images, audio, and video clips. 
			Fully searchable digital libraries with instant delivery.
		3D navigation in real and abstract landscapes. 
		Simulation on demand with direct graphical output and interactive input.
	Multimedia Application Industry -- I
		 
		Hierarchical structure of the MM industry:
			Multimedia content providers: news industry,  television industry,  entertainment industry, multimedia CD-ROMs manufacturers.
				All these companies seek ways to deliver their products over the net.
			Multimedia application developers: distance learning, desktop videoconferencing, workgroup collaboration, multimedia kiosks, entertainment, imaging, video on demand. 
				All these applications need network support.
	Multimedia Application Industry (Continued)
		Multimedia platform builders: Of the computers sold in 1995, 80% was multimedia capable!
		Multimedia capable network infrastructure providers:
			Networking of multimedia is expected to initially occur in businesses over the private networking infrastructure (IntraNets).
			 In 1996,  a large demand is expected for  multimedia applications across public networks such as the Internet for home, education, business, and entertainment. 
		Our conclusion: Nearly all multimedia industry gears up to switch to networked applications.
	Categories of Net MM Apps -- I
		 
		As shown on next foil, for delivery over an internetwork, multimedia applications can be grouped into categories according to
			Their sensitivity to delay and the number of simultaneously connected network nodes. 
		Applications that use stored data streams are not delay-sensitive. 
		Applications that involve real-time interactivity are sensitive to network delay. 
		Point-to-point applications involve communication between a single pair of network nodes.
		Multipoint applications typically involve a broadcast to many network nodes. 
	Categories of Net MM Apps - II 
		Pictorial Representation of Time Sensitivity in Applications
	Multimedia Kiosks -- I
		 
		Multimedia kiosk is an important business application!
			The financial industry wants to use multimedia kiosks at banks to provide detailed information about financial services. 
			The retail industry wants to use kiosks in stores to help customers locate merchandise and find out additional information about merchandise. 
		Stand-alone kiosk are expensive to maintain. Networking is an operational necessity.
	Multimedia Kiosks - II
		The entertainment industry wants to use kiosks as 
			points of sale and to provide 
			advertising for scheduled entertainment events such as the theatre, concerts, plays, etc. 
		The entertainment industry is also interested in multimedia kiosks that allow  multi-person video games to occur over networks.
		Highway authorities plan kiosks with tourist information
	Multimedia Network Requirements - I - Overview
		 
		To provide a decent multimedia delivery infrastructure the network must provide three operational characteristics at an acceptable level:
			Bandwidth
			Consistent quality of service
			Efficient multipoint packet routing and delivery
		Two latter requirements are specific to multimedia network traffic. In the past, MM traffic was very limited. 
			With MM revolution just around the corner, the network providers and corporate IS departments face the task of general system reengineering.
		Fortunately, the technological solutions are available.
	Multimedia Network Requirements - II - Bandwidth
		Bandwidth requirements
			BW requirements differ  widely from application to application.
			Type of applications and the requested quality are main differentiating factors.
			Typical examples are shown on following foil
		Typical workstation on a corporate LAN has today available BW of 50 - 100 Kbps
		This bandwidth is only sufficient for simple MM applications
		Solution: switched broadcast networks - will be discussed later.
	Multimedia Network Requirements -  III - Bandwidth (Continued)
		Some Examples of Needed Network Bandwidth
	Multimedia Network Requirements  - IV - Bandwidth Scenarios
		 
		Typical scenarios for deficient bandwidth:
			I: Desktop machines running MM applications
				In this environment the most effective way of alleviating the bandwidth problem is network segmentation.
				However, if there is significant server-related traffic, segmentation is ineffective and a higher BW carrier is needed
	Multimedia Network Requirements  - V - Bandwidth Scenarios (Continued)
		Typical scenarios for deficient bandwidth--Contd:
		II: Campus backbone
			For the campus backbone the only  solution is a high-speed carrier. Current leading technology is FDDI but its position is being challenged by ATM. Taking this path is a very risky decision, though!
		III: Wide area network
			Very expensive (recurring cost!). Eventual solution: bandwidth on demand (ATM, but also inverse multiplexing of more traditional channels).
	Multimedia Network Requirements - VI - Quality of Service
		 
		
		Three major components in Quality of Service requirements:
			Guaranteed bandwidth (note this is different from available bandwidth)
			End-to-end latency
			Jitter (i.e. deviation from the average packet arrival time)
		None of these factors was a design parameter of todayÕs packet networks.
		Different applications running concurrently over the networks may have different service requirements: this imples need for an integrated service network able to handle data and stream applications.
		QoS support is  sometimes referred to as integrated services.
	Multimedia Network Requirements - VII- Quality of Service (Continued)
		 
		Guaranteed bandwidth requirement: how good are packet-switched networks for different types of applications?
			Constant bit rate applications
				Difficult on packet networks. With deficient BW they break, surplus BW not useful. Large buffers on client side about the only remedy if QoS absent.
			Variable bit rate applications
				Via statistical sharing VBR applications are more efficient on packet networks than on circuit switched networks. 
				QoS requirements only help with sophisticated application-level network resource scheduling.
			Available bit rate applications
				Packet networks are ideal transport for ABR apps. ABR apps adapt to the momentarily available bandwidth.
	Multimedia Network Requirements - VIII -- Latency
		 
		For MM applications network latency requirements are in general less stringent than for compute intensive applications.
			Compute Intensive often requires short round trip times 
			The latency is measured on the time scale of human perception.
			Latency  is of little relevance for one-way transmissions (up to a certain limit...) but is a potential nuisance for teleconferencing and for shared applications.
			 For these applications the latency should be kept below 0.5 sec.
	Multimedia Network Requirements -  IX - Latency (Continued)
		Latency issue is almost entirely under control (or lack thereof) of the networking gear vendors. 
			Almost every operation on a packet contributes to the total latency.
			Technologies such as cut-through (instead of store and forward) forwarding attempt to decrease the latency.
		More heterogenous networks usually induce higher latency due to packets encapsulation/header changes or segmentation and reassembly.
	Multimedia Network Requirements - X - Jitter
		 
		Jitter - audio quality killer
			Due to statistical factors, packets do not arrive in evenly spaced intervals. Instead, arrival time displays Guassian variation.
			Jitter is a problem for both audio and video streams.
			For audio, jitter may cause ÒhiccupÓ which is extremely annoying and adversely affects comprehension.
		For video, packets that arrive too late require complex logic in the decoder.
		Dropping the late packets may cause header loss and decoder confusion. 
		Processing the late packets compounds the synchronization problems.
		Remedy: network buffers, Bandwidth reservation, packet priority handling, etc.
	Multimedia Network Requirements - X I - Jitter   (Continued)
		 Typical Jitter Distribution
	Multimedia Network Requirements - XII - Multipoint Packet Delivery 
		 
		
		One-to-many and many-to-many applications are extremely expensive in terms of both network bandwidth and processing power on both workstations and on the routers. Typically, unicast and broadcast mechanisms are used:
			Unicast: the sending computer can send out a different copy of the data for each recipient. 
				Very wasteful of bandwidth, terrible scaling properties.
			Broadcast: the sending computer can send out a broadcast packet. The networking devices need to forward these packets to all portions of the network in order to ensure that they reach their intended recipients. 
				Also very wasteful of bandwidth. 
	Multimedia Network Requirements - XIII - Multipoint Packet Delivery (Continued) -- Multicast 
		Multicast: the sending computer can send out a multicast packet that is addressed to all the intended recipients. The network will replicate the packet when necessary. 
			It is a very efficient process.
			In order for multicast to work, the networking devices need to know which computers need to receive multicast traffic, and they need to be able to dynamically build efficient paths to all destinations. 
			Collective communication algorithms on parallel computers use this approach (if they are any good!)
	Multimedia QoS Support -- Introduction
		 
		Global solution of the multimedia QoS problem requires broad consensus of the network gear vendors on how to implement necessary protocols and measures. 
		All networking devices carrying the multimedia traffic must support the same set of mechanisms.
	Multimedia QoS Support -- General Mechanisms
		Among the mechanisms discussed for QoS Support, the most elementary are:
		Priority queuing: todayÕs packet networks are truly democratic and egalitarian - 
			FIFO is about the only packet forwarding strategy. 
			Priority queuing could alleviate jitter problems.
		Custom queuing: this is a bandwidth reservation mechanism. 
			It is less drastic than priority queuing as it schedules MM packets based on the specified jitter upper bound, not on the absolute priority.
	QoS -- ATM and Integrated Services Network
		 
		Two possible solutions:
		ATM networking technology - QoS is a build-in feature for this type of transport. This is probably a solution for tomorrowÕs GII backbone. Will it work in near future?
			100% ATM network will never happen. 
			ATM far more expensive than broadcast networks; new fiber/UTP cable plant needed, 
			Serious management and maintenance problems unsolved. 
			ATM QoS does not provide global QoS support.
	ATM versus Integrated Services Network 
		ATM Technology -- problems!
			ATM standards still in flux, implementations more so, LANE not universally available. Consequently, QoS mostly works on the paper.
			There is no API to the ATM QoS mechanisms. Hence, applications do not have any way to request such services.
		Solution -- Integrated services over the packet switched networks
			A new architecture on top of the current IP layer as opposed to ATM low level approach 
	Integrated Services for the Internet
		 
		In the following, we will discuss the emerging architecture implementing so called integrated services running on top of the existing Internet infrastructure.
		The integrated services infrastructure complements two other enabling technologies:
			Client multimedia hardware: 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: while not yet commonly available, it makes its way into Internet infrastructure. Integrated services architecture assumes multicast as a sine qua non component of future multimedia Internet
	Integrated Services: Additional Rationale -- Bandwidth Allocation - I
		 
		Real-time QoS is not the only issue for a next generation of traffic management in the Internet: network operators are requesting the ability to control the sharing of bandwidth on a particular link among different traffic classes.  
			They want to be able to divide traffic 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.  
	Integrated Services: Additional Rationale  -- Bandwidth Allocation II
		These network administration classes may represent different user groups or different protocol families, for example.  
			Such a management facility is commonly called controlled link-sharing. 
		Therefore, in the following,  the term  integrated services (IS) for an Internet service model includes  best-effort service, real-time service, and controlled link sharing.
	Integrated services: Architecture Elements - I
		 
		The fundamental service model of the Internet, as embodied in the best-effort delivery service of IP, has been unchanged since the beginning of the Internet research project.  
		Integrated services postulate a major change. 
			 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.
	Integrated services: Architecture Elements  - II
		The proposed architectural extension is comprised of two elements: 
			An extended service model, called the IS model, 
			A reference implementation framework, which provides a set of vocabulary and a generic program organization to realize the IS  model. 
		It is important to separate the service model, which defines  the externally visible behavior, from the discussion of the  implementation, which will evolve during the life of the service model.  
	Integrated Services Model - I
		 
		The IS model  includes two sorts of service targeted towards real-time traffic: 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. 
		We now discuss several basic assumptions of the model:
		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 is to attempt to support real-time traffic without any explicit changes to the Internet service model.
	Integrated Services Model - II -- Basic assumptions of the model
		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. 
			With this  approach one would lose the significant advantages of statistical sharing between real-time and non-real-time traffic, and it would be much more complex to build and administer than a common infrastructure.
	Integrated Services Model - III -- Basic assumptions of the model (Continued)
		 
		
		There is a unified protocol stack, employing a single Internet-layer protocol for both real-time and non-real-time service.  
			The IS model  proposes to use the existing Internet-layer protocol for real-time data.  
			Another approach would be to add a new  real-time protocol in the Internet layer.  
			Unified stack approach provides economy of mechanism, and it allows  one to fold in controlled link-sharing 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.
	Integrated Services Model - IV -- Basic assumptions of the model (Continued)
		There should be a single service model for the Internet.  
			If there were different service models in different   parts of the Internet, it is very difficult to see how any end- to-end service quality statements could be made.  
			Single service model does not necessarily imply a single implementation for packet scheduling or admission control.   It  is  possible to implement different mechanisms that  will also satisfy the  service model. 
	Integrated Services Model: Unnecessary? - I
		 
		Arguments have been raised against an integrated service model based on the assumptions we outlined. 
		In particular, the following arguments have been presented against the necessity of a complex reservation model:
			 ÒBandwidth will be infinite.Ó
				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-effective design principle.  
	Integrated Services Model: Unnecessary?  - II
		 ÒBandwidth will be infinite.Ó (Continued)
			Even if low-cost bandwidth does eventually become commonly available, it is unlikely  that it will be available ÒeverywhereÓ in the  Internet. 
			Hence, unless the network management  provides for the possibility of dealing  with congested links, then real-time services will simply be  precluded in those cases.
			In military applications, assume need for ÒTheater ExtensionsÓ with low bandwidth in major areas of activity linked to high bandwidth Global Information Infrastructure  
	Integrated Services Model: Unnecessary?    - III
		 
		Arguments against integrated services (continued):
		 ÒSimple priority is sufficient.Ó
			While it is true that simply giving higher priority to real-time traffic would lead to adequate real-time service at some times and under some conditions,  priority is an  implementation mechanism, not a service model.  
			If we define  the service by means of a specific 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 the service to this single failure mode is unacceptable. 
			 In some cases, users will demand that some streams succeed while some new requests receive a Òbusy  signalÓ.
	Integrated Services Model: Unnecessary?   - IV
		 People argue that: ÒApplications can adapt.Ó However ...
			The development of adaptive real-time applications does not eliminate the need to put an upper bound on packet delivery time.  
			Human requirements for interaction and intelligibility limit the possible range of adaptation to network delays.  
			It can be shown in real experiments that, while an application can adapt to network delays of many seconds, the users find that interaction is impossible in these cases.
	Integrated Services Model: Reservations - I
		 
		There is an inescapable requirement for routers  to be able to reserve resources, in order to provide special QoS  for specific user packet streams, or ÒflowsÓ.  
			This in turn requires flow-specific state in the routers, which represents a fundamental change to the Internet model:  the  Internet architecture has been founded on the concept that all flow-related state should be in the end systems.
			Designing the TCP/IP protocol suite on this concept  of end system flow control led to a robustness that is one of the keys to its success. 
			Adding flow state to the routers threatens Internet robustness!
	Integrated Services Model: Reservations  - II
		Therefore, the flow state added to the routers for resource reservation in the integrated services model is designed to be ÒsoftÓ, i.e., it is maintained by periodic ÒrefreshÓ.
		Since reservation implies that some users are getting privileged service, resource reservation  needs enforcement of policy and administrative controls. 
		This in turn calls for authentication of both users and packets.
			Incidentally, these issues are not unique to ÒISÓ: commercialization and commercial security are leading to the same  requirements.  
	Reference Implementation Framework Overview I
		 
		 The implementation framework includes four components: 
			The packet scheduler, 
			The admission control routine, 
			The classifier, 
			And the reservation setup protocol. 
		The first three items will be discussed in the following foils.
		The reservation protocol will be discussed is a separate presentation.
	Reference Implementation Framework  - Overview II
		It is important to understand that the implementation framework discussed below is essentially an example of how the IS model can be realized. 
		The framework is not a part of any proposed standard!
		This notwithstanding, the framework reveals the actual working model of the future Internet....
	Reference Implementation Framework  -- flow
		 
		The ÒflowÓ is a  distinguishable stream of related datagrams that results from a single user activity and requires the same QoS.  
			A flow might consist of one transport connection or one video stream between a given host pair.  
			A flow is the finest granularity of packet stream distinguishable by the IS.  
			A flow is assumed to be simplex,  i.e., to have a single source but N destinations.  Thus, an N-way  teleconference will generally require N flows, one originating at each site.
	Reference Implementation Framework  -- Router Function
		For integrated services, a router must implement an appropriate QoS  for each flow, in accordance with the service model.  
			The router  function that creates different qualities of service is called Òtraffic controlÓ.
			Traffic control in turn is implemented by three components: 
				The packet scheduler, 
				The classifier, 
				And admission control.
	Reference Implementation Framework -- Packet Scheduler I
		 
		
		The packet scheduler manages the forwarding of different   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 system, and  corresponds to the link layer protocol.  
		The details of the scheduling algorithm may be specific 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.
	Reference Implementation Framework -- Packet Scheduler II
		There is another component that could be considered part of  the packet scheduler or as a separate piece: the estimator. 
			This algorithm is used to measure properties of the outgoing  traffic stream
			To develop statistics that control packet scheduling and admission control. 
			This presentation will consider  the estimator to be a part of the packet scheduler.
	Reference Implementation Framework  -- Classifier I
		 
		
		For the purpose of traffic 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 classifier. Choice of a class may be based upon the contents of the existing packet header(s) and/or some additional classification number added to each packet.
	Reference Implementation Framework  -- Classifier II
		A class might correspond to a broad category of flows, e.g., all video flows or all flows attributable to a particular organization. 
			A class might also hold only a single flow.  
		A class is an abstraction that may be local to  a particular router; the same packet may be classified  differently by different routers along the path.  
			For example, backbone routers may choose to map many flows into a  few aggregated classes, while routers nearer the periphery, where there is much less aggregation, may use a separate class for each flow.
	Reference Implementation Framework -- Admission Control I
		 
		
		Admission control implements the decision algorithm that a  router or host uses to determine whether a new flow can be  granted the requested QoS without impacting earlier guarantees.  
		Admission control is invoked at each node to make a local accept/reject 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 traffic control.  
	Reference Implementation Framework -- Admission Control II
		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 traffic characteristics. 
			Packet level policing is considered  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 enforcing administrative policies on resource reservations.
			Some  policies will demand authentication of those requesting  reservations.  
		Finally, admission control will play an  important role in accounting and administrative reporting.
	Integrated Services Router -- Diagram
		 
		The router has two broad functional divisions:  the forwarding path below the double horizontal line, and the background code above the line.   
	Integrated Services Router  -- Forwarding Path
		 
		The forwarding path of the router is executed for every packet and usually involves a hardware assist. 
		The  path is divided into three sections: input driver,  Internet forwarder, and output driver.  
			The Internet forwarder  interprets the internet working protocol header appropriate to the  protocol suite.
			For each packet, an Internet forwarder executes a  suite-dependent classifier and then passes the packet and its  class to the appropriate output driver.  
			The output driver implements the packet scheduler. 
			It now has two distinct sections: the packet scheduler that is largely independent of the detailed  mechanics of the interface, and the actual I/O driver that is only concerned with the nitty gritty details of the hardware.
			The estimator lives somewhere in between.  
	Integrated Services Router -- Background Routines
		The 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.
				If admission control gives the ÒOKÓ for a new request, the appropriate changes are made to the classifier and packet  scheduler database to implement the desired QoS.   
			The network management agent must  be able to modify the classifier and packet scheduler databases to  set up controlled link-sharing and to set admission control policies.
	IS : Host Model and Routing Changes - I
		 
		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 flow must somehow invoke a local reservation setup agent.  
			The best way  to interface to applications is not determined yet. 
			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 classifier, since the class assignment for a packet can be specified in the local I/O control structure  corresponding to the flow.
	IS : Host Model and Routing Changes  -- II
		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 difficult and costly to change.
			It will be vital  to choose a set of traffic control mechanisms that is general and adaptable to a wide variety of policy requirements and future  circumstances, and that can be implemented efficiently.
	Integrated Service Model: Core Services - I
		 
		 A service model is embedded within the network service interface invoked by applications to define the set of services they can request.  
			For compatibility reasons, this service interface must remain relatively stable 
				(or, more properly, extensible; adding new services in the future should be possible but it is expected 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 specific network artifact but rather should be based on fundamental service requirements.
	Integrated Service Model: Core Services - II
		The core service model addresses those services which relate most directly to the time-of-delivery of packets. 
			Services as routing, security, or stream synchronization are subject of  other standardization venues.  
		Multicast -- Send one packet to bunch of places
		  RTP -- real Time Protocol
		 RSVP -- reservation Protocol
		will be discussed in later foilsets
	Integrated Service Model: Core Services - III
		 
		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 flows or to collective entities (classes of flows). 
			The service commitments made to individual flows 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 flow.  
	Integrated Service Model: Core Services - IV
		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 the following, we will explore the service requirements of  individual flows and describe 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.
	Integrated Service Model: Core Services- QoS - I
		 
		For QoS requirements, the core service model is concerned almost exclusively with the  time-of-delivery of packets. 
		Per-packet delay is the central quantity about which the network makes quality of service commitments. 
		Strictly speaking,  the only quantity about which a quantitative service commitments  can be made are bounds on the maximum and minimum delays. 
	Integrated Service Model: Core Services- QoS - II
		The degree to which application performance depends on low delay  service varies widely, and one 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 - these are real-time applications.  
			Another class of applications will always wait for  data to arrive;  these are ÒelasticÓ applications.  
		The taxonomy of applications into real time and elastic is neither exact nor complete. It is only used to guide the development of the core service model.
	Integrated Service Model: Core Services Playback Real-Time Apps - I
		 
		 An important class of such real-time applications: Ò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 buffering the incoming data and then replaying the signal at  some fixed offset delay from the original departure time; 
	Integrated Service Model: Core ServicesPlayback  Real-Time Apps - II
		The  term Òplayback pointÓ refers to the point in time which is offset from the original departure time by this fixed delay.  
		Data arriving after the  playback point is essentially useless.
		In order to choose a reasonable value for the offset delay, an  application needs some Òa prioriÓ characterization of the maximum delay its packets will experience.
		This Òa prioriÓ characterization 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.
	Integrated Service Model: Core ServicesPlayback Real-Time Apps - III
		 
		The performance of a playback application is measured along two dimensions:  latency and fidelity.  
			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; 
			Transmitting a movie or  lecture is not.  
			Similarly,  applications exhibit a wide range of sensitivity to loss of   fidelity.  
				Intolerant applications require an absolutely faithful playback, 
				Tolerant applications can tolerate some loss of fidelity.  
	Integrated Service Model: Core Services Playback  Real-Time Apps - IV
		Vast  majority of audio and video applications will be tolerant. 
		One can however envision applications, such as  circuit emulation, that are intolerant.
		Web based Computing is likely to be intolerant if synchronizing many nodes on a single application as delays at one point, will delay all nodes
		It is important to note that late packets always decrease fidelity, even if the applications has clever ÒadaptiveÓ ways of dealing with them
	Integrated Service Model: Core Services Playback Real-Time Apps - V -- intolerant
		 
		Hence, intolerant applications must use a fixed offset delay.  
			For a given distribution of packet delays, this fixed offset delay must be larger than the  absolute maximum delay, to avoid the possibility of late packets.
			Such an application can only set its offset delay  appropriately if it is given a perfectly reliable upper bound on the maximum delay of each packet.  
		A service characterized by a perfectly reliable upper bound on delay is called Òguaranteed serviceÓ.
		This is the appropriate service model for intolerant playback applications. 
	Integrated Service Model: Core Services Real-Time Apps - Tolerant - I
		In contrast, tolerant applications do not need to set their offset delay greater than the absolute maximum delay.  
			They can also attempt to  reduce their latency by varying their offset delays in response  to the actual packet delays experienced in the recent past (ÒadaptivityÓ).  
		For tolerant applications, the Òright: service model is Òpredictive serviceÓ which supplies a fairly reliable, but not perfectly reliable, delay bound.
	Integrated Service Model: Core Services Real-Time Apps - Tolerant/Predictive Service - II
		 
		
		For Òpredictive serviceÓ the  bound  is not based on worst case   assumptions on the behavior of other flows.  
		Instead, this  bound might be computed with properly conservative predictions  about the behavior of other flows.  
		If the network turns out to be wrong and the bound is violated, the applicationÕs  performance will perhaps suffer, but the users are willing to tolerate such interruptions in service in return for the presumed lower cost of the service.  
	Integrated Service Model: Core Services Real-Time Apps - Guaranteed v. Predictive Services
		Why two different services?
			The key consideration here is efficiency:
			When one relaxes the service requirements from perfectly to fairly reliable bounds, this increases the level  of network utilization that can be sustained, and thus the  price of the predictive service will presumably be lower than  that of guaranteed service. 
			The predictive service class is  motivated by the conjecture that the performance penalty will be small for tolerant applications but the overall efficiency gain will be quite large.
	Integrated Service Model: Core Services - Adaptive Real-Time Apps - I
		 
		Let us discuss accommodation of the ÒtrueÓ adaptive applications in the service model 
			A fundamental point of the overall IS architecture is that traffic characterization and admission control are necessary for these real-time delay bound  services.  
			So far one assumed that an applicationÕs data  generation process is an intrinsic property unaffected by the network.  
			However, there are likely to be many audio and video applications which can adjust their coding scheme and thus can alter the resulting data generation process depending on the network service available. 
	Integrated Service Model: Core Services - Adaptive Real-Time Apps - II
		This alteration of the coding  scheme will present a trade-off between fidelity (of the coding scheme itself, not of the playback process) and the bandwidth requirements of the flow.
		Such Òrate-adaptiveÓ playback  applications have the advantage that they can adjust to the current network conditions not just by resetting their playback point but also by adjusting the traffic pattern itself.  
		For  rate-adaptive applications, the traffic characterizations used  in the service commitment are not immutable.
		One can thus augment the service model by allowing the network to notify  (either implicitly through packet drops or explicitly through control packets) rate-adaptive applications to change their traffic characterization.
	Integrated Service Model: Core Services - Elastic Applications - I
		 
		 Elastic applications will always wait for data to arrive.   
			Elastic application typically uses the  arriving data immediately and will always choose to wait for the incoming  data rather than proceed without it.  These applications do not require any a  priori characterization of the service in order for the  application to function. 
			For a given distribution of packet delays, the perceived performance of elastic applications will depend more on the average delay than on the tail of the delay distribution.
		Categories of  elastic applications:
		interactive burst (Telnet, X, NFS),
		interactive bulk transfer (FTP), and
		asynchronous bulk transfer (electronic mail, FAX).  
	Integrated Service Model: Core Services - Elastic Applications - II
		
		The delay requirements of elastic applications vary from rather demanding for interactive burst applications to rather lax for asynchronous bulk transfer, with interactive bulk transfer being intermediate between them.
		An appropriate service model for elastic applications is to provide Òas-soon-as-possibleÓ, or ASAP (=best effort) service.
		One should offer several classes of best-effort service to reflect the relative delay sensitivities of  different elastic applications. 
		This service model allows  interactive burst applications to have lower delays than  interactive bulk applications, which in turn would have lower  delays than asynchronous bulk applications.
		Applications using this service are  not subject to admission control.
	Integrated Service Model: Core Services -- Analysis of Taxonomy - I
		 
		Although the applications taxonomy was rather crude, the core service model should be judged  on its ability to adequately meet the needs of the entire spectrum of   applications.  
			Not all real-time applications  are playback applications; 
			for example, one might imagine a visualization application which merely displayed the image encoded in each packet whenever it arrived.
			However, non- playback applications can still use either the guaranteed or  predictive real-time service model, although these services are not specifically tailored to their needs.  
	Integrated Service Model: Core Services -- Analysis of Taxonomy - II
		Similarly, playback applications cannot be neatly classified as either tolerant or  intolerant, but rather fall along a continuum. 
		Offering both guaranteed and predictive service allows applications to make their own trade-off between fidelity, latency, and cost.
		Despite these obvious deficiencies in the taxonomy, there are reasons to believe that it describes the service requirements of current and future applications well enough so that the Integrated Service model core services can adequately meet essentially all application needs. 
	Integrated Service Model: Core Services -- Resource Sharing - I
		 
		 The quantity of primary interest in resource-sharing is aggregate bandwidth on individual  links.  
		Òlink- sharingÓ component of the service model addresses the question of how to share the aggregate bandwidth of a link among various collective entities according to some set of specified shares.  
		 Multi-entity link-sharing
			A link may be purchased and used jointly by several organizations, government agencies or the like.
			They may wish to insure that under overload the link is shared in  a controlled way, perhaps in proportion to the capital investment of each entity.
			At the same time, they might wish that when the link is underloaded, any one of the entities could utilize all the  idle bandwidth.
	Integrated Service Model: Core Services -- Resource Sharing - II
		 Multi-protocol link-sharing 
			In a multi-protocol Internet, it  may be desired to prevent one protocol family (DECnet, IP, IPX, OSI, SNA, etc.) from overloading the link and excluding the other  families.
			Note that different families may have different methods of detecting and responding to congestion, and  some methods may be more ÒaggressiveÓ than others.
			This could lead  to a situation in which one protocol backs off more rapidly than  another under congestion, and ends up getting no bandwidth.  
	Integrated Service Model: Core Services -- Resource Sharing - III
		 
		Multi-service sharing 
			Within a protocol family such as IP, an administrator might wish to limit the fraction of bandwidth allocated to various service classes.
			For example, an administrator might wish to limit the amount of real-time traffic  to some fraction of the link, to avoid preempting elastic traffic such as FTP.
		 In general terms
			The link-sharing service model is to share the aggregate bandwidth according to some specified shares.
			A hierarchy of shares is possible.
	Integrated Service Model: Core Services -- Resource Sharing - IV
		Definition of a service supporting efficient link-sharing is difficult.
		There is a number of research models, including the idealized fluid model of instantaneous link-sharing with  proportional sharing of excess where at every instant the available bandwidth is shared between the active entities  in proportion to the assigned shares of the resource. 
		This fluid model exhibits the desired policy behavior but is an unrealistic  idealization. 
		The actual service model should be to approximate, as closely as possible, the bandwidth  shares produced by the ideal fluid model. 
		Actual implementation may be difficult!
	Integrated Services: Outstanding Issues
		 
		There is a number of issues that have not been discussed but are quite important:
			impact of packet dropping on the proposed core services
			Usage feedback (to prevent abuse of network resources)
			Reservation model (will be covered)
			Detailed traffic control mechanisms for
				packet scheduling, controlled packet dropping, packet classification, admission control
			Combination of the traffic control mechanisms to ensure
				guaranteed delay bounds, link sharing, predictive real time service
			Implementation of the soft state for the routers
		For these, access to the original literature is recommended