Experimental settings employed to evaluate the Google Congestion Control for WebRTC

This web page provides the guideline and some scripts required to reproduce the experiments to evaluate the Google Congestion Control (GCC) for WebRTC. It can be used to reproduce the results obtained in the papers published in the context of the Google Faculty Research Award 2014 reported here.

Figure 1 shows an example of the experimental testbed topology. Two nodes, connected through an Ethernet cable, are used to run instances of the Chromium browsers, where GCC is installed, to generate WebRTC traffic and IPerf-like applications to generate concurrent TCP traffic. The experiments are orchestrated by the Controller that sends ssh commands to automatically start the WebRTC calls, start the TCP traffic and set the bottleneck parameters.

Experimental Testbed
Figure 1: Experimental Testbed Example

WAN Link Emulation

This repository contains the scripts used to emulate a WAN bottleneck link which in Figure 1 is shown on Node 1:

The bottleneck link queue can be governed by Drop Tail queue, AQM algorithms or flow queuing schedulers.These scripts employ iproute2 package and the NetEm Linux module. With tc “traffic control” is possible to set the queuing discipline, limit the link capacity and much more. The NetEm linux module can be employed to set the propagation delay.

Google Congestion Control Settings

The Google Congestion Control algorithm is implemented in Google Chrome browser which is daily updated. To carry out the experimental investigation with the version of GCC according to the results that the reader wants to reproduce, we recommend to Download and Compile the open source Chromium browser:

The reader can work with the appropriate release version number since they are tagged in the git repository.

The implementation of the GCC can be found in two main directories of the git repository:

1. Remote Bitrate Estimator
This directory contains the delay-based controller implementation in the form of three main classes:
1. Over Use Detector: (overuse_estimator.cc) which estimates the one-way delay variation between the incoming packets with a Kalman filter;
2. Over Use Estimator: (overuse_detector.cc) which compares the one way delay variation with a threshold and generates a signal that reports the status of the network (over-used, normal, under-used);
3. Rate Control: (aimd_rate_control.cc) which uses this signal to drive a finite state machine that computes the sending bitrate
2. Bitrate Controller
This directory contains the loss-based controller implementation:
1. Bandwidth Estimation: (send_side_bandwidth_estimation.cc) which computes the sending bitrate based on the fraction loss reported in RTCP packets

Relevant metrics , such as sending bitrate, RTT, packets losses, can be measured by employing different approaches. Here we cite some.

  1. Extraction in the form of traces from the Chromium source code after re-compilation.

Web Server Settings

Video Settings

TCP Settings

Experimental settings employed to evaluate the Google Congestion Control for WebRTC[edit]

This web page provides the guideline and some scripts required to reproduce the experiments to evaluate the Google Congestion Control (GCC) for WebRTC. It can be used to reproduce the results obtained in the papers published in the context of the Google Faculty Research Award 2014 reported here.

Figure 1 shows an example of the experimental testbed topology. Two nodes, connected through an Ethernet cable, are used to run instances of the Chromium browsers, where GCC is installed, to generate WebRTC traffic and IPerf-like applications to generate concurrent TCP traffic. The experiments are orchestrated by the Controller that sends ssh commands to automatically start the WebRTC calls, start the TCP traffic and set the bottleneck parameters.

Experimental Testbed
Figure 1: Experimental Testbed Example

WAN Link Emulation[edit]

This repository contains the scripts used to emulate a WAN bottleneck link which in Figure 1 is shown on Node 1:

The bottleneck link queue can be governed by Drop Tail queue, AQM algorithms or flow queuing schedulers.These scripts employ iproute2 package and the NetEm Linux module. With tc “traffic control” is possible to set the queuing discipline, limit the link capacity and much more. The NetEm linux module can be employed to set the propagation delay.

Google Congestion Control Settings[edit]

The Google Congestion Control algorithm is implemented in Google Chrome browser which is daily updated. To carry out the experimental investigation with the version of GCC according to the results that the reader wants to reproduce, we recommend to Download and Compile the open source Chromium browser:

The reader can work with the appropriate release version number since they are tagged in the git repository.

The implementation of the GCC can be found in two main directories of the git repository:

1. Remote Bitrate Estimator
This directory contains the delay-based controller implementation in the form of three main classes:
1. Over Use Detector: (overuse_estimator.cc) which estimates the one-way delay variation between the incoming packets with a Kalman filter;
2. Over Use Estimator: (overuse_detector.cc) which compares the one way delay variation with a threshold and generates a signal that reports the status of the network (over-used, normal, under-used);
3. Rate Control: (aimd_rate_control.cc) which uses this signal to drive a finite state machine that computes the sending bitrate
2. Bitrate Controller
This directory contains the loss-based controller implementation:
1. Bandwidth Estimation: (send_side_bandwidth_estimation.cc) which computes the sending bitrate based on the fraction loss reported in RTCP packets

Relevant metrics , such as sending bitrate, RTT, packets losses, can be measured by employing different approaches. Here we cite some.

  1. Extraction in the form of traces from the Chromium source code after re-compilation.

Web Server Settings[edit]

Video Settings[edit]

TCP Settings[edit]