1. 1 Analysis of BitTorrent-like Protocols for On-Demand Stored Media Streaming Khandoker Nadim Parvez Carey Williamson Anirban Mahanti Niklas Carlsson

2. 2 Introduction and Motivation n BitTorrent is a popular protocol used for Peer-to-Peer (P2P) file sharing on the Internet n Very efficient for download of large files, such as media objects (audio/video) n Question: How suitable is BitTorrent for on-demand stored media streaming?

3. 3 Background: BitTorrent 101 n Key features of BitTorrent: –all peers associated with a file are called a swarm (tracker, downloaders, and seeds) –a single file (e.g., 100 MB movie) is split into many fixed-size pieces (e.g., 256 KB) –peers can download pieces in any order –“Rarest-First” piece selection policy makes prevalence of pieces asymptotically uniform –can download pieces concurrently from multiple peers at a time –“tit-for-tat” reciprocity among peers to encourage cooperation (upload/download)

4. 4 Background: Streaming n Download = Streaming –D: obtain file first, then do something with it –S: view the file while it is still being obtained (start-up delay << download latency) n Media playback must be sequential n Media file has an inherent media playback rate (frames per second) n Playback rate must be sustained for the duration of the media object (uninterrupted)

5. 5 Background: P2P Streaming n The P2P paradigm has also been applied to media streaming applications –CoolStreaming, PPLive, ZigZag, … n Two types of streaming: –live streaming: usually a single source, and many peers with shared temporal content focus, joining and leaving at any time –on-demand streaming: stored media objects, accessed at any time, retrieved in entirety n Our focus: on-demand P2P streaming

6. 6 Research Questions n Can BitTorrent-like protocols provide scalable on-demand streaming? n How sensitive is the performance to the application configuration parameters? –Piece selection policy –Upload/download bandwidth n What is the user-perceived performance? –Startup delay –Probability of disrupted playback

7. 7 A Key Observation n MediaStreamingProgress (MSP) depends on two different things: –DownloadProgress (DP) –SequentialProgress (SP) n These two can be analyzed separately (useful media pieces per unit time) (pieces obtained per unit time) (useful media pieces per pieces obtained) MSP = DP x SP

8. 8 Quiz Time: Sequential Progress E[j] = ------------- k M - k + 1 Q: After having retrieved k pieces (at random) from a file with M pieces, what is the probability that a peer has (exactly) pieces 1 to j inclusive? A1: Prob(M,k,j) = M k () M - 1 - j k - j () A2: P = Var[j] = --------------------- k(M+1)(M-k) (M-k+2)(M-k+1) 2 M k () M - j k - j () jjjj () “useful” pieces“useless” pieces total ways to choose

9. 9 Sequential Progress Example E[j] = ------------- k M - k + 1

10. 10 BitTorrent System Model Arrival rate = Departure rate =  y Downloader Seed Download Time T Residence Time 1/  Torrent (with x downloaders and y seeds)

11. 11 Assumptions and Parameters n Single swarm; homogeneous peers n x downloaders and y seeds at time t n D download conns > U upload conns n System is demand-driven: xD > (x+y)U n Per-connection throughput is C bps n Download latency = T n Number of pieces in the file = M n Startup delay =  n Media Playback Rate = r

12. 12 Fluid Model Overview Arrivals Departures Downloaders Seeds Conversions x(t) y(t)

13. 13 Model: Rarest-First n Conversion of downloaders to seeds at rate (x+y)UC. n Therefore the change of swarm population: dy See [Qiu and Srikant 2004]

14. 14 Model: Rarest-First Download latency: Sequential progress: n Startup delay:

15. 15 Rarest-First: Observations n Download latency is independent of the peer arrival rate (system is scalable). n Latency improves when upload bandwidth or seed residence time increase. n Sequential progress is very poor (bad news for on-demand streaming!). n Startup delay approximately equals the download latency when M is large.

16. 16 Strict In-Order Model (naïve) n Obtain pieces in numerical order n Best case for sequential progress n Implications: –Completely breaks the “tit-for-tat” mechanism! (only older peers have useful pieces for you) –Uneven distribution of demand in system (heaviest at seeds and older peers, who use random selection with purging to handle load) –Young peers progress quickly, but progress gets slower and slower with age –Unstable system population (oscillation)

17. 17 Departure rate =  y Downloader Seed Torrent (with x downloaders and y seeds) U = # of upload connections C = Per connection throughput Arrival rate = Peers (sorted by age) Strict In-Order Model (naïve)

18. 18 Model: Strict In-Order (naïve) The probability of getting a download connection for a downloader of age t is : n Averaging over all downloaders (age 0 to T), the change of swarm population is: dy

19. 19 Model: Strict In-Order (naïve) Swarm population: Download latency: n Startup delay:

20. 20 Strict In-Order(naïve): Observations n System progress is very sluggish due to x/2 term in the conversion rate. n Number of downloaders is much higher. n Number of seeds is same as Rarest-First. n Download latency is almost double compared to Rarest-First (for  near 1).

21. 21 Departure rate =  y Downloader Seed Torrent (with x downloaders and y seeds) U = # of upload connections C = Per connection throughput Arrival rate = Peers (sorted by age) Strict In-Order Model (clever)

22. 22 In-Order(clever) Model n Obtain pieces in numerical order n Best case for sequential progress n Features: –Pending requests are queued –Queues are served in FCFS order –Closed-loop mechanism for new requests ensures finite queue size –Load is less uneven, and self-regulated –System is “fair” to peers of all ages

23. 23 Model: Strict In-Order (clever) Swarm population: Download latency: n Startup delay:

24. 24 In-Order(clever): Observations n Population evolution is identical to Rarest-First. n Download latency is identical to Rarest-First. n Sequential progress is ideal (unlike Rarest-First). n Lowest startup delay among policies evaluated. n We believe this policy is optimal, but do not have a formal proof at this time. (Help!)

25. 25 Model Validation: Scenario n Fluid simulation in ns-2 n Number of pieces: M = 100 –Range: 100 to 200 n Piece size: 128 KB n Media playback rate: r = 2000 Kbps n Download capacity: 3200 Kbps (D = 16 conns) n Upload capacity: 800 Kbps (U = 4 conns) –Range: 300 Kbps to 2000 Kbps n Arrival rate: 50 (per media duration) –Range: 6.25 to 100.0 n Seed residence time: 20 seconds –Range: 10 seconds to 150 seconds

26. 26 Model Validation (1 of 3) n Swarm population increases linearly with peer arrival rate n In-Order(naïve) has higher system pop. n In-Order(naïve) is sensitive to seed residence time, while other policies are not.

27. 27 Model Validation (2 of 3) n Download time improves when the seed residence time is increased n Download time improves when the upload bandwidth is increased n Good agreement with analytical models

28. 28 Model Validation (3 of 3) n Startup delay improves when seed residence time or upload bandwidth are increased n In-Order(clever) achieves lowest startup delay n Good agreement between simulation results and analytical model

29. 29 Conclusions n BitTorrent-like protocols can support scalable and efficient on-demand streaming. n Rarest-First attains poor sequential progress. n In-Order(clever) achieves best performance for media playback while attaining the same download latency of Rarest-First. n Our analytic models accurately predict system performance (simulation validation).

30. 30 Key Contributions n Decoupling of download progress and sequential progress (key insight). n Download latency and startup delay characterization for different policies. n Effect of upload U and download D connections, not just total bandwidth. n Distribution of download time and variability of progress (stream quality). n Optimal structure for on-demand media streaming in P2P networks (???)