Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!tcp-ip From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: A Noop Strategy for TCP Message-ID: <9333@ucbvax.ARPA> Date: Thu, 25-Jul-85 18:12:46 EDT Article-I.D.: ucbvax.9333 Posted: Thu Jul 25 18:12:46 1985 Date-Received: Sat, 27-Jul-85 02:53:28 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 54 From: "J. Spencer Love" 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?