QoS Quality of Service Management Typical Service Characteristics - - PowerPoint PPT Presentation

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

Microphones Camera Screen Window system Codec D B Mixer PC/workstation PC/workstation C Video store Network connections K L M : multimedia stream Codec A G Codec H Window system White boxes represent media processing components, many of which are implemented in software, including: codec: coding/decoding filter mixer: sound-mixing component Video file system

QoS Specifications

Component Bandwidth Latency Loss rate Resources required Camera Out: 10 frames/sec, raw video 640x480x16 bits Zero A Codec In: Out: 10 frames/sec, raw video MPEG-1 stream Interactive Low 10 ms CPU each 100 ms; 10 Mbytes RAM B Mixer In: Out: 2 44 kbps audio 1 44 kbps audio Interactive Very low 1 ms CPU each 100 ms; 1 Mbytes RAM H Window system In: Out: various 50 frame/sec framebuffer Interactive Low 5 ms CPU each 100 ms; 5 Mbytes RAM K Network connection In/Out: MPEG-1 stream, approx. 1.5 Mbps Interactive Low 1.5 Mbps, low-loss stream protocol L Network connection In/Out: Audio 44 kbps Interactive Very low 44 kbps, very low-loss 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
• nly 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
• f 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
• verflowing 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

Token generator (a) Leaky bucket (b) Token bucket

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
• f 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

Token generator (a) Leaky bucket (b) Token bucket

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 Token bucket size Maximum transmission rate Minimum delay noticed Maximum delay variation Loss sensitivity Burst loss sensitivity Loss interval Quality of guarantee Bandwidth: Delay: Loss:

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
• f 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
• f 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

Admission Control - Details

• Regulates access to resources to avoid resource overload

and to protect resources from requests that they cannot fulfill

• It can involve turning down service requests should the

resource requirements violate existing QoS guarantees

• An admission control scheme is based on some knowledge
• f the overall system capacity and load generated by a

particular application

• Distributed resources require either a centralized admission

control entity or some distributed admission control algorithm that avoids conflicting concurrent admissions

Bandwidth Reservation

• Common technique - reserve some portion of the resource

bandwidth for an applications exclusive use

• A reservation needs to be made for its maximum bandwidth
• Unfortunately, capacity calculations are not always simple
• For example, to allocate CPU bandwidth requires that the

"execution profile" for each application be known - this can be hard to determine (there can be wide error margins and limited portability)

More on Bandwidth Reservation

• The actual bandwidth consumed by an application may

be significantly lower than its maximum bandwidth requirement (especially over time)

• Reservations based on maximum requirements can lead

to wasted resources

• A number of statistical methods do exist to help in this

area