Riga 3: | Riga 3: | ||
The congestion control for multimedia applications (Voice over IP, video on demand) is an open issue. We have investigated the congestion control strategies employed by leading multimedia applications such as the WebRTC framework, currently used by Google Hangouts and Skype for VoIP We have found that both applications do not employ an efficient congestion control scheme. We are designing, implementing and experimenting a congestion control algorithm for real-time traffic over the Web. | The congestion control for multimedia applications (Voice over IP, video on demand) is an open issue. We have investigated the congestion control strategies employed by leading multimedia applications such as the WebRTC framework, currently used by Google Hangouts and Skype for VoIP We have found that both applications do not employ an efficient congestion control scheme. We are designing, implementing and experimenting a congestion control algorithm for real-time traffic over the Web. | ||
[[Immagine:WebRTCArc.jpg|center|''WebRTC Architecture'']] | [[Immagine:WebRTCArc.jpg|center|''WebRTC Architecture'']] | ||
+ | |||
+ | == WebRTC Congestion Control == | ||
+ | Nowadays, the Internet is rapidly evolving to become an equally efficient platform for multimedia content delivery. Key examples are YouTube, Skype Audio/Video, IPTV, P2P video distribution platforms such as Coolstreaming or Joost, to name few. While YouTube streams videos using the Transmission Control Protocol (TCP), applications that are time-sensitive such as Video Conferencing employ the UDP because they can tolerate small loss percentages but not delays due to TCP recovery of losses via retransmissions. Since the UDP does not implement congestion control, these applications must implement those functionalities at the application layer. | ||
+ | In these papers we experimentally evaluate the Google Congestion Control (GCC) which has been proposed in the RMCAT IETF WG. By setting up a controlled testbed, we have evaluated to what extent GCC flows are able to track the available bandwidth, while minimizing queuing delays, and fairly share the bottleneck with other GCC or TCP flows. We have found that the algorithm works as expected when a GCC flow accesses the bottleneck in isolation, whereas it is not able to provide a fair bandwidth utilization when a GCC flow shares the bottleneck with either a GCC or a TCP flow. | ||
+ | |||
+ | <paper authors="L. De Cicco, G. Carlucci, and S. Mascolo" conference="Packet Video Workshop" date="2013" place="San Jose, CA, USA" pdf="Gcc-pv-2013.pdf" slides="gcc-slides-pv2013.pdf"> | ||
+ | Understanding the Dynamic Behaviour of the Google Congestion Control for RTCWeb | ||
+ | </paper> | ||
+ | |||
+ | <paper authors="L. De Cicco, G. Carlucci, and S. Mascolo" conference="ACM SIGCOMM 2013 Workshop on Future Human-Centric Multimedia Networking" place="Hong Kong, China" date="August 2013" pdf="webrtc_cc-Fhcmn2013.pdf"> | ||
+ | Experimental Investigation of the Google Congestion Control for Real-Time Flows</paper> | ||
+ | |||
+ | |||
== Skype Video Congestion Control Responsiveness to Bandwidth Variations == | == Skype Video Congestion Control Responsiveness to Bandwidth Variations == | ||
− | + | This paper investigates Skype Video in order to discover at what extent this application is able to throttle its sending rate to match the unpredictable Internet bandwidth while preserving resource for co-existing best-effort TCP traffic. | |
− | |||
<paper authors="L. De Cicco, S. Mascolo, V. Palmisano" date="May, 2008" pdf="skype-video_nossdav08.pdf" conference="ACM NOSSDAV '08" place="Braunschweig, Germany"> | <paper authors="L. De Cicco, S. Mascolo, V. Palmisano" date="May, 2008" pdf="skype-video_nossdav08.pdf" conference="ACM NOSSDAV '08" place="Braunschweig, Germany"> |
The congestion control for multimedia applications (Voice over IP, video on demand) is an open issue. We have investigated the congestion control strategies employed by leading multimedia applications such as the WebRTC framework, currently used by Google Hangouts and Skype for VoIP We have found that both applications do not employ an efficient congestion control scheme. We are designing, implementing and experimenting a congestion control algorithm for real-time traffic over the Web.
Nowadays, the Internet is rapidly evolving to become an equally efficient platform for multimedia content delivery. Key examples are YouTube, Skype Audio/Video, IPTV, P2P video distribution platforms such as Coolstreaming or Joost, to name few. While YouTube streams videos using the Transmission Control Protocol (TCP), applications that are time-sensitive such as Video Conferencing employ the UDP because they can tolerate small loss percentages but not delays due to TCP recovery of losses via retransmissions. Since the UDP does not implement congestion control, these applications must implement those functionalities at the application layer. In these papers we experimentally evaluate the Google Congestion Control (GCC) which has been proposed in the RMCAT IETF WG. By setting up a controlled testbed, we have evaluated to what extent GCC flows are able to track the available bandwidth, while minimizing queuing delays, and fairly share the bottleneck with other GCC or TCP flows. We have found that the algorithm works as expected when a GCC flow accesses the bottleneck in isolation, whereas it is not able to provide a fair bandwidth utilization when a GCC flow shares the bottleneck with either a GCC or a TCP flow.
This paper investigates Skype Video in order to discover at what extent this application is able to throttle its sending rate to match the unpredictable Internet bandwidth while preserving resource for co-existing best-effort TCP traffic.
Check also a comparison between BEST video application and Skype video over a variable bandwidth. Click on the image to go to the demo.
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 and slides).
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 investigated the end-to-end quality of service (QoS) that is provided by the Apple Darwin Streaming Server and the Quick-Time client player in the presence of time-varying available bandwidth and multiple concurrent streaming sessions.
More can be found in the paper: An Experimental Investigation of the End-to-End QoS of the Apple Darwin Streaming Server (pdf).
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.
This page is mantained by Luca De Cicco, please send feedback to ldecicco at gmail DOT com
The congestion control for multimedia applications (Voice over IP, video on demand) is an open issue. We have investigated the congestion control strategies employed by leading multimedia applications such as the WebRTC framework, currently used by Google Hangouts and Skype for VoIP We have found that both applications do not employ an efficient congestion control scheme. We are designing, implementing and experimenting a congestion control algorithm for real-time traffic over the Web.
Nowadays, the Internet is rapidly evolving to become an equally efficient platform for multimedia content delivery. Key examples are YouTube, Skype Audio/Video, IPTV, P2P video distribution platforms such as Coolstreaming or Joost, to name few. While YouTube streams videos using the Transmission Control Protocol (TCP), applications that are time-sensitive such as Skype VoIP or Video Conferencing employ the UDP because they can tolerate small loss percentages but not delays due to TCP recovery of losses via retransmissions. Since the UDP does not implement congestion control, these applications must implement those functionalities at the application layer. This paper investigates Skype Video in order to discover at what extent this application is able to throttle its sending rate to match the unpredictable Internet bandwidth while preserving resource for co-existing best-effort TCP traffic.
Check also a comparison between BEST video application and Skype video over a variable bandwidth. Click on the image to go to the demo.
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 and slides).
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 investigated the end-to-end quality of service (QoS) that is provided by the Apple Darwin Streaming Server and the Quick-Time client player in the presence of time-varying available bandwidth and multiple concurrent streaming sessions.
More can be found in the paper: An Experimental Investigation of the End-to-End QoS of the Apple Darwin Streaming Server (pdf).
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.
This page is mantained by Luca De Cicco, please send feedback to ldecicco at gmail DOT com