Scalable On-demand Media Streaming with Packet Loss

Recovery

Anirban MahantiDepartment of Computer Science

University of CalgaryCalgary, AB T2N 1N4

Canada

2

Objectives Context:

Video-on-demand applications on the Internet, satellite & cable television networks

E.g., Online courses, movies, interactive TV Goals:

Scalable and reliable streaming

3

Outline Background

Reliable Periodic Broadcast (RPB)

SWORD Prototype

Summary

4

Video-on-Demand Distribution Model

A client can tune in to receive any ongoing media delivery using its Set Top Box

True broadcast: Satellite and cable TV networks Multipoint delivery provided in the Internet by

IP-Multicast or Application Level Multicast

VI DEO

SERVER

Multicast/ Broadcast Capable Network

STB STB STB

5

Traffic Assumptions 100s – 1000s requests for a media file per

play duration Skewed popularity of media files

10% – 20% of the files account for 80% of the requests

0

5

10

15

20

25

1 4 7 10 13 16 19 22 25 28Object

Acc

ess

Freq

uenc

y Zipf(0)

6

Scalable Streaming Protocols: Overview

Bounded Delay Protocols Batching, Periodic Broadcasts Tradeoff: start-up delay vs. bandwidth

Immediate Service Protocols Patching, Bandwidth Skimming Tradeoff: request rate vs. bandwidth

7

Batching Example Playback rate = 1 Mbps, duration = 90 minutes Group requests in non-overlapping intervals of

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

Bandwidth increases linearly with decrease in start-up delay

0 30

60 90 120 150 180 210 240Time (minutes)

Channel 1

Channel 2

Channel 3

8

Periodic Broadcast Example Partition the media file into 2 segments with relative

sizes {1, 2}. For a 90 min. movie: Segment 1 = 30 minutes, Segment 2 = 60 minutes

Advantage: Max. start-up delay = 30 minutes Bandwidth required = 2 channels = 2 Mbps

Disadvantage: Requires increased client capabilities

Time (minutes)

1

2

1 11 1 1

2 2

0 30 60 90 120 150 180

Channel 1

Channel 2

9

Skyscraper Broadcasts (SB) Divide the file into K segments of increasing size

Segment size progression: 1, 2, 2, 5, 5, 12, 12, 25, … Multicast each segment on a separate channel

at the playback rate Aggregate rate to clients: 2 x playback rate

Channel 1

Channel 2

Channel 3

Channel 4

Channel 5

Channel 6

A B

[Hua & Sheu 1997]

10

Harmonic Broadcasts [Juhn & Tseng, 1998]

11

Performance Comparisons

1ln1

0min dTdx

dxB

TPB

12

Periodic Broadcast Protocols: Summary

Lower bound tells us that just-in-time delivery results in least server bandwidth usage

Protocols such as Skyscraper broadcast the initial portion more often than the later portions

Harmonic Broadcasting attempts to delay the delivery of media by using low rate channels

Periodic broadcast very short latency to play the media (nearly) minimum server bandwidth

Internet delivery ? How to provide packet loss recovery?

13

“Digital Fountain” Approach

• A single multicast stream of FEC encoded data• Each client listens until P packets arrive• Client decodes after all packets arrive (long latency)

SERVER

NETWORK

[Vicisano et al. 1998, Byers et al.1998]

14

Periodic Broadcasts: Performance

Lower Bound:

0

10

20

30

0.0001 0.001 0.01 0.1 1

Start-up Delay (fraction of total stream duration)

Req

uire

d Se

rver

B

andw

idth

Piecewise DigitalFountain

Skyscraper

Lower Bound(Loss = 10%)

pd

Tdxdx

B TPB

111ln1

0min

15

Unicast Service

Broadcast/Multicast Service

Digital Fountain

(bulk data)

Reliable Delivery

Delivery Techniques: Summary

??

ImmediateStreaming

Unicast Streaming

Bandwidth Skimming

Patching

BoundedDelay

Streaming

Batching

Periodic Broadcasts

16

Outline

Background

Reliable Periodic Broadcast (RPB)

SWORD Prototype

Rate Adaptation

Quality Adaptation

Summary

17

Packet Loss Recovery Make each channel a Digital Fountain Is Skyscraper amenable to the Digital

Fountain approach? No! Some segments played while being received Reception schedule requires tuning into

channels at precise times Other limitations of Skyscraper:

Ad hoc segment size progress Does not work for low client data rates

18

Reliable Periodic Broadcasts (RPB)

Optimized PB protocols (no packet loss recovery) client fully downloads each segment before

playing required server bandwidth near minimal Segment size progression is not ad hoc Works for client data rates < 2 x playback rate

extend for packet loss recovery extend for “bursty” packet loss extend for client heterogeneity

19

Optimized Periodic Broadcasts

r = segment streaming rate = 1 s = maximum # streams client listens to concurrently = 2 b = client data rate = s x r = 2

length of first s segments:

length of segment k s:

1

11

11 k

jjk ll

rl

r

11 k

skjjk ll

r

Channel 1Channel 2Channel 3Channel 4Channel 5Channel 6

20

