Bittube case study of a web based peer assisted video on demand vod system
Download
1 / 33

BitTube: Case Study of a Web-based Peer-Assisted Video-on-Demand VoD System - PowerPoint PPT Presentation


  • 654 Views
  • Uploaded on

BitTube : Case Study of a Web-based Peer-Assisted Video-on-Demand ( VoD ) System. 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. Outline. Motivation Internet Video

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'BitTube: Case Study of a Web-based Peer-Assisted Video-on-Demand VoD System' - Olivia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Bittube case study of a web based peer assisted video on demand vod system l.jpg

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.


Outline l.jpg
Outline

  • Motivation

    • Internet Video

    • Can P2P Help?

    • On-demand P2P Streaming

  • BitTube Design

  • BitTube Implementation

  • Results


Motivation l.jpg
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 l.jpg
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 l.jpg
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.


On demand p2p streaming6 l.jpg
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 l.jpg
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


Outline8 l.jpg
Outline

  • Motivation

  • BitTube Design

    • Design Rationales

    • Architecture

    • User Request Flow

  • BitTube Implemetation

  • Results


Design rationales l.jpg
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 l.jpg
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


Request and data flow l.jpg
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


Service confederation l.jpg
Service Confederation

  • Required changes to existing video service

    • Video URL Modification

    • Torrent File Creation

P2P Network

BitTorrent

Tracker



Outline14 l.jpg
Outline

  • Motivation

  • BitTube Design

  • BitTube Implementation

    • BitTorrent Overview

    • From BitTorrent to BitTube

      • Locality-awareness

      • Window-based Approach

  • Results


Bittorrent protocol l.jpg
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 l.jpg
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 l.jpg
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


Bittorrent to bittube l.jpg
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 l.jpg
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 l.jpg
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


Window based piece picker l.jpg
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


Outline22 l.jpg
Outline

  • Motivation

  • BitTube Design

  • BitTorrent Implementation

  • Results

    • Experimental Setup

    • Server load reduction

    • User Experience

    • Locality-Related Results

    • Impact to ISPs


Experimental setup l.jpg
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 setup24 l.jpg
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 l.jpg
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 l.jpg
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


User experience interruption l.jpg
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 l.jpg
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


As hop count l.jpg
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


Redundancy l.jpg
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 l.jpg
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


Number of supplying peers l.jpg
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 l.jpg
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)


ad