🚀 go-pugleaf

Bob,

    Well, I don't see why that would be more generally useful.  Presumably
    you use source route because you want to force a particular path, or
    to override some inadequate routing mechanism; it seems most likely that
    the same problem will hold along the path back to the source host.

This is exactly the point of using echo as a diagnostic tool in an
environment where routes out and back are NOT the same.  By forcing a packet
to a spot in the internet, using a source route to get it there via whatever
path you have found to work, you can explore/diagnose the "inadequate routing
mechanism", aka the default routing.

    I have heard other people talk about source routing a packet out and back
    to yourself, but this doesn't seem sensible to me.  As my message said, a
    host should send an Echo Reply only if the Echo Request message is
    DESTINED to it.  If, on the other hand, a host merely appears as an
    intermediate step in the source route, that datagram is not destined for
    that host, and the host should never look at the ICMP level of the
    datagram.

We agree that an echo request should only be turned into an echo reply by
the host to which it was destined.  Most systems allow messages to be sent
to themselves -- you can telnet, ftp, smtp, and ping (with ICMP echo requests)
to your own host (many systems bypass the net in such cases, allowing "loop-
back" tests to measure host & protocol throughput, cpu load, etc.).  The
scenario I was suggesting is to ping your own host, but force the outgoing
echo request through some portion of the net through use of a source route.
Why do this? Because some hosts have better diagnostic tools than others --
if you are trying to collect information using IP options and the desintation
host flushes them when forming an echo reply, you get nothing; but if your
host either doesn't flush the opions or allows you to see echo requests
that it receives, then you can get the information without the cooperation
of the other host.  (If collecting timing information you may win even more
due to the ability to estimate skew in clocks along the way.)

    Did I hear "network management"?
	
Certainly!  Haven't all the uses for ICMP echos which we have been reading
the last few weeks been for some form of fault or performance management?
Isn't "management" the reason that ICMP was created?

Also, I agree that Dave's point of not resetting the IP TTL is a good
idea, and that leaving the options alone should be explicitly stated.

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 
originator sets the initial values for MTU and bandwidth to big values,
error rate and delay to small;  each IP entity along the path checks the
local parameters (for the inbound and outbound patha) and overwrites the
MTU or bandwidth fields if the local parameters are smaller, and the error
rate and delay if the local parameters are larger.  The recipient can then
find out some of the (admittedly instantaneous) characteristics of the
communications path.

I think the MTU information would be useful, especially given the
inherent problems associated with IP-level fragmentation, if only as
something to be used if a) IP decides to send an ICMP fragmentation
timeout message (piggyback the parameters option and the sender can
try something better), or b) TCP is having to do a lot of
retransmissions and wants to try something better.

The bandwidth parameter could be used to limit the maximum send data
rate -- no need to fill all the gateway queues before the bottleneck,
keep the data at the source so others can use the bandwidth of the
cross-paths.  (One of the hooks in our tcp was to pass a process's
controlling tty speed to TCP -- it could then send data at a rate
which wasn't too much for the user's terminal; it worked much better
than window-type flow control as the delay in the feedback path was
"eliminated", the response to telnet interrupts was much improved too
- little data in the pipe.)

Charlie