\section{Experimental Evaluation}\label{4-Experimental Evaluation}
In this section, we provide an experimental analysis of our TCP implementation operating over a multi hop wireless ad hoc network in a real environment. A description of the methodology followed as well as the selected performance metrics will be provided, and the experimental results obtained will be discussed.

As pointed out in section I, although TCP is conceptually independent from the underlying network technology, some basic design assumptions are clearly inspired from the characteristics of wired networks dominant at the time when it was conceived. TCP implicitly assumes that packet loss is mainly due to network congestion causing buffer overflows at intermediate routers and that nodes are mostly static. These assumptions do not hold in wireless ad hoc networks, as changes in the network topology may occur due to node mobility or variability of the link quality. In the past years, a lot of scientific research has been done studying the influence that multi hop ad hoc networks have over TCP's performance. It has been suggested that the important differences existing between ad hoc networks and the wired Internet legacy may have a clear negative effect on the performance of TCP. However, to the extent of our knowledge a very small number of experimental analyses~\cite{13,14} have been carried out so far, and most of the studies in the field have been based on simulation results, some of them taking simplistic assumptions, e.g., ignoring the effect of the routing protocol. Although we acknowledge the importance of simulations in protocol design validation, it is our belief that our TCP implementation should be verified against real-environment measurements in order to gain a clear understanding of its behavior. For that purpose, we built a set of testbed scenarios and conditions against which the performance of the protocol could be evaluated.

Our analysis is focused in static networks with a chain topology and a limited number of hops deployed in an indoor scenario. The selection of an indoor scenario to set up our experimental testbed is motivated by the fact that it constitutes an inherently more predictable environment where undesirable multi-path signal propagation effects can be mitigated, thus simplifying in great manner the extraction of conclusions in the analytical evaluation process. In order to select the number of nodes to be used in the testbed, we decided to include enough devices to create interesting topologies where multi-hop behavior can be observed, while keeping the network size small enough to be easily manageable. Each node in the network makes use of TCP version to provide a reliable end-to-end connection oriented transmission service, with DSR being selected as the underlying routing protocol. The generation of data segments that would be originated by an upper application layer protocol was simulated by a traffic generator implemented by our team.

All our experiments were carried out in a seminar room of our institute at the Free University (FU) Berlin located amongst labs and classrooms. Furthermore, the hardware employed was the ScatterWeb Modular Sensor Board (MSB), designed at the FU Berlin, which features the 16-bit microcontroller MSP430F1612 from Texas Instruments and the broadcast-oriented radio transceiver Chipcon CC1020~\cite{11,12}. The transceiver transmission power was set to the minimum allowed value in order to to reduce the transmission range and make possible to deploy real multi-hop experiments in an indoor environment. The internodal distance was determined in all experiments in such a way that only adjancent nodes were within each other's transmission range.

We selected the Packet Delivery Ratio as main metric in our testbed, as we are interested in measuring both the correctness and completeness of our TCP protocol version. The Packet Delivery Ratio constitutes a highly significant performance metric because it provides a description of the loss rate that will be seen by the upper transport layers, which in last term affects the maximum throughput achievable by the network. The analysis of additional performance measures, such as the Routing Overhead generated by the protocol or the achieved Throughput, will be a subject of further study.

The main objective of the first experiment was to investigate the influence that additional traffic generated by the activity of the underlying transport protocol has over the packet loss rate. For that purpose, we deployed a single hop transmission scenario in which a sender and receiver wireless nodes were placed confronting each other. Two scenarios were considered: a protocol stack with TCP making use of the services provided by the underlying DSR routing protocol; and a more simplistic configuration in which the TCP data segments are transmitted by directly using the data link layer. The only parameter that was varied along the testbed experimentation process was the interval between successive packet transmissions (0.125-1000 ms), which directly defines the data rate at which traffic is generated by the application layer. For each protocol stack considered, the initiator node transmitted 500 packets of a fixed payload size (30 bytes) at a certain rate.

We expected that an increasingly higher intersegment interval would be reflected in a better behavior of the packet delivery ratio. As the traffic data rate decreases, so it does the overall congestion within the network, which in last term leads to a lower probability of collisions and therefore a higher expected number of successfully delivered data segments. It is to be expected as well that a number of data segments will be discarded as a consequence of Retransmission Buffer overflowing, such event be proportionally higher when the protocol is subjected to high workloads. As it was mentioned in section II, the Retransmission Buffer is defined in our TCP version as a static structure with a predefined limited number of entries. As a consequence of implementing a single-sized sliding window mechanism, the sender is limited to the transmission of a single data segment at a time. Therefore, once a segment transmission is performed, the successive data segments of the connection are directly stored in the buffer. In addition to this, it has been previously indicated that when the network congestion is increased there is a greater probability that a segment transmission fails. When a segment transmission isn't successfully performed, the data must be resent at the sender node, and in the meantime additional entries are stored in the Retransmission Buffer waiting for the previous segments to be acknowledged. We can conclude that as the probability of segment transmission failure increases, so it does the average lapse of time until the data entries are deleted from the Send Buffer, which in last term leads to frequent overflows in case the highest data rate is being used at the traffic generator.

