Transcript No Slide Title

Peer-to-peer IP telephony
Kundan Singh, Henning Schulzrinne and
Salman Abdul Baset
April 21, 2004
IRT lab - internal talk
Agenda


What is P2P?
How does it apply to IP telephony?
Napster
1999-2001
Napster clones
Academic Research
KaZaA
Gnutella
FreeNet
……
CAN
Chord
Pastry
Tapestry
……
Distributed computing
SETI@home
folding@home
……
Total about
40 slides
2
Key idea
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
Kazaa
C
C
S
C
C
C
P
File sharing
P
P
P
P
SETI@Home
folding@Home
Distributed computing
3
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
4
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
5
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
6
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
7
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
8
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
9
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)
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)
10
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
11
CAN [2]
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
12
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 13 8
Chord [2]
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
14
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
15
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
16
Other schemes






Distributed TRIE
Viceroy
Kademlia
SkipGraph
Symphony
…
17
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
18
P2P for IP telephony
REGISTER
[email protected] =>128.59.19.194
INVITE [email protected]
columbia.edu
128.59.19.194
Alice’s host
128.59.19.194
Bob’s host
P2P overlay
FIND alice
JOIN
128.59.19.194
Alice
128.59.19.194
19
Skype
From the KaZaA community
P
P
P

P
P
P
P

P

P

P
P
P
Host cache of some super nodes
Bootstrap IP addresses
Auto-detect NAT/firewall settings
Protocol among super nodes – ??





Allows searching a user (e.g., kun*)
History of known buddies
All communication is encrypted
Promote to super node


Guaranteed to find if exists and logged in
recently (< 72 hours)
Based on availability, capacity
Conferencing
20
P2P is my
next “killer”
application
Ya right!!
Napster got
killed already!
I am waiting
to be “killer”
21
Lessons learnt


Auto-configure
Adaptive




Client-server, P2P
Search options, state overhead
Node, super node
No blind search, flooding

Use DHT
22
SIPeer
Proposed extension of SIPua/SIPc

Goals






P2P design, but SIP-based
No configuration
Conferencing, offline messaging
Interoperate with existing SIP systems
Inspired by Skype
Use existing DHT schemes

Key=hash(user@domain)
23
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
24
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
25
Node starts up
(1) DNS
sipd

DB

(2) REGISTER
REGISTER with SIP
registrar
Discover peers

[email protected]

(3) Detect peers
First-time bootstrap peers
Detect if multicast is
supported (How?)




Multicast with incremental
TTL
Cache for subsequent
startup
Detect local NAT/firewall
Detect existing “buddies”
26
Node joins

Super-nodes are SIP
registrars

REGISTER
REGISTER sip:node-address
To: <sip:user@domain>

DHT
REGISTER with a Supernode
OPTIONS
Periodically monitor
peers

OPTIONS as heart-beat
message
27
Super-nodes

Initial bootstrap super-nodes


When to become super-node

REGISTER key=42


REGISTER


Local decision; can be influenced by
existing peer
If REGISTER received

DHT
Never allow capacity to exceed
Local key => store locally
Else, forward REGISTER to appropriate
nodes
Super-node refreshes REGISTER on
behalf
Should be in “public” address space (?)
42
28
Node leaves

Graceful leave

REGISTER key=42


REGISTER
42
OPTIONS
DHT
Node leaves: no problem
Super-node leaves



42
Un-REGISTER; what about
server=>client?
Attached nodes detect and
re-REGISTER
New REGISTER goes to new
super-nodes
Super-nodes adjust DHT
accordingly
29
Dialing out

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


42
Send to super-nodes: proxy
Use DHT to locate: proxy or
redirect
30
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?
31
Sophisticated search


*@columbia.edu=38
38
58
14
Interest:movies=29
32
[email protected],
Interest:movies

*@columbia.edu;
keywords
Some super nodes can
act as search servers
Use redirect response to
appropriate nodes when
a query (e.g., INVITE)
is received
Alternative: Hierarchical
design (not pure P2P)
29
32
Conferencing

Conference servers REGISTER all the
conference addresses



Bad – centralized conferencing
Which peer should act as mixer?
Proximity info for application level
multicast

Cascaded mixers
33
NAT/firewall

Super-node tunnels to internal node on
TCP connection initiated by internal node


Use flow control without retransmission, if
possible (?)
Codecs that work best on TCP (?)
34
Mobile nodes


Mobile-IP: no issues
SIP-based mobility



Periodically detect local IP
If it changes, re-REGISTER
If super-node moves, similar to leave+join
35
Embedded devices

Automatically detect available resources





Cap on host cache size
Cap on CPU/memory/bandwidth utilization
Select best codec
Automatically disable p2p if local
domain registrar is found (?)
...
36
Explosive growth

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, …
...
37
Implementation

Implementation



Simulation


No use unless FREE
and used by masses
Not different from existing DHT; on paper
only
Combine

...
38
More open issues

Security





Optimization


Anonymity, encryption,
Attack/DOS-resistant, SPAM-resistant
Malicious version of SIPeer
Protecting voicemails from storage nodes
Locality, proximity
Motivation

Why should I run as super-node?
39
Conclusions
C
C
P
P
C
P
P
S
C



P
C
P2P useful

763
427
d46a1c
364
123
135
564

P2P/SIP
d4213f
324
Route(d46a1c)
365
d471f1
d467c4
d462ba
65a1fc
d13da3
Scalable, reliable
No configuration
Not as fast as client/server


Basic operations easy
Some potential issues



Security
Performance
Quality (audio)
40
Questions, comments
41