ppsp problem statement y.zhang, n.zong, g.camarillo,j.seng,r.yang maastricht july 27,2010

19
PPSP Problem Statement Y.Zhang, N.Zong, G.Camarillo,J.Seng,R.Yang Maastricht July 27,2010

Upload: marvin-carson

Post on 01-Jan-2016

217 views

Category:

Documents


2 download

TRANSCRIPT

PPSP Problem Statement

Y.Zhang, N.Zong, G.Camarillo,J.Seng,R.YangMaastricht

July 27,2010

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?

To address all these motivations, open protocols are required

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

Thanks!