Peertopeer Communication Services Henning Schulzrinne Jae Woo Lee

Peer-to-peer Communication Services Henning Schulzrinne, Jae Woo Lee, Salman Baset Columbia University Wolfgang Kellerer, Zoran Despotovic Do. Co. Mo Communications Laboratories Europe

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

Current results • Conceptual framework: 4 stages of p 2 p 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 • z 2 z: Zeroconf-to-Zeroconf Toolkit – – • • Interconnect Zeroconf networks using Open. DHT C++ prototype for proof of concept z 2 z v 1. 0: open-source Java implementation on Source. Forge Paper submitted to IEEE Globecom’ 07 Workshop on Service Discovery P 2 PP: generic P 2 P 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 p 2 p systems 1. Bootstrapping • Formation of small private p 2 p islands 2. Interconnection • Connectivity and service discovery between the p 2 p islands (each represented by a leader) 3. Structure formation • DHT construction among the leaders 4. Growth • Merger of multiple such DHTs

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: – – RFC 3927: Link-local addressing standard for 1) DNS-SD/m. DNS: Apple’s protocol for 2) & 3) Bonjour: DNS-SD/m. DNS implementation by Apple Avahi: DNS-SD/m. DNS implementation for Linux and BSD

DNS-SD/m. DNS overview • DNS-Based Service Discovery (DNS-SD) adds a level of indirection to SRV using PTR: _daap. _tcp. local. PTR 1: n mapping Tom’s Music. _daap. _tcp. local. 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" "i. TSh Version=196608" "Machine ID=6070 CABB 0585" "Password=true” Toms-machine. local. • A 160. 39. 225. 12 Multicast DNS (m. DNS) – – – Run by every host in a local link Queries & answers are sent via multicast All record names end in “. local. ”

z 2 z: Zeroconf-to-Zeroconf interconnection rendezvous point - Open. DHT Import/export services z 2 z Zeroconf subnet A Zeroconf subnet B

Demo: global i. Tunes sharing • Exporting i. Tunes shares under key “columbia”: $ z 2 z --export: opendht _daap. _tcp --key “columbia” • Importing services stored under key “columbia”: $ z 2 z --import: opendht --key “columbia”

How z 2 z works (exporting) Open. DHT put: key= z 2 z. _daap. _tcp. columbia value= Tom’s Music 160. 39. 225. 12: 3689 z 2 z Password=true …… 1) Send browse request (i. e. , PTR query) for service type: _daap. _tcp 2) Send resolve request (i. e. , SRV, A, and TXT query) for each service 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 …… 3) Export them by putting into Open. DHT

How z 2 z works (importing) Open. DHT get: key=z 2 z. _daap. _tcp. columbia value=Tom’s Music 160. 39. 225. 12: 3689 …… value=Joe’s Music …… z 2 z 1) Issue get call into Open. DHT “A” record for 160. 39. 225. 12 2) Add “A” record into m. DNS Tom’s Music. _daap. _tcp. local _remote-160. 39. 225. 12. local …… m. DNS 3) Import services by registering them (i. e. , add PTR, SRV, TXT records to the local m. DNS)

