TCP performance over mobile ad hoc networks La ... - CiteSeerX

8 downloads 0 Views 278KB Size Report
Malgré son bon fonctionnement ... C'est dû `a ce que la supposition implicite de TCP affirmant ... Si le TCP interpr`ete de telles pertes comme étant de la congestion et qu'il appelle alors des procédures de contrôle de la congestion, il souffrira.
TCP performance over mobile ad hoc networks ´ La performance de TCP sur des reseaux mobiles ad hoc Xiang Chen, Hongqiang Zhai, Jianfeng Wang, and Yuguang Fang TCP is a transport protocol that guarantees reliable ordered delivery of data packets over wired networks. Although it is well tuned for wired networks, TCP performs poorly in mobile ad hoc networks (MANETs). This is because TCP’s implicit assumption that any packet loss is due to congestion is invalid in mobile ad hoc networks where wireless channel errors, link contention, mobility and multipath routing may significantly corrupt or disorder packet delivery. If TCP misinterprets such losses as congestion and consequently invokes congestion control procedures, it will suffer from performance degradation and unfairness. To understand TCP behaviour and improve the TCP performance over multi-hop ad hoc networks, considerable research has been carried out. As the research in this area is still active and many problems are still wide open, an in-depth and timely survey is needed. In this paper, the challenges imposed on the standard TCP in the wireless ad hoc network environment are first identified. Then some existing solutions are discussed according to their design philosophy. Finally, some suggestions regarding future research issues are presented. TCP est un protocole de transfert qui garantit une livraison fiable et ordonn´ee des paquets de donn´ees sur un r´eseau filaire. Malgr´e son bon fonctionnement sur ces r´eseaux, le TCP performe tr`es mal sur les r´eseaux mobiles ad hoc (MANETs). C’est dˆu a` ce que la supposition implicite de TCP affirmant que toute perte de paquet est caus´ee par la congestion est invalide dans les r´eseaux mobiles ad hoc o`u des erreurs dans le canal sans fil, le partage du lien entre plusieurs usagers, ainsi que le routage multi trajet et de mobilit´e peuvent corrompre de fac¸on significative ou mettre en d´esordre les paquets rec¸us. Si le TCP interpr`ete de telles pertes comme e´ tant de la congestion et qu’il appelle alors des proc´edures de contrˆole de la congestion, il souffrira d’une d´egradation de performance. Afin de comprendre le comportement du TCP et d’am´eliorer sa performance sur des r´eseaux multi sauts ad hoc, des recherches consid´erables ont e´ t´e effectu´ees. Puisque la recherche dans ce domaine est encore tr`es active et que plusieurs probl`emes sont encore non r´esolus, un aperc¸u d´etaill´e et opportun est n´ecessaire. Dans ce papier, les d´efis impos´es au TCP standard dans l’environnement d’un r´eseau sans fil ad hoc sont d’abord identifi´es. Ensuite, nous discutons de quelques solutions existantes selon leur philosophie de design. Finalement, quelques suggestions sur de futures questions de recherche sont pr´esent´ees. Keywords: congestion control, mobile ad hoc networks (MANETs), TCP

I. Introduction

Mobile ad hoc networks (MANETs) are suitable for applications in battlefield communications, disaster rescue, and inimical environment monitoring, where fixed wired infrastructure is unavailable. In most of these scenarios, reliable data transfer is required. It is well known that the transport control protocol (TCP) has been well tuned to provide such services in the traditional wired network environment. Due to its wide use in the Internet, it is desirable that TCP remain in use to provide reliable data delivery for communications within MANETs and for communications across MANETs and the Internet. In TCP, reliability is achieved by retransmitting lost packets. Thus, each TCP sender maintains a running average of the estimated roundtrip delay and the mean deviation derived from it. Packets are retransmitted if the sender receives no acknowledgement within a certain timeout interval (e.g., the sum of smoothed round-trip delay and four times the mean deviation) or receives duplicate acknowledgements. Due to the inherent reliability of wired networks, there is an implicit assumption made by TCP that any loss is due to congestion. To reduce congestion, TCP will invoke its congestion control mechanisms whenever any packet loss is detected.

poor performance if it still interprets such losses as congestions and consequently invokes congestion control and avoidance procedures, as confirmed through analysis and extensive simulations carried out in [1]–[6]. Based on these observations, several research works suggest that standard TCP, if no necessary changes are effected, is not appropriate for use in ad hoc networks [2]–[8]. In response to these MANET-specific challenges, many schemes have been proposed to improve TCP performance over MANETs. Based on their design philosophy, they can be classified into three groups. The first group of schemes incorporates network feedback information into its designs to modify TCP’s response to noncongestion-related packet losses, whereas the second group attempts to operate without requiring explicit feedback. Unlike the previous two, the third group starts by tuning the lower layers in order for TCP to operate normally, while leaving TCP intact. The rest of this paper is organized as follows. Section II categorizes the challenges that TCP is faced with in wireless ad hoc network environments. Some representative approaches to improving TCP performance over wireless ad hoc networks are classified and compared in Section III. We finally conclude with a discussion of future research issues in Section IV.

