--- 1/draft-ietf-tcpm-tcp-uto-07.txt 2007-11-19 12:13:52.000000000 +0100 +++ 2/draft-ietf-tcpm-tcp-uto-08.txt 2007-11-19 12:13:52.000000000 +0100 @@ -1,19 +1,19 @@ TCP Maintenance and Minor L. Eggert Extensions (tcpm) Nokia Internet-Draft F. Gont Intended status: Standards Track UTN/FRH -Expires: May 16, 2008 November 13, 2007 +Expires: May 22, 2008 November 19, 2007 TCP User Timeout Option - draft-ietf-tcpm-tcp-uto-07 + draft-ietf-tcpm-tcp-uto-08 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,21 +24,21 @@ 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 May 16, 2008. + This Internet-Draft will expire on May 22, 2008. 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 @@ -65,21 +65,21 @@ 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Document Revision History . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . . . 16 + Intellectual Property and Copyright Statements . . . . . . . . . . 17 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 longer than the user timeout, no acknowledgments will be received for @@ -115,21 +115,21 @@ Although some TCP implementations allow applications to set their local user timeout, TCP has no in-protocol mechanism to signal changes to the local user timeout to the other end of a connection. This causes local changes to be ineffective in allowing a connection to survive extended periods without connectivity, because the other end will still close the connection after its user timeout expires. The ability to inform the other end of a connection about the local user timeout can improve TCP operation in scenarios that are - currently not well supported. One example of such scenarios are + currently not well supported. One example of such a scenario is mobile hosts that change network attachment points based on current location. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423] or transport-layer mobility mechanisms [I-D.eddy-tcp-mobility], are only intermittently connected to the Internet. In between connected periods, mobile hosts may experience periods without end-to-end connectivity. Other factors that can cause transient connectivity disruptions are high levels of congestion or link or routing failures inside the network. In these scenarios, a host may not know exactly when or for how long connectivity disruptions will occur, but it might be able to determine an increased likelihood for such events @@ -162,41 +162,41 @@ 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 defaults 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 USER_TIMEOUT (TCP's USER_TIMEOUT + Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT parameter) may be changed based on an UTO option received from the other end of the connection. 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 of the connection has explicitly allowed it (both ENABLED and CHANGEABLE are true). Before opening a connection, an application that wishes to use the UTO option enables its use by setting ENABLED to true. It may choose an appropriate local UTO by explicitly setting ADV_UTO; otherwise, UTO is 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 of a connection. The default is to allow this for connections that do not have specific user timeout concerns. If an application - explicitly sets the USER TIMEOUT, CHANGEABLE MUST become false, to + explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false, to prevent UTO options from the other end to override local application requests. Alternatively, applications can set or clear CHANGEABLE directly through socket API calls. 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. TCP implementations MAY provide system-wide default settings for the ENABLED, ADV_UTO and CHANGEABLE connection parameters. @@ -292,22 +292,22 @@ 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. The RECOMMENDED formula results in the maximum of the two advertised - values to be adopted for the user timeout of the connection on both - ends, provided they are within the upper and lower limits. The + values, adjusted for the configured upper and lower limits, to be + adopted for the user timeout of the connection on both ends. 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 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. @@ -525,24 +525,20 @@ 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, 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 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 [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-08 (work in progress), October 2007. @@ -591,64 +587,74 @@ Sun Microsystems, "Solaris Tunable Parameters Reference Manual", Part No. 806-7009-10, 2002. Appendix A. Document Revision History [[Note to the RFC Editor: Section to be removed upon publication.]] +----------+--------------------------------------------------------+ | Revision | Comments | +----------+--------------------------------------------------------+ - | 07 | Addressed working group last call comments. | - | 06 | Includes a note on the limited space for TCP options | - | | and miscelaneous editorial changes(suggested by | + | -08 | Addressed additional, minor working group last call | + | | comments. | + | | | + | -07 | Addressed working group last call comments. | + | | | + | -06 | Includes a note on the limited space for TCP options | + | | and miscellaneous 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 | + | | consensus 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 | + | | | + | -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 | + | | | + | -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 | | | 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 | + | | | + | -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 | + | | | + | -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 | + | | | + | -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 Lars Eggert