draft-ietf-tcpm-tcp-uto-01.txt | draft-ietf-tcpm-tcp-uto-02.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: January 16, 2006 UTN/FRH | Expires: April 27, 2006 UTN/FRH | |||
July 15, 2005 | October 24, 2005 | |||
TCP User Timeout Option | TCP User Timeout Option | |||
draft-ietf-tcpm-tcp-uto-01 | draft-ietf-tcpm-tcp-uto-02 | |||
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 January 16, 2006. | This Internet-Draft will expire on April 27, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
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. The advisory TCP User Timeout | local, per-connection parameter. The advisory TCP User Timeout | |||
Option allows conforming TCP implementations to exchange their local | Option allows conforming TCP implementations to exchange their local | |||
user timeouts. This exchange provides an in-protocol mechanism to | user timeouts. This is an in-protocol mechanism to allow a host to | |||
coordinate raising or lowering the two user timeouts of a connection. | modify its local user timeout for a connection based on knowledge of | |||
Increase the user timeouts allows established TCP connections to | the peer's user timeout. Increasing the user timeouts allows | |||
survive extended periods of disconnection. Decreasing user timeouts | established TCP connections to survive extended periods of | |||
allows busy servers to explicitly notify their clients that they will | disconnection. Decreasing user timeouts allows busy servers to | |||
maintain the connection state only across short periods of | explicitly notify their clients that they will maintain the | |||
disconnection. | connection state only across short periods of disconnection. | |||
Table of Contents | ||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | ||||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | ||||
3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 | ||||
3.2. Reliability Considerations . . . . . . . . . . . . . . . . 8 | ||||
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
3.4. Special Option Values . . . . . . . . . . . . . . . . . . 9 | ||||
4. Additional Considerations . . . . . . . . . . . . . . . . . . 9 | ||||
5. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 | ||||
5.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
5.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 | ||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | ||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | ||||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | ||||
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 | ||||
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . | ||||
Appendix A. Document Revision History . . . . . . . . . . . . . . 15 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 17 | ||||
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 a network disconnection lasts longer than the | and SEND calls. If a network disconnection lasts longer than the | |||
user timeout, no acknowledgments will be received for any | user timeout, no acknowledgments will be received for any | |||
transmission attempt, including keep-alives [TCP-ILLU], and the TCP | transmission attempt, including keep-alives [TCP-ILLU], and the TCP | |||
connection will close when the user timeout occurs. In the absence | connection will close when the user timeout occurs. In the absence | |||
of an application-specified user timeout, the TCP specification | of an application-specified user timeout, the TCP specification | |||
[RFC0793] defines a default user timeout of 5 minutes. | [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 notify | retransmissions of a single segment. It suggests that TCP should | |||
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 refines 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 applications may set their local user timeout, there is no | Although some TCP implementations allow applications to set their | |||
in-protocol mechanism to signal changes in the local user timeout to | local user timeout, e.g., through the SO_SNDTIMEO socket option, | |||
remote peers. This causes local changes to be ineffective, because, | there is no in-protocol mechanism to signal changes in the local user | |||
for example, the peer will still close the connection after its user | timeout to remote peers. This causes local changes to be | |||
timeout expires, even when a host has raised its local user timeout. | ineffective, because the peer will still close the connection after | |||
The ability to modify the two user timeouts associated with a | its user timeout expires, even when a host has raised its local user | |||
connection in a coordinated manner can improve TCP operation in | timeout. The ability to modify the two user timeouts associated with | |||
scenarios that are currently not well supported. One example of such | a connection can improve TCP operation in scenarios that are | |||
scenarios are mobile hosts that change network attachment points | currently not well supported. One example of such scenarios are | |||
based on current location. Such hosts, maybe using MobileIP | mobile hosts that change network attachment points based on current | |||
[RFC3344], HIP [I-D.ietf-hip-arch] or transport-layer mobility | location. Such hosts, maybe using MobileIP [RFC3344], HIP [I-D.ietf- | |||
mechanisms [I-D.eddy-tcp-mobility], are only intermittently connected | hip-arch] or transport-layer mobility mechanisms [I-D.eddy-tcp- | |||
to the Internet. In between connected periods, mobile hosts may | mobility], are only intermittently connected to the Internet. In | |||
experience periods of disconnection during which no network service | between connected periods, mobile hosts may experience periods of | |||
is available [SCHUETZ-THESIS][SCHUETZ-CCR][DRIVE-THRU]. Other | disconnection during which no network service is available [SCHUETZ- | |||
factors that can cause transient periods of disconnection are high | THESIS][SCHUETZ-CCR][DRIVE-THRU]. Other factors that can cause | |||
levels of congestion as well as link or routing failures inside the | transient periods of disconnection are high levels of congestion as | |||
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 satellite might | |||
experience disconnections due to line-of-sight blocking by other | experience disconnections due to line-of-sight blocking by other | |||
planetary bodies. The disconnection periods of such a node may be | planetary bodies. The disconnection periods of such a node may be | |||
easily computable from orbital mechanics. | easily computable from orbital mechanics. | |||
skipping to change at page 3, line 28 | skipping to change at page 4, line 23 | |||
connection user timeout information. This allows, for example, | connection user timeout information. This allows, for example, | |||
mobile hosts to maintain TCP connections across disconnected periods | mobile hosts to maintain TCP connections across disconnected periods | |||
that are longer than their peer's default user timeout. A second use | that are longer than their peer's default user timeout. A second use | |||
of the TCP User Timeout Option is advertisement of shorter-than- | of the TCP User Timeout Option is advertisement of shorter-than- | |||
default user timeouts. This can allow busy servers to explicitly | default user timeouts. This can allow busy servers to explicitly | |||
notify their clients that they will maintain the state associated | notify their clients that they will maintain the state associated | |||
with established connections only across short periods of | with established connections only across short periods of | |||
disconnection. | disconnection. | |||
The same benefits can be obtained through an application-layer | The same benefits can be obtained through an application-layer | |||
mechanism, i.e., coordinating changes to the user timeout values of a | mechanism, i.e., exchanging user timeout information via application | |||
connection through application messages. This approach does not | messages and having the application adjust the user timeouts through | |||
require a new TCP option, but requires application changes. | the TCP API on both sides of a connection. This approach does not | |||
require a new TCP option, but requires changing all application | ||||
implementations that desire to tolerate extended periods of | ||||
disconnection, and in most cases also requires a modification to the | ||||
corresponding application layer protocol. With the proposed TCP | ||||
option, application changes may not be necessary at all, or may be | ||||
restricted to sender- or receiver-side only, and there is no need to | ||||
modify the corresponding application protocol. | ||||
A different approach to tolerate longer periods of disconnection is | A different approach to tolerate longer periods of disconnection is | |||
simply increasing the system-wide user timeout on both peers. This | to simply increase the system-wide user timeout on both peers. This | |||
approach has the benefit of not requiring a new TCP option. However, | approach has the benefit of not requiring a new TCP option or | |||
it can also significantly increase the amount of connection state | application changes. However, it can also significantly increase the | |||
information a busy server must maintain, because a longer global | amount of connection state a busy server must maintain, because a | |||
timeout value will apply to all its connections. The proposed TCP | longer global timeout value will apply to all its connections. The | |||
User Timeout Option, on the other hand, allows hosts to selectively | proposed TCP User Timeout Option, on the other hand, allows hosts to | |||
manage the user timeouts of individual connections, reducing the | selectively manage the user timeouts of individual connections, | |||
amount of state they must maintain across disconnected periods. | 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 suggests that the remote peer | Sending a TCP User Timeout Option informs the remote peer of the | |||
SHOULD start using the indicated user timeout value for the | current local user timeout and suggests that the remote peer SHOULD | |||
corresponding connection. The user timeout value included in a TCP | start using the indicated user timeout value for the corresponding | |||
User Timeout Option specifies the requested user timeout during the | connection. The user timeout value included in a TCP User Timeout | |||
synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN- | Option specifies the requested user timeout during the synchronized | |||
WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other | states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE- | |||
states MUST use standard timeout values [RFC0793][RFC1122]. [anchor4] | WAIT, CLOSING, or LAST-ACK). Connections in other states MUST the | |||
default timeout values defined in [RFC0793][RFC1122].[anchor3] | ||||
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 forcefully close or abort | |||
connections at any time for any reason, whether or not they use | connections at any time for any reason, whether or not they use | |||
custom user timeouts or have suggested to the peer to use them. | custom user timeouts or have suggested the peer to use them. | |||
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 | ||||
shown that unknown options are correctly handled by the vast majority | ||||
of modern TCP stacks. It is thus not necessary to require | ||||
negotiation of the use of the TCP User Timeout Option during the | ||||
three-way handshake of a connection. | ||||
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 decides whether to change its local user timeout of the connection | |||
based on the received value. Generally, hosts should honor requests | based on the received value. Generally, hosts should honor requests | |||
for changes to the user timeout (see Section 3.3), unless security | for changes to the user timeout (see Section 3.1), unless security | |||
concerns, resource constraints or external policies indicate | concerns, resource constraints or external policies indicate | |||
otherwise (see Section 5). If so, hosts may ignore incoming TCP User | otherwise (see Section 6). If so, hosts may ignore incoming TCP User | |||
Timeout Options and use a different user timeout for the connection. | Timeout Options and use a different user timeout for the connection. | |||
When a host receives a TCP User Timeout Option, it first decides | When a host receives a TCP User Timeout Option, it first decides | |||
whether to change its local user timeout for the connection (see | whether to change its local user timeout for the connection - | |||
Section 3.3) and then decides whether to send a TCP User Timeout | Section 3.1 discusses the specifics of this choice - and then decides | |||
Option to its peer in response. If it has never sent a TCP User | whether to send a TCP User Timeout Option to its peer in response. | |||
Timeout Option to its peer during the lifetime of the connection or | If a host has never sent a TCP User Timeout Option to its peer during | |||
if it has changed its local user timeout, it SHOULD send TCP User | the lifetime of the connection, or if it has changed its local user | |||
Timeout Option with its current local user timeout to its peer. | timeout, it SHOULD send TCP User Timeout Option with its current | |||
[anchor5] | local user timeout to its peer. [anchor4] | |||
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 | ||||
shown that unknown options are correctly handled by the vast majority | ||||
of modern TCP stacks. It is thus not necessary to require | ||||
negotiation use of the TCP User Timeout Option for a connection. | ||||
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 SHOULD impose upper and lower limits on the user timeouts they | |||
use. Section 3.3 discusses user timeout limits. A TCP User Timeout | use. Section 3.1 discusses user timeout limits, and describes a | |||
Option with a value of zero (i.e., "now") is nonsensical and is used | recommended scheme to apply them. A TCP User Timeout Option with a | |||
for a special purpose, see Section 3.4. Section 3.3 discusses | value of zero (i.e., "now") is nonsensical and is used for a special | |||
potentially problematic effects of other user timeout durations. | purpose, see Section 3.4. Section 3.1 discusses potentially | |||
problematic effects of other user timeout durations. | ||||
3.1 Reliability Considerations | ||||
The TCP User Timeout Option is an advisory TCP option that does not | ||||
change processing for subsequent segments. Unlike other TCP options, | ||||
it need not be exchanged reliably. Consequently, the specification | ||||
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 is lost, the option may never reach the intended peer. | ||||
Implementations MAY implement local mechanisms to improve delivery | ||||
reliability, such as retransmitting the TCP User Timeout Option when | ||||
they retransmit the segment that originally carried it or "attaching" | ||||
the option to a byte in the stream and retransmitting the option | ||||
whenever that byte or its ACK are retransmitted. | ||||
It is important to note that although these mechanisms can improve | ||||
transmission reliability for the TCP User Timeout Option, they do not | ||||
guarantee delivery (a three-way handshake would be required for | ||||
this). Consequently, implementations MUST NOT assume that a TCP User | ||||
Timeout Option is reliably transmitted. | ||||
3.2 Option Format | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Kind = X | Length = 4 |G| User Timeout | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
(One tick mark represents one bit.) | ||||
Figure 1: Format of the TCP User Timeout Option | ||||
Figure 1 shows the format of the TCP User Timeout Option. It | ||||
contains these fields: | ||||
Kind (8 bits) | ||||
A TCP option number [RFC0793] to be assigned by IANA upon | ||||
publication of this document (see Section 6). | ||||
Length (8 bits) | ||||
Length of the TCP option in octets [RFC0793]; its value MUST be 4. | ||||
Granularity (1 bit) | ||||
Granularity bit, indicating the granularity of 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 | ||||
interval in the "User Timeout" field MUST be interpreted as | ||||
seconds. | ||||
User Timeout (15 bits) | 3.1. Changing the Local User Timeout | |||
Specifies the user timeout suggestion for this connection. It | ||||
MUST be interpreted as a 15-bit unsigned integer. The granularity | ||||
of the timeout (minutes or seconds) depends on the "G" field. | ||||
3.3 Duration of the User Timeout | When a host receives a TCP User Timeout Option, it MUST decide | |||
whether to change the local user timeout of the corresponding | ||||
connection. Application-requested user timeout values always take | ||||
precedence over timeout values received from the peer in a TCP User | ||||
Timeout Option. [anchor5] Consequently, unless the application on the | ||||
local host has requested a specific user timeout for the connection, | ||||
e.g., through a socket API call, hosts SHOULD adjust their local user | ||||
timeout in response to receiving a TCP User Timeout Option, as | ||||
described in the remainder of this section. If the local application | ||||
has requested a specific local user timeout, TCP implementations MUST | ||||
NOT change it in response to receiving a TCP User Timeout Option. In | ||||
this case, they SHOULD, however, notify the application about the | ||||
user timeout value received from the peer. | ||||
The TCP User Timeout Option allows hosts to exchange user timeout | The User Timeout Option specifies the user timeout in terms of time | |||
values from 1 second to over 9 hours at a granularity of seconds and | units, rather than in terms of number of retransmissions or round- | |||
from 1 minute to over 22 days at a granularity of minutes. (An | trip times (RTTs), as in most cases the periods of disconnection have | |||
option value of zero is reserved for a special purpose, see | to do with operation and mobility patterns, rather than with the | |||
Section 3.4.) | current network conditions [anchor6][anchor7]. Thus, the TCP User | |||
Timeout Option allows hosts to exchange user timeout values 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. (An option value of | ||||
zero is reserved for a 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 5 discusses the security implications of long timeout | time. Section 6 discusses the security implications of long timeout | |||
values. | values. | |||
To protect against these effects, implementations SHOULD impose | To protect against these effects, implementations SHOULD impose | |||
limits on the user timeout values they accept and use. The remainder | limits on the user timeout values they accept and use. The remainder | |||
of this section describes a RECOMMENDED scheme to limit user timeouts | of 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)) | |||
skipping to change at page 7, line 18 | skipping to change at page 7, line 30 | |||
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 | L_LIMIT | |||
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 the 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 the maximum of the two announced values will be | |||
adopted for the user timeout of the connection. The rationale is | adopted for the user timeout of the connection. The rationale is | |||
that choosing the maximum of the two values will let the connection | that choosing the maximum of the two values will let the connection | |||
survive longer periods of disconnection. If the TCP that announced | survive longer periods of disconnection. If the TCP that announced | |||
the lower of the two user timeout values did so in order to reduce | the lower of the two user timeout values did so in order to reduce | |||
the amount of TCP state information that must be kept on the host, it | the amount of TCP state information that must be kept on the host, it | |||
can, nevertheless, close or abort the connection whenever it wants. | can, nevertheless, close or abort the connection whenever it wants. | |||
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 6 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 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. | |||
3.4 Special Option Values | 3.2. Reliability Considerations | |||
The TCP User Timeout Option is an advisory TCP option that does not | ||||
change processing of subsequent segments. Unlike other TCP options, | ||||
it need not be exchanged reliably. Consequently, the specification | ||||
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 is lost, the option may never reach the intended peer. | ||||
Implementations MAY implement local mechanisms to improve delivery | ||||
reliability, such as retransmitting the TCP User Timeout Option when | ||||
they retransmit the segment that originally carried it, or | ||||
"attaching" the option to a byte in the stream and retransmitting the | ||||
option whenever that byte or its ACK are retransmitted. | ||||
It is important to note that although these mechanisms can improve | ||||
transmission reliability for the TCP User Timeout Option, they do not | ||||
guarantee delivery (a three-way handshake would be required for | ||||
this). Consequently, implementations MUST NOT assume that a TCP User | ||||
Timeout Option is reliably transmitted. | ||||
3.3. Option Format | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Kind = X | Length = 4 |G| User Timeout | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
(One tick mark represents one bit.) | ||||
Figure 1: Format of the TCP User Timeout Option | ||||
Figure 1 shows the format of the TCP User Timeout Option. It | ||||
contains these fields: | ||||
Kind (8 bits) | ||||
A TCP option number [RFC0793] to be assigned by IANA upon | ||||
publication of this document (see Section 7). | ||||
Length (8 bits) | ||||
Length of the TCP option in octets [RFC0793]; its value MUST be 4. | ||||
Granularity (1 bit) | ||||
Granularity bit, indicating the granularity of 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 | ||||
interval in the "User Timeout" field MUST be interpreted as | ||||
seconds. | ||||
User Timeout (15 bits) | ||||
Specifies the user timeout suggestion for this connection. It | ||||
MUST be interpreted as a 15-bit unsigned integer. The granularity | ||||
of the timeout (minutes or seconds) depends on the "G" field. | ||||
3.4. Special Option Values | ||||
Whenever it is legal to do so according to the specification in the | Whenever it is legal to do so according to the specification in the | |||
previous sections, TCP implementations MAY send a zero-second TCP | previous sections, TCP implementations MAY send a zero-second TCP | |||
User Timeout Option, i.e, with a "User Timeout" field of zero and a | User Timeout Option, i.e, with a "User Timeout" field of zero and a | |||
"Granularity" of zero. This signals their peers that they support | "Granularity" of zero. This signals their peers that they support | |||
the option, but do not suggest a specific user timeout value at that | the option, but do not suggest a specific user timeout value at that | |||
time. Essentially, a zero-second TCP User Timeout Option acts as a | time. Essentially, a zero-second TCP User Timeout Option acts as a | |||
"don't care" value. | "don't care" value. | |||
The receiver of a zero-second TCP User Timeout Option SHOULD perform | Thus, the sender SHOULD adapt its local user timeout according to the | |||
the RECOMMENDED strategy for calculating a new local USER_TIMEOUT | peer's UTO, and the receiver SHOULD continue using its local user | |||
described in Section 3.3 with a numeric value of zero seconds for | timeout. In order to achieve this, the receiver of a zero-second TCP | |||
REMOTE_UTO. The sender SHOULD perform the calculation as described | User Timeout Option SHOULD perform the RECOMMENDED strategy for | |||
in Section 3.3. Essentially, the sender SHOULD adapt the peer's UTO | calculating a new local USER_TIMEOUT described in Section 3.1, with a | |||
and the receiver SHOULD continue using its local UTO. | numeric value of zero seconds for REMOTE_UTO. The sender SHOULD | |||
perform the same calculation as described in Section 3.1, with a | ||||
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 sent it and MUST ignore it upon | use. TCP implementations MUST NOT send it and MUST ignore it upon | |||
reception. | reception. | |||
4. Interoperability Issues | 4. Additional Considerations | |||
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. | |||
4.1 Middleboxes | 5.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 contains a TCP User Timeout | |||
Option. Some recent results, however, indicate that for new TCP | Option. Some recent results, however, indicate that for new TCP | |||
options, this may not be a significant threat, with only 0.2% of web | options, this may not be a significant threat, with only 0.2% of web | |||
requests failing when carrying an unknown option [MEDINA]. | 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. | |||
4.2 TCP Keep-Alives | 5.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. | |||
5. Security Considerations | 6. 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. TCP | resources for maintaining the state of throw-away connections. | |||
implementations do not become more vulnerable to simple SYN flooding | However, TCP implementations do not become more vulnerable to simple | |||
by implementing the TCP User Timeout Option, because user timeouts | SYN flooding by implementing the TCP User Timeout Option, because | |||
negotiated during the handshake only affect the synchronized states | user timeouts exchanged during the handshake only affect the | |||
(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), | synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, | |||
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 [I-D.ietf-ipsec-rfc2401bis], before accepting long user | |||
timeouts for the peer's connections. Similarly, a host can only | timeouts for the peer's connections. Similarly, a host can start to | |||
start to accept long user timeouts for an established connection | accept long user timeouts for an established connection only after | |||
after in-band authentication has occurred, for example, after a TLS | in-band authentication has occurred, for example, after a TLS | |||
handshake across the connection has succeeded [RFC2246]. Although | handshake across the connection has succeeded [RFC2246]. Although | |||
these are arguably the most complete solutions, they depend on | these are arguably the most complete solutions, they depend on | |||
external mechanisms to establish a trust relationship. | external 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 | |||
skipping to change at page 10, line 22 | skipping to change at page 12, line 22 | |||
negatively affect service for intermittently connected, trusted peers | negatively affect service for intermittently connected, trusted peers | |||
that have suggested long user timeouts. On the other hand, resetting | that have suggested long user timeouts. On the other hand, resetting | |||
connections to untrusted peers that use long user timeouts may be | connections to untrusted peers that use long user timeouts may be | |||
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.3, 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. | |||
6. IANA Considerations | 7. 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. | |||
7. Acknowledgments | 8. Acknowledgments | |||
The following people have improved this document through thoughtful | The following people have improved this document through thoughtful | |||
suggestions: Mark Allmann, David Borman, Marcus Brunner, Wesley Eddy, | suggestions: Mark Allmann, David Borman, Bob Braden, Marcus Brunner, | |||
Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy | Wesley Eddy, Abolade Gbadegesin, Ted Faber, Guillermo Gont, Tom | |||
Harris, Phil Karn, Michael Kerrisk, Dan Krejsa, Kostas Pentikousis, | Henderson, Joseph Ishac, Jeremy Harris, Phil Karn, Michael Kerrisk, | |||
Juergen Quittek, Joe Touch, Stefan Schmid, Simon Schuetz and Martin | Dan Krejsa, Kostas Pentikousis, Juergen Quittek, Joe Touch, Stefan | |||
Stiemerling. | 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. | |||
8. References | 9. References | |||
8.1 Normative References | 9.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. | |||
8.2 Informative References | 9.2. Informative References | |||
[DRIVE-THRU] | [DRIVE-THRU] | |||
Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE | Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE | |||
802.11b for Automobile Users", Proc. Infocom , March 2004. | 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] | [I-D.ietf-hip-arch] | |||
Moskowitz, R., "Host Identity Protocol Architecture", | Moskowitz, R. and P. Nikander, "Host Identity Protocol | |||
draft-ietf-hip-arch-02 (work in progress), January 2005. | Architecture", draft-ietf-hip-arch-03 (work in progress), | |||
August 2005. | ||||
[I-D.ietf-ipsec-rfc2401bis] | [I-D.ietf-ipsec-rfc2401bis] | |||
Kent, S. and K. Seo, "Security Architecture for the | Kent, S. and K. Seo, "Security Architecture for the | |||
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work | Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work | |||
in progress), April 2005. | 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. | |||
skipping to change at page 12, line 22 | skipping to change at page 14, line 26 | |||
[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 | |||
[anchor4] LE: A future version of this document may extend per- | [anchor3] A future version of this document may extend per- | |||
connection user timeouts to the SYN-SENT and SYN-RECEIVED | connection user timeouts to the SYN-SENT and SYN-RECEIVED | |||
states in a way that conforms to the required minimum | states in a way that conforms to the required minimum | |||
timeouts. | timeouts. | |||
[anchor5] LE: Should it really always send UTO when it changes the | [anchor4] Should it really always send UTO when it changes the | |||
local timeout? I can imagine some ping-pong effect when | local timeout? I can imagine some ping-pong effect when | |||
two hosts user different UTO adoption strategies. But | two hosts user different UTO adoption strategies. But | |||
maybe that's OK? | 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 | ||||
requests. | ||||
[anchor6] When -01 was presented in Paris, Bob Braden suggested to | ||||
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 | ||||
network, and the disconnected periods last for, say, | ||||
about 15 minutes each. Let's suppose the attachment | ||||
points range from low-bandwidth/high-delay/congested | ||||
networks to high-bandwidth/low-delay networks. If the UTO | ||||
specified the user timeout in terms of number of | ||||
retransmissions or round-trip times, an UTO that is | ||||
appropriate for the high-bandwith/low-delay networks | ||||
would be too small for the low-bandwidth/high-delay/ | ||||
congested networks. Also, even if the host kept connected | ||||
to the same network, if the network conditions changed, | ||||
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 | ||||
TCP spec? Or should the SO_RCVTIMEO discussion be | ||||
removed? | ||||
Appendix A. Document Revision History | ||||
To be removed upon publication | ||||
+----------+--------------------------------------------------------+ | ||||
| Revision | Comments | | ||||
+----------+--------------------------------------------------------+ | ||||
| 02 | Corrected terminology by replacing terms like | | ||||
| | "negotiate", "coordinate", etc. that were left from | | ||||
| | pre-WG-document times when the UTO was a more | | ||||
| | formalized exchange instead of the advisory one it is | | ||||
| | now. Application-requested UTOs take precedence over | | ||||
| | ones received from the peer (pointed out by Ted | | ||||
| | Faber). Added a brief mention of SO_SNDTIMEO and a | | ||||
| | slightly longer discussion of SO_RCVTIMEO. | | ||||
| 01 | Clarified and corrected the description of the | | ||||
| | existing user timeout in RFC793 and RFC1122. Removed | | ||||
| | distinction between operating during the 3WHS and the | | ||||
| | established states and introduced zero-second "don't | | ||||
| | care" UTOs in response to mailing list feedback. | | ||||
| | Updated references and addressed many other comments | | ||||
| | from the mailing list. | | ||||
| 00 | Resubmission of | | ||||
| | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | | ||||
| | secretariat after WG adoption. Thus, permit | | ||||
| | derivative works. Updated Lars Eggert's funding | | ||||
| | attribution. Updated several references. No | | ||||
| | technical changes. | | ||||
+----------+--------------------------------------------------------+ | ||||
Authors' Addresses | Authors' Addresses | |||
Lars Eggert | Lars Eggert | |||
NEC Network Laboratories | NEC Network Laboratories | |||
Kurfuerstenanlage 36 | Kurfuerstenanlage 36 | |||
Heidelberg 69115 | Heidelberg 69115 | |||
Germany | Germany | |||
Phone: +49 6221 90511 43 | Phone: +49 6221 90511 43 | |||
skipping to change at page 13, line 14 | skipping to change at page 17, line 5 | |||
Fernando Gont | Fernando Gont | |||
Universidad Tecnologica Nacional | Universidad Tecnologica Nacional | |||
Evaristo Carriego 2644 | Evaristo Carriego 2644 | |||
Haedo, Provincia de Buenos Aires 1706 | Haedo, Provincia de Buenos Aires 1706 | |||
Argentina | Argentina | |||
Phone: +54 11 4650 8472 | Phone: +54 11 4650 8472 | |||
Email: fernando@gont.com.ar | Email: fernando@gont.com.ar | |||
URI: http://www.gont.com.ar/ | URI: http://www.gont.com.ar/ | |||
Appendix A. Document Revision History | ||||
To be removed upon publication | ||||
+-----------+-------------------------------------------------------+ | ||||
| Revision | Comments | | ||||
+-----------+-------------------------------------------------------+ | ||||
| 00 | Resubmission of | | ||||
| | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | | ||||
| | secretariat after WG adoption. Thus, permit | | ||||
| | derivative works. Updated Lars Eggert's funding | | ||||
| | attribution. Updated several references. No technical | | ||||
| | changes. | | ||||
| 01 | Clarified and corrected the description of the | | ||||
| | existing user timeout in RFC793 and RFC1122. Removed | | ||||
| | distinction between operating during the 3WHS and the | | ||||
| | established states and introduced zero-second "don't | | ||||
| | care" UTOs in response to mailing list feedback. | | ||||
| | Updated references and addressed many other comments | | ||||
| | from the mailing list. | | ||||
+-----------+-------------------------------------------------------+ | ||||
Intellectual Property Statement | Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
End of changes. 41 change blocks. | ||||
192 lines changed or deleted | 313 lines changed or added | |||
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |