64
Additional metrics will sometimes be needed. The best choice is usually task dependent. If you are sending real-time audio packets over a long link, you may want to minimize both delay and variability
in the delay. If you are using FTP to do bulk transfers, you may be more concerned with the throughput. If you are evaluating the quality of your link to the Internet, you may want to look at
bottleneck bandwidth for the path. The development of reliable metrics is an active area of research.
4.2.2 Bandwidth Measurements
We will begin by looking at ways to estimate bandwidth. Bandwidth really measures the capabilities of our hardware. If bandwidth is not adequate, you will need to reexamine your equipment.
4.2.2.1 ping revisited
The preceding discussion should make clear that the times returned by ping, although frequently described as propagation delays, really are the sum of the transmission, propagation, and queuing
delays. In the last chapter, we used ping to calculate a rough estimate of the bandwidth of a connection and noted that this treatment is limited since it gives a composite number.
We can refine this process and use it to estimate the bandwidth for a link along a path. The basic idea is to first calculate the path behavior up to the device on the closest end of the link and then calculate
the path behavior to the device at the far end of the link. The difference is then used to estimate the bandwidth for the link in question.
Figure 4-4 shows the basic arrangement.
Figure 4-4. Link traffic measurements
This process requires using ping four times. First, ping the near end of a link with two different packet sizes. The difference in the times will eliminate the propagation and queuing delays along the path
assuming they havent changed too much leaving the time required to transmit the additional data in the larger packet. Next, use the same two packet sizes to ping the far end of the link. The difference in
the times will again eliminate the overhead. Finally, the difference in these two differences will be the amount of time to send the additional data over the last link in the path. This is the round-trip time.
Divide this number by two and you have the time required to send the additional data in one direction over the link. The bandwidth is simply the amount of additional data sent divided by this last
calculated time.
[3] [3]
The formula for bandwidth is BW = 16 x P
l
-P
s
t
2l
-t
2s
-t
1l
+t
1s
. The larger and smaller packet sizes are P
l
and P
s
bytes, t
1l
and t
1s
are the ping times for the larger and smaller packets to the nearer interface in seconds, and t
2l
and t
2s
are the ping times for the larger and smaller packets to the distant interface in seconds. The result is in bits per second.
Table 4-1 shows the raw data for the second and third hops along the path shown in
Figure 4-1 .
Packets sizes are 100 and 1100 bytes.
65
Table 4-1. Raw data IP address
Time for 100 bytes Time for 1100 bytes
205.153.61.1 1.380 ms
5.805 ms 205.153.60.2
4.985 ms 12.823 ms
165.166.36.17 8.621 ms
26.713 ms Table 4-2
shows the calculated results. The time difference was divided by two RRT correction, then divided into 8000 bits the size of the data in bits, and then multiplied by 1000 milliseconds-to-
seconds correction.. The results, in bps, were then converted to Mbps. If several sets of packets are sent, the minimums of the times can be used to improve the estimate.
Table 4-2. Calculated bandwidth Near link
Far link Time difference
Estimated bandwidth
205.153.61.1 205.153.60.2
3.413 ms 4.69 Mbps
205.153.60.2 165.166.36.17
10.254 ms 1.56 Mbps
Clearly, doing this manually is confusing, tedious, and prone to errors. Fortunately, several tools based on this approach greatly simplify the process. These tools also improve accuracy by using multiple
packets.
4.2.2.2 pathchar
