In this section I describe how to run nettimer for actively probing the bottleneck link bandwidth. This is useful if you don't have any existing traffic that you want to measure.
However, the active probing mode has two limitations: 1) it can't measure asymmetric links, and 2) it puts a possibly significant load on the network.
The active probing mode currently cannot measure asymmetric links because it can only measure the bandwidth from the measurement to host to another host. This is because it's difficult to cause arbitrary Internet hosts to respond with two packets back-to-back. Consequently, you can only measure the bandwidth going in one direction of an asymmetric link unless you can run nettimer on both sides of the link (but not necessarily adjacent to it).
The active probing mode puts a possibly significant load on the network. In general, you should remember that the owner of the remote host has better things to do with his/her network bandwidth than carry your measurement traffic. Therefore, you should try to make sure that the measurement traffic isn't putting a noticeable burden on anyone's network. Otherwise, someone is going to think you are lauching a denial-of-service attack against them.
Using the default parameters given below, the traffic that the active mode generates is at most 64,000 bits. This is only a problem for very low bandwidth links (less than 28Kb/s) unless you are running the program very frequently. As a result, you are ok most of the time using the default parameters. However, the default parameters may not give you the most accurate results (as detailed below), so you may want to change them.
In this mode, the program will send some number of TCP FIN packets to ports on the destination host. The port is incremented for each packet. These packets should cause TCP RESET packets to be sent back to the measurement host. The program captures these packets, makes calculations, and decides whether to repeat the experiment. The following arguments control nettimer's behavior:
nettimer { ––active_probing_addresses [src_addr[:src_service] ]dst_addr[:dst_service] } [ ––active_probing_burst_size burst_size ] [ ––active_probing_packet_size packet_size ] [ ––active_probing_min_samples min_samples ] [ ––active_probing_max_packets_sent max_packets_sent ] [ ––active_probing_max_error max_error ] [ ––active_probing_timeout timeout ]
The dst_addr specifies the IP address or hostname of the destination. It must be specified. The other parts of the active_probing_adddresses are optional. The dst_service specifies the destination port to start with (default: 10100). The src_addr and src_service specify the source port and service, respectively.
The packet_size parameter specifies the size in bytes of the packets to be sent. Increase this value (max: 1500 bytes) when measuring high bandwidth links on slow hosts. Larger packets reduce the effect of client-based sources of error like poor packet capture timing precision (which usually occurs on slow hosts). This is necessary for high bandwidth bottleneck links. On the other hand, larger packets are more likely to encounter interference from other packets and put a larger load on the network.
The burst_size parameter specifies the number of packets to sent back-to-back. The larger this number is, the more accurate result you will get, until you send enough packets to cause packets to be dropped from a queue. Also, increases this number increases the load on the network.
The timeout parameter specifies the time to wait for the reception of all the expected packets of one burst until another burst is sent. If this is too low, then bursts will be sent before the last burst has cleared from the queue. If this is too high, then measurement will take a long time.
The min_samples, max_packets_sent, and max_error parameters specify the conditions under which the active probing will complete. If the program has collected at least min_samples samples and the error is below max_error, then the program will exit successfully. Otherwise, it will continue sending bursts until max_packets_sent packets have been sent and the program will exit with an exception.
In this section, I describe how to interpret the results that nettimer generates.
The first line of the output gives the bandwidth estimate, error estimate, and the number of samples used to generate the estimate. The following lines give the number of packets sent, the number of packets received, and the number of timeouts during measurement. Finally, an exception is printed if the final error exceeds the specified maximum error.
An example of the output:
BW: 7995536.719157 Error: 0.554183 Samples: 12
Active probing statistics:
packets sent: 16
packets received: 16
timeouts: 0
KLException caught in program: "nettimer"
at file: "nettimer.c" function: "main" line: XXX
Passed at file: "packet_capture.c" function: "packet_capture_event_handler" line: XXX
meaning: "Client exception."
Passed at file: "dpcap_flow.c" function: "flow_set_new_packet" line: XXX
meaning: "client exception"
Thrown at file: "active_probing.c" function: "active_probing_packet_new" line: XXX
meaning: "Exceeded active probing sent packets maximum."
nettimer exitting
|
This example shows that the estimated bottleneck link bandwidth is 7.995536 Mb/s, the estimated error is 55%, and the number of samples used was 12. This measurement was done on a busy 10Mb/s Ethernet which is why the error was so high. 16 packets were sent and 16 were received. Since the error was so high, the maximum number of packets were sent, and the program exits with an exception.
You may see that the results vary significantly between runs. The sources of error for the active probing are 1) cross traffic, 2) poor packet capture timing resolution and high bandwidth links, and 3) a short round trip time.
Cross traffic will cause arbitrary error in the measurement. Try measuring at a time when you know the there is little cross traffic (e.g. early in the morning).
Poor packet capture timing precision will prevent you from measuring a high bandwidth link. Poor packet capture timing precision is usually caused by a slow host and bugs in the packet capture library or OS kernel. The solutions are to run nettimer on a faster host, upgrade the packet capture library and/or OS kernel, or increase the active probing packet size.
A short round trip time can cause errors because the TCP RESET packet can arrive before the last TCP FIN packet in a burst is sent. Probe to a host that is farther away, decrease the burst size, or increase the packet size.