QoS

1. QoS

2. Quality of Service and Resource Management are basic concepts and central focus in multimedia systems. • Data of continuous media needs real-time processing, communication and presentation to delivery their desired media quality to the user. • Hence, the overall system, i.e., each computing and communication service component in the end-to-end path must respond to the real-time requirements, and support certain service quality. • To provide a corresponding service quality, the system needs necessary system resources, e.g., • storage, network bandwidth, and processing bandwidth, to allocate and manage. Today, there exist two major approaches which can be applied either separately or simultaneously: • The most flexible and simple adjustment of multimedia streams onto a given computing and communication environment can be achieved by Scaling and Adaptation of media quality. In this case, the resources interact with the data stream to adapt the resource allocation. • The second approach considers individual service components and their corresponding resources, needed for multimedia processing and communication, and it reserves the required resources before the processing and communication of multimedia streams starts. This concept, called Resource Reservation, includes all resources along the end-to-end multimedia stream path. This concept can be also applied to parts of an application, which processes continuous media.

3. Requirements and Constraint • The Notion of “Real-Time” • The German National Institute for Standardization, DIN, similar to the American ANSI, defines a real-time process in a computer system as follows: • A real-time process is a process which delivers the results of the processing in a given time-span. • Deadlines • A deadline represents the latest acceptable time limit for the presentation of a processing or communication result. It marks the border between normal (correct) and anomalous (failing) behavior. A real-time system has both hard and soft deadlines.

4. Characteristics of Real-Time Systems • The necessity of deterministic and predictable behavior of real-time systems requires processing guarantees for time-critical tasks. • A real-time system is distinguished by the following features (c.f. [SR89]): • Predictably fast responseto time-critical events and accurate timing information. For example, in the control system of a nuclear power plant, the response to a malfunction must occur within a well-defined period to avoid a potential disaster. • A high degree of schedulability. Schedulability refers to the degree of resource utilization at which, or below which, the deadline of each time-critical task can be taken into account. • Stability under transient overload. Under system overload, the processing of critical tasks must be ensured. These critical tasks are vital to the basic functionality provided by the system.

5. Furthermore, real-time systems need to show the following properties to ensure timing guarantees: • Multi-tasking: A real-time application consists of various individual tasks. An appropriate partitioning of these tasks requires an appropriate CPU allocation, which then ensures that the tasks are not blocked due to other system events. • Short Interrupt Delays: Interrupt delay is the time interval between the generation of an electric signal (which shows the wish of a device to preempt the processors) and the execution of the first instruction with the help of the software interrupt handler. • Fast Context Switching: The context switch represents the time interval between the time, when the OS recognizes that a new process/thread (mostly a waiting process/thread in the process queue) needs to run, and the start time of the execution of this new process/thread. This switching activity then includes the correct preemption of the current process/thread (i.e., storing all registers with relevant process information such as program counter of the old process) and starting the new process (i.e., loading all registers with the relevant information of the new process). • Control of Memory Management: A virtual memory operating system, which aims to support real-time programming, must provide a way for the task to lock its code and data into real memory, so that it can guarantee predictable responses to an interrupt. • Proper Scheduling: To ensure that tasks run as the real-time application developer expects, the OS must provide a facility to schedule properly time-constrained tasks. • Fine Granularity of Timer Services: We need timers with fine granularity resolution in the range of millisecond and microseconds. • Rich Set of InterTask Communication Mechanisms: We need a support of time-sensitive IPC mechanisms such as message queues, shared memory, semaphores and event flags.

6. 1.1.4 Real-time Requirements on Multimedia Systems • Audio and video data streams consist of single, periodically changing values of continuous media data, e.g., audio samples or video frames. • Each Logical Data Unit (LDU) must be represented by a well-determined deadline. • Jitter is only allowed before the final presentation to the user. A piece of music, for example, must be played back at a constant speed. • To fulfill the timing requirements of continuous media, the operating system must use real-time scheduling techniques. • These techniques must be applied to all system resources involved in the continuous media data processing, i.e., the entire end-to-end data path is involved. • The CPU is just one of these resources—all components must be considered including • main memory, storage, • I/O devices and • networks.

7. The real-time requirements of traditional real-time scheduling techniques (used for command and control systems in application areas such as factory automation or aircraft piloting) have also a high demand for security and fault-tolerance. However, the requirements derived from these demands somehow counteract real-time scheduling efforts applied to continuous media. Multimedia systems, which are not used in traditional real-time scenarios, have different (in fact more favorable) real-time requirements:

