Crónicas periodísticas o partes de un gran reportaje

Evaluating delays in a wide area network is a difficult task since it is hard to find good reference values. The most accurate approach is to provide each test site with a reliable external clock, such as an atomic clock or a GPS receiver. These solutions are costly, and other less expensive procedures were used to verify the implement-ation. Several tests were carried out in two different environments to evaluate the measurement techniques. The first setup consisted of two hosts in a separated net-work, interconnected through a third computer which acted as a network emulator.

In the second setup the two hosts were placed at different locations in Stockholm and the test traffic was routed over the Internet. The test probes were running Fedora 8 with a customized 2.6.24 Linux kernel on an Intel Pentium Celeron pro-cessor at clock speeds of 600 MHz and with 256 megabytes of RAM. An NTP server located at KTH[55] in Stockholm was used for all measurements. The system clocks were synchronized every minute for optimal accuracy[56].

Netem Test Sessions

Netem[57] is an application which provides network emulation functionality by emu-lating properties of wide area networks. Netem consists of a small kernel module for queuing discipline, which is included in recent Linux kernels, and a configur-ation utility which is part of the iproute2 package. It is a useful tool for testing the behaviour of different network protocols and provides options to emulate a real world network response[58]. The current version emulates delay, loss, duplication and reordering.

Netem implements the four different properties using statistical distributions and correlation values between packets, which gives a good resemblance to real networks. In the case of evaluating network protocols it would also be desirable to

24

4.2. EVALUATION

be able to decide an exact percentage of loss, duplication and reorder for a specified window size of transmitted packets. The evaluation with Netem does unfortunately not provide this feature, but running the test sessions over a long period of time makes the results more reliable.

Five separate one hour test sessions were carried out. During each session, TWAMP, One-way ping, PTAnalyzer and Ping ran in parallel, all methods used test streams with 100 packets per second. In the first four test sessions, Netem emulated one of the four properties delay, loss, duplication and reordering individually, since the properties might have influence on each other. During the last test session, all four properties were activated simultaneously. Netem’s emulation of delay was activated in both directions, but further metrics were only emulated on the reverse path between the two measurement nodes.

The emulator configuration was set to 20% loss rate and 15% duplication rate.

The delay on the forward path was set to 50 milliseconds, and 100 milliseconds on the reverse path. The reordering was set to 100% gap 100. This setting causes every 100th packet to be sent immediately, and all other packets were delayed as usual, in this case with 100 milliseconds. The test setup is shown in Figure 4.2.

Probe A

Netem

Probe B Delay: 50ms Delay: 100ms

Loss: 20%

Duplicate: 15%

Reorder: 100% gap 100

Figure 4.2. Probe A, the controller, sends TWAMP-Test packets to probe B, the responder, which are reflected back. The emulator adds 50 milliseconds delay on the forward path, and adds 100 milliseconds delay together with the remaining metrics on the reverse path.

CHAPTER 4. IMPLEMENTATION AND RESULTS

Internet Test Sessions

During the second experiment, the different techniques were evaluated between two hosts in Stockholm interconnected through the Internet. Test site A was connec-ted through Telia and test site B had Bredbandsbolaget as ISP, the two hosts were separated by 10 hops. The quality of the two connections differed; the host at Bred-bandsbolaget had a round-trip time to the NTP server of about 1.5 milliseconds, while the round-trip time between the host connected to Telia and the NTP server was 11 milliseconds. Different NTP servers were evaluated, but the difference was about the same or worse, and the tests were carried out with the initial setup.

Three different tests were performed, and similarly to the previous test sessions with the network emulator, all four measurement tools ran simultaneously. During the first test session, no other traffic was deliberately injected into the network.

However, the Internet connection at site A was shared with others, which unfortu-nately lead to a wide margin of error. During the second test session, the outgoing bandwidth from site A was strained by sending file transfers to another host, and during the third session, the incoming bandwidth to site A was used. The test setup is shown in Figure 4.3.

The duration of the tests was reduced to 1 minute per test session, but each session was performed ten times in order to characterize a more accurate average of the metrics. Since the bandwidth at site A was allocated to file transfers during the second and third test sessions, the NTP packets were delayed and the resulting measurement data was worthless. Therefore the system clock was synchronized before the test sessions began, and the NTP daemon was shut down during the sessions. The sessions were kept short due to skew.

Probe A Probe B

Internet

Session 3 Session 2

Figure 4.3. Probe A, the controller, sends TWAMP-Test packets routed over the Internet to probe B, the responder, which are reflected back. During sessions 2 and 3, the bandwidth at site A was used for file transfers in the outgoing respectively incoming direction.

26