2 Multimedia Networking

8/11/2019 2 Multimedia Networking

http://slidepdf.com/reader/full/2-multimedia-networking 1/47

1

MultimediaNetworking



2

Outline

The Internet Protocol Stack (Review)MM networking applications

Multimedia over “best effort” Internet

Evolving the Internet to supportmultimedia apps

Stored media streaming (in some detail)

What will we cover in this course?



3

Internet protocol stack (Review 1/5)

application: supporting network applications FTP, SMTP, STTP

transport: host-host data transfer TCP, UDP

network: routing of datagrams from sourceto destination IP, routing protocols

link: data transfer between neighboringnetwork elements PPP, Ethernet

physical: bits “on the wire”

application

transport

network

link

physical



4

The Network Layer (Review 2/5)

End systems inject datagrams in the networks A transmission path is determined for each packet

(routing)

A “best effort” service

Datagrams might be lost Datagrams might be arrive out of order

Jitter in arrival of datagrams from the same stream

Analogy: Postal system



5

The Transport Layer (Review 3/5)

Concerned with end-to-end data transfer betweenend systems (hosts)

Transmission unit is called segment

TCP/IP networks such as the Internet provides

two types of services to applications “connection-oriented” service – Transmission Control

Protocol (TCP)

“connectionless” service - User Datagram Protocol (UDP)



6

Connection-oriented Service (Review 4/5)

Handshaking between client & server programs Parameters for ensuing exchange Maintain connection-state

Packet switches do not maintain any connection-state; hence “connection-oriented”

Similar to a phone conversation TCP is bundled with reliability, congestion control,

and flow control.



7

UDP: Connectionless Service (Review 5/5)

No handshaking Send whenever and however you want

A “best effort” service No reliability

No congestion & flow control services Why is it needed?



8

Outline








9

MM Networking Applications

Fundamentalcharacteristics:

Typically delay sensitive end-to-end delay

delay jitter But loss tolerant:

infrequent losses causeminor glitches

Antithesis of data,which are loss intolerantbut delay tolerant.

Classes of MM applications:1) Streaming stored audio

and video

2) Streaming live audio and

video3) Real-time interactive

audio and video

Jitter is the variabilityof packet delays withinthe same packet stream



10

Streaming Stored Multimedia (1/2)

VCR-like functionality: client canpause, rewind, FF, push slider bar

10 sec initial delay OK

1-2 sec until command effect OK need a separate control protocol?

timing constraint for still-to-betransmitted data: in time for playout



11

Streaming Stored Multimedia (2/2)

1. videorecorded

2. videosent

3. video received,played out at client

streaming: at this time, clientplaying out early part of video,while server still sending laterpart of video

networkdelay

time



12

Streaming Live Multimedia

Examples: Internet radio talk show

Live sporting event

Streaming

playback buffer playback can lag tens of seconds after

transmission

still have timing constraint

Interactivity

fast forward impossible

rewind, pause possible!



13

Interactive, Real-Time Multimedia

end-end delay requirements:

audio: < 150 msec good, < 400 msec OK• includes application-level (packetization) and network

delays

• higher delays noticeable, impair interactivity

session initialization

how does callee advertise its IP address, portnumber, encoding algorithms?

applications: IP telephony,video conference, distributedinteractive worlds



14

Outline








15

Multimedia Over “Best Effort” Internet

TCP/UDP/IP: no guarantees on delay, loss

Today’s Internet multimedia applicationsuse application-level techniques to mitigate

(as best possible) effects of delay, loss

But you said multimedia apps requiresQoS and level of performance to beeffective!

? ? ? ?

?

?

? ? ?

?

?



16

Outline










18

How to provide better support forMultimedia? (2/4)

Concerns with Intserv: Scalability: signaling, maintaining per-flow router

state difficult with large number of flows

Flexible Service Models: Intserv has only two

classes. Desire “qualitative” service classes E.g., Courier, xPress, and normal mail

E.g., First, business, and cattle class

Diffserv approach:

simple functions in network core, relativelycomplex functions at edge routers (or hosts)

Don’t define define service classes, providefunctional components to build service classes



19


Content DistributionNetworks (CDNs) Challenging to stream large

files (e.g., video) from singleorigin server in real time

Solution: replicate content athundreds of serversthroughout Internet

content downloaded to CDNservers ahead of time

placing content “close” touser avoids impairments(loss, delay) of sendingcontent over long paths

CDN server typically in

edge/access network

origin serverin North America

CDN distribution node

CDN server

in S. America CDN server

in Europe

CDN server

in Asia



20


R1

R2

R3 R4

(a)

R1

R2

R3 R4

(b)

duplicate

creation/transmissionduplicate

duplicate

Source-duplication versus in-network duplication.

(a) source duplication, (b) in-network duplication

Multicast/Broadcast



21

Outline

The Internet Protocol Stack (Review)

MM networking applications


Evolving the Internet to support multimedia apps

Stored media streaming (in some detail) Streaming Architectures

Real Time Streaming Protocol

Packet Loss Recovery




22

Internet multimedia: simplest approach

audio, video not streamed:

no, “pipelining,” long delays until playout!

audio or video stored in file files transferred as HTTP object

received in entirety at client

then passed to player



23

Streaming vs. Download of Stored MultimediaContent

Download: Receive entirecontent before playback begins

High “start-up” delay as mediafile can be large

~ 4GB for a 2 hour MPEG IImovie

Streaming: Play the media filewhile it is being received Reasonable “start-up” delays

Reception Rate >= playbackrate. Why?



24

Progressive Download

browser GETs metafile browser launches player, passing metafile

player contacts server

server downloads audio/video to player



25

Streaming from a streaming server

This architecture allows for non-HTTP protocol betweenserver and media player

