(→'''Skype Voice over IP Congestion Control''') |
|||
Riga 4: | Riga 4: | ||
[[Immagine:Multimedia-cc.png|right|thumb|400px|''Multimedia application'']] | [[Immagine:Multimedia-cc.png|right|thumb|400px|''Multimedia application'']] | ||
− | == | + | == Skype Voice over IP 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. | 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. | ||
− | Next figures summarize main findings (more can be found in | + | Next figures summarize main findings (more can be found in the paper: "'''An Experimental Investigation of the Congestion Control Used by Skype VoIP'''" [http://c3lab.poliba.it/images/d/d2/Skype_wwic07.pdf pdf]). |
− | + | === Skype implements some mechanism to adapt the input rate to the available bandwidth === | |
[[Immagine:skype_on_off.png|right|thumb|400px|''One Skype flow over a square waveform available bandwidth'']] | [[Immagine:skype_on_off.png|right|thumb|400px|''One Skype flow over a square waveform available bandwidth'']] | ||
− | |||
The figure shows the sending rate, the loss rate and the available bandwidth. It can be noticed that Skype adapts its sending rate when the available bandwidth decreases but this adaptation takes 40s, thus leading to high packet loss rates. | The figure shows the sending rate, the loss rate and the available bandwidth. It can be noticed that Skype adapts its sending rate when the available bandwidth decreases but this adaptation takes 40s, thus leading to high packet loss rates. | ||
− | + | === Skype adapts to the available bandwidth very slowly === | |
For the before mentioned reason Skype is not able to cope with sudden bandwidth variations as it can be seen in the next figure. | For the before mentioned reason Skype is not able to cope with sudden bandwidth variations as it can be seen in the next figure. | ||
Riga 25: | Riga 22: | ||
− | + | === Skype is not TCP friendly === | |
Skype's response to bandwidth variation is sluggish and leads to unfriendliness with respect to TCP flows. | Skype's response to bandwidth variation is sluggish and leads to unfriendliness with respect to TCP flows. | ||
Riga 32: | Riga 29: | ||
The Figure above shows that TCP connection suffers a large number of timeouts. | The Figure above shows that TCP connection suffers a large number of timeouts. | ||
− | + | === Skype is not able to guarantee fairness either === | |
Two Skype calls have been placed flowing in the same bottleneck in order to investigate if Skype's congestion control is able to guarantee fairness. | Two Skype calls have been placed flowing in the same bottleneck in order to investigate if Skype's congestion control is able to guarantee fairness. | ||
Riga 38: | Riga 35: | ||
[[Immagine:skype_vs_skype.png|right|thumb|400px|''Two Skype flows sharing the same bottleneck'']] | [[Immagine:skype_vs_skype.png|right|thumb|400px|''Two Skype flows sharing 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. | 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. | ||
[[Immagine:helix-cc.png|right|thumb|400px|''Two Helix flows sharing a bottleneck'']] | [[Immagine:helix-cc.png|right|thumb|400px|''Two Helix flows sharing a bottleneck'']] |
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.
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.
Next figures summarize main findings (more can be found in the paper: "An Experimental Investigation of the Congestion Control Used by Skype VoIP" pdf).
The figure shows the sending rate, the loss rate and the available bandwidth. It can be noticed that Skype adapts its sending rate when the available bandwidth decreases but this adaptation takes 40s, thus leading to high packet loss rates.
For the before mentioned reason Skype is not able to cope with sudden bandwidth variations as it can be seen in the next figure.
Skype's response to bandwidth variation is sluggish and leads to unfriendliness with respect to TCP flows.
The Figure above shows that TCP connection suffers a large number of timeouts.
Two Skype calls have been placed flowing in the same bottleneck in order to investigate if Skype's congestion control is able to guarantee fairness.
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.
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.
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.
Next figures summarize main findings (more can be found in the paper "An Experimental Investigation of the Congestion Control Used by Skype VoIP" pdf)
The figure shows the sending rate, the loss rate and the available bandwidth. It can be noticed that Skype adapts its sending rate when the available bandwidth decreases but this adaptation takes 40s, thus leading to high packet loss rates.
For the before mentioned reason Skype is not able to cope with sudden bandwidth variations as it can be seen in the next figure.
Skype's response to bandwidth variation is sluggish and leads to unfriendliness with respect to TCP flows.
The Figure above shows that TCP connection suffers a large number of timeouts.
Two Skype calls have been placed flowing in the same bottleneck in order to investigate if Skype's congestion control is able to guarantee fairness.
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.