making peer-to-peer work for sip
DESCRIPTION
Making Peer-to-Peer Work for SIP. Henning Schulzrinne with Salman Baset, Jae Woo Lee Dept. of Computer Science, Columbia University, New York [email protected] SIP 2008 (upperside.fr) Paris, France January/February 2008. Outline. Why peer-to-peer? Three types of peer-to-peer systems - PowerPoint PPT PresentationTRANSCRIPT
Making Peer-to-Peer Work for SIP
Henning Schulzrinnewith Salman Baset, Jae Woo Lee
Dept. of Computer Science, Columbia University, New York
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:[email protected] - 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
[ 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 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