Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!GATEWAY.MITRE.ORG!tsuchiya
From: tsuchiya@GATEWAY.MITRE.ORG.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  ICMP echo
Message-ID: <8704301246.AA02177@jupiter.mitre.org>
Date: Thu, 30-Apr-87 08:46:02 EDT
Article-I.D.: jupiter.8704301246.AA02177
Posted: Thu Apr 30 08:46:02 1987
Date-Received: Fri, 1-May-87 05:35:36 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 33

> If we are allowed to add to the wish list, ...
>     I'll second Dave's suggestion for a way to capture the packet a la
> ICMP error messages.  How about an option (possibly to Dave's) which would
> cause each IP entity which processed the packet to send back such a reply
> (analogous to the 1822 trace bit?);  launch a single probe and several
> packets get returned showing the packet's progress through the internet
> (beware of recursion!).
>     I would like to suggest an internet parameters option: processed
> by each IP entity along the path, it has fields for MTU, maximum bandwidth
> (physical or "available"?), error rate, and "typical delay".  The 

I have been following the ICMP messages with interest, and note an
interesting turn in the trend.  Most of the earlier messages seemed
to me to praise ICMP Echo for its simplicity.  As Mills said, just
flip the source and destination address and shove it back out.
It seems to me that the beauty of Echo is that it is a very basic
and simple tool that can yield 90% of the information that one might
want with 10% of the effort.  Messages have shown that it can be
used for several quite different kinds of debugging.

We have discussed the "1822 trace bit" option in X3S3.3, and are
concerned about its Chernobyl-potential.  The internet parameters option
seems more like something a routing protocol or more sophisticated
(application layer) management function should provide.

In the standards environment, we have to provide pretty good justification
for putting management protocols at the network layer instead of at the
application layer.  One could probably justify a simple echo-probe at the
network layer for debugging purposes when that application layer has
failed, but echo-PLUS functions might be a little hard to swallow.

	Paul Tsuchiya		tsuchiya@gateway.mitre.org
	The MITRE Corp.		tsuchiya@mitre-gateway.arpa