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/