CONCLUSIONES Y RECOMENDACIONES

In this section, we introduce the components used in our framework; we give a brief description about each of the components and then we show the purpose of using each component in our framework.

5.4.1

Iperf

Iperf [75] was developed by National Laboratory for Applied Network Research (NLANR), Distributed Applications Support Team (DAST) as a modern alternative for measuring maximum TCP and UDP bandwidth performance. Iperf is considered a commonly used network testing tool that can create TCP and UDP traffic. Iperf is a tool for network performance measurement written in C++.

Iperf allows the user to set various parameters that can be used for testing a network, or alternately for optimizing or tuning a network. Iperf has a client and server functionality, and can measure the throughput between the two ends, either unidirectional or bi-directionally. It is open source software and runs on various platforms including Linux, Unix and Windows.

 UDP: When used for testing UDP capacity, Iperf allows the user to specify the datagram size and provides results for the datagram throughput, jitter and packet loss.

 TCP: When used for testing TCP capacity, Iperf measures the throughput of the payload. One thing to note is that Iperf uses 1024*1024 for megabytes and 1000*1000 for megabits.

One of the main advantages of Iperf is that it is considered a cross-platform tool (Figure 5-1) that can be run over any network and output standardized performance measurements. So, it can be installed on any UNIX/Linux or windows operating system. One host must be set as client, the other one as server. Consequently, it can be used to compare the wired and wireless networking equipment and technologies in an unbiased way depending on implementation constraints. Moreover, it is also an open source tool.

Figure 5-1 Iperf (Cross platform utility)

In a real world scenario, we may need to fill or nearly fill a call path with traffic in order to test its behavior under heavy loads. By tweaking the amount of load placed on the call path, we can figure out failure thresholds for it.

In our framework, we used Iperf to simulate a fixed load of the codec used and continually increase, recording the call quality and completion rate each time we do. Iperf has been recommended before for its accuracy and realism for such purpose [107 ]. Once, we hit the performance ceiling, we should be able to state that a particular link will carry no more than X G.711 calls or that a certain call path through the network will carry no more than Y G.729A calls or not even more than Z H.264 video calls. In addition, we used Iperf to simulate the traffic pattern of different audio/video codecs to measure the packet loss and jitter.

5.4.2

Dummynet

Dummynet [49] is a live network emulation tool, originally designed for testing networking protocols, and since then used for a variety of applications including bandwidth management. It simulates/enforces queue and bandwidth limitations, delays, packet losses, and multipath effects. It also implements various scheduling algorithms. Dummynet can be used on the machine running the user's application, or on external boxes acting as routers or bridges. Dummynet runs within your operating system (FreeBSD, OSX, Linux, Windows) and works by intercepting selected traffic on its way through the network stack and passing packets to objects called pipes which implement a set of queues, a scheduler, and a link, all with configurable features (bandwidth, delay, loss rate, queue size, scheduling policy...) as in Figure 5-2. Traffic selection is done using the Ipfw firewall, which is the main user interface for Dummynet. Ipfw lets you select precisely the traffic and direction you want to work on, making configuration and use incredibly simple. You can create multiple pipes, send traffic to different pipes, and even build cascades of pipes.

Figure 5-2 Dummynet Pipe [49]

Below, we will see some examples for using the Ipfw rule. The following examples can be illustrated as follows:

Example 1

The first command line creates a pipe which limits traffic into 500Kbit/s, delays packets for 100 ms and drops 10% of the packets. The second command line adds the pipe to the kernel and specifies filter conditions.

ipfw pipe 1 config bw 500Kbit/s delay 100ms plr 0.1 ipfw add pipe 1 ip from any to any

Example 2

Dummynet can also be used to model multiple paths using a classifier option that matches packets with a given probability; this allows traffic to be randomly directed to one of multiple links. As an example, the rules:

send 20% of incoming HTTP traffic to pipe 10, another 56% (0.7 of the remaining 80%) to pipe 20, and the remaining part to pipe 30. If pipes have different bandwidth or delays, or they are subject to other interfering traffic, one can cause a wide range of effects, from selective packet loss to jitter and reordering.

In our framework, we use Dummynet for two purposes. First, we use Dummynet to change the network conditions (delay, packet loss, queue and bandwidth) to be able to test the QoS and QoE under different network conditions. Second, we use it to set the bandwidth with the Ethernet bandwidth according to the codec emulated in order to measure accurate delay results with the current browsing sessions if any on the computer.

5.4.3

Ping (network utility)

Ping is a computer network utility used to measure the Round-trip time for messages sent from certain source to a destination computer. Ping works by sending Internet Control Message Protocol (ICMP) echo request to the destination and waiting for the ICMP response. During such process, the time is measured from the source to destination and back to the source again (Round trip time) and also any packet loss is measured as well. At the end, the results are shown at the sender side, including minimum, maximum, and the mean round-trip times. The ICMP packet is shown in table 5-3.

ipfw add 1000 prob 0.2 pipe 10 src-port 80 in ipfw add 1010 prob 0.7 pipe 20 src-port 80 in ipfw add 1020 pipe 30 src-port 80 in

Figure 5-3 ICMP packet [87]

We use the ping utility in our framework to estimate the one-way delay required from the caller to the callee, we specify the packet size option in the ping command according to the codec used in order to emulate the codec's traffic patterns.