draft-ietf-tsvwg-tfrc-02.txt   draft-ietf-tsvwg-tfrc-03.txt 
Internet Engineering Task Force TSV WG Internet Engineering Task Force TSV WG
INTERNET-DRAFT Mark Handley/ACIRI INTERNET-DRAFT Mark Handley/ACIRI
draft-ietf-tsvwg-tfrc-02.txt Jitendra Padhye/ACIRI draft-ietf-tsvwg-tfrc-03.txt Jitendra Padhye/ACIRI
Sally Floyd/ACIRI Sally Floyd/ACIRI
Joerg Widmer/Univ. Mannheim Joerg Widmer/Univ. Mannheim
18 May 2001 20 July 2001
Expires: November 2001 Expires: January 2002
TCP Friendly Rate Control (TFRC): TCP Friendly Rate Control (TFRC):
Protocol Specification Protocol Specification
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at page 3, line 36 skipping to change at page 3, line 36
5.4. Average Loss Interval. . . . . . . . . . . . . . . . 15 5.4. Average Loss Interval. . . . . . . . . . . . . . . . 15
5.5. History Discounting. . . . . . . . . . . . . . . . . 16 5.5. History Discounting. . . . . . . . . . . . . . . . . 16
6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 18 6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 18
6.1. Receiver behavior when a data packet is 6.1. Receiver behavior when a data packet is
received. . . . . . . . . . . . . . . . . . . . . . . . . 19 received. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Expiration of feedback timer . . . . . . . . . . . . 19 6.2. Expiration of feedback timer . . . . . . . . . . . . 19
6.3. Receiver initialization. . . . . . . . . . . . . . . 20 6.3. Receiver initialization. . . . . . . . . . . . . . . 20
6.3.1. Initializing the Loss History after the 6.3.1. Initializing the Loss History after the
First Loss Event . . . . . . . . . . . . . . . . . . . . 20 First Loss Event . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . 20
8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 21 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a
congestion control mechanism designed for unicast flows operating in a congestion control mechanism designed for unicast flows operating in a
Internet environment and competing with TCP traffic. Instead of Internet environment and competing with TCP traffic [2]. Instead of
specifying a complete protocol, this document simply specifies a specifying a complete protocol, this document simply specifies a
congestion control mechanism that could be used in a transport protocol congestion control mechanism that could be used in a transport protocol
such as RTP [6], in an application incorporating end-to-end congestion such as RTP [6], in an application incorporating end-to-end congestion
control at the application level, or in the context of endpoint control at the application level, or in the context of endpoint
congestion management [BRS99]. This document does not discuss packet congestion management [BRS99]. This document does not discuss packet
formats, reliability, or implementation-related issues. formats, reliability, or implementation-related issues.
TFRC is designed to be reasonably fair when competing for bandwidth with TFRC is designed to be reasonably fair when competing for bandwidth with
TCP flows [2]. However it has a much lower variation of throughput over TCP flows, where a flow is ``reasonably fair'' if its sending rate is
time compared with TCP, which makes it more suitable for applications generally within a factor of two of the sending rate of a TCP flow under
such as telephony or streaming media where a relatively smooth sending the same conditions. However TFRC has a much lower variation of
rate is of importance. 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 The penalty of having smoother throughput than TCP while competing
fairly for bandwidth is that TFRC responds slower than TCP to changes in fairly for bandwidth is that TFRC responds slower than TCP to changes in
available bandwidth. Thus TFRC should only be used when the application available bandwidth. Thus TFRC should only be used when the application
has a requirement for smooth throughput, in particular, avoiding TCP's has a requirement for smooth throughput, in particular, avoiding TCP's
halving of the sending rate in response to a single packet drop. For 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 applications that simply need to transfer as much data as possible in as
short a time as possible we recommend using TCP, or if reliability is short a time as possible we recommend using TCP, or if reliability is
not required, using an Additive-Increase, Multiplicative-Decrease (AIMD) not required, using an Additive-Increase, Multiplicative-Decrease (AIMD)
congestion control scheme with similar parameters to those used by TCP. congestion control scheme with similar parameters to those used by TCP.
TFRC is designed for applications that use a fixed packet size, and vary TFRC is designed for applications that use a fixed packet size, and vary
their sending rate in packets per second in response to congestion. their sending rate in packets per second in response to congestion.
Some audio applications require a fixed interval of time between packets Some audio applications require a fixed interval of time between packets
and vary their packet size instead of their packet rate in response to and vary their packet size instead of their packet rate in response to
congestion. The congestion control mechanism in this document cannot be congestion. The congestion control mechanism in this document cannot be
used by those applications; variants of TFRC for applications that have used by those applications; TFRC-PS (for TFRC-PacketSize) is a variant
a fixed sending rate but vary their packet size in response to of TFRC for applications that have a fixed sending rate but vary their
congestion will be addressed in a separate document. 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 TFRC is a receiver-based mechanism, with the calculation of the
congestion control information (i.e., the loss event rate) in the data congestion control information (i.e., the loss event rate) in the data
receiver rather in the data sender. This is well-suited to an receiver rather in the data sender. This is well-suited to an
application where the sender is a large server handling many concurrent application where the sender is a large server handling many concurrent
connections, and the receiver has more memory and CPU cycles available connections, and the receiver has more memory and CPU cycles available
for computation. In addition, a receiver-based mechanism is more for computation. In addition, a receiver-based mechanism is more
suitable as a building block for multicast congestion control. suitable as a building block for multicast congestion control.
2. Terminology 2. Terminology
skipping to change at page 9, line 18 skipping to change at page 9, line 18
estimate of the mean packet size for s. estimate of the mean packet size for s.
o The application needs to change the packet size rather than the o The application needs to change the packet size rather than the
number of packets per second to perform congestion control. This number of packets per second to perform congestion control. This
would normally be the case with packet audio applications where a would normally be the case with packet audio applications where a
fixed interval of time needs to be represented by each packet. fixed interval of time needs to be represented by each packet.
Such applications need to have a completely different way of Such applications need to have a completely different way of
measuring parameters. measuring parameters.
The second class of applications are discussed separately in a separate The second class of applications are discussed separately in a separate
document. For the remainder of this section we assume the sender can document on TFRC-PS. For the remainder of this section we assume the
estimate the packet size, and that congestion control is performed by sender can estimate the packet size, and that congestion control is
adjusting the number of packets sent per second. performed by adjusting the number of packets sent per second.
4.2. Sender Initialization 4.2. Sender Initialization
To initialize the sender, the value of X is set to 1 packet/second and To initialize the sender, the value of X is set to 1 packet/second and
the nofeedback timer is set to expire after 2 seconds. The initial the nofeedback timer is set to expire after 2 seconds. The initial
values for R (RTT) and t_RTO are undefined until they are set as values for R (RTT) and t_RTO are undefined until they are set as
described above. The intial value of tld, for the Time Last Doubled described above. The intial value of tld, for the Time Last Doubled
during slow-start, is set to -1. during slow-start, is set to -1.
4.3. Sender behavior when a feedback packet is received 4.3. Sender behavior when a feedback packet is received
skipping to change at page 21, line 29 skipping to change at page 21, line 29
transport protocol, and in particular on whether the transport protocol transport protocol, and in particular on whether the transport protocol
is reliable or unreliable. is reliable or unreliable.
We expect that protocols incorporating ECN with TFRC will also want to We expect that protocols incorporating ECN with TFRC will also want to
incorporate feedback from the receiver to the sender using the ECN nonce incorporate feedback from the receiver to the sender using the ECN nonce
[WES01]. The ECN nonce is a modification to ECN that protects the [WES01]. The ECN nonce is a modification to ECN that protects the
sender from the accidental or malicious concealment of marked packets. sender from the accidental or malicious concealment of marked packets.
Again, the details of such a nonce would depend on the transport Again, the details of such a nonce would depend on the transport
protocol, and are not addressed in this document. protocol, and are not addressed in this document.
8. Authors' Addresses 8. IANA Considerations
There are no IANA actions required for this document.
9. Authors' Addresses
Mark Handley, Jitendra Padhye, Sally Floyd Mark Handley, Jitendra Padhye, Sally Floyd
ACIRI/ICSI ACIRI/ICSI
1947 Center St, Suite 600 1947 Center St, Suite 600
Berkeley, CA 94708 Berkeley, CA 94708
mjh@aciri.org, padhye@aciri.org, floyd@aciri.org mjh@aciri.org, padhye@aciri.org, floyd@aciri.org
Joerg Widmer Joerg Widmer
Lehrstuhl Praktische Informatik IV Lehrstuhl Praktische Informatik IV
Universitat Mannheim Universitat Mannheim
L 15, 16 - Room 415 L 15, 16 - Room 415
D-68131 Mannheim D-68131 Mannheim
Germany Germany
widmer@informatik.uni-mannheim.de widmer@informatik.uni-mannheim.de
9. Acknowledgments 10. Acknowledgments
We would like to acknowledge feedback and discussions on equation-based We would like to acknowledge feedback and discussions on equation-based
congestion control with a wide range of people, including members of the congestion control with a wide range of people, including members of the
Reliable Multicast Research Group, the Reliable Multicast Transport Reliable Multicast Research Group, the Reliable Multicast Transport
Working Group, and the End-to-End Research Group. We would like to Working Group, and the End-to-End Research Group. We would like to
thank Eduardo Urzaiz, Vladica Stanisic, and Shushan Wen for feedback on thank Eduardo Urzaiz, Vladica Stanisic, and Shushan Wen for feedback on
earlier versions of this document, and to thank Mark Allman for his earlier versions of this document, and to thank Mark Allman for his
extensive feedback from using the draft to produce a working extensive feedback from using the draft to produce a working
implementation. implementation.
10. References 11. References
[1] Balakrishnan, H., Rahul, H., and Seshan, S., "An Integrated [1] Balakrishnan, H., Rahul, H., and Seshan, S., "An Integrated
Congestion Management Architecture for Internet Hosts," Proc. ACM Congestion Management Architecture for Internet Hosts," Proc. ACM
SIGCOMM, Cambridge, MA, September 1999. SIGCOMM, Cambridge, MA, September 1999.
[2] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based [2] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based
Congestion Control for Unicast Applications", August 2000, Proc Congestion Control for Unicast Applications", August 2000, Proc
SIGCOMM 2000. SIGCOMM 2000.
[3] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based [3] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/