tpc@bnr-fos.UUCP (Tom Chmara) (11/23/88)
We've been examining the 4.3BSD tcp-ip code from Berkeley, and I'm a bit confused. From what I can see, an attempted connection to a dead host will take TCPTV_KEEP (i.e. 45) seconds. Timeout of an active connection on the demise of a remote host will take until all 12 retransmission inter- vals have expired, i.e. <= (12*TCPTV_MAX = 360s). The first figure I can understand...but 6 minutes to timeout on unacknowledged traffic? Sounds kind of high, even for Internet applications with their long-haul lines. Two questions spring to mind: 1) What am I misreading? 2) If this is correct, is it the same for other flavours of TCP-IP? If not, has someone got ballpark figures for other implementations? Signed, Confused (a.k.a. ---tpc---) (thanks for your time, folks...) -- I am sole owner of the above opinions. Licensing inquiries welcome. ------------------------------------------------------------------------ Tom Chmara UUCP: ..utgpu!bnr-vpa!bnr-fos!tpc BNR Ltd. BITNET: TPC@BNR.CA
almquist@JESSICA.STANFORD.EDU (Philip Almquist) (11/27/88)
Tom, > ...<In 4.3BSD> Timeout of an active connection > on the demise of a remote host will take until all 12 retransmission inter- > vals have expired, i.e. <= (12*TCPTV_MAX = 360s)... > 6 minutes to timeout on unacknowledged traffic? Sounds kind of high... If you get a more recent version of 4.3BSD, I think you'll find that the timeout is considerably higher than that now. What would be the point of having a shorter timeout? If you decide that your telnet connection has lost it, you are perfectly free to abort it yourself, even if the operating system hasn't yet decided the connection is dead. Impatient applications that run without human operators ar similarly free to make their own decisions about the usefulness (or lack thereof) of a TCP connection. Why not have a shorter timeout? Well, suppose that some evening you left an ftp running on your system, retrieving some huge file from somewhere several continents away. You might be rather annoyed if you came in the next morning and discovered that the transfer had been aborted because some gateway crashed and your TCP timed the connection out while the gateway was rebooting. Indeed, some would say that this argument suggests that TCP should never time out connections. I'm not sure that they're wrong... Even if they are wrong, it's important to keep in mind that the Internet is growing at a phenomenal pace. Many early implementors of TCP chose "reasonable" upper bounds on round trip times; several years of Internet growth later, those systems were performing very badly and people were calling those same upper bounds "unreasonable" (and various unprintable things). Don't make the same mistake! Philip
dnwcv@dcatla.UUCP (William C. VerSteeg) (11/29/88)
In article <196@bnr-fos.UUCP> tpc@bnr-fos.UUCP (Tom Chmara) writes: >...but 6 minutes to timeout on unacknowledged traffic? >Sounds kind of high, even for Internet applications with their long-haul >lines. Two questions spring to mind: > >1) What am I misreading? >2) If this is correct, is it the same for other flavours of TCP-IP? > If not, has someone got ballpark figures for other implementations? > To me, six minutes is not a bad figure for a general purpose computer. For non-interactive connections, (mail,file transfer) this figure would allow for a flaky link to stabilize. For interactive connections, (Telnet, etc) the user can abort the connection attempt himself if he doesn't want to wait this long. However, in dedicated systems (Terminal servers), this interval should be MUCH shorter. Something on the order of 10-20 seconds would be reasonable. Asking a user to wait for a connection much longer than this is generally counter-productive. The user will typically abort login attempts after a few seconds anyway. Another issue relating to timers and terminal servers is how to disconnect sessions in the absence of data. When a users on system A logs into system B, then system A crashes, system B has no good way to end the session. If no data is sent from system B, it will never know that system A is dead. The only way that I can think of to close such circuits is to run a timer on all idle circuits. When the timer fires, system B could send "are you there" messages to system A. B would then close dead connections. There are problems with this, though. Some Telnet implementations don't handle "are you there" well. This method also doesn't close sessions that have been abandoned by users. A way around this would be to close any circuit that has been inactive for a configurable amount of time. However, this also is not very elegent. Are there any standard ways of handling this? In our line of statistical multiplexor-based products, we can configure inactivity timers and can sense loss of physical media. We can then make rational circuit disconnection decisions. In the Telnet world, inactivty timers are feasible. But is there a good method to determine if the other end of a circuit is dead? Thanks Bill VerSteeg
kent@WSL.DEC.COM (12/03/88)
Maybe you'd like your terminal server connections to time out after 10 or 20 seconds, but I don't. I want my Telnet connection to ride out simple gateway crashes; a gateway that crashes and "immediately" reboots shouldn't cause me to lose all my session state.