However, MANETs consisting of multi-hop wireless links suffer from packet losses due to error-prone wireless channels, media access control (MAC)–layer contention, and route breakages. TCP will yield

II. Challenges for TCP in MANETs

 Xiang Chen, Hongqiang Zhai, Jianfeng Wang, and Yuguang Fang are with Wireless Networks Laboratory (WINET), Department of Electrical and Computer Engineering, University of Florida, 446 & 481 Engineering Building, P.O. Box 116130, Gainesville, Florida 32611, U.S.A. E-mail: xchen, zhai@ecel.ufl.edu, [email protected], [email protected]

Unlike wired networks, mobile ad hoc networks have some unique characteristics that seriously deteriorate TCP performance. These characteristics include unpredictable wireless channels due to fading and interference, vulnerable shared media access due to random access col-

Can. J. Elect. Comput. Eng., Vol. 29, No. 1/2, January/April 2004

130

CAN. J. ELECT. COMPUT. ENG., VOL. 29, NO. 1/2, JANUARY/APRIL 2004 nel, the node has to back off for a random period of time and try again. After several failed tries, a route failure is reported. TCP may also encounter serious unfairness problems [2], [6], [10]– [11] for the following reasons: TCP flow 1

0

1

TCP flow 2

2

3

4

5

6

Figure 1: Node interference in a chain topology.

lision, the hidden terminal problem and the exposed terminal problem, and frequent route breakages due to node mobility. Undoubtedly, all of these pose great challenges to TCP in terms of its ability to provide reliable end-to-end communications in mobile ad hoc networks. From the point of view of layered network architecture, these challenges can be broken down into five categories, i.e., channel error, medium contention and collision, mobility, multipath routing, and congestion, whose adverse impacts on TCP are elaborated below in sequence. A. Channel error Bursty bit errors may corrupt packets in transmission, leading to the loss of TCP data packets or acknowledgements (ACKs). If it cannot receive the ACK within the retransmission timeout (RTO), the TCP sender immediately reduces its congestion window to one packet, exponentially backs off its retransmission, and retransmits the lost packet. Intermittent channel errors may thus cause the congestion window size at the sender to remain small, prompting low throughput. B. Medium contention and collision Contention-based medium access control schemes, such as the IEEE 802.11 MAC protocol [9], have been widely studied and incorporated into many wireless test beds and simulation packages for wireless multi-hop ad hoc networks, where the neighbouring nodes contend for the shared wireless channel before transmitting. There are three key problems, i.e., the hidden terminal problem, the exposed terminal problem, and unfairness. A hidden node is one that is within the interfering range of the intended receiver, but outside the sensing range of the transmitter. The receiver may not correctly receive the intended packet because of collision from the hidden node. An exposed node is one that is within the sensing range of the transmitter, but outside the interfering range of the receiver. Though its transmission does not interfere with the receiver, it could not start transmission because it senses a busy medium, which introduces spatial reuse inefficiency. The binary exponential backoff scheme always favours the latest successful transmitter and results in unfairness. These problems could be more harmful in multi-hop ad hoc networks than in wireless LAN because ad hoc networks are characterized by multi-hop connectivity. MAC protocols have been shown to significantly affect TCP performance [2], [5]–[6], [10]–[12]. When TCP runs over IEEE 802.11 MAC, as [6] pointed out, the instability problem becomes very serious. It is shown that collisions and the exposed terminal problem are two major factors that can prevent one node from reaching the other when the two nodes are in each other’s transmission range. If a node cannot reach its adjacent node after several tries, it will trigger a route failure, which in turn will cause the source node to start route discovery. Before a new route is found, no data packet can be sent out. During this process, the TCP sender has to wait and will invoke congestion control algorithms if it observes a timeout. Serious oscillation in TCP throughput will thus be observed. Moreover, the random backoff scheme used in the MAC layer exacerbates this behaviour [2]. Since large data-packet sizes and back-to-back packet transmissions both decrease the likelihood that the intermediate node will obtain the chan-

