An Experimental Study of the Skype Peer-to-Peer VoIP Skype Peer-to-Peer VoIP System Saikat Guha ... 0.8 0.9 1 10 30 100 300 1k 3k 10k 30k CDF Bandwidth (Bps) ... Discussion For a peer-to-peer

An Experimental Study of theSkype Peer-to-Peer VoIP

System

Saikat Guha (Cornell)

Neil Daswani (Google)

Ravi Jain (Google)

IPTPS 2006

Saikat Guha, Neil Daswani, Ravi Jain Experimental Study of Skype

About Skype

I Voice over IP (VoIP)

I 50 million users

I Valued at $2.6 billion

I Proprietary


About Skype

“Internet Telephony that Just Works”

I Adaptive voice quality

modem, broadband, T1, . . .

I Works in any network topology

one or more NATs, Firewalls, . . .


Outrageous Opinion1 #1

I NAT Traversal in Skype:I Level 0: Initiator NAT’edI Level 1: Recipient NAT’edI Level 2: Both NAT’ed (well-behaved NATs)I Level 3: Both NAT’ed (broken NATs)

Outrageous Opinion

NAT Traversal is essential for P2P

I How to pick NAT Traversal complexity,

and make it scale?1does not, necessarily, reflect the views of all co-authors or employers


NAT Traversal in Skype

Skype SkypeNAT

Level 0: Initiator NAT’ed

Solution: Don’t embed IP address in payloadApps: Most old software, almost all new software



Rendezvous

Skype SkypeNAT

Level 1: Recipient NAT’ed

Solution: Use Rendezvous ServiceApps: Bittorrent, MSN, Yahoo, Skype, . . .



Rendezvous

Skype SkypeNAT NAT

Level 2: Both NAT’ed (well-behaved NATs)

Solution: Use STUN (UDP) or STUNT (TCP)Apps: MSN, Yahoo, Skype, . . .



Rendezvous

Skype SkypeNAT NAT

Level 3: Both NAT’ed (broken NATs)

Solution: Use TURNApps: MSN (limited), Yahoo (limited), Skype



Rendezvous

Skype SkypeNAT NAT

Level 3: Both NAT’ed (broken NATs)

Solution: Use TURN + P2PApps: Skype


Contributions

1. Properties of Skype’s P2PRendezvous-Relay Service

I load (low), structure (yes), churn (low) . . .

2. Skype user behaviorI call-length (long), file-transfer (small), online

activity (predictable) . . .


Skype’s P2P Network

I Inherent structure: [Baset et al. INFOCOM ’06]

I Supernodes (SN): no NAT, spare bandwidth

I Ordinary nodes (ON): associate with one (or

a few) supernodes. Don’t contribute to overlay.

I Skype network: FastTrack (likely)I Experiment: Capture traffic for a SN

I at Cornell, 4.5 months, ∼13GB

I Caveat: everything “encrypted”, only one SNSaikat Guha, Neil Daswani, Ravi Jain Experimental Study of Skype


00.10.20.30.40.50.60.70.80.9

1

30k10k3k1k3001003010

CD

F

Bandwidth (Bps)

Control trafficAll traffic

Relayed traffic

Supernode: Low Network Load

� Bandwidth: 51 Bps (median), 7.5 kBps (median relayed),34 kBps (peak)

� Control traffic (∼75%), Relayed traffic (∼10%)Saikat Guha, Neil Daswani, Ravi Jain Experimental Study of Skype


I Experiment: Estimate no. of active nodes

I Supernodes (SN):I Discover SN: crawl client SN cacheI App-level ping: replay “hello”-packetI 30%–40% of SNs active, 250k foundI Caveat: DHCP assigned SN address

I All Nodes (ON+SN):I Record number of active nodesI .4 million simultaneous usersI Caveat: reported by proprietary client



I Rough estimate: (just network, not CPU)

I ∼1–2 GBps median relay-trafficI .20 well-provisioned boxes at PoPsI ∼ $10 million per year

I Supernodes mostly at universities (EU, Asia, US)

Outrageous Opinion

Skype freeloads on university bandwidth

I Is there an ISP-friendly commercial

model for P2P?Saikat Guha, Neil Daswani, Ravi Jain Experimental Study of Skype


20%

40%

60%

80%

100%

Sun 10/2Sun 9/25Sun 9/18

Fra

ctio

n O

nlin

e

Date (noon UTC)

All NodesSupernodes

24h12h0h

UTC Thu 9/22

-5%

0%

5%

24h12h0h

Sup

erno

de C

hurn

UTC Thu 9/22

JoinsDeparts

Supernodes: Diurnal, Work-week Patterns

� Supernodes: low churn, .5% turnover (over 30-min)



I Handling ChurnI a blood sportI Skype, perhaps intentionally, controls

churn (based on NAT, bandwidth, maybe session history, . . .)

Outrageous Opinion

Churn resistance is overrated. Control churn.

I Is there a price-performance tradeoff

between controlling, and handling

churn?Saikat Guha, Neil Daswani, Ravi Jain Experimental Study of Skype

Skype Users

0.001

0.01

0.1

1

16d8d4d2d1d8h4h2h1h

P[s

essi

on ti

me

> x

]

Supernode Session Time

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

3h1h30m10m3m1m20s

CD

F

Relayed Conversation Duration

Skype users: differ from file-sharing, phone users

� Session Length: heavy-tailed, 5.5h median� File-Transfer: 346kB median� Call-Length: 12m 53s mean, 3h 26m max


Summary

1. Properties of Skype’s P2PRendezvous-Relay Service

I Low Load: NAT traversal, manysupernodes

I Stable: exploits heterogeneityI ISP-unfriendly, taxes universities

2. Skype usersI Different from file-sharing users

(longer session lengths, smaller files transferred)

I Different from phone users (longer calls)

3. Data available on requestSaikat Guha, Neil Daswani, Ravi Jain Experimental Study of Skype

Discussion

For a peer-to-peer application:

I Complexity and scalability of NAT

traversal

I ISP-friendly commercial model

I Tradeoffs between controlling and

handling churn

www.cs.cornell.edu/∼saikat/skype/


www.cs.cornell.edu/~saikat/skype/

Outrageous Opinions2

I NAT Traversal is essential for P2P

I Skype freeloads on university bandwidth

I Churn resistance is overrated. Control

churn.

www.cs.cornell.edu/∼saikat/skype/

2does not, necessarily, reflect the opinion of my co-authors, our employers, or

anyone else.


www.cs.cornell.edu/~saikat/skype/

Supernode Distribution

0%

20%

40%

60%

80%

100%

Sun 10/2Sun 9/25Sun 9/18

Dis

trib

utio

n of

Sup

erno

des

Date (noon UTC)

Europe

North America

Asia

Others

24h18h12h6h0h

UTC Thu 9/22


Filesize Distribution

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

10M3M1M300k100k30k10k3k1k

CD

F

File Size (bytes)

Relayed File Size


An Experimental Study of the Skype Peer-to-Peer VoIP Skype Peer-to-Peer VoIP System Saikat Guha ... 0.8 0.9 1 10 30 100 300 1k 3k 10k 30k CDF Bandwidth (Bps) ... Discussion For a peer-to-peer

Documents