8. The fault tolerance requirements of multimedia systems are usually less strict than those of traditional real-time systems. • A short time failure of a continuous media system will not directly lead to a destruction of technical equipment or constitute a threat to human life. • For many multimedia system applications, missing a deadline is not a severe failure, although it should be avoided. An occasional error may even go unnoticed. • Audio requirements are more stringent than video requirements because the human ear is more sensitive to audio gabs than the human eye is to presentation jitters of video media. • A sequence of digital continuous media data is the result of periodicallysampling a sound or image signal. Hence, in processing the data units of such a data sequence, all time-critical operations are periodic.

9. The bandwidth demand of continuous media is not always that stringent; it must not be a priori fixed, but it may be eventually lowered. As some compression algorithms are capable of using different compression ratios -- leading to different qualities -- the required bandwidth can be negotiated. • If not enough bandwidth is available for full quality, the application may also accept reduced quality (instead of no service at all). The quality may also be adjusted dynamically to the available bandwidth, for example, by changing encoding parameters. This is known as scalable video.

10. 1.1.5 Service and Protocol Requirements • The user/applications, utilizing Networked Multimedia Systems (NMS), put various requirements on their services and protocols. The requirements span from (1) time-sensitive requests, (2) high data throughput, (3) service guarantees, (4) high or partial reliability requests with timing constraints, to (5) cost-based fairness decisions: • Time-sensitive requirements are important because the audio/video communication needs to be bounded by deadlines or even defined within a time interval. • This requirement then implies that end-to-end jitter, synchronization skews among dependent streams, or end-to-end delay for conversational applications must be bounded. • High data throughput requirements come from the video representation of images and its stream-like behavior. This behavior can represent a long -lived requirement in case of applications such as video on demand or video conferencing.

11. Service guarantees requirements mean that processing and communication services must provide guarantees during the whole time the audio-visual media are processed and communicated within applications. • This means that the time-sensitive requirements and the high-throughput might be provided and sustained over a long period of time which is very different from previous data applications. • High or partial reliability requirements with timing constraints represent an important request on the multimedia system because traditional systems until now supported either unreliable or highly reliable processing and communication without any timing constraints. • Cost-based fairness requirements are triggered by the request for quality and resources allocated to provide timing and throughput service guarantees. The applications may request that if they pay the corresponding resource cost for its requested quality, then the quality of the audio-visual streams should be delivered to the applications. This means that the fairness principle to let every application process and communicate through FIFO queues will not apply here because in this case the timing requirements of the audio-visual streams could be violated.

12. 1.1.6 Processing and Communication Constraints • Due to the layered communication architectures, processing and communication services and protocols have also several constraints. The constraints include • (1) limitations to data movement, • (2) segmentation and reassembly of Protocol Data Units (PDU)s, • (3) error-recovery mechanisms, and others. • The data movement constraint relates to protocols which move a lot of data through the layered communication architecture. • This movement involves copying which is very expensive and has become a bottleneck. Therefore, new mechanisms for buffer management must be found. • The layered communication architecture considers different PDU sizes at different layers, therefore segmentation and reassembly operations on PDUs must occur. These operations must be done fast and efficiently. • Some parts of protocols may use error-recovery mechanisms via retransmission which imposes constraints on the buffer space for queues at the expense of larger end-to-end delays. These constraints must be considered when requesting the granularity of end-to-end timing guarantees.

13. 1.2 Quality of Service Concepts • The user/application requirements on multimedia systems need to be mapped into services which then make the effort to satisfy the requirements. • Due to the heterogeneity of requirements, services in multimedia systems must be parameterized. • Parameterization of requirements as well as underlying services allows for flexibility and customization of services. The result is the “quality-controllable services” which then allow to classify and differentiate system and communication services. • Parameterization of services was defined first in ISO (International Standard organization) standards through the notion of Quality of Service (QoS). • The ISO standard defined QoS as a concept for specifying how “good” the offered networking services are. Hereby, we will agree on the following understanding of the QoS notion: Quality of Service indicates the defined and controlling behavior of a service expressed through quantitative measurable parameter(s).

14. 1.2.1 Quality Layering • Traditional QoS (ISO standard) was defined for the network layer of the communication system. Further enhancement of the QoS concept was achieved through inducing QoS into transport services. • For networked multimedia systems the QoS concept must be further extended because many services besides network and transport services contribute to end-to-end quality behavior.

