19
August 31, 2007 P2P-TV 2007 @ SIGCOMM Peer-assisted VoD for set- top box based IP network Vaishnav Janardhan & Henning Schulzrinne Dept. of Computer Science Columbia University New York, NY

Peer-assisted VoD for set-top box based IP network

Embed Size (px)

DESCRIPTION

Peer-assisted VoD for set-top box based IP network. Vaishnav Janardhan & Henning Schulzrinne Dept. of Computer Science Columbia University New York, NY. Overview. Costs in providing video content DVRs Architecture local DHTs and pre-fetching Challenges. Economics of VoD. - PowerPoint PPT Presentation

Citation preview

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Peer-assisted VoD for set-top box based IP network

Vaishnav Janardhan & Henning SchulzrinneDept. of Computer Science

Columbia University

New York, NY

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Overview

• Costs in providing video content

• DVRs

• Architecture– local DHTs and pre-fetching

• Challenges

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Economics of VoD

• Transit bandwidth $40/Mb/s/month ~ $0.125/GB• US colocation providers charge $0.30/GB to $1.75/GB• Netflix postage cost: $0.70 round-trip• Typical PPV charges: $4/movie (7 GB)

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Cost for providing content

cost

distance

possibly another step

when crossing oceans

within home

within campus/AS(multiple L2s)

same L2 switch(non-blocking)

across provider boundaries

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Example: FiOS TV architecture

Fiber

ServingOffice

ServingOffice

HubOffice

SuperHeadend

Broadcast Video

Voice, Data, IP TV

Voice, Data, IP TV

SuperHeadend

ServingOffice

Splitter

Fiber

J. Savage (Telecom ThinkTank), Nov. 2006● 2 national super headends

● 9 video hub offices

● 292 video serving offices

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Verizon’s FTTP Architecture

ONTOptical Network

Terminal

OLTOptical

Line Terminal

Optical Couplers (WDM)

Voice & Data Downstream 1490 nm

Upstream 1310 nm

Voice, Data & Video 1490 nm, 1310 nm, 1550

nm

1x32

Optical Splitte

r

EDFAErbium Doped Fiber Amplifier

Video 1550 nm

Bandwidth & ServicesUpstream Downstrea

mVoice, Data & Voice, Data &

VOD VOD at 622 Mbpsat 622 Mbps

Voice & Data Voice & Data at 155 to at 155 to

622 Mbps622 Mbps

Broadcast VideoBroadcast Video

1310 nm 1490 nm 1550 nm

Analog TV Digital TV and HDTV

54 MHz 864 MHz

CENTRAL OFFICE

CUSTOMER PREMISE

Brian Whitton, Verizon

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Properties of DVRs

• Storage of 80-250 GB (Tivo 3)• Probably on-line 24/7 already• Often, directly connected to network (“home gateway”)• May be owned by cable or DSL company

August 31, 2007 P2P-TV 2007 @ SIGCOMM

(P2P) video variants

• Lots of variants - with very different requirements

Mode start-up time VCR controls content

near VoD minutes - hours (~ BlockBuster)

full, including skip ahead

movies, UGC

VoD seconds full movies, UGC

live streaming none TiVo-like (pause, rewind)

news, sports

August 31, 2007 P2P-TV 2007 @ SIGCOMM

VoD approaches

WAN LAN

content provider

Internet video(YouTube, Netflix, ...)

ISP-provided VoD

end

use

rs

Classical P2P (BitTorrent, ...)

this approach

servers

network

August 31, 2007 P2P-TV 2007 @ SIGCOMM

VoD requirements

short clips < 10’(long tail)

feature-length

• Example: Superbad grossed $33M during August 17 weekend (in US)

• = roughly 3M viewers• = roughly 1% of US population if VoD, each neighborhood

has likely one copy• 2 problems:

– get initial copy to neighborhood

• multicast, OTA

– distribute in neighborhood

• only viable for top 1000 content

•avoid Netflix queue•avoid stocking 20,000

DVDs

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Assumptions

• Every P2P scheme needs to address those• DRM is orthogonal

– i.e., access to bits access to content– may not work if DRM assumes individualized content

• keying or fingerprinting

• Upstream bandwidth is sufficient to deliver >= 1 stream– true for modern FTTH and FTTC networks– if not, P2P systems only work if ∑ upstream > ∑ consumption

• if near-VoD, averaging interval may be whole day, rather than peak viewing period

– but still need time to buffer content delay and no feedback on FF

• DVRs have spare capacity– likely true for PCs– may be optimistic for DVRs using LRU-style storage management– may be able to leverage content having been viewed by user– if owned by ISP, cheating problems disappears (no need for tit-for-tat)

• DVRs can’t store all content– 85,000 DVDs 595 TB

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Notes on cost shifting

• Servers vs. bandwidth• Fixed vs. incremental costs

– for VoD providers, each (peak) stream incurs additional cost– for end systems, generally $0

• Bandwidth– providers - ~ peak usage– ISP - want to avoid paid (= non-local) traffic– users - may not care, but may be rate-limited or violate contract

• no cost impact as long as downstream >> upstream bandwidth• e.g., Columbia severely limits student bandwidth

– “Quotas are 350M/hr download and 180M/hr upload” (= 400 kb/s)

• not much extra upstream bandwidth left

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Example: Columbia University

ratio 1.5 - not much upstream capacity

left

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Regional Data Center

Server services:•DNS•DHCP

Chicago

Dallas

New YorkLos Angeles

National Backbone

Network architecture

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Architecture

• Try to find content locally (AS)– using a local (provider-internal) DHT by identifier– identify peer with available capacity– cf. Aggarwal (CCR 7/07) to identify candidate nodes

• If local, stream from peer– assume single server upstream bandwidth is sufficient– otherwise, piece together multiple servers– could use standard RTSP VCR controls

• Use extra upstream capacity for pre-fetching content– first, retrieve key frames and anchor points for fast-forward

• MPEG: 1/15th of frames

– then, rest of video– handles bandwidth variability & releases server earlier for other uses

• If not local, contact ISP (caching) video server– e.g., RTSP redirect

August 31, 2007 P2P-TV 2007 @ SIGCOMM

5 sec 5 sec 5 sec

60 seconds 60 seconds 60 seconds

Anchorpoint

Anchorpoint

Anchorpoint

Seek pointSeek point

t (sec)

Adjust to anchor point Adjust to anchor point

Pre-fetching

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Peer 1[seed]

Peer 2[leech]

Peer 4[leech]

Peer 3[leech]

Peer 5[leech]

Tracker

Sliding Window module Pre-fetching module

Pre-fetching

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Conclusion

• Need careful analysis of cost trade-off– P2P may only be optimal if you ignore network costs– compare to classical proxy architectures– clearly identify assumptions -- more than one “P2P video”

• Presented combination of different approaches– Locally popular content remains local– Mid-list content at end users– “Long tail” content at ISP– Back list at content provider

• What is the minimal set of tools and building blocks?

August 31, 2007 P2P-TV 2007 @ SIGCOMM

Admission control

• DVR has small upload capacity– during busy time, may have > 50% DVR utilization

• Content replication converges to popularity• But also hosts rare content only available once in

network• Allow client displacement

– new client indicates rare content (“last resort”)– DVR tries to find alternative source for existing user– and serves new client