wiltzius@lll-lcc.UUCP (Dave P. Wiltzius) (01/15/90)
Can someone explain exactly why TCP requires that one side of the TCP connection remain active (in TIME_WAIT state) for 2MSL when the connection is gracefully closed? I could not find this explained in the Host Requirements document nor in RFC793 (not well enough for me, anyway). Thanks. Dave (wiltzius@lll-lcc.llnl.gov)
zweig@brutus.cs.uiuc.edu (Johnny Zweig) (01/16/90)
wiltzius@lll-lcc.UUCP (Dave P. Wiltzius) writes: >Can someone explain exactly why TCP requires that one side >of the TCP connection remain active (in TIME_WAIT state) >for 2MSL when the connection is gracefully closed? I could >not find this explained in the Host Requirements document >nor in RFC793 (not well enough for me, anyway). "Gracefully" is in the eye of the beholder. Recall that there could be spurious retransmissions of the FIN you sent me which I have ack'ed, and that I might send you an ack that doesn't get through. TIME-WAIT is a way of making it overwhelmingly likely that losing a single segment (that last ack) or spuriously retransmitting a single segment (the FIN) won't mess things up. Keeping the connection descriptor around for 2 MSL is necessary so that I know what sequence numbers and whatnot to use when I get a retransmission of a FIN I have ack'ed during that time. The TIME-WAIT state is there so that a retransmission of the other guy's FIN segment won't cause a spurious RST segment (i.e. I need the TCB around so I can figure out that it is merely a retransmission and not some other scary piece of weirdness) to be transmitted. The only reason you can get away without going into it (by going from ESTABLISHED to CLOSE-WAIT to LAST-ACK to CLOSED) is because in that one case you can only get an acknowledgement of your FIN segment if the other TCP has gotten your ack of its FIN segment, because that's how the sequence-numbers work out. A retransmission of the other guy's FIN could still occur after I go into CLOSED state, but he'll silently ignore the RST I would send in reply to it. In any case, the setup guarantees that both ends have received ack's of their FIN segments at least once (unless the network is so bad that the last ack never gets through even after my 2 MSL wait in TIME-WAIT state). Is that any less confusing than what's in RFC793? -Johnny Trying-not-to-be-confusing
sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) (01/16/90)
zweig@tut.cis.ohio-state.edu (Johnny Zweig) writes: > <deleted> TIME-WAIT is > a way of making it overwhelmingly likely that losing a single segment > (that last ack) or spuriously retransmitting a single segment (the FIN) > won't mess things up. > > Keeping the connection descriptor around for 2 MSL is necessary so that > I know what sequence numbers and whatnot to use when I get a retransmission > of a FIN I have ack'ed during that time. would it be a "good idea" to set the length of time a connection stays in the TIME_WAIT state to a (small) multiple of the smoothed round trip time accumulated during the connection's lifetime rather than a fixed (larger than necessary almost all of the time) constant? i find it hard to believe that the TIME_WAIT interval needs to be as large (default is 75 seconds i believe) on an ethernet as it does on a WAN from one coast to the other. Steven M. Schultz sms@wlv.imsd.contel.com