15. The QoS Model differentiates among users, application, system (including communication and operating system services), and individual device components. • The requirements and constraints analysis above suggests, too many layers in a communication architecture may impose a large performance overhead, hence low end-to-end quality and violation of user/application requirements on multimedia processing and communication. In case of a human user it is important to consider specification of perceptual QoS.

16. 1.2.2 Service Objects • Services are performed on different objects, for example, media sources, connections and Virtual Circuits (VC). Hence, the QoS parameterization reflects these service objects. • In ISO standards, the QoS description is meant to be for services processing transport and network connections (e.g., connection setup delay bound). In Tenet protocol suite, representing real-time protocols for multimedia delivery, transport and network services operate over real-time channels of a packet switched network, and the quality parameters describe allowed packet jitter over a real-time channel or end-to-end delay of a packet, sent over a real-time channel. In Lancaster’s Multimedia EnhancedTransport System (METS), a QoS parameter specification is given for a media call, transport connection, and VC objects. In Resource Reservation Protocol (RSVP), part of the Internet Integrated Services, a flow specification is given for parameterization and control of the packet scheduling mechanism in routers and hosts. At higher layers in communication systems, the service objects such as media or streams may be labeled with quality of service parameters. • In operating systems, which are an integral part in provision of the end-to-end quality guarantees, the service objects are tasks or memory chunks and they are characterized with quality parameters such as deadline, processing time, memory size, access pattern, to control the CPU bandwidth allocation and pinned memory bandwidth availability. • In middleware systems, service objects such as distributed objects, invocation methods, CORBA objects, software components are being labeled by quality parameters to control distributed services in timely fashion during their configuration, distribution, mapping and processing phases.

17. ´1.2.3 QoS Specification • The set of chosen parameters for the particular service determines what will be measured as the QoS. • Most of the current QoS parameters differ from the parameters described in ISO because of the heterogeneity of applications, media types, networks and end-systems. • The traditional ISO network layer QoS parameters included QoS parameters such as the throughput, delay, error rate, secrecy and cost. Figure shows the relationship among the QoS parameters throughput, delay and error rate.

18. The transport layer QoS parameters included connection establishment delay, connection establishment failure, throughput, transit delay, residual error rate, transfer failure probability, connection release delay, connection release failure probability, protection, priority, and resilience. These parameters were further expanded according to the layered model and led to many different QoS specifications. We give here one possible set of QoS parameters for each layer.

