• Save
International SIP conference 2009
Upcoming SlideShare
Loading in...5
×
 

International SIP conference 2009

on

  • 919 views

Live Streaming over P2PSIP

Live Streaming over P2PSIP

Statistics

Views

Total Views
919
Views on SlideShare
916
Embed Views
3

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 3

http://www.slideshare.net 1
http://www.google.co.uk 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

International SIP conference 2009 International SIP conference 2009 Presentation Transcript

  • January 22, 2009 (Paris, France) Live Streaming over P2PSIP International SIP 2009 Conference - 10th edition Victor Pascual System Architect Tekelec This document is for informational purposes only, and Tekelec reserves the right to change any aspect of the products, features or functionality described in this document without notice. Please contact Tekelec for additional information and updates. Tekelec. For What's Next.
  • Agenda › Motivation Video broadcast in the Internet? P2P beyond File Sharing P2P-based architectural approaches • Tree-based • Data-driven How to cope with heterogeneity? Requirements of P2P live video streaming in the Internet › Contribution Live Streaming over P2PSIP Layered Architecture Functional Distributions • Consumer does most • Overlay does most Evaluation › Conclusions Summary Work-in-progress 2 | Tekelec. For What's Next. Tekelec Confidential
  • Motivation 3 | Tekelec. For What's Next. Tekelec Confidential
  • Video Broadcast in the Internet? (1/2) 4 | Tekelec. For What's Next. Tekelec Confidential
  • Video Broadcast in the Internet? (2/2) › Movies and sport are the basis of Pay TV But you can get it for free in the Internet › Video is basic for on-line news and a number of other kinds of adult entertainment businesses › Video as a new channel of expression in Web 2.0 › Video is the most bandwidth-hungry application and the basis for today's architectural headaches › Life expectancy for non-IP video broadcast? Who is brave enough to speak up and make a prediction? 5 | Tekelec. For What's Next. Tekelec Confidential
  • P2P Beyond File Sharing › To make systems in which the capacity of the system scales up at the same rate that new users join the system › P2P Live and VoD streaming applications are becoming dominant traffic in some networks Surpassed that of file sharing in China Accounting for ~50% P2P traffic (according to “Problem Statement of Peer to Peer Streaming Protocol”, PPSP BOF- IETF 73) › Most current P2P streaming applications make use of proprietary protocols But they share the similar architecture (tracker based and with CDN support) › Use of standards can benefit to each party in the P2P value chain P2P streaming service providers End users and terminal companies ISP and other network service providers Network equipment vendors 6 |
  • P2P-based architectural approaches › Key idea: Transform users into media relays Overall capacity increases with the number of users! › Two main approaches: Tree-based Data-driven Source: Opportunities and Challenges of Peer-to-Peer Internet Video Broadcast 7 | Tekelec. For What's Next. Tekelec Confidential
  • Tree-based Solutions › Push-based Data automatically forwarded to children Almost negligible delay in relaying › Need a lot of management in the face of churn Reassign parents › Bandwidth is underutilized Leaves do not contribute to the system › Evolution: Multi-trees Every user is both leaf and node in different trees 8 | Tekelec. For What's Next. Tekelec Confidential
  • Data-driven Solutions › No definite structure is maintained › Use gossip protocols to distribute data (push-based) Data spreads like a virus Resilient against churn Decentralized Highly inefficient and redundant use of bandwidth › Alternative: Pull-based solutions Exchange chunk availability with (random) partners Choose from whom to download (pull-based) Redundancy is avoided while resilient to churn High additional delay 9 | Tekelec. For What's Next. Tekelec Confidential
  • Data-Driven: higher algorithmic complexity › How to choose from whom to download? Also in the presence of churn › How to choose what to download from each? Scheduling problem is NP-hard Avoid holes and meet playback deadlines › How to choose to whom to upload/relay? Uplink capacity is scarce in ADSL › How to discover other peers that have the information you want? General problem in P2P systems › How to (efficiently) interchange data availability? Delay vs overhead trade-off 10 | Tekelec. For What's Next. Tekelec Confidential
  • How to cope with heterogeneity? (1/2) › Overall bandwidth is dynamic and heterogeneous Due to churn Due to changing uplink/downlink usage conditions Due to heterogeneous access technologies › For a P2P broadcast system to be sustainable, every node must upload more than it downloads! Impossible in ADSL networks 11 | Tekelec. For What's Next. Tekelec Confidential
  • How to cope with heterogeneity? (2/2) › Source coding Divide video in layers, and layers in chunks Scalable Video Coding (SVC): Each layer adds quality to the basic one Multiple Descriptive Coding (MDC): Each layer is independent, yet combined provide higher quality Drawbacks • High information redundancy on every layer • Computationally very intensive • High management overhead • Not widely used yet › Network coding Coding at the peers (Coming from Information Theory) Not clear how it could help to improve P2P network performance › Clever architectures Use of media reflectors/mirrors Nodes that provide upload capacity only With or without operator support Incentives to users to provide more uploading capacity Combine trees and meshes to achieve optimum bandwidth usage 12 | Tekelec. For What's Next. Tekelec Confidential
  • Requirements of P2P live video streaming in the Internet › Decentralized Less workload on streaming servers Better scalability & robustness › Large scale Hundreds of thousands of users › Application layer scheme Flexible and easy to deploy › Performance demanding 1,5 Mbps for TV quality 300 kbps – 450 kbps achievable today (asymmetrical upload and download bandwidth) › Real-time Uninterrupted video with limited buffering: timely and continuously streaming delivery Limited start-up delay and limited latency between the broadcasting time and the audience view time › Gracefully degradable quality to accommodate bandwidth heterogeneity and dynamics Different access speeds and churn (also channel zapping) › Interoperability Standards based › Others Firewall and NAT traversal, AAA, Security, Group membership management 13 | Tekelec. For What's Next. Tekelec Confidential
  • Contribution 14 | Tekelec. For What's Next. Tekelec Confidential
  • Live Streaming over P2PSIP › Discover and consume distributed real-time content in a peer-to-peer live streaming scenario › Multicast of content, such as TV shows and telepresence › Signaling protocols (Control plane) › Report status such as data availability (which peer has which content) › Create, modify and terminate video sessions › Transmission protocol (User Plane) › Exchange data contents (end-to-end video chunks) SIP P2PSIP P2P Live Streaming 15 | Tekelec. For What's Next. Tekelec Confidential
  • Layered Architecture › Overlay (Core) Network formed by Peers › End nodes are viewers, sources or relays of the video channel › Different functional distributions can be arranged Consumer does most: endpoint-centric approach Overlay does most: network-centric approach Hybrid approach (under study) 16 | Tekelec. For What's Next. Tekelec Confidential
  • Consumer does most › The application logic resides at the end nodes themselves Overlay only keeps information about relaying nodes and channels being emitted 17 | Tekelec. For What's Next. Tekelec Confidential
  • Overlay does most › The application logic resides at the overlay Centralized control of the whole signalling and data interchange 18 | Tekelec. For What's Next. Tekelec Confidential
  • Control Plane (Signaling) Scheduling Algorithm SIP SIP Peer Protocol Consumer Peer Protocol does most Scheduling Algorithm Peer Protocol Peer Protocol SIP SIP Overlay does most 19 | Tekelec. For What's Next. Tekelec Confidential
  • User Plane (Media distribution) Seed Consumer (Relay) Consumer Consumer (Relay) Consumer (Relay) Consumer (Relay) Consumer (Relay) Consumer Consumer Consumer Consumer (Relay) Consumer Consumer (Relay) 20 | Tekelec. For What's Next. Tekelec Confidential
  • Evaluation ‘Messages per Node Per Second’ under churn › Analytical evaluation of the complexity (w.r.t. signaling load) V.Pascual and C.Macián: A layered P2PSIP-based architecture for live video streaming with flexible application logic placement (2008- in review process) Numerical examples for small/large, static/dynamic scenarios Chord is taken as DHT example for the architecture › Good scalability in terms of signalling load involved 21 | Tekelec. For What's Next. Tekelec Confidential
  • Comparison Consumer does most Overlay does most › Main logic of the application › Overlay directly provides the resides at the consumer service › Consumers must have an › Centralized control of the important processing/battery whole signalling and data capacity interchange › Lightly loaded overlay › Respects the tight battery › Overlay only keeps and bandwidth constraints of information about relaying today’s mobile devices nodes and channels being › Lower Scalability emitted 22 | Tekelec. For What's Next. Tekelec Confidential
  • Conclusions 23 | Tekelec. For What's Next. Tekelec Confidential
  • Summary › Live video broadcast in the Internet is a reality › Peer-to-Peer architectures enable reduced cost on infrastructure better scalability on large number of users › But most current P2P streaming applications make use of proprietary protocols › Highly relevant topic for the future but many challenges remain unsolved Protocol, architecture and algorithmic issues Churn together with real-time constraints is the biggest challenge › We presented a layered architecture for P2P live video streaming with flexible application logic placement Based on industry standards First estimation of the complexity and signaling load involved in the architecture shows very promising results, which support our belief that it can grow to very large sizes without severe penalty Still a lot of open issues! 24 |
  • Work-in-Progress › Simulation Comparison with results obtained from the analytical analysis Start-up delay and latency evaluation › Prototyping Local environment and PlanetLab Measurements › Business Model Analysis Relationship between industry actors: “where is the money?” › Participation in Standardization efforts PPSP BOF https://www.ietf.org/mailman/listinfo/ppsp ALTO WG http://www.ietf.org/html.charters/alto-charter.html LEDBAT WG http://www.ietf.org/html.charters/ledbat-charter.html P2PSIP WG http://www.ietf.org/html.charters/p2psip-charter.html 25 | Tekelec. For What's Next. Tekelec Confidential
  • Thank you!
  • References › J.Liu, S.Rao, B.Li and H.Zhang: Opportunities and Challenges of Peer-to-Peer Internet Video Broadcast (2008) › V.Pascual and C.Macián: A layered P2PSIP-based architecture for live video streaming with flexible application logic placement (2008) › V.Pascual et al.: A SIP-based P2P control plane for a P2P transport plane (2008). › V.Pascual et al.: Architecture for a Peer-to-peer Live streaming Service for High Quality Media (2008) › N.Zong and J.Jiang: Survey of P2P Streaming (2008) › Y.Zhang, C.Williams, H.Zhang, N.Zong and S.Dawkins: Problem Statement of Peer to Peer Streaming Protocol (2008) 27 | Tekelec. For What's Next. Tekelec Confidential
  • About Tekelec › Tekelec is a high-performance network applications company that is accelerating the transition to IP Multimedia Subsystem (IMS) networks for service providers around the globe. With its experience at the intersection of network applications and session control, Tekelec creates highly efficient platforms for managing media and delivering network solutions. Corporate headquarters are located near Research Triangle Park in Morrisville, N.C., U.S.A., with research and development facilities and sales offices throughout the world. For more information, please visit www.tekelec.com 28 |
  • About the Author › V. Pascual Ávila holds a Bachelor's Degree in Telematics Engineering, a Master's Degree in Telecommunications Engineering and a Master’s Degree in Information, Communication and Audiovisual Media Technologies from the Universitat Pompeu Fabra (Barcelona), where he graduated with honors and was awarded by the Association of Telecommunication Engineers of Catalonia (COETC). Victor’s previous experience includes working for Voztelecom as a Voice over IP (VoIP) engineer and at Universitat Pompeu Fabra as a research engineer and assistant professor (Telecommunications Engineering School). He is currently working as a System Architect with Tekelec (Germany), leader in signaling products for telecommunications. His professional interests include Internet Telephony, IP Multimedia Subsystem (IMS) networks, Next Generation Networks (NGN) and Peer-to-Peer (P2P) Multimedia Distribution platforms. Victor is active in several IETF working groups and has co-authored a number of Internet-Drafts. 29 |
  • Contact Information Victor Pascual System Architect Tekelec Germany GmbH Am Borsigturm 11 D-13507 Berlin Office: +49 30 32 51 32 12 victor.pascual@tekelec.com 30 | Tekelec. For What's Next. Tekelec Confidential
  • Backup 31 | Tekelec. For What's Next. Tekelec Confidential
  • Operation mode (1/2) › Overlay setup › Nodes registration (and authentication) › Channel Publication › Retrieve List of Channels Overlay returns a list of Channels to the consumer › Retrieve List of Sources Overlay returns an initial list of peers that are currently watching the channel to the consumer (or peer) › Source selection The consumer (or peer) selects some sources to connect and exchange buffer map information to know where to get which data › Buffer Map Exchange Indicate which chunks a relay currently has buffered and can share. A node can request a buffer map from any relay in its current list of sources. After a node receives a buffer map from a relay, the node can request one or more chunks that the relay has advertised in the buffer map 32 | Tekelec. For What's Next.
  • Operation mode (2/2) › Session Scheduling The node decides which data are requested in which order / priority using scheduling algorithm and the information obtained in Buffer Map Exchange › Session Initiation The node requests the data from some connected relays (some others are used as a backup) Get the video from only a few peers at the same time and switch periodically from one peer to another • Chunk transmission among peers • Re-assembling • Peer Reporting to Tracker chunks availability › Update List of Sources The node introduces itself into the List of Sources relaying that channel 33 | Tekelec. For What's Next.
  • The Who is Who in Live Streaming over P2PSIP Consumer does Overlay does most most Overlay as a B2BUA Overlay as a REFER issuer Channel and Source ›SIP Specific Event Notification Publication/Retrieval ›P2PSIP Peer Protocol (DHT based) Channel and Source lists ›P2PSIP Peer Protocol (DHT based) maintenance Buffer Map Exchange ›SIP Specific Event Notification Channel Selection ›User Input Source Selection ›(Pseudo) random algorithm Session Scheduling ›(tuned) OTSp2p algorithm Session creation, ›SIP ›SIP modification and termination ›SIP REFER method ›Referring to Multiple Resources in SIP Session Description ›SDP Offer/Answer Mechanism to Enable File Transfer Media Exchange ›RTP 34 |
  • Consumer does most Consumer Seed Media Relay Publish ‘Channel A’ ‘Channel List’ (A) and ‘Source List’ maintenance (A:Seed) Publish ‘I’m Relaying Channel A’ Startup ‘Source List’ maintenance (A:Seed, Media Relay) Subscribe ‘Channel List’ ‘Channel List’ Channel Selection Subscribe ‘Source List for Channel A’ “Source List for Channel A’ Publish ‘I’m Relaying Channel A’ Source Selection ‘Source List’ maintenance (A: Seed, Media Relay, Consumer) Subscribe ‘BufferMap Status for Channel A’ Subscribe ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ Session Scheduling Session Initiation Session Initiation Data Transfer Data Transfer ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ Session Scheduling Session Update Session Update Data Transfer Data Transfer 35 | ...
  • Overlay does most - Overlay as a REFER issuer Consumer Seed Media Relay Publish ‘Channel A’ ‘Channel List’ (A) and ‘Source List’ maintenance (A:Seed) Publish ‘I’m Relaying Channel A’ Startup ‘Source List’ maintenance (A:Seed, Media Relay) Subscribe ‘BufferMap Status for Channel A’ Subscribe ‘Channel List’ ‘Channel List’ Subscribe ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ Channel Selection ‘Buffer Map Image’ maintenance (Seed:A:x-y, Media Relay:A:z-w) HTTP/SOAP Request Session Scheduling REFER (Seed:A:x-y, Media Relay:A:z-w) Publish ‘I’m Relaying Channel A’ ‘Source List’ maintenance (A:Seed, Media Relay, Consumer) Subscribe ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ ‘Buffer Map Image’ maintenance (Seed:A:x-y, Media Relay:A:z-w, Consumer:A:0) Session Initiation Session Initiation Data Transfer Data Transfer ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ 36 | ...
  • Overlay does most - Overlay as a B2BUA Consumer Seed Media Relay Publish ‘Channel A’ ‘Channel List’ (A) and ‘Source List’ maintenance (A:Seed) Publish ‘I’m Relaying Channel A’ Startup ‘Source List’ maintenance (A:Seed, Media Relay) Subscribe ‘BufferMap Status for Channel A’ Subscribe ‘Channel List’ ‘Channel List’ Subscribe ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ Channel Selection ‘Buffer Map Image’ maintenance (Seed:A:x-y, Media Relay:A:z-w) HTTP/SOAP Request Session Scheduling Publish ‘I’m Relaying Channel A’ ‘Source List’ maintenance (A:Seed, Media Relay, Consumer) Subscribe ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ ‘Buffer Map Image’ maintenance (Seed:A:x-y, Media Relay:A:z-w, Consumer:A:0) Session Initiation Session Initiation Session Initiation Data Transfer Data Transfer ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ ‘BufferMap Status for Channel A’ 37 | ...