Revisiting the remarkably resilient ping utility

One of the most basic tools in the IP tool kit is the packet Internet groper, or ping, utility. All ping does is bounce packets off another machine running TCP/IP and measure the time it takes the packets to get there and back.

Doesn't sound like much, but it's a tool you absolutely must have. The reason is that ping is available on just about every platform that supports TCP/IP and answers two questions: Do I have a connection, and is that connection any good?

Ping is based on a core protocol of the TCP/IP suite, the Internet Control Message Protocol (ICMP). The purpose of ICMP is to let a receiving computer or an intermediate gateway device inform the computer that originated an IP packet that it must take corrective action.

For example, if the packet was corrupted in transit, the ICMP message would request a retry. Or if the destination was unreachable, a gateway would use ICMP to inform the sender to try something else.

To see where ICMP fits in, let's take a second to review the TCP/IP architecture. At the lowest level is the network layer, roughly equivalent to the physical and data link layers of the good old Open Systems Interconnection model. This is where the standards for network transports, notably Ethernet, live.

The next TCP/IP layer on the stack is the Internet layer, equivalent to OSI's network layer, which encompasses the Internet Protocol. On top of that sits the transport layer, which equates to the OSI layer of the same name and is the domain of TCP.

Finally, we have TCP/IP's application layer, which encompasses the final three layers of the OSI model.

Now, back to ICMP. ICMP datagrams are encapsulated in IP packets, so the protocol should logically be part of the transport layer. But as ICMP actually modifies the behavior of the IP layer, it is functionally an IP protocol.

ICMP has many functions. Central to our interest is the ICMP echo request. Support for the echo request is a basic design element of TCP/IP stacks. Upon receipt of an ICMP echo request, TCP/IP responds by immediately sending an identical packet back to the sender.

The length of a ping datagram is variable from one to 1,472 bytes. This leads to an interesting hack: Have you ever wondered how people come up with the statistics of which machines are running what operating systems on the Internet?

The answer is that they send out malformed ping requests of various lengths. Because each TCP/IP stack handles the error reply differently (there's no defined standard), each implementation has a different response.

But what's really useful about ping is you can not only find out if another computer is online, but you can also determine how far away it is. This relies on another simple technique: When a ping request is sent, the payload includes a time stamp of when the packet was transmitted.

If the remote machine responds, the time stamp in the returned packet is compared to the current time to determine how long it took for the packet to get there and back. That value is then halved, and that gives the average time required for a packet to travel from one computer to the other.

In large TCP/IP networks, ping gives valuable insight into how the system is performing. For example, as routers drop out, packets may change their routing and therefore transit time may increase (or, rarely, decrease).

Packets may also be lost. Large, heavily trafficked routers do, in fact, drop packets because TCP/IP has the ability to resend lost packets. And when you run a ping utility, what you will get in addition to the transit time will be a count of dropped packets.

Next week, ping software. Packets to gh@gibbs.com.