TL;DR We are working on a new congestion control method that probes for additional capacity with redundant data (FEC).
In our previous blog post we discussed a flexible Forward Error Correction (FEC) method for recovering packets at the end-point side by sending redundant data along with media traffic. This blog post is about using redundant data for congestion control.
Congestion Control algorithms are considered in the RTP for Media Congestion Avoidance Technique IETF group using proactive congestion control for detecting and avoiding congestions. Most congestion control algorithms for real-time multimedia use several congestion indicators to estimate the new sending rate. The most important congestion indicators are: variation in one-way delay and packet loss.
Packet loss can occur when a network queue gets congested or when packets get corrupted in a wireless networks due to fading, interference, mobility, etc. In TCP packet loss is considered congestion and the sending rate reduced.
Similarly, increase in the one-way delay metric indicates that congestion may be occurring, and that the sending bit rate may need to be reduced. Since, not all video packets are of equal size, for example, I-frames are substantially bigger (10-100x) than the P-frames, the queuing delay may be increasing because the sender sent a large frame onto the network, however, majority of the video frames are the small P-frames. Hence, most congestion control algorithms assume that the one-way delay is gaussian distributed, i.e., it a spike around an expected mean value. For example:
- Google Congestion Control GCC determines the average one-way delay value for group of packets using a Kalman Filter.
- SCReAM uses the differences between the timestamp of two consecutive RTP packets (inter-arrival time) to calculates the autocorrelation over the last 20-50 measurements.
FRACTaL: FEC for congestion control
Flexible and Adaptive FEC for RTP Congestion Control (FRACTaL) is an evolution of the FEC Based Rate Adaptation, which proposes using FEC when probing for additional capacity. The Internet draft incorporates FEC with any RMCAT-based congestion control.
The basic idea is to use FEC as redundant data alongside the media traffic, in order to probe for additional capacity. Instead of increasing the media bit rate, the sender introduces more FEC packet, which in effect increases the amount of redundancy. For example, protecting two equal sized packets increases the overall rate by 33%, etc. In the next reporting interval, if the lost packets were recovered by the FEC, the sender has a better estimate of the bottleneck capacity and can swap the redundant FEC packets with media packets. Figure 1 shows the application of FEC for congestion control, i.e., the variation of FEC and media bit rate to the bottleneck capacity. Figure 2 shows the corresponding state machine for the congestion control, it provides guidance on when to add and remove FEC.
Figure 1. Flexible and Adaptive FEC for RTP Congestion Control.
Figure 2: State machine for the FEC based RTP Congestion Control
Introducing FEC as part of the congestion control slightly changes the RTP architecture. For example, the FEC module sits between the rate controller and the RTP multiplexer, at the sender, creates the repair packets based on the FEC code (parity, reed-solomon, etc) and the source RTP packets coming from the media encoder. See Figure 3 for details, it is also dicussed in more detail in RFC 6363
Figure 3. Congestion Control Framework incorporating FEC.
Figure 4 is a sample plot showing the variation of combined media and FEC rate (blue) and just the FEC rate (green) using FRACTaL in comparison to the bottleneck capacity (red line). The congestion control (combined FEC and media rate) reaches the bottleneck capacity in roughly 15 seconds, as soon as it goes over (sharp drop in capacity at 40s), it turns off FEC (at 41s). When the combined rate is close to the bottleneck capacity, FRACTaL maintains the media bitrate (observe this in the 15-20s, and again 35-40s) and keeps a very low amount of FEC to keep probing for additional capacity. Consequently, when it observes short queues, and low variation in end-to-end delay, it attempts to ramp up quickly (see around 22-25s).
Figure 4. The variation of media throughput to bottleneck capacity using FRACTaL. The blue lines represents the media rate, green only the FEC rate, and red is the bottleneck capacity.
Additional reading list
