No abstract

No abstract

Enabling real-time communication over the Internet is of ever increasing importance due to the use of Internet for audio/video communication. The RTCWeb IETF working group has been established with the goal of standardizing a set of protocols for inter-operable real-time communication among Web browsers. In this paper we experimentally evaluate the Google Congestion Control (GCC) which has been recently proposed in the RTCWeb 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.

Real-time communication over the Internet is of ever increasing importance due the diffusion of portable devices, such as smart phones or tablets, with enough processing capacity to support video conferencing applications. The RTCWeb working group has been established with the goal of standardizing a set of protocols for inter-operable real-time communication among Web browsers. In this paper we focus on the Google Congestion Control (GCC), recently proposed in such WG, which is based on a loss-based algorithm run at the sender and a delaybased algorithm executed at the receiver. In a recent work we have shown that a TCP flow can starve a GCC flow. In this work we show that this issue is due to a threshold mechanism employed by the delay-based controller. By carrying out an extensive experimental evaluation in a controlled testbed, we have found that, when the threshold is small, the delay-based algorithm prevails over the loss-based algorithm, which contains queuing delays and losses. However, a small threshold may lead to starvation of the GCC flow when sharing the bottleneck with a loss-based TCP flow.

This paper investigates "Quick UDP Internet Connections" (QUIC), which was proposed by Google in 2012 as a reliable protocol on top of UDP in order to reduce Web Page retrieval time. We first check, through experiments, if QUIC can be safely deployed in the Internet and then we evaluate the Web page load time in comparison with SPDY and HTTP. We have found that QUIC reduces the overall page retrieval time with respect to HTTP in case of a channel without induced random losses and outperforms SPDY in the case of a lossy channel. The FEC module, when enabled, worsens the performance of QUIC.