Agenda

1. Agenda • Agenda Bashing (5min) • Problem statement of PPSP – Yunfei.Z (45mins) • Protocol Requirements (10mins) • Comparison of PPLive and PPstream protocols by Internet measurement (10mins) • Vision of Distributed Services Network-a combination of P2PSIP and PPSP implementations (10mins) • Open Discussion (40mins)

2. Problem Statement of P2P Streaming Protocol IETF 74 Yunfei Zhang China Mobile Ning Zong Huawei Tech. James Seng PPlive Hui Zhang NEC Labs, USA 2009.03.23

3. Outline • Motivation • Problem Statement • Scope • Comparison with Other Working Groups • Conclusion

4. Background Facts • 10% of backbone traffic at major Chinese ISP is PPLive • More than BitTorrent • PPLive • 110m users, 2m concurrent online peers , 600+ channels • 20%-30% outside of China (10-15% in US), >200/ countries • PPstream • 70m users, 340+ channels, 2 million concurrent peers • UUSee • 1m concurrent online peers during Olympic Games • CNN (OctoShape) • Obama inauguration ~300K concurrent peers by OctoShape • Many P2P streaming vendors • Babelgum, Kontik, Pando, Abacast, Vakaka… • Each one has a proprietary streaming protocol to support

5. Understanding • There is a great deal of legitimate P2P video traffic on the network • Piracy occurs on any protocol, not just on P2P • Signal and Transport is the focus of PPSP to solve real operation problems • Question: Should Piracy or content protection be part of work?

6. Benefits of standardizing • User: One client can access multiple services • Operator: Easier to cache data to optimize traffic (including mobile Internet) • Network Provider: Open standard allows interface with CDN systems • Content Provider: Developers more likely to implement an open standard, applications work with more services • R&D: Research work improves all services • Market: Standard allows content providers and network providers to cooperate

7. Outline • Motivation • Problem Statement • Scope • Comparison with Other Working Groups • Conclusion

8. Problems to Solve • Interoperability of streaming services • Caching P2P streaming data • Supporting mobile or low bandwidth peers

9. Interoperability Problem • Multiple P2P streaming services • Heterogeneous terminals • Today, may need many clients to connect to many services • Not all services available on all devices PPlive Mobile Phone PPstream PDA UUSee …… OctoShape PC ……. p2p streaming vendors End users/Clients

10. Cache Problem • Need to cache P2P streaming content between domains • Lowering the cross-network traffic • Better user performance • Very difficult with multiple, proprietary protocols, which change frequently ISP1 ISP2 Cache Cache Cache Cache

11. Mobile Streaming Problems • MobileTV has been provided with client/server paradigm • Low scalability/ robustness • How about mobile p2p streaming? • A lot of problems… Peer list Peers Cache Bottleneck for p2p streaming providing Tracker Peer Access Point Low Bandwidth × PC PC Mobile Phone Mobile Phone End-to-end works well No end to end connection

12. Outline • Motivation • Problem Statement • Scope • Comparison with Other Working Groups • Conclusion

13. Standardized Interactions 1) Peer sends request to trackers 2) Tracker returns peer list 3) Peers communicate to exchange peer list, chunk bitmaps and find chunks 4) Chunk transmission among peers 5) Peers periodically report to tracker Not standardizing: 6) Peer Re-assembling and playback 7) Peer scheduling to get the chunk and cache replacement（e.g., BT like, rarest first) Tracker Peer3 1,5 2 3 3 Peer2 Peer1 Peer1 4 3 Peer4

14. Standardize Signaling • Peer ↔ Peer and Peer ↔ Tracker • Standardize format of data • Chunk descriptions • Bitmap • Peer information (online time, link status, capability, etc.) • Standardized mechanisms to exchange information between peers/between peer and tracker • Finding and updating chunk information, bitmaps, etc. • Locating other peers • Evaluate existing options

15. Standardize Transport • Payload between Peer ↔ Peer • No strawman proposal at this moment • Todo: • Evaluate existing transport protocols • Specify or develop protocol for transport

16. Outline • Motivation • Problem Statement • Scope • Comparison with Other Working Groups • Conclusion

17. Relationship to other WGs • P2PSIP specifies how to organize a DHT • ALTO is about providing data to find optimal paths • P2PRG is exploring research problems • PPSP is a narrow, engineering task for an existing problem • PPSP is for standardizing the exchanging information in a streaming scenario • May reuse work from other groups • This work may be useful to other groups

18. Why is this the right place? • IETF is the place for standardizing interoperable Internet-wide protocols • We have a group of interested people who have deployed this, and with expertise in P2P: • Streaming service operators (PPLive etc.) • Top P2P streaming researchers • Existing P2P standards contributors • Operators with P2P streaming implementations • Developers of P2P streaming cache implementations

19. Outline • Motivation • Problem Statement • Scope • Comparison with Other Working Groups • Conclusion

20. Conclusion • Goal: To form a working group within IETF to standardize an open P2P streaming protocol • Needed solve existing operation problem • Work already started on PPSP signaling protocol and transport protocol is under discussion • Deliverables: • 1) PPSP Architectural • 2) PPSP Signal Protocol • 3) PPSP Transport Protocol

21. Acknowledgements • We appreciate much valuable comments and help from -L. Eggert from Nokia -G. Camarillo from Ericsson -C. Williams and J. Wang from ZTE -X. Jiang, H. Song from Huawei -D. Zhang from PPlive -P. Pan -D. Bryan from Cogent Force -S. Shen, L. Xiao and C. Schmidt from NSN -H. Deng from China Mobile -J. Lei from Univ. Goettingen -B. Li from HK Univ. of Sci and Tech

22. Thank you for your attention! Welcome to visit http://labs.chinamobile.com/ppsp for more information