< draft-ietf-dccp-tfrc-faster-restart-05.txt		draft-ietf-dccp-tfrc-faster-restart-06.txt >
	Internet Engineering Task Force E. Kohler		Internet Engineering Task Force E. Kohler
	INTERNET-DRAFT UCLA		INTERNET-DRAFT UCLA
	Intended status: Experimental S. Floyd		Intended status: Experimental S. Floyd
	Expires: May 2008 ICIR		Expires: January 2009 ICIR
	A. Sathiaseelan		A. Sathiaseelan
	University of Aberdeen		University of Aberdeen
	18 November 2007		14 July 2008
	Faster Restart for TCP Friendly Rate Control (TFRC)		Faster Restart for TCP Friendly Rate Control (TFRC)
	draft-ietf-dccp-tfrc-faster-restart-05.txt		draft-ietf-dccp-tfrc-faster-restart-06.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 2008.		This Internet-Draft will expire on January 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	TCP-Friendly Rate Control (TFRC) is a congestion control mechanism		TCP-Friendly Rate Control (TFRC) is a congestion control mechanism
	for unicast flows operating in a best-effort Internet environment.		for unicast flows operating in a best-effort Internet environment.
	This document introduces Faster Restart, an optional mechanism for		This document introduces Faster Restart, an optional mechanism for
	safely improving the behavior of interactive flows that use TFRC.		safely improving the behavior of interactive flows that use TFRC.
	Faster Restart is proposed for use with TFRC and with TFRC-SP, the		Faster Restart is proposed for use with TFRC and with TFRC-SP, the
	Small Packet variant of TFRC. We present Faster Restart in general		Small Packet variant of TFRC. We present Faster Restart in general
	terms as a congestion control mechanism, and further discuss Faster		terms as a congestion control mechanism, and further discuss Faster
	Restart for Datagram Congestion Control Protocol (DCCP) Congestion		Restart for Datagram Congestion Control Protocol (DCCP) Congestion
	Control IDs 3 and 4.		Control IDs 3 and 4.
	Table of Contents		Table of Contents
	1. Introduction ....................................................6		1. Introduction ....................................................6
	2. Conventions .....................................................9		2. Conventions ....................................................10
	3. Faster Restart: Changes to TFRC ................................10		3. Faster Restart: Changes to TFRC ................................11
	3.1. Feedback Packets ..........................................10		3.1. Feedback Packets ..........................................11
	3.2. Nofeedback Timer ..........................................13		3.2. Nofeedback Timer ..........................................15
	4. Faster Restart Discussion ......................................13		4. Faster Restart Discussion ......................................15
	4.1. Worst-Case Scenarios ......................................14		4.1. Worst-Case Scenarios ......................................16
	4.2. Incentives for applications to send unnecessary packets		4.2. Incentives for applications to send unnecessary packets
	during idle or data-limited periods ............................15		during idle or data-limited periods ............................16
	4.3. Interoperability Issues ...................................15		4.3. Interoperability Issues ...................................17
	4.3.1. Interoperability Issues with CCID-3 and the RFC		4.3.1. Interoperability Issues with CCID-3 and the RFC
	4342 Errata ...............................................15		4342 Errata ...............................................17
	4.4. Faster Restart for TFRC-SP ................................16		4.4. Faster Restart for TFRC-SP ................................18
	5. Simulations of Faster Restart ..................................16		5. Simulations of Faster Restart ..................................18
	6. Implementation Issues ..........................................17		6. Implementation Issues ..........................................19
	7. Security Considerations ........................................17		7. Security Considerations ........................................19
	8. IANA Considerations ............................................17		8. IANA Considerations ............................................19
	9. Thanks .........................................................17		9. Thanks .........................................................19
	Normative References ..............................................17		Normative References ..............................................19
	Informative References ............................................18		Informative References ............................................20
	A. Appendix: Simulations ..........................................19		A. Appendix: Simulations ..........................................21
	Authors' Addresses ................................................21		Authors' Addresses ................................................23
	Full Copyright Statement ..........................................22		Full Copyright Statement ..........................................24
	Intellectual Property .............................................22		Intellectual Property .............................................24
	NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.		NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.
			Changes from draft-ietf-dccp-tfrc-faster-restart-05.txt:
			* Updated application-limited behavior for Revised TFRC
			in Table 1, to reflect changes to rfc3448bis.
			* Updated description of code in rfc3448bis to reflect
			changes in that document.
	Changes from draft-ietf-dccp-tfrc-faster-restart-04.txt:		Changes from draft-ietf-dccp-tfrc-faster-restart-04.txt:
	* Changed "RTO" to "NFT".		* Changed "RTO" to "NFT".
	Changed the targeted idle period to the configurable DelayTime.		Changed the targeted idle period to the configurable DelayTime.
	Feedback from Gerrit Renker.		Feedback from Gerrit Renker.
	* Removed Section 4.1 on the receive rate, after it is made		* Removed Section 4.1 on the receive rate, after it is made
	into an Errata for RFC 4342. Feedback from Gerrit Renker.		into an Errata for RFC 4342. Feedback from Gerrit Renker.
	* General editing from Gorry Fairhurst and Arjuna, and additional		* General editing from Gorry Fairhurst and Arjuna, and additional
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 49 ¶
	receiver over the previous RTT. Thus in Standard TFRC the previous		receiver over the previous RTT. Thus in Standard TFRC the previous
	receive rate limits the sending rate of applications with highly		receive rate limits the sending rate of applications with highly
	variable sending rates, forcing the applications to ramp up, by		variable sending rates, forcing the applications to ramp up, by
	doubling their sending rate each round-trip time, from the earlier		doubling their sending rate each round-trip time, from the earlier
	data-limited rate to the sending rate allowed by the throughput		data-limited rate to the sending rate allowed by the throughput
	equation. TFRC's nofeedback timer halves the allowed sending rate		equation. TFRC's nofeedback timer halves the allowed sending rate
	after each nofeedback timer interval (at least four round-trip times)		after each nofeedback timer interval (at least four round-trip times)
	in which no feedback is received. One result is that applications		in which no feedback is received. One result is that applications
	must slow-start after being idle for any significant length of time,		must slow-start after being idle for any significant length of time,
	in the absence of mechanisms such as Quick-Start [RFC4782] and Quick-		in the absence of mechanisms such as Quick-Start [RFC4782] and Quick-
	Start for DCCP [GA07].		Start for DCCP [GA08].
	For Revised TFRC as specified in [RFC3448bis], the previous receive		For Revised TFRC as specified in [RFC3448bis], the previous receive
	rate is not used to limit the sending rate during data-limited		rate is not used to limit the sending rate during data-limited
	periods. Thus, unlike [RFC3448], in [RFC3448bis] applications with		periods. Thus, unlike [RFC3448], in [RFC3448bis] applications with
	highly variable sending rates are not limited by the previous receive		highly variable sending rates are not limited by the previous receive
	rates. However, [RFC3448bis] is like [RFC3448] in that the		rates. However, [RFC3448bis] is like [RFC3448] in that the
	nofeedback timer is used to halve the allowed sending rate after each		nofeedback timer is used to halve the allowed sending rate after each
	nofeedback timer interval in which no feedback is received. With		nofeedback timer interval in which no feedback is received. With
	[RFC3448] the allowed sending rate is not reduced below two packets		[RFC3448] the allowed sending rate is not reduced below two packets
	per RTT during idle periods, and with [RFC3448bis] the allowed		per RTT during idle periods, and with [RFC3448bis] the allowed
	skipping to change at page 8, line 28 ¶		skipping to change at page 9, line 23 ¶
	As a result, at most double the sending rate each RTT.		As a result, at most double the sending rate each RTT.
	------------------------------------------------------------------		------------------------------------------------------------------
	------------------------------------------------------------------		------------------------------------------------------------------
	- Revised TFRC -		- Revised TFRC -
	------------------------------------------------------------------		------------------------------------------------------------------
	Idle period:		Idle period:
	Halve allowed sending rate each NFT, not below initial sending rate.		Halve allowed sending rate each NFT, not below initial sending rate.
	After sending again, double the sending rate each RTT.		After sending again, double the sending rate each RTT.
	Application-limited period:		Application-limited period:
	Sending rate not limited by X_recv.		If no loss, send at most twice max (X_recv_set), including old values
			of X_recv going back to just before the data-limited interval was
			entered.
			If loss, reduce saved values of X_recv.
	------------------------------------------------------------------		------------------------------------------------------------------
	------------------------------------------------------------------		------------------------------------------------------------------
	- Revised TFRC with Faster Restart -		- Revised TFRC with Faster Restart -
	------------------------------------------------------------------		------------------------------------------------------------------
	Idle period:		Idle period:
	Halve allowed sending rate each NFT, not below twice initial rate.		Halve allowed sending rate each NFT, not below twice initial rate.
	(Specified in Section 3.2.)		(Specified in Section 3.2.)
	After sending again, quadruple the sending rate towards old rate.		After sending again, quadruple the sending rate towards old rate.
	(Specified in Section 3.1.)		(Specified in Section 3.1.)
	skipping to change at page 10, line 28 ¶		skipping to change at page 11, line 27 ¶
	The rate at which the sender should stop quadrupling its sending		The rate at which the sender should stop quadrupling its sending
	rate, and return to at most doubling its sending rate.		rate, and return to at most doubling its sending rate.
	Other variables have values as described in [RFC3448] and		Other variables have values as described in [RFC3448] and
	[RFC3448bis].		[RFC3448bis].
	3. Faster Restart: Changes to TFRC		3. Faster Restart: Changes to TFRC
	3.1. Feedback Packets		3.1. Feedback Packets
	The Faster Restart algorithm replaces the line:		The Faster Restart algorithm replaces the lines in step (4) of
			Section 4.3, "Sender Behavior When a Feedback Packet is Received", of
	recv_limit = 2 * max (X_recv_set);		[RFC3448bis] that specify the limitation on the sending rate
			calculated from the reported receive rates. [RFC3448bis] allows the
	in step (4) of Section 4.3, "Sender Behavior When a Feedback Packet		sender to slow-start back up to the previous sending rate after an
	is Received", of [RFC3448bis]. This line specifies the limitation on		idle period, doubling its sending rate after each round-trip time.
	the sending rate calculated based on the recent receive rate, and in
	[RFC3448bis] allows the sender to slow-start back up to the previous
	sending rate after an idle period, doubling its sending rate after
	each round-trip time.
	This document replaces the line above so that during recovery from an		This document specifies a mechanism so that during recovery from an
	idle period, the TFRC sender can quadruple its sending rate each		idle period, the TFRC sender can quadruple its sending rate each
	(congestion-free) round-trip time, until it reaches its old sending		(congestion-free) round-trip time, until it reaches its old sending
	rate before the idle period. This modification uses three new		rate before the idle or data-limited period. This modification uses
	variables: X_active_recv specifies the maximum receive rate achieved		three new variables: X_active_recv specifies the maximum receive rate
	before the idle period, T_active_recv specifies the time of the last		achieved before the idle period, T_active_recv specifies the time of
	update of X_active_recv, and X_fast_max specifies the adjusted rate		the last update of X_active_recv, and X_fast_max specifies the
	at which the sender should stop quadrupling its sending rate and		adjusted rate at which the sender should stop quadrupling its sending
	continue to its default behavior of doubling its sending rate.		rate and continue to its default behavior of doubling its sending
			rate.
	The procedure "Update X_active_recv and X_fast_max" below increases		The procedure "Update X_active_recv and X_fast_max" below increases
	the two variables in response to increases in the reported receive		the two variables in response to increases in the reported receive
	rate and reduces them after a report of a lost packet or an		rate and reduces them after a report of a lost packet or an
	indication of congestion (e.g. an ECN-marked packet).		indication of congestion (e.g. an ECN-marked packet).
	Update X_active_recv and X_fast_max:		Update X_active_recv and X_fast_max:
	If (the feedback packet does not indicate a loss or mark,		If (the feedback packet does not indicate a loss or mark,
	and X_recv >= X_fast_max)		and X_recv >= X_fast_max)
	X_active_recv = X_fast_max = X_recv,		X_active_recv = X_fast_max = X_recv,
	skipping to change at page 12, line 38 ¶		skipping to change at page 13, line 37 ¶
	// set X_fast_max to X_active_recv;		// set X_fast_max to X_active_recv;
	// If achieved X_active_recv >= 3 minutes ago,		// If achieved X_active_recv >= 3 minutes ago,
	// set X_fast_max to zero;		// set X_fast_max to zero;
	// If in between, interpolate.		// If in between, interpolate.
	delta_T = now - T_active_recv;		delta_T = now - T_active_recv;
	F = (6 min - min(max(delta_T, 2 min), 6 min)) / (2 min);		F = (6 min - min(max(delta_T, 2 min), 6 min)) / (2 min);
	X_fast_max = F * X_active_recv;		X_fast_max = F * X_active_recv;
	The pseudocode above uses the temporary variables delta_T and F.		The pseudocode above uses the temporary variables delta_T and F.
	Faster Restart replaces the following line from step (4) of Section		Faster Restart replaces the following lines from step (4) of Section
	4.3 of [RFC3448bis]:		4.3 of [RFC3448bis]:
	recv_limit = 2 * max (X_recv_set);		If (the entire interval covered by the feedback packet
			was a data-limited interval) {
			If (the feedback packet reports a new loss event or an
			increase in the loss event rate p) {
			Halve entries in X_recv_set;
			X_recv = 0.85 * X_recv;
			Maximize X_recv_set();
			recv_limit = max (X_recv_set);
			} Else {
			Maximize X_recv_set();
			recv_limit = 2 * max (X_recv_set);
			}
			} Else { // typical behavior
			Update X_recv_set();
			recv_limit = 2 * max (X_recv_set);
			}
	with the following:		with the following:
	Interpolate X_fast_max;		Interpolate X_fast_max;
	Update X_active_recv and X_fast_max;		Update X_active_recv and X_fast_max;
	recv_limit = 2 * max (X_recv_set);		If (the entire interval covered by the feedback packet
	If (recv_limit < X_fast_max)		was a data-limited interval) {
	recv_limit = min(2*recv_limit, X_fast_max);		If (the feedback packet reports a new loss event or an
			increase in the loss event rate p) {
			Halve entries in X_recv_set;
			X_recv = 0.85 * X_recv;
			Maximize X_recv_set();
			recv_limit = max (X_recv_set);
			} Else {
			Maximize X_recv_set();
			recv_limit = 2 * max (X_recv_set);
			If (recv_limit < X_fast_max)
			recv_limit = min (2*recv_limit, X_fast_max);
			}
			} Else { // typical behavior
			Update X_recv_set();
			recv_limit = 2 * max (X_recv_set);
			If (recv_limit < X_fast_max)
			recv_limit = min (2*recv_limit, X_fast_max);
			}
	In summary, when a feedback packet is received, as specified in		In summary, when a feedback packet is received, as specified in
	[RFC3448bis], then the sender updates the round-trip time estimate		[RFC3448bis], then the sender updates the round-trip time estimate
	and the NFT (NoFeedback Timer), and updates X_recv_set, the set of		and the NFT (NoFeedback Timer), and updates X_recv_set, the set of
	recent X_recv values, and then executes the procedure above.		recent X_recv values, and then executes the procedure above.
	X_fast_max always represents the interpolated value from highest		X_fast_max always represents the interpolated value from highest
	X_recv reported since the last loss event. However, because		X_recv reported since the last loss event. However, because
	X_recv_set contains only X_recv values from the most recent two		X_recv_set contains only X_recv values from the most recent two
	round-trip times, the calculated recv_limit could be less than		round-trip times, the calculated recv_limit could be less than
	X_fast_max. In this case, recv_limit is doubled, up to at most		X_fast_max. In this case, recv_limit is doubled, up to at most
	X_fast_max. Faster Restart's doubling of recv_limit allows the TFRC		X_fast_max. Faster Restart's doubling of recv_limit allows the TFRC
	sender to quadruple its sending rate each round-trip time after an		sender to quadruple its sending rate each round-trip time after an
	skipping to change at page 16, line 50 ¶		skipping to change at page 18, line 45 ¶
	2. Fairness within Faster Restart: The simulation tests examine how		2. Fairness within Faster Restart: The simulation tests examine how
	multiple competing Faster Restart flows share the available		multiple competing Faster Restart flows share the available
	capacity among them.		capacity among them.
	3. Response to transient events: The simulation tests examine how a		3. Response to transient events: The simulation tests examine how a
	Faster Restart flow reacts to a sudden congestion event.		Faster Restart flow reacts to a sudden congestion event.
	4. Behavior in a range of environments: Tests assess a range of		4. Behavior in a range of environments: Tests assess a range of
	bandwidths, RTTs, and varying idle periods.		bandwidths, RTTs, and varying idle periods.
	A set of initial simulation results are described in [S07]. We note		A set of initial simulation results will be described in [S08]. We
	some of the important results here.		note some of the important results here.
	o Faster Restart does improve the performance of a flow after an		o Faster Restart does improve the performance of a flow after an
	idle period by faster restarting when compared to TFRC. The		idle period by faster restarting when compared to TFRC. The
	results indicate that the worst case packet delay distribution is		results indicate that the worst case packet delay distribution is
	small for Faster Restart than for TFRC.		small for Faster Restart than for TFRC.
	o The effect of Faster Restart restarting after an idle period seems		o The effect of Faster Restart restarting after an idle period seems
	to have an effect on other competing flows only when the Faster		to have an effect on other competing flows only when the Faster
	Restart flow has a high sending rate before it enters the idle		Restart flow has a high sending rate before it enters the idle
	period.		period.
	skipping to change at page 18, line 8 ¶		skipping to change at page 19, line 51 ¶
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer,		[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer,
	"TCP Friendly Rate Control (TFRC): Protocol		"TCP Friendly Rate Control (TFRC): Protocol
	Specification", RFC 3448, Proposed Standard, January		Specification", RFC 3448, Proposed Standard, January
	2003.		2003.
	[RFC3448bis] Handley, M., Floyd, S., Padhye, J., and J. Widmer,		[RFC3448bis] Handley, M., Floyd, S., Padhye, J., and J. Widmer,
	"TCP Friendly Rate Control (TFRC): Protocol		"TCP Friendly Rate Control (TFRC): Protocol
	Specification", internet draft draft-ietf-dccp-		Specification", internet draft draft-ietf-dccp-
	rfc3448bis-02.txt, work-in-progress, July 2007.		rfc3448bis-06.txt, work-in-progress, April 2008.
	[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram		[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
	Congestion Control Protocol (DCCP)", RFC 4340, March		Congestion Control Protocol (DCCP)", RFC 4340, March
	2006.		2006.
	[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for		[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
	Datagram Congestion Control Protocol (DCCP) Congestion		Datagram Congestion Control Protocol (DCCP) Congestion
	Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC		Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC
	4342, March 2006.		4342, March 2006.
	Informative References		Informative References
	[CCID4] Floyd, S., and E. Kohler, "Profile for Datagram		[CCID4] Floyd, S., and E. Kohler, "Profile for Datagram
	Congestion Control Protocol (DCCP) Congestion ID 4:		Congestion Control Protocol (DCCP) Congestion ID 4:
	TCP-Friendly Rate Control for Small Packets (TFRC-		TCP-Friendly Rate Control for Small Packets (TFRC-
	SP)", Internet-Draft draft-ietf-dccp-ccid4-00.txt,		SP)", Internet-Draft draft-ietf-dccp-ccid4-02.txt,
	work in progress, October 2007.		work in progress, February 2008.
	[GA07] "Quick-Start for the Datagram Congestion Control		[GA08] "Quick-Start for the Datagram Congestion Control
	Protocol (DCCP)", Internet-Draft draft-fairhurst-		Protocol (DCCP)", Internet-Draft draft-fairhurst-
	tsvwg-dccp-qs-02.txt, work in progress, November 2007.		tsvwg-dccp-qs-03.txt, work in progress, June 2008.
	[JS00] W. Jiang and H. Schulzrinne, Analysis of On-Off		[JS00] W. Jiang and H. Schulzrinne, Analysis of On-Off
	Patterns in VoIP and Their Effect on Voice Traffic		Patterns in VoIP and Their Effect on Voice Traffic
	Aggregation, Proceedings of the Ninth Conference on		Aggregation, Proceedings of the Ninth Conference on
	Computer Communications and Networks (ICCCN), October		Computer Communications and Networks (ICCCN), October
	2000.		2000.
	[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP		[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP
	Congestion Control", RFC 2581, April 1999.		Congestion Control", RFC 2581, April 1999.
	skipping to change at page 19, line 12 ¶		skipping to change at page 21, line 9 ¶
	[RFC4342Errat] RFC Errata for RFC 4342, URL "http://www.rfc-		[RFC4342Errat] RFC Errata for RFC 4342, URL "http://www.rfc-
	editor.org/errata.php".		editor.org/errata.php".
	[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti,		[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti,
	"Quick-Start for TCP and IP", RFC 4782, June 2006.		"Quick-Start for TCP and IP", RFC 4782, June 2006.
	[RFC4828] Floyd, S., and E. Kohler, "TCP Friendly Rate Control		[RFC4828] Floyd, S., and E. Kohler, "TCP Friendly Rate Control
	(TFRC): the Small-Packet (SP) Variant", RFC 4828,		(TFRC): the Small-Packet (SP) Variant", RFC 4828,
	April 2007.		April 2007.
	[S07] Sathiaseelan, A., Faster Restart - Analysis, URL		[S08] Sathiaseelan, A., Faster Restart - Analysis, URL
	www.erg.abdn.ac.uk/users/arjuna/faster-restart.pdf.		www.erg.abdn.ac.uk/users/arjuna/faster-restart.pdf, to
			appear.
	A. Appendix: Simulations		A. Appendix: Simulations
	This appendix describes a set of initial test case scenarios for		This appendix describes a set of initial test case scenarios for
	simulation analysis of Faster Restart. The simulation results were		simulation analysis of Faster Restart. The simulation results use
	performed using the ns-2 simulator. The topology is the classic		the ns-2 simulator.
	dumb-bell topology used in many simulations of TCP. The bottleneck
	capacity was set to 6 Mbps. We considered various link delays. The
	bottleneck queue was set to the bandwidth delay product for all the
	simulations. The results presented here were based on an average of
	20 simulation runs.
	Several types of flows are considered:		Several types of flows are considered:
	o Bulk TCP Flows.		o Bulk TCP Flows.
	o Interactive (short) TCP Flows.		o Interactive (short) TCP Flows.
	o TFRC Flows with and without Faster Restart.		o TFRC Flows with and without Faster Restart.
	o TFRC-SP Flows with and without Faster Restart.		o TFRC-SP Flows with and without Faster Restart.
	skipping to change at page 19, line 49 ¶		skipping to change at page 21, line 42 ¶
	For these simulations, we consider two application rates.		For these simulations, we consider two application rates.
	o Small media flows: These have a similar rate to voice over IP		o Small media flows: These have a similar rate to voice over IP
	with a media bit rate of 64 Kbps (using segments of 160 bytes and		with a media bit rate of 64 Kbps (using segments of 160 bytes and
	a nominal transmit rate of 8 KBps).		a nominal transmit rate of 8 KBps).
	o Large media flows: These have a similar rate to medium quality		o Large media flows: These have a similar rate to medium quality
	video over IP with a media bit rate of 512 Kbps (using segments of		video over IP with a media bit rate of 512 Kbps (using segments of
	size 1000 bytes and a nominal transmit rate of 64 KBps).		size 1000 bytes and a nominal transmit rate of 64 KBps).
	The transmit buffer was set to zero packets unless otherwise noted.		The simulations will model the effect of an idle period in which the
	This means there would no buffering between the application and the
	transport protocol.
	The simulations model the effect of an idle period in which the
	application does not attempt to send any data for a period of time,		application does not attempt to send any data for a period of time,
	then resumes transmission. Various idle times are considered in the		then resumes transmission. Various idle times are considered.
	simulation experiments.
	The simulation scenarios include the following. These are intended		The simulation scenarios include the following. These are intended
	to be illustrative, rather than exact models of the application		to be illustrative, rather than exact models of the application
	behavior.		behavior.
	o Performance of a long-lived (bulk) TCP flow (e.g. FTP) with TFRC		o Performance of a long-lived (bulk) TCP flow (e.g. FTP) with TFRC
	flows (with and without Faster Restart): The test scenario would		flows (with and without Faster Restart): The test scenario would
	involve a single large FTP flow with varying number of large media		involve a single large FTP flow with varying number of large media
	flows. Each large media flow becomes idle for one second and then		flows. Each large media flow becomes idle for one second and then
	restarts. The FTP flow starts during the idle period. The		restarts. The FTP flow starts during the idle period. The
End of changes. 26 change blocks.
	73 lines changed or deleted		103 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/