NJIT1

Distributed Multimedia Systems

Coulouris, Dollimore and Kindberg, Distributed Systems, Concepts and

Design, Chapter 17

Prepared by:

Pravin Kumar Katragadda

2

Introduction

Modern computers can handle streams of continuous, time-based data such as digital audio applications and video.

This capability has led to the development of distributed multimedia applications.

3

Introduction (contd..)

The requirements of multimedia applications significantly differ from real-time applications: Multimedia applications are highly distributed

and therefore compute with other distributed applications for network bandwidth and computing resources.

The resource requirements of multimedia applications are dynamic.

4

Figure 17.1 A distributed multimedia system

Wide area gateway Videoserver

DigitalTV/radioserver

Video cameraand mike

Local network Local network

5

Distributed Multimedia System

The above figure illustrates a typical distributed multimedia system, capable of supporting a variety of applications such as desktop conferencing, video-on-demand services, accessing stored video sequences using web-based multimedia and broadcast digital TV/ radio.

6

Web-based multimedia

These applications provide best effort access to streams of audio and video data published via the Web.

Their performance is constrained with limited bandwidth and variable latencies found in current networks.

These applications are most successful when there is little need for the synchronization of data streams.

7

Network phone and audio conferencing

These applications have relatively low bandwidth requirements when efficient compression techniques are used.

However, its interactive nature demands low round-trip delays which are not always achievable.

8

Video-on-demand services

These supply video information in digital form, retrieving data from large online storage systems and delivering them to user’s display.

These are successful only when dedicated network bandwidth is available and where the video server and the receiving stations are dedicated.

9

Figure 17.2 Window of scarcity for computing and communication

1980 1990

remotelogin

networkfile access

high-qualityaudio

interactivevideo

insufficientresources

scarceresources

abundantresources

2000

10

The Window of Scarcity

Many of today’s computer systems provide some capacity to handle multimedia data, but the necessary resources are very limited.

Especially, when dealing with large audio and video streams many systems are constrained in the quantity and quality of streams they can support. This situation is depicted as the Window of Scarcity.

11

The Window of Scarcity operation

If a certain class of application lies within this window, a system needs to allocate and schedule its resources carefully in order to provide the desired service.

Before the window of scarcity is reached, a system has insufficient resources to execute relevant applications.

Once an application class has left the window of scarcity, system performance will be sufficient to provide the service even under adverse circumstances.

12

Figure 17.3 Characteristics of typical multimedia streams

Data rate(approximate)

Sample or frame size frequency

Telephone speech 64 kbps 8 bits 8000/secCD-quality sound 1.4 Mbps 16 bits 44,000/secStandard TV video(uncompressed)

120 Mbps up to 640 x 480pixels x 16 bits

24/sec

Standard TV video (MPEG-1 compressed)

1.5 Mbps variable 24/sec

HDTV video(uncompressed)

1000–3000 Mbpsup to 1920 x 1080pixels x 24 bits

24–60/sec

HDTV videoMPEG-2 compressed)

10–30 Mbps variable 24–60/sec

13

Characteristics of multimedia data

Multimedia data (video and audio) is continuous and time-based. Continuous data is represented as sequence of

discrete values that replace each other over time. Time-based (or isochronous data) is so called because

timed data elements in audio and video streams define the semantics or content of the stream. The time at which the values are played effect the validity of the data. Hence, the timing should be preserved.

Multimedia systems are often bulky. Hence the data should be moved with greater throughput.

14

Characteristics of multimedia data (contd..)

Figure 17.3 shows typical data rates and frame/sample frequencies.

The resource bandwidth requirements for some are very large especially for video of reasonable quality.

A standard TV/Video stream requires more than 120 Mbps.

The figures for HDTV are even higher and in video-conferencing there is a need to handle multiple streams concurrently. Hence compression is used.

15

QoS Management

When multimedia run in networks of PCs, they compete for resources at workstations running the applications and in the network.

In multi-tasking operating system, the central processor is allocated to individual tasks in a Round-Robin or other scheduling scheme.

The key feature of these schemes is that they handle increases in demand by spreading the available resources more thinly between the competing tasks.

16

QoS Management (contd..)

The timely processing and transmission of multimedia streams in crucial. In order to achieve timely delivery, applications need guarantees that the necessary resources will be allocated and scheduled at the required times.

The management and allocation of resources to provide such guarantee is referred to as Quality of Service Management (QoS Management)

17

Figure 17.4 Typical infrastructure components for multimedia applications

Microphones

Camera

Screen

Window system

CodecD

BMixer

PC/workstation PC/workstation

CVideostore

Networkconnections

K

L

M

: multimedia stream

CodecA 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

18

Typical infrastructure components for multimedia applications (contd..)

The above figure shows the most commonly used abstract architecture for multimedia software.

