Luca De Cicco

Feedback control for adaptive live video streaming

Multimedia content feeds an ever increasing fraction of the Internet traffic. Video streaming is one of the most important applications driving this trend. Adaptive video streaming is a relevant advancement with respect to classic progressive download streaming such as the one employed by YouTube. It consists in dynamically adapting the content bitrate in order to provide the maximum Quality of Experience, given the current available bandwidth, while ensuring a continuous reproduction. In this paper we propose a Quality Adaptation Controller (QAC) for live adaptive video streaming designed by employing feedback control theory. An experimental comparison with Akamai adaptive video streaming has been carried out. We have found the following main results: 1) QAC is able to throttle the video quality to match the available bandwidth with a transient of less than 30s while ensuring a continuous video reproduction; 2) QAC fairly shares the available bandwidth both in the cases of a concurrent TCP greedy connection or a concurrent video streaming flow; 3) Akamai underutilizes the available bandwidth due to the conservativeness of its heuristic algorithm; moreover, when abrupt available bandwidth reductions occur, the video reproduction is affected by interruptions.

ELASTIC: A Client-Side Controller for Dynamic Adaptive Streaming over HTTP (DASH)

Today, video distribution platforms use adaptive video streaming to deliver the maximum Quality of Experience to a wide range of devices connected to the Internet through different access networks. Among the techniques employed to implement video adaptivity, the stream-switching over HTTP is getting a wide acceptance due to its deployment and implementation simplicity. Recently it has been shown that the client-side algorithms proposed so far generate an on-off traffic pattern that may lead to unfairness and underutilization when many video flows share a bottleneck. In this paper we propose ELASTIC (fEedback Linearization Adaptive STreamIng Controller), a client-side controller designed using feedback control theory that does not generate an on-off traffic pattern. By employing a controlled testbed, allowing bandwidth capacity and delays to be set, we compare ELASTIC with other client-side controllers proposed in the literature. In particular, we have checked to what extent the considered algorithms are able to: 1) fully utilize the bottleneck, 2) fairly share the bottleneck, 3) obtain a fair share when TCP greedy flows share the bottleneck with video flows. The obtained results show that ELASTIC achieves a very high fairness and is able to get the fair share when coexisting with TCP greedy flows.

An experimental investigation of the Akamai adaptive video streaming

Akamai offers the largest Content Delivery Network (CDN) service in the world. Building upon its CDN, it recently started to offer High Definition (HD) video distribution using HTTP-based adaptive video streaming. In this paper we experimentally investigate the performance of this new Akamai service aiming at measuring how fast the video quality tracks the Internet available bandwidth and to what extent the service is able to ensure continuous video distribution in the presence of abrupt changes of available bandwidth. Moreover, we provide details on the client-server protocol employed by Akamai to implement the quality adaptation algorithm. Main results are: 1) any video is encoded at five different bit rates and each level is stored at the server; 2) the video client computes the available bandwidth and sends a feedback signal to the server that selects the video at the bitrate that matches the available bandwidth; 3) the video bitrate matches the available bandwidth in roughly 150 seconds; 4) a feedback control law is employed to ensure that the player buffer length tracks a desired buffer length; 5) when an abrupt variation of the available bandwidth occurs, the suitable video level is selected after roughly 14 seconds and the video reproduction is affected by short interruptions.

Skype video responsiveness to bandwidth variations

The TCP/IP stack has been extremely successful for reliable delivery of best-effort, time insensitive elastic type data traffic. Nowadays, the Internet is rapidly evolving to become an equally efficient platform for multimedia content delivery. Key examples of this evolution are, to name few, YouTube, Skype Audio/Video, IPTV, P2P video distribution such as Coolstreaming or Joost. 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 in order to avoid congestion and preserve network stability. In this paper we investigate Skype Video in order to discover to 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.

An adaptive video streaming control system: modeling, validation, and performance evaluation