Topology causes unfairness because of unequal channel-access opportunity for different nodes. As shown in Fig. 1, where the small circle denotes a node’s valid transmission range and the large circle denotes a node’s interference range, all nodes in a seven-node chain topology experience different degrees of competition. There are two TCP flows, namely flow 1 from node 0 to node 1 and flow 2 from node 6 to node 2. The transmission from node 0 to node 1 experiences interference from three nodes, i.e., nodes 1, 2, and 3, while the transmission from node 3 to node 2 experiences interference from five nodes, i.e., nodes 0, 1, 2, 4, and 5. Flow 1 will obtain much higher throughput than flow 2 because of the unequal channel-access opportunity. The backoff mechanism in the MAC may lead to unfairness as it always favours the last successfully transmitting node. TCP flow length influences unfairness. A longer flow implies longer round-trip time and higher packet dropping probability, leading to lower and more fluctuating TCP end-to-end throughput. Through this chain reaction, unfairness is amplified, as high throughput will become higher and low throughput will become lower. C. Mobility Mobility may induce link breakage and route failure between two neighbouring nodes, as one mobile node moves out of the other’s transmission range. Link breakage in turn causes packet losses. As stated earlier, TCP cannot distinguish between packet losses due to route failures and packet losses due to congestion. Therefore, TCP congestion control mechanisms react adversely to such losses caused by route breakages [13]–[15]. Meanwhile, discovering a new route may take a significantly longer time than the TCP sender’s RTO. If route discovery time is longer than RTO, the TCP sender will invoke congestion control after timeout. The already-reduced throughput due to losses will further shrink. It could be even worse when the sender and the receiver of a TCP connection fall into different network partitions. In such a case, multiple consecutive RTO timeouts will lead to inactivity lasting for one or two minutes even if the sender and receiver finally become reconnected. Fu et al. conducted simulations considering mobility, channel error, and shared media-channel contention [4]. They indicated that mobility-induced network disconnections and reconnections have the most significant impact on TCP performance compared to channel error and shared media-channel contention. As mobility increases compared to a reference TCP, TCP NewReno suffers from a relative throughput drop ranging from close to % in a static case to  % in a highly mobile case (when moving speed is  m/s). In contrast, congestion and mild channel error (say %) have a less noticeable effect on TCP (with a performance drop of less than  % compared with the reference TCP). D. Multipath routing Routes are short-lived due to frequent link breakages. To reduce delay due to route recomputation, some routing protocols such as the temporally ordered routing algorithm (TORA) [16] maintain multiple routes between a sender-receiver pair and use multipath routing to transmit packets. In such a case, packets coming from different paths may not arrive at the receiver in order. Being unaware of multipath routing, the TCP receiver will misinterpret such out-of-order packet arrivals as congestion. The receiver will thus generate duplicate ACKs that cause the sender to invoke congestion control algorithms like fast retransmission (upon reception of three duplicate ACKs). E. Congestion It is known that TCP is an aggressive transport-layer protocol. Its attempt to fully utilize the network bandwidth can easily cause ad hoc

CHEN / ZHAI / WANG / FANG: TCP PERFORMANCE OVER MOBILE AD HOC NETWORKS networks to become congested. In addition, because of many factors such as route change and unpredictable variable MAC delay, the relationship between congestion window size and the tolerable data rate for a route is no longer maintained in ad hoc networks. The congestion window size computed for the old route may be too large for the newly found route, resulting in network congestion if the sender still transmits at the full rate allowed by the old congestion window size. Congestion/overload may give rise to buffer overflow and increased link contention, which degrades TCP performance. As a matter of fact, [17] showed that the capacity of wireless ad hoc networks decreases as traffic and/or competing nodes rise. F. Energy efficiency As power is limited at mobile nodes, any successful scheme must be designed to be energy efficient. In some scenarios where battery recharge is not allowed, energy efficiency is critical for prolonging network lifetime. In [18], the energy-consumption behaviour of three versions of TCP (Reno, Newreno, and SACK) was compared. The study in [19] showed that a tradeoff exists between the individual packet transmission energy and the likelihood of retransmission, which is tied to the session throughput. Therefore, future study of TCP over ad hoc networks will need to strike a balance between low energy consumption and high session throughput.

III. Current approaches to improving TCP performance in MANETs

Recently, several schemes have been proposed to improve TCP performance over mobile ad hoc networks. We classify the schemes into three groups, based on their fundamental philosophy: TCP with feedback [20]–[23], TCP without feedback [14], [24]–[25], and TCP with lower-layer enhancement [3], [12], [26]–[29]. Through the use of feedback information to signal non-congestion-related causes of packet losses, the feedback approaches help TCP distinguish between true network congestion and other problems such as channel errors, link contention, and route failures. On the other end of the solution spectrum, TCP-without-feedback approaches make TCP adapt to route changes without relying on feedback from the network, considering that feedback mechanisms may bring about additional complexity and cost in ad hoc networks. The third class of approaches, i.e., TCP with lower-layer enhancement, starts with the idea that the TCP sender should be shielded from any problems specific to ad hoc networks, while lower layers such as the routing layer and the MAC layer need to be tailored with TCP’s congestion control algorithms in mind. As expected, this idea guarantees that TCP end-to-end semantics is maintained for ad hoc networks to seamlessly internetwork with the wired Internet. In the following, we present some representative schemes according to the aforementioned taxonomy. Notice that in this paper we focus on how to improve TCP performance over ad hoc networks; therefore some schemes such as the ad hoc transport protocol (ATP) [7], which attempts to propose an entirely new transport-layer protocol, are not presented here, since they are not improvement schemes based on standard TCP. A. TCP with feedback 1. TCP-F In mobile ad hoc networks, topology may change rapidly due to the movement of mobile hosts (MHs). The frequent topology changes result in sudden packet losses and delays. TCP misinterprets such losses as congestion and invokes congestion control, leading to unnecessary retransmission and loss of throughput. To overcome this problem, TCP-feedback (TCP-F) [20] was proposed so that the sender can distinguish between route failure and network congestion. In this scheme, the sender is forced to stop transmission without reducing window size upon route failure. As soon as the connection is re-established, fast retransmission is enabled.

RFN

131

From SYN-RECVD

From SYN-SENT

Snooze

RRN or route failure timeout

Established

To FIN-WAIT_1 To CLOSE-WAIT

Figure 2: The TCP-F state machine [20].

TCP-F relies on the network layer at an intermediate node to detect the route failure due to the mobility of its downstream neighbour along the route. A sender can be in an active state or a snooze state. In the active state, the transport layer is controlled by the normal TCP. As soon as an intermediate node detects a broken route, it explicitly sends a route failure notification (RFN) packet to the sender and records this event. Upon reception of the RFN, the sender goes into the snooze state, in which the sender completely stops sending further packets and freezes all of its timers and the values of state variables such as RTO and congestion window size. Meanwhile, all upstream intermediate nodes that receive the RFN invalidate the particular route to avoid further packet losses. The sender remains in the snooze state until it is notified of the restoration of the route through a route re-establishment notification (RRN) packet from an intermediate node. Then it resumes the transmission from the frozen state. The state machine of TCP-F is shown in Fig. 2. 2. TCP-ELFN References [21] and [22] proposed another feedback-based technique, explicit link failure notification (ELFN). The goal is to inform the TCP sender of link and route failures so that it can avoid responding to the failures as if congestion had occurred. ELFN is based on the dynamic source routing (DSR) [30] protocol. To implement an ELFN message, the route failure message of DSR is modified to carry a payload similar to the “host unreachable” Internet control message protocol (ICMP) message. Upon receiving an ELFN, the TCP sender disables its congestion control mechanisms and enters into a “stand-by” mode, which is similar to the snooze state of TCP-F mentioned above. Unlike TCPF, which uses an explicit notice to signal that a new route has been found, TCP-ELFN requires the sender, while on stand-by, to periodically send a small packet to probe the network to see if a route has been established. If there is a new route, the sender leaves the stand-by mode, restores its RTO and continues as normal. Given that most of the popular routing protocols in ad hoc networks are on-demand and route discovery/rediscovery is event-driven, it is appropriate to periodically send a small packet from the sender to restore routes with mild overhead and without modification to the routing layer. Through explicit route failure notification, TCP-EFLN and TCP-F allow the sender to instantly enter snooze state and avoid unnecessary retransmissions and congestion control, both of which waste precious MH battery power and scarce bandwidth. With explicit route re-establishment notification from intermediate nodes or active route probing initiated at the sender, these two schemes enable the sender to resume fast transmission as soon as possible. However, neither of these two considers the effects of congestion, out-of-order packets, or bit errors, all of which are quite common in wireless ad hoc networks. In addition, both TCP-ELFN and TCP-F use the same parameter sets, including congestion window size and RTO, after re-establishment of routes as they do before the route failure; this may cause problems because congestion window size and RTO are route-specific. Using the same parameter sets helps little in approximating the available bandwidth of the new route if the route changes significantly.

132

CAN. J. ELECT. COMPUT. ENG., VOL. 29, NO. 1/2, JANUARY/APRIL 2004

Disconnected

Receive “Destination Unreachable” ICMP CWND 1

TCP sender put in persist state

TCP transmits a packet

Receive ECN

Congested

Receive dup ACK or packet from receiver

Normal

RTO about to expire OR 3 dup ACKs

New ACK

Loss

ATCP retransmits segments in TCP’s buffer

Figure 3: State transition diagram for ATCP at the sender [8].

3. ATCP Ad hoc TCP (ATCP) [8] also utilizes the network-layer feedback. The idea of this approach is to insert a thin layer called ATCP between IP and TCP, thus ensuring correct behaviour in the event of route failures as well as high bit error rate. The TCP sender can be put into a persist state, a congestion control state or a retransmit state, corresponding to the packet losses due to route breakage, true network congestion or high bit error rate, respectively. Note that unlike the previous two feedback-based approaches, ATCP also tackles packet corruption caused by channel errors. The sender can choose an appropriate state by learning the network state information through explicit congestion notification (ECN) messages and ICMP “destination unreachable” messages. The state transition diagram for ATCP at the sender is shown in Fig. 3. Upon receiving a “destination unreachable” message, the sender enters into the persist state. The TCP at the sender is frozen, and no packets are sent until a new route is found, so that the sender does not invoke congestion control. Upon receipt of an ECN, congestion control is invoked without waiting for a timeout event. If a packet loss occurs and the ECN flag is not set, ATCP assumes the loss is due to bit errors and simply retransmits the lost packet. In the case of multipath routing, upon receipt of duplicate ACKs, the TCP sender does not invoke congestion control, realizing that multipath routing shuffles the order in which packets are received. Thus ATCP works well when multipath routing is applied. ATCP is considered to be a more comprehensive approach than TCP-F and TCP-ELFN in that it accounts for more possible sources of deficiency, including bit errors and out-of-order delivery due to multipath routing. Through recomputation of congestion window size after each route re-establishment, ATCP may adapt to route changes. Another benefit of ATCP is that it is transparent to TCP, and hence nodes with and without ATCP can interoperate.

