ppsp problem statement y.zhang, n.zong, g.camarillo,j.seng,r.yang maastricht july 27,2010
TRANSCRIPT
What’s now and What’s new • Now
– We had got overwhelming consensus on PPSP problem statement in IETF76
– We had set up the PPSP WG in IETF 77– We had hot discussions on candidates protocol selections
in IETF 77• What’s new
– Supplements on the • Target and Problem description• Use case of PPSP• Protocol descriptions• candidates protocol discussions
Key Facts Outline
• Streaming traffic is dominating on the Internet,50%+• Dealing with streaming transfer using P2P is more and more
popular and important– CNTV: P2P broadcasting and VoD of CCTV programs
• FIFA world cup, 3 million online a day and 350 million views
– PPLive,PPStream,UUSee…– Adobe flash,P2P data exchange
• More participants involved in P2P streaming delivery• Infrastructure nodes: Akamai, ChinaCache,ComCast• However almost all of them use proprietary protocols
Problems(1)• Proprietary signaling leads to unnecessary
complexity for cooperative P2P streaming vendors– Case: PPLive broadcasting Chinese spring festival
gala for American Chinese by Pando networks• Few American chinese pplive users, hard to realize
efficient P2P delivery• Borrowing peer resources from Pando
– Different messages and interactions cause the difficulty in interoperability among PPLive peers and Pando peers
Problems(2)
• Proprietary signaling leads to multiple client software in a terminal– Cannot reuse the common parts, wasting a lot of
repeated work• Scheduling algorithms can be different but no use for
the difference in showing what peers have– Terminal limitation may don’t allow for many
clients– Even lead to vicious competitions: Delete the
software each other
Problems(3)
• Proprietary signaling leads to bad network resource utilization– From the network resource utilization perspective,
leading to wasted resource (e.g., storage,bandwidth) sharing
– many repeated on-the-way data for a same content to waste storage and cause congestion
Problems(4)
• Proprietary signaling leads difficult interactions in case of multiple parties involved in the delivery– Case:M P2P streaming vendors, N CDN vendors– CDN can act as a SuperNode(UUSee, RayV,Forthtech)– Better performance for HD Internet streaming
– How to identify different private systems by a same CDN node?---No good ways, CDN/Cache is updating its protocol through case-by-case negotiations.
– CDN nodes: How to report to different trackers with proprietary protocols?
Problems(5)• Proprietary signaling doesn’t address mobile and wireless
environment• More and more mobile and wireless peers
• By now 2.6 million in China• Have more possibility to support P2P
– Better CPU, memory and storage– Better network bandwidth – Many uplink waste for nothing in symmetric links now– Note that we don’t have compulsory mobile peers, Network peers and WIFI
peers are easier selected• But…
– Unsteady network connections– Less steady power– Different media coding for mobile devices
– Current proprietary protocols don’t address this – Reinvent from Scratch?
Foundations in Standards (1)
• Technical feasibility: strong similarity among major systems• Tracker-based architecture• Similar signaling process while diverse transport and
scheduling – tracker and peer communication process, and inter-peer
communication process
• Standards – decoupling the information exchange with the data delivery in P2P
streaming– focusing on key issues, not reinventing the wheel
Foundations in Standards (2)
– Users desire:
– “… broadcasters from the BBC to Germany’s ARD just seem to love the idea of ditching their proprietary platforms.”
– -- Johan Pouwelse, scientific director of P2P Next
– UUSee will start to build an open platform and would like to participate in open protocols to cooperate with content providers, operators and many more participants for a better p2p streaming service.
– -- Zhu Li, CEO of UUSee
Use Case1:Cooperative vendors
A’s Tracker
B’s SuperNodesC’s SuperNodes
Users @B domain Users @C domain
Tracker protocol Tracker protocol
Peer protocol Peer protocol
Use Case2:Heterogeneous P2P Streaming
Tracker
Peer protocol
Tracker protocol
Tracker protocol
Peer protocol
Tracker protocol
Use Case3 : CDN supporting streaming
• PPSP usage– Interface between CDN
nodes and tracker– New construction of
CDN systems by PPSP
A’s Tracker
B’s CDN
Users @B domain
Tracker protocol
Peer protocol
Peer protocol
B’s CDN
Use Case 4:Mobile Supporting Super Nodes in Cellular Mobile Environment
Internet Internet
MSSN
Mobile access network
Mobile access network
Tracker
Tracker Protocol
Peer Protocol
Peer Protocol/HTTP
Two functionalities in MSSN:1)Self operational P2P streaming 2) 3rd P2P streaming withoptimized localization withoutcontinuous update of the protocols
Tasks of PPSP to address• How to quickly get to know the real-time stream swarm peers and what
content chunk they have in case of some Ms of concurrent requests?
• The current best practice is a tracker-based architecture
• Sub-Tasks:– Tracker-peer communication: For information request/answer to
provide suitable peers, esp. in the initial stage
– Peer-peer communication: For information gossip-like exchange for each other’s available stream data status and additional neighbor peers besides tracker tells
Discussions(1)-Tracker Protocol• Tracker organization: Tracker discovery
– Centralized: no trackers interactions– Distributed: more tasks, trackers to share peer lists
• Bittorrent is a good reference for open protocols, but not enough– Different group size
• Bittorent tracker: medium size <1000, global view of ALL peers• PPLIve like tracker: Part view of peers and peer incrementally by peer protocol to
achieve scalability– Different options in the message
• e.g., possible bitmap in VoD for the tracker protocol– Different requirements and user visiting patterns
• video quality and delay• Channel switch• Additional peer recruitment • Different peer roles (super-nodes VS peers)
• Should learn both from Bittorrent and PPLive/PPStream/Ravy for more thoughts on improving the tracker protocol
Discussions(2)-Peer Protocol
• How to exchange chunk availability?
– Modeled as gossip-like protocol, with periodic, pairwise,inter-process interactions of changed available neighbor peers and media piece states called bitmap between peers.
– Information exchanged is of bounded size
– Carried by TCP or UDP,likely together with ICE for NAT traversal support.
– Don’t involve in chunk transfer