tsuchiya@GATEWAY.MITRE.ORG.UUCP (04/14/87)
From John Shriver: > Another important aspect of ICMP echo reply is that it is Mandatory in > the TCP/IP suite (see the latest Official ARPA Internet Protocols, > where IP and ICMP are the only Mandatory protocols). Using > transport-level protocols in ISO for the same function will not be > nearly as effective, for example a router (IS in ISO parlance) > nominally has no use for transport protocols. I would recommend to > ISO designers to add a mandatory echo response at as low a level as > possible in the architecture. If the source routing trick does this, > and is a mandatory capability of ISO 8473, great. I would then ask > the implementers to provide the necessary user program. No, partial source routing is NOT mandatory in ISO 8473. I admit, I knew this when I suggested it, but I did it anyway. However, from the responses I have seen on this issue, a lot of people think ICMP ECHO is important. We in X3S3.3 would like to be obliging, but are a little uneasy of putting in an all purpose ping without understanding how it will be used. A lot of people may be using ECHO for things when some other function may do more for that thing. Since we are just now defining management functions for the network and transport layers, we are in a good position to provide a lot more than just pings. I would like to get some feedback from all those dirty-fingernailed pingers out there. What EXACTLY do you use ICMP ECHO for? Is there a better way to do what you want other than ICMP ECHO, but you are using ICMP ECHO because it is the only thing available? Are there things (management-wise) that you wish you could do, but there is currently nothing standardized to do it with. Of course, any other random comments are welcome. > (But enough, this discussion really belongs on the ISO mailing > list, see the CC: address...) Yes and no. While tcp-ip is obviously not going to go away, there is no question (at least in my mind) that tp4-ip is on the way. If we (the ISO designers) don't get feedback from you (the experienced tcp-ip designers) on these issues, then the ISO mailing list will be nothing but a repeat of the tcp-ip mailing list, but delayed 5 or 10 years. I think a lot of things belong on both lists. While on the ICMP topic, I'd like to bring up another tidbit...... In addition to an error message which is just like SOURCE QUENCH, there is a thing in ISO-IP called the congestion experienced bit. It is a bandwidth free way of indicating to transport machines that your congestion is getting up there, but not to the point where packets are being thrown away. This is how DEC does it, and it seems to work for them. Now the catches. One, its optional. However, optional doesn't have to mean don't do it. It is groups like COS (Corporation for Open Systems), the NBS-ISO Workshop, and GOSIP (or whoever is behind it) that ultimately decide these things. Two, what a transport does when it receives such a bit is not standardized (just like SOURCE QUENCH), nor is it standardized when the bit gets set. Again, COS, NBS, etc., are the places to fight those battles. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa
Rudy.Nedved@H.CS.CMU.EDU.UUCP (04/15/87)
As someone said recently for why you want ICMP ECHO required is for debugging. The application is to determine connectivity which you can not associate with gateway mechanisms since routing updates are broken half the time. You really need a simple way of to see if some node in the network tree is there. You test node A, you test node B and then test node C and then try X. This is usually neccessary if you are trying to answer the question, "Why can't I talk to X?". The other things that PINGing is good for is testing for drop tests, different packet sizes and random data failures. There are a variety of failure modes related to interfaces, translating a packet from one network to another, congestion versus media, packet sizes and a host of other conditions. Basic horror stories include the following: SDLC interface that paused a bit longer between bits after 256bytes, the interface was correct but the old piece of garbage hardware on the receiving side was slightly off...It would randomly pick a bit value for that bit. Pings using different packet sizes and data showed this. Oscillation failures between gateways. The gateways would believe a network was done when it is was up and vice versa. Pings helped detect this incorrect knowledge in the gateways. ARP mechanism is busted. A PING on one host said a host was up but on the busted host said it was down. Connections dropping during end of day. PINGs showed that occasionally for a minute or so, all packets were lost. Turned out interface under high load would occasionally shut itself off....probably related to input buffer ring size. In many cases, the thing that saved us was the fact that ICMP ECHO was required. We could point at an implementation and say you are not playing by the game rules and would treat them very badly...It never happened but the ability is there. I believe in the Ethernet configuration testing protocol. I look at ICMP ECHO with source routing as being a mid-level network testing mechanism. Losing this ability would hamper our ability to quickly track down problems. If ISO has a better mechanism then simple ECHOs and ECHOs with source routes, I would love to hear about it on this list since I am certainly eager to learn better and faster ways to isolate network failures. -Rudy
netnews@orstcs.cs.ORST.EDU (04/15/87)
/* Written 8:58 am Apr 14, 1987 by tsuchiya@GATEWAY.MITRE.ORG in orstcs:comp.protocols.tcp-ip */ /* ---------- "ICMP in ISO" ---------- */ From John Shriver: > Another important aspect of ICMP echo reply is that it is Mandatory in > the TCP/IP suite (see the latest Official ARPA Internet Protocols, > where IP and ICMP are the only Mandatory protocols). Using > transport-level protocols in ISO for the same function will not be > nearly as effective, for example a router (IS in ISO parlance) > nominally has no use for transport protocols. I would recommend to > ISO designers to add a mandatory echo response at as low a level as > possible in the architecture. If the source routing trick does this, > and is a mandatory capability of ISO 8473, great. I would then ask > the implementers to provide the necessary user program. No, partial source routing is NOT mandatory in ISO 8473. I admit, I knew this when I suggested it, but I did it anyway. However, from the responses I have seen on this issue, a lot of people think ICMP ECHO is important. We in X3S3.3 would like to be obliging, but are a little uneasy of putting in an all purpose ping without understanding how it will be used. A lot of people may be using ECHO for things when some other function may do more for that thing. Since we are just now defining management functions for the network and transport layers, we are in a good position to provide a lot more than just pings. I would like to get some feedback from all those dirty-fingernailed pingers out there. What EXACTLY do you use ICMP ECHO for? Is there a better way to do what you want other than ICMP ECHO, but you are using ICMP ECHO because it is the only thing available? Are there things (management-wise) that you wish you could do, but there is currently nothing standardized to do it with. Of course, any other random comments are welcome. > (But enough, this discussion really belongs on the ISO mailing > list, see the CC: address...) Yes and no. While tcp-ip is obviously not going to go away, there is no question (at least in my mind) that tp4-ip is on the way. If we (the ISO designers) don't get feedback from you (the experienced tcp-ip designers) on these issues, then the ISO mailing list will be nothing but a repeat of the tcp-ip mailing list, but delayed 5 or 10 years. I think a lot of things belong on both lists. While on the ICMP topic, I'd like to bring up another tidbit...... In addition to an error message which is just like SOURCE QUENCH, there is a thing in ISO-IP called the congestion experienced bit. It is a bandwidth free way of indicating to transport machines that your congestion is getting up there, but not to the point where packets are being thrown away. This is how DEC does it, and it seems to work for them. Now the catches. One, its optional. However, optional doesn't have to mean don't do it. It is groups like COS (Corporation for Open Systems), the NBS-ISO Workshop, and GOSIP (or whoever is behind it) that ultimately decide these things. Two, what a transport does when it receives such a bit is not standardized (just like SOURCE QUENCH), nor is it standardized when the bit gets set. Again, COS, NBS, etc., are the places to fight those battles. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa /* End of text from orstcs:comp.protocols.tcp-ip */
sch@sequent.UUCP (04/16/87)
It seems to me that the ISO attitude is that all vendors will have perfect hardware and software. This is obviously not true in the real network swamp. Pinging hosts is a useful tool just as a hardware tech checks cable continuities with an Ohm meter. It is always useful to verify things are working at the lowest level and trace the problem up through the levels. The more protocol levels in between the less useful the tool becomes. - Steve Hemminger - Network PIE - Sequent Computer Systems
tmallory@CCV.BBN.COM (04/16/87)
I just wanted to add to the debugging scenarios presented by Rudy. I have on many occasions used the message generators in our gateways to ping hosts in order to determine just where a routing problem may lie. The receipt of an echo reply packet by the gateway generates a trap message which is sent to the monitoring center. Using a gateway on a network to which the host is directly attached can show whether the host is able to communicate at all. By merely changing the source address in the ping to be the other side of the gateway, one can determine whether the host has the necessary routing information. Depending on the number of gateways under my control along the path, I can learn much about the type of problem. We often get complaints from users who cannot connect to some other host using tcp. It is very frequently case that one of the hosts does not have a route to the other network, but occasionally the problem turns out to be protocol related, as when it turned out that Sun's telnet could not use Class C internet addresses for opening connections in one direction. I don't remember whether it was client or server mode now. Such a simple low level tool can be implemented in virtually any network device, though even 4.2 bsd got it wrong for a while, so that a minimum of 48 bytes needed to be sent to get a reply where only 28 should be necessary. The more complex your debugging aids, the more likely they won't work when you need them. Tracy Mallory BBN Communciations 617-497-3193
Mills@UDEL.EDU (04/17/87)
We should not lose sight of the fact that echo mechanisms are embedded in many protocols besides ICMP. Both TCP and UDP have echo ports, for example. DECnet has an echo "mirror" mechanism as well. We might argue about the detail protocol involved or whether it belongs as an intrinsic feature of each protocol (as I believe) or belongs in a pervasive network management, but I think we can all agree the mechanisms are necessary for any real network. As one who often has had echo goo smeared up to my clavicle, I can observe there have been numerous cases where something was found to be working just fine at the IP level was broken at the TCP/UDP level as diagnosed by the TCP/UDP echo mechansim. I submit we shouldn't stop at ICMP and should strive for these mechanisms at each and every level in the protocol stack. DavU>
CASNER@VENERA.ISI.EDU (Stephen Casner) (04/17/87)
We have used ICMP echoes frequently in testing the Wideband Satellite Net and paths through the gateways that attach to it. Aside from simply probing for connectivity, using ICMP echoes allowed us to measure packet loss and misordering characteristics that would be harder to discern by examination of the behaviour of a transport protocol. It is easy for an ICMP echo tester to send packets at a regular rate and observe the delay distribution of the echo replies. The transmission rate of a transport protocol will likely be affected by network anomolies, clouding the measurement. We had observed unexpected behavior in the NETBLT protocol we were testing; with ICMP echoes we were able to get a better understanding of the performance of the network to serve as a basis for further NETBLT tests. One drawback of testing with ICMP echoes is that the path must be a round trip. Network performance may be different under unidirectional load. ICMP-like datagrams are useful for testing between a separate transmitter and receiver as well, but transmission time is then only relative rather than absolute unless synchronized clocks are available (oh so nice to have!). -- Steve Casner -------
gds@SPAM.ISTC.SRI.COM.UUCP (04/17/87)
We should not lose sight of the fact that echo mechanisms are embedded in
many protocols besides ICMP. Both TCP and UDP have echo ports, for
example.
...
I submit we shouldn't stop at ICMP and should strive for these
mechanisms at each and every level in the protocol stack.
Dave,
I agree with your points. However it may be difficult to do this in
practice. I took a random sampling of hosts I usually ping to measure
their round-trip times and tried connecting to their tcp echo ports
instead. Out of all the hosts I tried, none but the Unix 4.3 hosts were
listening on the echo port (and even some of them were not listening).
It's trivial to write an echo server, but for some reason most hosts
don't seem to support it. Transport-level echo services are not
required in the same sense that ICMP echo is required. If we want to be
assured that we can do debugging at all layers, not only must we push
for debugging protocols at all levels of the protocol stack but
encourage everyone to implement and use these protocols.
--gregboMills@UDEL.EDU.UUCP (04/17/87)
Greg, In a random search I found about half the dozen of so hosts I tried did respond to the TCP Echo port, including all the 4.2s and 4.3s I tried (but not the Suns). At least one Multics machine and all the Fuzzballs I tried responded as well. The SATNET SIMPs have long been used as a tool to debug reassembly implementations, since SATNET can fragment and dis-order datagrams in glorious ways. Nevertheless, your comment is accurate in that the TCP/UDP Echo service is certainly not ubiquitous. It is interesting to note that a TCP/UPD Echo service is trivial to implement, since all it takes is a swap of addresses (and ports in some implementations), which makes it no more intrusive than ICMP Echo. However, this defeats the purpose of the service, which is to verify that the TCP/UPD protocol layer itself is working properly. An interesting side issue is exactly how the echo service is implemented with respect to source-route, record-route, TTL and so forth. Exploration of this may shed some lumens on the general protocol model as well. Dave
narten@PURDUE.EDU (04/21/87)
>It is interesting to note that a TCP/UPD Echo service is trivial to >implement, since all it takes is a swap of addresses (and ports in some >implementations), which makes it no more intrusive than ICMP Echo. While you might get away with this at the TCP layer, it leads to interesting behavior when done with UDP or at lower layers. A certain dedicated IP gateway we have does this very thing when generating ICMP errors, and answering ICMP echo requests. Imagine further, a very widely distributed version of ping that allowed one to send ICMP echo requests to IP broadcast addresses. While pings are harmless enough, I have seen port unreachables fly across our Ethernet that "originate" from an IP broadcast address. Thomas
Mills@UDEL.EDU (04/21/87)
Thomas, An incoming packet, no matter what its protocol or port, with source address a broadcast address, has been formally declared a Chernobyl Packet, since it can lead to Ethernet meltdown. Your somarter gateway (and mine, too, after encountering these things) includes these things in the martian filter, which unceremoneously simply dumps them on the floor of a containment vessel. Dave