Making Peer-to-Peer Work for SIP

Henning Schulzrinnewith Salman Baset, Jae Woo Lee

Dept. of Computer Science, Columbia University, New York

hgs@cs.columbia.edu

SIP 2008 (upperside.fr)

Paris, France

January/February 2008

Jan/Feb 2008 2

Outline

• Why peer-to-peer?• Three types of peer-to-peer systems• Protocol architecture• A prototype for a P2P SIP system• Issues and challenges

Jan/Feb 2008 3

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

Jan/Feb 2008 4

Three kinds of P2P systems

ad-hoc802.11network

dentist office SMEFortune

500

mDNS

unstructuredP2P system

structuredP2P system

(DHT)

networksize

Jan/Feb 2008 5

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

Jan/Feb 2008 6

SIP URI Advertisement Format

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

Jan/Feb 2008 7

z2z: Zeroconf-to-Zeroconf interconnection

rendezvous point - OpenDHT

z2z

Import/exportservices

Zeroconf subnet A

z2z

Import/exportservices

Zeroconf subnet B

Jan/Feb 2008 8

Structured P2P networks (“overlays”)

Neighbor table(successor)

x+2i

x+2i+1

x+2i+2

x+2i+3

id=x

Routing table

• Maps key to data object• Can start search at any node• Finds in O(log N) steps• Examples: Chord, Kademlia, CAN• Distance metric differs

Jan/Feb 2008 9

Unstructured P2P network

• full or partial mesh• nodes keep search index of neighbors• forward queries (e.g., random walk)• allow search expressions• resilient against churn• examples: Gnutella, Gnutella2

Jan/Feb 2008 10

P2PSIP architecture

SIP

P2P

STUNTURN

Peer

NAT

NAT

Client

alice@example.com

bob@example.com

[ Bootstrap / authentication server ]

Overlay1

Overlay2

P2P

SIP

Jan/Feb 2008 11

Protocol stack

HIP

IPv4 IPv6

TCPUDP? SCTP

peer-to-peer lookuppeer-to-peer lookupDNS

H(URL) data (Contact URL, proxy)

SIP

OR

TLSDTLS

Jan/Feb 2008 12

• mDNS work in SIP WG– done; waiting for mDNS publication

• P2PSIP working group– generic lookup mechanism

• DHT-agnostic (CAN, Kademlia, Chord, ...)

– many protocols: ASP, RELOAD, P2PP, P2NS, XPP, SEP, ...

– HIP proposals: HIPHOP, draft-hautakorpi-p2psip-with-hip

• Open issues– how general?

– role of HIP?

– service discovery

– NAT traversal in HIP? specialized ICE?

IETF efforts

Jan/Feb 2008 13

P2PP implementation

• Chord, Kademlia, Bamboo (in-progress)• SHA1, SHA256, MD5, MD4• Runs on Windows & Linux• Integrated with OpenWengo (VoIP phone)• Available for download (Linux + Windows)

http://www1.cs.columbia.edu/~salman/p2pp/setupp2pp.html

Jan/Feb 2008 14

Screen snapshot

• Alice and Bob are part of Kademlia network• Alice calls Bob• The lookup is performed using P2PP• Call is established using SIP

Jan/Feb 2008 15

P2PP – Planet Lab

• 500 node network, 160 machines• OpenDHT: 150-200 nodes/machines• Integrated with Nokia Symbian OS

geographical view routing table

Jan/Feb 2008 16

P2PP – Planet Lab

DHT view

Jan/Feb 2008 17

P2P issues: performance

• Look-up performance for N peers is O(log N)– affects call setup delay– e.g., Skype delay much higher than client-server calls

use combination of peers and clients– only small fraction of participants should be clients

• media generally not routed through overlay• spare capacity more resilient to overload• harder to compensate for resolution hot spots

Jan/Feb 2008 18

P2P issues: economics

• Operator saves on– bandwidth

• minimal for SIP signaling

• interesting for media (TURN NAT traversal, media relay, mixing, transcoding)

– servers• single SIP server can handle > 100,000 users ==> $0.10/month

• except for NAT traversal (heartbeat)

• except for media processing and storage

Jan/Feb 2008 19

P2P issues: 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

Jan/Feb 2008 20

Security & privacy

• Security much harder– user authentication and credentialing

• usually now centralized (“enrollment server”)

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

Jan/Feb 2008 21

OA&M

• Hard to see what’s going on• No real peer-to-peer management systems

– system loading (CPU, bandwidth)• automatic splitting of hot spots

– user experience (signaling delay, data path)

– call failures

• IETF effort: design for manageability and debugging• P2PP adds mechanism to query nodes for characteristics• Who gathers and evaluates the overall system health?

Jan/Feb 2008 22

P2P issues: 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

Jan/Feb 2008 23

P2P issues: mobility

• Mobile nodes are poor peer candidates– power consumption– unreliable links– asymmetric links

• But no problem if clients• Useful for moving networks (train, plane)

Jan/Feb 2008 24

Conclusion

• P2P for SIP can provide– easier configuration– operation in challenged environments– lower infrastructure costs

• But at a cost:– greater system complexity– possibly longer call set-up delays– new security threats

• IETF designing common protocol for identifier lookups– likely to be useable for other purposes