Transcript P2P-SIP Peer to peer Internet telephony using SIP

P2P-SIP
Peer to peer Internet telephony using SIP
Kundan Singh and Henning Schulzrinne
Columbia University, New York
May 2005
http://www.cs.columbia.edu/IRT/p2p-sip
Agenda

Introduction


Architecture


SIP using P2P vs P2P over SIP; Components
that can be P2P
Implementation


What is P2P? and SIP? Why P2P-SIP?
Choice of P2P (DHT); Node join, leave;
message routing
Conclusions and future work
Total 33 slides
2
What is P2P?
Computer systems
Centralized

Distributed

mainframes
workstations
Client-server
Flat
Hierarchical
RPC
HTTP
DNS
mount
Share the resources of
individual peers
Peer-to-peer
Pure
Hybrid
Gnutella
Chord
Napster
Groove
CPU, disk, bandwidth,
information, …
Communication and collaboration
Magi
Groove
Skype
Napster
Gnutella
Kazaa
Freenet
Overnet
Kazaa
C
C
S
C
C
C
P
P
P
P
P
File sharing
SETI@Home
folding@Home
Distributed computing
3
P2P 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?


no need for central
server



true for proxy
true for SIP-based
media
SIP can be e2e
proxy functions
distributed among
end systems
4
P2P file sharing

Napster


Gnutella


Flooding, TTL, unreachable nodes
FastTrack (KaZaA)


Centralized, sophisticated search
Heterogeneous peers
Freenet

Anonymity, caching, replication
5
P2P goals [re-visited]
•
•
•
If present => find it
Flooding is not scalable
Blind search is inefficient
P2P systems
Unstructured
Data availability
•
Decentralization
•
Scalability
•
Load balancing
•
Fault tolerance

Structured
Maintenance
•
Join/leave
•
Repair
Efficient searching
•
Proximity
•
Locality
Query time, number of messages, network usage,
per node state
6
Distributed Hash Table (DHT)

Types of search




Central index (Napster)
Distributed index with flooding (Gnutella)
Distributed index with hashing (Chord)
Basic operations
find(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)
O(log(N)2)
O(1)
Join/leave messages O(n)
7
Why P2P-SIP?
REGISTER
[email protected] =>128.59.19.194
INVITE [email protected]
Contact: 128.59.19.194
Alice’s host
128.59.19.194
columbia.edu
Bob’s host
Client-server=> maintenance, configuration, controlled infrastructure
INVITE alice
P2P overlay
128.59.19.194
REGISTER
Alice
128.59.19.194
No central server, search latency
8
How to combine SIP + P2P?

SIP-using-P2P


Replace SIP location
service by a P2P
protocol
P2P-over-SIP

Additionally,
implement P2P using
SIP messaging
P2P network
FIND
INSERT
INVITE sip:[email protected]
INVITE alice
REGISTER
P2P-SIP
overlay
Alice
128.59.19.194
Alice
128.59.19.194
9
SIP-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
10
P2P-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
11
What else can be P2P?






Rendezvous/signaling
Configuration storage
Media storage
Identity assertion (?)
Gateway (?)
NAT/media relay (find best one)
12
What is our P2P-SIP?


Unlike server-based SIP architecture
Unlike proprietary Skype architecture


Robust and efficient lookup using DHT
Interoperability


Hybrid architecture


Lookup in SIP+P2P
Unlike file-sharing applications


DHT algorithm uses SIP communication
Data storage, caching, delay, reliability
Disadvantages

Lookup delay and security
13
Background: DHT (Chord)
1
54
8
58
10
14
47
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



ith finger points
to first node that
succeeds n by at
least 2i-1

Stabilization for
join/leave

21
42
Identifier circle
Keys assigned to
successor
Evenly distributed
keys and nodes
Finger table: logN

