1 / 12

Problem Statement of P2P Streaming Protocol (PPSP) draft-ietf-ppsp-problem-statement-00

Problem Statement of P2P Streaming Protocol (PPSP) draft-ietf-ppsp-problem-statement-00. Y. Zhang , N. Zong, G.Camarillo , J.seng and R. Yang IETF-79, Beijing China, November 12, 2010. Change since individual draft -06 （ 1 ）： Use case on cache.

karina-baldwin
Download Presentation

Problem Statement of P2P Streaming Protocol (PPSP) draft-ietf-ppsp-problem-statement-00

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Problem Statement of P2P Streaming Protocol (PPSP)draft-ietf-ppsp-problem-statement-00 Y. Zhang, N. Zong, G.Camarillo, J.seng and R. Yang IETF-79, Beijing China, November 12, 2010

  2. Change since individual draft -06（1）：Use case on cache • Currently：Cache using DPI (Deep Packet Inspection)to identify and cache corresponding contents • May need continuous update on the fingerprint library …. Source1 Tracker SourceN Tracker 3.Cache request protocol 1,2,..n ISP1 Ever larger fingerprint library in DPI box! Cache 2.DPI box dealing with n different protocols ISP2 1.Peer request protocols1,2,..n Peer4 Peer2 Peer1 Peer3 4.Peer serving protocol 1,2,..n for one cache

  3. Source1 Tracker SourceN Tracker 3.PPSP tracker protocol ISP1 Cache 2.DPI ISP2 1.PPSP tracker protocol Peer4 Peer2 Peer1 Peer3 4.PPSP peer protocol After PPSP used… Much Slimer with same protocol

  4. General Questions on PPSP WG Yunfei Zhang

  5. Open Issue #1 • Should we use pull-based only or include push/pull-push? • Reasons for pull-only • Best practices: PPLive, PPStream, UUSee, TVAnts,.. • Flexible topology • Works for poor network QoS, better for peer churn, more fit with current Internet • Reasons for push: • Low latency using push • Less signaling traffic • Also some “reasonable” tech on network coding using hybrid pull-push mode • Proposal: Mandatory support for pull and optional feather to support push if possible

  6. Open Issue #1 (from mailing list) • More messages in pull-push for PPSP (example) • Tracker protocol: No change • Peer protocol: • +Substream Subscribe Request • +Substream Subscribe Response • +Substream Subscribe Inform • +Substream State Feedback

  7. Open Issue #2 • Tracker or Non-tracker? • Clarification: Non-tracker doesn’t mean there is No (Part of ) Tracker functionality in the peers • We call the peer with tracker functionality “peer tracker” • PPSP tracker protocol is for information exchange between the peer tracker and normal peer

  8. Open Issue #3 • Binary or text encoding? • Reasons for Binary: • Simple • Efficient • More suitable for mobile phones • Reasons for text: • Readable • acceptable traffic increase compared with binary encoding (e.g., 10%+ for HTTP?) • Proposal: • Need a thorough analysis and experiments on both encodings • Support both encodings?

  9. Open Issue #4 • Do we need to address NAT traversal in PPSP with new protocol design? • Reasons for: • A large fraction of peers behind NATs • Situation in China (UUSee): • 50%, public IP • 40%, Full cone • 5%, Restricted cone • 5%, others • Reasons against: • Peerlist can include ENOUGH peers with public IP address • RELAOD has complete considerations on this, just re-use it

  10. Open Issue #5 • PeerID or IP for the identifier in the peerlist • For peerID • Easily re-use RELOAD for connecting with serving peer in a DHT • Easily NAT traversing • Mobility support • For IP • Low delay for transfer • Peers are just meshed and not DHT • PPSP tolerant IP address change and enough time for IP address update • Proposals: Add both in the message, IP is mandatory and PeerID is used if NO enough peers with public IP

  11. Next Steps • Reflect the reviewers’ comments on the draft • Security section: Tracker attack • Use case: Better and more solid description • Open issues • Refine the document (need more reviewers) and after that seeking WGLC

  12. Thanks!Q&A?

More Related