draft-ietf-tcpm-tcp-uto-02.txt   draft-ietf-tcpm-tcp-uto-03.txt 
TCP Maintenance and Minor L. Eggert TCP Maintenance and Minor L. Eggert
Extensions (tcpm) NEC Extensions (tcpm) NEC
Internet-Draft F. Gont Internet-Draft F. Gont
Expires: April 27, 2006 UTN/FRH Expires: January 20, 2007 UTN/FRH
October 24, 2005 July 19, 2006
TCP User Timeout Option TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-02 draft-ietf-tcpm-tcp-uto-03
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 April 27, 2006. This Internet-Draft will expire on January 20, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The TCP user timeout controls how long transmitted data may remain This document specifies a new TCP option - the TCP User Timeout
unacknowledged before a connection is forcefully closed. It is a Option - that allows a TCP to advertise its current user timeout for
local, per-connection parameter. The advisory TCP User Timeout a connection. Thus, the remote TCP may modify its local user timeout
Option allows conforming TCP implementations to exchange their local based on knowledge of the peer's user timeout. The TCP user timeout
user timeouts. This is an in-protocol mechanism to allow a host to controls how long transmitted data may remain unacknowledged before a
modify its local user timeout for a connection based on knowledge of connection is forcefully closed. It is a local, per-connection
the peer's user timeout. Increasing the user timeouts allows parameter. Increasing the user timeouts allows established TCP
established TCP connections to survive extended periods of connections to survive extended periods of disconnection. Decreasing
disconnection. Decreasing user timeouts allows busy servers to the user timeouts allows busy servers to explicitly notify their
explicitly notify their clients that they will maintain the clients that they will maintain the connection state only across
connection state only across short periods of disconnection. short periods of disconnection.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6
3.2. Reliability Considerations . . . . . . . . . . . . . . . . 8 3.2. Reliability Considerations . . . . . . . . . . . . . . . . 8
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Special Option Values . . . . . . . . . . . . . . . . . . 9 3.4. Special Option Values . . . . . . . . . . . . . . . . . . 9
4. Additional Considerations . . . . . . . . . . . . . . . . . . 9 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 9
5. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
5.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Document Revision History . . . . . . . . . . . . . . 15 Appendix A. Alternative solutions . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Document Revision History . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The Transmission Control Protocol (TCP) specification [RFC0793] The Transmission Control Protocol (TCP) specification
defines a local, per-connection "user timeout" parameter that [RFC0793]defines a local, per-connection "user timeout" parameter
specifies the maximum amount of time that transmitted data may remain that specifies the maximum amount of time that transmitted data may
unacknowledged before TCP will forcefully close the corresponding remain unacknowledged before TCP will forcefully close the
connection. Applications can set and change this parameter with OPEN corresponding connection. Applications can set and change this
and SEND calls. If a network disconnection lasts longer than the parameter with OPEN and SEND calls. If a network disconnection lasts
user timeout, no acknowledgments will be received for any longer than the user timeout, no acknowledgments will be received for
transmission attempt, including keep-alives [TCP-ILLU], and the TCP any transmission attempt, including keep-alives [TCP-ILLU], and the
connection will close when the user timeout occurs. In the absence TCP connection will close when the user timeout occurs. In the
of an application-specified user timeout, the TCP specification absence of an application-specified user timeout, the TCP
[RFC0793] defines a default user timeout of 5 minutes. specification [RFC0793] defines a default user timeout of 5 minutes.
The Host Requirements RFC [RFC1122] refines this definition by The Host Requirements RFC [RFC1122] refines this definition by
introducing two thresholds, R1 and R2 (R2 > R1), on the number of introducing two thresholds, R1 and R2 (R2 > R1), on the number of
retransmissions of a single segment. It suggests that TCP should retransmissions of a single segment. It suggests that TCP should
notify applications when R1 is reached for a segment, and close the notify applications when R1 is reached for a segment, and close the
connection once R2 is reached. [RFC1122] also defines the connection once R2 is reached. [RFC1122] also defines the
recommended values for R1 (three retransmissions) and R2 (100 recommended values for R1 (three retransmissions) and R2 (100
seconds), noting that R2 for SYN segments should be at least 3 seconds), noting that R2 for SYN segments should be at least 3
minutes. Instead of a single user timeout, some TCP implementations minutes. Instead of a single user timeout, some TCP implementations
offer finer-grained policies. For example, Solaris supports offer finer-grained policies. For example, Solaris supports
different timeouts depending on whether a TCP connection is in the different timeouts depending on whether a TCP connection is in the
SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL]. SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL].
Although some TCP implementations allow applications to set their Although some TCP implementations allow applications to set their
local user timeout, e.g., through the SO_SNDTIMEO socket option, local user timeout, there is no in-protocol mechanism to signal
there is no in-protocol mechanism to signal changes in the local user changes in the local user timeout to remote peers. This causes local
timeout to remote peers. This causes local changes to be changes to be ineffective, because the peer will still close the
ineffective, because the peer will still close the connection after connection after its user timeout expires, even when the host has
its user timeout expires, even when a host has raised its local user raised its local user timeout. The ability to suggest the remote
timeout. The ability to modify the two user timeouts associated with peer a user timeout to be used for the connection can improve TCP's
a connection can improve TCP operation in scenarios that are operation in scenarios that are currently not well supported. One
currently not well supported. One example of such scenarios are example of such scenarios are mobile hosts that change network
mobile hosts that change network attachment points based on current attachment points based on current location. Such hosts, maybe using
location. Such hosts, maybe using MobileIP [RFC3344], HIP [I-D.ietf- MobileIP [RFC3344], HIP [RFC4423]or transport-layer mobility
hip-arch] or transport-layer mobility mechanisms [I-D.eddy-tcp- mechanisms [I-D.eddy-tcp-mobility], are only intermittently connected
mobility], are only intermittently connected to the Internet. In to the Internet. In between connected periods, mobile hosts may
between connected periods, mobile hosts may experience periods of experience periods of disconnection during which no network service
disconnection during which no network service is available [SCHUETZ- is available. Other factors that can cause transient periods of
THESIS][SCHUETZ-CCR][DRIVE-THRU]. Other factors that can cause disconnection are high levels of congestion as well as link or
transient periods of disconnection are high levels of congestion as routing failures inside the network.
well as link or routing failures inside the network.
In scenarios similar to the ones described above, a host may not know In scenarios similar to the ones described above, a host may not know
exactly when or for how long it will be disconnected from the exactly when or for how long it will be disconnected from the
network, but it might expect such events due to past mobility network, but it might expect such events due to past mobility
patterns and thus benefit from using longer user timeouts. In other patterns and thus benefit from using longer user timeouts. In other
scenarios, the length and time of a network disconnection may even be scenarios, the length and time of a network disconnection may even be
predictable. For example, an orbiting node on a satellite might predictable. For example, an orbiting node on a non-geostationary
experience disconnections due to line-of-sight blocking by other satellite might experience disconnections due to line-of-sight
planetary bodies. The disconnection periods of such a node may be blocking by other planetary bodies. The disconnection periods of
easily computable from orbital mechanics. such a node may be easily computable from orbital mechanics.
This document specifies a new TCP option - the User Timeout Option This document specifies a new TCP option - the User Timeout Option
(UTO) - that allows conforming hosts to exchange their local, per- (UTO) - that allows a TCP to advertise its current local user timeout
connection user timeout information. This allows, for example, parameter. Thus, based on the information advertised by the remote
mobile hosts to maintain TCP connections across disconnected periods TCP peer, a TCP may modify its own user timeout accordingly. This
that are longer than their peer's default user timeout. A second use allows, for example, mobile hosts to maintain TCP connections across
of the TCP User Timeout Option is advertisement of shorter-than- disconnected periods that are longer than their peer's default user
default user timeouts. This can allow busy servers to explicitly timeout. A second use of the TCP User Timeout Option is
notify their clients that they will maintain the state associated advertisement of shorter-than-default user timeouts. This can allow
with established connections only across short periods of busy servers to explicitly notify their clients that they will
disconnection. maintain the state associated with established connections only
across short periods of disconnection.
The same benefits can be obtained through an application-layer Use of the TCP User Timeout Option could be triggered either by an
mechanism, i.e., exchanging user timeout information via application API call or by a system-wide toggle. The API could be, for example,
messages and having the application adjust the user timeouts through a Socket option that would need to be explicitly set by the
the TCP API on both sides of a connection. This approach does not corresponding application. This option would default to "off". A
require a new TCP option, but requires changing all application system-wide toggle would allow a system administrator to enable the
implementations that desire to tolerate extended periods of use of the TCP User Timeout Option on a system-wide basis, and set
disconnection, and in most cases also requires a modification to the the option a desired value. This system-wide toggle would allow the
corresponding application layer protocol. With the proposed TCP use of the option by application programs that have not been
option, application changes may not be necessary at all, or may be explicitly coded to do so. If such a system-wide toggle were
restricted to sender- or receiver-side only, and there is no need to provided, it would default to "off".
modify the corresponding application protocol.
A different approach to tolerate longer periods of disconnection is In all cases, use of the TCP User Timeout Option would depend on an
to simply increase the system-wide user timeout on both peers. This active decision, either by the application programmer (by means of an
approach has the benefit of not requiring a new TCP option or API call), or by a system administrator (by means of a system-wide
application changes. However, it can also significantly increase the toggle).
amount of connection state a busy server must maintain, because a
longer global timeout value will apply to all its connections. The
proposed TCP User Timeout Option, on the other hand, allows hosts to
selectively manage the user timeouts of individual connections,
reducing the amount of state they must maintain across disconnected
periods.
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
Sending a TCP User Timeout Option informs the remote peer of the Sending a TCP User Timeout Option informs the remote peer of the
current local user timeout and suggests that the remote peer SHOULD current local user timeout for the connection, and suggests the TCP
start using the indicated user timeout value for the corresponding peer to adapt its user timeout accordingly. The user timeout value
connection. The user timeout value included in a TCP User Timeout included in a TCP User Timeout Option specifies the requested user
Option specifies the requested user timeout during the synchronized timeout during the synchronized states of a connection (ESTABLISHED,
states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE- FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK).
WAIT, CLOSING, or LAST-ACK). Connections in other states MUST the Connections in other states MUST the default timeout values defined
default timeout values defined in [RFC0793][RFC1122].[anchor3] in [RFC0793] [RFC1122].
Note that an exchange of TCP User Timeout Options between peers is Note that an exchange of TCP User Timeout Options between peers is
not a binding negotiation. Transmission of a TCP User Timeout Option not a binding negotiation. Transmission of a TCP User Timeout Option
is an advisory suggestion that the peer consider adapting its local is an advisory suggestion that the peer consider adapting its local
user timeout. Hosts remain free to forcefully close or abort user timeout. Hosts remain free to adopt a different user timeout,
connections at any time for any reason, whether or not they use or to forcefully close or abort connections at any time for any
custom user timeouts or have suggested the peer to use them. reason, whether or not they use custom user timeouts or have
suggested the peer to use them.
A host that supports the TCP User Timeout Option SHOULD include one A host that supports the TCP User Timeout Option SHOULD include one
in each packet that carries a SYN flag, but need not. [MEDINA] has in each packet that carries a SYN flag, but need not. [MEDINA] has
shown that unknown options are correctly handled by the vast majority shown that unknown options are correctly handled by the vast majority
of modern TCP stacks. It is thus not necessary to require of modern TCP stacks. It is thus not necessary to require
negotiation of the use of the TCP User Timeout Option during the negotiation of the use of the TCP User Timeout Option during the
three-way handshake of a connection. three-way handshake of a connection. However, including a TCP User
Timeout Option in each segment that has the SYN flag set will result
in TCP being able to adopt a user timeout with knowledge of that used
by the peer TCP, since the beginning of the data transfer phase.
A host that supports the TCP User Timeout Option SHOULD include it in A host that supports the TCP User Timeout Option SHOULD include it in
the next possible segment to its peer whenever it starts using a new the next possible segment to its peer whenever it starts using a new
user timeout for the connection. This allows the peer to adapt its user timeout for the connection. This allows the peer to adapt its
local user timeout for the connection accordingly. local user timeout for the connection accordingly.
When a host that supports the TCP User Timeout Option receives one, When a host that supports the TCP User Timeout Option receives one,
it decides whether to change its local user timeout of the connection it will use the received value to compute the local user timeout for
based on the received value. Generally, hosts should honor requests the connection. Generally, hosts should honor requests for changes
for changes to the user timeout (see Section 3.1), unless security to the user timeout (see Section 3.1), unless security concerns,
concerns, resource constraints or external policies indicate resource constraints or external policies indicate otherwise (see
otherwise (see Section 6). If so, hosts may ignore incoming TCP User Section 5). If so, hosts may use a different user timeout for the
Timeout Options and use a different user timeout for the connection. connection.
When a host receives a TCP User Timeout Option, it first decides
whether to change its local user timeout for the connection -
Section 3.1 discusses the specifics of this choice - and then decides
whether to send a TCP User Timeout Option to its peer in response.
If a host has never sent a TCP User Timeout Option to its peer during
the lifetime of the connection, or if it has changed its local user
timeout, it SHOULD send TCP User Timeout Option with its current
local user timeout to its peer. [anchor4]
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
interoperability. interoperability.
Hosts SHOULD impose upper and lower limits on the user timeouts they Hosts MUST impose upper and lower limits on the user timeouts they
use. Section 3.1 discusses user timeout limits, and describes a use. Section 3.1 discusses user timeout limits, and describes a
recommended scheme to apply them. A TCP User Timeout Option with a RECOMMENDED scheme to apply them. A TCP User Timeout Option with a
value of zero (i.e., "now") is nonsensical and is used for a special value of zero (i.e., "now") is nonsensical and is used for a special
purpose, see Section 3.4. Section 3.1 discusses potentially purpose, see Section 3.4. Section 3.1 discusses potentially
problematic effects of other user timeout durations. problematic effects of other user timeout durations.
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. Application-requested user timeout values always take connection. Application-requested user timeout values always take
precedence over timeout values received from the peer in a TCP User precedence over timeout values received from the peer in a TCP User
Timeout Option. [anchor5] Consequently, unless the application on the Timeout Option. [anchor3] Consequently, unless the application on the
local host has requested a specific user timeout for the connection, local host has requested a specific user timeout for the connection,
e.g., through a socket API call, hosts SHOULD adjust their local user e.g., through the OPEN or SEND calls, hosts SHOULD adjust their local
timeout in response to receiving a TCP User Timeout Option, as user timeout in response to receiving a TCP User Timeout Option, as
described in the remainder of this section. If the local application described in the remainder of this section. If the local application
has requested a specific local user timeout, TCP implementations MUST has requested a specific local user timeout, TCP implementations MUST
NOT change it in response to receiving a TCP User Timeout Option. In NOT change it in response to receiving a TCP User Timeout Option. In
this case, they SHOULD, however, notify the application about the this case, they SHOULD, however, notify the application about the
user timeout value received from the peer. user timeout value received from the peer.
The User Timeout Option specifies the user timeout in terms of time The User Timeout Option specifies the user timeout in terms of time
units, rather than in terms of number of retransmissions or round- units, rather than in terms of number of retransmissions or round-
trip times (RTTs), as in most cases the periods of disconnection have trip times (RTTs), as in most cases the periods of disconnection have
to do with operation and mobility patterns, rather than with the to do with operation and mobility patterns, rather than with the
current network conditions [anchor6][anchor7]. Thus, the TCP User current network conditions. Thus, the TCP User Timeout Option allows
Timeout Option allows hosts to exchange user timeout values from 1 hosts to exchange user timeout values from 1 second to over 9 hours
second to over 9 hours at a granularity of seconds, and from 1 minute at a granularity of seconds, and from 1 minute to over 22 days at a
to over 22 days at a granularity of minutes. (An option value of granularity of minutes. (An option value of zero is reserved for a
zero is reserved for a special purpose, see Section 3.4.) special purpose, see Section 3.4.)
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 [TCP-ILLU]. Although the TCP to user timeout values of a few minutes [TCP-ILLU]. Although the TCP
User Timeout Option allows suggestion of short timeouts, applications User Timeout Option allows suggestion of short timeouts, applications
advertising them SHOULD consider these effects. advertising them should consider these effects.
Long user timeout values allow hosts to tolerate extended periods of Long user timeout values allow hosts to tolerate extended periods of
disconnection. However, they also require hosts to maintain the TCP disconnection. However, they also require hosts to maintain the TCP
state information associated with connections for long periods of state information associated with connections for long periods of
time. Section 6 discusses the security implications of long timeout time. Section 5 discusses the security implications of long timeout
values. values.
To protect against these effects, implementations SHOULD impose To protect against these effects, implementations MUST impose limits
limits on the user timeout values they accept and use. The remainder on the user timeout values they accept and use. The remainder of
of this section describes a RECOMMENDED scheme to limit user timeouts this section describes a RECOMMENDED scheme to limit user timeouts
based on upper and lower limits. Under the RECOMMENDED scheme, each based on upper and lower limits. Under the RECOMMENDED scheme, each
TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection
according to this formula: according to this formula:
USER_TIMEOUT = 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
Resulting user timeout value to be adopted by the local TCP for a Resulting user timeout value to be adopted by the local TCP for a
connection. 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.
skipping to change at page 7, line 36 skipping to change at page 7, line 25
Current lower limit imposed on the user timeout of a connection by Current lower limit imposed on the user timeout of a connection by
the local host. the local host.
LOCAL_UTO LOCAL_UTO
Current local user timeout of this specific connection. Current local user timeout of this specific connection.
REMOTE_UTO REMOTE_UTO
Last "user timeout" value suggested by the remote peer by means of Last "user timeout" value suggested by the remote peer by means of
the TCP User Timeout Option. the TCP User Timeout Option.
This means that the maximum of the two announced values will be This means that, provided they are within the upper and lower limits,
adopted for the user timeout of the connection. The rationale is the maximum of the two announced values will be adopted for the user
that choosing the maximum of the two values will let the connection timeout of the connection. The rationale is that choosing the
survive longer periods of disconnection. If the TCP that announced maximum of the two values will let the connection survive longer
the lower of the two user timeout values did so in order to reduce periods of disconnection. If the TCP that announced the lower of the
the amount of TCP state information that must be kept on the host, it two user timeout values did so in order to reduce the amount of TCP
can, nevertheless, close or abort the connection whenever it wants. state information that must be kept on the host, it can,
nevertheless, close or abort the connection whenever it wants.
It must be noted that the two endpoints of the connection will not
necesarilly 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 6 discusses the details of these attacks. attacks. Section 5discusses 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 or even per-
connection basis. Furthermore, these limits need not be static. For connection basis. Furthermore, these limits need not be static. For
example, they MAY be a function of system resource utilization or example, they MAY be a function of system resource utilization or
attack status and could be dynamically adapted. 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. scheme described in this section. Adopting a user timeout smaller
than the current retransmission timeout (RTO) for the connection
would likely cause the connection to be aborted unnecesarily.
Therefore, the lower limit (L_LIMIT) MUST be larger than the current
retransmission timeout (RTO) for the connection.
3.2. Reliability Considerations 3.2. Reliability Considerations
The TCP User Timeout Option is an advisory TCP option that does not The TCP User Timeout Option is an advisory TCP option that does not
change processing of subsequent segments. Unlike other TCP options, change processing of subsequent segments. Unlike other TCP options,
it need not be exchanged reliably. Consequently, the specification it need not be exchanged reliably. Consequently, the specification
in this section does not define a reliability handshake for TCP User in this section does not define a reliability handshake for TCP User
Timeout Option exchanges. When a segment that carries a TCP User Timeout Option exchanges. When a segment that carries a TCP User
Timeout Option is lost, the option may never reach the intended peer. Timeout Option is lost, the option may never reach the intended peer.
Implementations MAY implement local mechanisms to improve delivery Implementations MAY implement local mechanisms to improve delivery
reliability, such as retransmitting the TCP User Timeout Option when reliability, such as retransmitting the TCP User Timeout Option when
they retransmit the segment that originally carried it, or they retransmit the segment that originally carried it, or
"attaching" the option to a byte in the stream and retransmitting the "attaching" the option to a byte in the stream and retransmitting the
option whenever that byte or its ACK are retransmitted. option whenever that byte 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 the TCP User Timeout Option, they do not transmission reliability for the TCP User Timeout Option, they do not
guarantee delivery (a three-way handshake would be required for guarantee delivery (a three-way handshake would be required for
this). Consequently, implementations MUST NOT assume that a TCP User this). Consequently, implementations should not assume that a TCP
Timeout Option is reliably transmitted. User Timeout Option is reliably transmitted.
3.3. Option Format 3.3. Option Format
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
Figure 1 shows the format of the TCP User Timeout Option. It Figure 1 shows the format of the TCP User Timeout Option. It
contains these fields: contains these fields:
Kind (8 bits) Kind (8 bits)
A TCP option number [RFC0793] to be assigned by IANA upon A TCP option number [RFC0793] to be assigned by IANA upon
publication of this document (see Section 7). publication of this document (see Section 6).
Length (8 bits) Length (8 bits)
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.
skipping to change at page 9, line 48 skipping to change at page 9, line 44
calculating a new local USER_TIMEOUT described in Section 3.1, with a calculating a new local USER_TIMEOUT described in Section 3.1, with a
numeric value of zero seconds for REMOTE_UTO. The sender SHOULD numeric value of zero seconds for REMOTE_UTO. The sender SHOULD
perform the same calculation as described in Section 3.1, with a perform the same calculation as described in Section 3.1, with a
numeric value of zero seconds for LOCAL_UTO. numeric value of zero seconds for LOCAL_UTO.
A zero-minute TCP User Timeout Option, i.e., with a "User Timeout" A zero-minute TCP User Timeout Option, i.e., with a "User Timeout"
field of zero and a "Granularity" bit of one, is reserved for future field of zero and a "Granularity" bit of one, is reserved for future
use. TCP implementations MUST NOT send it and MUST ignore it upon use. TCP implementations MUST NOT send it and MUST ignore it upon
reception. reception.
4. Additional Considerations 4. Interoperability Issues
Section 1 described that although [RFC0793] defines the API mechanism
to change the user timeout as an optional parameter for TCP's OPEN
and SEND calls, many implementations provide a different API.
Several popular TCP implementations offer the SO_SNDTIMEO socket
option, either in addition or instead of the RFC-defined OPEN and
SEND user timeout parameter.
Many implementations that offer the SO_SNDTIMEO socket option also
implement a corresponding SO_RCVTIMEO socket option. Whereas the
user timout (SO_SNDTIMEO), specifies how long data may remain
unacknowledged by the peer, i.e., how long a SEND call may take, the
SO_RCVTIMEO specifies how long a RECV call may take.
Even when two TCPs implement the TCP User Timeout Option and decide
to lengthen their local UTOs for a connection, RECV operations during
a disconnection can trigger the SO_RCVTIMEO timeout. Note that
[RFC0793] does not specify this receive timeout or how TCP reacts
when it occurs. If implementations close a connection when its
SO_RCVTIMEO times out, they SHOULD modify this parameter similarly to
how they modify SO_SNDTIMEO upon reception of a TCP User Timeout
option. [anchor10]
5. 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.
5.1. Middleboxes 4.1. Middleboxes
The large number of middleboxes (firewalls, proxies, protocol The large number of middleboxes (firewalls, proxies, protocol
scrubbers, etc.) currently present in the Internet pose some scrubbers, etc.) currently present in the Internet pose some
difficulty for deploying new TCP options. Some firewalls may block difficulty for deploying new TCP options. Some firewalls may block
segments that carry unknown options, preventing connection segments that carry unknown options, preventing connection
establishment when the SYN or SYN-ACK contains a TCP User Timeout establishment when the SYN or SYN-ACK segment contain a TCP User
Option. Some recent results, however, indicate that for new TCP Timeout Option. Some recent results, however, indicate that for new
options, this may not be a significant threat, with only 0.2% of web TCP options, this may not be a significant threat, with only 0.2% of
requests failing when carrying an unknown option [MEDINA]. web requests failing when carrying an unknown option [MEDINA].
Stateful firewalls usually reset connections after a period of Stateful firewalls usually reset connections after a period of
inactivity. If such a firewall exists along the path between two inactivity. If such a firewall exists along the path between two
peers, it may close or abort connections regardless of the use of the peers, it may close or abort connections regardless of the use of the
TCP User Timeout Option. In the future, such firewalls may learn to TCP User Timeout Option. In the future, such firewalls may learn to
parse the TCP User Timeout Option and modify their behavior or the parse the TCP User Timeout Option and modify their behavior or the
option accordingly. option accordingly.
5.2. TCP Keep-Alives 4.2. TCP Keep-Alives
Some TCP implementations, such as the one in BSD systems, use a Some TCP implementations, such as the one 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 of disconnection. otherwise have survived the transient period of disconnection.
Therefore, if a TCP peer enables TCP keep-alives for a connection Therefore, if a TCP peer enables TCP keep-alives for a connection
that is using the TCP User Timeout Option, then the keep-alive timer that is using the TCP User Timeout Option, then the keep-alive timer
MUST be set to a value larger than that of the adopted USER TIMEOUT. MUST be set to a value larger than that of the adopted USER TIMEOUT.
6. Security Considerations 5. Security Considerations
Lengthening user timeouts has obvious security implications. Lengthening user timeouts has obvious security implications.
Flooding attacks cause denial of service by forcing servers to commit Flooding attacks cause denial of service by forcing servers to commit
resources for maintaining the state of throw-away connections. resources for maintaining the state of throw-away connections.
However, TCP implementations do not become more vulnerable to simple However, TCP implementations do not become more vulnerable to simple
SYN flooding by implementing the TCP User Timeout Option, because SYN flooding by implementing the TCP User Timeout Option, because
user timeouts exchanged during the handshake only affect the user timeouts exchanged during the handshake only affect the
synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK), which simple SYN floods never reach. CLOSING, LAST-ACK), which simple SYN floods never reach.
However, when an attacker completes the three-way handshakes of its However, when an attacker completes the three-way handshakes of its
throw-away connections it can amplify the effects of resource throw-away connections it can amplify the effects of resource
exhaustion attacks, because the attacked server must maintain the exhaustion attacks, because the attacked server must maintain the
connection state associated with the throw-away connections for connection state associated with the throw-away connections for
longer durations. Because connection state is kept longer, lower- longer durations. Because connection state is kept longer, lower-
frequency attack traffic, which may be more difficult to detect, can frequency attack traffic, which may be more difficult to detect, can
already cause resource exhaustion. already cause resource exhaustion.
Several approaches can help mitigate this issue. First, Several approaches can help mitigate this issue. First,
implementations can require prior peer authentication, e.g., using implementations can require prior peer authentication, e.g., using
IPsec [I-D.ietf-ipsec-rfc2401bis], before accepting long user IPsec [RFC4301], before accepting long user timeouts for the peer's
timeouts for the peer's connections. Similarly, a host can start to connections. Similarly, a host can start to accept long user
accept long user timeouts for an established connection only after timeouts for an established connection only after in-band
in-band authentication has occurred, for example, after a TLS authentication has occurred, for example, after a TLS handshake
handshake across the connection has succeeded [RFC2246]. Although across the connection has succeeded [RFC2246]. Although these are
these are arguably the most complete solutions, they depend on arguably the most complete solutions, they depend on external
external mechanisms to establish a trust relationship. mechanisms to establish a trust relationship.
A second alternative that does not depend on external mechanisms A second alternative that does not depend on external mechanisms
would introduce a per-peer limit on the number of connections that would introduce a per-peer limit on the number of connections that
may use increased user timeouts. Several variants of this approach may use increased user timeouts. Several variants of this approach
are possible, such as fixed limits or shortening accepted user are possible, such as fixed limits or shortening accepted user
timeouts with a rising number of connections. Although this timeouts with a rising number of connections. Although this
alternative does not eliminate resource exhaustion attacks from a alternative does not eliminate resource exhaustion attacks from a
single peer, it can limit their effects. Reducing the number of single peer, it can limit their effects. Reducing the number of
high-UTO connections a server supports in the face of an attack turns high-UTO connections a server supports in the face of an attack turns
that attack into a denial-of-service attack against the service of that attack into a denial-of-service attack against the service of
skipping to change at page 12, line 25 skipping to change at page 11, line 44
effective. In general, using the peers' level of trust as a effective. In general, using the peers' level of trust as a
parameter during the load-shedding decision process may be useful. parameter during the load-shedding decision process may be useful.
Note that if TCP needs to close or abort connections with a long TCP Note that if TCP needs to close or abort connections with a long TCP
User Timeout Option to shed load, these connections are still no User Timeout Option to shed load, these connections are still no
worse off than without the option. worse off than without the option.
Finally, upper and lower limits on user timeouts, discussed in Finally, upper and lower limits on user timeouts, discussed in
Section 3.1, can be an effective tool to limit the impact of these Section 3.1, can be an effective tool to limit the impact of these
sorts of attacks. sorts of attacks.
7. IANA Considerations 6. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to [RFC2434].
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.
8. Acknowledgments 7. Acknowledgments
The following people have improved this document through thoughtful The following people have improved this document through thoughtful
suggestions: Mark Allmann, David Borman, Bob Braden, Marcus Brunner, suggestions: Mark Allman, David Borman, Bob Braden, Marcus Brunner,
Wesley Eddy, Abolade Gbadegesin, Ted Faber, Guillermo Gont, Tom Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Faber,
Henderson, Joseph Ishac, Jeremy Harris, Phil Karn, Michael Kerrisk, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Phil
Dan Krejsa, Kostas Pentikousis, Juergen Quittek, Joe Touch, Stefan Karn, Michael Kerrisk, Dan Krejsa, Kostas Pentikousis, Juergen
Schmid, Simon Schuetz, Tim Shepard and Martin Stiemerling. Quittek, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and
Martin Stiemerling.
Lars Eggert is partly funded by Ambient Networks, a research project Lars Eggert is partly funded by Ambient Networks, a research project
supported by the European Commission under its Sixth Framework supported by the European Commission under its Sixth Framework
Program. The views and conclusions contained herein are those of the Program. The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of official policies or endorsements, either expressed or implied, of
the Ambient Networks project or the European Commission. the Ambient Networks project or the European Commission.
9. References 8. References
9.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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
9.2. Informative References 8.2. Informative References
[DRIVE-THRU]
Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE
802.11b for Automobile Users", Proc. Infocom , March 2004.
[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-hip-arch]
Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005.
[I-D.ietf-ipsec-rfc2401bis]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), April 2005.
[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.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[SCHUETZ-CCR] [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, Internet Protocol", RFC 4301, December 2005.
"Protocol Enhancements for Intermittently Connected
Hosts", To appear: ACM Computer Communication Review, Vol.
35, No. 3, July 2005.
[SCHUETZ-THESIS] [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
Schuetz, S., "Network Support for Intermittently Connected (HIP) Architecture", RFC 4423, May 2006.
Mobile Nodes", Diploma Thesis, University of Mannheim,
Germany, June 2004.
[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.
[TCP-ILLU] [TCP-ILLU]
Stevens, W., "TCP/IP Illustrated, Volume 1: The Stevens, W., "TCP/IP Illustrated, Volume 1: The
Protocols", Addison-Wesley , 1994. Protocols", Addison-Wesley , 1994.
Editorial Comments Editorial Comments
[anchor3] A future version of this document may extend per- [anchor3] Without this, UTO would modify TCP semantics, because
connection user timeouts to the SYN-SENT and SYN-RECEIVED
states in a way that conforms to the required minimum
timeouts.
[anchor4] Should it really always send UTO when it changes the
local timeout? I can imagine some ping-pong effect when
two hosts user different UTO adoption strategies. But
maybe that's OK? Additionally, when -01 was presented in
Paris, Joe Touch has suggested that an "UTO-ACK" should
be sent when a UTO is received. I have not seen consensus
for this on the mailing list, hence -02 does not include
this suggestion.
[anchor5] Without this, UTO would modify TCP semantics, because
application-requested UTOs could be overridden by peer application-requested UTOs could be overridden by peer
requests. requests.
[anchor6] When -01 was presented in Paris, Bob Braden suggested to Appendix A. Alternative solutions
specify the UTO in terms of multiples of the RTT. Others
disagreed, hence -02 does not include this suggestion.
One reason this may be problematic is that the RTT may
change for one direction of the connection, sort of
defeating the process of exchanging UTOs.
[anchor7] Let's suppose a host is intermittently connected to a The same benefits could be obtained through an application-layer
network, and the disconnected periods last for, say, mechanism, i.e., exchanging user timeout information via application
about 15 minutes each. Let's suppose the attachment messages and having the application adjust the user timeouts through
points range from low-bandwidth/high-delay/congested the TCP API on both sides of a connection. This approach would not
networks to high-bandwidth/low-delay networks. If the UTO require a new TCP option, but would require changing all application
specified the user timeout in terms of number of implementations that desire to tolerate extended periods of
retransmissions or round-trip times, an UTO that is disconnection, and in most cases would also require a modification to
appropriate for the high-bandwith/low-delay networks the corresponding application layer protocol. With the proposed TCP
would be too small for the low-bandwidth/high-delay/ option, application changes may not be necessary at all, or may be
congested networks. Also, even if the host kept connected restricted to sender- or receiver-side only, and there is no need to
to the same network, if the network conditions changed, modify the corresponding application protocol.
UTO opions would need to be re-sent (as n*RTO and n*RTT
would change), unnecesarily.
[anchor10] Can we even say this much about an API that's not in the A different approach to tolerate longer periods of disconnection
TCP spec? Or should the SO_RCVTIMEO discussion be would be to simply increase the system-wide user timeout on both
removed? peers. This approach has the benefit of not requiring a new TCP
option or application changes. However, it can also significantly
increase the amount of connection state a busy server must maintain,
because a longer global timeout value would apply to all its
connections.
Appendix A. Document Revision History The proposed TCP User Timeout Option, on the other hand, allows hosts
to selectively manage the user timeouts of individual connections,
reducing the amount of state they must maintain across disconnected
periods.
Appendix B. Document Revision History
To be removed upon publication To be removed upon publication
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| 03 | Corrected use of RFC2119 terminology. Clarified how |
| | use of the TCP UTO is triggered. Clarified reason for |
| | sending a UTO in the SYN and SYN/ACK segments. |
| | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO |
| | options. Removed text that suggested that a UTO |
| | should be sent upon receipt of an UTO from the remote |
| | peer. Required minimum value for the lower limit of |
| | the user timeout. Moved alternative solutions to |
| | 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 |
| | existing user timeout in RFC793 and RFC1122. Removed | | | existing user timeout in RFC793 and RFC1122. Removed |
skipping to change at page 17, line 41 skipping to change at page 16, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 55 change blocks. 
258 lines changed or deleted 208 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/