from routing protocols such as DSR. More precisely, the CWL should never exceed the RTHC of the path. The rationale behind this scheme is very simple, as shown in the following. It is known that to fully utilize the capacity of a network, a TCP flow should set its CWL to the bandwidth-delay product (BDP) of the current path, where a path’s BDP is defined as the product of the bottleneck bandwidth of the forward path and the packet transmission delay in a round trip. On the other hand, the CWL should never exceed the path’s BDP in order to avoid network congestion. In ad hoc networks, if we assume that the size of a data packet is and the bottleneck bandwidth along the forward and return paths is the same and equal to   , it can be easily seen that the delay at any hop along the path is less than the delay at the bottleneck link, i.e.,   . Since the size of a TCP acknowledgement is normally smaller than that of the data packet, according to the definition of the BDP, we know     . Therefore, the CWL, which is bounded by the path’s BDP, should never exceed the RTHC of the path. This upper bound can be further tightened when the IEEE 802.11 MAC–layer protocol is adopted. In fact, it is shown that, in a chain topology, a tighter upper bound exists, which is equal to approximately one fifth of the RTHC of the path. According to this tighter upper bound, the maximum RTO is set to a relatively small value of  s, which enables TCP to probe the route quickly should it break (due to false link failure). Simulation results showed that this simple but useful strategy is able to improve TCP-Reno performance by % to  % in a dynamic MANET. 2. TCP detection of out-of-order and response (TCP-DOOR) TCP-DOOR [25] attempts to improve TCP performance by detecting and responding to out-of-order (OOO) packet-delivery events and thus avoiding invocation of unnecessary congestion control. By definition, OOO occurs when a packet sent earlier arrives later than a subsequent packet. In ad hoc networks, OOO may happen multiple times in one TCP session because of route changes. In order to detect OOO, ordering information is added to TCP ACKs and TCP data packets. OOO detection is carried out at both ends: the sender detects the out-of-order ACK packets, and the receiver detects the out-of-order data packets. If the receiver detects OOO, it should notify the sender, given that it is the sender that initiates congestion control actions. Once the TCP sender knows of an OOO condition, it may take one of two responsive actions: temporarily disabling congestion control, and instant recovery during congestion avoidance. The first action means that, whenever an OOO condition is detected, the TCP sender will keep its state variables, such as RTO and the congestion window size, constant for a time period  . The second action means that if, during the past time period  , the TCP sender has already entered the state of congestion avoidance, it should recover immediately to the state prior to such congestion avoidance. The main reason for this is that the detection of an OOO condition implies that a route change event has just occurred.

In summary, as shown by the simulations, these feedback-based approaches improve TCP performance significantly while maintaining TCP’s congestion control behaviour and end-to-end TCP semantics. However, all these schemes require that the intermediate nodes have the capability of detecting and reporting network states such as link breakages and congestion. Enhancementat the transport layer, network layer, and link layer are all required. Further research on ways to detect and distinguish network states in the intermediate nodes is needed.

However, OOO can be detected only after a route has recovered from failures. As a result, TCP-DOOR is less accurate and responsive than a feedback-based approach that is able to determine whether congestion or route errors occur, and hence can report to the sender at the very beginning. Furthermore, it may not work well with multipath routing since multipath routing may cause OOO as well. Therefore, it is concluded that TCP-DOOR may work as an alternative to the feedback-based approach to improve TCP performance over an ad hoc network, if the latter is not available.

B. TCP without feedback 1. Adaptive congestion window limit setting Based on the observation that TCP’s congestion control algorithm often overshoots, leading to network overload and heavy contention at the MAC layer, Chen et al. [24] proposed an adaptive congestion window limit (CWL, measured in terms of the number of packets)–setting strategy to dynamically adjust the TCP’s CWL according to the current round-trip hop count (RTHC) of the path, which can be obtained

3. Fixed RTO In TCP congestion control, TCP doubles the RTO and retransmits the oldest unacknowledged packet when the retransmission timer expires. Although this exponential backoff mechanism of the RTO could handle network congestion gracefully, it is no longer suitable in MANETs when the loss of packets or ACKs is caused by temporary route breakages, as discussed earlier. In such a case, the RTO should be recalculated, if possible, according to the new route instead of being doubled.