19. The perceptual QoS parameters need to allow for description of two major requirements: • (1) description of perceptive qualities such as media quality (e.g., excellent, good, or bad quality), windows size (e.g., big, small), response time (e.g., interactive, batch), security (e.g., high, low), and • (2) description of pricing choices, i.e., users should be able to specify the range of price they are willing to pay for the desired service. • Application QoS parameters describe requirements for application services in terms of • (1) media quality, including media characteristics (e.g., frame rate, frame resolution), and their transmission characteristics (e.g., end-to-end delay, jitter); • (2) media relations, specifying relations among media (e.g., media transformation, inter and intra frame synchronization skews),; and • (3) adaptation rules (e.g., actions if network bandwidth is scare) [NS95,KN97b]. • Application-level QoS specifications take different approaches to be represented. Possible approaches are: • (a) script-based approach, where QoS is added to script languages such as Tcl (e.g., QoS scripts written in SafeTcl, • (b) parameter-based approach, where QoS parameters are represented via data structures, i.e., application developers define data structures to express and declare qualitative and quantitative parameters • (c) process-oriented approach, where communicating end-ports, represented by processes, are associated with QoS • (d) control-based logic approach, where QoS specification describes adaptive policies and flow control to specify QoS changes • (e) aspect-based approach, where QoS specification is part of the aspect-oriented programming paradigm, i.e., QoS-related tasks are examples of so-called aspects • (f) object-oriented approach, where QoS specification is attached to an object.

20. System QoS parameters describe requirements, placed on communication and computing services, derived from application QoS. • They may be specified in terms of quantitative and qualitative criteria. Quantitative criteria represent concrete measures such as bit per second, number of errors, task processing time, task period. • The QoS parameters include then throughput, delay, response time, data rate, data corruption at the system level, task and buffer specifications. • Qualitative criteria specify the expected functions needed for provision of QoS such as interstream synchronization, ordered data delivery, error-recovery mechanisms, scheduling mechanisms and others. • The expected functions are then associated with specific parameters. For example, the interstream synchronization function is associated with an acceptable synchronization skew within the particular data stream.

21. Network QoS parameters describe requirements, placed on low level network services. They may be specified in terms of • (1) network load, describing the ongoing network traffic and characterized through average/minimal interarrival time on the network connection, burstiness, packet/cell size and service time in the node for a connection’s packet/cell and • (2) network performance, describing network service guarantees. Performance might be expressed through a source to destination delay bound for a packet, or packet loss rate, or others. Generally, network performance QoS parameters such as latency, bandwidth, or delay jitter are bounded, and the network QoS specification, represented through the traffic envelope, will carry the bounds as the contract parameters for network services.

22. Device QoS parameters typically specify timing and throughput demands for media data units given by audio/video devices such as audio speakers or video capture boards.

23. As a concrete and example of a layered QoS model, we will discuss application and system QoS parameters for MPEG compressed video streams. • Note that the application QoS is quite complex to express the source coding and to capture the compression algorithm behavior. Application and System QoS Parameters for MPEG Video Streams

24. Note that the classification of the QoS specification as described above happens due to the layered QoS model. However, there is also another angle which needs to be considered when specifying QoS parameters: Individual quality parameters at each level need to be classified into input QoS (QoSin) and output QoS (QoSout) parameters. This classification is crucial because the resulting output quality of service very much depends on the input quality of data into the service. It means that if the input data quality is poor, then even if the service has plenty of resources available for its processing and communication the output quality of the service may be poor. For example, if a display service receives only 10 frames per second from the video digitizer as the input QoS of the video stream, we can not display 30 different frames per second as the output QoS frame rate (we could display 30 frames per second if the display service has enough CPU resource, but only every 3rd frame would be different). The relation between the input QoS and output QoS might be defined through a servicecurve [Cru97] or a reward profile [LNH+97]. This relation then allows for decisions how to reach output quality starting from the input quality.

25. 1.2.4 QoS Parameter Values and Service Classes • The specification of QoS parameter values determines the type of service, called service class. There are at least three service classes: • guaranteed, • predictive and • best effort services. • This service class classification determines at least two important factors: • (1) reliability of the offered QoS, and • (2) utilization of resources.

26. The next Figure shows the reliability and utilization of resources for guaranteed and best effort classes.

27. Guaranteed services provide QoS guarantees, as specified through QoS parameter values (bounds) either in deterministic or statistical representation. The deterministic QoS parameters can be represented by positive real numbers at certain time, which means that: • where T is a time domain representing the lifetime of a service during which QoS should hold and R is the domain of positive real numbers representing the QoS parameter value. The overall QoS deterministic bounds can be specified by: • a single value (e.g., average value, contractual value, threshold value, target value); • a pair of values [QoSmin, QoSmax] (e.g., minimum and average values, lowest and target values) which can represent an interval of values with lower bound as the minimum value and upper bound as the maximum value.

28. The pair value specification also divides the QoS range into acceptable quality regions[QoSmin, QoSmax], and unacceptable quality regions QoS(t) < QoSmin as shown in the following Figure: • a triple of values can be also used to specify the overall QoS. For example, we can use best value QoSmax, average value QoSave, and worst value QoSmin.

29. Guaranteed services may also deal with statistical bounds of QoS parameters, such as statistical bound on packet error rate, bandwidth or others. For example, the requirement for bandwidth parameter value may be represented as probability P(B > Bmin) = p (i.e., probability that bandwidth B will be larger than the low bound Bmin is p, where p is close to 1.

30. A predictable service is based on past network behavior, hence the QoS parameter bounds are estimates of the past behavior which the service tries to match. For example, if predicted network bandwidth Bp was calculated as an average of the bandwidth which the service provided in the past, i.e., • where i=1,...n, Bi is a past history value, then the predictable service class could promise to provide bandwidth B up to Bp. In this example, the history values taken into account are from the start of the communication. One could also predict QoS parameter values based on a recent history. For example, if L is the length of the sliding bandwidth history window, then

31. Best effort services are services based on either no guarantees or partial guarantees. There is either no specification of QoS parameters required or a non-binding bound in deterministic or statistical forms is given. Most of the current computing and communication services are best effort services. • Multimedia services require guaranteed service class or at least a predictive service class, hence in our further discussion about QoS guarantees we will concentrate on these classes of service. • Note that various systems may provide different service classification: • IETF standard committee introduced Internet integrated service model[BCS94] which supports in addition to the traditional best effort Internet service also real-time services (guaranteed service class) and controlled load link sharing service. • ATM Forum standard committee considers four service classes: Constant Bit Rate (CBR), Variable Bit Rate (VBR), Available Bit Rate (ABR), and Unspecified Bit Rate (UBR) service classes. The VBR class is further refined supporting real-time VBR traffic class and non-real-time VBR traffic class.

32. 1.2.5 Quality-Aware Service Model • Now we refine the service model which is aware of its QoS and aims to deliver QoS guarantees. We will first define a single autonomous service and then a composite service which aims to deliver end-to-end QoS guarantees. • An autonomous single service consists of a set of functions and it accepts input data with a QoS level QoSin and it generates output data with a QoS level QoSout, both of which are vectors of QoS parameter values QoSin = [q1in, q2in,..., qnin], and QoSout = [q1out,..., qnout]. In order for the autonomous service to process input data of quality QoSin and generate output data of quality QoSout, a specific amount of resources R is required, where R is a vector of different resource requirements R = [r1, r2,..., rm] (e.g., CPU, memory, bandwidth).

33. Multimedia services consist of a set of services. Hence, a distributed multimedia service represents a composite service which is constructed through a sequence of autonomous services performing independent operations, such as transformations, synchronization, filtering, on the data stream passing through them. • Services can be connected into a directed acyclic graph (DAG), which is called the service graph. The quality-aware composite service is correct if the inter-service “satisfaction” relation is valid. • It means that if an autonomous service K is connected to an autonomous service M, then the output QoS of K (QoSoutK) must “match” the input QoS requirement of service M (QoSinM). More formally, QoSoutK “satisfies” QoSinM if and only if

34. where Dim(QoSK) represents the dimension of the vector QoSK. The single value QoS parameters include deterministic value such as frame resolution, or end-to-end delay bound. QoS parameters with range values are given through a pair of values as discussed above and can represent, for example a range of frame rates a video can be played at.

35. 1.3 Resources • When discussing provision of QoS, one must consider resources because the resource availability determines the actual output QoS which the network, OS or application services deliver. • A resource is a system entity required by tasks for manipulating data. Each resource has a set of distinguished characteristics and they can be classified as follows: • We differentiate between active and passive resources. • An active resource is a resource which provides a service. Examples of active resources are the processor unit or the network adapter for protocol processing. • A passive resource brings space required by active resources. Examples of passive resources are main memory, frequency range or file system. • A resource can be used by a process at a certain time point exclusively, or several processes can share a resource. Active resources can be mostly used exclusively, where passive resources are usually shared. • A resource which exists as a single entity in the computer system is called a single resource. If we have multiple entities of a resource in the computer system, we refer to the resource as a multiple resource. An example of a single resource is a video card in a PC. An example of a multiple resource is a parallel processor machine with multiple processors at work.

36. Each resource needs a certain capacity for accomplishment of a task. This capacity can be a processor bandwidth, a network bandwidth, or a memory space. For real-time processes, major interest is on the timely division of a resource capacity, i.e., not only how much resource a process can get but also when a process can get the requested resource. • The figure shows the most important resources of two end-systems communicating with each other over a router. The process management falls into the category of an exclusive, active, single resource; the file system over an optical storage with CD-ROM/XA format is a passive, shared resource.

37. 1.3.1 Resource Management • Multimedia systems with their intergrated audio and video processes reach often their capacity limits despite the usage of data compression and utilization of newest computing and communication technologies. • Current multimedia systems require therefore their own resource management; here the availability of resource reservation may provide an advantage for quality provision in these systems. The development phases with respect to available capacity and upcoming requirements are shown in the Figure.

38. Requirements Available, but Tight amount of resources Interactive Video missing resources Audio in CD-Quality Data transmission over network More than sufficient amount of resources Remote Login Hardware Resources in Year … 1980 1990 2000 2010 The “Window of Resources” matched towards current state of art

39. Application Source Application Source Local Resources System Software System Software System Software CPU Storage CPU Storage CPU Storage Network Resources Interaction among Resources

40. Frame Rate (fps) max. QoS resolution min. QoS resolution max. QoS-Frame-Rate 30 Acceptable Region 20 min. QoS-Frame-Rate 10 Unacceptable Region Resolution (Pixel) 0 80x40 640x480 Range Representaion of QoS Parameters (Video Data)

41. Application Requirements Required QoS with acceptable quality Desired QoS with high quality Increasing QoS Best effort class with possible conflicts Guaranteed class Reliability and Utilization of Resources for Guaranteed and Best Effort Classes