Measuring Round Trip Times With Ping

Exercise #1

a)Our results:

    www.lcs.mit.edu	1/7/22 ms	(100% packets received)
    www.stanford.edu	81/86/96 ms	(100% packets received)
    www.cca.vu.nl	116/130/171 ms	(100% packets received)
    www.kyoto-u.ac.jp	197/211/241 ms	(100% packets received)

There numbers are not exact and may be different depending on when and where you did the exercise. The point of this part is to make the grading of the next part more flexible. The answers to the next part should correlate to the observations from this part.

In general, however, the round-trip times should be increasing as we go down the list since the sites get further and further away from MIT.

Comment:
The extra 8 bytes for each reply packet comes from the header for echo-request and echo-response packets (an 8 byte ICMP header in addition to the 56 bytes of data).

b) The minimum round-trip times get longer as the distance of the host from MIT increases.

Comments:
This observation is related to the 6.033 concept that as we try to communicate over longer distances, the speed of light begins to limit the speed at which we can communicate.

c) Once again, some experimental values:

 For 512 data byte packets:
   www.lcs.mit.edu	3/4/13 ms	(100% received)
   www.stanford.edu	84/90/109 ms	(100% received)
   www.cca.vu.nl	119/121/125 ms	(100% received)
   www.kyoto-u.ac.jp	200/205/210 ms	(95% received)

 For 1024 data byte packets:
   www.lcs.mit.edu	6/12/33 ms	(100% received)
   www.stanford.edu	88/95/147 ms	(100% received)
   www.cca.vu.nl	124/126/140 ms	(100% received)
   www.kyoto-u.ac.jp	206/213/246 ms	(100% received)

d) The minimum round trip times increase as size of the packets increase.

Comment:
Larger packets have a longer transmission delay since the sending and receiving machines must spend more time just getting the packet on and off the network. The time it takes to put the packet onto the network is determined by the bandwidth and the amount of data being transmitted.

However, the transmission delay is small compared to the latency caused by the propagation delay. Hence the amount of additional time for larger packets is small compared to the amount of additional time observed for exercise 1a.

Exercise #2

a)

Again, experimental results:
    www.pku.edu.cn	   711/762/839 ms	(90% received)
    www.wits.ac.za	   583/613/679 ms	(95% received)
    pastwatch.lcs.mit.edu  2/7/42 ms		(85% received)
    www.microsoft.com	   N/A			(0% received)

The machine pastwatch.lcs.mit.edu was configured to drop 25% of the packets it received, statistically speaking. However, some variance in terms of the round trip times and percentage of successful responses are to be expected.

The www.microsoft.com host does not send back any ping responses.

b) A few of the possible responses:

1) Saving of resources: The www.microsoft.com site might be trying to minimize the number of services on its web site so that the system can focus on serving web requests.

2) Security: By providing fewer services, fewer security "holes" are likely to exist. People have been known to use ping to send very large packets to hosts. These packets cause the servers' buffers to overflow and crash the system.

3) Firewall: The www.microsoft.com machine could be hidden behind a firewall which only allows http requests to pass. Hence ICMP packets never make it to www.microsoft.com.

4) Crash: The system on the other end might have crashed.

5) Temporary Congestion: The network may be dropping packets because of congestion.

6) Network failure: The network connection to or from a host may have failed.

7) Hacked Machine: A machine was modified to behave by dropping packets.

This list does not exhaustively enumerate all the possible answers. If you have any further suggestions, email 6.033-tas@mit.edu.