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

REGISTERalice@columbia.edu =>128.59.19.194

INVITE alice@columbia.edu

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:alice@128.59.19.194

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:15@192.2.1.3 Unknown node: sip:17@example.com User: sip:alice@columbia.edu

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:11@example.invalid>

From: <sip:7@128.59.15.56>

SIP/2.0 200 OK

To: <sip:11@example.invalid>

Contact: <sip:15@128.59.15.48>; predecessor=sip:10@128.59.15.55

Update my neighbor about meREGISTER

To: <sip:1@128.59.15.60>

Contact: <sip:7@128.59.15.56>; predecessor=sip:1@128.59.15.60

1

10

15

22

Find(11) gives 15

7

20

SIP messagesSIP messages

User registrationREGISTER

To: sip:alice@columbia.edu

Contact: sip:alice@128.59.19.194:8094

Call setup and instant messagingINVITE sip:bob@example.com

To: sip:bob@example.com

From: sip:alice@columbia.edu

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(alice@columbia.edu)

alice@columbia.edu

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:hgs10@columbia.eduMESSAGE sip:alice@yahoo.com

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:bob@example.comsip:bob@b.example.com

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