1 / 7

P2P Live Streaming RayV Solution Implications of customers requirements on ‘tracker’ protocol

P2P Live Streaming RayV Solution Implications of customers requirements on ‘tracker’ protocol. March 22 th , 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

hei
Download Presentation

P2P Live Streaming RayV Solution Implications of customers requirements on ‘tracker’ protocol

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. P2P Live StreamingRayV Solution Implications of customers requirements on ‘tracker’ protocol March 22th, 2010

  2. 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

  3. 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)

  4. Customers requirements - Quality 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’

  5. Customers requirements – SLA and Delay ‘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.

  6. Content owners, Operators, ISPs, Telco rules: Preventing the content owner viewers from contributing to different types of content Allowing the content owner viewers to contribute only to its own channels Allowing 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 Customers requirements - Rules

  7. Customers requirements – Reports/Security ‘Reports’ requirement: Daily including viewing quality Number 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.

More Related