In this article, we discuss the high-level structure of Skype traffic and key network parameters to monitor, so that Network operators can confirm that Skype is working well in a network.   As an aside, for those who have always wondered where the word “Skype” comes from, it originated from the phrase “Sky peer-to-peer” and was abbreviated from there.

Skype Control Protocol

All Skype traffic is encrypted, with the Control protocol part using SSL, therefore, debugging will focus on the TCP performance data that can still be seen for this traffic.  The initial SSL setup can also be examined for smooth and fast handshake setup and first encrypted data received.

Skype Data Protocol

Once the initial handshake has completed, content can be transferred. This (for Audio and video), uses encrypted Real-time Transport Protocol (RTP). Currently, only the content and not the header are encrypted, so RTP statistics are available and will help give a good picture of performance.

Skype Control Traffic

As previously stated, Skype control traffic is based on SSL. Therefore, an analytics solution should focus on the generic layer 4 TCP/IP properties and ideally the SSL handshake. The properties to focus on are:

1. TCP Handshake response time
2. SSL handshake response time
3. Time to first encrypted data response
4. TCP retransmissions during handshakes

Skype Audio / Video traffic

Skype uses the RTP protocol to transfer the audio or video content of a skype session. This enables most analytics solutions to calculate or directly see KPIs such as:

1. The codec in use
2. Throughput, up and down
3. Packetloss
4. Jitter

A packetloss of less than 1% is generally acceptable and still provides good quality. However, only a small increase to 3% or more, is very noticeable and starts to reduce usability. However, even 0% packetloss does not guarantee perfect quality. Changes in latency in the end to end connection can mean Packet Delay Variations can occur causing poor quality. Jitter, as it is often called, is a useful metric to track and Skype includes a ‘Jitter Buffer’, that will re-assemble packets into the correct order, however this will introduce delay in the audio and can only cope with so much jitter.

Microsoft also make general network recommendations:

1. Record network performance over at least a week, to establish a full benchmark of usage variation and peaks seen.
2. Separately assess your internal network and the connectivity to Skype servers.
3. Record network KPIs with high accuracy, ideally continuously.
4. Do not rely on ICMP ping measurements, some Skype infrastructure will not respond.

Packetloss and Jitter can sometimes be caused by Network Congestion (but not always, sometimes issues with Wi-fi or Mobile access can cause loss and jitter without congestion). If a network is congested, it may be possible to use QoS marking to prioritise Skype’s RTP traffic through a network. This is highly recommended, but relies on all network elements respecting QoS marking and prioritisation. So called “DSCP Bleaching” occurs when a device is not configured correctly, strips the DSCP marking and the traffic is no longer prioritised.  Active testing with synthetic traffic is the best way to check for DSCP Bleaching.

An Allegro Packets Network Multimeter is a layer 2 to layer 7 network analytics tool that comes in a wide variety of sizes, from small handheld with GE connectivity to large rack mounted units with 100G links.   Allegro supports TCP and RTP statistics, enable both the control and data traffic to be monitored and recorded. Allegro supports a quick search function, to rapidly find any TCP servers with “Skype” in their name for example.

Monitor critical Skype KPIs over time and discover where the pinch-points are in an end to end connection.

Network Engineers with responsibility for an office network will often be faced with issues that relate to the transport layer. This could be fixed ethernet, or more likely wi-fi.  Whilst a monitoring solution like the Allegro  Packets Network Multimeter can look at L2 to L7, it is often extremely useful to be able to stress test and examine the transport layer with a dedicated tool.  

Analytics like those provided by the Network Multimeter can help find an issue, but for transport related root cause, a different solution is required.  If packetloss is being introduced at the ethernet or wi-fi layer, the best way to find this, is by running active testing.  The Etherscope nXG  supports wired, wireless, GE and 10G testing and can even be used to map wi-fi coverage, to find locations that may be suffering from interference or other issues.

When used in combination with an Allegro Network Multimeter, gives a very reasonably priced, full solution covering almost every possible situation where an error could appear in a network.  

1. Packetloss, latency and jitter are key parameters to measure in an end to end skype connection.
2. Experiencing delayed audio could be an indication of high jitter.
3. Confirming correct QoS performance in a network to prioritise Skype RTP, helps to protect quality during congestion periods.
4. Monitor network parameters long term, both in the local network and the connectivity towards the Skype Edge.
5. Monitor with Allegro Packets Network Multimeter, for real time and historical Skype traffic debugging.
6. Test with netAlly’s Etherscope nXG for a total layer 1 to layer 7 solution, by adding a transport testing capability for fixed and wireless networks.