Abstract: In recent years, there has been a strong interest in measuring the available bandwidth of network paths. Several methods and techniques have been proposed and various measurement tools have been developed and evaluated. However, there have been few comparative studies with regard to the actual performance of these tools. This research project presents a study of available bandwidth measurement techniques for both PRTG and Oaunetmon and undertakes a comparative analysis in terms of accuracy, intrusiveness and response time of active probing tools. Finally, measurement errors and uncertainty of the tools are analyzed and overall conclusions were made.

INTRODUCTION

Active bandwidth estimation tools can not only provide network operators with useful information on network characteristics and performance but also can enable end users (and user applications) to perform independent network auditing, load balancing and server selection tasks, among many others, without requiring access to network elements or administrative resources (Case et al., 1990).

Application users on high-speed networks perceive the network as an end-to-end connection between resources of interest to them. Discovering the least congested end-to-end path to distributed resources is important for optimizing network utilization. Therefore, users and application designers need tools and methodologies to monitor network conditions and to rationalize their performance expectations (Lee et al., 2007).

Several network characteristics related to performance are measured in bits per second: capacity, available bandwidth, bulk transfer capacity and achievable TCP throughput. Although, these metrics appear similar, they are not and knowing one of them does not generally imply that one can say anything about others (Oetiker and Rand, 1998).

Bandwidth estimation tools face increasingly difficult measurement challenges as link speeds increase and network functionality grows more complex. Consider the issue of time precision: on faster links, interval between packets decrease, rendering packet probe measurements more sensitive to timing errors (Zhang et al., 2005). The nominal 1 μs resolution of UNIX timestamps is acceptable when measuring 120 μs gaps between 1500 B packets on 100 Mb sec^-1 links but insufficient to quantify packet Inter Arrival Time (IAT) variations of 12 μs gaps on Gige links.

The research community is developing a set of metrics and techniques for active bandwidth measurement. Many of them are well understood and can provide accurate estimates under certain conditions (Kola and Vernon, 2006).

Also, some partial measurement and evaluation studies of bandwidth estimation tools have been published but the preference has been given to the lack of publicly available comprehensive and comparative experimental results (Chobanyan et al., 2008).

As we performed test over PRTG and Oaunetmon, comparative analysis procedures were being developed. Among these, a number of generic criteria were highlighted. These criteria have been classified into two groups: a first set of criteria specified as simple numerical and scalar metrics that provide a partial comparison of tools performance, a second set of criteria that provide comparative evaluation of tools performance. The first set includes metrics that can be useful to quickly choose or discard some techniques and tools according to simple constraints such as required time or allowed probe bandwidth, some of these metrics are the following (Fraiwan and Manimaran, 2008):

The second set of criteria for comparative analysis between different techniques includes but is not limited to the following (Haga et al., 2007):

PRTG and Oaunetmon monitor network and bandwidth usage as well as various other network parameters like memory and CPU usages, providing system administrators with live readings and periodical usage trends to optimize the efficiency, layout and setup of leased lines, routers, firewalls, servers and other network components.

This research project provides a comparative study of two Available Bandwidth (ABw) techniques (PRTG and Oaunetmon) taking into account the statistical conditions of the ABw, several improvement of Oaunetmon in terms of accuracy and efficiency and a performance evaluation of Oaunetmon under a DiffServ environment.

The same study was carried out for PRTG and the results obtained were compared with Oaunetmon and recommendations were made only to know which among the two to choose when a bandwidth is to be measured in order to obtain accurate, reliable and up-to-date results.

Research justification: The following are the contributions of this research work in particular:

Research aim and objectives: The aim of this research is to carry out a research work on the measurement of comparative evaluation of available bandwidth estimation tools in a campus Wide Area Network (PRTG and Oaunetmon).

The objectives of this research work include the following:

MATERIALS AND METHODS

To compare the performance of the measurement tools studied; Oaunetmon and PRTG, a set of experiments were carried out on an isolated network that comprises three Cisco 1700 series routers that is SNMP enabled connected through FastEthernet links.

The network built for tests, comprise sender and receiver hosts, belonging to different LANs on which several cross-traffic sources are active.

