The IESG has approved the Internet-Draft 'TCP Friendly Rate Control (TFRC):Protocol Specification' <draft-ietf-tsvwg-tfrc-05.txt> as a Proposed Standard. This document is the product of the Transport Area Working Group Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary TCP-Friendly Rate Control (TFRC) is a congestion control mechanism designed for unicast flows operating in a Internet environment and competing with TCP traffic. Instead of specifying a complete protocol, this specification provides the algorithm and protocol exchange mechanism needed for a transport protocol such as RTP (RFC 1889) to be extended with TFRC. It could also be used by an application directly (assuming this style of congestion control is well suited to the application's needs) or used in the context of the Endpoint Congestion Management standard (RFC 3124). The two constraints for use of TFRC are that the traffic use fixed packet size, varying sending rate in packets per second as the response to congestion, and that there be a channel for feedback from the receiver. TFRC is based on the TCP- equivalent throughput equation, described in the specification, with references to studies validating it both in simulations and Internet measurements. TFRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where a flow is ``reasonably fair'' if its sending rate is generally within a factor of two of the sending rate of a TCP flow under the same conditions. However TFRC has a much lower variation of throughput over time compared with TCP, which makes it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. The penalty of having smoother throughput than TCP while competing fairly for bandwidth is that TFRC responds more slowly than TCP to changes in available bandwidth. Thus TFRC should only be used when the application has a requirement for smooth throughput, in particular, avoiding TCP's halving of the sending rate in response to a single packet drop. For applications that simply need to transfer as much data as possible in as short a time as possible, the continued recommendation is to use TCP (or SCTP if the data needs to be not a byte-stream). TFRC is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion. Some audio applications require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. The congestion control mechanism in this document cannot be used by those applications; TFRC-PS (for TFRC-PacketSize) is a variant of TFRC for applications that have a fixed sending rate but vary their packet size in response to congestion. TFRC-PS will be specified in a later document. TFRC is a receiver-based mechanism, with the calculation of the congestion control information (i.e., the loss event rate) in the data receiver rather in the data sender. This is well-suited to an application where the sender is a large server handling many concurrent connections, and the receiver has more memory and CPU cycles available for computation. In addition, a receiver-based mechanism is more suitable as a building block for multicast congestion control. Working Group Summary The Transport Working Group discussed this specification in some depth and gave a solid consensus for it be advanced in standards track. It had previously received lengthy and active review by the Reliable Multicast Research Group, an open research group with an open archive (see www.irtf.org for pointers). Protocol Quality The specification was reviewed for the IESG by Allison Mankin. Open source code for TFRC can be found at www.aciri.org/tfrc/.
