1 / 46

Peer-to-peer Communication Services

Peer-to-peer Communication Services. Henning Schulzrinne, Jae Woo Lee, Salman Baset Columbia University Wolfgang Kellerer, Zoran Despotovic DoCoMo Communications Laboratories Europe. Outline. Research overview Conceptual framework Four stages of p2p systems

Olivia
Télécharger la présentation

Peer-to-peer Communication Services

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. Peer-to-peer Communication Services Henning Schulzrinne, Jae Woo Lee, Salman Baset Columbia University Wolfgang Kellerer, Zoran Despotovic DoCoMo Communications Laboratories Europe

  2. Outline • Research overview • Conceptual framework • Four stages of p2p systems • Zeroconf: solution for bootstrapping • Overview and example • z2z: Zeroconf-to-Zeroconf interconnection • Overview, design and implementation • Zeroconf for SIP • Motivation and overview of the Internet Draft • P2P systems for VoIP • P2P-SIP • Background concepts and overview of current proposals • Next step • DHT discovery • DHT initialization

  3. Current results • Conceptual framework: 4 stages of p2p systems • Bootstrapping • Interconnection • Structure formation • Growth • Zeroconf: solution for bootstrapping • Detailed study of Bonjour, Apple’s Zeroconf implementation • Internet Draft published on using Zeroconf for SIP • z2z: Zeroconf-to-Zeroconf Toolkit • Interconnect Zeroconf networks using OpenDHT • C++ prototype for proof of concept • z2z v1.0: open-source Java implementation on SourceForge • Paper submitted to IEEE Globecom’07Workshop on Service Discovery • P2PP: generic P2P transport protocol • Next step: DHT discovery and initialization • How to discover an existing DHT? • How to construct a DHT efficiently from scratch?

  4. Four stages of dynamic p2p systems • Bootstrapping • Formation of small private p2p islands • Interconnection • Connectivity and service discovery between the p2p islands (each represented by a leader) • Structure formation • DHT construction among the leaders • Growth • Merger of multiple such DHTs

  5. Zeroconf: solution for bootstrapping • Three requirements for zero configuration networks: • IP address assignment without a DHCP server • Host name resolution without a DNS server • Local service discovery without any rendezvous server • Solutions and implementations: • RFC3927: Link-local addressing standard for 1) • DNS-SD/mDNS: Apple’s protocol for 2) & 3) • Bonjour: DNS-SD/mDNS implementation by Apple • Avahi: DNS-SD/mDNS implementation for Linux and BSD

  6. DNS-SD/mDNS overview • DNS-Based Service Discovery (DNS-SD) adds a level of indirection to SRV using PTR: _daap._tcp.local. PTR Tom’s Music._daap._tcp.local. _daap._tcp.local. PTR Joe’s Music._daap._tcp.local. Tom’s Music._daap._tcp.local. SRV 0 0 3689 Toms-machine.local. Tom’s Music._daap._tcp.local. TXT "Version=196613" "iTSh Version=196608" "Machine ID=6070CABB0585" "Password=true” Toms-machine.local. A 160.39.225.12 • Multicast DNS (mDNS) • Run by every host in a local link • Queries & answers are sent via multicast • All record names end in “.local.” 1:n mapping

  7. z2z: Zeroconf-to-Zeroconf interconnection rendezvous point - OpenDHT Import/export services Import/export services z2z z2z Zeroconf subnet A Zeroconf subnet B

  8. Demo: global iTunes sharing • Exporting iTunes shares under key “columbia”: $ z2z --export:opendht _daap._tcp --key “columbia” • Importing services stored under key “columbia”: $ z2z --import:opendht --key “columbia”

  9. OpenDHT Send browse request (i.e., PTR query) for service type: _daap._tcp Send resolve request (i.e., SRV, A, and TXT query) for each service Export them by putting into OpenDHT 1) 2) 3) put: key= z2z._daap._tcp.columbia value= Tom’s Music 160.39.225.12:3689 Password=true …… z2z Tom’s Music. _daap._tcp.local Joe’s Music. _daap._tcp.local 160.39.225.12 Tom’s Computer Password=true …… 160.39.225.13 Joe’s Computer Password=false …… How z2z works (exporting)

  10. OpenDHT Issue get call into OpenDHT Add “A” record into mDNS Import services by registering them (i.e., add PTR, SRV, TXT records to the local mDNS) 1) 2) 3) get: key=z2z._daap._tcp.columbia value=Tom’s Music 160.39.225.12:3689 …… value=Joe’s Music …… “A” record for 160.39.225.12 z2z mDNS Tom’s Music._daap._tcp.local _remote-160.39.225.12.local …… How z2z works (importing)

  11. z2z implementation • C++ Prototype using xmlrpc-c for OpenDHT access • Proof of concept • Porting problem due to Bonjour and Cygwin incompatibility • z2z v1.0 released • Rewritten in Java from scratch • Open-source (BSD license) • Available in SourceForge (https://sourceforge.net/projects/z2z) • Paper describing design and implementation detail • z2z: Discovering Zeroconf Services Beyond Local Link • Lee, Schulzrinne, Kellerer, and Despotovic • Submitted to IEEE Globecom’07 Workshop on Service Discovery

  12. Zeroconf for SIP • Enable SIP communication when proxy and registrar are not available • Good use case for z2z • Fill in the gap of P2P-SIP effort: • local & small scale (10s to 100s) • high mobility • avoid construction of DHT • Internet Draft published and presented at IETF-68 • SIP URI Service Discovery using DNS-SD • Lee, Schulzrinne, Kellerer, and Despotovic • http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-01

  13. SIP URI advertisement • Example _sipuri._udp.local. PTR sip:bob@a.com._sipuri._udp.local. _sipuri._udp.local. PTR sip:joe@a.com._sipuri._udp.local. sip:bob@a.com._sipuri._udp.local. SRV 0 0 5060 bobs-host.local. sip:bob@a.com._sipuri._udp.local. TXT txtvers=1 name=Bob contact=sip:bob@bobs-host.local. • Service instance name: Instance.Service.Domain • Instance = ( SIP-URI / SIPS-URI ) [ SP description ] • Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp” • E.g.) sip:bob@example.com - PDA._sipuri._udp.local. • Contact TXT record attribute • Similar to Contact SIP header except: • It contains only a single URI • Non-SIP URIs are not allowed • UA capabilities advertised via field parameters (RFC3840)

  14. Next step: DHT discovery and initialization • DHT discovery (prospective peer to overlay) • How to discover an existing DHT to join • Current mechanisms: • Well-known bootstrap server • Expanding ring multicast • Server selection infrastructure: overlay anycast, LoST • Meta-DHT • DHT initialization • How to construct a DHT efficiently from scratch • first time or after major disruption • deal with network partition? • avoid creating multiple islands • Comparison between different DHT architectures • Ring vs prefix-based • Flat vs hierarchical • Cost considerations: time and network bandwidth • Especially timely with recent Skype failure

  15. P2P for Voice - Open Issues

  16. VoIP functions • All subject to distribution: • call routing • media server (mixing, transcoding, recognition) • media storage • credentialing • authorization • PSTN gateway

  17. Performance • Look-up performance for N peers is O(log N) • affects call setup delay • e.g., Skype delay much higher than C-S calls • ==> use combination of peers and clients • media generally not routed through overlay • spare capacity => more resilient to overload • harder to compensate for hot spots

  18. Economics • Operator saves on • bandwidth • minimal for SIP signaling • interesting for media (TURN, relay, mixing) • servers • single SIP server can handle > 100,000 users ==> $0.10/month • except for NAT traversal (heartbeat) • except for media processing

  19. Reliability • CW: “P2P systems are more reliable” • Catastrophic failure vs. partial failure • single data item vs. whole system • Node reliability • correlated failures of servers (power, access, DOS) • lots of very unreliable servers (95%?) • Natural vs. induced replication of data items

  20. Security & privacy • Security much harder • user authentication and credentialing • usually now centralized • sybil attacks • byzantine failures • Privacy • storing user data on somebody else’s machine • Distributed nature doesn’t help much • one attack likely to work everywhere • CALEA?

  21. OA&M • No real peer-to-peer management systems • system loading (CPU, bandwidth) • automatic splitting of hot spots • user experience (signaling delay, data path) • call failures • P2PP adds mechanism to query nodes for characteristics • Who gathers and evaluates the overall system health?

  22. Locality • Most P2P systems location-agnostic • each “hop” half-way across the globe • Locality matters • media servers, STUN servers, relays, ... • Working on location-aware systems • keep successors in close proximity • AS-local STUN servers

  23. Mobility • Mobile nodes are poor peer candidates • power consumption • unreliable links • asymmetric links • But no problem as clients

  24. Peer-to-Peer Protocol (P2PP) Salman Abdul Baset, Henning Schulzrinne Columbia University

  25. Overview • Objective: key  (opaque) data • distributed data structure with O(log N) or O(1) [rarely] • Practical issues in peer-to-peer systems • Peer-to-peer systems • file sharing • VoIP • streaming • P2PSIP architecture • Peer-to-peer protocol (P2PP) • P2PP design issues • Implementation

  26. Practical issues in peer-to-peer systems • Bootstrap / service discovery • NAT and firewall traversal • TCP or UDP? • Routing-table management • Operation during churn • Availability and replication • Identity and trust management

  27. Peer-to-peer systems Service discovery High Data size NAT Data size Replication NAT Performance impact / requirement Medium Replication Replication Data size Low NAT VoIP Streaming File sharing

  28. P2PSIP: Concepts • Decentralized SIP • Replace SIP proxy and registrar with p2p endpoints • Supernode architecture • P2PSIP peers • participate in the p2p overlay • P2PSIP clients • use peers to locate users and resources

  29. P2PSIP architecture [ Bootstrap / authentication server ] alice@example.com Overlay2 SIP NAT Overlay1 P2P STUN TLS / SSL NAT A peer in P2PSIP bob@example.com A client

  30. Peer-to-Peer Protocol (P2PP) • P2P applications have common requirements such as discovery, NAT traversal, relay selection, replication, and churn management. • Goals • A protocol to potentially implement any structured or unstructured protocol. • Not dependent on a single DHT or p2p protocol • Not a new DHT! • It is hard! • Too many structured and unstructured p2p protocols • Too many design choices! • Lets consider DHTs

  31. DHTs

  32. Periodic recovery Accordion Routing-table stabilization Finger table Tree Kademlia Lookup correctness Parallel requests Prefix-match Modulo addition Routing-table size OneHop Leaf-set Recursive routing Pastry Bootstrapping Updating routing-table from lookup requests Bamboo Ring Tapestry XOR Proximity neighbor selection Lookup performance Successor Reactive recovery Hybrid Chord Strict vs. surrogate routing Proximity route selection Routing-table exploration

  33. How to design P2PP? • Structured • Identify commonalities in DHTs • Routing table (finger table) • Neighbor table (successor list, leaf-set) • Separate core routing mechanisms from from DHT-independent issues. • Unstructured • may not always find all keys • Incorporate mechanisms for • discovery • NAT / firewall traversal • churn, identity and trust management • request routing (recursive / iterative / parallel)

  34. DHT-independent Bootstrapping Routing-table stabilization Reactive vs. periodic recovery Parallel requests Recursive routing Proximity neighbor selection Proximity route selection How to design P2PP? DHT-specific Not restricted toone DHT DHT-specific Bamboo Chord Lookup performance Tapestry Kademlia Lookup correctness Pastry OneHop Accordion Successor / leaf-set Finger table / routingtable Modulo addition Prefix-match Routing-table size XOR Geometry Updating routing-table from lookup requests Ring Hybrid Strict vs. surrogate routing Tree Routing-table exploration

  35. Chord (Strict routing-table management) id=x Neighbor table(successor) Routing table Immediately succeeds routing-table id Node

  36. Chord (flexible routing-table management) id=x Neighbor table Routing table Any node inthe interval Node

  37. Kademlia(XOR) id=x No neighbor table Routing table Node

  38. Peer-to-Peer Protocol (P2PP) • A binary protocol • Geared towards IP telephony but equally applicable to file sharing, streaming, and p2p-VoD • Multiple DHT and unstructured p2p protocol support • Application API • NAT traversal • using STUN, TURN and ICE • ICE encoding in P2PP • Request routing • recursive, iterative, parallel • per message • Supports hierarchy (super nodes [peers], ordinary nodes [clients]) • Reliable or unreliable transport (TCP or UDP)

  39. Peer-to-Peer Protocol (P2PP) • Security • DTLS, TLS, signatures • Multiple hash function support • SHA1, SHA256, MD4, MD5 • Diagnostics • churn rate, messages sent/received • Node capabilities • bw determination, CPU utilization, number of neighbors, mobility

  40. Join JP BS P5 P7 P9 1. Query 2. 200 P5, P30, P2P-Options 3+. STUN (ICE candidate gathering) 4. Join 5. Join JP (P10) 6. 200 7. 200 N(P9, P15) N(P9, P15) 8. Join 9. 200 10. Transfer 11. 200

  41. Call establishment P1 P3 P5 P7 1. Lookup-Peer (P7) 2. Lookup-Peer (P7) 3. Lookup-Peer (P7) 4. 200 (P7 Peer-Info) 5. 200 (P7 Peer-Info) 6. 200 (P7 Peer-Info) 7. INVITE 8. 200 Ok 9. ACK Media

  42. Peer-to-Peer Protocol (P2PP) Peer-Info HT = host | NAT-address | relayed P2P-Options

  43. Implementation • Chord, Kademlia, Bamboo (in-progress) • SHA1, SHA256, MD5, MD4 • Windows, Linux • Integrated with OpenWengo (VoIP phone) • Available for download (Linux + Windows) http://www1.cs.columbia.edu/~salman/p2pp/setupp2pp.html

  44. Implementation insert (key, value, callback) callback (resp) lookup (key, callback) Bootstrap Client ChordPeer KadPeer OtherPeer Node Distance Routing table Parser / encoder Neighbor table BigInt Transactions Sys Transport / timers UDP TCP

  45. Screen snapshot • Alice and Bob are part of Kademlia network • Alice calls Bob • The lookup is performed using P2PP • Call is established using SIP

  46. Conclusion • P2P techniques now becoming mainstream • motivated by low opex, ease of deployment • building block, rather than application • Many operational issues • interconnection: z2z • local peering: Bonjour for SIP • start-up and recovery: cf. Skype failure • P2PP: Common platform protocol • application-neutral • extensible mechanism

More Related