Academia.eduAcademia.edu

Outline

Title
Abstract
Figures
Introduction
Tests and Results
Conclusions
References

WAN Emulator Software Tool

Profile image of Andrei RusAndrei Rus

2016

Abstract

Testing in real life conditions is not as easy as it first seems, because often it is costly and difficult to reproduce Internet behavior in controlled environment. WAN Emulator (WANE) proposed herein is a software tool that helps controlling the IP traffic parameters of a network, like delay, packet loss or packet duplication. The advantage of this software is that is using free tools implemented in Linux kernels but offers a friendly graphical interface, so that the researcher does not have to bother with time consuming operations like creating the tc tree, marking the specific traffic and filtering it.

Figures (13)
iptables is the native packet filtering mechanism for the Linux 2.4 and above kernel series. We can use it to filter packets, implement network address translation and mangle packets. There are three default chains for filtering packets: INPUT, OUTPUT and FORWARD, and two default chains for network address translation: PREROUTING and POSTROUTING, and three tables: filter, nat and mangle. In Figure 2 we can see the chains through which the packets are going, when the iptables service is enabled in Linux kernels. In this paper we used the mangle table in order to mark packets from a specific data flow. The marking rules were set into the PREROUTING chain from the mangle table. We later used this mark in order to identify the flows and apply the desired changes in the network metrics.
iptables is the native packet filtering mechanism for the Linux 2.4 and above kernel series. We can use it to filter packets, implement network address translation and mangle packets. There are three default chains for filtering packets: INPUT, OUTPUT and FORWARD, and two default chains for network address translation: PREROUTING and POSTROUTING, and three tables: filter, nat and mangle. In Figure 2 we can see the chains through which the packets are going, when the iptables service is enabled in Linux kernels. In this paper we used the mangle table in order to mark packets from a specific data flow. The marking rules were set into the PREROUTING chain from the mangle table. We later used this mark in order to identify the flows and apply the desired changes in the network metrics.
The position of Linux queuing disciplines into the TCP/IP stack is shown in to the Figure 3.
The position of Linux queuing disciplines into the TCP/IP stack is shown in to the Figure 3.
As it can be seen in Figure 5, OWAMP is a client-server application. The owping client contacts the owampd daemon on the peer host to request a specific test. This includes a series of traffic test parameters like: transmission rate, packet size in bytes and direction (from server to client or vice- versa).
As it can be seen in Figure 5, OWAMP is a client-server application. The owping client contacts the owampd daemon on the peer host to request a specific test. This includes a series of traffic test parameters like: transmission rate, packet size in bytes and direction (from server to client or vice- versa).
Figure 6. Testbed with Synchronization Kit When measuring the delay between a source and a destination, OWAMP tool writes into the data packets a timestamp and calculates the difference between the time when the packet was received and the time when the packet was sent. This is the reason why the NTP (Network Time Protocol) service must run on both source and destination computers, as their system clocks must be synchronized for meaningful measurement results. In this testbed we used Palisade GPS synchronization kit to synchronize the source and destination computers with the router PC which was the NTP server. The testbed including the synchronization kit can be seen in Figure 6:
Figure 6. Testbed with Synchronization Kit When measuring the delay between a source and a destination, OWAMP tool writes into the data packets a timestamp and calculates the difference between the time when the packet was received and the time when the packet was sent. This is the reason why the NTP (Network Time Protocol) service must run on both source and destination computers, as their system clocks must be synchronized for meaningful measurement results. In this testbed we used Palisade GPS synchronization kit to synchronize the source and destination computers with the router PC which was the NTP server. The testbed including the synchronization kit can be seen in Figure 6:
First, we used the OWAMP tool in order to measured packet delay from a specific source to a destination. Within the first test in WANE we considered a fixed delay of 100 ms, whilst in the second test each packet was delayed randomly within a range of values 180 ms and 220 ms. Test 3 took into consideration the fact that the delay variation (jitter) is not purely random in real networks. So we specified a correlation between two consecutive values. This represented how much of the current delay applied to the packet depended on the previous one. This correlation is described analytically in the following equation: 4. Tests And Results
First, we used the OWAMP tool in order to measured packet delay from a specific source to a destination. Within the first test in WANE we considered a fixed delay of 100 ms, whilst in the second test each packet was delayed randomly within a range of values 180 ms and 220 ms. Test 3 took into consideration the fact that the delay variation (jitter) is not purely random in real networks. So we specified a correlation between two consecutive values. This represented how much of the current delay applied to the packet depended on the previous one. This correlation is described analytically in the following equation: 4. Tests And Results
where Delay, refers to the current packet and Delay,.; to the previous packet. Corr is the correlation and RandDelay is a random delay value. Within the third test the delay was in the range 280 ms up to 320 ms, with a correlation of 80%. Finally, the fourth test took the delay between 380 ms and 420 ms, with a normal distribution. Note that the normal distribution, also known as Gaussian, is a family of continuous probability distributions, defined by two parameters: the mean ("average") ,u and the variance ("variability") 0°, respectively. WANE implemented a mean of zero and a variance of one (the ereen curve in Figure 8). Figure 8. Normal (Gaussian) distribution
where Delay, refers to the current packet and Delay,.; to the previous packet. Corr is the correlation and RandDelay is a random delay value. Within the third test the delay was in the range 280 ms up to 320 ms, with a correlation of 80%. Finally, the fourth test took the delay between 380 ms and 420 ms, with a normal distribution. Note that the normal distribution, also known as Gaussian, is a family of continuous probability distributions, defined by two parameters: the mean ("average") ,u and the variance ("variability") 0°, respectively. WANE implemented a mean of zero and a variance of one (the ereen curve in Figure 8). Figure 8. Normal (Gaussian) distribution
Figure 9. Normal distribution implemented by WANE The density of probability function for the normal distribution is given by the equation:
Figure 9. Normal distribution implemented by WANE The density of probability function for the normal distribution is given by the equation:
for all x > Xm, where x,, is the minimum possible value of x (necessarily positive) and k represents a positive parameter.
for all x > Xm, where x,, is the minimum possible value of x (necessarily positive) and k represents a positive parameter.
The second group of experiments was devoted to check how accurate WANE can emulate packet dropping. Before doing a measurement we configured the emulator to discard a specific percentage of packets. For each set we performed three tests, taking the average as a final result. We also repeated the tests to see if the performance is the same if we vary the throughput. Observe from Table | that the difference between imposed values of dropped packets and the measured ones was less than 1%. This performance is good enough for emulating a certain connection as in a real network. The same procedure was applied for duplicate packets, the results being presented in the Table 2. Again the WANE emulation errors were less than 1%. Table 1. Packets dropped
The second group of experiments was devoted to check how accurate WANE can emulate packet dropping. Before doing a measurement we configured the emulator to discard a specific percentage of packets. For each set we performed three tests, taking the average as a final result. We also repeated the tests to see if the performance is the same if we vary the throughput. Observe from Table | that the difference between imposed values of dropped packets and the measured ones was less than 1%. This performance is good enough for emulating a certain connection as in a real network. The same procedure was applied for duplicate packets, the results being presented in the Table 2. Again the WANE emulation errors were less than 1%. Table 1. Packets dropped
NetEm implements a specific discipline by taking a table to specify the distribution. The actual tables (normal, Pareto) are generated as part of the tc compilation and placed in /usr/1ib/tc on the Linux machine. With additional effort it is even possible to make your own distribution based on experimental data and to store it in the same location as for the others [4]. According to Figure 11, WANE can successfully emulate delays that have a Pareto distribution.
NetEm implements a specific discipline by taking a table to specify the distribution. The actual tables (normal, Pareto) are generated as part of the tc compilation and placed in /usr/1ib/tc on the Linux machine. With additional effort it is even possible to make your own distribution based on experimental data and to store it in the same location as for the others [4]. According to Figure 11, WANE can successfully emulate delays that have a Pareto distribution.
Table 2. Duplicate packets
Table 2. Duplicate packets
Next we investigated the maximum transfer rate using a tool called NetPerf [5]. Thus we started from 10 kbps up to 100 Mbps. For each maximum rate imposed by WANE several tests were performed, the average throughput been presented in the Table 3. Observe that in this case the emulation error was less than 5%. There are several reasons for this. First is the fact that the measuring tool worked at the Application Layer and it did not count the headers added to the packets. Moreover TCP automatically adjusted the transmission window, usually underestimating the available throughput. The formula for the error value was the following:
Next we investigated the maximum transfer rate using a tool called NetPerf [5]. Thus we started from 10 kbps up to 100 Mbps. For each maximum rate imposed by WANE several tests were performed, the average throughput been presented in the Table 3. Observe that in this case the emulation error was less than 5%. There are several reasons for this. First is the fact that the measuring tool worked at the Application Layer and it did not count the headers added to the packets. Moreover TCP automatically adjusted the transmission window, usually underestimating the available throughput. The formula for the error value was the following:

References (7)

  1. ***, http://www.ccaba.upc.edu/netmeter
  2. MA.Brown, Traffic Control HOWTO, http://linux-ip.net/articles/Traffic-Control-HOWTO/classful-qdiscs.html, 2006
  3. ***,http://linux-net.osdl.org/index.php/Netem
  4. ***,http://www.netperf.org/netperf/training/Netperf.html
  5. S.Hemminger, Network Emulation with NetEm, 2005
  6. J.Boxman, A Practical Guide to Linux Traffic Control, Chapter 6.3 Using the Netfilter MARK Target, http://trekweb.com/~jasonb/articles/traffic_shaping/ classlows.html
  7. B.Hubert, Linux Advanced Routing & Traffic Control HOWTO, http://lartc.org/howto/
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved