Network Working Group H. Kitamura Internet-Draft NEC Corporation Intended status: Standards Track S. Ata Expires: September 2015 Osaka City University M. Murata Osaka University March 9, 2015 "Sharp Close": Elimination of TIME-WAIT state of TCP connections Abstract This document describes an idea "Sharp Close" that eliminates or minimizes TIME-WAIT state of TCP connections. In the current TCP specification ([RFC0793]), there are some inappropriate or not up to date functions. Here we focus and discuss on TCP TIME-WAIT state function. TIME-WAIT is the last state of TCP connection of Active Close side node. After TCP connections are effectively closed, they move to TIME-WAIT state. After TIME-WAIT state is finished, resources of connections are released. This means that even if connections are effectively finished, resources of connections are NOT released. The TIME-WAIT state prevents from releasing them. From the viewpoints of current high-speed and high-multiplicity communication styles, it is thought that TIME-WAIT state is one of evil functions. In order to provide efficient communication that matches current styles, an idea "Sharp Close" that eliminates or minimizes TIME- WAIT state of TCP connections is proposed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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." H. Kitamura Expires September 2015 [Page 1] Internet Draft Sharp Close 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 April 2013. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Analysis of current TIME-WAIT state . . . . . . . . . . . . . . 3 3. Why we need TIME-WAIT state? . . . . . . . . . . . . . . . . . 5 4. Design of "Sharp Close" (elimination of TIME-WAIT state) . . . 6 5. Eliminate TIME-WAIT state by setsockopt() . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Implementations . . . . . . . . . . . . . . . . . . . 8 1. Introduction This document describes an idea "Sharp Close" that eliminates or minimizes TIME-WAIT state of TCP connections. In the current TCP specification ([RFC0793]), there are some inappropriate or not up to date functions. Here we focus and discuss on TCP TIME-WAIT state function. TIME-WAIT is the last state of TCP connection of Active Close side node. After TCP connections are effectively closed, they move to last TIME-WAIT state. [RFC0793] defines that the connections stay there 2MSL(Maximum Segment Lifetime) seconds. (2MSL = 240 sec.) H. Kitamura Expires September 2015 [Page 2] Internet Draft Sharp Close After TIME-WAIT state is finished, resources of connections are released. This means that even if connections are effectively finished, resources of connections are NOT released. The TIME-WAIT state prevents from releasing them. From the viewpoints of current high-speed and high-multiplicity communication styles that requires highly resource recycling, it is thought that TIME-WAIT state is one of evil functions. In order to provide efficient communication that matches current styles, an idea "Sharp Close" that eliminates or minimizes TIME- WAIT state of TCP connections is proposed. In the following sections, analysis of current TIME-WAIT state and design of "Sharp Close" etc. are described. 2. Analysis of current TIME-WAIT state ACTIVE CLOSE PASSIVE CLOSE side side | | ESTABLISH | | ESTABLISH _________________|_ FIN | | \__ | | \__ | | \__ | FIN-WAIT-1 | \_|__________________ | __/ | | __/ACK | CLOSE-WAIT | __/ _|__________________ _________________|_/ __/ | | __/FIN | FIN-WAIT-2 | __/ | _________________|_/ | LAST-ACK | | \_ACK | | | \__ | | | \__ | 2MSL TIME-WAIT | \_|__________________ | | | | | | | | | CLOSED __V______________| | | | CLOSED | | | | Fig. 1 Current ACTIVE-PASSIVE Close Sequence H. Kitamura Expires September 2015 [Page 3] Internet Draft Sharp Close ACTIVE CLOSE ACTIVE CLOSE side side | | ESTABLISH | | ESTABLISH _________________|_ FIN | | \__ FIN_|__________________ | \__ __/ | FIN-WAIT-1 | __X__ | FIN-WAIT-1 | __/ \_|__________________ _________________|_/ __/ | | \_ACK_/ACK | CLOSING | __\/_ | CLOSING _________________|_/ \__ | | | \_|__________________ | | | | | | | | 2MSL TIME-WAIT | | | | | | TIME-WAIT 2MSL | | | | | | | | __V______________| | | | |_______________V__ CLOSED | | | | CLOSED | | Fig. 2 Current ACTIVE-ACTIVE Close Sequence Fig. 1 and Fig. 2 show Close Sequence that is defined by current specification [RFC0793]. TCP connections on ACTIVE CLOSE node (that initiates sending FIN) side reach TIME-WAIT as a last state. They wait there 2MSL seconds. Table 1 Actual 2MSL values used by major OS implementation. +-------------+-----------+ | RFC/OS | 2MSL value| +=============+===========+ | [RFC0793] | 240 sec.| +-------------+-----------+ | Windows2000 | 240 sec.| +-------------+-----------+ | Windows | | |(after Win2K)| 120 sec.| +-------------+-----------+ | Unix/Linux | 60 sec.| +-------------+-----------+ H. Kitamura Expires September 2015 [Page 4] Internet Draft Sharp Close Table 1 shows actual 2MSL values that are surveyed by authors. [RFC0793] says "For this specification the MSL is taken to be 2 minutes." Since 240 sec. ([RFC0793]) is long time, recent major OSes adopt rather shorter time. However, from the viewpoints of current communication styles that require highly resource recycling, TIME-WAIT time is still too long. Now, it is almost thought that staying at TIME-WAIT state is waste of time. 3. Why we need TIME-WAIT state? Basically, TIME-WAIT state is designed for !fail-safe! purpose. If we assume there is no packet sending order change, all of data packets from a corresponding node are received at FIN-WAIT-2 state. At TIME-WAIT state, an ACTIVE CLOSE node waits for a resending control packet FIN only from the corresponding node. (No data packets are waited for.) Only when the last packet ACK from the ACTIVE CLOSE node is lost, resending control packet FIN from the corresponding node is issued. It is rare case to happen this event at current stable network environment. Since all data from the corresponding node is received by the ACTIVE CLOSE node, it is less significant issue to wait for resending FIN packet. If resending FIN is NOT waited at ACTIVE CLOSE node and resending FIN is issued from the corresponding node, significant problem will NOT be happened, only RST packet (to notifiy receiving unexpected packet) will be issued from the ACTIVE CLOSE node. H. Kitamura Expires September 2015 [Page 5] Internet Draft Sharp Close 4. Design of "Sharp Close" (elimination of TIME-WAIT state) ACTIVE CLOSE PASSIVE CLOSE side side | | ESTABLISH | | ESTABLISH _________________|_ FIN | | \__ | | \__ | | \__ | FIN-WAIT-1 | \_|__________________ | __/ | | __/ACK | CLOSE-WAIT | __/ _|__________________ _________________|_/ __/ | | __/FIN | FIN-WAIT-2 | __/ | _________________|_/ | LAST-ACK (NO) TIME-WAIT | \_ACK | | \__ | CLOSED | \__ | | \_|__________________ | | | | CLOSED | | Fig. 3 (Proposed) Sharp ACTIVE-PASSIVE Close Sequence ACTIVE CLOSE ACTIVE CLOSE side side | | ESTABLISH | | ESTABLISH _________________|_ FIN | | \__ FIN_|__________________ | \__ __/ | FIN-WAIT-1 | __X__ | FIN-WAIT-1 | __/ \_|__________________ _________________|_/ __/ | | \_ACK_/ACK | CLOSING | __\/_ | CLOSING _________________|_/ \__ | (NO) TIME-WAIT | \_|__________________ | | (NO) TIME-WAIT CLOSED | | | | CLOSED Fig. 4 (Proposed) Sharp ACTIVE-ACTIVE Close Sequence H. Kitamura Expires September 2015 [Page 6] Internet Draft Sharp Close It is easy to design "Sharp Close" function. "Sharp Close" function is achieved by eliminating or minimizing TIME-WAIT state of TCP connections. Fig. 3 and Fig. 4. show Close Sequence that is defined by "Sharp Close" function. 5. Eliminate TIME-WAIT state by setsockopt() Under current implementation, TIME-WAIT (close()) action can be controlled by setsockopt() function. SO_LINGER option of setsockopt() can eliminate TIME-WAIT state and close connections immediately. Concrete procedures how to eliminate TIME-WAIT: Fig. 5 shows struct socket in struct linger { int l_onoff; /* linger active */ int l_linger; /* how many seconds to linger for */ }; Fig. 5. struct linger 1. makes linger active(on) l_onoff = on; 2, sets linger time to 0 l_linger = 0 ; With above shown procedure, TIME-WAIT state is eliminated and connections are closed immediately. It is possible to eliminate TIME-WAIT state. However, this behavior is "NOT default" operation. In order to utilize this feature, it is necessary to modify huge number of communication applications. Furthermore, this feature is not implemented on every existing OSes and it is not always possible to eliminate TIME-WAIT state on every OSes. H. Kitamura Expires September 2015 [Page 7] Internet Draft Sharp Close 6. Security Considerations Goals of the proposed idea ("Sharp Close") are to eliminate or minimize TIME-WAIT state by default on OS kernel level. From functional viewpoints, the same concept to eliminate TIME-WAIT state is already implemented by using LINGER option of setsockopt() function. It is not default operation, however it is already worked. So, there are no new Security Consideration issues that should be discussed here. 7. IANA Considerations This document does not require any resource assignments to IANA. Acknowledgment A part of this work is supported by the program: SCOPE (Strategic Information and Communications R&D Promotion Programme) operated by Ministry of Internal Affairs and Communications of JAPAN. Appendix A. Implementations Currently, above described "Sharp Close" functions have been implemented and verified under the following OS. Ubuntu 13.04 (kernel 3.8.13.8) References Normative References [RFC0793] "Transmission Control Protocol", RFC 0793, September 1981 [RFC3513] R. Hinden and S.Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003 [RFC3493] R. Gilligan, S. Thomson, J. Bound, J. McCann and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC3493, February 2003 Informative References [RFC3542] W. Stevens, M. Thomas, E. Nordmark and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003 H. Kitamura Expires September 2015 [Page 8] Internet Draft Sharp Close Authors' Addresses Hiroshi Kitamura Cloud System Research Laboratories, NEC Corporation (SC building 12F)1753, Shimonumabe, Nakahara-Ku, Kawasaki, Kanagawa 211-8666, JAPAN Phone: +81 44 431 7686 Fax: +81 44 431 7680 Email: kitamura@da.jp.nec.com Shingo Ata Graduate School of Engineering, Osaka City University 3-3-138, Sugimoto, Sumiyoshi-Ku, Osaka 558-8585, JAPAN Phone: +81 6 6605 2191 Fax: +81 6 6605 2191 Email: ata@info.eng.osaka-cu.ac.jp Masayuki Murata Graduate School of Information Science and Technology, Osaka Univ. 1-5 Yamadaoka, Suita, Osaka 565-0871, JAPAN Phone: +81 6 6879 4542 Fax: +81 6 6879 4544 Email: murata@ist.osaka-u.ac.jp H. Kitamura Expires September 2015 [Page 9]