BitTube : Case Study of a Web-based Peer-Assisted Video-on-Demand ( VoD ) System

1. BitTube: Case Study of a Web-based Peer-Assisted Video-on-Demand (VoD) System Bo Liu, Bin Chang, Ben Gotow, Yi Cui, Yuan Xue Vanderbilt Advanced Network and Systems Group Vanderbilt University, USA Presenter: Bin Chang, YouTube Inc.

2. Outline • Motivation • Internet Video • Can P2P Help? • On-demand P2P Streaming • BitTube Design • BitTube Implementation • Results

3. Motivation • Internet Video • Video streams served increased 38.8% in 2006 to 24.92 billion (Source: AccuStream iMedia Research) • 53 web-video startup in 2006 (US), $521M VC funding (Source: DowJones VentureOne) • Major studio goes into Web Video • $410M video ads revenue in 2006 and grow by 89% in 2007 (0.6% of $74B TV ad market, Internet ads $16.4B in 2006, expect to grow 19% in 2007) [source: Emarketer] • Operating Cost • Hosting, storage, infrastructure, management… • Bandwidth Subscription

4. Can P2P Help? • Successful Track Record in Broadcasting and Live Streaming • Challenges in On-demand Streaming • Peer Aggregation: a number of peers access the same media file simultaneously • Key Factors Enabling Peer Aggregation • High Access Rate • Skewed File Popularity • Short Inter-arrival Time • Concentrated Requests • Long Online Duration • Sustained Peer Mass

5. On-demand P2P Streaming • Theoretical Study Request interarrival time = Buffer Length Request Interarrival Time = Buffer Length  request rate T Movie Length S Playback Time W Buffer Length Sequential Access Random Access Yi Cui, Baochun Li, and Klara Nahrstedt, oStream: Asynchronous Streaming Multicast in Application-Layer Overlay Networks, IEEE Journal on Selected Areas in Communications, Special Issue on Recent Advances in Service Overlays, 2004.

6. On-demand P2P Streaming • Trace Study • Traces from the on-demand service of MSN Video • 9-month period: April – December 2006 • 520M streaming requests • 59,000 unique videos • With the aid of P2P streaming (greedy prefetch policy) • Server Bandwidth Reduction from 2.20Gbps to 79 Mbps on December 2006 • Studio Produced Content • Bitrate: 200 kbps in April 2006, 320 kbps in December 2006 • Duration: 5 to 60 minutes Cheng Huang, Jin Li, and Keith Ross, Can Internet Video-on-Demand Be Profitable?, ACM SIGCOMM, August 2007, Kyoto, Japan

7. Peer-Assisted On-demand P2P Streaming • P2P solutions can greatly reduce server load, hence the bandwidth subscription budget • Proved by theoretical analysis and trace study • Commercial Deployment: PPLive • Server load reduction 91.7% on May 12, 2008 • However, P2P cannot replace server, but only complement it • Skewed Video Popularity • Unpopular videos are more likely to be only possessed by the server • Peer Population Fluctuation • At the beginning, a new video is only available the server, then distributed to peers one by one • Alternative Viewpoint • Server can be regarded as super peer or seed

8. Outline • Motivation • BitTube Design • Design Rationales • Architecture • User Request Flow • BitTube Implemetation • Results

9. Design Rationales • Minimum Interruption to Current Internet Video Infrastructure • Web-based platform should stay uninterrupted • Massive Video Archive • Adopt the most commonly-accepted P2P Technique • Our choice: BitTorrent • Retain usability of the current Internet video service • Click-to-view

10. BitTube Architecture User Server Request Web Browser Video Server Flash Player video video Request BitTube Desktop Other Peers video Local HTTP Module Tracker Downloading Stub P2P Module Client/Server Module BitTorrent Tracker Peer List

11. Request and Data Flow Other Peers Request is formatted as http://localhost/ video URL/ torrent URL Downloading stub peer list Web Browser Local HTTP Module torrent URL P2P Module BitTorrent Tracker peer list request video video URL Flash Player Client/Server Module Video Server piece request Local HTTP process reassembles the collected pieces into the complete video file HTTP/1.1 content-range entity-header feature enables it to request a particular piece of the file

