Transcript: New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
International SIP conference 2009
1. 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.
2. 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
4. Video Broadcast in the Internet? (1/2)
4 | Tekelec. For What's Next. Tekelec Confidential
5. 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
6. 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 |
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
15. 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
16. 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
17. 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
18. 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
19. 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
21. 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
22. 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
24. 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 |
25. 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
27. 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
28. 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 |
29. 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 |
30. 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
32. 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.
33. 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.
34. 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 |
35. 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 | ...
36. 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 | ...
37. 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 | ...