Congestion control for Real-Time media communication (Video-conferencing, Voice over IP) over the Internet is currently being addressed in IETF and W3C bodies aiming at standardizing a set of inter-operable protocols and APIs to enable real-time communication between Web browsers. The IETF working group (WG) RTP Media Congestion Avoidance Techniques (RMCAT) has been established in 2012 to propose the standardization of congestion control algorithms using the RTP. We are developing a congestion control algorithm for Web Real-time Communication (WebRTC). The proposed algorithm is used in Google Chrome and Google Hangouts.
Google Faculty Award 2014 for designing a congestion control algorithm for real-time communication within the WebRTC framework to enable video conference among Web browsers.
A description of the algorithm is provided in the IETF RMACT draft.
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.
Our experimental investigation has shown that the first version of GCC gets starved when a TCP flow joins the bottleneck (see Fig. below (a)). Moreover, we have found that starvation also occurs when two coexisting GCC flows share a bottleneck (see Fig. below (b) (c)).
To overcome these issues, we have proposed the adaptive threshold mechanism in the last version of the IETF draft which sets the threshold g(i) used by the over-use detector.
Fig. below shows how rate flows dynamics along with one way delay variations are nicely set after the introduction of the adaptive threshold.
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.
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.
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.