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

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
Toms-machine.local.
Tom’s Music._daap._tcp.local. TXT
"Version=196613" "iTSh Version=196608"
"Machine ID=6070CABB0585" "Password=true”
Toms-machine.local. A
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. 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
: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)
Tom’s Computer
Password=true ……
Joe’s Computer
Password=false

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

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

13. SIP URI advertisement Example
_sipuri._udp.local. PTR _sipuri._udp.local. PTR SRV
bobs-host.local.
TXT
txtvers=1 name=Bob
Service instance name: Instance.Service.Domain
Instance = ( SIP-URI / SIPS-URI ) [ SP description ]
Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp”
E.g.) - 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 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

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

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

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

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

29. P2PSIP architecture [ Bootstrap / authentication server ]
Overlay2
SIP
NAT
Overlay1
P2P
STUN
TLS / SSL
STUN=session traversal utilities
Optional bootstrap authentication server
NAT
A peer in P2PSIP
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. 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.

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

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

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

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

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

37. Kademlia (XOR) id=x No neighbor table Routing table Node 2i 2i+1 2i+2
Can be skipped.
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)
Session Traversal Utilities for (NAT)
Interactive connectivity establishment (ICE)
Security mechanisms in progress

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

41. Call establishment P1 P3 P5 P7 1. Lookup-Peer (P7) 2. Lookup-Peer (P7)
(P7 Peer-Info)
(P7 Peer-Info)
(P7 Peer-Info)
7. INVITE Ok
9. ACK
Media

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

43. Implementation Chord, Kademlia, Bamboo (in-progress)
SHA1, SHA256, MD5, MD4
Windows, Linux
Integrated with OpenWengo (VoIP phone)
Available for download (Linux + Windows)
Currently, only executables are available for download. Source code will be made available soon.
Will be running on planet-lab soon.

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