z 2 z implementation • C++ Prototype using xmlrpc-c for Open. DHT access – Proof of concept – Porting problem due to Bonjour and Cygwin incompatibility • z 2 z v 1. 0 released – Rewritten in Java from scratch – Open-source (BSD license) – Available in Source. Forge (https: //sourceforge. net/projects/z 2 z) • Paper describing design and implementation detail – z 2 z: 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 z 2 z – Fill in the gap of P 2 P-SIP effort: • local & small scale (10 s to 100 s) • 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. 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 (RFC 3840)

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, Lo. ST Meta-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

P 2 P for Voice - Open Issues

Vo. IP 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 • 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: “P 2 P 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 – 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 • P 2 PP adds mechanism to query nodes for characteristics • Who gathers and evaluates the overall system health?

Locality • Most P 2 P 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

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

Peer-to-Peer Protocol (P 2 PP) 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 – Vo. IP – streaming • • P 2 PSIP architecture Peer-to-peer protocol (P 2 PP) P 2 PP 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

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

P 2 PSIP: Concepts • Decentralized SIP – Replace SIP proxy and registrar with p 2 p endpoints • Supernode architecture – P 2 PSIP peers • participate in the p 2 p overlay – P 2 PSIP clients • use peers to locate users and resources

P 2 PSIP architecture [ Bootstrap / authentication server ] alice@example. com Overlay 2 SIP NAT Overlay 1 P 2 P NAT STUN TLS / SSL A peer in P 2 PSIP bob@example. com A client

Peer-to-Peer Protocol (P 2 PP) • P 2 P 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 p 2 p protocol • Not a new DHT! • It is hard! – Too many structured and unstructured p 2 p protocols – Too many design choices! • Lets consider DHTs

DHTs DHT Chord Accordion Tapestry, Pastry, Bamboo Kademlia Geometry Distance function Lookup correctness (neighbor table) Lookup performance (routing table) Ring Modulo numeric difference Successor list Finger table Leaf-set (Pastry) Routing table None Routing table Prefix match. If fails, then Hybrid = modulo Tree + Ring numeric difference XOR of two IDs

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

How to design P 2 PP? • Structured – Identify commonalities in DHTs • Routing table (finger table) • Neighbor table (successor list, leaf-set) – Separate core routing mechanisms from DHTindependent 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 P 2 PP? DHT-independent Bootstrapping Routing-table stabilization Reactive vs. periodic recovery Parallel requests Recursive routing DHT-specific Not restricted to one DHT Bamboo Chord Lookup performance Tapestry Kademlia Lookup correctness Pastry One. Hop Successor / leaf-set Finger table / routing table Routing-table size Proximity neighbor selection Proximity route selection DHT-specific Accordion Modulo addition Prefix-match XOR Geometry Updating routing-table from lookup requests Ring Strict vs. surrogate routing Tree Routing-table exploration Hybrid

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

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

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

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

Peer-to-Peer Protocol (P 2 PP) • Security – DTLS, signatures • Multiple hash function support – SHA 1, SHA 256, MD 4, MD 5 • Diagnostics – churn rate, messages sent/received • Node capabilities – bw determination, CPU utilization, number of neighbors, mobility

Join JP BS P 5 P 7 P 9 1. Query 2. 200 P 5, P 30, P 2 P-Options 3+. STUN (ICE candidate gathering) 4. Join 5. Join 6. 200 7. 200 N(P 9, P 15) 8. Join 9. 200 10. Transfer 11. 200 JP (P 10)

Call establishment P 1 P 3 1. Lookup-Peer (P 7) 6. 200 (P 7 Peer-Info) P 5 2. Lookup-Peer (P 7) 5. 200 (P 7 Peer-Info) 7. INVITE 8. 200 Ok 9. ACK Media P 7 3. Lookup-Peer (P 7) 4. 200 (P 7 Peer-Info)

Peer-to-Peer Protocol (P 2 PP) Peer-Info HT = host | NAT-address | relayed P 2 P-Options

Implementation • • Chord, Kademlia, Bamboo (in-progress) SHA 1, SHA 256, MD 5, MD 4 Windows, Linux Integrated with Open. Wengo (Vo. IP phone) • Available for download (Linux + Windows) http: //www 1. cs. columbia. edu/~salman/p 2 pp/setupp 2 pp. html

Implementation insert (key, value, callback) callback (resp) lookup (key, callback) Bootstrap Client Chord. Peer Kad. Peer Other. Peer Node Distance Routing table Big. Int Neighbor table Sys Transport / timers UDP TCP Parser / encoder Transactions

Screen snapshot • • Alice and Bob are part of Kademlia network Alice calls Bob The lookup is performed using P 2 PP Call is established using SIP

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