An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol
Ai-Chun Pang
Graduate Institute of Networking and Multimedia
Dept. of Comp. Sci. and Info. Engr.
National Taiwan University
What’s Overlay Network
&
What’s P2P ?
What is P2P?
z
Distributed systems
z
Direct sharing of computer resources
z
Without requiring the intermediation or
support of a global centralized server or
authority.
What is Overlay Network?
z
The operation of any peer-to-peer system relies on a network of peer computers
(nodes), and connections (edges) between them.
z
This network is formed on top of –and
independently from—the underlying physical
computer (typically IP) network and is thus
referred to as an “overlay” network.
Overlay Network Architecture (1/3)
z
Purely Decentralized Architectures
z All nodes in the network perform exactly the same tasks, acting both as servers and clients, and there is no central coordination of their activities.
Overlay Network Architecture (2/3)
z
Partially Centralized Architectures
Supernode
Overlay Network Architecture (3/3)
z
Hybrid Decentralized Architectures
Server
Query
Reply
File
Data Trans
mis sion
File
Classification of P2P Applications
z
Communication and Collaboration
z
Distributed Computation
z
Database Systems
z
Content Distribution
z Peer-to-Peer File Exchange Systems
z Napster:Hybrid decentralized.
z KaZaA:Partially centralized.
z Gnutella:Purely decentralized.
Advantages of P2P (1/3)
z
Scalability
z A dramatic increase in the number of nodes or documents will have minimal effect on performance and availability.
Advantages of P2P (2/3)
z
Low Cost
z There is no need to buy more special machines to be
servers. Every computer can be a server and a client at the same time.
Advantages of P2P (3/3)
z
Robustness and Reliability
z It could work without centralized server.
z Increased Network Connectivity
Issues of P2P (1/2)
z
Security
z Integrity and authenticity.
z Privacy and confidentiality.
Voice Voice
Voice
Issues of P2P (2/2)
z
Performance
z The time required for performing the operations allowed by the system, typically routing, searching, and retrieval of documents.
z
Fairness
z Ensuring that users offer and consume resources in a fair and balanced manner.
z Resource Management Capabilities
An Example of
Voice over Overlay Network
Jason
Introduction
z
Skype is a peer-to-peer VoIP client developed by KaZaa in 2003
z
Skype claims that
z It can work almost seamlessly across NATs and firewalls
z It has better voice quality than the MSN and Yahoo IM applications
z
The key Skype functions include
z Login
z NAT and firewall traversal
z Call establishment and teardown
z Media transfer
z Codecs
z Conferencing
Skype Network
z
Any Skype Client (SC) with a public IP address having sufficient CPU, memory,
and network bandwidth is a candidate to become a
super node (SN)
Key Components of Skype Software [1/2]
z Ports
z SC opens a TCP and an UDP listening port
z SC also opens port 80 (HTTP) and port 443 (HTTPS)
z There is no default TCP or UDP listening port
z Host Cache (HC)
z The HC is a list of super node IP:Port pairs
z A SC stores HC in the Windows registry at
HKEY_CURRENT_USER / SOFTWARE / SKYPE / PHONE / LIB / CONNECTION / HOSTCACHE
z HC contains a maximum of 200 entries
z Codecs
z The white paper observes that Skype uses iLBC, iSAC, or a third unknown codec
z Skype codecs allow frequency between 50-8000 Hz to pass through
Key Components of Skype Software [2/2]
z
Buddy List
z Skype stores its buddy information in the Windows registry
z Digitally signed and encrypted
z The buddy list is local to one machine and is not stored on a central server
z
Encryption
z Skype uses AES (Advanced Encryption Standard)
z 256-bit key (1.1x1077 possible keys)
z Skype uses 1536 to 2048 bit RSA to negotiate symmetric AES keys
Experimental Setup
z
Version 0.97.0.6
z Latest version 1.0.0.106
z
Under three different network setups
1) Both Skype users were on machines with public IP address
2) One Skype user was behind port-restricted NAT
3) Both Skype users were behind port-restricted NAT and UDP-restricted firewall
z
Ethereal was used to monitor network traffic
z
NetPeeker was used to tune the bandwidth
Skype Functions
z Startup
z When SC was run for the first time after installation
z sent a HTTP 1.1 GET request (contains the keyword “installed”) to the Skype server
z During subsequent startups
z a SC only sent a HTTP 1.1 GET request to determine if a new version is available
z Login
z User Search
z Call Establishment and Teardown
z Media Transfer and Codec
z Keep-alive Messages
z The SC sent a refresh message to its SN over TCP every 60s
Login
z
Login is perhaps the most critical function to the Skype operation
z
During this process, a SC
z Authenticates its user name and password with the login server
z Advertises its presence to other peers and its buddies
z Determines the type of NAT and firewall it is behind
z Discovers online Skype nodes with public IP addresses
Login Server and Bootstrap Super Nodes
z
Login Server
z The only central component in the Skype network
z IP address: 80.160.91.11
z ns14.inet.tele.dk and ns15.inet.tele.dk
z
Bootstrap Super Nodes
z HC was initialized with 7 IP:Port pairs
z Bootstrap SNs are connected to the Internet through 4 ISPs
z If the HC was flushed after the first login, SC was unable to connect to the Skype Network
First-time Login Process [1/2]
z
There are only 7 entries in the SC host cache upon installation
z
A SC must connect to well known Skype
nodes in order to log on to the Skype Network
z By sending UDP packets to some bootstrap SNs and then wait for their response
z It is not clear how SC selects among bootstrap SNs to send UDP packets to
z SC then established a TCP connection with the bootstrap SN that responded
First-time Login Process [2/2]
z A SC running on a machine with public IP address
z Exchange some packets with SN over TCP
z Then establishes a TCP connection with the login server
z The TCP connection with the SN persisted as long as SN was alive
z The total data is about 9k bytes
z A SC behind a port-restricted NAT
z Roughly the same as for a SC on a public IP address
z The total data is about 10k bytes
z A SC behind a port-restricted NAT and UDP- restricted firewall
z Unable to receive any UDP packets from machines outside the firewall
z It exchanged 8.5k bytes of data
NAT and Firewall Determination
z
The authors conjecture that a SC is able to determine at login if it is behind a NAT and firewall
z By exchanging messages with its SN or some nodes using a variant of the STUN protocol
z
Once determined, the SC stores this information in the Windows registry
z
SC refreshes this information periodically
STUN and TURN
z STUN
z Simple Traversal of UDP through NAT
z Doesn’t work through symmetric NAT
z TURN
z Traversal Using Relay NAT
z Increase latency
z Server load
Login Procedures
z Alternate Node Table
z SC sends UDP packets to about 20 distinct nodes at the end of login process
z To advertise its arrival on the network
z Upon receiving a response from them, SC builds a table of online nodes
z Alternate node table
z It is with these nodes a SC can connect to, if its SN becomes unavailable
z Subsequent Login Process
z Quite similar to the first-time login process
z Login Process Time
z Scenario (1) and (2): 3-7 seconds
z Scenario (3): about 34 seconds
User Search
z Skype uses its Global Index (GI) technology to search for user
z A distributed algorithm
z Guarantee to find a user if it exits and has logged in during the last 72 hours
z For SC on a public IP address
z SC sent a TCP packet to its SN
z SN gave SC the IP:Port of 4 nodes to query
z If it could not find the user, it informed the SN over TCP
z It appears that the SN now asked it to contact 8 different nodes
z This process continued until the SC found the user or it determined that the user did not exist
z The search took 3 to 4 seconds
z Search Result Caching
Call Establishment and Teardown [1/2]
z
The call signaling is always carried over TCP
z
For users that are not in the buddy list
z Call placement = user search + call signaling
z
Both users were on public IP address
z The caller SC established a TCP connection with the callee SC
z
The caller was behind port-restricted NAT and callee was on public IP address
z The caller sent signaling information over TCP to an online Skype node which forwarded it to callee over TCP
z The online node also routed voice packets from caller to callee over UDP and vice versa
Call Establishment and Teardown [2/2]
z
Both users were behind port-restricted NAT and UDP-restricted firewall
z Caller SC sent media over TCP to an online node, which forwarded it to callee SC over TCP and vice versa
z
Advantages of having a node route the voice packets from caller and callee
z It provides a mechanism for users behind NAT and firewall to talk to each other
z If other users want to participate in a conference, this node serves as a mixer
z
Call tear-down
Media Transfer and Codecs [1/2]
z
The total uplink and downlink bandwidth used for voice traffic is 5k bytes/s
z This bandwidth usage corresponds with the Skype claim of 3k-16k bytes/s
z
No silence suppression is supported in Skype
z It maintains the UDP bindings at NAT
z These packets can be used to play some background noise at the peer
z
Skype allows peers to hold a call
z To ensure UDP binding, a SC sends three UDP packets per second to the call peer on average
Media Transfer and Codecs [2/2]
z
Codec Frequency Range
z The min. and max. audible frequency Skype codecs allow to pass through are 50 Hz and 8000 Hz
z
Congestion
z Uplink and downlink bandwidth of 2k bytes/s each was necessary for reasonable call quality
z The voice was almost unintelligible at an uplink and downlink bandwidth of 1.5k bytes/s
Conferencing
z
A acts as a mixer, mixing its own packets with those of B and sending to C and vice versa
z The most powerful machine will be elected as conference host and mixer
z
Two-way call: 36k bytes/s
z
Three-user conference: 54k bytes/s
A(mixer)
B C
B C
A+C A+B