Peertopeer IP telephony

1
Peer-to-peer IP telephony

• Kundan Singh, Henning Schulzrinne and Salman
  Abdul Baset
• April 21, 2004
• IRT lab - internal talk

2
Agenda

• What is P2P?
• How does it apply to IP telephony?

Napster 1999-2001
Napster clones
Academic Research
Distributed computing
CAN Chord Pastry Tapestry
KaZaA Gnutella FreeNet
SETI_at_home folding_at_home
Total about 40 slides
3
Key idea

• Share the resources of individual peers
• CPU, disk, bandwidth, information,

4
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
Napster

• 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
P5
S
P2
P4
P2
Where is quit playing games ?
FTP
P3
6
Gnutella

• 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
7
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
P
P
P
P
P
P
P
P
8
FreeNet

• 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
2
1
P
P
3
12
7
11
4
6
P
10
P
5
P
9
8
P
9
Goals re-visited

• If present find it
• Flooding is not scalable
• Blind search is inefficient

P2P systems
Unstructured
10
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)

11
CANContent 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
E
A
B
12
CAN 2
1.0 .75 .5 .25 0.0
E
E
A
A
C
B
C
B
X
X
Z
D
D
(x,y)
0.0 .25 .5 .75
1.0
Node Z joins
Node X locates (x,y)(.3,.1)
State 2d Search dxn1/d
13
Chord

• Identifier circle
• Keys assigned to successor
• Evenly distributed keys and nodes

1
54
8
58
10
14
47
21
42
38
32
38
24
30
14
Chord 2
1
54
8
58
10
14
47
21

• Finger table logN
• ith finger points to first node that succeeds n
  by at least 2i-1
• Stabilization after join/leave

42
38
32
38
24
30
15
Tapestry

• ID with base B2b
• 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

763
427
364
123
324
365
135
564
4 64 364
16
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
d467c4
d46a1c
d462ba
d4213f
Route(d46a1c)
d13da3
65a1fc
17
Other schemes

• Distributed TRIE
• Viceroy
• Kademlia
• SkipGraph
• Symphony

18
Comparison
19
P2P for IP telephony
REGISTER alice_at_columbia.edu 128.59.19.194
INVITE alice_at_columbia.edu
columbia.edu
128.59.19.194
Alices host 128.59.19.194
Bobs host
20
Skype From the KaZaA community

• Host cache of some super nodes
• Bootstrap IP addresses
• Auto-detect NAT/firewall settings
• Protocol among super nodes ??
• Guaranteed to find if exists and logged in
  recently (
• Allows searching a user (e.g., kun)
• History of known buddies
• All communication is encrypted
• Promote to super node
• Based on availability, capacity
• Conferencing

21
Ya right!! Napster got killed already!
P2P is my next killer application
22
Lessons learnt

• Auto-configure
• Adaptive
• Client-server, P2P
• Search options, state overhead
• Node, super node
• No blind search, flooding
• Use DHT

23
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
• Keyhash(user_at_domain)

24
Find(user)

• Option-2 With REGISTER
• REGISTERs with nodes responsible for its key
• Refreshes periodically
• Allows offline messages (?)

• Option-1 No REGISTER
• Node computes key based on user ID
• Nodes join the overlay based on ID
• One node ? one user

56
REGISTER alice42
58
42
alice42
12
bob12
42
14
12
REGISTER bob12
32
24
24
sam24
25
Design alternatives
servers
1
54
10
38
24
30
clients
Use DHT in server farm
Use DHT for all clients But some are resource
limited

• Use DHT among super-nodes
• Hierarchy
• Dynamically adapt

26
Node starts up

• REGISTER with SIP registrar
• Discover 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

(1) DNS
(2) REGISTER
alice_at_columbia.edu
(3) Detect peers
27
Node joins

• Super-nodes are SIP registrars
• REGISTER with a Super-node
• REGISTER sipnode-address
• To
• Periodically monitor peers
• OPTIONS as heart-beat message

REGISTER
OPTIONS
DHT
28
Super-nodes

• Initial bootstrap super-nodes
• Never allow capacity to exceed
• When to become super-node
• Local decision can be influenced by existing
  peer
• If REGISTER received
• Local key store locally
• Else, forward REGISTER to appropriate nodes
• Super-node refreshes REGISTER on behalf
• Should be in public address space (?)

REGISTER key42
REGISTER
DHT
42
29
Node leaves

• Graceful leave
• Un-REGISTER what about serverclient?
• Node leaves no problem
• Super-node leaves
• Attached nodes detect and re-REGISTER
• New REGISTER goes to new super-nodes
• Super-nodes adjust DHT accordingly

REGISTER key42
REGISTER
OPTIONS
DHT
42
42
30
Dialing out

• Call, instant message, etc.
• INVITE siphgs10_at_columbia.edu
• MESSAGE sipalice_at_yahoo.com
• If existing buddy, use cache first
• If not found
• SIP-based lookup (DNS NAPTR, SRV,)
• P2P lookup
• Send to super-nodes proxy
• Use DHT to locate proxy or redirect

INVITE key42
Last seen
302
INVITE
DHT
42
31
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?

32
Sophisticated search

• _at_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)

33
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

34
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 (?)

35
Mobile nodes

• Mobile-IP no issues
• SIP-based mobility
• Periodically detect local IP
• If it changes, re-REGISTER
• If super-node moves, similar to leavejoin

36
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 (?)
• . . .

37
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,
• . . .

38
Implementation

• Implementation
• No use unless FREE
• and used by masses
• Simulation
• Not different from existing DHT on paper only
• Combine
• . . .

39
More open issues

• Security
• Anonymity, encryption,
• Attack/DOS-resistant, SPAM-resistant
• Malicious version of SIPeer
• Protecting voicemails from storage nodes
• Optimization
• Locality, proximity
• Motivation
• Why should I run as super-node?

40
Conclusions

• P2P useful
• Scalable, reliable
• No configuration
• Not as fast as client/server
• P2P/SIP
• Basic operations easy
• Some potential issues
• Security
• Performance
• Quality (audio)

41
Questions, comments