CHEN / ZHAI / WANG / FANG: TCP PERFORMANCE OVER MOBILE AD HOC NETWORKS Furthermore, when the new route is established, the TCP sender should start the transmission immediately instead of waiting for the expiration of the retransmit timer. In the fixed RTO approach [14], no feedback from lower layers is needed. Rather, a heuristic is employed to distinguish route failures and congestion. When timeouts occur consecutively, i.e., an ACK is not received before the second RTO expires, the sender assumes that a route failure rather than network congestion has taken place. Therefore, the unacknowledged packet is retransmitted again without doubling of the RTO. The RTO remains fixed until the route is reestablished and the retransmitted packet is acknowledged. By adopting this strategy, the TCP sender avoids waiting for a long period of time before attempting to retransmit. This fast retransmission would force routing protocols, especially those like AODV [31] and DSR, to repair routes fast, which in turn would lead to a large congestion window on average and high TCP throughput. Actually, this technique complements TCP-DOOR. C. TCP with lower-layer enhancement 1. Routing-layer enhancement In [26], Anantharaman et al. presented a framework termed Atra to improve TCP performance over ad hoc networks by enhancing routing layers. Three mechanisms, called symmetric route pinning (SRP), route failure prediction (RFP) and proactive route error (PRE), were introduced to minimize the probability of route failures, to predict route failures in advance, and to minimize the latency in conveying route failure information to source, respectively. Since an asymmetric path would increase the probability of route failure for a connection, in the first mechanism, the ACK path of a TCP connection is always kept the same as the data path. Based on the progression of signal strengths of packet receptions from the concerned neighbour, the second mechanism enables the node to predict the occurrence of link failure more accurately. Finally, with PRE, when a link failure is detected, all sources that have used the link within a certain time period are informed of the link failure. This reduces the latency involved in the route failure information delivery and consequently reduces the number of packet losses, as well as triggering early alternate route computations. 2. Link-layer enhancement Fu et al. [3] discussed the interaction between TCP and IEEE 802.11 MAC. Their studies reveal two interesting results. First, given a specific network topology and flow pattern, there exists a TCP window size, say   , at which TCP throughput is maximized, since the best spatial reuse can be achieved; further increasing the window size will reduce throughput. However, the standard TCP protocol does not operate around   ; typically the average window size is much larger than   . As a result, TCP experiences throughput reduction due to reduced spatial reuse and increased packet loss. In the simulated scenarios, throughput reductions ranging from % to % of maximum throughput were observed. Second, most packet drops experienced by TCP are not due to buffer overflow, but rather to link-layer contention that is incurred by hidden terminals. Reference [3] showed that contention drops exhibit a load-sensitive loss feature: as the injected TCP packets exceed   and further increase, the link dropping probability becomes non-negligible and increases accordingly; after the injected TCP packets exceed another threshold  , the link dropping probability saturates and flattens out. It turns out that the link-layer dropping probability is not significant enough to make the average TCP window oscillate around   ; this circumstance subsequently leads to suboptimal TCP throughput. Therefore, two link-layer techniques were proposed in [3] to improve TCP efficiency: a link random early detection (Link-RED) algorithm to tune the wireless link’s packet dropping probability, and an adaptive link-layer pacing scheme to reduce the medium contention. The Link-RED algorithm attempts to maintain the optimum congestion window size at the TCP sender. At the link layer each node measures the average number of retries for recent packet transmissions. Normally, when the TCP sender increases the congestion window size and injects more packets into the network, this average number will increase, as more packets will aggravate medium contention. The head-

133

of-line packet is dropped from the buffer or marked as congested with a probability that is calculated based on this average number. Once it detects packet losses or the congestion flag in the ACKs, the TCP sender invokes the congestion control algorithm that could help maintain the congestion window size around the optimum value and hence improve TCP’s throughput. The goal of adaptive link-layer pacing is to alleviate the medium contention, especially when the congestion window size exceeds the optimum value. It is enabled from within the Link-RED algorithm. When a node (which is just sending a packet) notices that its average number of retries is below a predefined threshold, it calculates its backoff time as usual. Otherwise, it increases the backoff period by an interval equal to the transmission time of the previous data packet, and backs off accordingly. 3. Neighbourhood RED As described in the previous subsection on challenges, TCP exhibits serious unfairness in ad hoc networks as a result of the combination of MAC-inherent problems such as medium contention, the hidden terminal problem, and the exposed terminal problem. As these problems are likely to exist in nodes which are located in a neighbourhood, Xu et al. [27] proposed a scheme named neighbourhood random early detection (NRED) that seeks to improve TCP fairness from the point of view of a neighbourhood. By definition, a node’s neighbourhood consists of the node itself and the nodes which can interfere with this node’s signal. To make things simpler, a node’s neighbourhood as considered in the scheme comprises the node itself and its one-hop and two-hop neighbours. The key idea of NRED is that each node forms a distributed neighbourhood queue based on the individual queues maintained at every node located in the node’s neighbourhood, and the RED scheme can be applied to the distributed queue to address the fairness issue, as has been done effectively in wired networks to improve fairness among TCP flows by controlling average queue size at routers. The NRED scheme boils down to three algorithms, namely, neighbourhood congestion detection (NCD), neighbourhood congestion notification (NCN), and distributed neighbourhood packet drop (DNCP). Instead of counting on each node to actively advertise its own queue size information and then measuring the neighbourhood queue size (a task which may cause a large amount of overhead or even aggravate congestion), NCD intelligently gets around the difficult task by monitoring channel utilization. Normally, channel utilization can serve as an indicator of the queue size, based on the observation that channel utilization around a node is likely to increase when the queues at its neighbouring nodes build up. An early congestion is assumed to take place as the channel utilization exceeds a certain threshold. If congestion is detected, the node will calculate the packet dropping probability and send it in an NCN packet to its neighbours, provided that certain conditions are met in order to avoid “overreaction.” The neighbours, upon the reception of such notification, will drop some packets according to DNCP. Simulation studies show that the NRED scheme can improve TCP fairness to some extent in ad hoc networks. However, the price paid is that the aggregate throughput in the network is actually reduced, which shows that there is room for further improvement. It is noteworthy that, besides the schemes described above, there are also some other IEEE 802.11 MAC–based TCP enhancement schemes, such as DCF+ [12], AEDCF [28], and the non-workconserving scheduling algorithm [29]. By modifying the MAC protocol, these schemes are shown to improve TCP throughput or fairness to some degree. IV. Conclusions and future research In this paper, we presented a brief survey of the challenges TCP has encountered in MANETs and recent efforts to improve its performance.

