🚀 go-pugleaf

From: "J. Spencer Love" <JSLove@MIT-MULTICS.ARPA>

My recommendation is that you send out an unsolicited acknowledgement
every 5 minutes or so when there is no activity of any kind on the
connection.  Activity is defined as any traffic, incoming or outgoing.
Thus, in practice only one end of the connection will be pinging the
other, since the receipt of such an unsolicited acknowledgement would
constitute activity.  If the host at the other end of the connection has
crashed, there will be no response to the ping at the TCP level, and
most TCP implementations don't understand ICMP destination unreachable
messages anyway.  However, when the host comes back up, the unsolicited
ack will elicit a reset, aborting the half-connection.

If your TCP implements ICMP destination unreachable messages, you
probably don't want to actually reset a connection because of one unless
the destination remains unreachable for some period of time, such as the
transmission timeout.  Given a little time, IP routing may find another
route or the gateway may come back up.  Multics uses transmission
timeouts of typically one minute.

Pinging is in disrepute these days because of network loading which it
causes.  On the good side, you are only pinging connections which are in
the established state, and if the clocks of the system are not perfectly
in step (well, "clocks" is an oversimplification) and the packet
dropping rate is low, only one system will be doing the pinging every
ping interval.  If different timeouts are used based on whether the
activity was transmission or reception, the systems can take turns doing
the pinging.  The ping interval can be quite long, perhaps several
minutes, since it is not constrained to be less than a transmission
timeout interval.  On the bad side, you are pinging for each connection,
not just for each host or even first hop gateway.

The rationale for leaving the pinging to the next higher level protocol
(telnet negotiations) is that then only telnet connections will present
this additional load on the network.  I think this is a crock of your
least favorite substance.  This means that ANY protocol or application
which is potentially idle for long periods must reinvent this wheel.  I
think that any application with humans in the loop will require this,
and that most other applications (e.g., SMTP, FTP data connections,
finger) do not have TCP connections sitting idle in both directions for
extended periods of time anyway.  A reliable stream protocol should be
more reliable than TCP is at telling its clients that the connection has
gone away.

Most real TCP implementations have ways of passing this information
around.  For example, if the client is blocked on read it has to handle
an abort, and a telnet user has to be able to receive urgent data to
implement Interrupt Process, even though these mechanisms are not
formally part of the TCP spec.

Multics does not do this pinging (yet?), and I know of no implementation
which does.  Would anyone care to offer additional reasons why
implementations should NOT do this, and why the TCP spec shouldn't be
amended?