Adaptive video streaming is a relevant advancement with respect to classic progressive download streaming a la YouTube. Among the different approaches, the video stream-switching technique is getting wide acceptance, being adopted by Microsoft, Apple, and popular video streaming services such as Akamai, Netflix, Hulu, Vudu, and Livestream. In this paper, we present a model of the automatic video stream-switching employed by one of these leading video streaming services along with a description of the client-side communication and control protocol. From the control architecture point of view, the automatic adaptation is achieved by means of two interacting control loops having the controllers at the client and the actuators at the server: One loop is the buffer controller, which aims at steering the client playout buffer to a target length by regulating the server sending rate; the other one implements the stream-switching controller and aims at selecting the video level. A detailed validation of the proposed model has been carried out through experimental measurements in an emulated scenario.

Skype Video congestion control

The Internet is facing a significant evolution from being a delivery network for static content to an efficient platform for multimedia content delivery. Well-known examples of applications driving this evolution are YouTube Video on Demand, Skype Audio/Video conference, IPTV and P2P video distribution. While YouTube streams videos using the Transmission Control Protocol (TCP), time-sensitive applications, such as Skype Audio/Video conference, employ the UDP because they can tolerate small loss percentages but not delays due to TCP recovery of lost packets via retransmissions. Since, differently from the TCP, the UDP does not implement congestion control, these applications must implement congestion control at the application layer in order to avoid congestion and preserve network stability. In this paper we investigate Skype Video congestion control in order to assess to 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. We have found that: (1) Skype Video adapts its sending rate by varying frame rate, frame quality and video resolution; (2) in many scenarios a Skype Video call refrains from fully utilizing all available bandwidth thus not sending videos at the highest possible quality; (3) Skype Video employs an adaptive FEC action that is proportional to the experienced loss rate; (4) the sending rate matches a changing available bandwidth with a transient time as large as a hundred of seconds; (5) the minimum bandwidth required for a video call is 40kbps at 5 frames per second.

Experimental investigation of the google congestion control for real-time flows

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.

Impact of TCP congestion control on bufferbloat in cellular networks

The existence of excessively large and too filled network buffers, known as bufferbloat, has recently gained attention as a major performance problem for delay-sensitive applications. One important network scenario where bufferbloat may occur is cellular networks. This paper investigates the interaction between TCP congestion control and buffering in cellular networks. Extensive measurements have been performed in commercial 3G, 3.5G and 4G cellular networks, with a mix of long and short TCP flows using the CUBIC, NewReno and Westwood+ congestion control algorithms. The results show that the completion times of short flows increase significantly when concurrent long flow traffic is introduced. This is caused by increased buffer occupancy from the long flows. In addition, for 3G and 3.5G the completion times are shown to depend significantly on the congestion control algorithms used for the background flows, with CUBIC leading to significantly larger completion times.

An Experimental Investigation of the Congestion Control Used by Skype VoIP

The explosive growth of VoIP traffic poses a potential challenge to the stability of the Internet that, up to now, has been guaranteed by the TCP congestion control. In this paper, we investigate how Skype behaves in the presence of time-varying available bandwidth in order to discover if some sort of congestion control mechanism is implemented at the application layer to match the network available bandwidth and cope with congestion. We have found that Skype flows are somewhat elastic, i.e. they employ some sort of congestion control when sharing the bandwidth with unresponsive flows, but are inelastic in the presence of classic TCP responsive flows, which provokes extreme unfair use of the available bandwidth in this case. Finally, we have found that when more Skype calls are established on the same link, they are not able to adapt their sending rate to correctly match the available bandwidth, which would confirm the risk of network congestion collapse.

Brief paper: Robust stability analysis of Smith predictor-based congestion control algorithms for computer networks

Congestion control is a fundamental building block in packet switching networks such as the Internet due to the fact that communication resources are shared. It has been shown that the plant dynamics is essentially made up of an integrator plus time delay and that a proportional controller plus a Smith predictor defines a simple and effective controller. It has also been shown that the TCP congestion control can be modelled using a Smith predictor plus a proportional controller. Due to the importance of this control structure in the field of data network congestion control, we analyse the robust stability of the closed-loop system in the face of delay uncertainties that are present in data networks due to queuing. In particular, by applying a geometric approach, we derive a bound on the proportional controller gain which is necessary and sufficient to guarantee the closed-loop stability for a given bound on the delay uncertainty.