What is Google Congestion Control in WebRTC?

Real-time communication relies on delivering high-quality audio and video without causing network congestion. This article explores Google Congestion Control (GCC), a foundational algorithm used in WebRTC to manage media flows. We will examine how GCC works, its two primary components—delay-based and loss-based controllers—and how it dynamically adjusts bandwidth to ensure smooth, real-time media delivery even under fluctuating network conditions.

Understanding Google Congestion Control (GCC)

Google Congestion Control (GCC) is an algorithm designed to estimate the available bandwidth in a network path and adjust the WebRTC media transmission rate accordingly. Unlike file downloads, which can buffer, real-time media (like video calls) must prioritize low latency. If WebRTC sends more data than the network can handle, packets queue up in routers, causing latency (lag) and packet loss, which degrades the user experience.

GCC solves this by continuously monitoring the network and dynamically calculating the optimal target bitrate. It does this by combining two distinct control mechanisms: a delay-based controller and a loss-based controller.

The Dual-Engine Approach of GCC

To accurately govern media flows, GCC operates on two fronts simultaneously, using both delay and packet loss as indicators of network congestion.

1. Delay-Based Congestion Control

The delay-based controller is proactive. It aims to detect network congestion before packet loss actually occurs by measuring “one-way delay variation” (jitter).

• How it works: The sender groups packets into bursts. The receiver measures the time difference between when packets were sent and when they arrived.
• Trendline Estimator: If the arrival time interval is longer than the departure time interval, it indicates that packets are buffering in a network router. GCC uses a mathematical model called a Trendline Estimator to analyze these delay trends.
• State Detection: Based on the trend, the controller classifies the network into one of three states:
  • Normal: The network is stable; bitrate can be safely increased.
  • Underuse: The network is clearing queued packets; bitrate can be increased.
  • Overuse: Network queues are building up; bitrate must be decreased immediately to prevent packet loss.

Initially, this delay-based calculation was performed on the receiver side (using REMB packets to send feedback). Modern implementations of GCC have moved this to the sender side (using Transport-wide Congestion Control, or TWCC), where the receiver simply sends arrival timestamps back to the sender, and the sender calculates the delay trend.

2. Loss-Based Congestion Control

The loss-based controller is reactive. It acts as a safety net when sudden congestion occurs or when the network buffer is too small to trigger delay-based warnings.

This controller runs on the sender side and relies on RTCP Receiver Reports, which communicate the percentage of packets lost during transmission. The sender adjusts the target bitrate based on three loss thresholds:

• Low Loss (Less than 2%): The network is healthy. The sender is allowed to increase the bitrate to explore higher quality.
• High Loss (Greater than 10%): The network is congested. The sender immediately decreases the bitrate (typically by multiplying the current rate by 0.85) to ease the congestion.
• Moderate Loss (Between 2% and 10%): The bitrate is kept constant to allow the network to stabilize.

How GCC Determines the Final Bitrate

The sender’s congestion controller continuously calculates two independent bitrate limits: one from the delay-based estimator and one from the loss-based estimator.

To govern the WebRTC media flow safely, GCC selects the minimum of these two calculated bitrates.

For example, if the delay-based estimator determines the network can handle 2 Mbps, but sudden packet loss restricts the loss-based estimator to 1 Mbps, GCC will cap the media stream at 1 Mbps. This conservative approach prevents WebRTC from overloading weak networks while allowing it to scale up to maximum quality when network conditions are pristine.