Scalable On-demand Media Streaming with Packet Loss Recovery Anirban Mahanti Department of Computer Science University of Calgary Calgary, 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

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

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 Time (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) 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 [Hua & Sheu 1997]

10 Harmonic Broadcasts [Juhn & Tseng, 1998]

11 Performance Comparisons

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) [Vicisano et al. 1998, Byers et al.1998]

14 Periodic Broadcasts: Performance Lower Bound:

15 Unicast Service Broadcast/Multicast Service Digital Fountain (bulk data) Reliable Delivery Delivery Techniques: Summary ?? Immediate Streaming Unicast Streaming Bandwidth Skimming Patching Bounded Delay 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:

20 Optimized PB: Performance r = segment transmission rate, s = max. # streams client listens to concurrently b = client data rate = s x r

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: 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 = s  segment streaming rate (r)

23 Internet Loss Measurements

24 RPB: Tolerating Bursty Loss 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 = T:

25 RPB: Client Heterogeneity B = 10, b = 2, s = 8, p = 0.1

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

28 For Details … Anirban Mahanti, “Scalable Reliable On-Demand Media Streaming Protocols”, Ph.D. Thesis, Dept. of Computer Science, Univ. of Saskatchewan, March 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 Also in ACM SIGCOMM

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 [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 [Eager et al. 1999]

32 Bandwidth Skimming: Performance Bandwidth Skimming better than Patching Bandwidth Skimming policies allow merging for b < 2

33 RBS Performance 10% Packet Loss