TCP Maintenance and Minor F. Gont Extensions (tcpm) UTN/FRH Internet-Draft January 29, 2009 Intended status: Informational Expires: August 2, 2009 On the problem of long delays between connection-establishment attempts in TCP draft-gont-tcpm-connection-delays-00.txt 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." 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 August 2, 2009. Copyright Notice Copyright (c) 2009 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. Gont Expires August 2, 2009 [Page 1] Internet-Draft Connection-delays in TCP January 2009 Abstract This document discusses a number of solutions to the problem of long delays between connection establishment attempts in TCP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. A more conservative approach . . . . . . . . . . . . . . . . . 3 3. Asynchronous Application Notification . . . . . . . . . . . . . 4 4. Issuing several connection requests in parallel . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Gont Expires August 2, 2009 [Page 2] Internet-Draft Connection-delays in TCP January 2009 1. Introduction This document discusses a number of alternative solutions to the one proposed in [I-D.ietf-tcpm-tcp-soft-errors] for the problem of long delays between connection establishment attempts in TCP. 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 RFC 2119 [RFC2119]. 2. A more conservative approach A more conservative approach would be to abort a connection in the SYN-SENT or SYN-RECEIVED states only after an ICMP Destination Unreachable has been received a specified number of times, and the SYN segment has been retransmitted more than some specified number of times. Two new parameters would have to be introduced to TCP, to be used only during the connection-establishment phase: MAXSYNREXMIT and MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN segment would have to be retransmitted before a connection is aborted. MAXSOFTERROR would specify the number of ICMP messages indicating soft errors that would have to be received before a connection is aborted. Two additional variables would need to be introduced to store additional state information during the connection-establishment phase: "nsynrexmit" and "nsofterror". Both would be initialized to zero. "nsynrexmit" would be incremented by one every time the SYN segment is retransmitted. "nsofterror" would be incremented by one every time an ICMP message that indicates a soft error is received. A connection in the SYN-SENT or SYN-RECEIVED states would be aborted if nsynrexmit was greater than MAXSYNREXMIT and "nsofterror" was simultaneously greater than MAXSOFTERROR. This approach would give the network more time to solve the connectivity problem. However, it should be noted that depending on the values chosen for the MAXSYNREXMIT and MAXSOFTERROR parameters, this approach could still lead to long delays between connection establishment attempts, thus not solving the problem. For example, BSD systems abort connections in the SYN-SENT or the SYN-RECEIVED state when a second ICMP error is received, and the SYN segment has been retransmitted more than three times. They also set up a "connection-establishment timer" that imposes an upper limit on the time the connection establishment attempt has to succeed, which Gont Expires August 2, 2009 [Page 3] Internet-Draft Connection-delays in TCP January 2009 expires after 75 seconds [Stevens2]. Even when this policy may be better than the three-minutes timeout policy specified in [RFC1122], it may still be inappropriate for handling the potential problems described in this document. This more conservative approach has been implemented in BSD systems since, at least, 1994 [Stevens2]. 3. Asynchronous Application Notification In section 4.2.4.1, [RFC1122] states that there MUST be a mechanism for reporting soft TCP error conditions to the application. Such a mechanism (assuming one is implemented) could be used by applications to cycle through the destination IP addresses. However, this approach would increase application complexity, and would take a long time to kick in, as it would require all existing applications to be modified. 4. Issuing several connection requests in parallel For those scenarios in which a domain name maps to several IP addresses, several connection requests could be issued in parallel, each one to a different destination IP address. The host would then use the first connection attempt to succeed, eliminating the potential delay in establishing a connection with the destination host. However, this would mean that every attempt to connect to a multihomed host would imply sending several SYN segments, making it hard for network operators to distinguish valid connection attempts from those performing Denial of Service (DoS) attacks. An alternative approach would be as follows. A host would issue a connection request to the first IP address in the list returned by the name-to-address mapping function. If this connection request didn't succeed in some time, a connection request to the second IP address in the list would be issued in parallel. If none of these connection requests succeeded in some time, and there were still more addresses left in the list, they would be tried in the same way. While this approach would, in principle, avoid the problems of the previous approach, it might be hard to define the time interval to wait before issuing each parallel connection request. A short time interval would lead to the problems caused by the previous approach, while a long time interval would likely still lead to long delays in establishing a connection with the destination host. In any case, it must be noted that both approaches have the same drawbacks as the solution described in Section 2: they would increase application complexity, and would take too long to begin to be used by applications. Gont Expires August 2, 2009 [Page 4] Internet-Draft Connection-delays in TCP January 2009 5. Security Considerations To be included in future revisions of this document. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements 8. References 8.1. Normative References [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-tcpm-tcp-soft-errors] Gont, F., "TCP's Reaction to Soft Errors", draft-ietf-tcpm-tcp-soft-errors-09 (work in progress), November 2008. [Stevens2] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley , 1994. Author's Address Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fernando@gont.com.ar URI: http://www.gont.com.ar Gont Expires August 2, 2009 [Page 5]