Continuously flowing streams of media data elements are processed by a collection of processed and transferred between the processes by inter-process connections.

The processes produce, transform and consume continuous streams of multimedia data.

19

Typical infrastructure components for multimedia applications (contd..)

The connections link the processes in a sequence from a source of media elements to a target.

For the elements of multimedia data to arrive at their target on time , each process must be allocated adequate resources to perform its task and must be scheduled to use the resources sufficiently frequently to enable it to deliver the data elements in its stream to the next process on time.

20

Figure 17.5 QoS specifications for components in Figure 17.4

Component Bandwidth Latency Loss rate Resources required

Camera Out: 10 frames/sec, raw video640x480x16 bits

Zero

A Codec In:Out:

10 frames/sec, raw videoMPEG-1 stream

Interactive Low 10 ms CPU each 100 ms;10 Mbytes RAM

B Mixer In:Out:

2 44 kbps audio1 44 kbps audio

Interactive Very low 1 ms CPU each 100 ms;1 Mbytes RAM

H Windowsystem

In:Out:

various50 frame/sec framebuffer

Interactive Low 5 ms CPU each 100 ms; 5 Mbytes RAM

K Networkconnection

In/Out: MPEG-1 stream, approx.1.5 Mbps

Interactive Low 1.5 Mbps, low-lossstream protocol

L Networkconnection

In/Out: Audio 44 kbps Interactive Very low 44 kbps, very low-lossstream protocol

21

QoS specifications for components

The figure 17.5 sets out the resource requirements for the main software components and network connections (in Fig 17.4)

The required resources can be guaranteed only if there is a system component responsible for the allocation and scheduling of those resources.

We refer to that as the Quality of Service (QoS) manager.

22

Figure 17.6The QoS manager’s task

Application components specify their QoS requirements to QoS manager

Yes No

Yes No

Flow spec.

Resource contract

Admission control QoS negotiation

QoS manager evaluates new requirementsagainst the available resources.

Sufficient?

Reserve the requested resources

Allow application to proceed

Application runs with resources as per resource contract

Negotiate reduced resource provision with application.Agreement?

Do not allow application to proceed

Application notifies QoS manager of increased resource requirements

23

QoS Manager’s Tasks

The QoS Manager’s two main subtasks are: Quality of Service Negotiation Admission control

24

QoS Negotiation

The application indicates its resource requirements to the QoS manager.

To Negotiate QoS between an application and its underlying system an application must specify its QoS requirements to the QoS manager.

This is done by transmitting a set of parameters.

25

QoS Negotiation Parameters

Bandwidth: The rate at which data flows through a multimedia stream.

Latency: It is the time required for an individual data element to move through a stream from the source to the destination.

Loss Rate: The rate at which the data elements are dropped due to untimely delivery.

26

Traffic Shaping

Traffic shaping is the term used to describe the use of output buffering to smooth the flow of data elements.

The bandwidth parameter of a multimedia stream provides an idealistic approximation of the actual traffic pattern.

The closer the actual pattern matches the description, the better the system will handle the traffic.

27

LBAP Model of bandwidth variations

This calls for the regulation of burstiness of the multimedia streams.

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 can be illustrated using following algorithms: Leaky Bucket Token Bucket

28

Figure 17.7Traffic shaping algorithms

Token generator

(a) Leaky bucket (b) Token bucket

29

Leaky Bucket Algorithm

The bucket can be filled arbitrarily with water until it is full. Through a leak at the bottom of the bucket water will flow out.

The algorithm ensures that a stream will never flow at a rate higher than R.

The size of the buffer B defines the maximum burst a string an incur without losing elements.

This algorithm completely eliminates bursts.

30

Token Bucket Algorithm

The elimination of bursts in the previous algorithm is not necessary as long as bandwidth is bounded over any time interval.

The token bucket algorithm allows larger bursts to occur when the stream has been idle for a while.

Tokens are generated at a rate R and collected in a bucket of size B. Data can be sent only when atleast S tokens are in bucket.

This ensures that over any interval t the amount of data sent is not larger than Rt+B

31

Figure 17.8The 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:

32

Flow Specifications

A collection of QoS parameters is typically known as a flow specification, or flow spec for short.

Several examples for flow spec exists. In Internet RFC 1363 , a flow spec is defined as a 16-bit numeric values, which reflect the QoS parameters.

33

QoS Admission Control

Admission control regulates access to resources to avoid resource overload and to protect resources from requests that they cannot fulfill.

An admission control scheme is based on the overall system capacity and the load generated by each application.

34

QoS Admission Control

Bandwidth reservation: A common way to ensure a certain QoS level for a multimedia stream is to reserve some portion of resource bandwidth for its exclusive use.

Statistical multiplexing: It is based on the hypothesis that for a large number of streams the aggregate bandwidth required remains nearly constant regardless of the bandwidth of individual streams.

35

Resource Management

