1. Peer-to-peer Communication Services Project Status Presentation Sep 18, 2007 Henning Schulzrinne, Jae Woo Lee, Salman Baset Columbia University Wolfgang Kellerer, Zoran Despotovic DoCoMo Communications Laboratories Europe

2. Outline Research overview –Initial proposal –Summary of current results 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-SIP –Background concepts and overview of current proposals Next step –DHT discovery –DHT initialization

3. Initial research proposal Investigate core problems related to p2p communication services –Transient p2p services –Adaptive p2p systems –Standardization of p2p elements

4. 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’07 Workshop on Service Discovery Next step: DHT discovery and initialization –How to discover an existing DHT? –How to construct a DHT efficiently from scratch?

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

6. Zeroconf: solution for bootstrapping Three requirements for zero configuration networks: 1)IP address assignment without a DHCP server 2)Host name resolution without a DNS server 3)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

7. 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

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

9. 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”

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

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

12. 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)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

13. 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

14. 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)

15. 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

16. P2P SIP -- Using P2P techniques for SIP-based communications

17. P2P-SIP: Concepts Decentralized SIP –Replace per-domain SIP proxy and registrar with instances running on p2p endpoints –largely maintain SIP functionality and protocol –P2P SIP working group in IETF Supernode architecture –P2PSIP peers participate in the p2p overlay –P2PSIP clients use peers to locate users and resources

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

19. P2P-SIP: Current proposals Three competing proposals for peer protocol 1.Peer-to-Peer Protocol (P2PP)Peer-to-Peer Protocol (P2PP) - S. Baset and H. Schulzrinne - Separation of SIP and P2P protocol - Separation of DHT algorithm and overlay maintenance - Pluggable DHT algorithms 2.REsource LOcation And Discovery (RELOAD) - D. Bryan, M. Zangrilli, and B. Lowekamp - Successor to dSIP, a SIP extension for P2P - RELOAD is now a binary protocol 3.Address Settlement by P2P (ASP) - C. Jennings, J. Rosenberg, and E. Rescorla - Focus on security and NAT traversal - Leaves DHT details unspecified

20. Peer-to-peer protocol (P2PP) Practical issues in peer-to-peer systems Peer-to-peer systems –file sharing –VoIP –streaming Peer-to-peer protocol (P2PP) P2PP design issues Implementation

21. 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

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

23. 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

24. DHTs DHTGeometry Distance function Lookup correctness (neighbor table) Lookup performance (routing table) Chord Accordion Ring Modulo numeric difference Successor listFinger table Tapestry, Pastry Hybrid = Tree + Ring Prefix match. If fails, then modulo numeric difference Leaf-set (Pastry)Routing table KademliaXORXOR of two IDsNoneRouting table

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

26. 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 Incorporate mechanisms for –discovery –NAT / firewall traversal –churn, identity and trust management –request routing (recursive / iterative / parallel)

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

28. Chord (Strict routing-table management) Neighbor table (successor) Node x+2 i x+2 i+1 x+2 i+2 x+2 i+3 id=x Routing table Immediately succeeds routing-table id

29. Chord (flexible routing-table management) Neighbor table Node x+2 i x+2 i+1 x+2 i+2 x+2 i+3 id=x Routing table Any node in the interval

30. Kademlia (XOR) Node 2i2i 2 i+1 2 i+2 2 i+3 id=x Routing table No neighbor table

31. Peer-to-Peer Protocol (P2PP) A binary protocol Geared towards IP telephony but equally applicable to file sharing and streaming Multiple DHT and unstructured p2p protocol support Application API NAT traversal –using STUN, TURN and ICE Request routing –recursive, iterative, parallel Supports hierarchy (super nodes [peers], ordinary nodes [clients]) Multiple hash function support –SHA1, SHA256, MD4, MD5,... TCP or UDP

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

33. 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

34. 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