Upload
ronny72
View
525
Download
5
Embed Size (px)
Citation preview
• Introduction
• Characteristics of multimedia data
• Quality of service management
• Resource management
• Stream adaptation
• Case study: the Tiger video file server
• Summary
Chapter 15: Distributed Multimedia Systems
• Distributed multimedia applications– Networked video library, Internet telephony, videoco
nference
• Characteristics of multimedia applications– Timely delivery of streams of multimedia data to en
d-users• Audio sample, video frame
• To meet the timing requirements– QoS( quality of service)
Characteristics of distributed multimedia applications
• Traditional real-time system– E.g. avionics, air traffic control, telephone switching– Small quantities of data, strict time requirement– QoS management: fixed schedule that ensures worst-c
ase requirements are always met
• Different requirements of multimedia app.– General environment
• Compete with other distributed app. for network bandwidth, computing resource
– Dynamic resource requirements • E.g. the number of participants of a video conference may va
ry
– User participant in the control of resource consumption
QoS management
• Web-based multimedia– Extensive buffering– Best-effort
• Network phone and audio conference– Relatively low bandwidth– Efficient compression techniques– High interactive latency
• Video-on-demand services– Require sufficient dedicated network bandwidth
Existing distributed multimedia Apps. without QoS
• Examples– Videoconference (cooperative)– Distributed online ensemble (synchronous)
• Requirements– Low-latency communication
• round trip delays < 100 ms
– Synchronous distributed state• If one user stops a video on a given frame, the other users should see it st
opped at the same frame
– Media synchronization• All participants in a music performance should hear the performance at a
pproximately the same time
– External synchronization• Sometime, other information need to be synchronized with the time-base
d multimedia streams
• Expecting rigorous QoS management
Highly interactive applications
• A history of computer systems that support distributed data access
The window of scarcity
1980 1990
remotelogin
networkfile access
high-qualityaudio
interactivevideo
insufficientresources
scarceresources
abundantresources
2000
• Introduction
• Characteristics of multimedia data
• Quality of service management
• Resource management
• Stream adaptation
• Case study: the Tiger video file server
• Summary
Chapter 15: Distributed Multimedia Systems
• Continuous– Refer to the user’s view of the data– Video: a image array is replaced 25 times per second– Audio: the amplitude value is replaced 8000 times
per second
• Time-based– The delivery delay for each element is bounded in a
value– Bulky multimedia stream– Data compression
• Reduce bandwidth requirements by factors between 10 and 100
• E.g. GIF, TIFF, JPEG, MPEG-1, MPEG-2, MPEG-4
Characteristics of multimedia data
• Introduction
• Characteristics of multimedia data
• Quality of service management
• Resource management
• Stream adaptation
• Case study: the Tiger video file server
• Summary
Chapter 15: Distributed Multimedia Systems
• Multimedia App. compete with other App. for– Processor cycles, bus cycles, buffer capacity– Physical transmission links, switches, gateways
• Best-effort policies– Multi-task OS: round-robin scheduling
• Each task is allocated so few cycles when there are so many tasks
– Ethernet: conflict detecting• Much collisions when the network is heavily loaded
• Best-effort policies are not fit to multimedia apps.
Traditional computer systems
• Architecture of a typical system– Source
• Stream processors
– Connections• Network connection
• In-memory transfer
– Target• Each process must be allocated adequate CPU time,
memory capacity and network bandwidth
• Resource requirement
QoS management for distributed multimedia apps.
• The OoS manager’s task– Quality of service negotiation
• Apps. specify the resource requirements
• QoS manager evaluates the feasibility
• Give a positive or negative response
– Admission control• Applications run under a resource contract
• Recycle the released resource
The QoS manager’s task
• Resource requirements specification– bandwidth
• The rate at which a multimedia stream flows
– Latency• The time required for an individual data element to
move through a stream from the source to the destination
– Loss rate• Data loss due to unmet resource requirements
• A rate of data loss that can be accepted. E.g., 1%
Quality of service negotiation
• Describe a multimedia stream– Describe the characteristics of a multimedia stream in
a particular environment– E.g. a video conference
• Bandwidth: 1.5Mbps; delay: 150ms, loss rate: 1%
• Describe the resources– Describe the capabilities of resources to transport a st
ream– E.g. a network may provide
• Bandwidth: 64kbps; delay: 10ms; loss rate: 1/1000
The usage of resource requirements spec.
• Bandwidth– Specified as minimum-maximum value or av
erage value• Required bandwidth varies according to the compression
rate of the video. E.g., 1:50 - 1:100 of MPEG video
– Specify burstiness• Different traffic patterns of streams with the same averag
e bandwidth
• LBAP model: Rt + B, where R is the rate, B is the maximum size of burst
Specify the QoS parameters for streams
• Latency– The frames of a stream should be processed with the
same rate at which frames arrive– No human perception
• E.g. 150ms for interactive apps, 500ms for demand on video
– No jitter• Jitter: the variation in the period between the delivery of two adjacent
frames
• Loss rate– Typically be expressed as a probability
• Be calculated based on worst-cast assumptions or on standard distributions
Specify the QoS parameters for streams (2)
• Traffic shaping– Output buffering to smooth the flow of data
elements
• The leaky bucket algorithm– Eliminate burst– R
• A stream will never flow with a rate higher than R
– B• Size of the buffer
• Bound the time for which an element will remain in the buffer
Traffic shaping
• The token bucket algorithm– Allow larger burst– Token is generated at a fixed rate of R– the tokens are collected in a bucket of size B– Data of size S can be sent only if at least S tokens a
re in the bucket– The sender process removes these S tokens– Ensure: over any interval t, the amount of data sent
is not larger than Rt+B, • An implementation of the LBAP model
Traffic shaping (2)
• Bandwidth– The maximum transmission unit and maximum trans
mission rate– The burstiness of the stream
• The token bucket size and rate
• Delay– The minimum delay that an application can notice, t
he maximum jitter it can accept
• Loss rate– The total acceptable number of losses over a certain i
nterval– The maximum number of consecutive losses
Flow specification – RFC 1363
• Simple approach– Follow the flow of data along each stream from the s
ource to the target• The source send out a flow spec to local QoS manager
• The manager check against its database of available resources whether the requested QoS can be provided
• The flow spec is forwarded to the next node until the last node
• The result is passed from the target to the source
• Transactional QoS negotiation procedure– Deal with concurrent QoS negotiations
Negotiation procedures
• Avoid resource overload• Bandwidth reservation
– Reserve maximum bandwidth exclusively• Used for applications that cannot adapt to different QoS le
vels, e.g. x-ray video
• Statistical multiplexing– Reserve minimum or average bandwidth– Handle burst that cause some service drop level occa
sionally– Hypothesis
• a large number of streams the aggregate bandwidth required remains nearly constant regardless of the bandwidth of individual streams
Admission control
• Introduction
• Characteristics of multimedia data
• Quality of service management
• Resource management
• Stream adaptation
• Case study: the Tiger video file server
• Summary
Chapter 15: Distributed Multimedia Systems
• Fair scheduling– Round-robin
• Packet-by-packet• Bit-by-bit
– Weighted fair queuing
• Real-time scheduling– Earliest-deadline-first (EDF)
• Each media element is assigned a deadline by which it must be sent out
• The scheduler send media elements according to their deadline
Resource scheduling
• Introduction
• Characteristics of multimedia data
• Quality of service management
• Resource management
• Stream adaptation
• Case study: the Tiger video file server
• Summary
Chapter 15: Distributed Multimedia Systems
• Stream adaptation– An application adapt to changing QoS levels
when a certain QoS cannot be guaranteed
• Drop pieces of information– Audio stream
• Drop can be noticed immediately by the listener
– Video stream• Motion JPEG: easy since frames are independent• MPEG: difficult since frames are interdependent
• Increase delay– Acceptable for non-interactive applications
Stream adaptation
• When to perform scaling– Adapt a stream to the bandwidth available in t
he system before it enters a bottleneck resource
• Scaling approach– Subsample
• E.g. reduce the rate of audio sample• E.g. drop a channel in a stereo transmission
– Implementation• A monitor process at the target• A scaler process at the source
Scaling
• Temporal scaling– Decrease the number of video frames transmitted within an int
erval
• Spatial scaling– Reduce the number of pixels of each image in an vide
o stream, e.g., JPEG and MPEG-2
• Frequency scaling– Modify the compression algorithm applied to an image
• Amplitudinal scaling– Reduce the color depths for each image pixel
• Color space scaling– Reduce the number of entries in the color space, e.g., from colo
r to grey-scale presentation
Different scaling methods
• Scaling is not suitable to a stream that has several receivers– Since scaling is conducted at the source, a scale-down
message will degrade the quality of all streams
• Filtering– A stream is partitioned into a set of
hierarchical sub-streams
– The capacity of nodes on a path determines the number of sub-streams a target receives
Filtering
• Introduction
• Characteristics of multimedia data
• Quality of service management
• Resource management
• Stream adaptation
• Case study: the Tiger video file server
• Summary
Chapter 15: Distributed Multimedia Systems
• Video-on-demand for a large number of users– A large stored digital movie library– Delay of receiving the first frame is within a few seconds– Users can perform pause, rewind, fast-forward
• Quality of service– Constant rate– a maximum jitter and low loss rate
• Scalable and distributed– Support up to 10000 clients simultaneously
• Low-cost hardware– Constructed by commodity PC
• Fault tolerant– Tolerant to the failure of any single server or disk
Design goals
• One controller – Connect with each server by low-bandwidth network
• Cubs – the server group– Each cub is attached by a number of disks ( 2-4)– Cubs are connected to clients by ATM
System architecture
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
• Stripping– A movie is divided into blocks
– The blocks of a movie are stored on disks attached to different cubs in a sequence of the disk number
– Deliver a movie: deliver the blocks of the movie from different disks in the sequence number
– Load-balance when delivering hotspot movies
• Mirroring– Each block is divided into several portions (secondaries)
– The secondaries are stored in the successors• If a block is on a disk i, then the secondaries are stored on disks i+1 to i
+d
– Fault-tolerance for single cub or disk failure
Storage organization
• Slot– The work to be done to play one block of a movie
• Deliver a stream– Deliver the blocks of the stream disk by disk– Can be viewed as a slot moving along disks step by step
• Deliver multiple streams– Multiple slots moving along disks step by step
• Viewer state– Network address of client– File ID for current movie– Number of next block– Viewer’s next play slot
Distributed schedule
• Block play time - T– The time that will be required for a viewer to display a block on
the client computer– Typically about 1 second for all streams– The next block of a stream must begin to be delivered T time
after the current block begin to be delivered
• Block service time – t ( a slot )– Read the next block into buffer– Deliver it to the client– Update viewer state in the schedule and pass the updated slot to
the next cub– T / t typically result in a value > 4
• The maximum streams the Tiger system can support simultaneously – T/t * the number of disks
Distributed schedule (2)
• Initial prototype [1994]– 5 x cubs: 133MHz Pentium PCs(48M RAM, 2G SCSI
disk, Windows NT), ATM network• 68 simultaneous streams with perfect quality• One cub failed, the loss rate is 0.02%
• 14 cubs: each 4 disks, ATM network [1997]– 602 simultaneous streams ( 2Mbps)– Loss rate < 0.01%; with one cub failed, loss rate <
0.04%
• The designers suggested that Tiger could be scaled to 1000 cubs supporting 30,000 clients.
• Microsoft NetShow Theater Server
Performance and scalability
• Introduction
• Characteristics of multimedia data
• Quality of service management
• Resource management
• Stream adaptation
• Case study: the Tiger video file server
• Summary
Chapter 15: Distributed Multimedia Systems
• Characteristics of distributed multimedia apps.– Large volumes of time-dependent data
• QoS management– QoS negotiation
• Bandwidth, latency, loss rate
• Traffic shapping: bucket leaky algorithm, token bucket leaky algorithm
– Admission control
• Schedule– Fair schedule– Real-time schedule
Summary
• Stream adaption– Scale– Filter
• The Tiger video file servers– Date layout
• Striping
• Mirroring
– Distributed schedule• slots
Summary
A typical distributed multimedia system
Wide area gateway Videoserver
DigitalTV/radioserver
Video cameraand mike
Local network Local network
Characteristics of typical multimedia streams
Data rate
(approximate)
Sample or frame frequency size
Telephone speech 64 kbps 8 bits 8000/sec
CD-quality sound 1.4 Mbps 16 bits 44,000/sec
Standard 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 Mbps up to 1920 x 1080pixels x 24 bits
24–60/sec
HDTV video
MPEG-2 compressed)
10–30 Mbps variable 24–60/sec
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
QoS specifications for components of the application shown in Figure 15.4
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
The 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
The 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: