7.2 Ping Program

7.2 Ping Program

We call the ping program that sends the echo requests the client, and the host being pinged the server. Most TCP/IP implementations support the Ping server directly in the kernel ” the server is not a user process. (The two ICMP query services that we described in Chapter 6, the address mask and timestamp requests, are also handled directly by the kernel.)

Figure 7.1 shows the ICMP echo request and echo reply messages.

Figure 7.1. Format of ICMP message for echo request and echo reply.

As with other ICMP query messages, the server must echo the identifier and sequence number fields. Also, any optional data sent by the client must be echoed . These are presumably of interest to the client.

Unix implementations of ping set the identifier field in the ICMP message to the process ID of the sending process. This allows ping to identify the returned responses if there are multiple instances of ping running at the same time on the same host.

The sequence number starts at 0 and is incremented every time a new echo request is sent. ping prints the sequence number of each returned packet, allowing us to see if packets are missing, reordered, or duplicated . IP is a best effort datagram delivery service, so any of these three conditions can occur.

Historically the ping program has operated in a mode where it sends an echo request once a second, printing each echo reply that is returned. Newer implementations, however, require the -s option to operate this way. By default, these newer implementations send only a single echo request and output " host is alive " if an echo reply is received, or "no answer" if no reply is received within 20 seconds.

LAN Output

ping output on a LAN normally looks like the following:

 bsdi %  ping svr4  PING svr4 (140.252.13.34): 56 data bytes    64 bytes from 140.252.13.34: icmp_seq=0 ttl=255 time=0 ms    64 bytes from 140.252.13.34: icmp_seq=l ttl=255 time=0 ms    64 bytes from 140.252.13.34: icmp_seq=2 ttl=255 time=0 ms    64 bytes from 140.252.13.34: icmp_seq=3 ttl=255 time=0 ms    64 bytes from 140.252.13.34: icmp_seq=4 ttl=255 time=0 ms    64 bytes from 140.252.13.34: icmp_seq=5 ttl=255 time=0 ms    64 bytes from 140.252.13.34: icmp_seq=6 ttl=255 time=0 ms    64 bytes from 140.252.13.34: icmp_seq=7 ttl=255 time=0 ms  ^?   type interrupt key to stop  --- svr4 ping statistics ---    8 packets transmitted, 8 packets received, 0% packet loss    round-trip min/avg/max = 0/0/0 ms 

When the ICMP echo reply is returned, the sequence number is printed, followed by the TTL, and the round-trip time is calculated. (TTL is the time-to-live field in the IP header. The current BSD ping program prints the received TTL each time an echo reply is received ” some implementations don't do this. We examine the usage of the TTL in Chapter 8 with the traceroute program.)

As we can see from the output above, the echo replies were returned in the order sent (0,1,2, and so on).

ping is able to calculate the round-trip time by storing the time at which it sends the echo request in the data portion of the ICMP message. When the reply is returned it subtracts this value from the current time. Notice that on the sending system, bsdi, the round-trip times are all calculated as 0 ms. This is because of the low-resolution timer available to the program. The BSD/386 Version 0.9.4 system only provides a 10-ms timer. (We talk more about this in Appendix B.) We'll see later that when looking at the tcpdump output from this ping example on a system with a finer resolution clock (the Sun) the time difference between the ICMP echo request and its echo reply is just under 4ms.

The first line of output contains the IP address of the destination host, even though we specified its name ( svr4 ). This implies that the name has been converted to the IP address by a resolver. We examine resolvers and the DNS in Chapter 14. For now realize that if we type a ping command, and a few seconds pass before the first line of output with the IP address is printed, this is the time required for the DNS to determine the IP address corresponding to the hostname.

Figure 7.2 shows the tcpdump output for this example.

Figure 7.2. ping output across a LAN.

The time between sending the echo request and receiving the echo reply is always 3.7 ms. We can also see that echo requests are sent approximately 1 second apart.

Often the first round-trip time is larger than the rest. This occurs if the destination's hardware address isn't in the ARP cache of the sender. As we saw in Chapter 4, sending an ARP request and getting the ARP reply can take a few milliseconds before the first echo request can be sent. The following example shows this:

 sun %  arp -a   make sure ARP cache is empty  sun %  ping svr4  PING svr4: 56 data bytes      64 bytes from svr4 (140.252.13.34): icmp_seq=0. time=7. ms      64 bytes from svr4 (140.252.13.34): icmp_seq=l. time=4. ms      64 bytes from svr4 (140.252.13.34): icmp_seq=2. time=4. ms      64 bytes from svr4 (140.252.13.34): icmp_seq=3. time=4. ms  ^?   type interrupt key to stop  ---svr4 PING Statistics----      4 packets transmitted, 4 packets received, 0% packet loss      round-trip (ms) min/avg/max = 4/4/7 

The additional 3 ms in the first RTT is probably for the ARP request and reply.

This example was run on the host sun, which provides a timer with microsecond resolution, but the ping program prints the round-trip times with only millisecond resolution. The earlier example, run under BSD/386 Version 0.9.4, printed the round-trip times as 0 ms, since the available timer provided only 10-ms accuracy. The following output is from BSD/386 Version 1.0, which provides a timer with microsecond resolution and a version of ping that prints the higher resolution.

 bsdi %  ping svr4  PING svr4 (140.252.13.34): 56 data bytes     64 bytes from 140.252.13.34: icmp_seq=0 ttl=255 time=9.304 ms     64 bytes from 140.252.13.34: icmp_seq=l ttl=255 time=6.089 ms     64 bytes from 140.252.13.34: icmp_seq=2 ttl=255 time=6.079 ms     64 bytes from 140.252.13.34: icmp_seq=3 ttl=255 time=6.096 ms  ^?   type interrupt key to stop  --- svr4 ping statistics ---     4 packets transmitted, 4 packets received, 0% packet loss     round-trip min/avg/max = 6.079/6.880/9.304 ms 

WAN Output

On a wide area network the results can be quite different. The following example was captured on a weekday afternoon, a time when the Internet is normally busy:

 gemini %  ping vangogh.cs.berkeley.edu  PING vangogh.cs.berkeley.edu: 56 data bytes     64 bytes from (128.32.130.2): icmp_seq=0. time=660. ms     64 bytes from (128.32.130.2): icmp_seq=5. time=1780. ms     64 bytes from (128.32.130.2): icmp_seq=7. time=380. ms     64 bytes from (128.32.130.2): icmp_seq=8. time=420. ms     64 bytes from (128.32.130.2): icmp_seq=9. time=390. ms     64 bytes from (128.32.130.2): icmp_seq=14. time=110. ms     64 bytes from (128.32.130.2): icmp_seq=15. time=170. ms     64 bytes from (128.32.130.2): icmp_seq=16. time=100. ms  ^?   type interrupt key to stop  ----vangogh.CS.Berkeley.EDU PING Statistics----     17 packets transmitted, 8 packets received, 52% packet loss     round-trip (ms) min/avg/max = 100/501/1780 

Either the echo requests or the echo replies for sequence numbers 1, 2, 3, 4, 6, 10, 11, 12, and 13 were lost somewhere. Note also the large variance in the round-trip times. (This high packet loss rate of 52% is an anomaly. This is not normal for the Internet, even on a weekday afternoon.)

It is also possible across WANs to see packets duplicated (the same sequence number printed two or more times), and to see packets reordered (sequence number N + 1 printed before sequence number N).

Hardwired SLIP Links

Let's look at the round-trip times encountered over SLIP links, since they often run at slow asynchronous speeds, such as 9600 bits/sec or less. Recall our serial line throughput calculations in Section 2.10. For this example we'll set the speed of the hardwired SLIP link between hosts bsdi and slip to 1200 bits/sec.

We can estimate the round-trip time as follows . First, notice from the example Ping output shown earlier that by default it sends 56 bytes of data in the ICMP message. With a 20-byte IP header and an 8-byte ICMP header this gives a total IP datagram size of 84 bytes. (We can verify this by running tcpdump -e and seeing the Ethernet frame sizes.) Also, from Section 2.4 we know that at least two additional bytes are added: the END byte at the beginning and end of the datagram. It's also possible for additional bytes to be added by the SLIP framing, but that depends on the value of each byte in the datagram. At 1200 bits/sec with 8 bits per byte, 1 start bit, and 1 stop bit, the rate is 120 bytes per second, or 8.33 ms per byte. Our estimate is then (86 — 8.33 — 2), or 1433 ms. (The multiplier of 2 is because we are calculating the round-trip time.)

The following output verifies our calculation:

 svr4 %  ping -s slip  PING slip: 56 data bytes     64 bytes from slip (140.252.13.65): icmp_seq=0. time=1480. ms     64 bytes from slip (140.252.13.65): icmp_seq=l. time=1480. ms     64 bytes from slip (140.252.13.65): icmp_seq=2. time=1480. ms     64 bytes from slip (140.252.13.65): icmp_seq=3. time=1480. ms  ^?  ----slip PING Statistics----     5 packets transmitted, 4 packets received, 20% packet loss     round-trip (ms) min/avg/max = 1480/1480/1480 

(The -s option is required for SVR4 to send one request every second.) The round-trip time is almost 1.5 seconds but the program is still sending out each ICMP echo request at 1-second intervals. This means there are two outstanding echo requests (sent at time 0 and time 1) before the first reply comes back (at time 1.480). That's also why the summary line says one packet has been lost. It really hasn't been lost, it's probably still on its way back.

We'll return to this slow SLIP link in Chapter 8 when we examine the traceroute program.

Dialup SLIP Links

The conditions change with a dialup SLIP link since we now have modems on each end of the link. The modems being used between the systems sun and netb provide what is called V.32 modulation (9600 bits/sec), V.42 error control (also called LAP-M), and V.42bis data compression. This means that our simple calculations, which were fairly accurate for a hardwired link where we knew all the parameters, become less accurate.

Numerous factors are at work. The modems introduce some latency. The size of the packets may decrease with the data compression, but the size may then increase to a multiple of the packet size used by the error control protocol. Also the receiving modem can't release received data bytes until the cyclic redundancy character (the checksum) has been verified . Finally, we're dealing with a computer's asynchronous serial interface on each end, and many operating systems read these interfaces only at fixed intervals, or when a certain number of characters have been received.

As an example, we ping the host gemini from the host sun:

 sun %  ping Gemini  PING gemini: 56 data bytes     64 bytes from gemini (140.252.1.11): icmp_seq=0. time=373. ms     64 bytes from gemini (140.252.1.11): icmp_seq=l. time=360. ms     64 bytes from gemini (140.252.1.11): icmp_seq=2. time=340. ms     64 bytes from gemini (140.252.1.11): icmp_seq=3. time=320. ms     64 bytes from gemini (140.252.1.11): icmp_seq=4. time=330. ms     64 bytes from gemini (140.252.1.11): icmp_seq=5. time=310. ms     64 bytes from gemini (140.252.1.11): icmp_seq=6. time=290. ms     64 bytes from gemini (140.252.1.11): icmp_seq=7. time=300. ms     64 bytes from gemini (140.252.1.11): icmp_seq=8. time=280. ms     64 bytes from gemini (140.252.1.11): icmp_seq=9. time=290. ms     64 bytes from gemini (140.252.1.11): icmp_seq=10. time=300. ms     64 bytes from gemini (140.252.1.11): icmp_seq=ll. time=280. ms     ----gemini PING Statistics----     12 packets transmitted, 12 packets received, 0% packet loss     round-trip (ms) min/avg/max = 280/314/373 

Note that the first RTT is not a multiple of 10 ms, but every other line is. If we run this numerous times, we see this property every time. (This is not caused by the resolution of the clock on the host sun, because we know that its clock provides millisecond resolution from the tests we run in Appendix B.)

Also note that the first RTT is larger than the next , and they keep decreasing , and then they range between 280 and 300 ms. If we let it run for a minute or two, the RTTs stay in this range, never going below 260 ms. If we calculate the expected RTT at 9600 bits/sec (Exercise 7.2) we get 180 ms, so our observed values are about 1.5 times the expected value.

If we run ping for 60 seconds and look at the average RTT it calculates, we find that with V.42 and V.42bis our average is 277 ms. (This is better than the average printed for our preceding example, because we ran it longer to amortize the longer RTTs at the beginning.) If we turn off just the V.42bis data compression our average is 330 ms. If we turn off the V.42 error control (which also turns off the V.42bis data compression) our average is 300 ms. These modem parameters do affect the RTTs, and using the error control and data compression appears to be the best.