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

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

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

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

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

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

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”

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

How z2z works (importing) OpenDHT z2z Issue get call into OpenDHT 1) 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 Add “A” record into mDNS 2) Tom’s Music._daap._tcp.local _remote-160.39.225.12.local …… Import services by registering them (i.e., add PTR, SRV, TXT records to the local mDNS) 3)

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

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

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)

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

P2P for Voice - Open Issues

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

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

Economics Operator saves on bandwidth servers 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

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

Security & privacy Security much harder Privacy 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?

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?

Locality Most P2P systems location-agnostic Locality matters 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

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

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

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

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

Peer-to-peer systems Service discovery High Data size NAT Data size Replication NAT Performance impact / requirement Medium Replication Replication NAT: In filesharing, there are multiple copies of a file. If a peer cannot download a file from a peer behind a NAT, it can possibly consult other peers, and thus NAT issues have a relatively low impact on filesharing than VoIP. Not so in bit-torrent style systems. Replication: Implicit replication for popular content in file-sharing. No implicit replication in VoIP. P2P protocol should actively replicate for availability. Low NAT Data size File sharing VoIP Streaming

P2PSIP: Concepts Decentralized SIP Supernode architecture 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

P2PSIP architecture [ Bootstrap / authentication server ] alice@example.com Overlay2 SIP NAT Overlay1 P2P STUN TLS / SSL STUN=session traversal utilities Optional bootstrap authentication server NAT A peer in P2PSIP bob@example.com A client

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

Lookup correctness (neighbor table) Lookup performance (routing table) DHTs DHT Geometry Distance function Lookup correctness (neighbor table) Lookup performance (routing table) Chord Accordion Ring Modulo numeric difference Successor list Finger table Tapestry, Pastry, Bamboo Hybrid = Tree + Ring Prefix match. If fails, then modulo numeric difference Leaf-set (Pastry) Routing table Kademlia XOR XOR of two IDs None Tapestry has surrogate routing Chord has a strict requirement of how routing table is filled. Each node in routing table row must succeed the interval. Accordion relaxes it.

Routing-table stabilization 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 Slide: This slide shows many different DHT-independent and DHT-specific design choices Different names for similar concepts (finger, routing-table). Mixing of DHT-independent and DHT-specific issues in original papers. Proximity neighbor selection Lookup performance Successor Reactive recovery Hybrid Chord Strict vs. surrogate routing Proximity route selection Routing-table exploration

How to design P2PP? Structured Unstructured Incorporate mechanisms for 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)

How to design P2PP? DHT-independent Parallel requests Recursive routing Routing-table stabilization Proximity neighbor selection Proximity route selection Bootstrapping Reactive vs. periodic recovery DHT-independent DHT-specific Not restricted to one DHT DHT-specific Bamboo Chord Lookup performance Tapestry Kademlia Lookup correctness Pastry OneHop Accordion Successor / leaf-set Finger table / routing table 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

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

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

Kademlia (XOR) id=x No neighbor table Routing table Node 2i 2i+1 2i+2 Can be skipped. Node

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) Session Traversal Utilities for (NAT) Interactive connectivity establishment (ICE) Security mechanisms in progress

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

Join JP BS P5 P7 P9 JP (P10) 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) P2P-Options=P2P algorithm, hash algorithm, logarithm base 1) Joining peer (JP) first sends a query message to the bootstrap server to discover P2P-Options and other peers in the network. 2) It then discovers its NAT type and gathers ICE candidates. 3) Sends a join request which is recursively forwarded. 4) JP will be inserted between P7 and P9. 5) P9 is responsible for all objects between [P7, P9]. It transfers the relevant objects to JP. 6) JPs gathered candidates are sent in the Peer-Info TLV. N(P9, P15) 8. Join 9. 200 10. Transfer 11. 200

Call establishment P1 P3 P5 P7 1. Lookup-Peer (P7) 2. 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

Peer-to-Peer Protocol (P2PP) Peer-Info HT = host | NAT-address | relayed Host, server-reflexive, peer reflexive, relayed Algorithm=Hash algorithm Base=Log base P2P-Options

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 Currently, only executables are available for download. Source code will be made available soon. Will be running on planet-lab soon.

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

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

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