134

CAN. J. ELECT. COMPUT. ENG., VOL. 29, NO. 1/2, JANUARY/APRIL 2004

Because of certain inherent characteristics of MANETs, including time-varying wireless channels, medium collision, and mobility, traditional TCP, which performs well in fixed wired networks, suffers from severe performance degradation in wireless networks. Because the assumption made by TCP that any packet loss is due to network congestion is not valid in ad hoc networks, either TCP should be capable of distinguishing various reasons for packet losses, or such non-congestion-related losses should be reduced. To enable TCP to identify various causes of packet losses, there are largely two approaches, depending on whether or not network feedback information is used. Feedback-based schemes seem to be able to react more quickly to non-congestion-related packet losses, and thus to be more effective in enhancing TCP performance. However, the price to be paid is that they are more difficult to implement, since they require end nodes and intermediate nodes to cooperate with each other. On the other hand, approaches without feedback are relatively simple to implement. However, the performance gain may not be high enough. Meanwhile, some solutions based on enhancing the link layer and routing layer provide insights into how to reduce non-congestionrelated losses in order to improve TCP’s performance. At the routing layer, in an effort to help TCP avoid unnecessary congestion control, some schemes have been proposed to reduce the negative impact of mobility by minimizing the probability of route failures and the latency in routing re-establishment. At the link layer, there are a few algorithms attempting to reduce the contention at the MAC layer and achieve less packet loss due to medium contention. Although some encouraging improvements have been reported by employing the proposed schemes, none of them work well in all scenarios and meet all the challenges mentioned. Therefore, there is still much work to do in the near future. To serve as guidance for future research, some critical issues regarding improving TCP performance and fairness are identified as follows. A. TCP fairness In light of the considerable effort made to improve TCP end-to-end throughput, fairness is a critical issue that definitely deserves more attention. It has been shown that in a mobile network with multiple flows, the throughput can be significantly different among competing flows. This variance is particularly evident when comparing flows of short paths to those of long paths. It is crucial for every flow to fairly share the network resource in ad hoc networks, as the network capacity is so limited compared with its counterpart in wired networks. Although fairness is touched upon in a few existing schemes, a more mature approach is highly anticipated. B. Compatibility with the wired Internet For the purpose of internetworking with the wired Internet, as will be required in future pervasive mobile computing, whatever TCP is designed for ad hoc networks should be fully compatible with the Internet. This quest for compatibility translates into two requirements for future research. First, TCP’s end-to-end semantics must be maintained. Second, TCP performance should be considered when TCP connections span both the wired networks and mobile ad hoc networks. C. Cross-layer solution Although layered network architecture brings a myriad of advantages, the layered design approach is inefficient for wireless networks because there is a strong interconnection between layers in wireless networks. Cross-layer design, where higher layers share the physical- and MAC-layer knowledge of the wireless medium, thus becomes promising for more efficient network resource utilization and better qualityof-service provisioning [32]. To completely tackle TCP performance degradation over ad hoc networks, we believe the cross-layer approach is worth exploring, as is evident since the causes for performance degradation lie in the physical layer, the MAC layer, and the routing layer.

