Peer-to-peer Communication Services

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, Apples 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 Globecom07 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 Apples 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 Toms Music._daap._tcp.loc
  al.
• _daap._tcp.local. PTR Joes Music._daap._tcp.loc
  al.
• Toms Music._daap._tcp.local. SRV
• 0 0 3689
  Toms-machine.local.
• Toms Music._daap._tcp.local. TXT
• "Version196613" "iTSh Version196608"
  
• "Machine ID6070CABB0585"
  "Passwordtrue
• 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.

1n 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 --exportopendht _daap._tcp --key
  columbia
• Importing services stored under key columbia
• z2z --importopendht --key columbia

9
How z2z works (exporting)
10
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 Globecom07 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-ur
  i-01

13
SIP URI advertisement

• Example
• _sipuri._udp.local. PTR sipbob_at_a.com._sipuri._u
  dp.local. _sipuri._udp.local. PTR
  sipjoe_at_a.com._sipuri._udp.local.
  sipbob_at_a.com._sipuri._udp.local. SRV
• 0 0 5060
  bobs-host.local.
• sipbob_at_a.com._sipuri._udp.local. TXT
• txtvers1 nameBob contactsipbob_at_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.) sipbob_at_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
• gt use combination of peers and clients
• media generally not routed through overlay
• spare capacity gt 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 gt 100,000 users gt
  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 elses machine
• Distributed nature doesnt help much
• one attack likely to work everywhere
• CALEA?

21
OAM

• 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
NAT
Data size
Data size
Replication
NAT
Performance impact / requirement
Medium
Replication
Replication
Data size
Low
NAT
File sharing
VoIP
Streaming
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_at_example.com
Overlay2
SIP
NAT
Overlay1
P2P
STUN
TLS / SSL
NAT
A peer in P2PSIP
bob_at_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
DHT Geometry Distance function Lookup correctness (neighbor table) Lookup performance (routing table)
ChordAccordion 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 Routing table
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
Chord
Hybrid
Proximity route selection
Strict vs. surrogate routing
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
How to design P2PP?
DHT-specific
DHT-specific Not restricted toone DHT
Bamboo
Chord
Lookup performance
Kademlia
Tapestry
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)
idx
Neighbor table(successor)
Routing table
x2i
x2i1
x2i2
x2i3
Immediately succeeds routing-table id
Node
36
Chord (flexible routing-table management)
idx
Neighbor table
Routing table
x2i
x2i1
x2i2
x2i3
Any node inthe interval
Node
37
Kademlia(XOR)
idx
No neighbor table
Routing table
2i
2i1
2i2
2i3
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/setupp2p
  p.html

44
Implementation
insert (key, value, callback)
callback (resp)
lookup (key, callback)
Client
Bootstrap
ChordPeer
KadPeer
OtherPeer
Node
Parser / encoder
Routing table
Distance
Neighbor table
BigInt
Transactions
Transport / timers
Sys
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