Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!lll-lcc!ames!ucbcad!ucbvax!SPAM.ISTC.SRI.COM!gds
From: gds@SPAM.ISTC.SRI.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: ICMP As A Diagnostic Tool?
Message-ID: <8704082245.AA04129@spam.istc.sri.com>
Date: Wed, 8-Apr-87 17:13:01 EST
Article-I.D.: spam.8704082245.AA04129
Posted: Wed Apr  8 17:13:01 1987
Date-Received: Sat, 11-Apr-87 08:17:57 EST
References: <8704081320.AA06603@gateway.mitre.org>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 20
Approved: tcp-ip@sri-nic.arpa


     The Redirect function in ISO is in the ES-IS (End System to Intermediate
     System) routing protocol, DP 9542.  The Echo function can be accomplished
     by using partial source route with the "echoing" machine on the list.
     (This if the distant machine is an IS.)  To an ES, a transport connection
     can be used much to the same, if not better, effect.

I believe one advantage to the way we do ICMP echoes is that, for all
the implementations I have heard of, processing of the echo reply takes
place in kernel space instead of user space.  The use of a user program
waiting on a transport connection to trap echoes and generate echo
replies requires scheduling of that process.  If the system is loaded,
it will lessen the accuracy of the round-trip time.

In case anyone is interested, I have some war stories describing the use
of ICMP for fault isolation.  (Example:  discovering that you have lost
your gateway, and finding a new one.)  They're too long to reprint here,
but might provide some amusing reading.

--gregbo