P2P-SIP Peer to peer Internet telephony using SIP
description
Transcript of P2P-SIP Peer to peer Internet telephony using SIP
P2P-SIPP2P-SIPPeer to peer Internet telephony using Peer to peer Internet telephony using SIPSIP
Kundan Singh and Henning Schulzrinne Columbia University, New York
April 2005http://www.cs.columbia.edu/IRT/p2p-sip
2
AgendaAgenda 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
5
P2P file sharingP2P file sharing
Napster Centralized, sophisticated search
Gnutella Flooding, TTL, unreachable nodes
FastTrack (KaZaA) Heterogeneous peers
Freenet Anonymity, caching, replication
6
P2P goals [re-visited]P2P goals [re-visited]
Query time, number of messages, network usage, per node state
P2P systems
Unstructured Structured
Data availability• Decentralization• Scalability• Load balancing• Fault tolerance
Maintenance• Join/leave• Repair
Efficient searching• Proximity• Locality
• If present => find it• Flooding is not
scalable• Blind search is
inefficient
7
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)
8
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
9
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
10
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
11
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
12
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)
13
What is our P2P-SIP?What is our P2P-SIP? 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
14
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
15
Background: DHT (Chord)Background: DHT (Chord)
Find Map key to node
Join, Leave, or Failure Update the immediate neighbors
Successor and predecessor Stabilize: eventually propagate the
info Reliability
Log(N) successors; data replication
16
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
17
ArchitectureArchitecture
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
18
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
19
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
20
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]
21
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
22
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
23
Dialing Out (message Dialing Out (message routing)routing)
Call, instant message, etc.INVITE sip:[email protected] sip:[email protected]
If existing buddy, use cache first
If not found SIP-based lookup (DNS
NAPTR, SRV,…) P2P lookup
Use DHT to locate: proxy or redirect to next hop
DHT
Last seen
INVITE key=42
302
42
INVITE
24
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
25
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
26
Hybrid architectureHybrid architecture Cross register,
or Locate during
call setup DNS, or P2P-SIP
hierarchy
27
Offline messagesOffline messages INVITE or MESSAGE fails
Responsible node stores voicemail, instant message.
Delivered using MWI or when online detected
Replicate the message at redundant nodes
Sequence number prevents duplicates Security: How to avoid spies? How to recover if all responsible nodes
leave?
28
Conferencing (further Conferencing (further study)study)
One member becomes mixer Centralized conferencing What if mixer leaves?
Fully distributed Many to many signaling and media
Application level multicast Small number of senders
29
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
30
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
31
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, … . . .
32
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?
33
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
Backup slidesBackup slides
35
NapsterNapster Centralized index File names =>
active holder machines Sophisticated search
Easy to implement Ensure correct search
Centralized index Lawsuits Denial of service Can use server farms
P1
P2
P3
P5
P4
S
Where is“quit playing games” ?
P2
FTP
36
GnutellaGnutella Flooding Overlay network Decentralized
Robust Not scalable.
Use TTL. Query can fail
Can not ensure correctness
P
P
P
P
P
P P P P
37
KaZaA (FastTrack)KaZaA (FastTrack) Super-nodes Election:
capacity bandwidth, storage,
CPU and availability
connection time public address
Use heterogeneity of peers
Inherently non-scalable
If flooding is used
P
P
P
P
PP
PP
P
P P P
38
FreeNetFreeNet File is cached on reverse
search path Anonymity
Replication, cache Similar keys on same
node Empirical log(N) lookup TTL limits search Only probabilistic
guarantee Transaction state No remove( )
Use cache replacement
P PP
PP
P
P
1
12
2
3
4
5
67
89
10
11
39
Distributed Hash TablesDistributed Hash Tables Types of search
Central index (Napster) Distributed index with flooding (Gnutella) Distributed index with hashing (Chord)
Basic operationsfind(key), insert(key, value), delete(key), no search(*)
Properties/types Every peer has complete table
Every peer has one key/value
Search time or messages
O(1) O(n)
Join/leave messages
O(n) O(1)
40
CANCANContent Addressable Network Content Addressable Network
Each key maps to one point in the d-dimensional space
Each node responsible for all the keys in its zone.
Divide the space into zones.
A B
C D E
0.0 1.00.0
1.0
A B
C D E
41
CANCANAE
X CB
D
(x,y)
AE
X CB
D
Z
Node X locates (x,y)=(.3,.1)Node Z joins
State = 2d Search = dxn1/d
0.0 .25 .5 .75 1.0
1.0
.75
.5
.25
0.0
42
ChordChord
Identifier circle Keys assigned
to successor Evenly
distributed keys and nodes
1
8
14
21
32
38
58
47
10
2430
54
38
42
0 1 2 3 4 5 6 7 8
43
ChordChord
Finger table: logN ith finger points to first node
that succeeds n by at least 2i-
1
Stabilization after 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
44
TapestryTapestry ID with base B=2b
Route to numerically closest node to the given key
Routing table has O(B) columns. One per digit in node ID.
Similar to CIDR – but suffix-based
427 763
135
365
123
324
564
364
N=2 N=1 N=0
064 ?04 ??0
164 ?14 ??1
264 ?24 ??2
364 ?34 ??3
464 ?44 ??4
564 ?54 ??5
664 ?64 ??6
**4 => *64 => 364
45
PastryPastry Prefix-based Route to node with
shared prefix (with the key) of ID at least one digit more than this node.
Neighbor set, leaf set and routing table.
65a1fc
d13da3
d4213f
d462bad467c4
d471f1
d46a1c
Route(d46a1c)
46
Other schemesOther schemes
Distributed TRIE Viceroy Kademlia SkipGraph Symphony …
47
ComparisonComparison
Property/scheme
Un-structured
CAN Chord Tapestry
Pastry Viceroy
Routing O(N) or no guarantee
d x N1/d log(N) logBN logBN log(N)
State Constant 2d log(N) logBN B.logBN log(N)
Join/leave
Constant 2d (logN)2 logBN logBN log(N)
Reliability and fault resilience
Data at Multiple locations;Retry on failure; finding popular content is efficient
Multiple peers for each data item; retry on failure; multiple paths to destination
Replicate data on consecutive peers; retry on failure
Replicate data on multiple peers; keep multiple paths to each peers
Routing load is evenly distributed among participant lookup servers
48
Server-based vs peer-to-Server-based vs peer-to-peerpeer
Reliability, failover latency
DNS-based. Depends on client retry timeout, DB replication latency, registration refresh interval
DHT self organization and periodic registration refresh. Depends on client timeout, registration refresh interval.
Scalability, number of users
Depends on number of servers in the two stages.
Depends on refresh rate, join/leave rate, uptime
Call setup latency
One or two steps. O(log(N)) steps.
Security TLS, digest authentication, S/MIME
Additionally needs a reputation system, working around spy nodes
Maintenance, configuration
Administrator: DNS, database, middle-box
Automatic: one time bootstrap node addresses
PSTN interoperability
Gateways, TRIP, ENUM Interact with server-based infrastructure or co-locate peer node with the gateway
49
Related work: Skype Related work: Skype From the KaZaA communityFrom the KaZaA community
Host cache of some super nodes Bootstrap IP addresses Auto-detect NAT/firewall settings
STUN and TURN Protocol among super nodes – ?? Allows searching a user (e.g.,
kun*) History of known buddies All communication is encrypted Promote to super node
Based on availability, capacity Conferencing
P
P
P
P
PP
PP
P
P P P
50
Reliability and scalabilityReliability and scalabilityTwo stage architecture for CINEMATwo stage architecture for CINEMA
Master
Slave
Master
Slave
sip:[email protected]:[email protected]
s1
s2
s3
a1
a2
b1
b2
a*@example.com
b*@example.com
example.com_sip._udp SRV 0 40 s1.example.com SRV 0 40 s2.example.com SRV 0 20 s3.example.com SRV 1 0 ex.backup.com
a.example.com_sip._udp SRV 0 0 a1.example.com SRV 1 0 a2.example.com
b.example.com_sip._udp SRV 0 0 b1.example.com SRV 1 0 b2.example.com
Request-rate = f(#stateless, #groups)
Bottleneck: CPU, memory, bandwidth?Failover latency: ?
ex
51
Related workRelated workP2PP2P
P2P networks Unstructured (Kazaa, Gnutella,…) Structured (DHT: Chord, CAN,…)
Skype and related systems Flooding based chat, groove, Magi
P2P-SIP telephony Proprietary: NimX, Peerio, File sharing: SIPShare
52
Why we chose Chord?Why we chose Chord?
Chord can be replaced by another As long as it can map to SIP
High node join/leave rates Provable probabilistic guarantees Easy to implement X proximity based routing X security, malicious nodes
53
Related workRelated workJXTA vs Chord in P2P-SIPJXTA vs Chord in P2P-SIP
JXTA Protocol for communication (peers,
groups, pipes, etc.) Stems from unstructured P2P
P2P-SIP Instead of SIP, JXTA can also be used
Separate search (JXTA) from signaling (SIP)
54
Find(user)Find(user) Option-1: No REGISTER
Node computes key based on user ID
Nodes join the overlay based on ID
One node one user
Option-2: With REGISTER REGISTERs with nodes
responsible for its key Refreshes periodically Allows offline messages (?)
12
24
42 14
32
5812
24
56
42
REGISTER alice=42
REGISTER bob=12
alice=42
sam=24
bob=12
55
P2P-SIPP2P-SIPSecurity – open issues (threats, solutions, issues)Security – open issues (threats, solutions, issues)
More threats than server-based Privacy, confidentiality Malicious node
Don’t forward all calls, log call history (spy),… “free riding”, motivation to become super-node
Existing solutions Focus on file-sharing (non-real time) Centralized components (boot-strap, CA) Assume co-operating peers (
works for server farm in DHT Collusion Hide security algorithm (e.g., yahoo, skype)
Chord Recommendations, design principles, …
56
P2P so far…P2P so far…Applejuice network
Applejuice Client BitTorrent network
ABC Azureus BitAnarch BitComet BitSpirit BitTornado BitTorrent BitTorrent++ BitTorrent.Net G3 Torrent mlMac MLDonkey QTorrent SimpleBT Shareaza TomatoTorrent (Mac OS X)TorrentStorm
CAKE network BirthdayCAKE
Direct Connect network BCDC++ CZDC++ DC++ NeoModus Direct Connect JavaDC DCGUI-QT
Gnutella network Acquisitionx (Mac OS X) BearShare BetBug Cabos CocoGnut (RISC OS)Gnucleus Grokster iMesh Light gtk-gnutella (Unix) LimeWire (Java) MLDonkey mlMac Morpheus Phex Poisoned Swapper Shareaza XoloX
Gnutella2 network Adagio Caribou Gnucleus iMesh Light MLDonkey mlMac Morpheus Shareaza TrustyFiles
HyperCast Joltid PeerEnabler
Altnet Bullguard Joltid Kazaa, Kazaa Lite
eDonkey network aMule (Linux) eDonkey client (no longer
supported) eMule LMule MindGem MLDonkey mlMac Shareaza xMule iMesh Light
ed2k (eDonkey 2000 protocol) eDonkey eMule xMule aMule Shareaza
FastTrack protocol giFT Grokster iMesh, iMesh Light Kazaa , Kazaa Lite, K++, Diet
Kaza, CleanKazaa Mammoth MLDonkey mlMac Poisoned
Freenet network EntropyFreenet Frost
Kademlia protocol eMule MindGem MLDonkey
MANOLITO/MP2P network Blubster Piolet RockItNet
Napster network Napigator OpenNap WinMX
Peercasting type networks PeerCast IceShare Freecast
WPNP network WinMX
other networks Akamai Alpine ANts P2P Ares Galaxy Audiogalaxy network Carracho Chord The Circle Coral[5] Dexter Diet-Agents EarthStation 5 network
Evernet FileTopia GNUnet Grapevine Groove Hotwire iFolder[6] konspire2b Madster/Aimster MUTE Napshare OpenFT Poisoned P-Grid[7]IRC @find XDCCJXTA Peersites [8]MojoNation Mnet Overnet network Scour Scribe Skype SolipsisSongSpy network Soulseek SPIN SpinXpress SquidCam [9]Swarmcast WASTE Warez P2P Winny