We used the NetDyn tool [7,8] in our experiments to observe the three metrics mentioned earlier. NetDyn has four main components, which are shown as ovals within rectangles representing hosts in the figure below. These are Source(udpsend), Echo(udpecho), Sink(udprecv), and Logger(udpread). Although it is possible to merge Sink and Logger, they are kept separate for the purpose of freeing Sink from file update overheads of Logger process. These processes are user level applications (i.e. no root access is required to build or run them) which use UNIX sockets.
Different fields of our probe packets (shown in the figure as divided rectangles near links) are filled by different processes at different times as illustrated in the figure. Source Time Stamp (STS) and Source Sequence Number (SSN) are put into every packet sent out from Source. The echoing process puts its own Time Stamp (ETS) and Sequence Number (ESN) on the packets after it receives the packet, and before sending them back. Note that ESN is increased for every packet that reached Host 2. Thus, if a packet gets lost on its way to Host 2, these two sequence numbers, namely SSN and ESN, will differ. The Sink process will fill in its Time Stamp (SiTS) in the last field of a packet to allow the Logger to calculate round-trip time as:
RTT = SiTS - STS (1)
As these time stamps belong to the same host, we do not need to synchronize clocks as may be necessary in some other approaches. This means we can calculate the RTTs in microsecond granularity (i.e. at a granularity as fine as the gettimeofday() system call.)
The choice for protocol selections in these links is clearly UDP, which lets our programs be awared of the losses and reorders as it is a best-effort protocol. On the other hand, when a packet finishes its trip, we wanted to make sure that it is recorded in our files. That is the reason a reliable protocol, TCP [4], is used between the Sink and the Logger.
In the most common version of our experiments, the Echo was run at a remote host and all the others were run at local hosts at the University of Maryland . Because one of the main aspects of the NetDyn design was flexibility, the system allows the user to start the Logger at a different host. However, as this will put additional load on the network, which we were trying to characterize, we preferred to run all three processes at the same host.
Another flexibility NetDyn provides is the option of using a second host. The system allows the user to utilize the IP's [3] IP _LSRR (Loose Source and Record Route) option to get rid of the Echo process and route the packets back to sender host after putting them on network. Although this kind of experiment would be helpful in understanding the network layer performance, we cannot fully understand the regular end-to-end behavior of such path because packets with IP options are known to be treated differently and given lower priority at many gateways.
· Duration of Experiments: The time it took an experiment to complete is defined by the number of packets and interpacket delay described below.
· Number of Packets: This parameter will define how many packets will be put on to the network by NetDyn. The most typical number we used was 45,000.
· Interpacket Delay: This parameter specifies to the sender (Source) how long it should wait before sending out the next packet. The value we used for this parameter was mostly 40ms, which allowed us to run experiments for half an hour when we set number of packets to 45,000. We believe this duration is sufficient to understand short and long-term network behavior changes.
· Packet Size: The minimum amount of data we need to put on a packet (as seen in the figure above) consists of 3 time stamps (2 words each) and 2 sequence numbers which correspond to a total of 8 words. However the packet size can also be increased to put extra load on the network if preferred.
The main purpose of this study was to understand user-level behavior of a network in providing user level services to the sites of interest to the user community of the National Library of Medicine. This called for a tool that doesn't require special privileges such as kernel modifications, or root user access. This helps in transporting the NetDyn package to any Unix host at which we have user level access, and being able to run experiments without hassles.
Regular user-level behavior is also characterized by the help of the protocol used. Acharya and Saltz [11] used ICMP (i.e. ping), which may be treated differently than user level packets. TCP, being a reliable protocol, would have hidden the losses and reorders, which are among the basic metrics we are investigating. Therefore we used UDP.
One concern, while running the experiments, was putting a load on network that can affect the natural behavior, and skew the results, which we were trying to understand. According to our calculations, with the default parameters mentioned above, NetDyn puts about 1.5KB on the network per second. That is less than 1% for a T1 link, which has a capacity about 185KB per second.
[Top] [Back to NetCalliper Project]
