< draft-padhye-dcp-ccid3-03.txt		draft-padhye-dcp-ccid3-04.txt >
	Internet Engineering Task Force		Internet Engineering Task Force
	INTERNET-DRAFT Jitendra Padhye		INTERNET-DRAFT Jitendra Padhye
	draft-padhye-dcp-ccid3-03.txt Microsoft Research		draft-padhye-dcp-ccid3-04.txt Microsoft Research
	Sally Floyd		Sally Floyd
	Eddie Kohler		Eddie Kohler
	ICIR		ICIR
	24 May 2002		19 June 2002
	Expires: November 2002		Expires: December 2002
	Profile for DCCP Congestion Control ID 3:		Profile for DCCP Congestion Control ID 3:
	TFRC Congestion Control		TFRC Congestion Control
	Status of this Document		Status of this Document
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 3, line 25 ¶		skipping to change at page 3, line 25 ¶
	4.3. Acknowledgments of Acknowledgments . . . . . . . . . 7		4.3. Acknowledgments of Acknowledgments . . . . . . . . . 7
	5. Explicit Congestion Notification. . . . . . . . . . . . 7		5. Explicit Congestion Notification. . . . . . . . . . . . 7
	6. Relevant Options and Features . . . . . . . . . . . . . 7		6. Relevant Options and Features . . . . . . . . . . . . . 7
	6.1. Window counter option. . . . . . . . . . . . . . . . 7		6.1. Window counter option. . . . . . . . . . . . . . . . 7
	6.2. Elapsed time option. . . . . . . . . . . . . . . . . 8		6.2. Elapsed time option. . . . . . . . . . . . . . . . . 8
	6.3. Loss Event Rate Option . . . . . . . . . . . . . . . 8		6.3. Loss Event Rate Option . . . . . . . . . . . . . . . 8
	6.4. Receive Rate Option. . . . . . . . . . . . . . . . . 8		6.4. Receive Rate Option. . . . . . . . . . . . . . . . . 8
	6.5. ECN NONCE Option . . . . . . . . . . . . . . . . . . 9		6.5. ECN NONCE Option . . . . . . . . . . . . . . . . . . 9
	7. Application Requirements. . . . . . . . . . . . . . . . 10		7. Application Requirements. . . . . . . . . . . . . . . . 10
	8. Design Considerations . . . . . . . . . . . . . . . . . 10		8. Design Considerations . . . . . . . . . . . . . . . . . 10
	9. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . 11		8.1. Determining Loss Events. . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . 11		8.2. Sending Feedback Packets . . . . . . . . . . . . . . 11
	11. Authors' Addresses . . . . . . . . . . . . . . . . . . 13		9. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . 12
			10. References . . . . . . . . . . . . . . . . . . . . . . 12
			11. Authors' Addresses . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	This document contains the profile for Congestion Control Identifier		This document contains the profile for Congestion Control Identifier
	3, TCP-friendly rate control (TFRC), in the Datagram Congestion		3, TCP-friendly rate control (TFRC), in the Datagram Congestion
	Control Protocol (DCCP). DCCP uses Congestion Control Identifiers,		Control Protocol (DCCP). DCCP uses Congestion Control Identifiers,
	or CCIDs, to specify the congestion control mechanism in use on a		or CCIDs, to specify the congestion control mechanism in use on a
	half-connection. (A half-connection might consist of data packets		half-connection. (A half-connection might consist of data packets
	sent from DCCP A to DCCP B, plus acknowledgments sent from DCCP B to		sent from DCCP A to DCCP B, plus acknowledgments sent from DCCP B to
	DCCP A. DCCP A is the sending DCCP, and DCCP B the acknowledging		DCCP A. DCCP A is the sending DCCP, and DCCP B the acknowledging
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 25 ¶
	TFRC is a receiver-based congestion control mechanism that provides		TFRC is a receiver-based congestion control mechanism that provides
	a TCP-friendly send rate, while minimizing abrupt rate changes [1].		a TCP-friendly send rate, while minimizing abrupt rate changes [1].
	The basic TFRC protocol is as follows. The sender sends a stream of		The basic TFRC protocol is as follows. The sender sends a stream of
	data packets to the receiver at some rate. The receiver sends a		data packets to the receiver at some rate. The receiver sends a
	feedback packet to the sender at least once every round-trip time.		feedback packet to the sender at least once every round-trip time.
	Based on the information contained in the feedback packets, the		Based on the information contained in the feedback packets, the
	sender adjusts its sending rate in accordance with the TCP		sender adjusts its sending rate in accordance with the TCP
	throughput equation [2], to maintain TCP-friendliness. If no		throughput equation [2], to maintain TCP-friendliness. If no
	feedback is received from the receiver in two round-trip times, the		feedback is received from the receiver in several round-trip times
	sender halves its sending rate.		(four, in the current TFRC specification), the sender halves its
			sending rate.
	The values of the round-trip time RTT, the loss event rate p and the		The values of the round-trip time RTT, the loss event rate p and the
	base timeout value TO are needed by the sender to calculate the send		base timeout value TO are needed by the sender to calculate the send
	rate using the TCP throughput equation. The sender calculates the		rate using the TCP throughput equation. The sender calculates the
	values of RTT and TO, while the receiver calculates the value of p.		values of RTT and TO, while the receiver calculates the value of p.
	1.1. Usage Scenario		1.1. Usage Scenario
	DCCP with TFRC congestion control is intended to provide congestion		DCCP with TFRC congestion control is intended to provide congestion
	control for the flow of data packets from the server to the client		control for the flow of data packets from the server to the client
	skipping to change at page 4, line 50 ¶		skipping to change at page 4, line 51 ¶
	prefer to minimize abrupt changes in the sending rate.		prefer to minimize abrupt changes in the sending rate.
	1.2. Example Half-Connection		1.2. Example Half-Connection
	This example, taken from the main DCCP draft, is of a half-		This example, taken from the main DCCP draft, is of a half-
	connection using TFRC Congestion Control specified by CCID 3. The		connection using TFRC Congestion Control specified by CCID 3. The
	"sender" is the HC-Sender, and the "receiver" is the HC-Receiver.		"sender" is the HC-Sender, and the "receiver" is the HC-Receiver.
	(1) The sender sends DCCP-Data packets, where the number of packets		(1) The sender sends DCCP-Data packets, where the number of packets
	sent is governed by an allowed transmit rate, as specified in		sent is governed by an allowed transmit rate, as specified in
	[1]. Each DCCP-Data packet has a sequence number, and includes		[1]. Each DCCP-Data packet has a sequence number and a window
	an Acknowledgment Number that is the sequence number of the most		counter option.
	recent acknowledgment packet received from the receiver. Each
	DCCP-Data packet also contains a timestamp, the sender's
	estimate of the round-trip time, and the current sending rate.
	One or more of these data packets are DCCP-DataAck packets		One or more of these data packets are DCCP-DataAck packets
	acknowledging the data packet from the receiver, but for		acknowledging the data packet from the receiver, but for
	simplicity we will not discuss the half-connection of data from		simplicity we will not discuss the half-connection of data from
	the receiver to the sender in this example.		the receiver to the sender in this example.
	(2) The receiver sends DCCP-Ack packets at least once per round-trip		(2) The receiver sends DCCP-Ack packets at least once per round-trip
	time acknowledging the data packets, or as indicated by the TFRC		time acknowledging the data packets, unless the sender is
	specification [1]. Each DCCP-Ack packet uses a sequence number		sending at a rate of less than one packet per RTT, as indicated
	and identifies the most recent packet received from the sender.		by the TFRC specification [1]. Each DCCP-Ack packet uses a
	Each DCCP-Ack packet includes feedback about the loss event rate		sequence number and identifies the most recent packet received
	calculated by the receiver, as specified below.		from the sender. Each DCCP-Ack packet includes feedback about
			the loss event rate calculated by the receiver, as specified
			below.
	(3) The sender continues sending DCCP-Data packets as controlled by		(3) The sender continues sending DCCP-Data packets as controlled by
	the allowed transmit rate. Upon receiving DCCP-Ack packets, the		the allowed transmit rate. Upon receiving DCCP-Ack packets, the
	sender updates its allowed transmit rate as specified in [1].		sender updates its allowed transmit rate as specified in [1].
	(4) The sender estimates round-trip times and calculates a TimeOut		(4) The sender estimates round-trip times and calculates a TimeOut
	value TO as specified in [1].		value TO as specified in [1].
	(5) If the use of ECN has been negotiated, each DCCP-Data and DCCP-		(5) If the use of ECN has been negotiated, each DCCP-Data and DCCP-
	DataAck packet is sent as ECN-Capable, with either the ECT(0) or		DataAck packet is sent as ECN-Capable, with either the ECT(0) or
	the ECT(1) codepoint set. The use of the ECN Nonce with TFRC is		the ECT(1) codepoint set. The use of the ECN Nonce with TFRC is
	described below.		described below.
	2. Connection Establishment		2. Connection Establishment
	The connection is initiated by the client using mechanisms described		The connection is initiated by the client using mechanisms described
	in the DCCP specification [3]. The client and the server MAY		in the DCCP specification [3]. The client and the server MAY
	negotiate the use of the ACK Vector option. Both the server and the		negotiate the use of the ACK Vector option. The ACK vector option
	client MUST support the timestamp option. The ACK vector option and		is described in [3].
	the timestamp option are described in [3].
	3. Congestion Control on Data Packets		3. Congestion Control on Data Packets
	The sender sends DCCP-Data packets to the receiver at the rate		The sender sends DCCP-Data packets to the receiver at the rate
	specified by the TCP throughput equation [2].		specified by the TCP throughput equation [2].
	Each DCCP-Data packet has a sequence number, and an acknowledgment		Each DCCP-Data packet has a sequence number, and an acknowledgment
	number that is the sequence number of the most recent acknowledgment		number that is the sequence number of the most recent acknowledgment
	packet received from the receiver. Each data packet contains the		packet received from the receiver. Each data packet contains the
	window counter option. The format of the window counter option is		window counter option. The format of the window counter option is
	described below.		described below.
	After each feedback packet is received from the receiver, the sender		After each feedback packet is received from the receiver, the sender
	updates values of RTT, TO and the sending rate using procedures		updates values of RTT, TO and the sending rate using procedures
	specified in [1].		specified in [1].
	If no feedback packet is received from the receiver after an		If no feedback packet is received from the receiver after an
	inverval specified in [1], the sending rate is halved. However, the		interval specified in [1], the sending rate is halved. However, the
	sending rate is never reduced below one packet per 64 seconds. See		sending rate is never reduced below one packet per 64 seconds. See
	[1] for more details.		[1] for more details.
	4. Acknowledgments		4. Acknowledgments
	The receiver sends DCCP-Ack packets to the sender once per round-		The receiver sends a DCCP-Ack packet to the sender roughly once per
	trip time, or more frequently. This rate is determined by details of		round-trip time, if the sender is sending packets that frequently.
	the TFRC protocol, as specified in [1].		This rate is determined by details of the TFRC protocol, as
			specified in [1].
	The acknowledgment number in the DCCP-Ack packet acknowledges the		The acknowledgment number in the DCCP-Ack packet acknowledges the
	most recent packet received from the sender. Each DCCP-Ack packet		most recent packet received from the sender. Each DCCP-Ack packet
	from the receiver includes the following options:		from the receiver includes the following options:
	1. An option specifying the amount of time elapsed between since		1. An option specifying the amount of time elapsed between since
	the receiver received the packet whose sequence number appears		the receiver received the packet whose sequence number appears
	in the acknowledgment field.		in the acknowledgment field.
	2. An option specifying the loss event rate p calculated by the		2. An option specifying the loss event rate p calculated by the
	skipping to change at page 10, line 21 ¶		skipping to change at page 10, line 21 ¶
	As it is presently specified, this CCID should only be used by		As it is presently specified, this CCID should only be used by
	senders that are willing to trust the receiver to report the correct		senders that are willing to trust the receiver to report the correct
	loss event rate. If ECN is used, the ECN Nonce Option allows the		loss event rate. If ECN is used, the ECN Nonce Option allows the
	sender to probabilistically verify the loss rate reported by the		sender to probabilistically verify the loss rate reported by the
	receiver. However, we have not specified such a verification		receiver. However, we have not specified such a verification
	procedure in this document.		procedure in this document.
	8. Design Considerations		8. Design Considerations
	The data packets do not carry timestamps. The sender can store the		The data packets do not carry timestamps. The sender can store the
	times at which each packet was sent. When an acknowldegemnt arrives,		times at which recent packets were sent. When an acknowledgement
	the acknowldegemnt number and the elapsed time option provide		arrives, the acknowledgement number and the elapsed time option
	sufficient information to compute the round trip time.		provide sufficient information to compute the round trip time.
			8.1. Determining Loss Events
	The window counter option is used by the receiver to determine if		The window counter option is used by the receiver to determine if
	multiple lost packets belong to the same loss event. The sender		multiple lost packets belong to the same loss event. The sender
	increases the window counter by 1 every quarter round trip time. To		increases the window counter by 1 every quarter round trip time. To
	determine whether two lost packets, with sequnece numbers X and Y (Y		determine whether two lost packets, with sequence numbers X and Y (Y
	> X), belong to different loss events, the receiver proceeds as		> X), belong to different loss events, the receiver proceeds as
	follows:		follows:
	- Let X_prev be the highest sequence number which was received,		- Let X_prev be the highest sequence number which was received
	and X_prev < X.		with X_prev < X.
	- Let Y_prev be the highest seuqnce number which was received,		- Let Y_prev be the highest sequence number which was received
	and Y_prev < Y.		with Y_prev < Y.
	- Let CX_prev and CY_prev be the window counters associated with		- Let CX_prev and CY_prev be the window counters associated with
	packets X_prev and Y_prev respectively. Clearly, CY_prev >=		packets X_prev and Y_prev respectively. Clearly, CY_prev >=
	CX_prev.		CX_prev.
	- Packets X and Y belong to different loss events if (CY_prev -		- Packets X and Y belong to different loss events if (CY_prev -
	CX_prev) > 4		CX_prev) > 4
	The use of the window counter option can help the receiver to		The use of the window counter option can help the receiver to
	disambiguate multiple losses after a sudden decrease in the actual		disambiguate multiple losses after a sudden decrease in the actual
	round-trip time. When the sender receives an acknowledgement		round-trip time. When the sender receives an acknowledgement
	acknowledging a data packet with window counter i, the sender can		acknowledging a data packet with window counter i, the sender
	increase its window counter, if necessary, so that subsequent data		increases its window counter, if necessary, so that subsequent data
	packets are sent with window counter values of at least i+4. This		packets are sent with window counter values of at least i+4. This
	can help minimize errors on the part of the receiver of incorrectly		can help minimize errors on the part of the receiver of incorrectly
	interpreting multiple loss events as a single loss event.		interpreting multiple loss events as a single loss event.
	As an alternative to the window counter option, the sender could		As an alternative to the window counter option, the sender could
	have sent its estimate of the round-trip time to the receiver		have sent its estimate of the round-trip time to the receiver
	directly in a round-trip time option, and the receiver should use		directly in a round-trip time option, and the receiver should use
	the sender's round-trip time estimate to infer when multiple lost or		the sender's round-trip time estimate to infer when multiple lost or
	marked packets belong in the same loss event. A round-trip time		marked packets belong in the same loss event. In some respects, a
	option would in some ways give a more precise encoding of the		round-trip time option gives a more precise encoding of the sender's
	sender's round-trip time estimate than would a window counter		round-trip time estimate than does the window counter option.
	option. However, the window counter option conveys information		However, the window counter option conveys information about the
	about the relative *sending* times for packets, while the receiver		relative *sending* times for packets, while the receiver could only
	could only use a round-trip time option to distinguish between the		use the round-trip time option to distinguish between the relative
	relative *receive* times (in the absence of timestamps). That is,		*receive* times (in the absence of timestamps). That is, the window
	the window counter option will give more robust performance in some		counter option will give more robust performance in some cases when
	cases when there is a large variation in delay for packets sent		there is a large variation in delay for packets sent within a window
	within a window of data. As a slightly more speculative		of data. As a slightly more speculative consideration, the round-
	consideration, a round-trip time option could possibly be used more		trip time option could possibly be used more easily by middleboxes
	easily by middleboxes attempting to verify that a flow was using		attempting to verify that a flow was using conformant end-to-end
	conformant end-to-end congestion control.		congestion control.
			8.2. Sending Feedback Packets
			The window counter option is also used by the receiver to decide
			when to send feedback packets. Feedback packets should normally be
			sent at least once per round-trip time, if the sender is sending at
			least one data packet per round-trip time. Whenever the receiver
			sends a feedback message, the receiver sets a local variable
			last_counter to the highest received value of the window counter
			since the last feedback message was sent, if any data packets have
			been received since the last feedback message was sent. If the
			receiver receives a data packet with a window counter value greater
			than last_counter + 4, then the receiver sends a new feedback
			packet.
			The TFRC protocol [1] specifies that the receiver uses a feedback
			timer to decide when to send feedback packets. In the TFRC
			protocol, when the feedback timer expires, the receiver resets the
			timer to expire after R_m seconds, where R_m is the most recent
			estimate of the round-trip time received by the receiver from the
			sender. However, when the window counter option is used, the
			receiver can use information from the window counter option in
			deciding when to send feedback packets.
			When the sender is sending less than one packet per round-trip time,
			then the receiver sends a feedback packet after each data packet,
			and the feedback timer is not required. Similarly, when the sender
			is sending several packets per round-trip time, then the receiver
			will send a feedback packet each time that a data packet arrives
			with a window counter more than four greater than the window counter
			when the last feedback packet was sent, and again the feedback
			counter is not required. Similarly, the receiver always sends a
			feedback packet after the detection of a loss event. Thus, the
			feedback timer is not absolutely necessary when the window counter
			is used.
			However, the feedback timer still could be useful in some rare cases
			to prevent the sender from unnecessarily halving its sending rate.
			We have not considered this in detail. Consider the case when the
			receiver receives data soon after the most recent feedback packet
			has been sent, but has received no data packets with a window
			counter sufficiently large to trigger sending a new feedback packet.
			The TFRC protocol specifies that after a feedback packet is
			received, the sender sets a nofeedback timer to at least four times
			the round-trip time estimate. If the sender doesn't receive any
			feedback packets before the nofeedback timer expires, then the
			sender halves its sending rate. One could construct scenarios where
			the use of a feedback timer at the receiver would prevent the
			unnecessary expiration of the nofeedback timer at the sender.
			For implementors who wish to implement a feedback timer for the data
			receiver, we suggest estimating the round-trip time from the most
			recent data packet as follows: Let K be the window counter from the
			most recent data packet, and let T_k be the time that that packet
			was received. Let J be the highest window counter received that was
			less than K-4, and let T_j be the most recent time that such a
			packet was received. Then the round-trip time can be very roughly
			estimated as 4 (T_k-T_j)/(K-J).
	9. Thanks		9. Thanks
	We thank Mark Handley for his help in defining CCID 3.		We thank Mark Handley for his help in defining CCID 3. We thank
			Sara Karlberg and Yufei Wang for feedback on an earlier version of
			this document.
	10. References		10. References
	[1] M. Handley, J. Padhye, and S. Floyd. TCP Friendly Rate Control		[1] M. Handley, J. Padhye, and S. Floyd. TCP Friendly Rate Control
	(TFRC): Protocol Specification. draft-ietf-tsvwg-tfrc-02.txt,		(TFRC): Protocol Specification, draft-ietf-tsvwg-tfrc-04.txt,
	work in progress.		work in progress, April 2002.
	[2] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP		[2] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP
	Throughput: A Simple Model and its Empirical Validation. Proc		Throughput: A Simple Model and its Empirical Validation. Proc
	ACM SIGCOMM 1998.		ACM SIGCOMM 1998.
	[3] E. Kohler, M. Handley, S. Floyd, and J. Padhye. Datagram		[3] E. Kohler, M. Handley, S. Floyd, and J. Padhye. Datagram
	Congestion Control Protocol. Work in progress.		Congestion Control Protocol, draft-kohler-dcp-02.txt, work in
			progress, March 2002.
	[4] David Wetherall, David Ely, and Neil Spring. Robust ECN		[4] Neil Spring, David Wetherall, and David Ely. Robust ECN
	Signaling with Nonces. draft-ietf-tsvwg-tcp-nonce-02.txt, work		Signaling with Nonces, draft-ietf-tsvwg-tcp-nonce-03.txt, work
	in progress.		in progress, April 2002.
	[5] S. Floyd, E. Kohler. Profile for DCCP Congestion Control ID 2:		[5] S. Floyd, E. Kohler. Profile for DCCP Congestion Control ID 2:
	TCP-like Congestion Control. Work in progress.		TCP-like Congestion Control, draft-floyd-dcp-ccid2-03.txt, work
			in progress, May 2002.
	[6] K.K. Ramakrishnan, S. Floyd, and D. Black. The Addition of		[6] K.K. Ramakrishnan, S. Floyd, and D. Black. The Addition of
	Explicit Congestion Notification (ECN) to IP. RFC 3168.		Explicit Congestion Notification (ECN) to IP. RFC 3168.
	September 2001.		September 2001.
	11. Authors' Addresses		11. Authors' Addresses
	Jitendra Padhye <padhye@microsoft.com>		Jitendra Padhye <padhye@microsoft.com>
	Microsoft Research		Microsoft Research
End of changes. 20 change blocks.
	56 lines changed or deleted		122 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/