Honours Year Project Report
Honours Year Project Report
Tools for Performance Measurement
of
TwinGlass, an IPv4 to IPv6 Transition Mechanism
By
Lee Weng Hong
Department of Computer Science
School of Computing
NationalUniversity of Singapore
2005/2006
Honours Year Project Report
Tools for Performance Measurement
of
TwinGlass, an IPv4 to IPv6 Transition Mechanism
By
Lee Weng Hong
Department of Computer Science
School of Computing
NationalUniversity of Singapore
2005 / 2006
Project No: H078480
Advisor: Dr. A.L.Ananda
Deliverables:
Report: 1 Volume
Abstract
At the Communication & Internet Research Lab, we have developed an IPv4-IPv6 transition mechanism calledTwinGlass. Enhancement on TwinGlass is currently being carried out, and regular testing is required to evaluate the effects of ongoing added enhancement.
In this project, we developed an efficient, realistic, robust, and rigorous automatablenetwork traffic generator, TrafWatch, to adequately test TwinGlass performance. TrafWatch is capable of producingcustomizable traffics at packet level accurately replicating appropriate stochastic processes for traffic patterns, including TCP, UDP, ICMP, VoIP, Telnet, and DNS. It is multithreaded and capable of generating both single and multiple flow streams, and generateseasily interpretable and detailed logs with metrics of throughput, jitters, packet delays, packet losses. The logs generated are suitable for easy graph generation in most graphing programs.
The capability of TrafWatch as a performance analysis tool is not limited to testing on TwinGlass, and can be extended to testing on all other wired and wireless networking projects in our Center for Internet Research Lab. It has a user-friendly GUI and is a very efficient and useful tool for performing fast and repetitive network testing.
Subject descriptors:
C. 2.2. Network Protocols
C.4. Performance of Systems
D.2.5 Testing and Debugging
D.2.8 Metrics
Keyword:
Network Traffic Generator, NetworkTraffic Models, Network Performance Evaluation,Performance Metrics, performance analysis tools
Implementation Software and Hardware:
Tcl/Tk, WinXP, Linux Fedora Core, C Programming, and CIRLTestbed
Acknowledgement
Many thanksto Prof A.L.Ananda for his guidance for this project over the past year.Without his vision and support, this project would not have been complete.
I would like tothank Mr. Xu Chu for hishelp in guiding me for the completion of this project, and I am thankful to him for spending his precious time in guiding me on how to write a good report.
I would like to thank Universita' degli Studi di Napoli ''Federico II'' (Italy) Dipartimento di Informatica e Sistemistica for allowing me to work on their existing codes for Distributed-ITG.
Finally, I would like to thank all the members of Communication & Internet Research Lab,who provided me such a favorable work environment. All the food snacks you left on my work desk add daily joys to my heart.
Tables of Contents
Title i
Abstract ii
Acknowledgement iii
List of Figures vi
List of Tables vii
1Introduction......
1.1Current Problem
1.2Objective
1.3Report Organization
2Background......
2.1Basic ideas
2.1.1Protocol Topologies......
2.1.2Data Generation Patterns......
2.1.3Metrics......
2.2Available implementations
2.2.1Ttcp......
2.2.2Iperf......
2.2.3Surge......
2.2.4Apache Benchmark (AB)......
2.2.5TCPLIB......
2.2.6TG2......
2.2.7NetPerf......
2.2.8NetSpec......
2.2.9MGEN......
2.2.10Rude/Crude......
2.2.11UDPgen......
2.2.12Traffic......
2.2.13PacGen......
2.2.14Distributed Integrated Traffic Generator (D-ITG)......
3System Design......
3.1System Design
3.2The Sender Process
3.2.1Setting up connection......
3.2.2Generating customized data traffic......
3.2.3Encapsulating information for statistics collection......
3.3The Receiver Process......
3.3.1Setting up connection......
3.3.2Receiving data traffic and recording logging statistics......
3.4User Interface automation and simplification......
3.4.1Flow Definition......
3.4.2Batch Tests......
3.4.3Read Logs......
3.4.4Decipher Graphs......
3.5Typical Test Scenario......
3.5.1Flow Settings......
3.5.2The Test Process......
3.5.3Test Logs......
3.5.4Delay Analysis......
4Implementation......
4.1The Sender Process......
4.1.1Setting up connection......
4.1.2Generating Customized data traffic......
4.1.3Encapsulating information for statistic collection (Logging)......
4.2The Receiver Process......
4.2.1Setting up connection......
4.2.2Receiving data traffic and recording logging statistics......
4.3Logging......
4.4User Interface implementation......
4.4.1Flow Definition......
4.4.2Batch tests......
4.4.3Read Logs......
5Test Suites......
5.1Raw Throughput......
5.2Bulk Traffic......
5.3Interactive Traffic......
5.4Web Traffic......
5.5Voice Traffic......
5.6Broadband Traffic......
6Conclusion & Future Work......
6.1Conclusion......
6.2Future Work......
Bibliography......
List of Figures
Figure 21 – OSI Layers
Figure 31 System Design of TrafWatch
Figure 32 Flow Definition
Figure 33 Graph of Instantaneous values of Delay
Figure 41 Sender TSP State Diagram
Figure 42 Receiver TSP State Diagram
Figure 43 Sequence Diagram of TSP
Figure 44 User interface usage flow diagram
Figure 45 Creating Flow Settings Window
Figure 46 Consecutive Flows Window
Figure 47 Simultaneous Flows Window
Figure 48 Read Logs Window
Figure 51 Voice Codecs and their properties
Figure 52 Generated data from pareto distribution
List of Tables
Table 21 Traffic Generated by Different Software Traffic Generators
Table 31 Settings for throughput testing
Table 32 Results of throughput testing
Table 33 Instantaneous values of Delay
1
1Introduction
At the Communication & Internet Research Lab (CIRL), we have developed an IPv6-IPv4 transition mechanism calledTwinGlass, which provides transparent communication between hosts in IPv6 network and hosts in IPv4 network. Based on assigning TwinGlass-allocatedIPv6 addresses and dynamic tunneling, seamless communication between different hosts across organization IPv6 backbone has been achieved. This will help the initial transition from IPv4 to IPv6. ATwinGlass gateway is placed at the boundary between the two different types of networks, which serves like the tunnel entry / end point and forwards the encapsulated / de-capsulated packets.
TwinGlass currently employs two solutions:
(i) The static TwinGlass solution; and
(ii) The dynamic solution.
The static solution is based on dynamic tunneling, where the TwinGlass-allocated IP-addresses are used as the tunnel entry / exit points. Dynamic Tunnels can be created dynamically between any 2 distinct TwinGlass boxes, where packet encapsulation / decapsulation are involved.
The dynamic TwinGlasssolution is an enhancement of the static solution, where message propagation is used to realize more flexible & reliable control. Instead of statically allocating IPv4 subnets, a special type of message is propagated based on a special OSPFv6LSA among all TwinGlass boxes, which makes it possible for every TwinGlass box to know the current status of all the others in a timely manner.
Ongoing enhancements to the TwinGlass system include:
(i)DHCP Address Assignment: The TwinGlass boxes is properly configured to make all the DHCP services available to the network.
(ii)NAT Compatibility: The transition gateway handover mechanism retains existent network connections and hence guarantees there will be no double mapping for a single private address among gateways, and NAT can safely be done. The NAT function has to be enabled in TwinGlass’ OS.
(iii)NAT-PT: NAT-PT is used for IPv4-IPv6 communication, for IPv4 clients outside the IPv6 backbone to access IPv6 server within the IPv6 backbone, and for IPv6 clients within the IPv6 backbone to access IPv4 server outside the IPv6 backbone. KAME's NAT-PT implementation for FreeBSD 4.10 snapshot is used to achieve this.
(iv)IPSec: The two hosts must be configured to use IKE (Internet Key Exchange), which is a protocol to allow IPSec to exchange its encryption keys securely and automatically. The psk.txt file under the /usr/local/etc/raccoon/ directory must also be properly configured for raccoon to setup its initial connection.
1.1Current Problem
Testing on our TwinGlass system has been done thoroughly on the functional aspect, but little testing has been done on the performance aspect. As the TwinGlass technology has matured significantly enough to approach mainstream deployment, hardware boxes for TwinGlass is prototyped for product testing.We need to properly characterize scalability in order to understand the impact of the TwinGlass deployment on existing networks and to prevent bottlenecks. Since tunneling is a key technology component used in TwinGlass, the scalability and performance of TwinGlass depends on the number of tunnels TwinGlass can simultaneously handle (encapsulate/de-capsule incoming/outgoing data packets) – this metric must be monitored and measured closely in performance testing.
The processes of tunneling and encapsulation (with respective decapsulation) prevalent in TwinGlass technology may have significant effects on the performance of packets delivery, as it adds multiple levels of complexity into the network layer.
In essence, rigorous and thorough performance measurement experiments must be carried out on an experimental network with the TwinGlass implementation and on another experimental network without the TwinGlass implementation, to efficiently and accurately measure performance metrics such as throughput, delay, jitters and packet losses, in order for us to deduce the performance variations on a network due to the addition of TwinGlass capability.
The experiments should not only reflect thewide scale of real scenarios, but also the rich variety of traffic sources, in terms of both data generation patterns and protocol typologies. Traffic models implemented should accurately and realistically represent relevant statistical properties of real data flow. However, no one traffic generator available in the free academic market suffices in modeling the necessary traffic sources required for a complete array of experimental scenarios.
This is the problem addressed by our project. We need to create a flexible and versatile network traffic generator capable of modeling different types of traffic sources, to finally build up a test suite adequate enough to simulate most (if not all) of the realistic traffics in a network. This will allow us to efficiently carry out performance testing on not just our TwinGlass technology, but also our other emerging network technologies in CIRL.
1.2Objective
Following are the objectives of this project:
- develop an efficient, realistic, robust, and rigorous automatable network traffic generation system, TrafWatch, to adequately test TwinGlass performance. It should be capable of
(i)Producingcustomizable traffics at packet level accurately replicating appropriate stochastic processes for traffic patterns, including (but not limited to) TCP, UDP, ICMP, VoIP, Telnet, FTP, and DNS.
(ii)Simulating traffics based on inter-departure times and packet sizes, choosing from realistic and relevant distributions such as constant, uniform, normal, Cauchy, pareto, and exponential distribution.
(iii)Generating both single and multiple flow-streamsto simulate multiple connections between senders and receivers, thus testing for scalability on the network system.
(iv)Measuring Quality of Service (QoS) parameters, including throughput, jitters, packet delay, and packet losses for traffic generated, producing results in time intervals and averages.
(v)Saving of generation parameters for repetitive and repeated testing.
(vi)Having a user-friendly graphical user interface for user access.
- Using the designed TrafWatch system, design test scripts to build up a test suite adequate enough to simulate most (if not all) of the realistic traffics in a network, allowing thorough testing to be done repetitively on the TwinGlass system.
1.3Report Organization
The rest of this report is organized as follows. Chapter 2 discussesthe related work in the Traffic Generator area, where severalexisting implementations will be discussed. Chapter 3 describesthe system design ofTrafW atch systemand describessome typical traffic scenarios. Chapter 4 gives implementation details, consisting of both the logical design and implementation details for WinXP. Finally, we present our conclusions and discuss future workin chapter 5.
2Background
Several works have addressed the issue of network traffic generation and analysis, and a number ofsoftware implementations are available freely for network testing. In this chapter,we will present some of the desired properties of a network traffic generator, and list the freely available traffic generators.
2.1Basic ideas
The ideal traffic generator must simulate, to very detailed levels, the exact character of network traffic in the specific network. The implication that different networks may have very different network traffic characteristics requires traffic generators to be versatile and customizable in terms of traffic patterns and profiles. For example, data traffic in an office network may consist largely of TCP packets spread out uniformly in both packet sizes and time intervals; whereas data traffic in a network with a radio streaming server may consist largely of UDP packets spread out in a constant distribution in both packet sizes and time intervals.
As storing complete tracesof every possible network is impossible in a traffic generator, network simulation research has largely focused on deriving analytical and rigorous traffic models which accuratelyrepresent relevant statistical properties of the original traffic. This process includes the study of traffic patterns and properties. Researchershave been looking for the definition of stochastic processes (that could be used as accurate and simple models) for traffic generation in packet switched networks, and, in particular, in IP networks.
In terms of performance analysis experiments conducted with a traffic generator, they should demonstrate the wide vector of traffic sources and the wider array of actual scenarios in terms of protocol topologies and data generation patterns.
The performance analysis experiments must also test for metricscritical to determine the actual performance of the network. Some of these metrics include throughput, jitters, delay, and packet losses.
2.1.1Protocol Topologies
Data traffic can come from different layers of the protocol topology. For example, UDP and TCP packets are generated at the Transport Layer of the OSI layers; ICMP is generated at the Network Layer; FTP, DNS, HTTP, and VoIP are generated at the Application Layer.
By defining protocol topology in traffic generation, a traffic generator can reproduce the “traffic profile” according to theoretical stochastic models.
Figure 21 – OSI Layers
2.1.2Data Generation Patterns
Two distinct and different variables under data generation patterns are inter-departure time and size. Inter-departure time refers to the time intervals between which data packets are sent out. Size refers to the size of data packets sent out. By customizing these two variables according to known mathematical distributions reflective of existing traffic models, realistic traffic patterns can be generated by the traffic generator for performance analysis experiments. For example, VoIP traffic follows the pareto-distribution in inter-departure time, and the uniform distribution in packet size, and can be simulated by setting these two variables as such.
2.1.3Metrics
Some of thestandard metrics useful for measuring network performance, as defined by IETF (IETF, 2006), are:
(i)Throughput;
(ii)Packet delay;
(iii)Jitters; and
(iv)Packet loss.
Throughput refers to the measurement of the channel capacity of a communications link, often in the units of bits per second.
Delay is the amount of time that a packet takes to travel from the sending applicationto reach the receiving application. For example, in an InternetTelephony scenario, one-way delay requirement is stringent for VoIP to maintaingood interaction between end-nodes.
Jitter is the variation in delay of the packets arriving at the receiving end. It canbe considered as the standard deviation and it might be caused by congestion,insufficient bandwidth, varying packet sizes in the network, out of order packets.
Packet loss is a measure of packets discarded deliberately or non-deliberatelyby intermediate links, nodes and end-systems along a given transmission pathbetween sender and receiver.
As these values changes throughout the lifespan of a network connection, it is often useful to generate their instantaneous values that in-depth analysis can be done to determine their fluctuation pattern and thus seek to resolve on their limiting factors.
2.2Available implementations
We seek to describe the software and hardware traffic generators available and list down their features here.
2.2.1Ttcp
Ttcp is able to generate TCP and UDP bulk traffic streams. It operates using a client / server mechanism. Ttcp shows the throughput of the connection on both the client and server sides, but it displays only the overall average throughput of transmission
2.2.2Iperf
Like ttcp, iperf also uses the client / server paradigm with the same program being able to act as both the client and the server. However iperf can display instantaneous throughput values at intervals specified by the user, and has support to display jitter calculations for UDP transfers. This feature is very useful for experiments involving multimedia traffic, as jitter is one of the metric that are usually required to be measured.
2.2.3Surge
Surge is a series of tools which attempts to realistically model HTTP requests. It consists of many tools which provide as their end product a script containing the access patterns to a set of files. This script will be created based on a number of parameters supplied by the user such as the arrival rate of HTTP requests, the size distribution of files requested etc. Surge will create all the necessary data files being accessed by the script. The user has to then transfer those files onto a real web server. Surge provides a network client which will read the script containing the access patterns. The client will then access the files on the web server based on the information in the script. Surge is thus very accurate in modeling HTTP traffic as it uses a real web server to respond to HTTP requests. Surge can also model HTTP 1.0 and HTTP 1.1 requests and access patterns.
2.2.4Apache Benchmark (AB)
AB is supplied together with the Apache web server. This benchmark generates HTTP traffic only and is used to stress test Apache web servers.
2.2.5TCPLIB
TCPLIB is a set of library functions based on actual network measurements. It is very accurate for simulating the classes of traffic it models, but the measurements were taken before the advent of the World Wide Web (WWW) and hence it may not accurately reflect the traffic distributions found on modern day networks.
2.2.6TG2
TG2 uses the TCPLIB functions and distributions to generate traffic and thus serves as a front end to the TCPLIB library. TG2 can simulate voice and video UDP streams but the distribution is not very accurate. TG2is capable to generate constant, uniform, exponential on/off, UDP, or TCP traffic.
2.2.7NetPerf
NETPERF can be used to measure the performance of TCP and UDP bulk streams.
2.2.8NetSpec
NETSPECis a traffic generator/emulator that allows the user to define multiple traffic flows from/to multiple computers. It is capable of emulating TCP, UDP, WWW, FTP, MPEG, VBR and CBR traffic.
2.2.9MGEN
MGEN is both a command line and GUI traffic generator. MGEN provides programs forsourcing/sinking real-time multicast/unicast UDP/IP traffic flows. The MGEN tools transmit and receive time-stamped, sequence numbered packets. The analysis of the log files can be performed to assess network or network component ability to support the given traffic load in terms of packet loss, delay, jitter, etc.