To provide a certain QoS level to an application, a system needs to have sufficient resources, it also needs to make the resources available to an application when they are needed (scheduling).

Resource Scheduling: A process needs to have resources assigned to them according to their priority. Following 2 methods are used: Fair Scheduling Real-time scheduling

36

Fair Scheduling

If several streams compete for the same resource, it becomes necessary to consider fairness and to prevent ill-behaved streams taking too much bandwidth.

A straight forward approach is to apply round-robin scheduling to all streams in the same class, to ensure fairness.

In Nagle, a method was introduced on a packet-by-packet basis that provides more fairness w.r.t varying packet sizes and arrival times. This is called Fair Queuing.

37

Real-time scheduling

Several algorithms were developed to meet CPU scheduling needs of applications.

Traditional real-time scheduling methods suit the model of regular continuous multimedia streams very well. Earliest-Deadline-First (EDF) scheduler uses

a deadline i.e. associated with each of its work items to determine the next item: The item with earliest deadline goes in first.

38

Stream Adaptation

The simplest form of adjustment when QoS cannot be guaranteed is adjusting its performance by dropping pieces of information.

Two methodologies are used: Scaling Filtering

39

Scaling Best applied when live streams are sampled. Scaling algorithms are media-dependent, although

overall scaling approach is the same: to subsample a given signal.

A system to perform scaling consists of a monitor process at the target and a scalar process at the source.

Monitor keeps track of the arrival times of messages in a stream. Delayed messages are an indication of bottle neck in the system.

Monitor sends a scale-down message to the source that scales up again .

40

Figure 17.9 Filtering

SourceTargets

High bandwidth

Medium bandwidth

Low bandwidth

41

Filtering

It is a method that provides the best possible QoS to each target by applying scaling at each target by applying scaling at each relevant node on the path from source to the target.

Filtering requires that a stream be partitioned into a set of hierarchical substreams, each adding a higher level of quality.

A substream is not filtered at an intermediate node if somewhere downstream a path exists that can carry the entire substream.

42

Case study: The Tiger video file server

A video storage system that supplies multiple real-time video streams simultaneously is an important component to support consumer oriented multimedia applications.

One of the most advanced prototypes of these is the Tiger video file server.

43

Design Goals

Video-on-demand for a large number of users.

Quality of Service Scalable and distributed Low cost hardware Fault tolerant

44

Figure 17.10 Tiger video file server hardware configuration

Controller

Cub 0 Cub 1 Cub 2 Cub 3 Cub n

ATM switching network

video distribution to clientsStart/Stop

requests from clients

low-bandwidth network

high-bandwidth

0 n+1 1 n+2 2 n+3 n+4 n 2n+13

45

Architecture

The cub computers shown in the Fig 17.10 are identical PCs with the same number of hard disk drives attached to each.

They are equipped with Ethernet and ATM network cards.

The controller is another PC, not involved in the handling of multimedia data and only responsible for handling client requests and the management of work schedules for the cubs.

46

Storage Organization

The key design issue is the distribution of video data among the disks attached to the cubs in order to enable them to share the load.

Schemes used: Striping, Mirroring Movies are stored in striped representation

among all disks. This could lead to a gap in the sequence of every movie if a disk fails. This is overcome by a storage mirroring scheme that replicates the data and a fault tolerance mechanism.

47

Distributed schedule

The heart of the Tiger’s design is the scheduling of the workload for the cubs. The schedule is organized as a list of slots where each slot represents the work that must be done.

There is exactly one slot for each potential client and each occupied slot represents 1 viewer receiving a real-time video data stream.

48

Distributed schedule (contd..)

The viewer state is represented by : Address of the client computer Identity of the file being played Viewer’s position in the file The viewer’s play sequence number Bookeeping information

49

Figure 17.11 Tiger schedule

012

slot 0

viewer 4

slot 1

free

slot 2

free

slot 3

viewer 0

slot 4

viewer 3

slot 5

viewer 2

slot 6

free

slot 7

viewer 1

block play time Tblock service

time t

state state state state state

50

Tiger Schedule

The block play time T is the time that is required by a viewer to display a block on the client computer.

Tiger must therefore maintain a time interval T between delivery times of the blocks.

Each cub maintains a pointer into the schedule for each disk that it controls.

51

Tiger Schedule (contd..)

The cub steps through the schedule in real-time processing slots as follows: Read the next block into buffer storage at the

cub. Packetize the block and deliver it to the cub’s

ATM network controller with the address of the client computer.

Update viewer state in the schedule to show the new next block and play sequence number and pass the updated slot to the next cub.

52

George Coulouris, Jean Dollimore and Tim Kindberg, Distributed Systems, Concepts and Design, Addison Wesley, Fourth Edition, 2005

Figures from the Coulouris text are from the instructor’s guide and are copyrighted by Pearson Education 2005

Bibliography