References [1] H. Balakrishnan, V. Padmanabhan,S. Seshan, and R. Katz, “A comparison of mechanisms for improving TCP performance over wireless links,” in Proc. ACM SIGCOMM’96, Aug. 1996. [2] M. Gerla, R. Bagrodia, L. Zhang, K. Tang, and L. Wang, “TCP over wireless multihop protocols: Simulation and experiments,” in Proc. IEEE ICC’99, Vancouver, B.C., June 1999. [3] Z. Fu, P. Zerfos, H. Luo, S. Lu, L. Zhang, and M. Gerla, “The impact of multihop wireless channel on TCP throughput and loss,” in Proc. IEEE INFOCOM’03, San Francisco, Calif., Mar. 2003. [4] Z. Fu, X. Meng, and S. Lu, “How bad TCP can perform in mobile ad-hoc networks,” in Proc. IEEE Symp. Computers and Commun., Italy, July 2002. [5] M. Gerla, K. Tang, and R. Bagrodia, “TCP performance in wireless multihop networks,” in Proc. IEEE WMCSA’99, New Orleans, La., Feb. 1999. [6] S. Xu and T. Saadawi, “Does the IEEE 802.11 MAC protocol work well in multihop wireless ad hoc networks?” IEEE Commun. Mag., vol. 39, no. 6, June 2001, pp. 130–137. [7] K. Sundaresan, V. Anantharaman, H.-Y. Hsieh, and R. Sivakumar, “ATP: A reliable transport protocol for ad-hoc networks,” in Proc. ACM Mobihoc, June 2003. [8] J. Liu and S. Singh, “ATCP: TCP for mobile ad hoc networks,” IEEE J. Select. Areas Commun., vol. 19, no. 7, July 2001, pp. 1300–1315. [9] IEEE, “IEEE 802.11 wireless LAN medium access control (MAC) and physical layer (PHY) specifications,” IEEE, 1999. [10] K. Tang and M. Gerla, “Fair sharing of MAC under TCP in wireless ad hoc networks,” in Proc. IEEE MMT’99, Venice, Italy, Oct. 1999. [11] E. Royer, S. J. Lee, and C. Perkins, “The effects of MAC protocols on ad hoc network communication,” in Proc. IEEE WCNC, Chicago, Ill., Sept. 2000. [12] H. Wu, Y. Peng, K. Long, S. Cheng, and J. Ma, “Performance of reliable transport protocol over IEEE 802.11 wireless LAN: Analysis and enhancement,” in Proc. IEEE INFOCOM 2002, 2002. [13] A. Ahuja, S. Agarwal, J.P. Singh, and R. Shorey, “Performance of TCP over different routing protocols in mobile ad-hoc networks,” in Proc. IEEE Veh. Technol. Conf. 2000, vol. 3, Tokyo, Japan, 2000, pp. 2315–2319. [14] T.D. Dyer and R.V. Boppana, “A comparison of TCP performance over three routing protocols for mobile ad hoc networks,” in Proc. ACM Mobihoc, Oct. 2001. [15] D-K. Kim, C.-K. Toh, and Y. Choi, “TCP-BuS: Improving TCP performance over wireless ad hoc networks,” IEEE Comsoc J. Commun. Networks., vol. 3, no. 2, June 2001, pp. 1–12. [16] V.D. Park and M.S. Corson, “A highly adaptive distributed routing algorithm for mobile wireless networks,” in Proc. IEEE INFOCOM, Kobe, Japan, Apr. 1997. [17] J. Li, C. Blake, D.S.J. De Couto, H. Lee, and R. Morris, “Capacity of ad hoc wireless networks,” in Proc. ACM MobiCom’01, Rome, Italy, July 2001. [18] H. Singh and S. Singh, “Energy consumption of TCP Reno, Newreno, and SACK in multi-hop wireless networks,” in Proc. ACM SIGMETRICS’02, July 2002. [19] I. Ali, R. Gupta, S. Bansal, A. Misra, A. Razdan, and R. Shorey, “Energy efficiency and throughput for TCP traffic in multi-hop wireless networks,” in Proc. IEEE INFOCOM’02, New York, 2002. [20] K. Chandran, S. Raghunathan, S. Venkatesan, and R. Prakash, “A feedback-based scheme for improving TCP performance in ad hoc wireless networks,” IEEE Pers. Commun., vol. 8, no. 1, Feb. 2001, pp. 34–39. [21] G. Holland and N.H. Vaidya, “Analysis of TCP performance over mobile ad hoc networks,” in Proc. ACM MOBICOM’99, Seattle, Wash., Aug. 1999. [22] J.P. Monks, P. Sinha, and V. Bharghavan, “Limitations of TCP-ELFN for ad hoc networks,” in Proc. MOMUC 2000, 2002. [23] Z. Fu, B. Greenstein, X. Meng, and S. Lu, “Design and implementation of a TCPfriendly transport protocol for ad hoc wireless networks,” in Proc. IEEE ICNP’02, Nov. 2002. [24] K. Chen, Y. Xue, and K. Nahrstedt, “On setting TCP’s congestion window limit in mobile ad hoc networks,” in Proc. IEEE ICC’03, Anchorage, Ala., May 2003. [25] F. Wang and Y. Zhang, “Improving TCP performance over mobile ad-hoc networks with out-of-order detection and response,” in Proc. ACM Mobihoc’02, Lausanne, Switzerland, June 2002, pp. 217–225. [26] V. Anantharaman, S.-J. Park, K. Sundaresan, and R. Sivakumar, “TCP performance over mobile ad-hoc networks: A quantitative study,” to appear in Wireless Commun. and Mobile Comput. J., special issue on performance evaluation of wireless networks, 2004. [27] K. Xu, M. Gerla, L. Qi, and Y. Shu, “Enhancing TCP fairness in ad hoc wireless networks using neighborhood RED,” in Proc. ACM MobiCom’03, Sept. 2003. [28] L. Romdhani, Q. Ni, and T. Turletti, “The effects of MAC protocols on ad hoc network communication,” in Proc. IEEE WCNC 2003, 2003. [29] L. Yang, W.K.G. Seah, and Q. Yin, “Improving fairness among TCP flows crossing wireless ad hoc and wired networks,” in Proc. ACM Mobihoc’03, June 2003. [30] D.B. Johnson, D.A. Maltz, and Y. Hu, “The dynamic source routing protocol for mobile ad hoc networks” [online], IETF Internet draft, Apr. 15, 2003, available from World Wide Web: http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr08.txt . [31] C.E. Perkins, E.M. Belding-Royer, and S. Das, “Ad hoc on demand distance vector (AODV) routing,” IETF RFC 3561.



[32] S. Shakkottai, T.S. Rappaport, and P.C. Karlsson, “Cross-layer design for wireless networks,” IEEE Commun. Mag., vol. 41, no. 18, Oct. 2003, pp. 74–80.