Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jul 1998 21:16:43 -0400 (EDT)
From:      Open Systems Networking <opsys@mail.webspan.net>
To:        freebsd-net@FreeBSD.ORG
Subject:   RFC 1337: Time-wait assassination (fwd)
Message-ID:  <Pine.BSF.3.95.980716211457.5542A-100000@orion.webspan.net>

next in thread | raw e-mail | index | archive | help

Thought this might lead to some feedback for DB, or prompt a slight
discussion here as well. Any thoughts on the subject?

Chris

--
"Linux... The choice of a GNUtered generation."

---------- Forwarded message ----------
Date: Thu, 16 Jul 1998 17:48:49 -0500 (CDT)
From: David Borman <dab@BSDI.COM>
To: end2end-interest@ISI.EDU
Subject: RFC 1337: Time-wait assassination

A customer recently asked us if BSD/OS conformed to RFC 1337.
I replied that RFC-1337 wasn't a standard, just an informational
RFC, so there really wasn't anything to conform to.

But, this got me thinking about TIME-WAIT Assassination.  It
occured to me that TWA could actually be used in a benificial
manner.  The main point of Time-Wait is to make sure that
if the final ACK is lost, when the FIN is retransmitted we will
respond with an ACK to the FIN, not a RST.  From RFC-793:

    TIME-WAIT - represents waiting for enough time to pass to be sure
    the remote TCP received the acknowledgment of its connection
    termination request.

But usually the ACK gets through, and the connection in TIME-WAIT
sits around doing nothing but using up system resources.  That's
usually not a big deal, but on busy servers you can accumulate
thousands of connections in TIME-WAIT state.

What occured to me was that when the side in LAST-ACK gets the ACK,
it could generate a RST before transitioning to CLOSED, allowing
the TIME-WAIT state on the remote side to be cleaned up.

Wouldn't this be a better solution to the thousands of TIME-WAIT
connections on a busy server than having the server crank down
the length of TIME-WAIT?  Of course, it means changing all the
clients out there to get any help.

Thoughts?  Comments?

			-David Borman, dab@bsdi.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980716211457.5542A-100000>