Optimized PB: Performance

r = segment transmission rate,s = max. # streams client listens to concurrentlyb = client data rate = s x r

0

5

10

15

20

0.0001 0.001 0.01 0.1 1Start-up Delay

(fraction of stream duration)

Req

uire

d Se

rver

B

andw

idth

Skyscraper

Optimized PB(b=2, s=2)Optimized PB(b=2, s=8)Lower Bound(No Loss)

21

Basic Reliable Periodic Broadcasts

encode each segment, multicast infinite stream of segment data a = “stretch” applied to listening time on each stream

length of first s segments:

length of segment k s:

1

11

11 k

jjk ll

ral

ra

11 k

skjjk ll

ra

Channel 1 Channel 2 Channel 3 Channel 4 Channel 5 Channel 6

a = 1/(1-p)

p = max. cumulative loss rate for uninterrupted playback

22

Basic RPB Protocol: Performance

10% max. cumulative packet loss (i.e., p 0.1, a 1/0.9)

b = client data rate = ssegment streaming rate (r)

0

5

10

15

20

0.0001 0.001 0.01 0.1

Start-up Delay (fraction of total object duration)

Req

uire

d Se

rver

Ban

dwid

thb=1.25, s = 8b=1.5, s = 8b=2, s = 8b=3, s = 8b=5, s = 64Lower Bound

23

Internet Loss Measurements

Duration of Stream (minutes)

Redundant Data

(fraction of media size)

24

RPB: Tolerating Bursty Loss

0

0.05

0.1

0.15

0.2

0.001 0.01 0.1 1

Position in Stream

Max

. Cum

ulat

ive

Loss

for

Uni

nter

rupt

ed P

layb

ack

Variable 'a' :Scenario IVariable 'a' :Scenario I IConstant 'a'

• Larger ‘a’ for initial segments at the cost of smaller a for later segments

• Cumulative loss protection for the whole object = 0.10,

B = 10, s = 8, b = 2, and d = 0.0017 T:

25

RPB: Client Heterogeneity

B = 10, b = 2, s = 8, p = 0.1

1.61.8

22.22.42.62.8

33.2

0 0.05 0.1 0.15 0.2Actual Loss Probability

Actu

al C

lient

Dat

a R

ate

26

Outline

Background

Reliable Periodic Broadcast (RPB)

SWORD Prototype

Summary

27

SWORD Prototype

Server side: encoding data stream, multicast streaming, merge algorithm

Client side: decoding data before sending to player

M e d iaS erv e r

M e d iaP la y er

H T T P

U D PM u ltica s t

S W O R D S e r v e rC o m p o n e n t

S W O R D C lie n tC o m p o n e n ts

C o ntro l D ata

28

For Details … Anirban Mahanti, “Scalable Reliable On-Demand Media

Streaming Protocols”, Ph.D. Thesis, Dept. of Computer Science, Univ. of Saskatchewan, March 2004.

Anirban Mahanti, Derek L. Eager, Mary K. Vernon, David Sundaram-Stukel, “Scalable On-Demand Media Streaming with Packet Loss Recovery”, IEEE/ACM Trans. On Networking, April 2003. Also in ACM SIGCOMM 2001.

Email: mahanti@cpsc.ucalgary.ca http://pages.cpsc.ucalgary.ca/~mahanti

29

Scalable Streaming Protocols: Overview

Bounded Delay Protocols Batching, Periodic Broadcasts Tradeoff: start-up delay vs. bandwidth

Immediate Service Protocols Patching, Bandwidth Skimming Tradeoff: request rate vs. bandwidth

30

Patching

Clients use a “patch” stream to catch-up with the “root” stream

Server Bandwidth scales as square root

00.10.20.30.40.50.60.70.80.9

11.1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Time

Posi

tion

in S

trea

m

Stream for Client A

Stream for Clients A, B

Stream for Clients A, B, C, D

Stream for Client B

Stream for Client C

Stream for Client D

Stream for Clients A, B, C

[Carter & Long 1997, Hua et al. 1998]

31

Bandwidth Skimming

Allocate a multicast stream to each client; a client also listens to closest earliest active stream

Bandwidth scales logarithmically

00.10.20.30.40.50.60.70.80.9

11.1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Time

Posi

tion

in S

trea

m

Stream for Client A

Stream for Clients A, B

Stream for Clients A, B, C, D

Stream for Client B

Stream for Client C

Stream for Client D

Stream for Clients C, D

[Eager et al. 1999]

32

Bandwidth Skimming: Performance

0

10

20

30

1 10 100 1000

Client Request Rate

Req

uire

d Se

rver

B

andw

idth

BandwidthSkimming (b=1.2)BandwidthSkimming (b=2)Patching

Lower Bound

Bandwidth Skimming better than Patching

Bandwidth Skimming policies allow merging for b < 2

33

RBS Performance

10% Packet Loss

0

5

10

15

20

1 10 100 1000Client Request Rate

Req

uire

d Se

rver

Ban

dwid

thb=1.25

b=1.39

b=1.67

b=2.22

LowerBound

pTdx

xB

Td

111ln1

10

0min