Congestion control schemes: sender-driven, receiver-driven and co-operative

Congestion control algorithms have been studied extensively for TCP since the 1980s. In the 1990s Voice and Video over IP has been emerged and products required to implement congestion control algorithms to adapt the quality of the media stream based on the network behavior (varying end-to-end delay, varying capacity in the bottleneck link, or varying amount of cross-traffic, etc).

Instead of its history, this blog-post is intended to give a short introduction about its schematic implementation point of view. Congestion Controllers can be implemented at the sender, at the receiver, or the sender and receiver can operate co-operatively. On the figure above the interaction, between a sender and receiver for each scheme are shown in a unidirectional media flow, however in reality media flows are bidirectional.

Schemes of congestion control indicates where the calculation for the desired sending rate is performed. The sender-driven scheme requires the receiver side to measure the current network condition and signal the observed congestion cues to the sender, which calculates the sender’s estimate and uses it as the new sending rate. A typical example of a sender-driven scheme is TCP Friendly Rate Control (TFRC).

In the receiver-driven scheme, the receiver calculates the new sending rate (receiver’s estimate) based on the observed congestion cues, and signals the new rate to the sender, which, on receiving the new rate, adapts the media bit rate to the received value. A typical example is Temporary Maximum Media Stream Bit Rate Request or Notification TMMBN/TMMBR.

The co-operative scheme is an extension to the sender-driven scheme. Here, the receiver calculates the receiver’s estimated rate and signals it along with the observed congestion cues; the sender side calculates its own estimate based on the congestion cues and chooses a new sending rate, typically a value in between the sender’s estimate and the receiver’s estimate. Earlier versions of GCC proposed by Google used a co-operative model.

Google’s operational experience showed that changing the behavior of the sender and receiver side of the congestion control became difficult to maintain. The difficulty mainly comes from the fact that the congestion control changes as the operations mature, and at any given time, there are simultaneously different versions of the browsers, which may need to interact with one another. For example one participant in a call may be on Chrome M53, another on M54, and yet another on M55, and so on. If all versions have a slightly different variant of the same protocol, the performance may be hard to predict and diagnose.

Based on the above, most of the community is transitioning to sender-driven congestion control, where the receivers send a set of relevant metrics (losses, discards, RTT, last packet received, etc) and the senders use those metrics to perform congestion control.

To facilitate this effort, the community got together to define a new generic congestion control feedback which should work with several algorithms RTP congestion control algorithms (e.g., SCReAM, Adaptive FEC, NADA, etc).

If you get excited about analysing and developing realtime communnications, have look at our jobs page and apply for a job.

Parts of this blog post text have been taken from Varun's (our CEO) PhD thesis.