38
32
38
24
30
0
1
2
3
4
5
6
7
8
14
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
15
Design Alternatives
1
54
58
servers
47
42
38
38
8
d471f1
14 10
d46a1c
21
d467c4
d462ba
1
54
d4213f
10
32
24 30
Route(d46a1c)
d13da3
65a1fc
38
24 30
clients
Use DHT in
server farm
Use DHT for all
clients; But some
are resource limited
Use DHT among super-nodes
1.
2.
Hierarchy
Dynamically adapt
16
Architecture
User interface (buddy list, etc.)
On reset Signout,
transfer
On startup
Leave
Discover
Peer found/
Detect NAT
ICE
Signup,
Find buddies
IM,
call
User location
Find
Join
DHT (Chord)
Multicast REGISTER
REGISTER
Audio devices
REGISTER,
INVITE,
MESSAGE
SIP
Codecs
RTP/RTCP
SIP-over-P2P
P2P-using-SIP
17
Naming and authentication

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
18
SIP messages

1
DHT (Chord) maintenance

Query the node at distance 2k with node id 11
REGISTER
To: <sip:[email protected]>
From: <sip:[email protected]>
10
22
7
15
Find(11) gives 15
SIP/2.0 200 OK
To: <sip:[email protected]>
Contact: <sip:[email protected]>; predecessor=sip:[email protected]

Update my neighbor about me
REGISTER
To: <sip:[email protected]>
Contact: <sip:[email protected]>; predecessor=sip:[email protected]
19
SIP messages

User registration
REGISTER
To: sip:[email protected]
Contact: sip:[email protected]:8094

Call setup and instant messaging
INVITE sip:[email protected]
To: sip:[email protected]
From: sip:[email protected]
20
Node Startup
columbia.edu
sipd

REGISTER
SIP

DB

[email protected]
DHT

Detect peers
Discover peers: multicast REGISTER


58

12

14

REGISTER bob=12
SLP, bootstrap, host cache
Join DHT using node-key=Hash(ip)

REGISTER alice=42
42
REGISTER with SIP registrar
Query its position in DHT
Update its neighbors
Stabilization: repeat periodically
User registers using userkey=Hash([email protected])
32
21
Node Leaves

Chord reliability

REGISTER key=42

Graceful leave

REGISTER

42
OPTIONS
DHT

Un-REGISTER
Transfer registrations
Failure

42
Log(N) successors, replicate
keys


Attached nodes detect and
re-REGISTER
New REGISTER goes to new
super-nodes
Super-nodes adjust DHT
accordingly
22
Dialing Out (message routing)

INVITE sip:[email protected]
MESSAGE sip:[email protected]
INVITE key=42
302
Last seen
Call, instant message, etc.

INVITE

If existing buddy, use cache
first
If not found

DHT

SIP-based lookup (DNS
NAPTR, SRV,…)
P2P lookup

Use DHT to locate: proxy or
redirect to next hop
42
23
Implementation
31
29
1

31
30
sippeer: C++,
Unix (Linux), Chord

25
26
26

9

19
11
Node join and form
the DHT
Node failure is
detected and DHT
updated
Registrations
transferred on node
shutdown
15
24
Adaptor for existing phones


Use P2P-SIP
node as an
outbound proxy
ICE for
NAT/firewall
traversal

STUN/TURN
server in the
node
25
Hybrid architecture


Cross register, or
Locate during call
setup


DNS, or
P2P-SIP hierarchy
26
Offline 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?
27
Conferencing (further study)

One member becomes mixer



Fully distributed


Centralized conferencing
What if mixer leaves?
Many to many signaling and media
Application level multicast

Small number of senders
28
Evaluation
scalability

#messages depends on




