Design Considerations

There are three main reasons to build the prototype measurement tool as part of this thesis. The first reason is to measure end-to-end performance between two hosts over both IPv4 and IPv6 protocols for comparative analysis.

Both of the network stacks may or may not follow the same network paths based on the underlying network infrastructure. The motive is to provide a single tool to decide on a better IP protocol between the two to leverage the existence of a Dual IP stack in order to gain performance and better network utilization. Based on measured performance metrics, an application built using the middleware

application can then be run using either IPv4 or IPv6 protocol. For client-server applications involved in large data transfers across the network using sockets (TCP/IP) and taking considerable amount of time to complete transfer, the measurement tool can be especially be useful. This tool can be run as a separate client-server application between the same hosts involved in large data transfers to determine a better protocol between IPv4 and IPv6 at that point of time. The application can then use the switching capability of the middleware application as explained in Chapter 4 to switch to a better IP protocol on the fly if needed. The measurement tool can be run either before running the main application to choose an IP protocol to start with or in parallel as a separate application while the main application is in execution to switch the IP protocol on the fly through the use of the middleware application. The second reason and one of the design considerations is to integrate and measure various end-to-end network performance parameters explained in Chapter 3 combined together in a single measurement tool. Currently the tool is built to measure latency and two types of bandwidths namely path capacity and Bulk Transfer Capacity (BTC) for TCP.

Measuring the capacity helps to gain information on the underlying network infrastructure from host A to host B as it is directly linked to layer-2 links [34].

Capacity remains constant until the underlying network infrastructure changes as explained in Section 3.1.1. Measuring BTC provides real time available bandwidth or TCP throughput offered to an application at a given point of time. BTC is a changing metric as is it influenced by many parameters as explained in Section 3.1.3. Two network paths having the same path capacity may offer different real

time bandwidth. The measurement tool can be run to measure BTC for both IPv4 and IPv6 protocols before the main application runs or while in execution to gain information on current traffic to help decide between the two IP protocols. Thus measuring capacity and BTC helps the application to be aware in terms of both;

its constant maximum bandwidth and real time achievable bandwidth for both IP protocols. The third reason to build the tool is to demonstrate the use of middleware application in creating and operating on socket connections with minimal code for both IPv4 and IPv6 protocols as a proof of concept.

This tool can be classified as an active probing tool to be run in a cooperative environment. It is active probing because it generates its own traffic for performance measurement. It needs a cooperative environment because the tool requires access on both the end points of the networks; client-server communication to measure performance. End-to-end measurement may not be as accurate as compared to its counterpart like using counters maintained by routers, but it is the only feasible approach to measure performance of network paths that cross several networks that do not provide access to underlying hardware for measurement [29]. The design and implementation of the measurement tool can be divided in two sections namely latency measurement and bandwidth measurement. Both measurement techniques make use of UDP and TCP protocols in ways described in their corresponding sections. This tool is run through a command line terminal and does not require any special privileges.

Either latency or bandwidth can be measured at one time and is one of the design considerations so as to not flood the network with probing packets. The user can

specify which parameter to measure as an option while running the tool. This measurement tool makes use of the middleware application functions explained in Chapter 4 to create and operate on sockets for both the IPv4 and IPv6 protocols. A simple example is accomplished by creating sockets using fn_socket() and performing I/O operations on those sockets using middleware application functions like fn_send()/fn_recv(). The socket structure st_mySocket created by fn_socket() is then further utilized for measurement technique. The measurement tool includes the middleware application header file

“commonhdr.h” and link to the shared library libnetaware.so at run time to be able to use the middleware application functions and symbolic constants. It is linked to the middleware application shared library libnetaware.so at runtime.

The next two sections provide more details on the measurement techniques for each of the performance parameters.