From owner-freebsd-net Thu Jul 16 18:17:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29905 for freebsd-net-outgoing; Thu, 16 Jul 1998 18:17:07 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA29900 for ; Thu, 16 Jul 1998 18:17:02 -0700 (PDT) (envelope-from opsys@mail.webspan.net) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with SMTP id VAA07532 for ; Thu, 16 Jul 1998 21:09:39 -0400 (EDT) Date: Thu, 16 Jul 1998 21:16:43 -0400 (EDT) From: Open Systems Networking X-Sender: opsys@orion.webspan.net To: freebsd-net@FreeBSD.ORG Subject: RFC 1337: Time-wait assassination (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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