The used hosts are equipped with Debian Linux and have the same hardware configuration. A couple of hosts are used as the sender and the receiver part of the measurement tool, while the other hosts are used as the source and the destination for the cross-traffic. The choice of an isolated network is motivated by the need to totally control the network under test.

The methodology adopted so far include the following:

The research takes one step further the testing and comparing publicly (PRTG and Oaunetmon) for available bandwidth estimation. First, I conducted two series of reproducible laboratory tests in a fully controlled environment using two different sources of cross-traffic. Second, I experimented on high-speed paths in real networks, where there is a complete knowledge of link capacities and had access to SNMP counters for independent cross traffic verification. Finally, I compare the accuracy and other operational characteristics of the tools and analyze factors impacting their performance.

Overview of PRTG-paessler router traffic grapher: PRTG Traffic Grapher is an easy to use Windows application for monitoring and classifying bandwidth usage. It provides system administrators with live readings and long-term usage trends for their network devices (Fraiwan and Manimaran, 2008). PRTG is mainly used for bandwidth usage monitoring but may also be used to monitor many other aspects of a network such as memory and CPU utilization.

With PRTG Traffic Grapher the user receives comprehensive bandwidth and network usage data that helps to optimize the efficiency of the network. Understanding bandwidth and resource, consumption is the key to better network management: Avoid bandwidth and server performance bottlenecks; find out what applications or what servers use up your bandwidth; deliver better quality of service to your users by being proactive; reduce costs by buying bandwidth and hardware according to actual load.

The Freeware Edition of PRTG Traffic Grapher is completely free for personal and commercial use and may be downloaded for free. PRTG Traffic Grapher is designed to run on a Windows machine in your network for 24 h every day and constantly records the network usage parameters. The recorded data is stored in an internal database for later reference. Using an easy to use Windows interface you can configure the monitored sensors as well as create usage reports. For remote access PRTG Traffic Grapher comes with a built-in web server to provide access to graphs and tables.

All common methods for network usage data acquisition are supported:

SNMP: Simple Network Management Protocol is the basic method of gathering bandwidth and network usage data. It can be used to monitor bandwidth usage of routers and switches port-by-port as well as device readings like memory, CPU load etc.

Packet sniffing: With its built-in Packet Sniffer PRTG can inspect all network data packets passing the network card to calculate the bandwidth usage.

Netflow: The NetFlow protocol is supported by most Cisco routers to measure bandwidth usage.

How to choose a method of data acquisition: There are four methods of Data Acquisition when using PRTG for measuring bandwidth. They are:

PRTG network monitor system architecture: PRTG network monitor consists of three main parts:

PRTG Core Server: The central part of a PRTG installation is the “Core Server” that includes data storage, web server, report engine and notification system.

PRTG probe: A probe performs the actual monitoring. It receives its configuration from the Core Server, runs the monitoring processes and delivers monitoring results back to the Core Server. A Core Server can manage an unlimited number of Probes in order to achieve multi location monitoring.

PRTG web interface: The user interface is completely web-based. The users access the configuration and monitoring results using a standard web browser.

Core and probe are Windows services, which are run by the Windows system without the requirement for a user to be logged in. The monitoring system runs on the Linux operating system. Monitoring was done using open source IPTraf software.

A wrapper script was used to start the IPTrafprogram with suitable command line arguments to sort the output of IPTraf based on IP address and protocol and it creates suitable inputs for PRTG and Webaliser. After starting up IPTraf and initializing some variables, the wrapper script is responsible for processing the summary information from IPTraf into suitable log formats both for PRTG and Webaliser. The software aims at doing the processing very fast and as such it is not complicated. In order to maintain system stability and minimize memory leaks, the software restarts every 24 h. Other script used are run_PRTG, PRTG_reader, run_webaliser and webaliser_caller (Lee et al., 2007).

Oaunetmon overview: The developed non intrusive traffic monitoring and analysis system (Oaunetmon) is different from similar tools because it is non intrusive. It uses open source software and has the capability to show traffic information on Global, host and protocol basis. It can keep historical information about network usage.

Fig. 1:	Design architecture of PRTG

