In order to verify our hypothesis that the inter-segment arrival rate at MAC for TCP flows is within the region of 10 µs, we examined the packet traffic of a small Ad-hoc network. The purpose of these experiments was to establish that aforementioned assumptions, derived from OPNET’s trace files, can also be reflected to real networks. We consider a set-up consisting of two (2) laptop computers, choosing as general OS Linux-based platform Ubuntu 8.10 (Intrepid Ibex) [170], and including the following wireless interfaces: i) a Netgear WG511T adapter card [171] and ii) a USRobotics USR5410 adapter card [172] . The STAs operated in a 22MHz frequency band around 2.462GHz, were located in the same room resulting in a high Signal-to-Noise Ration (SNR) between nodes and no hidden terminals. The channel is error-prone, thus few inaccuracies are expected. A schematic of the test-bed set-up is shown in Figure 7.5.
Figure 7.5: A schematic of the test-bed set-up
As we will discuss in detail, our measurements focus on two traffic scenarios. First, we consider UDP traffic from one STA (Client) to the other STA (Server) of
constant packet length with Poisson distributed inter-departure times at different rates, depending the application in study taken from Scenario 2. Subsequently, we consider the same configuration parameters but with TCP traffic instead. Note that the applications will be checked for both types of traffic although in real scenarios this is not the case, however to validate our results we consider all possible cases.
The traffic was generated using the Distributed Internet Traffic Generator (D-ITG) [173, 174, 175], which allowed us to statistically characterize parameters such as Inter-Departure Times (IDTs) and packet length. For example, in order to generate the traffic for the UDP traffic for Case 1, as displayed in Table 7.1, we instruct D-ITG to generate UDP packets at a rate of 1, 600 packets per second with constant inter-departure times and a constant packet length of 1, 458 bytes. Note that the listed packet size, refers to the packet length of the transmitted frame, consequently when we calculate the packet length for D-ITG, we consider the expected payload length at the Application Layer, thus excluding additional headers.
Case Flow Name Protocol Offered Load Packet Size Packets/Sec IDT 1 HDTV + Futuristic Audio UDP 19.2 M b/s 1,500B 1,600 0.000625 sec 2 HDTV + PCM 5.1 Audio UDP 24 M b/s 1,500B 2,000 0.0005 sec
3 Internet File TCP 120 M b/s 1,500B 10,000 0.0001 sec
Table 7.1: Test-bed traffic generation parameters
Besides the statistics provided by the wireless interface, we used nstat to gather IP, UDP and TCP statistics aggregated across all interfaces, so as to check for unexpected network activity during the tests. We have also operated a customized Packet Analyser (sniffer) to record detailed logs of all packets sent and received by the wireless interfaces during each test. Sniffers [176] are pro- grams used to read packets that travel across the network at various levels of the OSI layer. The custom implemented Packet Analyser was able to retrieve specific interface statistics, such as number of packets received and transmitted, inter-arrival times, packet lengths, etc., and histograms, like signal noise levels. The Listing 7.1 displays a snippet of one of the TCP traces. The sniffer’s trace files were examined off-line on a case by case basis, so a flow behavioural pattern for TCP and UDP cases could be derived. In order to calculate mean, minimum and maximum values for the statistics and examine the TCP and UDP traces,
a specialised parser was implemented as well. Both source codes for the Packet Analyser and the Parser can be found in Appendix Source Codes of Packet Anal- yser and Parser.
01:03:52.1 4 3 5 5 4 IP 10.0.0.2.3 8 2 2 1 > 10.0.0.1.9 0 0 0: S 4 1 9 3 9 9 3 9 6:4 1 9 3 9 9 3 9 6 ( 0 ) win 5 8 4 0 01:03:52.1 4 4 5 3 3 IP 10.0.0.1.9 0 0 0 > 10.0.0.2.3 8 2 2 1: S 3 7 2 8 5 0 3 5 9 3:3 7 2 8 5 0 3 5 9 3 ( 0 ) ack 4 1 9 3 9 9 3 9 7 win 5 7 9 2 01:03:52.1 4 4 5 8 5 IP 10.0.0.2.3 8 2 2 1 > 10.0.0.1.9 0 0 0: . ack 1 win 92 01:03:52.1 4 4 6 3 6 IP 10.0.0.2.3 8 2 2 1 > 10.0.0.1.9 0 0 0: P 1:2 ( 1 ) ack 1 win 92 01:03:52.1 4 5 9 9 9 IP 10.0.0.1.9 0 0 0 > 10.0.0.2.3 8 2 2 1: . ack 2 win 91 01:03:52.1 4 6 7 4 1 IP 10.0.0.1.9 0 0 0 > 10.0.0.2.3 8 2 2 1: P 1:2 ( 1 ) ack 2 win 91 01:03:52.1 4 6 7 6 3 IP 10.0.0.2.3 8 2 2 1 > 10.0.0.1.9 0 0 0: . ack 2 win 92 01:03:52.1 4 7 1 2 4 IP 10.0.0.2.3 8 2 2 1 > 10.0.0.1.9 0 0 0: P 2:3 4 ( 3 2 ) ack 2 win 92 01:03:52.1 4 8 3 9 0 IP 10.0.0.1.9 0 0 0 > 10.0.0.2.3 8 2 2 1: P 2:7 ( 5 ) ack 34 win 91 01:03:52.1 8 4 4 5 1 IP 10.0.0.2.3 8 2 2 1 > 10.0.0.1.9 0 0 0: . ack 7 win 92 01:03:52.2 0 1 9 7 8 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: S 4 2 2 9 8 3 5 0 4:4 2 2 9 8 3 5 0 4 ( 0 ) win 5 8 4 0 01:03:52.2 0 3 4 7 3 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: S 3 7 2 9 0 8 0 5 0 9:3 7 2 9 0 8 0 5 0 9 ( 0 ) ack 4 2 2 9 8 3 5 0 5 win 5 7 9 2 01:03:52.2 0 3 5 2 5 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . ack 1 win 92 01:03:52.2 0 8 7 9 1 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: P 1:1 4 3 5 ( 1 4 3 4 ) ack 1 win 92 01:03:52.2 0 8 9 8 6 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 1 4 3 5:2 8 8 3 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 0 5 3 8 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 1 4 3 5 win 136 01:03:52.2 1 0 5 8 0 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 2 8 8 3:4 3 3 1 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 0 6 0 2 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 4 3 3 1:5 7 7 9 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 1 1 9 8 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 2 8 8 3 win 181 01:03:52.2 1 1 2 2 6 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 5 7 7 9:7 2 2 7 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 1 2 4 8 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 7 2 2 7:8 6 7 5 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 3 0 6 4 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 4 3 3 1 win 227 01:03:52.2 1 3 0 9 2 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 8 6 7 5:1 0 1 2 3 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 3 1 1 2 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 1 0 1 2 3:1 1 5 7 1 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 5 3 5 2 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 5 7 7 9 win 272 01:03:52.2 1 5 3 7 9 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: P 1 1 5 7 1:1 3 0 1 9 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 5 4 1 2 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: P 1 3 0 1 9:1 4 3 4 1 ( 1 3 2 2 ) ack 1 win 92 01:03:52.2 1 6 9 2 8 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 7 2 2 7 win 317 01:03:52.2 1 6 9 5 5 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 1 4 3 4 1:1 5 7 8 9 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 6 9 7 7 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 1 5 7 8 9:1 7 2 3 7 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 8 1 8 0 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 8 6 7 5 win 362 01:03:52.2 1 8 2 0 7 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 1 7 2 3 7:1 8 6 8 5 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 8 2 2 8 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 1 8 6 8 5:2 0 1 3 3 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 9 0 0 5 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 1 0 1 2 3 win 408 01:03:52.2 1 9 0 3 1 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 2 0 1 3 3:2 1 5 8 1 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 1 9 0 4 2 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: P 2 1 5 8 1:2 3 0 2 9 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 2 0 5 5 9 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 1 1 5 7 1 win 453 01:03:52.2 2 0 6 1 0 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 2 3 0 2 9:2 4 4 7 7 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 2 0 6 2 7 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 2 4 4 7 7:2 5 9 2 5 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 2 1 0 4 0 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 1 3 0 1 9 win 498 01:03:52.2 2 1 0 6 6 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 2 5 9 2 5:2 7 3 7 3 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 2 1 0 8 0 IP 10.0.0.2.8 9 9 8 > 10.0.0.1.8 9 9 7: . 2 7 3 7 3:2 8 8 2 1 ( 1 4 4 8 ) ack 1 win 92 01:03:52.2 2 1 7 4 1 IP 10.0.0.1.8 9 9 7 > 10.0.0.2.8 9 9 8: . ack 1 4 3 4 1 win 543
Listing 7.1: Sample of Sniffer’s trace file
Simulation Results (Client ↔ AP)
Flow HDTV (19.2 M b/s) HDTV (24.0 M b/s) IF (120.0 M b/s)
IAT ≤ 10 µs UDP 4.32% UDP 2.64% UDP 2.87%
TCP 89.4% TCP 94.92% TCP 89.92%
Table 7.2: Ad-hoc test-bed results for inter-packet arrival expectancy For the experiments, we processed five (5) repetitions for each case and then provided as an output the average calculated result from all runs. Table 7.2 displays the ratio for the segments arrived at the MAC layer within the 10 µs (± small deviation) interval over the total number of segments. Although the
actual HDTV and IF flows are transmitted over the UDP and TCP protocols, respectively, we’ve also examined cases with opposite transport protocols with the same traffic characteristics (e.g. inter-arrival times, offered loads) for the sake of confidence. For the UDP test, we can observe that percentage of traffic arriving within that specific interval is only 4.32% and 2.64% for the HDTV flows, and 2.87% for the IF. For the TCP traffic, the statistics provided by the wireless interface are proving our initial hypothesis to a huge extend. A large portion of the total segments was recognised as TCP traffic even for flows that have smaller rates, like the HDTV. The results for the TCP traffic over both HDTV and IF, were 89.4%, 94.92% and 89.92%, respectively.