[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Protocol Action: TCP Friendly Rate Control (TFRC):Protocol Specification to Proposed Standard
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/.