12. Service Confederation • Required changes to existing video service • Video URL Modification • Torrent File Creation P2P Network BitTorrent Tracker

13. Screen Shot

14. Outline • Motivation • BitTube Design • BitTube Implementation • BitTorrent Overview • From BitTorrent to BitTube • Locality-awareness • Window-based Approach • Results

15. BitTorrent Protocol • De facto Protocol for P2P File Downloading • First software BitTorrent • Author: Bram Cohen • Development Time: Summer 2002 • Released as open source • Many BitTorrent-compliant Softwares • Writing BitTorrent-compliant Software • Stable open source code • Interoperability with existing P2P Softwares • No overlay structure needed • Highly dynamic P2P group • Many Abandoned Sessions • Distribution of small files

16. BitTorrent Overview • A File is divided into pieces • Torrent • Tracker • Swarm • Key Functions • Tracker • Neighbor selection • Choker • Optimistic Unchoking • Piece Picker • Rarest-First Policy

17. BitTorrent: Piece Picker Downloaded piece • Rarest-first Policy • Executed among unchoked peers • Piece with the minimum interest value is chosen • Interest value: the number of peers possessing this piece • Tie is broken arbitrarily if multiple pieces with the minimum interest value exist • Distribute the rarest pieces • Help promote the piece diversity of all peers Video File 1 2 1 3 4 2 1 3 2 Undownloaded piece Piece chosen by the policy 1 Interest value

18. BitTorrent to BitTube • BitTorrent Limitations • Lack of Locality-awareness • Excessive amount of inter-ISP traffic • A main reason why many ISPs block or throttle BitTorrent traffic • Unnecessary Long-haul end-to-end connections • Certain pieces can often be retrieved from near-by peers • No Support for Video Streaming • Rarest-first policy disregards positions of pieces in video playback • BitTube implementations • Embedding locality-awareness into key operations of BitTorrent • Tracker, choker, and piece picker • A window-based approach to support “viewing-while-downloading” feature • Bitos, BASS, Toast, BitTorrent DNA

19. Can BitTube Run Inside a Browser? • BitTube as a standalone software • Language: C++ • Binary code: 70 KB • Lifetime: as long as the user does not close it • BitTube embedded in browsers • Firefox Extension • Lifetime: as long as the browser runs • Other Options • Active X • User Confirmation Required • Java Applet • Redeveloping with Java • Lifetime: as long as the user stays in the website • Invisible Frame: A trick to make BitTube run longer inside a browser

20. Piece Picker Locality Downloaded piece • Locality-first Policy • Piece with the minimum distance value is chosen • Distance value: the average distance of all peers possessing this piece • Distance value is passed down in the peer list from the tracker • Tie is broken arbitrarily Video File 2 1 3 3 1 1 2 3 1 Undownloaded piece Piece chosen by the policy 2 Distance value

21. Window-based Piece Picker Downloaded piece • Adapting BitTorrent to video streaming • Piece selection restrained within the playback window • Enable Viewing while downloading • How to advance the playback window • Automatically pushed forward when the leftmost piece is downloaded • If the advancement falls behind the playback • The left-most piece is downloaded by the client-server thread • Streaming rate information is needed Playback Window Undownloaded piece Video File 2 1 3 3 1 1 2 3 Piece chosen by the policy Playback Window 1 Interest value 2 Distance value Video File 1 2 1 3 4 2 1 3

22. Outline • Motivation • BitTube Design • BitTorrent Implementation • Results • Experimental Setup • Server load reduction • User Experience • Locality-Related Results • Impact to ISPs

23. Experimental Setup • PlanetLab testbed • BitTube deployed on 200 nodes • Two PC machines at VANETS lab • video server and tracker • Intel Xeon 2.80GHz CPU, RedHat Linux • 10 minutes seeding time • Piece-level traces recorded at each PlanetLab node • Sequence number, receiving time, IP of source peer • Test Video File • Flash File downloaded from YouTube • Requested 53165 times from 18:18:33 to 22:31:59 on September 5, 2007 • Average 1.5 requests per second • 59MBytes and lasts 28 minutes 28 seconds • Original file is 7.5 Mbytes and lasts 3 minues 10 seconds

