QoS Quality of Service Management
Typical Service Characteristics ● Workstations and networks have to support several multimedia and conventional applications ● Obviously, there's competition for resources ● Traditionally, OSes have employed round-robin (or similar schemes) to share processing resources on a best-effort basis ● Networks, too, are designed to allow different source traffic to be interleaved, e.g., Ethernet is best-effort and as collisions are likely to our when the network is heavily loaded, Ethernet cannot provide any guarantees
The Basic Problem Round-robin and other best-effort methods for sharing processor cycles and network bandwidth cannot meet the needs of multimedia applications
Typical Multimedia Infrastructure PC/workstation PC/workstation Window system Camera H K G A Codec Codec B L Microphones Mixer Network connections C Screen Video Video file system store D M Codec Window system : multimedia stream White boxes represent media processing components, many of which are implemented in software, including: codec: coding/decoding filter mixer: sound-mixing component
QoS Specifications Component Bandwidth Latency Loss rate Resources required Out: 10 frames/sec, raw video Zero Camera 640x480x16 bits A Codec In: 10 frames/sec, raw video Interactive Low 10 ms CPU each 100 ms; Out: MPEG-1 stream 10 Mbytes RAM B Mixer In: 2 44 kbps audio Interactive Very low 1 ms CPU each 100 ms; Out: 1 44 kbps audio 1 Mbytes RAM H Window In: various Interactive Low 5 ms CPU each 100 ms; system Out: 50 frame/sec framebuffer 5 Mbytes RAM K Network In/Out: MPEG-1 stream, approx. Interactive Low 1.5 Mbps, low-loss connection 1.5 Mbps stream protocol L Network In/Out: Audio 44 kbps Interactive Very low 44 kbps, very low-loss connection stream protocol
Notes on Infrastructure ● Most commonly used abstract architecture for multimedia software is the notion of "streams of continuously flowing media data" ● Hardware and software processes produce, transform and consume continuous streams of multimedia data ● It is clear that the required resources can be guaranteed only if there is a system component responsible for the allocation and scheduling of those resources ● This component is called the Quality of Service Manager
QoS Manager - Main Subtasks ● QoS Negotiation - evaluates the feasibility of meeting the requested requirements against a database of available resources and current resource commitments, then gives a positive or negative response ● Admission Control - the requested resources are reserved and the application is given a (time limited) resource contract ● Note that, while an application is running, there is a need for fine-grained scheduling of resources such as processor time and network bandwidth to ensure that real-time processes receive their allocated resources on time
QoS Negotiation - Details ● An application must specify its QoS requirements to the QoS manager ● This is accomplished by forwarding a set of appropriate parameters, including bandwidth, latency and loss rate ● Bandwidth - the rate at which data flows through the media stream ● Latency - the time required for an individual data element to move through a stream from the source to the destination (a variable rate of latency is referred to as "jitter") ● Loss Rate - how much data loss can be tolerated before it becomes a problem for the application in question
More on the Three Parameters ● Usage - To describe the characteristics of a multimedia stream in a particular environment ● Usage - To describe the capabilities of resources to transport a stream ● Loss rate rarely occurs due to bit errors (especially with modern hardware), but has more to do with buffer overflows and data arriving late - a large bandwidth experiencing a large delay will still suffer data loss ● Large buffers can lead to large delays (especially if they are full)
Specifying QoS ● Values of QoS parameters can be stated explicitly or implicitly ● It is more usual, however, to specify a value and a range of permissible values
Specifying Bandwidth ● Bandwidth - specified as maximum, minimum or average values ● The degree of burstiness can also be used as a specification value
Defining Burst Parameters ● Specifies “the maximum number of media elements that may arrive early” - before they should arrive according to their regular delivery schedule ● LBAP (Linear Bounded Arrival Process) can be used to define the maximum number of messages in a stream during any time interval (t) to be Rt + B, where "R" is the data rate and "B" is the maximum size of the burst ● The value for "B" defines the amount of buffer space required in order to avoid loss
Specifying Latency ● In order to avoid backlogs, a frame must on average not remain in a buffer to longer than 1/R, where is "R" is the frame rate of a stream ● A backlog (and its size) affects the maximum end-to-end delay experienced by the system ● Jitter can also be a problem - the variation in the period between the delivery of two adjacent frames ● Jitter is essentially solved by using appropriate buffering, but jitter removal is much more difficult to do
Specifying Loss Rate ● Very difficult to specify (calculate) ● Can be deduced from probability calculations about overflowing buffers and delayed messages ● Can be based on worst-case assumptions or on standard distributions ● Is one-in-five missed frames acceptable or one-in-a-million? ● Any loss rate specification needs to determine the time interval during which to expect a certain loss
Traffic Shaping ● This is the use of output buffering to smooth the flow of data elements ● The bandwidth parameter of a multimedia stream typically provides an idealistic approximation of the actual traffic pattern ● Any stream can be regulated by inserting a buffer at the source and by defining a method by which data elements leave the buffer - this is the classic "leaky bucket" mechanism
Traffic Shaping Algorithms (a) Leaky bucket (b) Token bucket Token generator
The Leaky Bucket ● Ensures that a stream will never flow with a rate higher than “R” (the speed with which it can leave the bucket) ● The size of the bucket (a buffer of size “B”) defines the maximum burst that can be handled without data loss ● “B” also bounds the time for which an element can remain in the bucket ● Leaky buckets can eliminate bursts (which may or may not be totally necessary)
The Token Bucket ● This algorithm allows allows larger bursts to occur ● Tokens to send data are generated at a fixed rate “R” ● Tokens are collected in a bucket of size “B” ● Data of size “S” can be sent if there are at least “S” amount of tokens in the bucket (after sending, “S” tokens are removed from the bucket) ● It can be shown that the token bucket algorithm implements the LBAP model: (Rt + B)
Traffic Shaping Algorithms (a) Leaky bucket (b) Token bucket Token generator
Flow Specifications ● A flow specification is a collection of QoS parameters ● In the Internet, flow specifications can be defined using RFC 1363, which provides for eleven 16-bit numeric values ● Other standards exist - SRP and ST-II (RFC 1190) are commonly cited examples
The Internet's RFC 1363 Flow Spec Protocol version Maximum transmission unit Token bucket rate Bandwidth: Token bucket size Maximum transmission rate Minimum delay noticed Delay: Maximum delay variation Loss sensitivity Loss: Burst loss sensitivity Loss interval Quality of guarantee
Using RFC 1363 Flow Specs ● The MTU and MTR determine the maximum bandwidth required by the stream ● The token bucket rate and size determine the burstiness of a stream ● Delay is specified by combining the maximum delay noticed and the maximum jitter (variation) ● Loss is defined by the total number of losses over some time and the maximum number of consecutive losses
Negotiation Procedures ● There needs to be a QoS manager at each node of a distributed multimedia application ● Straightforward approach - follow the flow of data along each stream from the source to the target ● The source sends out a flow specification to its local QoS manager ● The manager can then check against its local database to see if the request can be satisfied ● The flow specification then traverses all of the nodes until the final target is reached ● Success or failure is then passed back to the source at the end of this process
Comments on Straightforward Approach ● It is simple and satisfactory for most purposes ● Does not consider the possibilities of conflict between concurrent QoS negotiations ● A distributed transactional QoS negotiation procedure would provide a full solution to this problem ● Applications rarely have fixed QoS requirements ● More useful for the system to determine the QoS that it can provide, then let the application decide if it is acceptable or not ● Applications can also specify the desired and worst QoS values
Multiple Sinks ● If a stream has multiple sinks (destinations), the negotiation path forks according to the data flow ● The available bandwidth then becomes the smallest available bandwidth of all targets ● The delay becomes the longest of all targets ● The loss rate becomes the largest of all targets
Recommend
More recommend