Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!amdahl!ames!sri-spam!rutgers!bellcore!faline!karn
From: karn@faline.bellcore.com (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ..."layering violations"
Message-ID: <1511@faline.bellcore.com>
Date: Mon, 2-Nov-87 18:11:16 EST
Article-I.D.: faline.1511
Posted: Mon Nov  2 18:11:16 1987
Date-Received: Fri, 6-Nov-87 04:41:21 EST
References: <8711010759.AA08856@okeeffe.Berkeley.EDU>
Organization: Bell Communications Research, Inc
Lines: 49
Summary: I still don't see the need for TCP keep-alives

In article <8711010759.AA08856@okeeffe.Berkeley.EDU>, karels@OKEEFFE.BERKELEY.EDU (Mike Karels) writes:
> Two comments on your recent message.  First, about TCP behavior
> when ICMP unreachables are received: I definitely agree that TCP
> ought not to quit when it receives an unreachable.  However, in Unix
> and probably most other systems, it's hard to report "soft" errors
> to a network client.  In 4.3, I chose to return a single error
> on the next send or receive, but the TCP connection remains open.
> Unfortunately, most network applications carefully check for errors
> on each send/receive, and they give up on the first error.
> (4.2 aborted the connection when ICMP errors were received,
> and thus the application had no chance to keep trying.)

TCP doesn't return an error to the application when it retransmits, so
why should it do so when it receives a sporadic ICMP unreachable
message? I think a better approach would be for TCP to ignore these
messages, except to keep the last one or two around in case the
application specifically wanted to see them (e.g., by doing a special
ioctl on the socket).

> I also agree that you're right to distinguish between interactive
> network users and automatic daemons.  However, it's precisely for
> the daemons that are willing to wait patiently forever that "keep alive"
> messages are needed.  Although the telnet client will give up and close
> the connection manually, there needs to be a way to prevent systems
> from accumulating useless, disconnected telnet servers and other such
> trash.  Most application-level programs don't have their own keep-alive
> or are-you-there to detect network failure.  For those reasons, we use
> TCP-level keepalives (which are also not well provided-for at this level)
> only on network servers that don't have their own time-out scheme.

I strongly disagree that this should be done at the TCP level. I took
keepalives out of most of our systems some time ago. It's really nice
not to have to recreate a half dozen rlogin windows on my Sun each time
my SLIP link drops and has to be redialed.  It's also nice not to have
a steady stream of useless traffic on my amateur packet radio channel
when somebody logs in but remains idle for long periods.

The only way you accumulate useless, disconnected telnet servers is when
the client machines crash. If you *really* want to get rid of them, just
have a shell script do a write to anybody idle for more than X days --
the data will trigger a TCP Reset which will close the connection for
you. On the other hand, while they are aesthetically unpleasing, idle
sessions really don't hurt anything -- main memory is cheap and paging
memory even cheaper.

A year or two ago I thought as you do on keepalives, but a discussion
with Jon Postel turned me around. :-)

Phil