Keep-alive and finger table refresh rate
Call arrival distribution
User registration refresh interval
Node join, leave, failure rates
M={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
29
Evaluation
reliability 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
30
P2P 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
31
Explosive growth (further 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 study)

Security





Optimization


Locality, proximity, media routing
Deployment


Anonymity, encryption
Attack/DOS-resistant, SPAM-resistant
Malicious node
Protecting voicemails from storage nodes
SIP-P2P vs P2P-SIP, Intra-net, ISP servers
Motivation

Why should I run as super-node?
33
Comparison of P2P and serverbased 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
34
Catastrophic 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:


Traditional server-based system:


all servers crash based on client stimulus (e.g., common
parser bug)
servers share same facility, power, OS, …
P2P system


less likely
share same OS?
35
Conclusions
C
C
S
C
C
P
P
P
P

763
d46a1c
364
Route(d46a1c)
365
d471f1
d467c4
d462ba
d4213f
324
135

P
123
P2P useful for VoIP

C
427


Scalable, reliable
No configuration
Not as fast as client/server
P2P-SIP

Basic operations easy

d13da3
65a1fc
Implementation

564


sippeer: C++, Linux
Interoperates
Some potential issues


Security
Performance
http://www.cs.columbia.edu/IRT/p2p-sip
36
Backup slides
Napster
P1
P5


S
P2
P2
P4

Where is
“quit playing games” ?
Centralized index
File names =>
active holder machines
Sophisticated search

FTP

P3

Easy to implement
Ensure correct search
Centralized index



Lawsuits
Denial of service
Can use server farms
38
Gnutella
P
P
P
P
P
P



P
P
Flooding
Overlay network
Decentralized


P
Not scalable.


Robust
Use TTL. Query can
fail
Can not ensure
correctness
39
KaZaA (FastTrack)

P
P
P
P

P
P
Super-nodes
Election:

capacity

P

P
and availability

P


P
P
P

bandwidth, storage,
CPU
connection time
public address
Use heterogeneity of
peers
Inherently non-scalable

If flooding is used
40
FreeNet

2
1
P
P
12
P

3
File is cached on reverse
search path
Anonymity

7
4
6
11

10
P
5
8
P
9
P



P


Replication, cache
Similar keys on same node
Empirical log(N) lookup
TTL limits search
Only probabilistic
guarantee
Transaction state
No remove( )

Use cache replacement
41
Distributed Hash Tables

Types of search




Central index (Napster)
Distributed index with flooding (Gnutella)
Distributed index with hashing (Chord)
Basic operations
find(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)
42
CAN
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.
1.0
C
D
E
B
A
0.0
1.0
0.0
C
D
A
B
E
43
CAN
1.0
E
A
B
X
E
A
B
X Z
.75
C
C
.5
D
D
.25
(x,y)
0.0
0.0
.25
.5
.75
1.0
Node X locates (x,y)=(.3,.1)
Node Z joins
State = 2d
Search = dxn1/d
44
Chord

1
54
8
58

10
14

47
21
42
Identifier circle
Keys assigned to
successor
Evenly
distributed keys
and nodes
38
32
38
24
30
0
1
2
3
4
5
6
7 45 8
Chord
1
54
8
58
10
14
47
21

42

38
32
38

24
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
Finger table: logN
ith finger points to first node that
succeeds n by at least 2i-1
Stabilization after join/leave
30
46
Tapestry
763
427


364
123
324
365
135
564
**4 => *64 => 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

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
47
Pastry



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.
d471f1
d46a1c
d467c4
d462ba
d4213f
Route(d46a1c)
d13da3
65a1fc
48
Other schemes






Distributed TRIE
Viceroy
Kademlia
SkipGraph
Symphony
…
49
Comparison
Property/
scheme
Unstructured
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
50
Server-based vs peer-to-peer
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
51
Related work: Skype
From the KaZaA community
P
P
P

P
P
P
P

P

P
Host cache of some super nodes
Bootstrap IP addresses
Auto-detect NAT/firewall settings

P
P
P





Protocol among super nodes – ??
Allows searching a user (e.g., kun*)
History of known buddies
All communication is encrypted
Promote to super node


STUN and TURN
Based on availability, capacity
Conferencing
52
Reliability and scalability
Two stage architecture for CINEMA
a*@example.com
a1
s1
Master
a2
a.example.com
_sip._udp
SRV 0 0 a1.example.com
SRV 1 0 a2.example.com
Slave
sip:[email protected]
s2
sip:[email protected]
b*@example.com
s3
ex
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
b1
Master
b2
Slave
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?
53
Failover latency: ?
Related work
P2P

P2P networks



Skype and related systems


Unstructured (Kazaa, Gnutella,…)
Structured (DHT: Chord, CAN,…)
Flooding based chat, groove, Magi
P2P-SIP telephony


Proprietary: NimX, Peerio,
File sharing: SIPShare
54
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
55
Related work
JXTA 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)
56
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 (?)
56
42
alice=42
42
12
REGISTER alice=42
58
12
bob=12
14
REGISTER bob=12
32
24
sam=24
24
57
P2P-SIP
Security – open issues (threats, solutions, issues)

