1. An Experimental Study of the Skype Peer-to-Peer VoIP System
Felipe Santos

2. Roadmap Background Skype Overview NAT Overview STUN Overview
TURN Overview
Performance Evaluation Model
Characterizing Skype (Results)
Related Work
Critique
Summary and Conclusions

3. Background and Motivation
Skype developed by KaZaa in 2003
Recently purchased by eBay for more than $2.6 Billion
Key user and network dynamics difference between Skype and file-sharing P2P services:
File-sharing users are generally patient; long download times are common, and client remains online for long periods of time
Skype users demand fast signaling and call completion, regularly run the client during normal working hours and close it in the evening

4. Skype Overview (1) Offers 3 (4) services:
VoIP (conference call up to 4 users also) IM
File transfer
(Not available in the versions used: video call)
Skype encrypts all user and signaling traffic payloads (AES – Advanced Encryption Standard) – all experiments performed using a “black box” approach
Several conclusions are simply educated guesses

5. Skype Overview (2) Overlay P2P network with 2 node classes:
BASET, S. A., AND SCHULZRINNE, H. An Analysis of the
Skype Peer-to-Peer Internet Telephony Protocol. In
Proceedings of the INFOCOM '06 (Barcelona, Spain, Apr.
2006).
Skype Overview (2)
Overlay P2P network with 2 node classes:
Super nodes (SN) – maintain overlay network amongst themselves
Ordinary nodes (SC) – pick supernodes to get attached to network
Any node with a public IP address having sufficient CPU, memory, and network bandwidth is a candidate to become a super node
No central server except for login server
Login server authenticates users and ensures unique login names across the network
A Skype client (SC) must connect to a SN and register with the login server for a successful login

6. Skype Overview (3) Works almost seamlessly across NATs and Firewalls
It is believed that it uses a variant of STUN/TURN to get around NATs/Firewalls
No dedicated NAT/Firewall traversal server
Each SC build and refreshes a table of reachable SNs called Host Cache (HC)
Skype uses wideband codecs (allows frequencies from 50 to 8000 Hz to pass through) to mainstain reasonable call 32 kbps
No silence suppression supported, which maintains UDP bindings at NAT

7. NAT Overview (1) Network Address Translation
FORD, B., SRISURESH, P., AND KEGEL, D. Peer-to-peer
communication across network address translators. In
Proceedings of the 2005 USENIX Annual Technical
Conference (Anaheim, CA, Apr. 2005).
Network Address Translation
Internet’s original uniform address architecture has been replaced by a global address realm and many private address realms interconnected by NATs
Only addresses in the global ream can be easily accessed from anywhere in the network
NATs allocate temporary public endpoints for outgoing connections, and translate the addresses and port numbers in packets comprising those sessions, while blocking any other traffic, unless otherwise specifically configured
New model suitable for traditional server/client communications. Not good for P2P

8. NAT Overview (2) General methods to traverse NATs Relaying
Connection Reversal
Hole Punching
Peers behind common NAT
Peers behind different NATs
Multiple levels of NAT
FORD, B., SRISURESH, P., AND KEGEL, D. Peer-to-peer
communication across network address translators. In
Proceedings of the 2005 USENIX Annual Technical
Conference (Anaheim, CA, Apr. 2005).

