[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
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]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/