Upload
nasim-barron
View
36
Download
1
Tags:
Embed Size (px)
DESCRIPTION
P2P-SIP Peer to peer Internet telephony using SIP. Kundan Singh and Henning Schulzrinne Columbia University, New York June 2005 http://www.cs.columbia.edu/IRT/p2p-sip. Introduction What is P2P? and SIP? Why P2P-SIP? Architecture SIP using P2P vs P2P over SIP; Components that can be P2P - PowerPoint PPT Presentation
Citation preview
P2P-SIPP2P-SIPPeer to peer Internet telephony using Peer to peer Internet telephony using SIPSIP
Kundan Singh and Henning Schulzrinne Columbia University, New York
June 2005http://www.cs.columbia.edu/IRT/p2p-sip
2
OverviewOverview Introduction
What is P2P? and SIP? Why P2P-SIP? Architecture
SIP using P2P vs P2P over SIP; Components that can be P2P
Implementation Choice of P2P (DHT); Node join, leave;
message routing Conclusions and future work
Total 33 slides
3
What is P2P?What is P2P? Share the resources of
individual peers CPU, disk, bandwidth,
information, …
C
C
C
C
C
SP
P
P
P
P
Computer systems
Centralized Distributed
Client-server Peer-to-peer
Flat Hierarchical Pure Hybrid
mainframesworkstations
DNSmount
RPCHTTP
GnutellaChord
NapsterGroove
Kazaa
File sharing
Communication and collaboration
Distributed computing
SETI@Homefolding@Home
NapsterGnutellaKazaaFreenetOvernet
MagiGrooveSkype
4
P2P goalsP2P goals Resource aggregation -
CPU, disk, … Cost sharing/reduction Improved
scalability/reliability Interoperability -
heterogeneous peers Increased autonomy at
the network edge Anonymity/privacy Dynamic (join, leave),
self organizing Ad hoc communication
and collaboration
Definition fuzzy both client and
server? true for proxy
no need for central server
true for SIP-based media
SIP can be e2e proxy functions
distributed among end systems
5
Distributed Hash Table Distributed Hash Table (DHT)(DHT) Types of search
Central index (Napster) Distributed index with flooding (Gnutella) Distributed index with hashing (Chord)
Basic operationsfind(key), insert(key, value), delete(key), but no search(*)
Properties/types Every peer has complete table
Chord Every peer has one key/value
Search time or messages
O(1) O(log(N)) O(n)
Join/leave messages
O(n) O(log(N)2) O(1)
6
Why P2P-SIP?Why P2P-SIP?
Bob’s hostAlice’s host128.59.19.194
[email protected] =>128.59.19.194
INVITE [email protected]
Contact: 128.59.19.194
columbia.edu
Client-server=> maintenance, configuration, controlled infrastructure
P2P overlay
Alice128.59.19.194
REGISTERINVITE alice
128.59.19.194
No central server, search latency
7
How to combine SIP + How to combine SIP + P2P?P2P?
SIP-using-P2P Replace SIP
location service by a P2P protocol
P2P-over-SIP Additionally,
implement P2P using SIP messaging
P2P network
Alice128.59.19.194
INSERT
INVITE sip:[email protected]
P2P-SIPoverlay Alice
128.59.19.194
REGISTERINVITE aliceFIND
8
SIP-using-P2PSIP-using-P2P
Reuse optimized and well-defined external P2P network
Define P2P location service interface to be used in SIP
Extends to other signaling protocols
9
P2P-over-SIPP2P-over-SIP P2P algorithm over SIP without
change in semantics No dependence on external P2P
network Reuse and interoperate with existing
components, e.g., voicemail Built-in NAT/media relays Message overhead
10
What else can be P2P?What else can be P2P?
Rendezvous/signaling Configuration storage Media storage Identity assertion (?) Gateway (?) NAT/media relay (find best one)
11
Our P2P-SIP approachOur P2P-SIP approach Unlike server-based SIP architecture Unlike proprietary Skype architecture
Robust and efficient lookup using DHT Interoperability
DHT algorithm uses SIP communication Hybrid architecture
Lookup in SIP+P2P Unlike file-sharing applications
Data storage, caching, delay, reliability Disadvantages
Lookup delay and security
12
Background: DHT (Chord)Background: DHT (Chord) Identifier circle Keys assigned to
successor Evenly distributed
keys and nodes Finger table: logN
ith finger points to first node that succeeds n by at least 2i-1
Stabilization for join/leave
1
8
14
21
32
38
58
47
10
2430
54
38
42
Key node
8+1 = 9 14
8+2 = 10
14
8+4 = 12
14
8+8 = 16
21
8+16=24
32
8+32=40
42
0 1 2 3 4 5 6 7 8
13
Design alternativesDesign alternatives
65a1fc
d13da3
d4213f
d462bad467c4
d471f1
d46a1c
Route(d46a1c)
18
14
21
3238
58
47
10
24 30
54
38
42
Use DHT in server farm
Use DHT for all clients - but some are resource limited
Use DHT among super-nodes
1. Hierarchy2. Dynamically adapt
servers
clients
1
10
2430
54
38
14
Architecture of prototypeArchitecture of prototype
User interface (buddy list, etc.)
SIPICE RTP/RTCP
Codecs
Audio devicesDHT (Chord)
On startup
Discover
User location
Multicast REGISTERPeer found/Detect NAT
REGISTER
REGISTER, INVITE,MESSAGE
Signup,Find buddies
JoinFind
Leave
On resetSignout,transfer
IM,call
SIP-over-P2P
P2P-using-SIP
15
Naming and Naming and authenticationauthentication SIP URI as node and user identifiers
Known node: sip:[email protected] Unknown node: sip:[email protected] User: sip:[email protected]
User name is chosen randomly by the system, by the user, or as user’s email
Email the randomly generated password TTL, security
16
SIP messagesSIP messages DHT (Chord) maintenance
Query the node at distance 2k with node id 11REGISTER
To: <sip:[email protected]>
From: <sip:[email protected]>
SIP/2.0 200 OK
To: <sip:[email protected]>
Contact: <sip:[email protected]>; predecessor=sip:[email protected]
Update my neighbor about meREGISTER
To: <sip:[email protected]>
Contact: <sip:[email protected]>; predecessor=sip:[email protected]
1
10
15
22
Find(11) gives 15
7
17
SIP messagesSIP messages
User registrationREGISTER
To: sip:[email protected]
Contact: sip:[email protected]:8094
Call setup and instant messagingINVITE sip:[email protected]
To: sip:[email protected]
From: sip:[email protected]
18
Node startupNode startup SIP
REGISTER with SIP registrar DHT
Discover peers: multicast REGISTER
SLP, bootstrap, host cache Join DHT using node-
key=Hash(ip) Query its position in DHT Update its neighbors Stabilization: repeat periodically
User registers using user-key=Hash([email protected])
REGISTER
DB
sipd
Detect peers
columbia.edu
14
32
5812
42
REGISTER alice=42
REGISTER bob=12
19
Node leavesNode leaves Chord reliability
Log(N) successors, replicate keys
Graceful leave Un-REGISTER Transfer registrations
Failure Attached nodes detect and
re-REGISTER New REGISTER goes to new
super-nodes Super-nodes adjust DHT
accordingly
DHT
REGISTER key=42
OPTIONS
42
42
REGISTER
20
ImplementationImplementation sippeer: C++,
Unix (Linux), Chord Node join and
form the DHT Node failure is
detected and DHT updated
Registrations transferred on node shutdown
1
11
9
30
26
31
15
29
25
19
31
26
21
Adaptor for existing Adaptor for existing phonesphones
Use P2P-SIP node as an outbound proxy
ICE for NAT/firewall traversal STUN/TURN
server in the node
22
Hybrid (federated) Hybrid (federated) architecturearchitecture
Cross register, or
Locate during call setup DNS, or P2P-SIP
hierarchy
23
EvaluationEvaluationscalabilityscalability
#messages depends on Keep-alive and finger table refresh rate Call arrival distribution User registration refresh interval Node join, leave, failure ratesM={rs+ rf(log(N))2} + c.log(N) + (k/t)log(N) + (log(N))2/N
#nodes = f(capacity,rates) CPU, memory, bandwidth
Verify by measurement and profiling
24
EvaluationEvaluationreliability and call setup latencyreliability and call setup latency
User availability depends on Super-node failure distribution Node keep-alive and finger refresh rate User registration refresh rate Replicate user registration Measure effect of each
Call setup latency Same as DHT lookup latency: O(log(N))
Calls to known locations (“buddies”) is direct DHT optimization can further reduce latency
User availability and retransmission timers Measure effect of each
25
P2P vs. server-based SIPP2P vs. server-based SIP Prediction:
P2P for smaller & quick setup scenarios
Server-based for corporate and carrier
Need federated system
multiple p2p systems, identified by DNS domain name
with gateway nodes
2000 requests/second ≈7 million registered users
26
Explosive growth (further Explosive growth (further study)study)
Cache replacement at super-nodes Last seen many days ago Cap on local disk usage (automatic)
Forcing a node to become super node Graceful denial of service if
overloaded Switching between flooding, CAN,
Chord, … . . .
27
More open issues (further More open issues (further study)study) Security
Anonymity, encryption Attack/DOS-resistant, SPAM-resistant Malicious node Protecting voicemails from storage nodes
Optimization Locality, proximity, media routing
Deployment SIP-P2P vs P2P-SIP, Intra-net, ISP servers
Motivation Why should I run as super-node?
28
Comparison of P2P and Comparison of P2P and server-based systemsserver-based systems
server-based P2P
scaling server count scales with user count, but limited by supernode count
efficiency most efficient DHT maintenance = O((log N)2)
security trust server provider; binary
trust most supernodes; probabilistic
reliability server redundancy; catastrophic failure possible
unreliable supernodes; catastrophic failure unlikely
29
Catastrophic failureCatastrophic failure Server redundancy is well-understood can
handle single-server failures Catastrophic (system-wide) failure occurs
when common element fails Both server-based and P2P:
all servers crash based on client stimulus (e.g., common parser bug)
Traditional server-based system: servers share same facility, power, OS, …
P2P system less likely share same OS?
30
ConclusionsConclusions P2P useful for VoIP
Scalable, reliable No configuration Not as fast as client/server
P2P-SIP Basic operations easy
Implementation sippeer: C++, Linux
Interoperates Some potential issues
Security Performance
C
C
C
C
C
SP
P
P
P
P
427 763
135
365
123
324
564
364
65a1fc
d13da3
d4213f
d462bad467c4
d471f1
d46a1c
Route(d46a1c)
http://www.cs.columbia.edu/IRT/p2p-sip
http://www.p2psip.org/