A microscopic analysis of TCP performance over wireless ad-hoc networks

• Authors: Vaidyanathan Anantharaman;Raghupathy Sivakumar
• Venue: SIGMETRICS '02 Proceedings of the 2002 ACM SIGMETRICS international conference on Measurement and modeling of computer systems
• Year: 2002

Ad-hoc networks are multi-hop wireless networks that can operate without the services of an established backbone infrastructure. While such networks have obvious applications in the military and disaster relief environments, more recent works that have motivated their use even in regular wireless packet data networks have increased their significance. The focus of this paper is to study the performance of the TCP transport layer protocol over ad-hoc networks.Recent works in transport protocols for ad-hoc networks have investigated the impact of ad-hoc network characteristics on TCP's performance, and proposed schemes that help TCP overcome the negative impact of such characteristics as random wireless loss and mobility. The primary mechanism proposed involves sending an explicit link failure notification (ELFN) to the source from the point of link failure. The source, upon receiving the ELFN freezes TCP's timers and state, re-computes a new route to the destination, and either releases the timers and state or re-starts them from their respective initial values. While the goal of ELFN based approaches is to prevent the route disruption time from adversely impacting TCP's performance, in this paper we contend that there are several other factors that influence TCP's performance degradation. We briefly outline the different factors below:• TCP Losses: Every route failure induces upto a TCP-window worth of packet losses. While the losses have an absolute impact on the performance degradation, the TCP source also reacts to the losses by reducing the size of its window. Note that ELFN will prevent this negative impact on TCP's performance by appropriately freezing TCP's state.• MAC Failure Detection Time: Since the MAC layer (802.11) has to go through multiple retransmissions before concluding link failure, there is a distinct component associated with the time taken to actually detect link failure since the occurrence of the failure. Importantly, the detection time increases with increasing load in the network. While an external mechanism to detect link failures (e.g. through periodic beacones at the routing layer) would solve this problem, it comes at the cost of beacon overheads and associated trade-offs.• MAC Packet Arrival: When a failure is detected as described above, the link failure indication is sent only to the source of the packet that triggered the detection. If another source is using the same link in the path to its destination, the node upstream of the link failure will wait until it receives a packet from that source before informing it of the link failure. This also contributes to the magnitude of the delay after which a source realizes that a path is broken.• Route Computation Time: Once a source is informed of a path failure, the time taken to recompute the route also increases with increasing load. With ELFN, for a load of 25 connections, the per-flow average of the aggregate time spent in route computation during a 100 second simulation was as high as 15 seconds. In addition to the absolute impact of the idle periods, TCP is also likely to experience timeouts, especially in the heavily loaded scenarios where the route computation time can be high.In the next section, we present a framework of mechanisms called Atra targeted toward addressing each of the above components. We show through representative simulation results that the proposed mechanisms outperform both the default protocol stack and an ELFN-enabled protocol stack substantially. We assume the default protocol stack to comprise of the IEEE 802.11 MAC protocol, the Dynamic Source Routing (DSR) routing protocol, and TCP-NewReno as the transport layer protocol. For a more detailed analysis of TCP performance in mobile ad-hoc networks, and description of the Atra framework, please see [1].