Transcript draft-gu-ppsp-tracker-protocol-02

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