Peer-to-peer Communication Services

Project Status Presentation

Sep 18, 2007

Henning Schulzrinne, Jae Woo Lee, Salman BasetColumbia University

Wolfgang Kellerer, Zoran DespotovicDoCoMo Communications Laboratories Europe

Outline

• Research overview– Initial proposal– Summary of current results

• 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-SIP– Background concepts and overview of current proposals

• Next step– DHT discovery– DHT initialization

Initial research proposal

• Investigate core problems related to p2p communication services– Transient p2p services– Adaptive p2p systems– Standardization of p2p elements

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

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

z2z

Import/exportservices

Zeroconf subnet A

z2z

Import/exportservices

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)

Tom’s Music._daap._tcp.local

Joe’s Music._daap._tcp.local

Send resolve request (i.e., SRV, A, and TXT query) for each service

2)

160.39.225.12Tom’s ComputerPassword=true……

160.39.225.13Joe’s ComputerPassword=false……

Export them by putting into OpenDHT

3)

put:key= z2z._daap._tcp.columbiavalue= Tom’s Music 160.39.225.12:3689 Password=true ……

How z2z works (importing)

OpenDHT

z2z

Issue get call into OpenDHT

1)

Add “A” record into mDNS

2)

Import services by registering them (i.e., add PTR, SRV, TXT records to the local mDNS)

3)

get:key=z2z._daap._tcp.columbiavalue=Tom’s Music

160.39.225.12:3689……

value=Joe’s Music…… mDNS

“A” record for 160.39.225.12

Tom’s Music._daap._tcp.local_remote-160.39.225.12.local……

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 SIP -- Using P2P techniques for SIP-based communications

P2P-SIP: Concepts

• Decentralized SIP– Replace per-domain SIP proxy and

registrar with instances running on p2p endpoints

– largely maintain SIP functionality and protocol

– P2P SIP working group in IETF

• Supernode architecture– P2PSIP peers

• participate in the p2p overlay

– P2PSIP clients• use peers to locate users and resources

P2PSIP architecture

SIP

P2P STUN

TLS / SSL

A peer in P2PSIP

NAT

NAT

A client

alice@example.com

bob@example.com

[ Bootstrap / authentication server ]

Overlay1

Overlay2

P2P-SIP: Current proposals

• Three competing proposals for peer protocol1. Peer-to-Peer Protocol (P2PP)

- S. Baset and H. Schulzrinne- Separation of SIP and P2P protocol- Separation of DHT algorithm and overlay maintenance

- Pluggable DHT algorithms

2. REsource LOcation And Discovery (RELOAD)- D. Bryan, M. Zangrilli, and B. Lowekamp- Successor to dSIP, a SIP extension for P2P- RELOAD is now a binary protocol

3. Address Settlement by P2P (ASP)- C. Jennings, J. Rosenberg, and E. Rescorla- Focus on security and NAT traversal- Leaves DHT details unspecified

Peer-to-peer protocol (P2PP)

• Practical issues in peer-to-peer systems• Peer-to-peer systems

– file sharing– VoIP– streaming

• 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

File sharing VoIP Streaming

Low

Medium

High

NAT

NAT

NAT

Data size

Data size

Data size

Pe

rfo

rman

ce im

pa

ct /

req

uire

me

nt

Service discovery

Replication

Replication

Replication

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

Lookup correctness (neighbor

table)

Lookup performance

(routing table)

ChordAccordion

RingModulo numeric

differenceSuccessor list Finger table

Tapestry, Pastry

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

Kademlia

XOR

Finger table

Parallel requests

Recursive routing Pastry

Bamboo

ChordSuccessor

Modulo additionPrefix-match

Leaf-set

Routing-table stabilization

Lookup correctness

Lookup performanceProximity neighbor selection

Proximity route selection

Routing-table size

Strict vs. surrogate routing

OneHop

Bootstrapping

Updating routing-table from lookup requests

Tapestry Ring

Tree

HybridReactive recovery

Periodic recovery Accordion

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 DHT-independent issues.

• Unstructured• Incorporate mechanisms for

– discovery– NAT / firewall traversal– churn, identity and trust management– request routing (recursive / iterative / parallel)

Parallel requests

Recursive routing

Routing-table stabilization

Proximity neighbor selection

Proximity route selection

Bootstrapping

Reactive vs. periodic recovery

DHT-independent

Kademlia

XOR

Pastry

Bamboo Chord

Modulo addition

Prefix-match

OneHop

Tapestry

Ring

Tree

Hybrid

DHT-specific

Accordion

Finger table / routingtable

Successor / leaf-set

Lookup correctness

Lookup performance

Routing-table size

Strict vs. surrogate routing

Updating routing-table from lookup requests

DHT-specific Not restricted toone DHT

Routing-table exploration

Geometry

How to design P2PP?

Chord (Strict routing-table management)

Neighbor table(successor)

Node

x+2i

x+2i+1

x+2i+2

x+2i+3

id=x

Routing table

Immediately succeeds routing-table id

Chord (flexible routing-table management)

Neighbor table

Node

x+2i

x+2i+1

x+2i+2

x+2i+3

id=x

Routing table

Any node inthe interval

Kademlia(XOR)

Node

2i

2i+1

2i+2

2i+3

id=x

Routing table

No neighbor table

Peer-to-Peer Protocol (P2PP)

• A binary protocol• Geared towards IP telephony but equally applicable to

file sharing and streaming• Multiple DHT and unstructured p2p protocol support• Application API• NAT traversal

– using STUN, TURN and ICE• Request routing

– recursive, iterative, parallel• Supports hierarchy (super nodes [peers], ordinary

nodes [clients])• Multiple hash function support

– SHA1, SHA256, MD4, MD5, ...• TCP or UDP

Peer-to-Peer Protocol (P2PP)

HT = host | NAT-address | relayed

Peer-Info

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

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