The same reasoning applies when considering a protocol stack that includes DSR as intermediate routing layer with respect to a configuration that lacks of it. Given that the DSR version considered in our testbed does not implement a Route Cache, whenever a segment transmission is performed using the routing protocol service, a message exchange must take place in order to discover a route throughout the network -REQ/RSP packet in Route Discovery procedure- and then forward the data to the given destination node. Using DSR undoubtedly incurs in a much greater number of packets circulating throughout the network, which eventually leads to a much more congested network with higher packet collision probability. Therefore, it is to be expected that the achieved delivery ratio will be clearly higher in case of considering the simplistic protocol stack with direct MAC data transmission.
\begin{figure*}
\centering
\includegraphics[width= 12 cm]{Exp1}
\begin{center}
     \textbf{Figure III.} Packet Delivery Ratio as a function of the intersegment interval in single-hop scenario, protocol stack including/lacking DSR layer.
\end{center}
\end{figure*}

The experimental outcomes are aligned with our expectations (see Figure III). As it can be observed, the simplistic version of the protocol stack undoubtedly outperforms its counterpart when the transport protocol was confronted with the shortest periods between successive data segment transmissions -for intersegment intervals (ISI) lower than 600ms.
\begin{figure*}
\centering
\includegraphics[width= 12 cm]{Exp2}
\begin{center}
     \textbf{Figure IV.} TCP Packet Delivery Ratio as a function of number of hops with varying intersegment intervals
\end{center}
\end{figure*}
Whereas the implementation lacking the routing protocol layer was able to successfully deliver the total amount of data segments independently of the data rate at which these were generated, the performance of the four layered alternative was negatively influenced by the use of the highest data rates -with 73.4\%\ of the data segments being correctly transmitted using an ISI of 375ms, and approximately 50\%\ for the lowest ISI considered (125ms). As we previously pointed out, the main reason for such a degradation is the network congestion that results from the additional routing traffic generated by DSR in order to operate, which leads to a higher data loss probability due too collisions and Retransmission Buffer overflow.

During our first testbed we found that an unexpectedly high proportion of the data losses in the implementation integrating DSR were due to buffer overflow, rather than by segment collisions, especially when the lowest values for ISI were being used. Note that our current protocol stack requires the payload data coming from the application layer to be stored simultaneously in the temporary buffers utilized by TCP (Retransmission Buffer) and DSR (Send Buffer). With such a redundant data storage approach, our implementation utilizes the limited memory of the wireless devices in an inefficient way. As a consequence the maximum capacity available to temporary store the application data has to be reduced, thus increasing the probability that buffer overflows may occur. A possible solution to tackle this problem would be to implement a more efficient data structure to store the variables and information required by each one of the protocol layers, where a unique memory space can be accessed both by the routing and the transport protocol through the use of pointers -such an approach is the one followed to implement the TCP/IP stack in most current Linux distributions.

An additional possibility would be for TCP to implement the Retransmission Buffer as a dynamic structure where the entries are created as required during the communication process. The drawback of this solution is that it increases the complexity of the memory management processing within the wireless nodes, which usually present important storage capacity restrictions.

In order to determine the impact that the length of the route between sender and destination has on the TCP performance, we set up a second experiment considering a chain topology. For that purpose, a network comprising 4 wireless nodes was deployed, with each device being only able to directly communicate with its predecessor and successor neighbors within the chain. The experimental procedure undertaken was a follows: the number of hops between the initiator and the destination node was progressively increased through the addition of successive nodes. For each chain size -ranging from 1 to 4 hops- we confronted the protocol to different data rates by varying the utilized intersegment interval (0.125-750 ms). During each run, the network was subjected a workload of 500 data segments,  each carrying a pre-established payload data content -set to a value of 30 bytes-, which were to be transferred from the originator to the destination nodes -corresponding to the first and last devices of the chain, respectively.

As we pointed out in the experimental evaluation of DSR~\cite{7}, the proportion of packets that the routing protocol is able to successfully deliver follows an inverse quadratic relationship with the number of hops between sender and destination. This is explained by the fact that, as longer multi-hop scenarios with higher data rates are established, the transmission conditions to which the routing protocol is subjected become more demanding. By increasing the chain size, undesirable events such as fading or packet collisions might occur more frequently.  Additionally, we observed that the use of higher data rates leads in last term to performance degradation, as packet discards due to overflows in the Send Buffer become more often.  As a consequence, the probability that a failure takes place -either by increasing the chain size or the workload- gets higher, thus having a negative impact in the packet delivery ratio achieved by DSR. Therefore, it is to be expected that the poorer packet delivery ratio achieved by the underlying routing protocol under more demanding scenarios will incur in a degradation of the TCP performance.

