A Dynamic Approach to Estimate Receiving Bandwidth for WebRTC

A Dynamic Approach to Estimate Receiving Bandwidth for WebRTC

Razib Iqbal (Missouri State University, Springfield, MO, USA), Shervin Shirmohammadi (University of Ottawa, Ottawa, Canada) and Rasha Atwah (King Abdulaziz University, Jeddah, Saudi Arabia)
DOI: 10.4018/IJMDEM.2016070102
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Web Real-Time Communication (WebRTC), drafted by the World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF), enables direct browser-to-browser real-time communication. As its congestion control mechanism, WebRTC uses the Google Congestion Control (GCC) algorithm. But using GCC will limit WebRTC's performance in cases of overusing due to using a fixed decreasing factor, known as alpha (a). In this paper, the authors propose a dynamic alpha model to reduce the receiving bandwidth estimate during overuse as indicated by the overuse detector. Using their proposed model, the receiver can more efficiently estimate its receiving rate in case of overuse. They implemented their model over both unconstrained and constrained networks. Experimental results show noticeable improvements in terms of higher incoming rate, lower Round-Trip Time, and lower packet loss compared to the fixed alpha model.
Article Preview

Introduction

Popularity of mobile technologies such as smartphones and tablets has encouraged competition amongst the video conferencing system researchers and developers to enhance the Real-Time Communication (RTC) technology as well as to implement various applications based on RTC. Accessibility and mobility of multimedia and video conferencing applications has also motivated the creation of browser-to-browser video conferencing technologies that can compete with the current standalone video conferencing applications (Alonso, Geiger, & Jorda, 2004; Xu et al., 2012). In 2012, Web Real-Time Communication (WebRTC) was proposed with the aim to implement RTC into web browsers, enabling audiovisual calls between two or more end users with no need to install third party plug-ins or specific applications. Real-Time Communication on the Web (RTCWeb) is an open source project of the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C) team that aims to standardize protocols and infrastructures for WebRTC (2016). Web developers can add WebRTC features to their browsers using standard Hyper Text Markup Language (HTML5) with simple Javascript APIs (Johnston & Burnett, 2014). Therefore, it allows any web browser running on any operating system and any device to connect seamlessly with any other web browser running on any operating system and any device via the internet and communicate in real-time, as long as both web browsers support WebRTC. WebRTC is open source, and it is currently implemented in three browsers: Google Chrome, Firefox, and Opera (WebRTC, 2016).

Like any other RTC application, WebRTC has to deal with the quality from two different perspectives – user and network. From the user’s perspective, services such audio-video streams have to be provided with less packet loss and delays, along with a high incoming rate and quality. From the network perspective, WebRTC has to have a mechanism that can deal with bottleneck problems and congestion to produce acceptable performance during a video session. Therefore, the IETF and W3C working groups proposed a congestion control mechanism, called Google Congestion Control (GCC) algorithm, for WebRTC to satisfy the quality requirements for real-time applications (Lundin et al. 2015). GCC has two main controllers: Receiver-side controller and Sender-side controller, as shown in Figure 1 (De Cicco, Carlucci, & Mascolo 2013a; Carlucci, De Cicco, & Mascolo, 2014; De Cicco, Carlucci, & Mascolo, 2013b). The Receiver-side controller computes the next expected receiving rate Ar. It is composed of five main components: Arrival-time filter (estimates the queuing time variation T), Remote rate region (computes the threshold γ), Overuse detector (produces appropriate signal, overuse/underuse/normal, based on T and γ), Remote rate controller (estimates the next expected receiving rate Ar), and Receiver Estimated Max Bitrate (REMB) message processing unit (notifies sender with the next expected receiving rate). The Sender-side controller consists of two main components: TCP-Friendly Rate Control (TFRC) bandwidth estimation, and Sending Rate Controller. According to De Cicco, Carlucci, and Mascolo (2013b), sender-side controller is a loss-based congestion control algorithm which computes the target sending bitrate As.

Figure 1.

GCC Receiver-side and Sender-side components

Complete Article List

Search this Journal:
Reset
Open Access Articles: Forthcoming
Volume 8: 4 Issues (2017)
Volume 7: 4 Issues (2016)
Volume 6: 4 Issues (2015)
Volume 5: 4 Issues (2014)
Volume 4: 4 Issues (2013)
Volume 3: 4 Issues (2012)
Volume 2: 4 Issues (2011)
Volume 1: 4 Issues (2010)
View Complete Journal Contents Listing