draft-ietf-tcpm-tcp-uto-05.txt		draft-ietf-tcpm-tcp-uto-06.txt
	TCP Maintenance and Minor L. Eggert		TCP Maintenance and Minor L. Eggert
	Extensions (tcpm) Nokia		Extensions (tcpm) Nokia
	Internet-Draft F. Gont		Internet-Draft F. Gont
	Intended status: Standards Track UTN/FRH		Intended status: Standards Track UTN/FRH
	Expires: September 6, 2007 March 5, 2007		Expires: December 13, 2007 June 11, 2007
	TCP User Timeout Option		TCP User Timeout Option
	draft-ietf-tcpm-tcp-uto-05		draft-ietf-tcpm-tcp-uto-06
	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 35		skipping to change at page 1, line 35
	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 September 6, 2007.		This Internet-Draft will expire on December 13, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The TCP user timeout controls how long transmitted data may remain		The TCP user timeout controls how long transmitted data may remain
	unacknowledged before a connection is forcefully closed. It is a		unacknowledged before a connection is forcefully closed. It is a
	local, per-connection parameter. This document specifies a new TCP		local, per-connection parameter. This document specifies a new TCP
	option - the TCP User Timeout Option - that allows one end of a TCP		option - the TCP User Timeout Option - that allows one end of a TCP
	connection to advertise its current user timeout value. This		connection to advertise its current user timeout value. This
	information allows the other end to adapt its user timeout		information provides advice to the other end to adapt its user
	accordingly. Increasing the user timeouts on both ends of a TCP		timeout accordingly. Increasing the user timeouts on both ends of a
	connection allows it to survive extended periods without end-to-end		TCP connection allows it to survive extended periods without end-to-
	connectivity. Decreasing the user timeouts allows busy servers to		end connectivity. Decreasing the user timeouts allows busy servers
	explicitly notify their clients that they will maintain the		to explicitly notify their clients that they will maintain the
	connection state only for a short time without connectivity.		connection state only for a short time without connectivity.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6		3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6
	3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8		3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8
	3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8		3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8
	3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 9		3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 9
	4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 9		4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10
	4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10		4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
	Appendix A. Document Revision History . . . . . . . . . . . . . . 13		Appendix A. Document Revision History . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 16		Intellectual Property and Copyright Statements . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The Transmission Control Protocol (TCP) specification [RFC0793]		The Transmission Control Protocol (TCP) specification [RFC0793]
	defines a local, per-connection "user timeout" parameter that		defines a local, per-connection "user timeout" parameter that
	specifies the maximum amount of time that transmitted data may remain		specifies the maximum amount of time that transmitted data may remain
	unacknowledged before TCP will forcefully close the corresponding		unacknowledged before TCP will forcefully close the corresponding
	connection. Applications can set and change this parameter with OPEN		connection. Applications can set and change this parameter with OPEN
	and SEND calls. If an end-to-end connectivity disruption lasts		and SEND calls. If an end-to-end connectivity disruption lasts
	skipping to change at page 4, line 12		skipping to change at page 4, line 12
	based on past mobility patterns and thus benefit from using longer		based on past mobility patterns and thus benefit from using longer
	user timeouts. In other scenarios, the time and duration of a		user timeouts. In other scenarios, the time and duration of a
	connectivity disruption may even be predictable. For example, an		connectivity disruption may even be predictable. For example, an
	orbiting node on a non-geostationary satellite might experience		orbiting node on a non-geostationary satellite might experience
	connectivity disruptions due to line-of-sight blocking by other		connectivity disruptions due to line-of-sight blocking by other
	planetary bodies. The timing of these events may be computable from		planetary bodies. The timing of these events may be computable from
	orbital mechanics.		orbital mechanics.
	This document specifies a new TCP option - the TCP User Timeout		This document specifies a new TCP option - the TCP User Timeout
	Option - that allows one end of a TCP connection to advertise its		Option - that allows one end of a TCP connection to advertise its
	current user timeout value. This information allows the other end to		current user timeout value. This information provides advice to the
	adapt its user timeout accordingly. Increasing the user timeouts on		other end of the connection to adapt its user timeout accordingly.
	both ends of a TCP connection allows it to survive extended periods		That is, TCP remains free to disregard the advice provided by the UTO
	without end-to-end connectivity. Decreasing the user timeouts allows		option if local policies suggest it to be appropriate.
	busy servers to explicitly notify their clients that they will
	maintain the connection state only for a short time without		Increasing the user timeouts on both ends of a TCP connection allows
	connectivity.		it to survive extended periods without end-to-end connectivity.
			Decreasing the user timeouts allows busy servers to explicitly notify
			their clients that they will maintain the connection state only for a
			short time without connectivity.
	2. Conventions		2. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Operation		3. Operation
	Use of the TCP User Timeout Option can be enabled either on a per-		Use of the TCP User Timeout Option can be enabled either on a per-
	application basis, e.g., through a socket option, or controlled by a		application basis, e.g., through a socket option, or controlled by a
	system-wide setting. TCP maintains three per-connection state		system-wide setting. TCP maintains four per-connection state
	variables to control the operation of UTO options, two of which		variables to control the operation of the UTO option, three of which
	(ENABLED and CHANGEABLE) are new:		(LOCAL_UTO, ENABLED and CHANGEABLE) are new:
	ENABLED (Boolean)		USER_TIMEOUT
	Flag that controls whether UTO options are enabled for a		TCP's USER TIMEOUT parameter, as specified in [RFC0793].
	connection. Defaults to false.
	LOCAL_UTO		LOCAL_UTO
	Local user timeout in effect for this connection. This is either		UTO option advertised to the remote TCP peer. This is an
	the system-wide default or an application-specified value.		application-specified value, and may be specified on a system-wide
	Defaults to the system-wide default.		basis. If unspecified, it default to the default system-wide USER
			TIMEOUT.
			ENABLED (Boolean)
			Flag that controls whether the UTO option is enabled for a
			connection. Defaults to false.
	CHANGEABLE (Boolean)		CHANGEABLE (Boolean)
	Flag that controls whether the local user timeout may be changed		Flag that controls whether USER_TIMEOUT (TCP's USER_TIMEOUT
	based on UTO options received from the other end. Defaults to		parameter) may be changed based on an UTO option received from the
	true and becomes false when an application explicitly sets		other end. Defaults to true and becomes false when an application
	LOCAL_UTO.		explicitly sets USER_TIMEOUT.
	Note that an exchange of UTO options between both ends of a		Note that an exchange of UTO options between both ends of a
	connection is not a binding negotiation. Transmission of a UTO		connection is not a binding negotiation. Transmission of a UTO
	option is a suggestion that the other end consider adapting its user		option is a suggestion that the other end consider adapting its user
	timeout. This adaptation only happens if the the other end has		timeout. This adaptation only happens if the the other end has
	explicitly enabled it (CHANGEABLE is true).		explicitly allowed it (both ENABLED and CHANGEABLE are true).
	Before opening a connection, an application that wishes to use UTO		Before opening a connection, an application that wishes to use the
	options SHOULD enable their use by setting ENABLED to true. It MAY		UTO option SHOULD enable its use by setting ENABLED to true. It MAY
	pick an appropriate local UTO by setting LOCAL_UTO, which is		pick an appropriate local UTO by setting LOCAL_UTO, which is
	otherwise set to the system default. Finally, the application should		otherwise set to the default USER TIMEOUT value. Finally, the
	determine whether it will allow the local UTO to change based on		application should determine whether it will allow the local USER
	received UTO options from the other end. The default is to allow		TIMEOUT to change based on received UTO options from the other end.
	this for connections that do not have a specific user timeout		The default is to allow this for connections that do not have a
	concerns, i.e., connections that operate with the default LOCAL_UTO.		specific user timeout concerns. If an application explicitly sets
	If an application explicitly sets LOCAL_UTO, CHANGEABLE MUST become		the USER TIMEOUT, CHANGEABLE MUST become false, to prevent UTO
	false, to prevent UTO options from the other end to override local		options from the other end to override local application requests.
	application requests. Alternatively, applications MAY set or clear		Alternatively, applications MAY set or clear CHANGEABLE directly.
	CHANGEABLE directly.
	Performing these steps before an active or passive open causes UTO		Performing these steps before an active or passive open causes UTO
	options to be exchanged in the SYN and SYN-ACK packets and is a		options to be exchanged in the SYN and SYN-ACK packets and is a
	reliable way to initially exchange and potentially adapt to UTO		reliable way to initially exchange and potentially adapt to UTO
	values. Systems MAY provide system-wide default settings for the		values. Systems MAY provide system-wide default settings for the
	ENABLED, LOCAL_UTO and CHANGEABLE connection parameters when		ENABLED, LOCAL_UTO and CHANGEABLE connection parameters.
	applications do not initialize them themselves.
	In addition to exchanging UTO options in the SYN segments, a		In addition to exchanging UTO options in the SYN segments, a
	connection that has enabled UTO options SHOULD include a UTO option		connection that has enabled UTO options SHOULD include a UTO option
	in the first packet that does not have the SYN flag set. This helps		in the first packet that does not have the SYN flag set. This helps
	to minimize the amount of state information TCP must keep for		to minimize the amount of state information TCP must keep for
	connections in non-synchronized states, and is particularly useful		connections in non-synchronized states, and is particularly useful
	when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are		when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are
	implemented, allowing a newly-established TCP connection to benefit		implemented, allowing a newly-established TCP connection to benefit
	from the information advertised by the UTO option, even if the UTO		from the information advertised by the UTO option, even if the UTO
	contained in the initial SYN segment was not recorded.		contained in the initial SYN segment was not recorded.
	A host that supports UTO options SHOULD include it in the next		A host that supports the UTO option SHOULD include one in the next
	possible outgoing segment whenever it starts using a new user timeout		possible outgoing segment whenever it starts using a new user timeout
	for the connection. This allows the other end to adapt its local		for the connection. This allows the other end to adapt its local
	user timeout for the connection accordingly.		user timeout for the connection accordingly. A TCP implementation
			that does not support the UTO option MUST silently ignore it
	A TCP implementation that does not support UTO options MUST silently		[RFC1122], thus ensuring interoperability.
	ignore them [RFC1122], thus ensuring interoperability.
	Hosts MUST impose upper and lower limits on the user timeouts they		Hosts MUST impose upper and lower limits on the user timeouts they
	use for a connection. Section 3.1 discusses user timeout limits and		use for a connection. Section 3.1 discusses user timeout limits and
	discusses potentially problematic effects of user timeout settings.		discusses potentially problematic effects of some user timeout
			settings.
			Finally, it is worth noting that TCP's option space is limited to 40
			bytes. As a result, if other TCP options are in use, they may
			already consume all the available TCP option space, thus preventing
			the use of the UTO option specified in this document. Therefore, TCP
			option space issues should be considered before enabling the UTO
			option.
	3.1. Changing the Local User Timeout		3.1. Changing the Local User Timeout
	When a host receives a TCP User Timeout Option, it must decide		When a host receives a TCP User Timeout Option, it must decide
	whether to change the local user timeout of the corresponding		whether to change the local user timeout of the corresponding
	connection. If the CHANGEABLE flag is false, LOCAL_UTO MUST NOT be		connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT
	changed, regardless of the received UTO option. Without this		be changed, regardless of the received UTO option. Without this
	restriction, UTO would modify TCP semantics, because application-		restriction, the UTO option would modify TCP semantics, because an
	requested UTOs could be overridden by peer requests. In this case,		application-requested USER TIMEOUT could be overridden by peer
	they SHOULD, however, notify the application about the user timeout		requests. In this case, they SHOULD, however, notify the application
	value received from the other end.		about the user timeout value received from the other end.
	In general, unless the application on the local host has requested a		In general, unless the application on the local host has requested a
	specific LOCAL_UTO for the connection, CHANGEABLE will be true and		specific USER TIMEOUT for the connection, CHANGEABLE will be true and
	hosts SHOULD adjust the local user timeout in response to receiving a		hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in
	UTO option, as described in the remainder of this section.		response to receiving a UTO option, as described in the remainder of
			this section.
	The UTO option specifies the user timeout in in seconds or minutes,		The UTO option specifies the user timeout in seconds or minutes,
	rather than in number of retransmissions or round-trip times (RTTs).		rather than in number of retransmissions or round-trip times (RTTs).
	Thus, the UTO option allows hosts to exchange user timeout values		Thus, the UTO option allows hosts to exchange user timeout values
	from 1 second to over 9 hours at a granularity of seconds, and from 1		from 1 second to over 9 hours at a granularity of seconds, and from 1
	minute to over 22 days at a granularity of minutes.		minute to over 22 days at a granularity of minutes.
	Very short user timeout values can affect TCP transmissions over		Very short USER TIMEOUT values can affect TCP transmissions over
	high-delay paths. If the user timeout occurs before an		high-delay paths. If the user timeout occurs before an
	acknowledgment for an outstanding segment arrives, possibly due to		acknowledgment for an outstanding segment arrives, possibly due to
	packet loss, the connection closes. Many TCP implementations default		packet loss, the connection closes. Many TCP implementations default
	to user timeout values of a few minutes. Although the UTO option		to USER TIMEOUT values of a few minutes. Although the UTO option
	allows suggestion of short timeouts, applications advertising them		allows suggestion of short timeouts, applications advertising them
	should consider these effects.		should consider these effects.
	Long user timeout values allow hosts to tolerate extended periods		Long USER TIMEOUT values allow hosts to tolerate extended periods
	without end-to-end connectivity. However, they also require hosts to		without end-to-end connectivity. However, they also require hosts to
	maintain the TCP state information associated with connections for		maintain the TCP state information associated with connections for
	long periods of time. Section 5 discusses the security implications		long periods of time. Section 5 discusses the security implications
	of long timeout values.		of long timeout values.
	To protect against these effects, implementations MUST impose limits		To protect against these effects, implementations MUST impose limits
	on the user timeout values they accept and use. The remainder of		on the user timeout values they accept and use. The remainder of
	this section describes a RECOMMENDED scheme to limit user timeouts		this section describes a RECOMMENDED scheme to limit TCP's USER
	based on upper and lower limits.		TIMEOUT based on upper and lower limits.
	Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end		Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end
	SHOULD compute LOCAL_UTO for a connection according to this formula:		SHOULD compute the local USER TIMEOUT for a connection according to
			this formula:
	LOCAL_UTO = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))		USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))
	Each field is to be interpreted as follows:		Each field is to be interpreted as follows:
			USER_TIMEOUT
			USER TIMEOUT value to be adopted by the local TCP for this
			connection.
	U_LIMIT		U_LIMIT
	Current upper limit imposed on the user timeout of a connection by		Current upper limit imposed on the user timeout of a connection by
	the local host.		the local host.
	L_LIMIT		LOCAL_UTO
	Current lower limit imposed on the user timeout of a connection by		User timeout advertised to the remote TCP peer in a TCP User
	the local host.		Timeout Option.
	REMOTE_UTO		REMOTE_UTO
	Last "user timeout" value received from the other end in a TCP		Last "user timeout" value received from the other end in a TCP
	User Timeout Option.		User Timeout Option.
			L_LIMIT
			Current lower limit imposed on the user timeout of a connection by
			the local host.
	This means that, provided they are within the upper and lower limits,		This means that, provided they are within the upper and lower limits,
	the maximum of current LOCAL_UTO and the last user timeout value		the maximum of the two advertised values will be adopted for the user
	received from the other end will become the new LOCAL_UTO for the		timeout of the connection. The rationale is that choosing the
	connection. The rationale is that choosing the maximum of the two		maximum of the two values will let the connection survive longer
	values will let the connection survive longer periods without end-to-		periods without end-to-end connectivity. If the end that announced
	end connectivity. If the end that announced the lower of the two		the lower of the two user timeout values did so in order to reduce
	user timeout values did so in order to reduce the amount of TCP state		the amount of TCP state information that must be kept on the host, it
	information that must be kept on the host, it can, nevertheless,		can, nevertheless, close or abort the connection whenever it wants.
	close or abort the connection whenever it wants. [anchor3]
	It must be noted that the two endpoints of the connection will not		It must be noted that the two endpoints of the connection will not
	necessarily adopt the same user timeout.		necessarily adopt the same user timeout.
	Enforcing a lower limit (L_LIMIT) prevents connections from closing		Enforcing a lower limit (L_LIMIT) prevents connections from closing
	due to transient network conditions, including temporary congestion,		due to transient network conditions, including temporary congestion,
	mobility hand-offs and routing instabilities.		mobility hand-offs and routing instabilities.
	An upper limit (U_LIMIT) can reduce the effect of resource exhaustion		An upper limit (U_LIMIT) can reduce the effect of resource exhaustion
	attacks. Section 5 discusses the details of these attacks.		attacks. Section 5 discusses the details of these attacks.
	Note that these limits MAY be specified as system-wide constants or		Note that these limits MAY be specified as system-wide constants or
	at other granularities, such as on per-host, per-user or even per-		at other granularities, such as on per-host, per-user, per-outgoing-
	connection basis. Furthermore, these limits need not be static. For		interface or even per-connection basis. Furthermore, these limits
	example, they MAY be a function of system resource utilization or		need not be static. For example, they MAY be a function of system
	attack status and could be dynamically adapted.		resource utilization or attack status and could be dynamically
			adapted.
	The Host Requirements RFC [RFC1122] does not impose any limits on the		The Host Requirements RFC [RFC1122] does not impose any limits on the
	length of the user timeout. However, a time interval of at least 100		length of the user timeout. However, a time interval of at least 100
	seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT)		seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT)
	SHOULD be set to at least 100 seconds when following the RECOMMENDED		SHOULD be set to at least 100 seconds when following the RECOMMENDED
	scheme described in this section. Adopting a user timeout smaller		scheme described in this section. Adopting a user timeout smaller
	than the current retransmission timeout (RTO) for the connection		than the current retransmission timeout (RTO) for the connection
	would likely cause the connection to be aborted unnecessarily.		would likely cause the connection to be aborted unnecessarily.
	Therefore, the lower limit (L_LIMIT) MUST be larger than the current		Therefore, the lower limit (L_LIMIT) MUST be larger than the current
	retransmission timeout (RTO) for the connection. It is worth noting		retransmission timeout (RTO) for the connection. It is worth noting
	skipping to change at page 8, line 22		skipping to change at page 8, line 43
	When a segment that carries a UTO option is lost, the other end will		When a segment that carries a UTO option is lost, the other end will
	simply not have the opportunity to update its local UTO.		simply not have the opportunity to update its local UTO.
	Implementations MAY implement local mechanisms to improve delivery		Implementations MAY implement local mechanisms to improve delivery
	reliability, such as retransmitting a UTO option when they retransmit		reliability, such as retransmitting a UTO option when they retransmit
	a segment that originally carried it, or "attaching" the option to a		a segment that originally carried it, or "attaching" the option to a
	byte in the stream and retransmitting the option whenever that byte		byte in the stream and retransmitting the option whenever that byte
	or its ACK are retransmitted.		or its ACK are retransmitted.
	It is important to note that although these mechanisms can improve		It is important to note that although these mechanisms can improve
	transmission reliability for UTO options, they do not guarantee		transmission reliability for the UTO option, they do not guarantee
	delivery (a three-way handshake would be required for this).		delivery (a three-way handshake would be required for this).
	Consequently, implementations MUST NOT assume that UTO options are		Consequently, implementations MUST NOT assume that UTO options are
	transmitted reliably.		transmitted reliably.
	3.3. Option Format		3.3. Option Format
	Sending a TCP User Timeout Option informs the other end of the		Sending a TCP User Timeout Option informs the other end of the
	current local user timeout for the connection and suggests that the		current local user timeout for the connection and suggests that the
	other end adapt its user timeout accordingly. The user timeout value		other end adapt its user timeout accordingly. The user timeout value
	included in a UTO option contains the local user timeout (LOCAL_UTO)		included in a UTO option contains the LOCAL_UTO value, that is
	used during the synchronized states of a connection (ESTABLISHED,		expected to be adopted for the TCP's USER TIMEOUT parameter during
	FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK).		the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1,
	Connections in other states MUST use the default timeout values		FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other
	defined in [RFC0793] and [RFC1122].		states MUST use the default timeout values defined in [RFC0793] and
			[RFC1122].
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kind = X | Length = 4 |G| User Timeout |		| Kind = X | Length = 4 |G| User Timeout |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	(One tick mark represents one bit.)		(One tick mark represents one bit.)
	Figure 1: Format of the TCP User Timeout Option		Figure 1: Format of the TCP User Timeout Option
	skipping to change at page 9, line 20		skipping to change at page 9, line 39
	Length of the TCP option in octets [RFC0793]; its value MUST be 4.		Length of the TCP option in octets [RFC0793]; its value MUST be 4.
	Granularity (1 bit)		Granularity (1 bit)
	Granularity bit, indicating the granularity of the "User Timeout"		Granularity bit, indicating the granularity of the "User Timeout"
	field. When set (G = 1), the time interval in the "User Timeout"		field. When set (G = 1), the time interval in the "User Timeout"
	field MUST be interpreted as minutes. Otherwise (G = 0), the time		field MUST be interpreted as minutes. Otherwise (G = 0), the time
	interval in the "User Timeout" field MUST be interpreted as		interval in the "User Timeout" field MUST be interpreted as
	seconds.		seconds.
	User Timeout (15 bits)		User Timeout (15 bits)
	Specifies the user timeout (LOCAL_UTO) used for this connection.		Specifies the user timeout suggestion for this connection.. It
	It MUST be interpreted as a 15-bit unsigned integer. The		MUST be interpreted as a 15-bit unsigned integer. The granularity
	granularity of the timeout (minutes or seconds) depends on the "G"		of the timeout (minutes or seconds) depends on the "G" field.
	field.
	3.4. Reserved Option Values		3.4. Reserved Option Values
	An empty TCP User Timeout Option, i.e., one with a "User Timeout"		An TCP User Timeout Option with a "User Timeout" field of zero and a
	field of zero and a "Granularity" bit of either minutes (1) or		"Granularity" bit of either minutes (1) or seconds (0) is reserved
	seconds (0), is reserved for future use. TCP implementations MUST		for future use. TCP implementations MUST NOT send it and MUST ignore
	NOT send it and MUST ignore it upon reception.		it upon reception.
	4. Interoperability Issues		4. Interoperability Issues
	This section discusses interoperability issues related to introducing		This section discusses interoperability issues related to introducing
	the TCP User Timeout Option.		the TCP User Timeout Option.
	4.1. Middleboxes		4.1. Middleboxes
	A TCP implementation that does not support the TCP User Timeout		A TCP implementation that does not support the TCP User Timeout
	Option MUST silently ignore it [RFC1122], thus ensuring		Option MUST silently ignore it [RFC1122], thus ensuring
	skipping to change at page 10, line 5		skipping to change at page 10, line 25
	transport protocols, Medina et al. have shown that the vast majority		transport protocols, Medina et al. have shown that the vast majority
	of modern TCP stacks correctly handle unknown TCP options [MEDINA].		of modern TCP stacks correctly handle unknown TCP options [MEDINA].
	In this study, 3% of connections failed when an unknown TCP option		In this study, 3% of connections failed when an unknown TCP option
	appeared in the middle of a connection. Because the number of		appeared in the middle of a connection. Because the number of
	failures caused by unknown options is small and they are a result of		failures caused by unknown options is small and they are a result of
	incorrectly implemented TCP stacks that violate existing requirements		incorrectly implemented TCP stacks that violate existing requirements
	to ignore unknown options, they do not warrant special measures.		to ignore unknown options, they do not warrant special measures.
	Thus, this document does not define a mechanism to negotiate support		Thus, this document does not define a mechanism to negotiate support
	of the TCP User Timeout Option during the three-way handshake.		of the TCP User Timeout Option during the three-way handshake.
	Stateful firewalls usually reset connections after a period of		Stateful firewalls usually time out connection state after a period
	inactivity. If such a firewall exists along the path, it may close		of inactivity. If such a firewall exists along the path, it may
	or abort connections regardless of the use of the TCP User Timeout		close or abort connections regardless of the use of the TCP User
	Option. In the future, such firewalls may learn to parse the TCP		Timeout Option. In the future, such firewalls may learn to parse the
	User Timeout Option and modify their behavior - or the option		TCP User Timeout Option and adapt connection state management
	contents - accordingly.		accordingly.
	4.2. TCP Keep-Alives		4.2. TCP Keep-Alives
	Some TCP implementations, such as those in BSD systems, use a		Some TCP implementations, such as those in BSD systems, use a
	different abort policy for TCP keep-alives than for user data. Thus,		different abort policy for TCP keep-alives than for user data. Thus,
	the TCP keep-alive mechanism might abort a connection that would		the TCP keep-alive mechanism might abort a connection that would
	otherwise have survived the transient period without connectivity.		otherwise have survived the transient period without connectivity.
	Therefore, if a connection enables keep-alives that is also using the		Therefore, if a connection enables keep-alives that is also using the
	TCP User Timeout Option, then the keep-alive timer MUST be set to a		TCP User Timeout Option, then the keep-alive timer MUST be set to a
	value larger than that of the adopted USER TIMEOUT.		value larger than that of the adopted USER TIMEOUT.
	skipping to change at page 12, line 4		skipping to change at page 12, line 21
	This document does not define any new namespaces. It uses an 8-bit		This document does not define any new namespaces. It uses an 8-bit
	TCP option number maintained by IANA at		TCP option number maintained by IANA at
	http://www.iana.org/assignments/tcp-parameters.		http://www.iana.org/assignments/tcp-parameters.
	7. Acknowledgments		7. Acknowledgments
	The following people have improved this document through thoughtful		The following people have improved this document through thoughtful
	suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,		suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,
	Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted		Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted
	Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris,		Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris,
	Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Mahdavi, Kostas		Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid
	Pentikousis, Juergen Quittek, Joe Touch, Stefan Schmid, Simon		Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe
	Schuetz, Tim Shepard and Martin Stiemerling.		Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and Martin
			Stiemerling.
	Lars Eggert is partly funded by Ambient Networks, a research project		Lars Eggert has been partly funded by Ambient Networks, a research
	supported by the European Commission under its Sixth Framework		project supported by the European Commission under its Sixth
	Program. The views and conclusions contained herein are those of the		Framework Program.
	authors and should not be interpreted as necessarily representing the
	official policies or endorsements, either expressed or implied, of
	the Ambient Networks project or the European Commission.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, September 1981.		RFC 793, September 1981.
	[RFC1122] Braden, R., "Requirements for Internet Hosts -		[RFC1122] Braden, R., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122, October 1989.		Communication Layers", STD 3, RFC 1122, October 1989.
	skipping to change at page 12, line 40		skipping to change at page 13, line 13
	October 1998.		October 1998.
	8.2. Informative References		8.2. Informative References
	[I-D.eddy-tcp-mobility]		[I-D.eddy-tcp-mobility]
	Eddy, W., "Mobility Support For TCP",		Eddy, W., "Mobility Support For TCP",
	draft-eddy-tcp-mobility-00 (work in progress), April 2004.		draft-eddy-tcp-mobility-00 (work in progress), April 2004.
	[I-D.ietf-tcpm-syn-flood]		[I-D.ietf-tcpm-syn-flood]
	Eddy, W., "TCP SYN Flooding Attacks and Common		Eddy, W., "TCP SYN Flooding Attacks and Common
	Mitigations", draft-ietf-tcpm-syn-flood-01 (work in		Mitigations", draft-ietf-tcpm-syn-flood-05 (work in
	progress), December 2006.		progress), May 2007.
	[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring		[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring
	Interactions Between Transport Protocols and Middleboxes",		Interactions Between Transport Protocols and Middleboxes",
	Proc. 4th ACM SIGCOMM/USENIX Conference on Internet		Proc. 4th ACM SIGCOMM/USENIX Conference on Internet
	Measurement , October 2004.		Measurement , October 2004.
	[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission		[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
	Timer", RFC 2988, November 2000.		Timer", RFC 2988, November 2000.
	[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,		[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
	skipping to change at page 13, line 21		skipping to change at page 13, line 40
	[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol		[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
	(HIP) Architecture", RFC 4423, May 2006.		(HIP) Architecture", RFC 4423, May 2006.
	[SOLARIS-MANUAL]		[SOLARIS-MANUAL]
	Sun Microsystems, "Solaris Tunable Parameters Reference		Sun Microsystems, "Solaris Tunable Parameters Reference
	Manual", Part No. 806-7009-10, 2002.		Manual", Part No. 806-7009-10, 2002.
	Editorial Comments
	[anchor3] Lars: With the new CHANGEABLE flag, which prevents
	changing of LOCAL_UTO when an application has indicated
	that it cares about the value, I think the formula can
	become LOCAL_UTO = min(U_LIMIT, max(REMOTE_UTO, L_LIMIT)),
	i.e., we adopt whatever the other end suggests, given that
	it is with in acceptable limits. I didn't want to make
	this change without discussing it first, however.
	Appendix A. Document Revision History		Appendix A. Document Revision History
	To be removed upon publication		To be removed upon publication
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	| Revision | Comments |		| Revision | Comments |
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
			| 06 | Includes a note on the limited space for TCP options |
			| | and miscelaneous editorial changes(suggested by |
			| | Anantha Ramaiah). Includes possible enforcement of |
			| | per-outgoing-interface limits for the UTO, and |
			| | miscellaneous editorial changes (suggested by Alfred |
			| | Hoenes). Includes relevant changes to reflect WG |
			| | consesus how the local user timeout should be selected |
			| | (i.e., record both the current user timeout, and the |
			| | advertised UTO). |
	| 05 | Made behavior on when to change/not change the local |		| 05 | Made behavior on when to change/not change the local |
	| | UTO in response to incoming options consistent through |		| | UTO in response to incoming options consistent through |
	| | the document. This required some reshuffling of text |		| | the document. This required some reshuffling of text |
	| | and also removed the need for the special "don't care" |		| | and also removed the need for the special "don't care" |
	| | option value. |		| | option value. |
	| 04 | Clarified the results obtained by Medina et al. Added |		| 04 | Clarified the results obtained by Medina et al. Added |
	| | text to suggest inclusion of the UTO in the first |		| | text to suggest inclusion of the UTO in the first |
	| | non-SYN segment by the TCP that sent a SYN in response |		| | non-SYN segment by the TCP that sent a SYN in response |
	| | to an active OPEN. |		| | to an active OPEN. |
	| 03 | Corrected use of RFC2119 terminology. Clarified how |		| 03 | Corrected use of RFC2119 terminology. Clarified how |
	| | use of the TCP UTO is triggered. Clarified reason for |		| | use of the TCP UTO is triggered. Clarified reason for |
	| | sending a UTO in the SYN and SYN/ACK segments. |		| | sending a UTO in the SYN and SYN/ACK segments. |
	| | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO |		| | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO |
	| | options. Removed text that suggested that a UTO |		| | socket options. Removed text that suggested that a |
	| | should be sent upon receipt of an UTO from the other |		| | UTO should be sent upon receipt of an UTO from the |
	| | end. Required minimum value for the lower limit of |		| | other end. Required minimum value for the lower limit |
	| | the user timeout. Moved alternative solutions to |		| | of the user timeout. Moved alternative solutions to |
	| | appendix. Miscellaneous editorial changes. |		| | appendix. Miscellaneous editorial changes. |
	| 02 | Corrected terminology by replacing terms like |		| 02 | Corrected terminology by replacing terms like |
	| | "negotiate", "coordinate", etc. that were left from |		| | "negotiate", "coordinate", etc. that were left from |
	| | pre-WG-document times when the UTO was a more |		| | pre-WG-document times when the UTO was a more |
	| | formalized exchange instead of the advisory one it is |		| | formalized exchange instead of the advisory one it is |
	| | now. Application-requested UTOs take precedence over |		| | now. Application-requested UTOs take precedence over |
	| | ones received from the peer (pointed out by Ted |		| | ones received from the peer (pointed out by Ted |
	| | Faber). Added a brief mention of SO_SNDTIMEO and a |		| | Faber). Added a brief mention of SO_SNDTIMEO and a |
	| | slightly longer discussion of SO_RCVTIMEO. |		| | slightly longer discussion of SO_RCVTIMEO. |
	| 01 | Clarified and corrected the description of the |		| 01 | Clarified and corrected the description of the |
End of changes. 46 change blocks.
	133 lines changed or deleted		150 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/