Master Thesis
Electrical Engineering March 2012
School of Computing
Blekinge Institute of Technology
On the use of pattern-based shaping for
emulating delay characteristics of mobile
channels
Ajay Surapaneni
Ramachandran Chakravadhanula
This thesis is submitted to the School of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering. The thesis is equivalent to 20 weeks of full time studies.
Contact Information:
Authors:
Ajay Surapaneni
Address: Polhemsgatan 28B, Karlskrona, Sweden.
E-mail: ajay05461@gmail.com Ramachandran Chakravadhanula
Address: Polhemsgatan 28B, Karlskrona, Sweden.
E-mail: ramachandran_492@yahoo.co.in
University advisor:
Markus Fiedler School of Computing
University Examiner:
Patrik Arlos
School of Computing
A BSTRACT
Trace based emulation is an approach that creates a synthetic network environment from observing network parameters. This approach is extensively useful for testing applications or protocols which are to be deployed in real networks. Repeatability and ease of debugging in a controlled environment are the important characteristics for successful testing, where applications/protocols are completely abstract to this synthetic network. Network emulation is an effective way to achieve it. KauNet is one such network emulator that makes use of pattern based shaping for deterministic emulations. Patterns are simple offline files that contain data sets in steps that indicate at which point the emulation should take place. Thus, patterns generated from mobile network traces are inserted in emulator to mimic the original network behavior. This work focused on reproducing original traffic traces using pattern based approach, thus imitating a target network. Also pattern sizes are simplified and its consequences are studied. In achieving it, results show that it is possible to effectively reproduce real network and simplification of patterns can be made at the expense of some accuracy.
Keywords: Trace-based emulation, KauNet, Pattern simplification, One-way-delay.
A CKNOWLEDGEMENTS
First and Foremost, we would like to express our sincere gratitude to our supervisor Docent Markus Fiedler. His constant support, guidance and patience at every moment in our work is outstanding. Our deep appreciation for sharing his ideas and insights, in making this work successful.
Furthermore, we would like to thank Tahir Minhas Nawaz for his valuable suggestions and encouraging us at every moment. Our numerous scientific discussions helped us in fetching knowledge and guided the right trajectory.
We would like to extend our special gratitude to Dr. Patrik Arlos for supporting us.
Also, we are thankful to Ravichandra Kommalapti, for helping us in laboratory and for answering our querys with at most patience.
Finally, we would like to thank our parents and all our friends in Sweden, who supported us during our studies.
Ajay and Ramachandran, Karlskrona.
C ONTENTS
ABSTRACT ... I ACKNOWLEDGEMENTS ... II CONTENTS ... III
1 INTRODUCTION ... 2
1.2 MOTIVATION ... 3
1.3RESEARCH QUESTIONS ... 3
1.4RESEARCH METHODOLOGY ... 4
1.5ORGANIZATION OF THESIS ... 4
2 RELATED WORK ... 5
3 KAUNET OVERVIEW ... 7
3.1IPFW ... 7
3.2PIPES AND QUEUES ... 8
3.3PATTERN AND SCENARIO FILES ... 8
3.4KAUNET MODES OF OPERATION ... 9
3.5PATTERN GENERATION ... 10
3.5.1 Patt_gen: ... 10
3.5.2 Pg_gui:... 10
4 EXPERIMENTATION ... 11
4.1SETUP DESIGN ... 11
4.2HARDWARE CONFIGURATIONS OF THE EQUIPMENTS ... 12
4.3EQUIPMENT FUNCTIONALITIES ... 12
4.3.1 Measurement Point ... 12
4.3.2 MArC ... 12
4.3.3 Consumer ... 12
4.4EMULATION SETUP CONFIGURATION ... 12
4.5PATTERN AND SCENARIO GENERATION ... 14
4.5.1 Delay change pattern generation... 14
4.5.2 Packet loss pattern generation ... 16
4.5.3 Bandwidth change pattern generation ... 18
4.5.4 Scenario file generation ... 19
4.6KAUNET CONFIGURATION ... 20
4.6.1 Packet filtering configuration ... 20
4.6.2 Pipe configuration ... 20
4.7MEASUREMENT POINT AND CONSUMER CONFIGURATION ... 21
4.8EXPERIMENTATION PROCEDURE ... 21
5 RESULTS ... 22
5.1REPRODUCING ONE WAY DELAY CHARACTERISTICS ... 22
5.2SHAPING ONE WAY DELAY AND PACKET LOSSES ... 25
5.2.1 Using Scenario files ... 25
5.2.2 Using multiple pipes ... 26
5.2.3 Emulated Effects implementation in multiple pipes first case ... 28
5.2.4 Emulated Effects implementation in multiple pipes second case ... 30
5.2.5 Emulated Effects implementation in Scenario files case ... 31
5.3USING SIMPLIFIED PATTERNS WITH THRESHOLD LEVEL... 31
5.3.1 Statistics with peak values ... 34
5.3.2 Statistics without peak values ... 34
5.4IMPACT ON PATTERN SIZE AFTER SIMPLIFICATION OF ORIGINAL TRACE ... 36
5.5COMPARISON OF TIME DRIVEN MODE AND DATA DRIVEN MODE ... 37
5.6EMULATING AN IDEAL MOBILE CHANNEL WITH KAUNET ... 37
6 CONCLUSION AND OUTLOOK ... 39
6.1 ANSWERS TO RESEARCH QUESTIONS ... 39
6.2 FUTURE WORK ... 40
BIBILOGRAPHY ... 41
A APPENDIX ... 43
A.1KAUNET INSTALLATION ON LINUX MACHINE (KUBUNTU 11.04) ... 43
A.2 REAL NETWORK TRACE FILE ... 43
A.3ANALYSIS OF CAPTURE FILES ... 45
A.4DELAY CHANGE PATTERN... 46
A.5PATTERN GENERATION IN TIME DRIVEN MODE ... 46
A.5.1 Packet loss pattern ... 46
A.5.2 Delay Pattern ... 46
A.5.3 Pattern generation in time driven mode using text files ... 47
A.6SIMPLIFICATION OF PATTERN FILES USING A THRESHOLD LEVEL ... 47
A.7SELECTING THRESHOLD VALUES FROM CCDF GRAPH ... 50
A.8PATTERN SIZES AND INFORMATION ... 50
LIST OF TABLES
Table 3-1 Types of Patterns and their operations ... 9
Table 3-2 KauNet modes of operation... 10
Table 4-1 Hardware equipment configurations ... 12
Table 5-1 Showing the statistics for original and synthetic traces. ... 23
Table 5-2 Showing the correlation coefficients for different traces. ... 25
Table 5-3 Comparison between multiple pipes and scenario trace files ... 28
Table 5-4 Statistics for threshold values considering Starting peaks in OWD. ... 34
Table 5-5 Statistics for Threshold values without considering starting peaks in OWD ... 34
Table 5-6 S Showing relative pattern sizes for corresponding threshold values of different traces. ... 36
Table 5-7 Comparing statistics in Time driven mode and Data driven mode ... 37
Table A-1 Real Traffic trace file format ... 44
Table A-2 showing original trace and Simplified trace with threshold 109ms. ... 49
LIST OF FIGURES
Figure 4-1 Experimental setup design ... 11
Figure 4-2 Delay change pattern generation using pg_gui ... 15
Figure 4-3 Graph representing plot of packet sequence numbers vs delay changes ... 15
Figure 4-4 Packet loss pattern generation using pg_gui ... 17
Figure 4-5 Graph representing packet sequence numbers versus packets that are to be lost . 17 Figure 4-6 Bandwidth pattern generation using pg_gui ... 18
Figure 4-7 Graph representing the plot of kernel ticks vs emulated bandwidth... 19
Figure 5-1 Graph representing Packet sequence number versus Delay ... 22
Figure 5-2 representing packet sequence number versus relative error ... 23
Figure 5-3 Representing relative error for the number of packets. ... 24
Figure 5-4 Complementary cumulative distribution functions of one way delay for synthetic trace and original trace. ... 24
Figure 5-5 Packet sequence number versus delay changes using scenario file ... 25
Figure 5-6 Complementary cumulative distribution of delay change ... 26
Figure 5-7 Packet sequence number versus delay obtained in first case ... 26
Figure 5-8 Complimentary cumulative distribution function of delay changes obtained in first case ... 27
Figure 5-9 Packet sequence number versus delay change in the second case ... 27
Figure 5-10 Complementary cumulative distribution function of delay change in 2nd case . 27 Figure 5-11 representing the flow of traffic through pipes [5]... 29
Figure 5-12 Comparison between OWD values of original and synthetic trace at 96 ms Threshold ... 31
Figure 5-13 OWD comparison graph of synthetic trace and original trace at threshold value 109 ms ... 32
Figure 5-14 OWD comparison graph of synthetic trace for threshold value 180 ms and original trace ... 32 Figure 5-15 OWD comparison graph for synthetic trace of threshold value 250 ms and
Figure 5-17 CCDF comparison for the threshold values of Trace1 ... 35 Figure 5-18 CCDF comparison values for threshold values of Trace 2 ... 35 Figure 5-19 CCDF comparison values for threshold values of Trace 3 ... 36 Figure 5-20 Illustration of the approximation of on-off behavior in terms of inter packet
arrival times. ... 38 Figure A-1 Trace file Analysis ... 45 Figure A-2 CCDF graphs of the original trace file for identification of the knee point. ... 50
1 I NTRODUCTION
With the evolution of various wireless technologies there has been a tremendous impact on the internet communications. As they provide high degree of convenience, flexibility and mobility to the user. In parallel, there is huge demand on mobile communication due to high data rates they provide. On contemporary, communications traffic can be assorted into Non-real-time and Real-time traffic.
Conventional traffic like E-Mails, textual data transfer, still images etc., are connoted as non-real-time traffic and are only sensitive to packet losses. Transmission of multimedia content over the network can be reckoned as real-time traffic and is going to dominate the future wireless communications [19]. Statistical results indicate that present Internet traffic holds about 30% of multimedia content and may increase enormously in coming days [20]. The combination of various types of media content like still images, video, audio, animation, text and interactivity form a multimedia. The list of multimedia applications includes IPTV, video conferencing, VoIP, video streaming, video broadcasting etc. RTP, UDP, TCP and RTSP are widely used protocols which run on top of IP Networks for streaming of visual media over the Internet. Among those UDP is the conventional transport layer protocol used for multimedia streaming. UDP is preferred for streaming services because of no retransmissions and data rate management services, that makes it suitable for fast transmission of real-time audio and video [21].
Real time data traffic is very much sensitive to losses, delays and bandwidth limitations. When a new protocol or application that is related to multimedia is proposed or introduced it is required to test its behavior, and to evaluate it with varying network conditions. By doing this their network resource requirements can be understood [2]. There are three ways to test a protocol or application. The first way is to evaluate it using real networks. The advantage with real networks is high degree of realism, but suffers with the problem of repeatability. Because of the dynamic nature of the real networks it is not possible to reproduce the same network behavior as many times as needed. Repeatability ensures efficient statistical results and optimal conditions [18]. The drawback of using real networks can be overcome by using simulation. Repeatability can be achieved by using simulation, but has a drawback in the need to develop models for applications, traffic and protocols. For closed source applications, development of these models is almost impossible. The validation of models is difficult in case of simulation [3]. Repeatability, accuracy, dynamicity and realism are the key issues required to study the impact of protocols/applications on network behavior [18]. These issues can be satisfied with the help of a network emulator.
A network emulator is a hybrid combination of real networks and simulations. It is a software application running on a computer or a dedicated device, which is capable of accurately repeating network behavior in a controlled way [5]. The purpose of network emulation is to imitate a specific network by imposing conditions to the ongoing traffic [18]. Performance evaluation of application/protocols can be done in an established controlled artificial network environment. An efficient network emulator should be open to test all types of protocols.
KauNet is a network emulator that is capable of introducing artificial perturbations like delay, packet loss, bandwidth restrictions, packet reordering and bit errors on the incoming and outgoing traffic that passes through it. It is a pattern-based shaper that mimics the real network behavior based on the patterns that are created from the
protocols or applications to determine their sensitivity towards varying network conditions [2], [3], [5], [13].
Due to increasing network services, design of a reliable and robust network is challenging task. So, a comprehensive study on traffic characterization is needed. For queuing analysis, a link that has state transitions from high regime to low and vice versa is considered.
This report presents the pattern handling capabilities of KauNet and investigates the trace-based modulation technique using pattern based approach. It is extremely important to evaluate the applications/protocols before deploying them in to real world. Moreover, a repeatable approach to test applications/protocols is difficult [7] as real networks are dynamic in nature. KauNet’s pattern based approach provides emulation in a repeatable manner [3]. Thus, exploring KauNet capabilities in mirroring an original network scenario is important.
Memory is a constraint when performing emulations using long traces. As KauNet network emulation revolves around data files called patterns, simplification of patterns and its ability in maintaining close accuracy with original patterns is an essential study.
Also, experiments with KauNet capabilities in modeling the state transitions between ON and OFF conditions are performed.
1.2 Motivation
If untested applications are deployed directly, there is a high probability that deployed application may not reach the expectations of the users. Due to this, users may switch to other service providers in search of better quality. Service provider will be at risk due to the reduced customer base. As a preventive measure it is better to test all the applications before deployment. Testing of application/protocol also point out the flaws when exposed to varying network conditions. In this scenario, network emulation is useful for ease of debugging.
Trace-based emulation is a technique where a target network can be emulated based on available previous traces of the network. Thus, a synthetic network condition is created, where applications to be tested are completely unaware to the emulated scenario [7]. Research works using this approach are described in chapter 2. Traces used in this work correspond to mobile networks that determine the behavioral characteristics of mobile channel.
Most of the emulators discussed in chapter 2 cannot fulfill the reproducibility and repeatability criteria for emulated experiments. KauNet is one such emulator that uses a pattern-based approach for mitigating these issues. Patterns give a fine control over the packet on the basis of per-packet or per-millisecond. However, it is interesting to know, how long traces can be emulated and which precision the emulation yields using a trace driven modulation and pattern based approach. While performing experiments using a real network trace files, memory management plays a key role. As patterns are heart of emulation, they are simplified to save memory, leading to reduced number of look-ups. As a result overhead can be decreased caused due to bulky original patterns generated from original traces. There by keeping patterns simple and short.
1.3 Research Questions
Based on the motivation described, the following research questions are formulated.
1. How can we reproduce original traces using the trace-based emulation?
2. How patterns be simplified and what are the consequences?
3. To which extent is KauNet capable in emulating an ideal channel with on-off characteristics?
1.4 Research Methodology
In order to find answers to the Research questions, an experimental test bed consisting of traffic generator, KauNet emulator and receiver was designed. Traffic generated from source machine is pumped to destination via the emulator machine. Set of traces which are collected ahead of time are used to generate real traffic trace patterns. Thus, by inserting the patterns in KauNet shaper and synthetic traces are collected. A comparison between original trace and synthetic trace gives the amount of error.
To answer second research question, pattern file is simplified based on the modeling of raising delays and delays above the threshold values in the original traces and experiments are repeated. The obtained results are analyzed to see the effect of simplified patterns in terms of error.
To answer the final research question, bandwidth pattern is to be created in the time- driven mode to suddenly drop the throughput of the mobile channel state to zero and release the state after some time. KauNet’s ability to perform such action is observed.
1.5 Organization of Thesis
Chapter 1 provides introduction to thesis work, with an overview about importance of patterns and its usage. Chapter 2 provides related work on trace-based emulation and research related to this thesis work. In chapter 3, the KauNet emulator is described. Further, the generation of patterns and its usage is described. Chapter 4 provides the details about experimentation part. Discussions about the obtained results are presented in chapter 5. Conclusion and future work are given in Chapter 6.
Additional information regarding the thesis is placed in Appendix.
2 R ELATED W ORK
There are many research papers focusing on trace based emulation and its importance. This section provides information on the shapers. Further, interesting work on trace based emulation is provided.
NIST Net [15] is used widely in academic and research laboratories for testing multimedia, mobile network and interactive gaming applications. NIST Net is a Linux based kernel emulator and can emulate the network behavior in a single hop. It is capable of imposing variable and fixed jitter, packet duplication, packet reordering, packet loss and other emulation alternatives. NIST Net can handle thousands of packet entries and treats the packets according to the entries supplied by the user. An entry contains information about set of specifications and effects to be applied for packets.
Users are provided with an interactive Graphical interface and a command line interface for handling and monitoring the emulation entries and for differentiating the multiple processes of emulation.
Dummynet [4] is a link emulator which runs on Linux, Windows, FreeBSD, OpenWRT and Mac OSX platforms and is widely known for its accessibility, ease of learning and feature set. Irrespective of the operating system in use it has the ability to create bridges that can emulate even fairly complex network environments. Dummynet is capable of imposing queue and bandwidth limitations, multipath effects, delays and packet losses. A pipe is the basic element in the dummynet emulator. Pipes are configured with various networking parameters mentioned above. Traffic to be emulated is passed via pipes to perform specified action. Ipfw is a firewall that helps in redirection of traffic to pipes. Queue management policies and scheduling packets can be realized with help of an object called queue which is bound to the pipe. The recent version of Dummynet has improvements such as better modeling of the Mac layer, support for loadable packet schedulers, and a packet classifier that enforces various queue management schemes for emulating multipath effects.
NetEm [12] is a traffic shaper that provides improvement to available traffic control functionality in Linux environment. NetEm has the abilities to provide delay, packet loss, duplication and reordering to emulate the network behavior. It has two parts, the first one is a kernel module and the other one is a command-line interface.
Communication between these two is established with the help of the Netlink socket interface. Also, it supports two queuing disciplines, namely classless and classful.
Parameters that are used for emulation are given as arguments for the command “tc”.
NetEm delivers its best performance for a single flow. It has limitations in emulating a complex and dynamic real internet. Timers, pseudo random number generators and network drivers play a key role in NetEm emulation. NetEm has primarily developed for validating BIC TCP and TCP Vegas. But still it is used by many researchers for evaluation of applications and protocols.
WinPLEM [8] is a Windows-based network emulator, which uses the network driver interface specification technology. It has the ability of emulating network parameters like delay, packet loss, link bandwidth and packet reordering. WinPLEm has four modules, namely data transmission, data receiving, emulating engine and control modules. Trace-driven emulation can be performed using WinPLEM. Results show that WinPLEM can almost replicate original measured values with low CPU usage in order of 5% [8].
RplTrc is an emulation tool that uses traces to provide network attributes like delay, packet loss and duplication. By using previously generated packet traces, rpl can reproduce the behavior of wireless or wired networks. There is no limit on length of traces that are being used. As network emulation is a task dependent on time, kernel programming is used to avoid problems with scheduling. It can emulate networks of 100 Mbit/s or low loaded 1 Gbits/s with precision for delays of approximately 100 μs.
RplTrc can be used for testing, evaluation of protocols, applications in many domains (gaming, multimedia etc.,) [9].
In the papers [1], [14] the authors tested the shaping behavior of KauNet, Netem and Nistnet with regards to applying delay changes to the packets. Experiments were performed with varying PDU sizes and delay values ranging from 100 to 400 ms.
Results show that KauNet shapes the delay values above and below the determined value, whereas the other shapers produced values according the specified value.
The work in paper [14] compared KauNet and NetEm in terms of applied bit rate implementation and PDU sizes in conjunction with architectures (Intel/AMD) on emulators performance. For smaller PDU sizes output bit rate doesn't follow input bit rate. But for the larger ones, obtained results were satisfactory. The NetEm emulator produced different set of results when experiments were conducted on Intel and AMD platforms, but the change of hardware doesn’t show any impact on KauNet emulator.
In paper [7] the authors introduced a new technique called trace modulation which is the basis for a trace-driven approach. Three methods are followed in this technique:
collection, distillation and modulation. In the first phase of collection, packet information and network characteristics are collected in a specified trace format. In distillation phase, collected traces are transformed to replay traces that contain tabulated data of loss rate, latency and bandwidth. With the help of replay traces, modulation is performed. In modulation phase, based on the models designed by the user level process, the traces that are fed into the kernel impose restrictions on inbound and outbound traffic. Thus the network behavior is reproduced in a controlled and repeatable manner. A performance comparison was made between trace modulation and live performance scenario in order to validate the technique. Results state that trace driven modulation can be considered to be effective and faithful in reproducing network behavior. Further, it needs more accurate and synchronized clocks to make one-way delay measurements so as to reproduce minimal delays.
With reference to the above background studies, our thesis focuses on deterministic one way delay shaping of KauNet based on trace driven approach as shown in [7]. In addition, it also discusses the implications of simplified patterns and modeling an ideal on and off channel.
3 K AUNET O VERVIEW
KauNet is an IP-level network emulator that is used to test the performance of applications and transport layer protocols [13]. It was developed by Johan Garcia, Per Hurtig and Anna Brunström of Karlstad University. It is a free software entity implemented on FreeBSD 7.3, and the recent release KauNet 2.0 has extended its support for Linux distributions with 2.6.x.x kernels. KauNet has the capability of reproducing the network behavior as many times as it is needed [3].
Dummynet is a kernel based network emulator that shows probabilistic nature in shaping the network behavior. To understand dummynet’s nature in packet dropping condition, consider an example when the pipe is configured to drop 50% of the packets. When the same experiment is repeated multiple times, it is not for sure that it drops the same packets every time.
ipfw pipe 1 config plr 0.5
With this usage of above command, pipe is configured to drop 50% of the transmitted packets randomly
KauNet can be seen as an improvement to the dummynet’s approach by adding its deterministic restrictions on the network behavior in aspects of bandwidth, delay change, packet loss, packet reordering and bit errors. To achieve these properties it makes use of patterns that can control the nature of network on per-packet and per- millisecond basis. Consider the following example, where there is a specific restriction on individual packet. Say, 4th and 7th packets are to be dropped for every 10 packets of data. A pattern has to be generated, that can introduce restrictions and later the generated pattern is to be inserted in pipe for applying the emulated effect.
thesis@theis-laptop:~$>./patt_gen -pkt -pos -loss.plp data 10 4,7 thesis@thesis-laptop:~$>ipfw pipe 1 config bw 1Mbit/s pattern loss.plp
First command generates the pattern with desired restriction and later command is used to insert the pattern into KauNet for emulation.
KauNet inherits the emulation properties and stable code base of dummynet emulator and in addition to that it is provided with a number of pattern handling extensions and user space programs for creation and management of patterns. A short description about pattern handling operations and user space programs are described in section 3.1, 3.2 and 3.5. Section 3.3 gives an idea of how KauNet makes use of the pattern files to replicate the environment that is an exact representation to the real network.
3.1 IPFW
For emulation setup and management KauNet uses the ipfw firewall configuration program. Ipfw is a default firewall software application that can be seen in FreeBSD, whereas in Linux machines either it has to be manually installed or it comes up with the installation of KauNet.
Ipfw is provided with certain rule sets that are used for regulating the flow of traffic and for classification of packets. It is a firewall configuration made up of a number of rules designated from 1 to 65535. Packets that are coming from protocol stack are forwarded to firewall. Now, forwarded packets are compared to the ascending order of sequence rules (starting with 1 and moving towards 65535) present
in the firewall. If a match to the rule is found then corresponding action defined for that rule is accomplished. If a packet that does not match any of the rules defined, then the default rule 65535 is applied to that packet, which means to allow or deny the packet and the action to be performed entirely depends on the configuration of the kernel.
Example
ipfw add 1 deny icmp from 192.168.1.1 to 192.168.4
Deny any icmp packets that are destined to 192.168.1.4 from 192.168.1.1 ipfw add 2 prob 0.5 allow ip from 192.168.1.1 to 192.168.1.4
Drop the ip packets with a probability of 0.5 that are transferred towards 192.168.1.4 from 192.168.1.1.
First when the packets are forwarded to the firewall the packets are matched to their rule sets and the packets having rule 1 are processed first and if any icmp packets are found they are dropped after that they are matched to rule 2 stating that any ip packets that are travelling towards 192.168.1.4 and originating at 192.168.1.1 are allowed and are dropped with a probability of 0.5 %.
These are the following arguments that are used in the experimentation.
1. Add - used to add a new rule.
2. Delete - delete existing rules.
3. Flush - globally delete all rules.
For detailed description of IPFW and its rule set the reader can check the IPFW man page [16].
3.2 Pipes and Queues
For regulation of traffic, KauNet uses two constructs, namely pipes and queues.
Pipe is the basic entity of an emulation system that can emulate a link by imposing restrictions on bandwidth, packet loss and propagation delay. Weights are assigned for traffic flows for differentiating them and this task is done by the queue which has its length fixed. For sharing of bandwidth based on weights, the WF2Q+ discipline is used. Pipes are configured with patterns (delay, packet loss, bandwidth restrictions, packet reordering, and triggers) to provide network emulation. The number of pipes in the machine can be up to the order of 232. Pipes can be dynamic i.e., multiple pipes can be created in parallel and also in series to handle traffic flows. For setting the limits on the traffic flow pipes are used and queues determine the sharing of bandwidth among the traffic flows. [4]
3.3 Pattern and Scenario files
In general, patterns are created from traces, handcrafted value entries, analytical expressions or from simulation experiments. Patterns created from traces that are collected from real networks are useful for exploring and verifying the functional mechanisms of transport layer protocols or for evaluating the performance of applications [17]. For emulating the network in a controlled environment, patterns are inserted into the kernel and played. Once the pattern comes to an end, by default the same pattern is played. To mimic the behavior of a network KauNet supports creation and usage of different patterns. Description about these patterns can be understood clearly from the Table 3.1.
Pattern Type Operation
Packet loss pattern The packets that are to be dropped are under control of this pattern.
Bandwidth pattern Controls the bandwidth changes that are to be applied to the packets.
Delay change pattern Handles the delay changes that are to be applied to the packets.
Packet reordering
pattern When applied, it delays the specified packet by a defined number of positions.
Bit-error pattern Used to change the specified individual bits of the data stream.
Table 3-1 Types of Patterns and their operations
Other than the patterns described in Table 3.1, KauNet supports a pattern driven event notification system called trigger pattern. Trigger patterns are used for apprising the user about the events happening in the current running emulation experiment. It has nothing to do with the experimentation and for receiving and constructing the triggered events a third party application are required and can be used in both time and data driven modes. The examples demonstrating the usage of patterns are listed in [5].
Patterns show control over any one of the network parameters for emulation. There may raise an instance where control over multiple parameters is required for testing the protocol behavior or applications, but this wouldn’t be possible with the usage of patterns. To solve this issue KauNet supports scenario files that make it possible to have control over multiple aspects. Scenario file is nothing but a collection of patterns grouped together to support multiple emulation effects. A maximum of six pattern files can be concatenated to form a scenario. While using scenario files, KauNet follows a certain order of applying emulated effects and the order is as follows:
I. Packet loss
II. Bandwidth changes III. Delay changes IV. Packet reordering
V. Bit-errors
Consider a situation where KauNet is instructed to apply delay and also to reorder the same packet, then KauNet first applies delay to packet and then reorders it [5].
Thus with the help of these patterns and scenario files, KauNet provides control over delay changes, bandwidth limitations, packet loss, bit errors and packet reordering characteristics to be emulated in deterministic and as well as in probabilistic way. This functionality makes KauNet special when compared to other emulators [2].
3.4 KauNet modes of operation
To provide control over emulations KauNet operates in data driven mode and time driven mode. In data driven mode control per-packet can be achieved, whereas in time driven mode, control happens on per-millisecond basis irrespective of the number of packets sent. Index is a pointer that holds the current position and servers as a reference to the data. In time driven mode index moves based on time. The time resolution is in the order of milliseconds. In contrast to the time driven mode, the data driven mode works irrespective of time. Here, the index moves with respect to packets rather than time [5].
Pattern Name Time driven Mode Data driven mode Packet loss
pattern Packets are dropped during
specific interval of time. Packets are dropped on per packet basis.
Bandwidth pattern
Bandwidth changes can be implied during a certain interval of time
Bandwidth restrictions can be placed after a certain number of packets are passed.
Delay change
pattern Delays to the packets are applied
during a certain interval of time. Delays are applied on specified packets.
Packet reordering
pattern Packets are reordered in specified
time duration. Packets are reordered according to packet numbers.
Bit error
pattern Bits can be flipped during certain
interval of time Bits can be flipped at defined positions of data.
Table 3-2 KauNet modes of operation
The functioning of patterns differs in time and data driven modes and the difference in functionality is listed in the Table 3.2.
3.5 Pattern Generation
For generation of pattern files, KauNet is provided with the patt_gen and pg_gui.tcl tools.
3.5.1 Patt_gen:
patt_gen is a pattern generation utility used in KauNet for generation and management of patterns. It is a command-line tool that is capable of creating patterns based on various distributions and it can also create compressed pattern files from uncompressed text files that are derived from traces, offline simulators and complex models. The syntax and usage of this patt_gen tool for pattern creation is explained in the experimentation part and in reference [13].
3.5.2 Pg_gui:
pg_gui is a tool developed to accompany the patt_gen tool. This is an interactive GUI tool that requires installation of tcl/tk and gnuplot to be installed on the emulator machine. It is possible to plot the created patterns and examine the pattern parameters [3]. The usage of patterns is elaborated more in Section 4.5.
4 E XPERIMENTATION
This section mainly focuses on the experimentation part. In section 4.1 an overview about the experimental testbed used to perform various experiments is presented. Section 4.2 provides hardware specification list. A quick outlook of equipment description is provided in section 4.3. In section 4.4 a detailed description about the configuration of the emulation setup is given. The complete overview of pattern generation is provided in section 4.5. The section 4.6 deals with complete description about the emulator configuration. In section 4.8, the experimental procedure followed to obtain the results is presented.
4.1 Setup Design
The experimental setup consists of three machines of which host A acts as a sender and host B acts as a receiver. In-between them, an emulator machine with two NICs is used to impose restrictions on the traffic passing through it. Both the Ethernet interfaces of emulator are connected to the measurement point consisting of two DAG cards for capturing the traffic that is flowing through and passing out from the emulator [11]. The hardware configurations of the machines used in the experimental procedure are listed below. The functionalities of the Measurement Point (MP), Measurement Area controller (MArC) and consumer are discussed below.
Figure 4-1 Experimental setup design
4.2 Hardware configurations of the equipments
Host Hardware Operating system
Sender
Intel® Core™ 2 Duo Processor, 2.20GHz, 4GB
RAM Ubuntu 10.04
Receiver
AMD Athlon ™ 64 X2 Dual Core Processor 5000+, 2.6 GHz, 3GB
RAM Ubuntu 10.04
Emulator
AMD Athlon ™ 64 X2 Dual Core Processor 5000+, 2.6 GHz, 3GB
RAM Kubuntu 11.04
Table 4-1 Hardware equipment configurations
4.3 Equipment functionalities
4.3.1 Measurement Point
The function of Measurement Point (M.P) is to perform packet capturing, filtering and transportation of the collected packets. Data travelling from sender to shaper and shaper to receiver is wiretapped twice. The purpose of wiretapping is to replicate data and send them to the measurement point. A Measurement point is equipped with Endace DAG cards, (DAG 3.5E) captures the traffic. Further, these cards are synchronized with respect to time and frequency, using global positioning system (GPS) antenna for obtaining time stamps with a resolution of 60 ns [10]. The collected traffic is filtered with rules set by MArC, and the resulting data are sent to the consumer.
4.3.2 MArC
The Measurement Area Controller (MArC) is the core entity in the distributed passive measurement infrastructure. The function of MArC is to manage the MPs. It is supplied with rules about what, where and when data is to be captured by the user.
MArC utilizes this information given by the user and transforms in to MP’s understandable format. It has the ability to modify rules that create problems with performance issues [11].
4.3.3 Consumer
The Consumer is a machine that is capable of filtering the received packets. It is attached to the Measurement area network switch. The Consumer is used to store the received packets in a specified format. File format of the stored packet information is .cap (capture files) [10].
4.4 Emulation setup configuration
The Architecture design used in the emulation setup is similar to Client Server model, and in this case host A acts as a Client and host B acts as a Server. KauNet
to host A via dag interface (dag00) of measurement point while the other interface is connected to host B via dag interface (dag11) as shown in Figure 4.1.
The Emulator in-between Client and Server acts as a gateway. For routing the traffic in-between the two hosts, it is needed that both Client and Server are found on different subnets. Using the ifconfig commands given below ip addresses are assigned to Client, Server and Emulator machines.
Client
ifconfig eth0 10.0.1.1 netmask 255.255.255.0 up Server
ifconfig eth0 10.0.2.1 netmask 255.255.255.0 up Emulator
1. eth0 interface
ifconfig eth0 10.0.1.2 netmask 255.255.255.0 up 2. eth2 interface
ifconfig eth2 10.0.2.2 netmask 255.255.255.0 up
To make these settings permanent it is required to modify the /etc/network/interfaces file with these statements
On the Client machine auto eth0
iface eth0 inet static address 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255 gateway 10.0.1.2 On the Server machine auto eth0
iface eth0 inet static address 10.0.2.1 netmask 255.255.255.0 broadcast 10.0.2.255 gateway 10.0.2.2 On the Emulator machine auto eth0
iface eth0 inet static address 10.0.1.2 nemask 255.255.255.0 broadcast 10.0.1.255 gateway 10.0.1.0 auto eth2
iface eth2 inet static address 10.0.2.2 netmask 255.255.255.0 broadcast 10.0.2.255 gateway 10.0.2.0
To enable routing of data from host A to host B via the Emulator static routes must be established from host A to host B and vice versa. For establishing the static route from Client to Server the following commands are issued at host A
route add –net 10.0.2.0 netmask 255.255.255.0 gw 10.0.1.2
The above commands adds an entry in the routing table that any traffic that is intended towards 10.0.2.0 should be forwarded to 10.0.1.2
Similarly for establishing static route from host B to host A the below command is used
route add –net 10.0.1.0 netmask 255.255.255.0 gw 10.0.2.2
To make the emulator act as a gateway and to enable the ip routing/forwarding possible the line containing net.ipv4.ip_forward must be located in the /etc/syscl.conf file and the following changes must be done using the editor(instance vi).
net.ipv4.ip_forward=1
After setting the changes in the file the system is rebooted to make the machine act as a gateway. This routing rule enables the emulation machine to allow traffic flow from both directions.
4.5 Pattern and Scenario generation
The experiments conducted in this thesis use the patterns generated from real network traces as they represent the real network behavior. The steps involved in pattern generation for various parameters are explained below.
4.5.1 Delay change pattern generation
1) The one way delay statistics are obtained from the real network trace file, from which the pattern file is to be generated.
2) To generate a pattern file from a real OWD trace file, it should be converted to a text format accepted by KauNet. The created text file should contain packet sequence number and corresponding delay separated by comma for every packet included in real trace file. Format of text file is specified in Appendix A.3.
3) With the help of created delay text file it is possible to generate patterns in two ways.
4.5.1.1 Pattern generation using patt_gen
The following command is used to generate a delay change pattern file of length 3460.
patt_gen –del –pos delaychange.dcp data 3460 –f delaychange.txt
The descriptions about the arguments of the command used for pattern creation are -del
The generated pattern is a delay pattern -pos
Pattern generation is based on positions delaychange.dcp
Generates a pattern file with name delaychange from the entries listed in the delaychange.txt file
data
Indicates that the pattern should be operated in data driven mode -f delaychange.txt
The name of the file which contains uncompressed pattern values from which the patterns are to be generated.
To get the complete description about the delaychange.dcp file the following command is used.
patt_gen –info delaychange .dcp
4.5.1.2 Pattern generation using pg_gui
Figure 4-2 Delay change pattern generation using pg_gui
Figure 4-3 Graph representing plot of packet sequence numbers versus delay changes Figure 4.2 shows how the pg_gui tool can be used to generate a delay change pattern file. In the position parameter field the packet positions followed by the propagation delays that are to be applied to those packets are specified. To generate a delay change pattern file the required parameters are provided and the Create & Save
option is used to create and save the pattern file. The generated pattern file is automatically stored in the patt_gen folder. It is possible to plot the delay change pattern file using pg_gui and Figure 4.3 shows the graph of the pattern file plotted with packet sequence number on the x-axis versus delay changes that are to be applied to individual packets on the y-axis. To plot the graph the Create & Show option is used.
4.5.2 Packet loss pattern generation
1) The packet losses are identified from the real traffic traces by determining the missing packets at the receiver side with respect to the sender side.
2) The packet numbers which the emulator should drop are stored in a text file in a format that is acceptable to pattern generation tools.
3) With the help of the packet loss text file, the packet loss pattern can be generated using patt_gen and pg_gui.
4.5.2.1 Pattern generation using patt_gen
When the following command is used it results in the generation of a packet loss pattern file that is applicable to 3460 packets (say).
patt_gen –pkt -pos packetloss.plp –pos data 3460 –f packetloss.txt
The descriptions about the arguments of the command used for pattern creation are -pkt
Packet loss pattern is generated.
-packetloss.plp
Generates a compressed format of packet loss pattern file that is made up with entries listed in text file
-f packetloss.txt
Contains entries of packets that are to be lost when pattern is played
A description regarding the number of packet losses and size of pattern file can be obtained when the command shown below is used:
patt_gen –info .plp
A .plt file consisting of pattern file entry information can be obtained when the following command is used:
patt_gen –graph .plp
4.5.2.2 Pattern generation using pg_gui
The packet loss pattern file can be generated using the pg_gui utility. Figure 4.4 shows the procedure involved in the generation of a pattern file. The values specified in the position parameter field are the packet numbers that are to be lost when this pattern file is used. After filling out all the required fields when a click is made on Create & Save option, the packet loss pattern file is generated and saved. The Create
& Show option is used to display the pattern file in graphical format. Figure 4.5 illustrates the plot of packet sequence number on x-axis versus packets that are to be dropped on y-axis.
Figure 4-4 Packet loss pattern generation using pg_gui
Figure 4-5 Graph representing packet sequence numbers versus packets that are to be lost
4.5.3 Bandwidth change pattern generation
1) The time positions and the emulated bandwidth that is applied to the packets, separated by commas, are listed in the text fiile.
2) With reference to the created text file, patt_gen and pg_gui.tcl can be used to produce the bandwidth change pattern file.
4.5.3.1 Bandwidth pattern generation using patt_gen
The following command can generate a bandwidth pattern file that can limit the flow of traffic rate.
patt_gen –bw –pos bandwidth.bcp time 60000 –f bandwidth.txt
-bw Generates a bandwidth pattern file bandwidth.dcp
A bandwidth pattern file with .dcp extension is generated.
time
The generated pattern should be operated only in time driven mode -f bandwidth.txt
The pattern file that is generated should take the values that are listed in the bandwidth.txt file.
The following command gives the complete information about the pattern file entries by generating a file with .plt extension.
patt_gen –info bandwidth.dcp patt_gen –graph bandwidth.dcp
Figure 4-7 Graph representing the plot of kernel ticks vs emulated bandwidth
Figure 4.6 demonstrates the generation of bandwidth change pattern in time driven mode. The values specified in the position parameter field indicate that the amount of bandwidth allowed for the traffic flow should be 8192 Kbps for the first 10 s and then it is limited to 4096 Kbps and so on. Figure 4.7 indicates the graphical representation of the bandwidth change pattern file generated using Create and Show option.
4.5.4 Scenario file generation
The scenario file can be generated using the following command patt_gen –mkscn <scenario> –t information text –f patt1 patt2 -mkscn
This is used for making and managing a scenario file -t “information text”
Displays the text which is written in-between the quotes
<scenario>
The name of the scenario file that is to be created is provided with an extension of .scenario
-f patt1 patt2
This keyword is used to indicate that the scenario file should be made from patt1 and patt2 files.
4.6 KauNet Configuration
In addition to the steps involved in dummynet configuration, KauNet configuration needs some additional keywords which provide special functionalities. To make KauNet a working emulation system the following steps are to be followed.
4.6.1 Packet filtering configuration
The selection of packets that are to be imposed with emulated conditions is done with the help of ipfw firewall rules. The packet filtering can be done based on Client or Server ip addresses, port addresses, etc. The filtered packets are then sent to a pipe where the packets are subjected to delay change, packet loss or bandwidth restrictions.
The packet filtering is done using the following commands:
ipfw add 1 pipe 1 ip from 10.0.1.1 to 10.0.2.1 out
Before performing the above step, it is important to flush out any previous configured rules for packet filtering and pipe configurations, and a default allow rule is to be created to allow traffic from sender to receiver and vice versa.
ipfw –f flush
It flushes all the previous rules ipfw pipe flush
This command destroys all pipes created previously.
ipfw add allow ip from any to any
Invokes a rule that allows general traffic flow
These steps are performed every time whenever a new experiment is initiated.
4.6.2 Pipe configuration
For configuring pipes with specific emulated conditions, the keyword pattern is used to load the pattern into the pipes that provides necessary requirements of emulation, and the following commands are used to configure the pipes:
ipfw pipe 1 config bw 1Mbit/s pattern .dcp
This command allows the configuration of a pipe with delay pattern file .dcp and with a bandwidth of 1 MByte/s
ipfw pipe 1 config bw 1Mbite/s pattern .plp
The pipe can mimic the network based on multiple parameters. This is made possible by loading scenario files into the pipe. The command using for doing this is
4.7 Measurement point and Consumer configuration
Configuration of measurement point should be done ahead of the experimentation.
First of all DAG cards are started and should be properly synchronized to each other with respect to time and frequency to get accurate timestamps.
In order to analyze the emulation capabilities of KauNet shaper, traffic flow from Client to shaper and shaper to Server is wiretapped and sent to measurement point. It is always good to ensure that DAG (Data Acquisition and Generation) cards are properly synchronized with respect to time and frequency ahead of experiments and these operations are done using NTP and GPS. Before starting the measurement point, file name of capture files are to be specified in consumer, thus received packets from the measurement point are stored in a .cap file. If the .cap file is not declared before configuring the M.P it is not possible to store the packet information.
4.8 Experimentation Procedure
To evaluate the efficiency of KauNet mimicking the network conditions, the UDP traffic representing the multimedia applications is transmitted from Client to Server.
For this, a tested tool built in C++ that generates UDP traffic is used. The tool consists of two independent Client Server applications.
On the Client side the following arguments are specified for generating and transmitting the UDP traffic to the Server.
e=Experiment number, r=Run number, k=Key id, s=Destination address, p=Destination port, n=Number of packets to send, l=Size of the packets and w=Inter frame gap in microseconds.
The traffic that is destined to the Server flows through the KauNet emulator where it is subjected to trace driven emulated conditions. Server uses the following rules for identifying the traffic
e=Experiment number, r=Run number, k=Key id, p=Destination port.
In-between, for capturing the traffic before and after the emulation process, the link between sender-emulator and emulator-receiver is wiretapped and the replicated packets are sent to MP and using the two duly synchronized DAG cards. The packets are captured and the timestamps and sequence numbers are assigned to the packets.
The captured packets are sent to the consumer, where the trace files are collected and the data analysis can be done.
5 R ESULTS
This chapter gives the detailed description about the obtained results. Section 5.1 deals with KauNet capability in reproducing the OWD characteristics. Emulating packet loss and delays are discussed in section 5.2. In section 5.3, a detailed analysis of simplified patterns performance is discussed. Section 5.4 deals with implications of reduced pattern size. A short comparison between time and data driven modes of KauNet are presented in 5.5. Section 5.6 deals with KauNet capabilities in emulating an ideal channel with on and off characteristics.
5.1 Reproducing one way delay characteristics
Network behavior can be reproduced multiple times with the help of patterns which are generated from real network measurements. The OWD values and the corresponding packet sequence numbers are extracted from the real network trace file and are converted into the format explained in Appendix A and stored in a text file.
The generated text file is used for creating a pattern file that is inserted into the kernel of the emulator machine for mimicking the real network behavior. To generate a pattern file from text file, it is needed to check whether any erroneous values are present in the text file and if they are present, these incorrect values should be removed. It is necessary that the text files which are used for generating the pattern file must be stored in the patt_gen folder.
KauNet controls the network behavior with the help of pattern files. The capability of KauNet in controlling the packets by applying the delay changes is explained in this section.
Figure 5-1 Graph representing Packet sequence number versus Delay
delay values applied to the separate packets. From the graph it is evident that the synthetic trace follows the original trace. Table 5.1 gives a comparison between synthetic and original traces and from the statistics obtained, it can be seen that the results are almost the same for the two traces in all cases.
Synthetic trace Original trace
Average (ms) 0.170 0.170
Standard deviation (ms) 0.418 0.418
Maximum delay (ms) 3.326 3.327
Minimum delay (ms) 0.078 0.079
Average Relative error (%) - 0.270
Table 5-1 Showing the statistics for original and synthetic traces.
The relative error is the ratio of the absolute error and original value. Let Si and Oi
be the synthetic and original one way delay of ith packet respectively. The relative error
Ri can be calculated using the formula 5.1.Ri (Si Oi) Oi (5.1)
Average relative error R is the summation of all samples of the relative error dividing by the number of samples.
Figure 5.2 is a plot between the relative error obtained from original and synthetic delays corresponding to the individual packets. The distribution of relative errors among the packets can be seen from the graph. The maximum error and minimum relative error values obtained are 0.063% and -0.045%, respectively.
Figure 5-2 representing packet sequence number versus relative error
Figure 5.3 is a plot of relative errors versus the number of packets. From the figure it can be seen that around 57% of the relative error values lies below the zero axis and 43% of the values above the zero axis. The reason behind these negative and positive relative errors is due to KauNet’s ability in shaping the delays both above and below the specified delays.
Figure 5-3 Representing relative error for the number of packets.
Figure 5.4 is a representation of a complementary cumulative distribution function of delay plotted on a logarithmic scale. The red line and green line indicates the original and synthetic delay values. It can be inferred from the graph that the green line has almost completely overlaps with the red line indicating that there is not much variation between the reproduced and the original values. KauNet has almost followed the original delay changes indicating a satisfactory shaping behavior.
Similar set of experiments are conducted with few more traces. The correlation coefficients for the traces are showed in the Table 5.2
Traces1 Correlation Coefficient
Trace1 0.99997
Trace2 0.99998
Trace3 0.99998
Trace4 0.99939
Trace5 0.99998
Table 5-2 Showing the correlation coefficients for different traces.
The correlation coefficient is calculated for the one-way delays of the obtained synthetic traces after experimentation and the original traces. Thus, from the table a strong correlation between the traces can be observed. Thereby, indicating that, “Trace doesn’t matter KauNet is always capable of reproducing the trace.”
5.2 Shaping One way delay and packet losses
It is possible to emulate a network environment consisting of delays and packet losses.
KauNet makes it possible by means of using scenario files and multiple pipes. The detailed procedure of doing this is listed below.
5.2.1 Using Scenario files
Scenario file used in the experiment is a collection of delay change pattern and packet loss pattern grouped together to enforce restrictions on delay changes and packet losses for shaping the traffic.
Figure 5-5 Packet sequence number versus delay changes using scenario file An overlap of OWD values of synthetic and original traces are observed in the Figure 5.5. A slight variation of delay changes in the range of 3.2-3.27 (extreme tail) is observed from the complementary cumulative distribution graph shown in the Figure 5.6.
1 Trace4: payload size-512 bytes speed 128kbps uplink, Trace5: payload size-1024 bytes and uplink speed 128 kbps, Trace1-payload size 1024 bytes and uplink speed 256 kbps, Trace2- payload size- 1232 bytes and uplink speed 256 kbps, Trace 3- 1440 bytes and uplink speed 128 kbps
Figure 5-6 Complementary cumulative distribution of delay change
5.2.2 Using multiple pipes
Usage of multiple pipes is another alternative option for shaping multiple emulation parameters. It provides flexibility to follow any kind of order of preference depending upon the need which is not possible with scenario files. There are two possible ways of shaping both delay and packet losses together. One way of achieving this is to configure the pipe with the delay changes that are to be applied to the packets. The resultant output of the pipe is then transferred to another pipe which is configured with packet losses. The second way of doing this is to allow the packets to pass through the pipe which is configured with packet losses and then it is transferred to other pipe where the delay changes are applied to the outgoing packets.
In figures 5.7 and 5.9 it is observed that an overlap of delay change values of synthetic and original traces has occurred. Small variations of values are observed at the range of 3.2 to 3.27 seconds and it can be seen from the Figure 5.8. Negligible amount of variations are seen in the case of Figure 5.10 resulting in close proximity of original and synthetic delay values.
Figure 5-7 Packet sequence number versus delay obtained in first case
Figure 5-8Complimentary cumulative distribution function of delay changes obtained in first case
Figure 5-9 Packet sequence number versus delay change in the second case
Figure 5-10 Complementary cumulative distribution function of delay change in 2nd case
Statistics Multiple pipes
first case Multiple pipes
second case Scenario files
Average (ms) 0.151 0.151 0.151
Standard deviation
(ms) 0.361 0.361 0.361
Max. Delay (ms) 3.327 3.326 3.327
Min. Delay (ms) 0.077 0.078 0.077
Average Relative
error (%) -0.27 0.05 0.05
Max. Relative
error (%) 4.6 69.7 70.5
Min. Relative
error (%) -4.5 -67.4 -67
Table 5-3Comparison between multiple pipes and scenario trace files
From the Table 5.3 shown, a close proximity in the statistical values are observed in all the cases except for average relative error, maximum and minimum relative errors.
For those statistics, variations can be seen in multiple pipes first case in comparison with scenario and multiple pipes second case. The relative error for scenario and multiple pipes second case with respect to the original trace lies around 0.0005 whereas in the multiple pipes first case it is around -0.002. The maximum and minimum relative error values obtained for multiple first case are 0.046 and -0.045 differ greatly when compared to 0.7 and -0.67 in scenario and multiple pipes second case. Due to the nature of KauNet imposing the emulated effects according to priority on the ongoing traffic these variations in statistics are noticed. A clear explanation of how KauNet intercepts the packets is given in the next sections.
5.2.3 Emulated Effects implementation in multiple pipes first case
In this case, the ongoing traffic that is passing through the emulator is first of all subjected to delay restrictions using delay pattern. For imposing the delay restrictions the pipe 1 is configured with delay pattern and these effects are applied to the traffic that is coming into the pipe. The UDP traffic that is imposed to delay restrictions is then sent to the pipe 2 which is configured with packet loss patterns.
Based on the pattern that is inserted into the kernel the respective packets are dropped from the transferred data that is coming out from the pipe. In both the cases the queue size is configured to 100 slots. The following steps listed below are used for packet filtering and pipe configuration with respective patterns.
1. ipfw pipe flush 2. ipfw –f flush
3. ipfw allow ip from any to any
7. ipfw pipe 2 config queue 100 pattern packetloss.plp
The first commands flush out the formerly defined rules assigned to the pipes and allow the flow of general traffic. Commands 4 and 5 are used for firewall rule creation that allows ip traffic destined to 10.0.2.1 and originated at 10.0.1.1 must be routed towards pipe 2 via pipe 1. Commands 6 and 7 are used to configure the pipes. In this case pipe is configured with delay pattern and pipe 2 is configured with packet loss pattern (as specified above).
In the Figure 5.11 [5], the queues denoted by q are reception or bandwidth queues.
Depending upon the specified emulated bandwidth the packets are made to wait for duration in theses queues. If the rate of ingress traffic flow is more when compared to the imitated bandwidth then the queues may continue to work up leading to the consequence of packets effecting with queuing delay in addition to the transmission delay. The p queues are the delay line queues where the packets are delayed according to the propagation delay that is specified in the pattern. r is the reordering queue bestowed to the KauNet that makes the reordering of packets possible. Usage of this queue is out of focus of this thesis. The detailed explanation about the pipes and the implementation of the emulated effects is found in [3].
The packets entering into pipe 1 are tapped by the dummynet through the dummynet_io() function, and this function is called for each and every packet. As bandwidth restrictions are not imposed on the traffic, the ready_event() function is called instantaneously.
Figure 5-11 representing the flow of traffic through pipes [5]
