Path: utzoo!mnetor!uunet!husc6!mailrus!umix!nancy!eecae!super.upenn.edu!rutgers!bellcore!faline!thumper!karn
From: karn@thumper.bellcore.com (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP Keep-alives, also push bit
Message-ID: <984@thumper.bellcore.com>
Date: 15 Mar 88 08:58:00 GMT
References: <900@rlgvax.UUCP>
Organization: Bell Communications Research, Inc
Lines: 39
Summary: How TCP keepalives work

In BSD at least, keepalives are implemented by sending a TCP segment
containing a single byte of "garbage". However, the SEQ field is one
less than the receiver is expecting, so it is not accepted as real data.

When the receiver sees an "old" data packet (i.e., a packet containing
data that has already been acked, i.e., the sequence number in the
header plus the length of its data is less than the receiver's RCV.NXT)
it is required by the spec to send a segment with its next expected
sequence number, i.e., RCV.NXT, in the ACK field.  (This is primarily
intended to prevent deadlock in normal data transfer should an
acknowledgment packet be lost.) The "polling" TCP uses this "do-nothing
ACK" as the indication that the remote host is still there. So hosts
that don't respond properly to BSD-style keepalives are most likely not
following the spec.

Having said this, I should point out that keepalives are NOT a formal
part of the TCP spec. I also think they're a very bad idea.  I didn't
always feel this way. However, some long and frustrating experiences
with slow, unreliable and often expensive network paths (amateur packet
radio, as well as commercial X.25 networks that charge for every packet)
have turned me into a crusader against keepalive pinging.  It simply
isn't worth the cost, especially when there's no way for me to tell the
other end to cease and desist.

Besides, the whole philosophy of TCP and the datagram approach to
networking was supposed to be reliability and robustness in the face of
network problems. Why should the system gratuitously close a connection
just because the network path happens to go down for a few minutes? If
the connection has been idle during the entire outage, the user wouldn't
even know (or care) that there had been a problem, as long as it's back
by the time he sends more data. But keepalive pinging will make SURE he
knows in the most annoying way possible!

In the same category are TCPs that immediately close a connection when they
get an ICMP Unreachable message. At most they should abort connections
only before they are established; once established they should serve as
diagnostic messages only.

Phil