Figure IV provides information relative to the packet delivery ratio achieved by the TCP protocol for the different number of hops and data rates considered in our experiment. The results obtained meet our expectations. As it can be observed, TCP shows clear performance degradation for increasingly higher chain size and workload values. More specifically, by comparing the results to the ones obtained when studying DSR performance, we can deduce that the existing inverse relationship between the packet delivery ratio and the route length follows a non-linear pattern very similar to the one indicated for the underlying DSR protocol.

The transport protocol performed well in the single-hop chain scenario, successfully transmitting 92\%\ of the segments when confronted to the highest data rate, and managing to deliver 100\%\ of the data segments in case the lower ISI values were utilized. However, we observe that the number of delivered segments rapidly decreases as the number of hops between sender and receiver is increased. Furthermore, for any considered chain size, TCP showed a poorer performance when confronted with lower spacing between consecutive segment transmissions. While in the two-hop chain scenario our transport protocol was able to transmit approximately 58\%\ of the packets using an ISI value of 750ms, only around 4\%\ were successfully delivered when the lowest intersegment period was utilized in the three-hop scenario was being considered. In fact, while running our experiments using the three-hop chain it was observed that in most of the cases -when the highest data rates were used- the TCP connections ended up abnormally before having transmitted all data segments. As it was previously, the data segment transmission failure rate -and consequently, the number of required successive data retransmissions- dramatically increases as length of the chain grows. Given that this multi-hop topology constitutes a more demanding transmission scenario, there is a high probability that a segment reaches the maximum number of retransmissions during the data transmission process, thus leading to the early termination of the TCP connection -as the transport protocol considers it unsuitable for any further data transmission.
\begin{figure*}
\centering
\includegraphics[width= 12 cm]{Exp3}
\begin{center}
     \textbf{Figure V.} Dropped segments due to Retransmission Buffer overflows as a function of number of hops with varying intersegment intervals
\end{center}
\end{figure*}
It is to be noted as well that a wide majority of the packet losses in the second experiment were related with Retransmission Buffer overflows. Figure V shows the number of segments that were directly discarded at the transport layer due to lack of available entries in the temporary transport protocol buffer. Actually, as it was expected, by comparing the results shown in Figures IV and V it is possible to remark a clear inverse relationship existing between the packet delivery ratio performance and the amount of buffer-overflow-related dropped segments. From the provided observations we can conclude that the size limitations present in the Retransmission Buffer constitute a critical issue that should be tackled in order to improve our transport protocol performance. Therefore, we believe that an increase in the maximum number of entries in the TCP temporary buffer -e.g. through the implementation of a more efficient data storage system- would have a noticeable positive impact in our TCP implementation performance.

Finally, we decided to run a third experiment in order to test the multiplexing functionality supported by our TCP version in a real environment. For that purpose, we deployed a network topology comprising three devices where each node was within each otherīs communication range, thus being able to directly exchange information without requiring any intermediate hops. As in the previous experiments, the delivery ratio was measured by generating a workload of 500 data packets of fixed payload size (30 bytes) transmitted from sender to destination. The only parameter that was varied along the experiment was the used ISI value in order to produce traffic with increasingly higher data rates. However, in this case we considered the scenario in which a single sender node establishes a simultaneous connection to the two remaining devices.
While running our experiment with the lowest considered data rate (ISI set to 1 segment/sec) we observed that our transport protocol version achieved remarkably poor segment delivery ratio results. Even when the data traffic was generated at a very low rate, TCP was capable of delivering a low fraction of the data segments before both connections had to be abnormally interrupted -after having reached the maximum number of allowed segment retransmissions. The utilization of lower intersegment intervals led to a collapse of our protocol performance in which TCP failed to successfully perform the connection establishment procedure in most of the cases. One of the main reasons for such clear performance degradation is the extremely high routing overhead generated by the underlying DSR version implemented in our protocol stack, which is reflected in an increased congestion of the shared wireless medium and in last term of the probability of collisions. As we indicated in its corresponding technical report~\cite{7}, the fact that our DSR version does not implement a Route Cache means that in most cases the routing protocol requires to start a Route Discovery whenever a data packet has to be transmitted. As a consequence, each segment transmission triggers a packet flooding procedure in the underlying layer that dramatically increases the number of routing messages circulating throughout the network. This additional routing traffic becomes a highly problematic issue in the considered scenario, where the simultaneous transmission of segments along two simultaneous connections leads to an almost continuous medium utilization where the segment transmission failure rate due to packet collisions become almost a certainty.  Therefore, it is to conclude from the obtained experimental results that the addition of a Route Cache to our DSR version constitutes a key future measure in order to improve the overall performance of our communication system.
