TFRC is a congestion control mechanism designed for media transmission. It has a much lower variation of throughput over time compared with TCP and, at the same time, it is reasonably fair when competing for bandwidth with TCP flows (ie, it is TCP-friendly). This smooth sending rate variation makes it an ideal option for the transmission of audio or video, as the receiver needs less buffering for balancing the input and output rates at the playout buffer.

Some time ago I implemented TFRC and integrated it in the Ultragrid project. However, TFRC was a pain when used in local are networks, environments with very short RTTs and huge data rates. The main problem was with the timeout used by TFRC for detecting lost packets.

A TFRC sender will expect a feedback from the receiver every RTT. In order to detect lost feedbacks, it sets a timeout equal to four times the RTT, and, if it doesn’t receive a feedback in that time, the sender will consider that there are some problems…

But, in local area networks, the RTT can be really short (in the order of microseconds), and high data rates can result in lots of interrupts (due to many packets going in and out thru the network card), so the receiver will not get the CPU so often as it would like, being preempted in many occasions. The receiver will then be late sending feedback many times, and the sender will fall back to a safe sending rate too often, leading to some sending rate instability.

Today I discovered a posible solution for this problem. In RFC2988 they deal with the timeout estimation problem for TCP, and the same calculation can (or, should I say, must) be applied to TFRC. This would lead to a more complex sending rate calculation, but it would probably provide greater stability…