9. NAT Overview (3) Consider 3 types of NATs: Full Cone
All Requests from the same internal IP address and port # are always mapped to the same external IP address and port # (generally different)
Any external host can send a packet to the internal host by sending a packet to the mapped external address
Restricted Cone (same as Full Cone, except)
An external host (IP address X) can only send a packet to an internal host if the same has previously sent a packet to the external host at IP X
Port Restricted Cone (same as Restricted Cone, except)
An external host (IP address X port # Y) can only send a packet to an internal host if the same has previously sent a packet to the external host at IP X and port # Y
Symmetric
Packets from an internal host addressed to a specific external host are mapped to the same external IP address and port #. If the internal node sends packets to another external host, a different mapping is used

10. STUN Overview (1)
Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
Allows entities behind a NAT to first discover the presence of a NAT, and then learn the address bindings allocated by the NAT
General Topology
STUN server
STUN client – usually embedded in an application
2 types of requests:
Binding requests – server examines the source IP and port of the request and copies them into a Binding response that is sent back to the client.
Shared Secret requests – asks the server to return a temporary username and password used to authenticate subsequent binding requests and binding responses

11. STUN Overview (2)
Test I – Client sends binding request to a server without any flags set (server simply sends the response back to the address and port # where the request came from)
Test II – client sends binding request with both the change IP and change port flags set (server replies to specified IP and port #)
Test III – Client sends binding request to a server with only the change port flag set (server replies to the same IP address, specified port #)
*Test I performed again but to the IP and port from the CHANGED-ADDRESS attribute from the response to the original test I

12. TURN Overview (1) Traversal Using Relay NAT
Allows entities behind a NAT or firewall to receive incoming data over TCP or UDP connections
General Topology
TURN server – resides on the public Internet; receives TURN requests and sends responses; acts as relay server
TURN client – generates TURN requests
Identical in syntax and general operation to STUN
Should be only used as a last resort

13. TURN Overview (2)
UDP Operation (after authentication and TURN connection setup):
Client sends a TURN SEND command to the server, containing a data packet and a destination IP address and port #
Server forwards the data packet to the specified IP and port # and sets a permission that generates a default routing of any non-TURN packets from this client to the same destination (reduces overhead)
TCP Operation (after authentication and connection setup):
Client issues a TURN SEND command
For TCP server does not need to examine the data received, it merely forwards all data between the associated socket pairs (in UDP server checks first 128 bytes of each UDP packet for a magic cockie, which indicates the packet is a TURN control packet)

14. Performance Evaluation Model
Experiment 1: Basic Operation
Part 1
Part 2
Part 3

15. Performance Evaluation Model
Experiment 2: Promotion to Supernode

16. Performance Evaluation Model
Experiment 3: Supernode Network Activity

17. Performance Evaluation Model
Experiment 4: Supernode and client population
Host Cache (HC) Capture Script – parses the Skype client HC, adds the address in the HC to a list, replaces the HC with a single supernode entry, restarts the Skype client (now forced to download a fresh list of hosts), waits for new host list, kills the client, which causes it to flush the list to disk, this list is then processed, and the whole process is repeated

18. Performance Evaluation Model
Experiment 5: Supernode Presence
Gathered snapshots of online supernodes at a given time
Used a tool that sends application level pings to supernodes
Tool replays the first packet sent by a Skype client to a supernode in its cache and waits for the expected response
For each snapshot (takes about 4 minutes to execute) parallel pings are performed to 6000 supernodes randomly selected from the list acquired from experiment 4
Snapshots were taken every 30 minutes from Sep. 12th, 2005 to Oct. 12th, 2005

19. Results (1) Experiment 1: Basic Operation
Part 1 - Ordinary nodes send control traffic including availability information, IMs, and requests for VoIP and file-transfer sessions over the supernode overlay network
Part 2 - If only one user is behind a NAT, Skype uses a connection reversal method whereas the node behind the NAT always initiates the session regardless of which peer initiated the VoIP or file transfer
Part 3 – If both users are behind NATs, Skype uses STUN-like NAT traversal; if STUN fails or a firewall blocks UDP packets, Skype falls back to a TURN-like relay approach
Experiment 2: Promotion to Supernode
Several Skype clients were run in various environments (2 weeks)
Node behind a saturated network uplink and another one behind a NAT did not get promoted to supernode status
A fresh install on a public host with a 10 Mbps connection to the Internet was promoted within minutes
Skype supernodes are chosen from nodes that have plenty of spare bandwidth and are publicly reachable, which contributes to the overall stability of the system.

20. Results (2) Experiment 3: Supernode Network Activity
Used Ethereal to capture 13 GB worth of supernode-related traffic over 135 days (Sep. 1st, 2005 thru Jan. 14th, 2006)
Captured data included relayed VoIP and file-transfer sessions
Experiment 4: Supernode and Client Population
The crawl of the Skype hosts described earlier yielded to the discovery of supernode addresses and of these were “crawlable”
Experiment 5: Supernode Presence
Data acquired in all experiments was further analyzed to generate an overall characterization of the Skype network as described next

21. Results (3) Characterizing Skype’s Network
Definitions:
Churn – continuous process of nodes joining and leaving the system, which increases routing latency as traffic is routed through failed nodes while new nodes are not taken advantage of
Session time – time interval between a node joining the network and then subsequently leaving
There is very little churn in the supernode network demonstrating diurnal behavior with median session times of several hours
Session lengths are heavy-tailed and not exponentially distributed
Number of supernodes is more stable than the number of regular nodes

22. Results (4) Characterizing Skype’s Network
There are large diurnal variations with peak usage during normal working hours and significantly reduced usage (40-50%) at night
Node arrivals concentrated towards the morning and departures towards the evening
Node arrivals and departures cannot be modeled directly as a Poisson on uniform process, but rather as Poisson process with varying hourly rate
20% utilization during weekends
Europe accounts for 45-60% of supernodes
North America contributes 15-25%
Asia 20-25%

23. Results (5) Bandwidth Consumption
Skype uses spare network and computing resources of hundreds of thousands of supernodes, and little additional infrastructure
There is a small cost for participating in the supernode network
Skype does not use silence suppression; it maintains a constant 33 packets per second rate for all VoIP connections. Silence suppression could reduce client and supernode (when relaying) bandwidth consumption, but on the other hand there could be problems with NAT timeouts

24. Related Work
BASET, S. A., AND SCHULZRINNE, H. An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. In Proceedings of the INFOCOM '06 (Barcelona, Spain, Apr.2006).
BHAGWAN, R., SAVAGE, S., AND VOELKER, G. M. Understanding availability. In Proceedings of the IPTPS '03 (Berkeley, CA, Feb. 2003).
FORD, B., SRISURESH, P., AND KEGEL, D. Peer-to-peer communication across network address translators. In Proceedings of the 2005 USENIX Annual Technical Conference (Anaheim, CA, Apr. 2005)
ROSENBERG, J., MAHY, R., AND HUITEMA, C. Internet draft: TURN . Traversal Using Relay NAT, Mar Work in progress.
ROSENBERG, J., WEINBERGER, J., HUITEMA, C., AND MAHY, R. RFC 3489: STUN . Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), Mar

25. Critique
Outdated version of Skype – no video traffic taken into account
The work assumes that supernodes that did not respond to the pings were offline; there are other reasons such as a software firewall that is not detected by Skype that prevents this supernode from responding to the ping requests

26. Summary and Conclusions
Skype is a unique P2P VoIP system
All traffic is encrypted, which makes the analysis of the traffic difficult
Skype is virtually NAT and Firewall proof by employing variations of STUN and TURN
Skype also demonstrates a very peculiar traffic/client pattern