Transcript Document 7186207

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
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
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
DNS-SD/mDNS overview
•
DNS-Based Service Discovery (DNS-SD) adds a
level of indirection to SRV using PTR:
_daap._tcp.local.
_daap._tcp.local.
PTR
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" "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.”
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
put:
key=
z2z._daap._tcp.columbia
value=
Tom’s Music
160.39.225.12:3689
z2z
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 OpenDHT
How z2z works (importing)
OpenDHT
get:
key=z2z._daap._tcp.columbia
value=Tom’s Music
160.39.225.12:3689
……
value=Joe’s Music
……
z2z
1) Issue get call into
OpenDHT
“A” record for
160.39.225.12 2) Add “A” record into
mDNS
mDNS
Tom’s Music._daap._tcp.local
_remote-160.39.225.12.local
……
3) Import services by
registering them
(i.e., add PTR, SRV,
TXT records to the local
mDNS)
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:[email protected]._sipuri._udp.local.
_sipuri._udp.local. PTR sip:[email protected]._sipuri._udp.local.
sip:[email protected]._sipuri._udp.local. SRV
0 0 5060 bobs-host.local.
sip:[email protected]._sipuri._udp.local. TXT
txtvers=1 name=Bob contact=sip:[email protected].
• Service instance name: Instance.Service.Domain
– Instance = ( SIP-URI / SIPS-URI ) [ SP description ]
– Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp”
– E.g.) sip:[email protected] - 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
• 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
– 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
– 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
Performance impact / requirement
Peer-to-peer systems
High
Service discovery
Data size
NAT
Replication
Medium
Data size
NAT
Replication
Replication
Low
NAT
File sharing
Data size
VoIP
Streaming
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
P2PSIP architecture
[ Bootstrap / authentication server ]
[email protected]
Overlay2
SIP
NAT
Overlay1
P2P
STUN
TLS / SSL
NAT
A peer in P2PSIP
[email protected]
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
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
Prefix match. If
fails, then
Hybrid =
modulo
Leaf-set (Pastry)
Tree + Ring
numeric
difference
XOR
XOR of two IDs
None
Routing table
Routing table
Periodic recovery
Routing-table stabilization
Finger table
Tree
Lookup correctness
Parallel requests
OneHop
Recursive routing
Kademlia
Prefix-match
Modulo addition
Routing-table size
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 P2PP?
• Structured
– Identify commonalities in DHTs
• Routing table (finger table)
• Neighbor table (successor list, leaf-set)
– Separate core routing mechanisms from 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 P2PP?
DHT-independent
Bootstrapping
Routing-table stabilization
Reactive vs. periodic
recovery
Parallel requests
Recursive routing
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
Routing-table size
Proximity neighbor selection
Modulo addition
Prefix-match
XOR
Geometry
Proximity route selection
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+2i
Immediately
succeeds
routing-table id
x+2i+1
x+2i+2
x+2i+3
Node
Chord
(flexible routing-table management)
id=x
Neighbor table
Routing table
x+2i
Any node in
the interval
x+2i+1
x+2i+2
x+2i+3
Node
Kademlia
(XOR)
id=x
No neighbor
table
Routing table
2i
2i+1
2i+2
2i+3
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)
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
1. Query
2. 200
P5, P30, P2P-Options
3+. STUN (ICE candidate gathering)
4. Join
5. Join
6. 200
7. 200
N(P9, P15)
N(P9, P15)
8. Join
9. 200
10. Transfer
11. 200
JP
(P10)
Call establishment
P1
P3
1. Lookup-Peer (P7)
6. 200 (P7 Peer-Info)
P5
2. Lookup-Peer (P7)
5. 200 (P7 Peer-Info)
7. INVITE
8. 200 Ok
9. ACK
Media
P7
3. Lookup-Peer (P7)
4. 200 (P7 Peer-Info)
Peer-to-Peer Protocol (P2PP)
Peer-Info
HT = host | NAT-address | relayed
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
Implementation
insert (key, value, callback)
callback (resp)
lookup (key, callback)
Bootstrap
Client
ChordPeer
KadPeer
OtherPeer
Node
Distance
Routing table
BigInt
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 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