1 / 24

Making Peer-to-Peer Work for SIP

Making Peer-to-Peer Work for SIP. Henning Schulzrinne with 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. Outline. Why peer-to-peer? Three types of peer-to-peer systems

dyre
Télécharger la présentation

Making Peer-to-Peer Work for SIP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Making Peer-to-Peer Work for SIP Henning Schulzrinne with 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

  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

  3. Peer-to-peer systems Service discovery High Data size NAT Data size Replication NAT Performance impact / requirement Medium Replication Replication Data size Low NAT VoIP Streaming File sharing

  4. Three kinds of P2P systems structured P2P system (DHT) unstructured P2P system mDNS network size Fortune 500 SME ad-hoc 802.11 network dentist office

  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

  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)

  7. z2z: Zeroconf-to-Zeroconf interconnection rendezvous point - OpenDHT Import/export services Import/export services z2z z2z Zeroconf subnet A Zeroconf subnet B

  8. Structured P2P networks (“overlays”) id=x Neighbor table(successor) 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

  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

  10. P2PSIP architecture [ Bootstrap / authentication server ] alice@example.com Overlay2 Peer SIP NAT Overlay1 STUN TURN P2P NAT SIP bob@example.com P2P Client

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

  12. IETF efforts • 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?

  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

  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

  15. P2PP – Planet Lab • 500 node network, 160 machines • OpenDHT: 150-200 nodes/machines • Integrated with Nokia Symbian OS geographical view routing table

  16. P2PP – Planet Lab DHT view

  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

  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

  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

  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?

  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?

  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

  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)

  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

More Related