The main drawback of previously discussed performance measurement tools is their client-server architecture, which makes the transmission of test data through the network along multiple paths in parallel difficult. To test the multiple paths, the clients need to execute in parallel on different nodes and have to run the server multiple times as well. Using the client – server architecture based tools to set up testing framework that involves multiple clients in a monotonous task. As well as these scenarios lead to the synchronization problems as well. For example, even if the two clients start the testing at the same time, there might be a chance that one client is still exchanging the testing parameters with its server, while the other clients have already begun the actual data testing with the server. The consequence of this lack of synchronization leads to the inaccurate results in the testing [62].
The bidirectional protocols like TCP can send the data in the both directions at the same time. But unfortunately all these tools support only unidirectional data transfer that means these tools can only generate unidirectional traffic on an individual test connection. Trying to simulate the bidirectional loads through the use of two parallel unidirectional test connections doesn’t represent the accurate model of true bidirectional test connections [62].
Table 3.1: Performance measurement tools feature matrix
Feature nuttcp iperf thrulay netperf
TCP X X X X UDP X X X X IPv6 X X X X RTT X - X - IAT X - X - Network Transactions/s - - - X CPU utilization X - - X
third party tests X - - -
interval reports X X X X
scheduling - - - -
control/test interface separated X - - -
bi-directional traffic X X(pseudo) - -
select congestion control X X - -
TCP_INFO X(partial) X(partial) - - -
Rate Limiting - X UDP only X
3.7 Conclusion
3.7 Conclusion
This chapter discuss in details regarding the present performance measurement tools and the comparison regarding their features is shown in the table 3.1. All the tools discussed in this chapter couldn’t generate the realistic internet traffic. This is considered as the one of the disadvantage of these tools. The details regarding the traffic generation is discussed in the next chapter.
4 Traffic Generation model
This chapter gives an overview regarding the stochastic traffic generation in the flowgrind. Additionally this section gives the mathematical model behind the stochastic traffic generation in basic. The section gives the details regarding the traffic model and scenarios generated by traffic generation.
4.1 Introduction to Traffic Generation model
Developing a traffic generation, for example a pragmatic internet is a challenge task. In general there are two primitive methods to generate manifold internet traffic. A basic and easy approach is to record cluster of traffic, and subsequently re-run them. This approach is calledtraffic replay[31]. Another approach to generate pragmatic traffic by using the stochastic process, this method is called as thestochastic traffic generation[47]. Both the methods, has its own advantages and disadvantages, because of their way, in which these approaches are developed. The traffic replay method is more pragmatic, since trace record is the combination of the data streams and the traffic attributes and it reproduces the trace records with the same traffic attributes [31]. Despite the easy implementation of the traffic replay, it has its own demerits because traffic replay considers the trace records as the black box and it is difficult to change the traffic to test different test scenarios [47]. And other demerits of the traffic replay approach are that it requires additional procedure and resources to record the traces, process and store them.
In contrast, the stochastic traffic generation generates the traffic based on the mathematical model for different traffic and workload characteristics. One of the useful features in the stochastic model is that the parameters can be extracted from quantitative analysis. This feature in the stochastic traffic generation compels it to do experiment protocols and evaluate them, before actually doing the implementation work for the protocols [47]. Another disadvantage of the traffic replay method is that difference between the traffic noise and the payload in the trace records requires additional information for boundaries in the data set [47]. The whole trace records are needed to store in traffic replay, but in contrast to it, the stochastic traffic generation, requires to store only the parameter to generate the stochastic traffic generation and random state number. The flowgrind stochastic traffic generation has been discussed in this section 5.8
4 Traffic Generation model