24. Experimental Setup • What results do we want to obtain? • Server Load • User Experience • Impact on ISPs • Peer Contributions • Interplaying of Design Goals • Original design goals in BitTorrent • Locality-awareness • Window-based

25. Server Load • Server Load Reduction • Average time length per piece • 4.25 seconds • BitTorrent (unlimited window size) • 91.8% • Window-based approach (window size = 20 pieces) • Rarest-first policy • 94.5% • Piece-picker Locality • 89.6% • Choker Locality • 85.3% • Tracker Locality • 83.5%

26. Server Load per Peer Piece picker locality (window size = 20 pieces) Rarest-first Policy (window size = 20 pieces) BitTorrent (unlimited window size) • The more self-supporting peers, the greater the server load reduction

27. User Experience: Interruption • Aggregate Interruption Time • Interruption stage is triggered if any piece is missing in playback • Aggregate interruption time is the summation of time lengths of all interruptions experienced by the peer • 80% peers have no interruptions • 10% peers have interruptions less than 100 seconds BitTorrent (unlimited window size) Choker Locality (window size = 20 pieces) Picker Locality (window size = 20 pieces) Tracker Locality (window size = 20 pieces)

28. Locality-Related Results • Minimum AS Hop Strategy • Each peer finds from previously-joined peers the one with the minimum AS hop as its parent • Result: a minimum spanning tree without degree constraint • Optimal P2P Strategy to minimize the total number of AS hops • Serve as the baseline strategy against which other realistic strategies are evaluated ISP A ISP B ISP C 1 5 3 8 7 4 6 2

29. AS Hop Count BitTorrent (unlimited window size) • Average AS Hop Count • Average value of AS hop counts traveled by all pieces download by each peer • Minimum AS Hop Strategy • Half the peers cause 0 AS hop count • Tracker Locality has the shortest AS hop count Choker Locality (window size = 20 pieces) Picker Locality (window size = 20 pieces) Tracker Locality (window size = 20 pieces) Minimum AS Hop

30. Redundancy • Redundancy • Number of times a piece has to enter an ISP until all peers in the ISP finish their downloading • Lowest value is 1 • Highest value is the number of peers in the ISP • Normalized Redundancy • Redundancy normalized by number of peers • Less than 80 ISPs are involved BitTorrent (unlimited window size) Choker Locality (window size = 20 pieces) Picker Locality (window size = 20 pieces) Tracker Locality (window size = 20 pieces) Minimum AS Hop

31. Peer Contribution • Sorted list of peers based on the number of bytes they have uploaded during the experiment • Tracker Locality has the most uneven distribution of peer contribution • Original BitTorrent and choker locality give the most even distribution of peer contribution • Minimum AS hop strategy only makes a few peers contribute • Unevenness of peer contribution is obvious across all policies BitTorrent (unlimited window size) Choker Locality (window size = 20 pieces) Picker Locality (window size = 20 pieces) Tracker Locality (window size = 20 pieces) Minimum AS Hop

32. Number of Supplying Peers • Sorted list of peers based on the number of supplying peers they have got pieces from during the downloading • Tracker Locality allows the least number of supplying peers • Original BitTorrent allows the most number of supplying peers • Minimum AS hop always allow only one supplying peer BitTorrent (unlimited window size) Choker Locality (window size = 20 pieces) Picker Locality (window size = 20 pieces) Tracker Locality (window size = 20 pieces)

33. Summary • A P2P solution to complement the current Internet video service • Motivation: saving bandwidth cost • Design Considerations: Minimum interruption to existing infrastructure • PlanetLab experiment shows great server load reduction without sacrificing user experience • Accommodating BitTorrent to locality-awareness and streaming applications • Less randomness are likely to shrink server load saving and cause more uneven peer contribution • But the cost saving is still significant • Worst performance: 83.5% saving (tracker locality) • Best performance: 94.5% saving (window-based rarest-first policy)