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

Presentation Transcript

Vaishnav Janardhan & Henning Schulzrinne

Dept. of Computer Science

Columbia University

New York, NY

P2P-TV 2007 @ SIGCOMM

Overview

Costs in providing video content
DVRs
Architecture

local DHTs and pre-fetching

Challenges

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)

Cost for providing content

cost

across provider boundaries

possibly another step when crossing oceans

within campus/AS

(multiple L2s)

same L2 switch

(non-blocking)

distance

within home

Broadcast Video

Voice, Data, IP TV

Serving

Office

Fiber

Super

Headend

Hub

Office

Serving

Office

Splitter

Serving

Office

Super

Headend

Example: FiOS TV architecture

2 national super headends
9 video hub offices
292 video serving offices

J. Savage (Telecom ThinkTank), Nov. 2006

Verizon’s FTTP Architecture

CUSTOMER PREMISE

Voice & Data Downstream 1490 nm

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

OLT

Optical Line Terminal

ONT

Optical Network Terminal

Optical Couplers (WDM)

Optical Splitter

Upstream 1310 nm

Video 1550 nm

1x32

CENTRAL OFFICE

EDFA

Erbium Doped Fiber Amplifier

Bandwidth & Services

Upstream

Downstream

1310 nm

1490 nm

1550 nm

Voice & Data at 155 to 622 Mbps

Voice, Data & VOD at 622 Mbps

Broadcast Video

54 MHz

864 MHz

Analog TV

Digital TV and HDTV

Brian Whitton, Verizon

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

(P2P) video variants

Lots of variants - with very different requirements

VoD approaches

network

servers

VoD requirements

short clips < 10’

(long tail)

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

feature-length

avoid Netflix queue
avoid stocking 20,000 DVDs

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

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

Example: Columbia University

ratio 1.5 - not much upstream capacity left

Network architecture

Los Angeles

New York

Chicago

National Backbone

Dallas

Regional Data Center

Server services:
DNS
DHCP

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

Pre-fetching

Adjust to anchor point

t (sec)

5 sec

Seek point

Anchor

point

Anchor

point

Seek point

Anchor

point

60 seconds

Tracker

Peer 3

[leech]

Peer 5

[leech]

Peer 1

[seed]

Peer 2

[leech]

Peer 4

[leech]

Sliding Window module

Pre-fetching module

Pre-fetching

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?

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