idnits 2.17.1 draft-gont-tcpm-connection-delays-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 29, 2009) is 5528 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor F. Gont 3 Extensions (tcpm) UTN/FRH 4 Internet-Draft January 29, 2009 5 Intended status: Informational 6 Expires: August 2, 2009 8 On the problem of long delays between connection-establishment attempts 9 in TCP 10 draft-gont-tcpm-connection-delays-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 2, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document discusses a number of solutions to the problem of long 50 delays between connection establishment attempts in TCP. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. A more conservative approach . . . . . . . . . . . . . . . . . 3 56 3. Asynchronous Application Notification . . . . . . . . . . . . . 4 57 4. Issuing several connection requests in parallel . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 This document discusses a number of alternative solutions to the one 69 proposed in [I-D.ietf-tcpm-tcp-soft-errors] for the problem of long 70 delays between connection establishment attempts in TCP. 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 2. A more conservative approach 78 A more conservative approach would be to abort a connection in the 79 SYN-SENT or SYN-RECEIVED states only after an ICMP Destination 80 Unreachable has been received a specified number of times, and the 81 SYN segment has been retransmitted more than some specified number of 82 times. 84 Two new parameters would have to be introduced to TCP, to be used 85 only during the connection-establishment phase: MAXSYNREXMIT and 86 MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN 87 segment would have to be retransmitted before a connection is 88 aborted. MAXSOFTERROR would specify the number of ICMP messages 89 indicating soft errors that would have to be received before a 90 connection is aborted. 92 Two additional variables would need to be introduced to store 93 additional state information during the connection-establishment 94 phase: "nsynrexmit" and "nsofterror". Both would be initialized to 95 zero. "nsynrexmit" would be incremented by one every time the SYN 96 segment is retransmitted. "nsofterror" would be incremented by one 97 every time an ICMP message that indicates a soft error is received. 99 A connection in the SYN-SENT or SYN-RECEIVED states would be aborted 100 if nsynrexmit was greater than MAXSYNREXMIT and "nsofterror" was 101 simultaneously greater than MAXSOFTERROR. 103 This approach would give the network more time to solve the 104 connectivity problem. However, it should be noted that depending on 105 the values chosen for the MAXSYNREXMIT and MAXSOFTERROR parameters, 106 this approach could still lead to long delays between connection 107 establishment attempts, thus not solving the problem. For example, 108 BSD systems abort connections in the SYN-SENT or the SYN-RECEIVED 109 state when a second ICMP error is received, and the SYN segment has 110 been retransmitted more than three times. They also set up a 111 "connection-establishment timer" that imposes an upper limit on the 112 time the connection establishment attempt has to succeed, which 113 expires after 75 seconds [Stevens2]. Even when this policy may be 114 better than the three-minutes timeout policy specified in [RFC1122], 115 it may still be inappropriate for handling the potential problems 116 described in this document. This more conservative approach has been 117 implemented in BSD systems since, at least, 1994 [Stevens2]. 119 3. Asynchronous Application Notification 121 In section 4.2.4.1, [RFC1122] states that there MUST be a mechanism 122 for reporting soft TCP error conditions to the application. Such a 123 mechanism (assuming one is implemented) could be used by applications 124 to cycle through the destination IP addresses. However, this 125 approach would increase application complexity, and would take a long 126 time to kick in, as it would require all existing applications to be 127 modified. 129 4. Issuing several connection requests in parallel 131 For those scenarios in which a domain name maps to several IP 132 addresses, several connection requests could be issued in parallel, 133 each one to a different destination IP address. The host would then 134 use the first connection attempt to succeed, eliminating the 135 potential delay in establishing a connection with the destination 136 host. However, this would mean that every attempt to connect to a 137 multihomed host would imply sending several SYN segments, making it 138 hard for network operators to distinguish valid connection attempts 139 from those performing Denial of Service (DoS) attacks. 141 An alternative approach would be as follows. A host would issue a 142 connection request to the first IP address in the list returned by 143 the name-to-address mapping function. If this connection request 144 didn't succeed in some time, a connection request to the second IP 145 address in the list would be issued in parallel. If none of these 146 connection requests succeeded in some time, and there were still more 147 addresses left in the list, they would be tried in the same way. 148 While this approach would, in principle, avoid the problems of the 149 previous approach, it might be hard to define the time interval to 150 wait before issuing each parallel connection request. A short time 151 interval would lead to the problems caused by the previous approach, 152 while a long time interval would likely still lead to long delays in 153 establishing a connection with the destination host. In any case, it 154 must be noted that both approaches have the same drawbacks as the 155 solution described in Section 2: they would increase application 156 complexity, and would take too long to begin to be used by 157 applications. 159 5. Security Considerations 161 To be included in future revisions of this document. 163 6. IANA Considerations 165 This document has no actions for IANA. 167 7. Acknowledgements 169 8. References 171 8.1. Normative References 173 [RFC1122] Braden, R., "Requirements for Internet Hosts - 174 Communication Layers", STD 3, RFC 1122, October 1989. 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 8.2. Informative References 181 [I-D.ietf-tcpm-tcp-soft-errors] 182 Gont, F., "TCP's Reaction to Soft Errors", 183 draft-ietf-tcpm-tcp-soft-errors-09 (work in progress), 184 November 2008. 186 [Stevens2] 187 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 188 The Implementation", Addison-Wesley , 1994. 190 Author's Address 192 Fernando Gont 193 Universidad Tecnologica Nacional / Facultad Regional Haedo 194 Evaristo Carriego 2644 195 Haedo, Provincia de Buenos Aires 1706 196 Argentina 198 Phone: +54 11 4650 8472 199 Email: fernando@gont.com.ar 200 URI: http://www.gont.com.ar