Making Peer-to-Peer Work for SIP Henning Schulzrinne with Salman Baset, Jae Woo Lee Dept. of Computer Science, Columbia University, New York SIP 2008 (upperside.fr) Paris, France January/February 2008

Jan/Feb 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 Peer-to-peer systems File sharing VoIPStreaming Low Medium High NAT Data size Performance impact / requirement Service discovery Replication

Jan/Feb Three kinds of P2P systems ad-hoc network dentist office SME Fortune 500 mDNS unstructured P2P system structured P2P system (DHT) network size

Jan/Feb 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

Jan/Feb 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.: - 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 z2z: Zeroconf-to-Zeroconf interconnection rendezvous point - OpenDHT z2z Import/export services Zeroconf subnet A z2z Import/export services Zeroconf subnet B

Jan/Feb Structured P2P networks (“overlays”) Neighbor table (successor) x+2 i x+2 i+1 x+2 i+2 x+2 i+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 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 P2PSIP architecture SIP P2P STUN TURN Peer NAT Client [ Bootstrap / authentication server ] Overlay1 Overlay2 P2P SIP

Jan/Feb Protocol stack HIP IPv4 IPv6 TCP UDP? SCTP peer-to-peer lookup DNS H(URL)  data (Contact URL, proxy) SIP OR TLS DTLS

Jan/Feb 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 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)

Jan/Feb 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 P2PP – Planet Lab 500 node network, 160 machines OpenDHT: nodes/machines Integrated with Nokia Symbian OS geographical viewrouting table

Jan/Feb P2PP – Planet Lab DHT view

Jan/Feb 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 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 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 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 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 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 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 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