Presentation is loading. Please wait.

Presentation is loading. Please wait.

Making Peer-to-Peer Work for SIP Henning Schulzrinne with Salman Baset, Jae Woo Lee Dept. of Computer Science, Columbia University, New York

Similar presentations


Presentation on theme: "Making Peer-to-Peer Work for SIP Henning Schulzrinne with Salman Baset, Jae Woo Lee Dept. of Computer Science, Columbia University, New York"— 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 Jan/Feb 20082 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 Jan/Feb 20083 Peer-to-peer systems File sharing VoIPStreaming Low Medium High NAT Data size Performance impact / requirement Service discovery Replication

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

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

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

9 Jan/Feb 20089 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 Jan/Feb 200810 P2PSIP architecture SIP P2P STUN TURN Peer NAT Client alice@example.com bob@example.com [ Bootstrap / authentication server ] Overlay1 Overlay2 P2P SIP

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

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

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

16 Jan/Feb 200816 P2PP – Planet Lab DHT view

17 Jan/Feb 200817 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 Jan/Feb 200818 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 Jan/Feb 200819 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 Jan/Feb 200820 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 Jan/Feb 200821 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 Jan/Feb 200822 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 Jan/Feb 200823 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 Jan/Feb 200824 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


Download ppt "Making Peer-to-Peer Work for SIP Henning Schulzrinne with Salman Baset, Jae Woo Lee Dept. of Computer Science, Columbia University, New York"

Similar presentations


Ads by Google