Peer-to-peer IP Peer-to-peer IP telephonytelephony

Kundan Singh, Henning Schulzrinne and Salman Abdul Baset

April 21, 2004IRT lab - internal talk

2

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

Napster1999-2001

KaZaAGnutellaFreeNet

……

Napster clones

CANChordPastry

Tapestry ……

Academic Research

SETI@homefolding@home

……

Distributed computing

Total about 40 slides

3

Key ideaKey idea 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

NapsterGnutellaKazaaFreenet

MagiGrooveSkype

4

GoalsGoals 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

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

6

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

7

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

8

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

9

Goals [re-visited]Goals [re-visited]P2P systems

Unstructured Structured

Data availability• Decentralization• Scalability• Load balancing• Fault tolerance

Maintenance• Join/leave• Repair

Efficient searching• Proximity• Locality

Query time, number of messages, network usage, per node state

• If present => find it• Flooding is not

scalable• Blind search is

inefficient

10

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)

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)

11

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

12

CAN [2]CAN [2]AE

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

13

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

14

Chord [2]Chord [2]

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

15

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

16

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)

17

Other schemesOther schemes

Distributed TRIE Viceroy Kademlia SkipGraph Symphony …

18

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

19

P2P for IP telephonyP2P for IP telephony

Bob’s host Alice’s host128.59.19.194

REGISTERalice@columbia.edu =>128.59.19.194

INVITE alice@columbia.edu

128.59.19.194

columbia.edu

P2P overlay

Alice128.59.19.194

JOINFIND alice

128.59.19.194

20

Skype Skype From the KaZaA communityFrom 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 (< 72 hours)

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

21

P2P is mynext “killer” application

Ya right!!Napster got killed already!

I am waiting to be “killer”

22

Lessons learntLessons learnt

Auto-configure Adaptive

Client-server, P2P Search options, state overhead Node, super node

No blind search, flooding Use DHT

23

SIPeer SIPeer Proposed extension ofProposed extension of SIPua/SIPc 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)

24

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

25

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

26

Node starts upNode 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”

alice@columbia.edu

(1) DNS (2) REGISTER

DB

sipd

(3) Detect peers

27

Node joinsNode joins Super-nodes are SIP

registrars REGISTER with a

Super-nodeREGISTER sip:node-address

To: <sip:user@domain>

Periodically monitor peers OPTIONS as heart-

beat message

DHT

REGISTER

OPTIONS

28

Super-nodesSuper-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 (?)

DHT

REGISTER key=42

REGISTER

42

29

Node leavesNode leaves Graceful leave

Un-REGISTER; what about server=>client?

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

DHT

REGISTER key=42

OPTIONS

42

42

REGISTER

30

Dialing outDialing out 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

Send to super-nodes: proxy Use DHT to locate: proxy or

redirect

DHT

Last seen

INVITE key=42

302

42

INVITE

31

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?

32

Sophisticated searchSophisticated search *@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)

14

32

58

29

38

*@columbia.edu=38

Interest:movies=29

alice@columbia.edu,Interest:movies

33

ConferencingConferencing

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/firewallNAT/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 nodesMobile 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

36

Embedded devicesEmbedded 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 growthExplosive 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

ImplementationImplementation

Implementation No use unless FREE and used by masses

Simulation Not different from existing DHT; on

paper only Combine

. . .

39

More open issuesMore 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

ConclusionsConclusions P2P useful

Scalable, reliable No configuration Not as fast as client/server

P2P/SIP Basic operations easy Some potential issues

Security Performance Quality (audio)

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)

41

Questions, commentsQuestions, comments