tai%hpltyj@HPLABS.HP.COM (Tai Jin) (04/25/87)
I have a question for those experienced in using ICMP echo for debugging. Does the spec specify how a system is supposed to reply to an echo? One implementation is to turn around and send the reply to the link address of the sender (or gateway). The other is to make a local routing decision before sending the reply. Which is better? Another question is whether a system should reply to an ICMP echo sent to a broadcast address.
braden@ISI.EDU.UUCP (04/27/87)
Hi. You have asked a question about ICMP Echo semantics that ought to be,
but isn't, contained in the RFC985-revision. Sigh.
Here is my totally-prejudiced view on how ICMP Echo should behave (it is
the way my own TCP/IP code implemented ICMP Echo, of course!). Anyone
who wants to beat me up about this should do so now... otherwise, this
interpretation is likely to find its way into the gateway specification
RFC.
A host or gateway D that receives an ICMP Echo Request addressed to
itself from host S should send an ICMP Echo Reply back to S,
using the following rules:
1. If the Echo Request contained no source route, the Reply should
be sent to S using the normal routing rules of D.
As a result, the Reply may come back by a different path
than the Request took.
2. If the Echo Request did contain a source route, the Echo
Reply will be sent using the return-route built up in the
source-routing option of the Echo Request.
As a result, it is not possible to force a route for the
Reply which is different from the route used for the Echo.
A result of these rules is that ICMP Echo can be used to sample the
complete round-trip path which any other higher-level protocol e.g.,
TCP) will use for its data and ACK packets between D and S. The
rules generally follow from the assumption that ICMP is a protocol
parallel to TCP and above IP, and needs no special routing mechanism.
Bob BradenCLYNN@G.BBN.COM.UUCP (04/28/87)
Bob's statement is a nice start but doesn't mention anything about other options. I would like to suggest that it would be more generally useful if a source route was NOT inverted by the receiver of an echo request when it formed the echo reply (... that's the way I implemented it ...). Maybe there should be two versions of source route ... I would argue that the simplest implementation is the most useful -- just change echo request to echo reply and switch the IP source and destination and send the packet back without changing the options in any way (except, of course, for the processing that IP is required to perform). By returning the options (which some implimentations don't now do) one gets to see, for example, information recorded in a record route option (possibly in addition to a source route) and in a timestamp option. If you want the time out and back along a specific route (Bob's case) you can source route the packet out and back to yourself, get the timestamp info, and have your host return the packet to you (which should be local delivery). By not returning along a recorded route one can (if the gateways implement IP ...) find what route is being used to reach you from point X in the internet. It might also be nice to include in this discussion the suggestion (not originally mine) that the pharse in the ICMP spec (4th paragraph, page 1) "no ICMP messages are sent about ICMP messages" be amended to "no ICMP messages are sent about ICMP error messages"; thus allowing one to get error messages about ICMP ECHO, TIMESTAMP, INFORMATION, etc., and their corresponding REPLYs. Charlie
Mills@UDEL.EDU (04/28/87)
Bob, Your model is the one I understand to be in common use, although only the TOPS-20 is known to me to implement the return route in the way you suggest (are there others?). However, there is still the question of options, such as security, etc. Your model, taken prima facie, implies the respondent simply flips the IP addresses and source-route and tosses it back in the net, presumably leaving the options alone. I think this is the right thing, but believe it should be explicitly stated. On the question of reciprocal routes, unless the ICMP Echo message was explicitly source-routed, the return route will not necessarily fly back the reciprocal path. Ordinarily one might expect this and, indeed, there are many well-behaved segments of the Internet where this is so. However, in the flooding NSF swamps it has been my observation that routes are reciprocal only sometimes. In such cases it would be useful to have an enriched record-route facility. A sneaky way to do this might be to simply continue the record-route past the echo server. A final tid: Should the TTL be reset at the echo server? If not, the sender would have a non-ambiguous way to measure the number of hops. He could, of course, also use record-route. Finally, how about a new ICMP Echo/Echo Reply message that operates as the present one, but where the echo server captures the IP header, etc., in the same way as ordinary ICMP error messages before returning to sender? Dave
Mills@UDEL.EDU (04/28/87)
Charlie, As far as I know, your suggestion (originally attributed to Mike Brescia, I believe) to amend the spec to allow error messages about non-error messages was approved for incorporation into the MILSTD protocol documents some time ago. In point of fact, every gateway I know of, including the BBN LSI-11 and Butterflies, fuzzbugs and others, in fact operate as you suggest. Dave
gross@GATEWAY.MITRE.ORG (Phill Gross) (04/28/87)
> A final tid: Should the TTL be reset at the echo server? If not, the > sender would have a non-ambiguous way to measure the number of hops. > He could, of course, also use record-route. Have we really given up on the original meaning of TTL? The Braden/Postel RFC985-update still talks about TTL in seconds, possibly decremented by more than one second at any gateway hop. If vendors take this as seriously as they are supposed to, then TTL will no longer be an unambiguous hop count. In either case, I would argue on principle that the TTL should be reset in the echo reply. Phill
braden@ISI.EDU (Bob Braden) (04/28/87)
From Dave Mills:
Finally, how about a new ICMP Echo/Echo Reply message that operates
as the present one, but where the echo server captures the IP header,
etc., in the same way as ordinary ICMP error messages before returning
to sender?
Yeah, that sounds like the germ of a Good Idea. The ANSI guys are
probably right, more effort is required to design the
monitoring/diagnostic tools we REALLY need. (But that doesn't mean we
need a 17-layered management architecture before we can make any
progress!).
Here is another example of a testing paradigm we cannot handle now.
In the testing Steve Casner and Mark Lambert have been doing across the
Wideband Net ("Fatnet"), they have wished they could do "one-way
pinging". That is, they wanted to collect the same data that a normal
Mike Muuss pinger gets, but with no return trip, assuming they could
access the hosts on both ends.
Bob Bradenbraden@ISI.EDU (Bob Braden) (04/28/87)
The ICMP Echo Reply packet should start out with a new TTL value (in your terms, yes, the TTL should be reset). This follows from my assumption that ICMP is a protocol layered above IP. Bob Braden
CLYNN@G.BBN.COM (04/28/87)
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.)
Charliedeering@PESCADERO.STANFORD.EDU (Steve Deering) (04/28/87)
From: CLYNN@G.BBN.COM :
I would argue that the simplest implementation is the most useful --
just change echo request to echo reply and switch the IP source
and destination and send the packet back...
From: Mills@UDEL.EDU :
Your [Bob Braden's] model, taken prima facie, implies the respondent
simply flips the IP addresses and source-route and tosses it back in
the net, presumably leaving the options alone. I think this is the right
thing, but believe it should be explicitly stated.
Although the ICMP spec does say to simply reverse the IP source and
destination addresses, that is incorrect when the original IP destination
is a multicast or broadcast address. In that case, the IP source address
of the Echo Reply (or Timestamp Reply, Information Reply, or Address Mask
Reply) should be set to one of the replying host's individual addresses
(presumably the one corresponding to the interface from which the reply
is sent). I realize that many of you already know this, but it is a
common bug and this seemed like a good opportunity to point it out.
Let me also remind people that ICMP *error* messages (i.e., Destination
Unreachable, Source Quench, Redirect, Time Exceeded, or Parameter Problem)
should never be sent in response to a packet with a multicast or broadcast
IP destination.
Steve DeeringMills@UDEL.EDU (04/29/87)
Bob, Byte my tongue if I can't resist responding to your challenge. THe fuzzies have been using one-way pings (between themselves) since 1979. I discovered the value of these things at 0500 the morning of the SATNET demonstration at NCC while trying to bring up TOPS-20s in California, facsimile machines in London and fuzzballs scattered all over, all this in the midst of power failures at ISI, wandering satellite antennas in Maryland and buzzy amplifiers on the convention floor. The one-way buggers were useful, since the satellite channel was very flaky and we only needed it from London to Washington for a packet-voice and facsimile demo. All this was almost eight years ago when ICMP was really a wart on the side of GGP. But that's a story for another time. Dave
mike@BRL.ARPA.UUCP (04/30/87)
I have a routine called TTCP which is useful for testing both TCP and UDP (inspired by a program of the same name that Excelan once sent a friend to test *his* TCP). By default, it acts much like a UNIX pipe, extended to the network on one side; optionally, it can source/sink a given quantity of patterns. Only occasionally useful as a communications tool, it's great for tests and debugging. For your fatnet tests, I'd use it in UDP mode with the source/sink option. While it will tell you about packet loss, CPU and clock time used, it does not assume the clocks are synchronized, so it does not try to make one-way timing assessments. That could be very easily added if times can be believed. TTCP is my standard tool for conducting performance measurements; on various occasions I have used it to test TCP performance, effects of window sizes, performance/overhead differences between various Ethernet interfaces on the same machine, gateway performance, and end-to-end InterNet performance. The most interesting communications use of this tool is for sending huge quantities of data painlessly between UNIX systems. On rcvr, run ttcp -r | tar xvf - on sender run tar cvf - . | ttcp -t destinationhost It has also been very useful for setting up "TCP relays" to avoid the GGP extra-hop problem, and/or the EGP packet-fragmentation-induced routing problem, when having to move > O(10 Mbytes) of data on our troubled InterNet. Best, -Mike
tsuchiya@GATEWAY.MITRE.ORG.UUCP (04/30/87)
> 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
CLYNN@G.BBN.COM.UUCP (04/30/87)
Bob,
The ICMP Echo Reply packet should start out with a new TTL value (in
your terms, yes, the TTL should be reset). This follows from my
assumption that ICMP is a protocol layered above IP.
I do not agree with the "This follows" logic. There are instancces in
the suite where a protocol "above" IP obtains information from the IP
header and later returns it for use in a subsequent IP datagram; the
two most obvious examples are the source and destination address, and
one could even consider the IP type-of-service and protocol fields to
be in this category.
I think the desire should be to specify a tool so that it provides as
much information as possible (without "external" knowledge of the
implementation details of particular components in the system). The
information gained by resetting the TTL is variations over time in "x"
on the way back (where "x" is hops or seconds or some combination);
one learns nothing about the way out. The information gained by not
resetting the TTL is both variations in "x", summed over out and back
AND, since you specified the original TTL, the absolute amount by which
"x" changed (out and back). Resetting gives one-way second-order
information while the not resetting it gives two-way first and second
order information. The question is, if we can only have one, which is
more generally useful?
Charlietmallory@CCV.BBN.COM.UUCP (04/30/87)
Bob, The LSI-11 gateways already have much of the one-way functionality you probably need. The gateway will send a trap message for each ICMP echo reply received (you can turn this off). The trap messages are timestamped (internal format, but adequate for inter-packet arrivals) and include, among other things, the 16-bit IP id field so that individual packets may be watched. Of course, you need access to the INOC... Perhaps a little more work is needed. Cheers, Tracy