More threats than server-based


Privacy, confidentiality
Malicious node



“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 (




Don’t forward all calls, log call history (spy),…
works for server farm in DHT
Collusion
Hide security algorithm (e.g., yahoo, skype)
Chord

Recommendations, design principles, …
58
P2P so far…
Kademlia protocol
eMule
Applejuice Client
Acquisitionx (Mac OS X)
MindGem
aMule
(Linux)
BitTorrent network
BearShare
eDonkey client (no longer
MLDonkey
ABC
BetBug
supported)
Azureus
MANOLITO/MP2P
network
Cabos
eMule
BitAnarch
Blubster
CocoGnut (RISC OS)
BitComet
LMule
Piolet
Gnucleus
BitSpirit
MindGem
Grokster
RockItNet
BitTornado
MLDonkey
iMesh Light
Napster network
BitTorrent
mlMac
gtk-gnutella (Unix)
Napigator
BitTorrent++
Shareaza
LimeWire (Java)
OpenNap
BitTorrent.Net
MLDonkey
xMule
WinMX
G3 Torrent
mlMac
iMesh Light
Peercasting
type networks
mlMac
Morpheus
ed2k
(eDonkey
2000
protocol)
MLDonkey
PeerCast
Phex
eDonkey
QTorrent
IceShare
Poisoned
eMule
SimpleBT
Freecast
Swapper
xMule
Shareaza
Shareaza
WPNP network
aMule
TomatoTorrent (Mac OS X)
XoloX
WinMX
Shareaza
TorrentStorm
Gnutella2
network
other
networks
FastTrack protocol
CAKE network
Adagio
Akamai
giFT
BirthdayCAKE
Caribou
Grokster
Alpine
Direct Connect network
Gnucleus
iMesh, iMesh Light
ANts P2P
BCDC++
iMesh Light
Kazaa , Kazaa Lite, K++, Diet
Ares Galaxy
CZDC++
MLDonkey
Kaza, CleanKazaa
Audiogalaxy network
DC++
mlMac
Mammoth
NeoModus Direct Connect
Carracho
Morpheus
MLDonkey
JavaDC
Chord
Shareaza
mlMac
DCGUI-QT
TrustyFiles
The Circle
Poisoned
HyperCast
Coral[5]
Freenet network
Joltid PeerEnabler
Entropy
Dexter
Freenet
Altnet
Diet-Agents
Frost
Bullguard
EarthStation 5 network
Applejuice network
eDonkey network
Gnutella network
Joltid
Kazaa, Kazaa Lite
Evernet
FileTopia
GNUnet
Grapevine
Groove
Hotwire
iFolder[6]
konspire2b
Madster/Aimster
MUTE
Napshare
OpenFT
Poisoned
P-Grid[7]
IRC @find XDCC
JXTA
Peersites [8]
MojoNation
Mnet
Overnet network
Scour
Scribe
Skype
Solipsis
SongSpy network
Soulseek
SPIN
SpinXpress
SquidCam [9]
Swarmcast
WASTE
Warez P2P 59
Winny