• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
On Feasibility of P2P On-Demand Streaming via Empirical VoD User ...
 

On Feasibility of P2P On-Demand Streaming via Empirical VoD User ...

on

  • 523 views

 

Statistics

Views

Total Views
523
Views on SlideShare
523
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Mentions PPLive server saving
  • 96.5%
  • May 12, 2008. A total of 182544 peers are recorded. The average rate of a peer downloading from the server is 32Kbps and 352Kbps from the neighbor peers. On the other hand, the average upload rate of a peer is about 368Kbps. The average server loading during this one-day measurement period is about 8.3%.
  • Permanent connection
  • Why BitTorrent has less saving than window-based? Client-server thread kicks in
  • In our testbed, there are lots of ISPs. In a normal situation, we should expect lower redundancy.

On Feasibility of P2P On-Demand Streaming via Empirical VoD User ... On Feasibility of P2P On-Demand Streaming via Empirical VoD User ... Presentation Transcript

  • Bo Liu, Bin Chang, Ben Gotow, Yi Cui, Yuan Xue V anderbilt A dvanced Net work and S ystems Group Vanderbilt University, USA Presenter: Bin Chang, YouTube Inc. BitTube: Case Study of a Web-based Peer-Assisted Video-on-Demand (VoD) System
  • Outline
    • Motivation
      • Internet Video
      • Can P2P Help?
      • On-demand P2P Streaming
    • BitTube Design
    • BitTube Implementation
    • Results
  • 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
  • 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
  • On-demand P2P Streaming
    • Theoretical Study
     request rate T Movie Length S Playback Time W Buffer Length Request interarrival time = Buffer Length Request Interarrival Time = Buffer Length 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. Sequential Access Random Access
  • 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
  • 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
  • Outline
    • Motivation
    • BitTube Design
      • Design Rationales
      • Architecture
      • User Request Flow
    • BitTube Implemetation
    • Results
  • 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
  • BitTube Architecture Server User Web Browser Video Server Flash Player video Request video Tracker BitTube Desktop BitTorrent Tracker Local HTTP Module Downloading Stub P2P Module Client/Server Module Peer List video Other Peers Request
  • Request and Data Flow Downloading stub Other Peers Web Browser Flash Player Local HTTP Module P2P Module Client/Server Module BitTorrent Tracker Video Server Request is formatted as http://localhost/ video URL/ torrent URL video URL torrent URL peer list request peer list HTTP/1.1 content-range entity-header feature enables it to request a particular piece of the file piece request video Local HTTP process reassembles the collected pieces into the complete video file
  • Service Confederation
    • Required changes to existing video service
      • Video URL Modification
      • Torrent File Creation
    P2P Network BitTorrent Tracker
  • Screen Shot
  • Outline
    • Motivation
    • BitTube Design
    • BitTube Implementation
      • BitTorrent Overview
      • From BitTorrent to BitTube
        • Locality-awareness
        • Window-based Approach
    • Results
  • 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
  • BitTorrent Overview
    • A File is divided into pieces
      • Torrent
      • Tracker
      • Swarm
    • Key Functions
      • Tracker
        • Neighbor selection
      • Choker
        • Optimistic Unchoking
      • Piece Picker
        • Rarest-First Policy
  • BitTorrent: Piece Picker
    • 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
    1 2 1 3 4 2 1 3 2 Downloaded piece Undownloaded piece Piece chosen by the policy 1 Interest value Video File
  • 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
  • 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
  • Piece Picker Locality
    • 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
    2 1 3 3 1 1 2 3 1 Downloaded piece Undownloaded piece Piece chosen by the policy 2 Distance value Video File
  • Window-based Piece Picker
    • 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
    2 1 3 3 1 1 2 3 Downloaded piece Undownloaded piece Piece chosen by the policy 2 Distance value Video File Playback Window 1 Interest value 1 2 1 3 4 2 1 3 Video File Playback Window
  • Outline
    • Motivation
    • BitTube Design
    • BitTorrent Implementation
    • Results
      • Experimental Setup
      • Server load reduction
      • User Experience
      • Locality-Related Results
      • Impact to ISPs
  • 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
  • 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
  • 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%
  • Server Load per Peer Piece picker locality (window size = 20 pieces) BitTorrent (unlimited window size) Rarest-first Policy (window size = 20 pieces)
    • The more self-supporting peers, the greater the server load reduction
  • 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)
  • 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 2 3 4 6 8 7
  • AS Hop Count 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
    • 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
  • 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
  • Peer Contribution 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
    • 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
  • 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)
  • 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)