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