('''Skype Congestion Control''')
('''Skype Congestion Control''')
Riga 5: Riga 5:
  
 
=='''Skype Congestion Control'''==
 
=='''Skype Congestion Control'''==
The following contains excerpts of the paper "'''An Experimental Investigation of the Congestion Control Used by Skype VoIP'''" to appear in the proceedings of WWIC 2007 ([http://c3lab.poliba.it/images/d/d2/Skype_wwic07.pdf paper])
+
 
  
 
Skype is the most popular VoIP application with over 250 million userbase spread all over the world. It is important to study how skype reacts to packet losses in order to infer if a huge amount of skype calls can result in a congestion collapse.
 
Skype is the most popular VoIP application with over 250 million userbase spread all over the world. It is important to study how skype reacts to packet losses in order to infer if a huge amount of skype calls can result in a congestion collapse.
  
In the next figures we stress the main issues we have found in our investigation.
+
In the next figures we stress the main issues we have found in our investigation. More can be found in  "'''An Experimental Investigation of the Congestion Control Used by Skype VoIP'''" ([http://c3lab.poliba.it/images/d/d2/Skype_wwic07.pdf paper])
  
 
* '''Skype implements some mechanism to adapt the input rate to the available bandwidth.'''
 
* '''Skype implements some mechanism to adapt the input rate to the available bandwidth.'''

Revisione 18:27, 13 Mar 2007

Congestion Control for Multimedia Applications

The congestion control for multimedia applications (Voice over IP, video on demand) is an open issue. We have evaluated the congestion control strategies employed by leading multimedia applications such as Skype for VoIP applications and RealNetworks video on demand applications. We have found that both applications don't employ an efficient congestion control scheme.

Multimedia application

Skype Congestion Control

Skype is the most popular VoIP application with over 250 million userbase spread all over the world. It is important to study how skype reacts to packet losses in order to infer if a huge amount of skype calls can result in a congestion collapse.

In the next figures we stress the main issues we have found in our investigation. More can be found in "An Experimental Investigation of the Congestion Control Used by Skype VoIP" (paper)

  • Skype implements some mechanism to adapt the input rate to the available bandwidth.
One Skype flow on a square wave form available bandwidth pattern


The figure shows the input rate, the drop rate and the available bandwidth. It can be noticed that Skype adapts its sending rate when the available bandwidth decreases but it takes 40s to match it, thus leading to high packet losses.

  • Skype adapts to the available bandwidth very slowly.

For this reason Skype is not able to cope with sudden bandwidth variations as can be seen in the next figure.

One Skype flow on a square wave form available bandwidth pattern (Higher frequency)
  • Skype is not TCP friendly

As expected the fact that Skype's response to bandwidth variation is sluggish leds to unfriendliness with respect to TCP flows.

One Skype flow versus one TCP flow

As it can be noticed by the figure shown above the TCP connection suffers a large number of timeouts.

  • Skype is not able to guarantee fairness neither

Two Skype calls have been placed flowing in the same bottleneck in order to see if Skype's congestion control is able to guarantee fairness.

Two Skype flows over the same bottleneck

Helix Player Congestion Control (RealPlayer by RealNetworks)

We have evaluated how Helix Player behaves when available bandwidth reductions take place in order to find out how it reacts to congestion episodes. The figure below shows how the throughput of an helix connection experiences up to 30% of packet losses when another helix flow enters the link at 30s and exits at 90s.

Two Helix flows sharing a bottleneck

Congestion Control for Multimedia Applications[edit]

The congestion control for multimedia applications (Voice over IP, video on demand) is an open issue. We have evaluated the congestion control strategies employed by leading multimedia applications such as Skype for VoIP applications and RealNetworks video on demand applications. We have found that both applications don't employ an efficient congestion control scheme.

Multimedia application

Skype Congestion Control[edit]

The following contains excerpts of the paper "An Experimental Investigation of the Congestion Control Used by Skype VoIP" to appear in the proceedings of WWIC 2007 (paper)

Skype is the most popular VoIP application with over 250 million userbase spread all over the world. It is important to study how skype reacts to packet losses in order to infer if a huge amount of skype calls can result in a congestion collapse.

In the next figures we stress the main issues we have found in our investigation.

One Skype flow on a square wave form available bandwidth pattern


The figure shows the input rate, the drop rate and the available bandwidth. It can be noticed that Skype adapts its sending rate when the available bandwidth decreases but it takes 40s to match it, thus leading to high packet losses.

For this reason Skype is not able to cope with sudden bandwidth variations as can be seen in the next figure.

One Skype flow on a square wave form available bandwidth pattern (Higher frequency)

As expected the fact that Skype's response to bandwidth variation is sluggish leds to unfriendliness with respect to TCP flows.

One Skype flow versus one TCP flow

As it can be noticed by the figure shown above the TCP connection suffers a large number of timeouts.

Two Skype calls have been placed flowing in the same bottleneck in order to see if Skype's congestion control is able to guarantee fairness.

Two Skype flows over the same bottleneck

Helix Player Congestion Control (RealPlayer by RealNetworks)[edit]

We have evaluated how Helix Player behaves when available bandwidth reductions take place in order to find out how it reacts to congestion episodes. The figure below shows how the throughput of an helix connection experiences up to 30% of packet losses when another helix flow enters the link at 30s and exits at 90s.

Two Helix flows sharing a bottleneck