Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP/IP close connection TIME_WAIT ?
Message-ID: <12093@ulysses.homer.nj.att.com>
Date: 29 Aug 89 13:42:30 GMT
References: <749@wrs.wrs.com> <8908290927.AA26586@ucbvax.Berkeley.EDU>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 36

In article <8908290927.AA26586@ucbvax.Berkeley.EDU>, almquist@JESSICA.STANFORD.EDU (Philip Almquist) writes:
> but my impression is that TIME_WAIT state was not a
> devious plot on the part of the protocol designers to tie up system
> resources; rather, it was included in the protocol because it is
> necessary to insure that delivery is indeed reliable.

Quite true.  The problem is that a host that has already closed its
direction of transmission must retain knowledge of the connection
until the other side has closed successfully.  I don't have a copy
of the RFC handy, so I won't mention the state names, but the
general scenario goes like this....

Recall, first, that each direction of transmission may be closed
independently.  Furthermore, everything must be ACKed, including
specifically close requests (known in the spec as FIN bits).  Suppose
that host A sends a FIN to host B, thereby ending its transmission.
B replies with an ACK, but continues sending data for an arbitrarily
long period.  Eventually, it too sends a FIN to host A; host A replies
with an ACK.

Let us consider now who knows what.  A has long-since finished transmitting;
it cannot send any more data.  Furthermore, it knows that B is done, too;
it's even acknowledged that.  Can A discard all knowledge of the connection?
No!  What if the ACK going to B gets lost?  B's transmitter will time out
and resend the the FIN; after all, B doesn't know which packet was
dropped.  If A has discarded knowledge of the connection, it would
have to send a reset (RST) in response to the repeated FIN.  This is
inappropriate.  Accordingly, A goes to TIMEWAIT state instead, thus
retaining the appropriate; if it sees a repeat FIN, it can simply repeat
the ACK.  TIMEWAIT persists for twice the maximum segment lifetime;
i.e., long enough to be sure that B has either seen the ACK or has
concluded that the connection is hopelessly broken.

Interestingly enough, B does not go into TIMEWAIT; the reasoning is left
as an exercise for the reader.  (N.B.  If both sides send simultaneous
FINs, both sides will end up in TIMEWAIT.)