Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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 1 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 Cache ISP2 • Peer4 Peer2 Ever larger fingerprint library in DPI box! 2.DPI box dealing with n different protocols 1.Peer request protocols1,2,..n Peer1 Peer3 4.Peer serving protocol 1,2,..n for one cache 2 After PPSP used… Source1 Tracker SourceN Tracker 3.PPSP tracker protocol ISP1 Cache ISP2 Peer4 Peer2 2.DPI Much Slimer with same protocol 1.PPSP tracker protocol Peer1 Peer3 4.PPSP peer protocol 3 General Questions on PPSP WG Yunfei Zhang 4 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 pullpush mode – Proposal: Mandatory support for pull and optional feather to support push if possible 5 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 6 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 7 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? 8 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 9 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 10 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 11 Thanks! Q&A? 12