P2P Live StreamingRayV Solution

Implications of customers requirements on ‘tracker’ protocol

March 22th, 2010

Overview

RayV solution – business, usage, why p2p The content owners and Telcos/MSO/ISP requirements

Quality (the upstream problem) SLA and delay Security and Reports Content Owners and ISPs rules

RayV P2P live streaming

Business: White label turn-key solution platform/CDN in a box for the Content owners/Telcos All content is legitimate Working with Telco/MSOs/ISPs Customers: NBA, DirecTV, Blizzard/Activision, Fox sports, American cap, Tennis Channel, Comcast CSN, AB Groupe, ex-pat channels, SMG

Usage: On average 500,000 connected peers 100,000 concurrent viewers at peak 8M minutes watched daily

P2P facts: Improves quality (due to stream localization) 90%-95% cost saving (HW and bandwidth) Building the network cost per concurrent viewer $0.6 Monthly per concurrent $0.5/month (10% of 1Mbps BW cost)

Quality Requirement: 500-800Kbps for news/music channels; 800-1.5Mbps for sports; 1.5Mbps to 3Mbps for

TVHD experience.

Requirement implication: Since peers can only contribute on average 200Kbps upstream P2P from peers only is

limited to 20% of BW needed. Additional sources are needed These additional sources must contribute much more than they consume thus cannot

be ‘typical viewers’ if consuming the entire stream. If those sources are ‘CDN nodes’ (hosted by an external CDN as in many ‘hybrid

solutions’ or by the P2P provider) the P2P benefits are limited to 20%-30% only. Possible but ‘not desired’ solution: ‘free riding’ on high upstream peers such as

universities and institutions. RayV solution: Adding many additional ‘typical’ nodes streaming to each of them

minimal data (2 MTUs/sec) and having those re-distribute to many other peers (we call those ‘amplifiers’)

‘Tracker’ functionality and protocol: Has to be able to ‘call resources’ for help. Must ‘control and optimize the resources’ according to needs Different nodes may have different ‘roles’

Customers requirements - Quality

‘SLA’ Requirement: Quality must be provided to all viewers Viewers behind firewalls should be able to watch as well Redundancy (multiple channels) Adaptive quality (multiple qualities)

Requirement implications: Stream must also exist in ‘reliable resources’ These resources are to be approached at the ‘last moment’ before watching, providing the missing pieces.Standard stream has to be provided from the above resources or other resources.Ability to ‘redirect’ to another channels

‘Delay’ Requirement: Delay from encoder to viewers must not exceed 8-10 seconds Viewers should watch ‘simultaneously’ with up to 2 sec difference

Requirement implications: Number of hops must be minimized (explain why not just Dhop but also Dsch) Clocks synchronization between peers. Usage of push protocol from donor to acceptor desired. Also to save upstream of viewers/helpers.

Customers requirements – SLA and Delay

Customers requirements - Rules

Content owners, Operators, ISPs, Telco rules:Preventing the content owner viewers from contributing to different types of contentAllowing the content owner viewers to contribute only to its own channelsAllowing upstream only within the ISP (or even closed LAN) – this imply that some peers could receive from others but not to contribute to them.Minimizing upstream

Technical rules:Closed environments (China, Australia)Peer selection is based on Zones

Implications:Tracker has to perform the ‘peer selection’ according to rules set up by ISPs and content owners (ALTO and more)Trackers better ‘hint’ viewers on desired selections (first take from this zone than another).Viewers may be able to receive from a specific node but not to contribute to it. So generally speaking protocol between peers should be asymmetric.Minimizing upstream may imply PET/IDA (network coding) techniques

‘Reports’ requirement:Daily including viewing qualityNumber of concurrent viewers

requirement implications: ‘Tracker’ should receive statistics every X seconds Data warehouse

Security requirements:Access control (not necessarily to ‘tracker’).Per program ability to stop viewing

Requirement implications:Tokens must be sent to donors about the time/program to continue streaming to viewer.These tokens have to be generated by a ‘reliable’ server.

Customers requirements – Reports/Security