(→Congestion Control for Multimedia Applications) |
(→'''Skype Congestion Control''') |
||
| Riga 11: | Riga 11: | ||
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 order to understand how Skype behaves in the presence of congestion we start by considering a step-like time-varying available bandwidth. Considering a step-like input is common practice in control theory when testing the dynamic behaviour of a system [Mas99]. In particular we start by considering square-wave available bandwidths characterized by different periods in order to test not only the Skype capability to match the available bandwidth but also the transient time required for the matching. |
| − | + | Before starting to report our results, it is worth noticing that Skype employs the adaptive codecs iSAC and iLBC both developed by Global IP Sound to provide sending rate adaptation capability. | |
| − | + | === Case 1: One Skype flow over a square form wave available bandwidth === | |
| + | |||
| + | This scenario aims at investigating how Skype sending rate reacts to sudden changes of available bandwidth in order to infer if it employs some sort of congestion control. In order do this, we have used a technique that is often employed in system identification, i.e. we have used an available bandwidth that varies as a square wave with maximum value A_max=160 kb/s and minimum value A_min=16 kb/s. | ||
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.
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.
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 order to understand how Skype behaves in the presence of congestion we start by considering a step-like time-varying available bandwidth. Considering a step-like input is common practice in control theory when testing the dynamic behaviour of a system [Mas99]. In particular we start by considering square-wave available bandwidths characterized by different periods in order to test not only the Skype capability to match the available bandwidth but also the transient time required for the matching.
Before starting to report our results, it is worth noticing that Skype employs the adaptive codecs iSAC and iLBC both developed by Global IP Sound to provide sending rate adaptation capability.
This scenario aims at investigating how Skype sending rate reacts to sudden changes of available bandwidth in order to infer if it employs some sort of congestion control. In order do this, we have used a technique that is often employed in system identification, i.e. we have used an available bandwidth that varies as a square wave with maximum value A_max=160 kb/s and minimum value A_min=16 kb/s.
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.
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.
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.
Towards this end we have evaluated Skype generated flows in a local testbed. We have routed the traffic of two Skype users hosted on the same machine through a virtual machine where "tc" and "netem" have been configured in order to add delays and and to control link capacity (see figure below).
The figure below shows how Skype behaves when the link suffers drops in capacity. We have set up the link capacity to vary between 20 Kbyte/s and 2 Kbyte/s as a square wave with 50% duty cycle and 30s period. The figure clearly shows (see the loss percentage) that Skype is not able to react to link capacity drops leading to very high packet loss rates (up to 80%) when the link capacity is reduced.