Fig. 2:	Design architecture of Oaunetmon, Oaunetmon traffic monitoring setup at University of Ibadan

It can also give a graphical overview as well as a detailed statistics. It has the ability to monitor and analyze traffic in a switched network such as Fast Ethernet and Gigabit Ethernet. Apart from monitoring and analyzing network traffic, Oaunetmon can also carry out proxy log analysis using Webalizer (Abiona et al., 2006).

The Obafemi Awolowo University Network Monitoring (Oaunetmon) experiment was conducted with the aim of monitoring live network without adversely imparting on the performance and also to identify and monitor traffic patterns (both speed and volume) on the basis of host (IP address), protocol and time of the day (Abiona et al., 2006). For this experiment, open source software was used for the reason of ease modification and cost. On a high-speed network, the system may not be able to handle all packets in time.

If the processing speed or the system itself operates at speed insufficient to capture all packets, the analysis result is unreliable. The project was to set up a single monitoring station that will monitor all the traffic. The Fig. 1 and 2 shows the architecture of Oaunetmon as it was used to monitor the traffic on the University of Ibadan Network.

RESULTS AND DISCUSSION

The results obtained for both the PRTG and Oaunetmon are presented in the Table 1. For each of the tools, there is a corresponding value for the following:

Each of the parameters are properly observed and studied into detail for each of the tools and conclusions were drawn from their characteristics. It is important to note that all the hardware requirements for both tools were the same in order to obtain dependable and consistent results on the same network.

For Oaunetmon, the results were obtained at every 5 min interval for a complete day. But for PRTG, the results obtained indicate a daily values for each of the parameters stated. Hence, the totals for 10-June 2008 from 9:30 PM to 11-June 20008 till 9:30 PM indicate a daily average as it was obtained for PRTG, which is on daily basis. The values obtained for each of the tools were used to determine the bandwidth requirements for the network.

Results obtained: The discussion on the results obtained from these experimental works was analyzed under the following criteria:

The network coverage: The network coverage value tells whether the monitoring was on all the time and covered the complete time period.

From the Table 1, the result shows that Oaunetmon has nearly 100% network coverage unlike PRTG with poor network coverage characteristics. This feature undoubtedly shows efficiency and reliability in Oaunetmon, which is a characteristic to rely on for any bandwidth measuring tool in order to obtain accurate result.

Daily result characteristics: The daily results obtained shows that PRTG did not give any result for few days. In Oaunetmon, this did not arise. For each of the day, the results were fully obtained and the required data were recorded. Daily result characteristics indicates that Oaunetmon is still far better to rely for precision of the result unlike PRTG, which omitted some results in most of its daily readings.

Speed required for implementing the tools: When both PRTG and Oaunetmon were both implemented on the network, it was clearly observed and noticed that Oaunetmon runs faster; two times the time required by PRTG for its implementation on the same network.

Speed required in generating the output: Of course, when the speed used by a particular tool is faster than the other, what this mean invariably is that the time, when the output will be generated shall definitely be different. Oaunetmon takes the opportunity of having a better running time to generate its result in a better time than PRTG. It was noticed that 3 min after Oaunetmon would have started generating its results that PRGT will just begin displaying its result on the same network.

Code size: PRTG has a better advantage over Oaunetmon in this regard. The size of code required for implementation on the network for PRTG is 7.302 kb whereas, Oaunetmon has 8.323 kb.

Bandwidth requirement: There are two approaches to getting bandwidth in this case:

Comparing the average total volume bandwidth For Oaunetmon: This is an important parameter for determining the efficiency, dependability, accuracy and precision of any bandwidth measuring tool.

Table 1:	Showing the characteristics features of PRTG and oaunetmon as demonstrated on the network

From 10-June 20008 9:30 pm to 11-June 20008 9:25 pm to 9:30 pm as shown in the statistical Table 1 obtained for Oaunetmon and which was obtained at 5 min interval, the following values were obtained:

Therefore, the amount of bandwidth required in this case is calculated as follow:

For PRTG: From 01-Mar 2008 to 23-May 2008, the following results were obtained from PRTG:

To calculate the equivalent bandwidth requirement as we have in Oaunetmon for PRTG, the following procedures are to be followed:

Hence,

From the calculation, it is clear that the bandwidth required, when Oaunetmon was used is better compare to bandwidth required by PTRG. The bandwidth required by the Oaunetmon is 275251.723625 Mbps, while the bandwidth required by the PRTG is 818555.78 Mbps, which is almost four times bandwidth required by the Oaunetmon.

Comparing the random bandwidth values: For Oaunetmon, from the result shown above, it is noted that the total volume for the Bandwidth Traffic in is 2,202,013.789 Kbyte and total volume for the Bandwidth Traffic out is 933,737.354Kbyte.

But for the PRTG, since there is more than a day value for total volume of Bandwidth Traffic in and Bandwidth Traffic out, the analysis is therefore base on randomly selection of values.

For example, on 23rd May 2008, the Bandwidth Traffic in is 2,106,288.017 Kbyte and the Bandwidth Traffic out is 1,185,471.328 Kbyte for PRTG and this is better than Oaunetmon. But on 30th April 2008 and 29th April, 2008 the Bandwidth Traffic out for PRTG are 4,585,835.226 and 2,887,869.427 Kbyte, respectively. In this case, the Bandwidth requirement for PRTG is poor, when compare to Oaunetmon.

This approach shows that neither Oaunetmon requires less/higher bandwidth nor PRTG requires such. There is no definite conclusion with this approach.

Finally, with analysis of the two approaches to bandwidth requirement of the two bandwidth measuring tools, it is noted that Oaunetmon is better in bandwidth requirement than PRTG. The general overview of their (PRTG and Oaunetmon) behaviours can be better interpreted in the Table 1. Table 1 gives a better interpretation of the above parameters used in analyzing the differences between the PRTG and Oaunetmon. Table 1 shows convincingly the acceptable features of Oaunetmon over PRTG.

From the Table 1, the network coverage (%), speed of running(/sec), the rate of generating out, Daily result features as well as the Bandwidth Requirements on the network are features, which have demonstrated the reasons why Oaunetmon should be preferred over the PRTG; in terms of their outputs when both were compared.

Some partial measurement and evaluation studies of bandwidth estimation tools have been published, nonetheless, my attention has been drawn to lack of publicly available comprehensive and comparative experimental results. Not only that, there is lack of common and consistent practices and procedures to test available active bandwidth measurement tools.

With this new research carried out on comparative analysis of both PRTG and Oaunetmon, it is therefore, a great advantage for both the network operators and user applications to make use of a better tool in order to get a better network auditing load balancing and a good server selection as well as the realization of other aims within which this research was carried out.

CONCLUSION

We have presented the systematic comparative analysis of active bandwidth estimation tools (PRTG and Oaunetmon) performed over a broad range of tools, scenario (both emulated and real) as well as experimental conditions, which results are publicly available.

Techniques tools ton estimate capacity, available bandwidth and bulk transfer capacity have been studied jointly. Furthermore, we have tried to analyze and to explain errors and uncertainties observed on the tools we have studied.

The results obtained shown that Oaunetmon is the least intrusive, reliable, consistence and dependable and in some cases can be very slow through with better accuracy and precision, when compare to PRTG. Finally, Oaunetmon offers the best performance with regard to the criteria studied:

The study presented in this project was on the small number of criteria that seemed to be the most important. However, this study must be completed by considering other parameters and by evaluating the measurement tools on real networks settings.

As a result from the tests carried out, a number of failure conditions for the analyzed tools have been identified, as well as the dependency of the estimates accuracy on factors such as system load and network properties.

Future work: We have seen a great challenge to this project; apart from making a comparative study to these bandwidth tools, what stands to be a challenging issue now is how to develop a tool that will compute available bandwidth at different time of the day.

This, undoubtedly, will give overtime statistics of usage pattern (peak an off peak) and to try to investigate why the network is not utilizing the maximum capacity of all times and what could be consuming the unused bandwidth.

Carrying out, this research will go a long way in explaining into detail the concept of bandwidth utilization and management. It will assist the network manager to fully understand how the available bandwidth can be optimized.