daveb@geac.UUCP (11/10/87)
In article <8711030915.AA00844@gumby.wisc.edu> Mitchell Tasman (g-tasman@GUMBY.WISC.EDU) writes: [discussion of the behavior on "host down"]... a daemon | should immediately close the associated TCP connection. | | With an 1822 Distant Host connection to DDN, this may be a fairly | reasonable approach. However, a typical DDN connection of late has been | X.25 or HDH. Here, "host down" may have a more transitory meaning: simply | that there was noise on the host access line. The remote host may well | reappear with all TCP connections intact. My experience with short-haul or secondary nets has been that there are two distinct kinds of events which TCP might regard as a "host down". One is a real host-down and the other is the aforementioned QRN (noise) on the line. The latter is particularly annoying on what is supposed to be a low-error medium... Methinks that TCP is being a bit pessimistic: IP is not supposed to be error-free, and I suggest that TCP may be misinterpreting the errors which a short-haul network seems to love to produce as a more serious and long-term event than it really should. Could map or someone comment? --dave (on the other hand, i could be biting my foot) c-b -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
PADLIPSKY@A.ISI.EDU.UUCP (11/12/87)
Since you asked.... "TCP", per se (or "TCP The Protocol"), doesn't take an explicit stand on when to give up that I recall. I emphatically agree with you (and Phil Karn, who started the subtopic off, and Mitchell Tasman, who pointed out that there are extra pitfalls in the X.25 environment [which I was not, repeat not, addressing in my first msg on the subtopic]) that it's contrary to the robustness goal of TCP to give up too easily. I still would hope that implementers to whom that view is a revelation don't swing too far the other way and keep "obviously" shot connections around needlessly, since in some contexts the storage shouldn't be wasted and in other contexts (perhaps even in all contexts) there's a waste of transmissions to get SNs back in synchrony. The call, however forlorn, is just to "do it right"--and when you get right down to it, the liabilities of taking too optimistic a view aren't all that severe... except, of course, if you're wasting transmissions for "liveness" checks, or needlesssly sending some latter-day analogue of the old NCP RST, or being charged by some comm subnet for the apparently open connection, or.... Oops, guess I still feel you oughta be prudent. Well, that's probably more than enough on the subtopic for/from me, so: cheers, map -------