P2P-SIPP2P-SIPPeer to peer Internet telephony using Peer to peer Internet telephony using SIPSIP

Kundan Singh and Henning Schulzrinne Columbia University, New York

June 2005http://www.cs.columbia.edu/IRT/p2p-sip

2

OverviewOverview 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

Definition fuzzy both client and

server? true for proxy

no need for central server

true for SIP-based media

SIP can be e2e proxy functions

distributed among end systems

5

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)

6

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

7

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

8

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

9

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

10

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)

11

Our P2P-SIP approachOur P2P-SIP approach 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

12

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

13

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

14

Architecture of prototypeArchitecture of prototype

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

15

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

16

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

17

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

18

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

19

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

20

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

21

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

22

Hybrid (federated) Hybrid (federated) architecturearchitecture

Cross register, or

Locate during call setup DNS, or P2P-SIP

hierarchy

23

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

24

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

25

P2P vs. server-based SIPP2P 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

26

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, … . . .

27

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?

28

Comparison of P2P and Comparison of P2P and server-based systemsserver-based 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

29

Catastrophic failureCatastrophic 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:

all servers crash based on client stimulus (e.g., common parser bug)

Traditional server-based system: servers share same facility, power, OS, …

P2P system less likely share same OS?

30

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

http://www.p2psip.org/