Can also use UDP instead of TCP.



26

constant bitrate video

transmission

time

variable

networkdelay

client videoreception

constant bitrate video

playout at client

client playout

delay

b u f f e r e

d

v i d e o

Streaming Multimedia: Client Buffering

Client-side buffering, playout delay compensatefor network-added delay, delay jitter



27

Streaming Multimedia: Client Buffering

Client-side buffering, playout delay compensatefor network-added delay, delay jitter

buffered

video

variable fill

rate, x(t)

constantdrain

rate, d



28

Streaming Multimedia: UDP or TCP?

UDP server sends at rate appropriate for client (oblivious to

network congestion !)

often send rate = encoding rate = constant rate

then, fill rate = constant rate - packet loss

short playout delay (2-5 seconds) to compensate for networkdelay jitter

error recover: time permitting

TCP send at maximum possible rate under TCP

fill rate fluctuates due to TCP congestion control

larger playout delay: smooth TCP delivery rate

HTTP/TCP passes more easily through firewalls



29

Outline











30

Real-Time Streaming Protocol (RTSP)

HTTP Does not target multimedia

content

No commands for fastforward, etc.

RTSP: RFC 2326 Client-server application

layer protocol.

For user to control display:rewind, fast forward,

pause, resume,repositioning, etc…

What it doesn’t do: does not define how

audio/video is encapsulatedfor streaming over network

does not restrict how

streamed media istransported; it can betransported over UDP orTCP

does not specify how the

media player buffersaudio/video



31

RTSP Example

Scenario: metafile communicated to web browser

browser launches player

player sets up an RTSP control connection, data

connection to streaming server



32

Metafile Example

<title>Twister</title>

<session>

<group language=en lipsync>

<switch>

<track type=audio

e="PCMU/8000/1"src = "rtsp://audio.example.com/twister/audio.en/lofi">

<track type=audio

e="DVI4/16000/2" pt="90 DVI4/8000/1"src="rtsp://audio.example.com/twister/audio.en/hifi">

</switch>

<track type="video/jpeg"

src="rtsp://video.example.com/twister/video">

</group>

</session>



33

RTSP Operation



34

RTSP Exchange ExampleC: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0

Transport: rtp/udp; compression; port=3056; mode=PLAY

S: RTSP/1.0 200 1 OKSession 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231Range: npt=0-

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0Session: 4231Range: npt=37

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0Session: 4231

S: 200 3 OK



35

Outline











36

Packet Loss

network loss: IP datagram lost due to networkcongestion (router buffer overflow)

delay loss: IP datagram arrives too late forplayout at receiver delays: processing, queueing in network; end-system

(sender, receiver) delays

Tolerable delay depends on the application

How can packet loss be handled? We will discuss this next …



37

Receiver-based Packet Loss Recovery

Generate replacement packet Packet repetition

Interpolation

Other sophisticated schemes

Works when audio/video stream exhibits short-term self-similarity

Works for relatively low loss rates (e.g., < 5%)

Typically, breaks down on “bursty” losses

F d E C ti (FEC)



38

Forward Error Correction (FEC)

for every group of n packets generate k redundant

packets send out n+k packets, increasing the bandwidth by factor

k/n.

can reconstruct the original n packets provided at most k

packets are lost from the group Works well at high loss rate (for a proper choice of k)

Handles “bursty” packet losses

Cost: increase in transmission cost (bandwidth)





40

Interleaving: Recovery from packet loss

Interleaving

Re-sequence packets before transmission

Better handling of “burst” losses

Results in increased playout delay



41

Summary: Internet Multimedia: bag of tricks

use UDP to avoid TCP congestion control (delays)for time-sensitive traffic

client-side adaptive playout delay: to compensatefor delay

server side matches stream bandwidth to availableclient-to-server path bandwidth chose among pre-encoded stream rates

dynamic server encoding rate

error recovery (on top of UDP) FEC, interleaving

retransmissions, time permitting

conceal errors: repeat nearby data



42

What will we study in this course?

Empirical measurements

Multicast support IP Multicast, Application layer multicast

Content Distribution

Scalable streaming, CDNs Multimedia Rate Control

TCP overview, TCP Vegas, unicast and multicast ratecontrol protocol

Media streaming in wireless networks? Network Games?

Quality of Service Issues? … Any ideas?



43

Example: Streaming Popular Content

Consider a popular media file Playback rate: 1 Mbps

Duration: 90 minutes

Request rate: once every minute

Can a video server handle such high loads? Approach 1: Start a new “stream” for each

request

Allocate server and disk I/O bandwidth for

each request Bandwidth required at server= 1 Mbps x 90

How to improve efficiency?



44

Streaming Popular Content using Batching

Approach 2: Leverage the multipoint delivery

capability of modern networks Playback rate = 1 Mbps, duration = 90 minutes

Group requests in non-overlapping intervals of 30minutes:

Max. start-up delay = 30 minutes Bandwidth required = 3 channels = 3 Mbps

0 3

0

60 90 120 150 180 210 240

Time (minutes)

Channel 1

Channel 2

Channel 3



45

Batching Issues

Bandwidth increases linearly with decreasein start-up delays

Can we reduce or eliminate “start-up”

delays? Periodic Broadcast Protocols

Stream Merging Protocols

CDNs



46

Another Example: Streaming Live Multimedia

How to stream to large numbers of clients? Example: A popular sporting event

Use multicast/broadcast

What about client heterogeneity?

E.g., clients might have different available b/w Use layered/scalable video

Internet

Video Server

ADSL

Dial-up

High-speed

Access



Multimedia Networking

Exciting, industry relevant research topicMultimedia is everywhere

Tons of open problems

Questions?

Documents

2 Multimedia Networking