TCP with delayed ack for wireless networks


Published on

TCP with delayed ack for wireless networks

Published in: Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

TCP with delayed ack for wireless networks

  1. 1. Available online at Ad Hoc Networks 6 (2008) 1098–1116 TCP with delayed ack for wireless networks Jiwei Chen *, Mario Gerla, Yeng Zhong Lee, M.Y. Sanadidi University of California, Los Angeles, CA 90095, United States Received 5 May 2006; received in revised form 25 October 2007; accepted 30 October 2007 Available online 6 November 2007Abstract This paper studies the TCP performance with delayed ack in wireless networks (including ad hoc and WLANs) whichuse IEEE 802.11 MAC protocol as the underlying medium access control. Our analysis and simulations show that TCPthroughput does not always benefit from an unrestricted delay policy. In fact, for a given topology and flow pattern, thereexists an optimal delay window size at the receiver that produces best TCP throughput. If the window is set too small, thereceiver generates too many acks and causes channel contention; on the other hand, if the window is set too high, the bur-sty transmission at the sender triggered by large cumulative acks will induce interference and packet losses, thus degradingthe throughout. In wireless networks, packet losses are also related to the length of TCP path; when traveling through alonger path, a packet is more likely to suffer interference. Therefore, path length is an important factor to consider whenchoosing appropriate delay window sizes. In this paper, we first propose an adaptive delayed ack mechanism which is suit-able for ad hoc networks, then we propose a more general adaptive delayed ack scheme for ad hoc and hybrid networks.The simulation results show that our schemes can effectively improve TCP throughput by up to 25% in static networks, andprovide more significant gain in mobile networks. The proposed schemes are simple and easy to deploy. The real testbedexperiments are also presented to verify our approaches. Furthermore, a simple and effective receiver-side probe and detec-tion is proposed to improve friendliness between the standard TCP and our proposed TCP with adaptive delayed ack.Ó 2007 Elsevier B.V. All rights reserved.Keywords: TCP; Congestion control; Adaptive delayed ack; Wireless medium access/contention; Friendliness1. Introduction networks, several other inherent factors attribute to the TCP performance deterioration, including The Transport Control Protocol (TCP) is the unpredictable channel errors, medium access con-most widely used reliable transport protocol over tention complicated by hidden/exposed terminalthe Internet. TCP was originally designed for wired problems, and frequent route breakages caused bylinks where buffer overflows account for most node mobility. All these factors pose great chal-packet losses. However, in multihop ad hoc wireless lenges to the design of TCP protocols to provide efficient and reliable end-to-end communications. * Many researchers have made valiant effort to pro- Corresponding author. E-mail addresses: (J. Chen), gerla@cs. pose various methods to make TCP survive in (M. Gerla), (Y.Z. Lee), medy@cs. challenging environments. In this paper, we (M.Y. Sanadidi). on studying the effect of delayed acks on TCP1570-8705/$ - see front matter Ó 2007 Elsevier B.V. All rights reserved.doi:10.1016/j.adhoc.2007.10.004
  2. 2. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1099performance. Then based on our findings, we pro- in turn causes severe packet interference with eachpose adaptive schemes that address the aforemen- other. When packet loss rate becomes high, thetioned factors effectively. benefit of delaying acks, via reducing ack packets, In standard TCP the receiver generates one ack disappears. Consequently, TCP performancefor each data packet, or more popularly, two in- degrades after reaching the peak at the optimalorder data packets with the standard delayed ack delay window size.option [1]. This mechanism works well in wired net- Armed with the deep understanding of delayedworks. In multihop wireless networks, however, this ack impact on TCP performance over multihopmechanism can be further improved due to: wireless links, we propose an adaptive scheme based on the hop count of a TCP path. The basic idea• Since the data and ack packets usually take the behind this scheme is, for a short path where inter- same route (or spatially close routes), they inter- ference problem is minimal, we delay the ack as fere with each other. The interference increases much as possible to maximally improve TCP with the number of acks generated. throughput; while for a long path, we apply an• Generating acks wastes scarce wireless resources. appropriate delay window size restriction to avoid Though acks are essential to provide reliability, high packet loss to achieve optimal TCP perfor- generating more acks than necessary is not desir- mance. Furthermore, we propose an end-to-end able in wireless networks. Ideally, the receiver delay based scheme tailored for hybrid wired/wire- should generate minimal number of acks less networks. These two schemes can be deployed required for reliable data recovery. separately, but are also compatible with each other to provide better performance in heterogenous net- Recently, the delayed ack strategy has been stud- works. It is also worth noting that our proposedied to improve TCP performance [2,3]. However, schemes only reside in transport layers at the endthis field is not fully exploited and many issues hosts, thus no modification on intermediate nodesremain unsolved. Some important questions is needed.include: what is the relation between delayed acks However, TCP with untraditional delayed ackand TCP performance, how to choose the proper (with delay window larger than 2) would causedelay window (the number of in-order data packets friendliness to the standard TCP. Since TCP senderto be waited for before generating an ack) for TCP, increases the congestion window (cwnd) by usuallyand how to deal with the loss of acks in multihop counting the number of acks received in the currentwireless networks. In this paper we carry out a sys- popular implementations, the TCP with untradi-tematic study to understand the effect of delayed tional delayed ack is slower in increasing the cwndacks on TCP over wireless links. We investigate than the standard TCP. If they coexist, the TCPTCP performance and delayed ack related packet with untraditional delayed ack would not get fairloss characteristics, under various wireless network share with the standard TCP. The unfriendlinessscenarios and flow patterns. problem was largely avoided in previous research Our objective is to clearly identify the relation- and stays unsolved. In the paper, we address theship between TCP throughput and delayed ack over problem with a simple and intelligent end-to-endmultihop wireless links. We reveal several interest- receiver-side detection mechanism. If the receivering findings, which are tremendously beneficial to detects other competing traffic, it switches to thedeeply understand TCP behavior in wireless multi- standard TCP, and vice versa. With this adaptivehop networks, and to design enhanced TCP proto- switching scheme, the friendliness of the standardcols. First, we found that TCP does not always TCP and our proposed adaptive delayed ack schemebenefit from arbitrary delaying of acks. In fact, for is significantly improved.a given network topology and flow pattern, there Another challenge for TCP with adaptiveexists an optimal delay window size at the receiver, delayed ack comes from mobile ad hoc which TCP achieves maximum throughput. Sec- Although delayed acks may potentially improveond, since 802.11 does not guarantee collision free TCP throughput regardless of underlying routingpacket transmission, a packet is more likely to be protocols. Different routing mechanisms, however,interfered with when going through a long path. If have great impact on TCP performance [4], and toa large delay window is used over a long path, it what degree delayed acks can benefit TCP perfor-causes large bursts of packets in transit, and this mance. The problem of more packet losses due to
  3. 3. 1100 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116mobility could have more impact on TCP with than the transmission range, request-to-send (RTS)untraditional delayed ack since fewer acks are gen- and clear-to-send (CTS) in 802.11 MAC cannoterated. In this paper, we investigate the TCP-DCA ensure collision free transfer of packets. This causes(Delayed Cumulative Ack) which addresses the hidden/exposed terminals leading to packet loss inack loss issue in mobile networks. Meanwhile, the ad hoc multihop wireless paths [8]. Many researchperformance of various TCP schemes are presented efforts have been made to adapt TCP to the uniqueover popular ad hoc routing protocols, namely, Ad- characteristic of wireless ad hoc network, e.g.Hoc On-Demand Distance Vector Routing Transport layer ‘‘Fixed RTO’’ in [4], delayed ack(AODV) [5], Dynamic Source Routing [6] and in [2,3], network layer support [9–11] and evenGreedy Perimeter Stateless Routing (GPSR) [7]. lower-layer assistance, for example, MAC supportThe reason we include GPSR in our study is that in [8].Geo-routing is a recently developed routing scheme Although a TCP ack packet is small, typicallypromising to be scalable, and robust to node 40 bytes, the transmission of TCP ack packetsmobility. may require the same overhead as that of data pack- While our work shares the common concept with ets in 802.11 MAC depending on the RTS thresh-previous research in that the TCP receiver delays old. If interference from TCP acks could beack up to a certain number of data packets, we reduced, data packets would suffer less collisionsundergo a more complete and optimized study to resulting in higher throughput. Several approachesunderstand the delayed ack impact and propose to delay acks have been proposed [2,3,12]. TCP-more effective solutions suitable for various scenar- ADA (Adaptive Delayed Ack) [12] proposed toios. To the best of our knowledge, our proposed decrease the number of acks to improve TCP per-schemes are the first existing mechanisms suitable formance. They claimed that maximum TCPfor both static/mobile wireless and hybrid networks, throughput is achieved when one ack acknowledgesand taking the ack loss and friendliness into account the full cwnd. However, the scheme did not addressas well. several important issues, such as packet loss and The remainder of this paper is organized as fol- out-of-order packet reception. In fact, as we willlows. Background work is provided in Section 2. show in this paper, TCP does not always benefitA thorough study of delayed ack impact on TCP from delaying ack as much as possible.performance is presented in Section 3 under various Altman and Jimenez [2] presented a basic delayednetwork topologies and traffic patterns. We present ack scheme which was further improved in [3] whereour adaptive delayed ack (TCP-DCA) scheme in TCP-DAA (Dynamic Adaptive Acknowledgement)Section 4. The issue of the loss of ack packets is dis- was proposed. In TCP-DAA, the receiver adjustscussed. Section 5 evaluates TCP-DCA on static and the delay window according to the channel condi-mobile ad hoc networks, and hybrid wired/wireless tion (packet loss event). A TCP-DAA receivernetworks as well. Several enhancements are pre- delays acking until it receives a certain number ofsented to improve TCP-DCA’s efficiency and data packets, ranging from 2 to 4 packets. Whenfriendliness. Section 6 discusses a few issues to fur- there is no packet loss, the TCP-DAA receiver waitsther improve TCP with untraditional delayed ack. for more data packets (up to 4) before generating anWe conclude the paper in Section 7. The impact of ack, but reduces the number to 2 in case of out-of-different routing protocols on TCP is also consid- order packet arrival. However, since a TCP senderered in proper sections. automatically cuts the cwnd when packet loss occurs, i.e. automatically adapting to the channel2. Related work state at the sender side, the receiver side adaptation provides little extra improvement. We will show The standard TCP assumes that a packet loss is that in our adaptive delayed ack scheme, the recei-invariably due to buffer overflow and reduces the ver does not respond dynamically to packet loss,cwnd by half when packet loss happens. However, yet achieves better ad hoc network, packet loss caused by buffer In [3], the ack time is set to be one average packetoverflow is rare. Instead, it is more likely due to inter-arrival time. That is, an ack is generated whenmedium contention as shown in [8]. The fundamen- no data packet arrives after one average packettal problem resides in the limitations of IEEE 802.11 inter-arrival time since last unacknowledged dataMAC. Since the interference range is usually longer packet. In wireless networks, the inter-arrival time
  4. 4. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1101is highly variable due to random MAC contention for further improvement. As it is a primarily recei-and back-off, so it is very difficult to get accurate ver-side modification, it could be combined withenough statistics in a complex large system. Another other sender-side schemes or low layer approaches.impact of this timer implementation is that the For example, at sender-side, [15] studied the perfor-receiver operates insensitively to the number of acks mance of TCP on three different routing protocols(2–4) to be delayed because any unexpected extra and proposed a TCP modification called fixeddelayed data packet will trigger an ack. RTO, which essentially freezes the TCP RTO value An important aspect of TCP with untraditional whenever there is a route loss. Recent work [9–11]delayed ack is the delay window size selection. In are approaches at the network layer. ChandranTCP-DAA [3], the receiver may delay up to four et al. [9] discussed a mechanism called TCP-Feed-ack packets and this number is limited by the sender back, which uses route failure and re-establishmentcwnd, which is fixed at four packets. The similar notifications to provide feedback to TCP, and thusdelay window size of 3–4 packets is also picked in reduce the number of packet retransmissions and[2] heuristically. There are issues in this scheme that TCP back-offs during route calculation, to improvedesires further clarification and improvement. First, throughput. Holland and Vaidya [10] evaluated analthough a small cwnd limit helps TCP operation in explicit link failure notification technique (ELFN)wireless networks, it is not suitable for hybrid wired in the context of improving TCP performance overand wireless network where a high bandwidth multi-hop ad-hoc networks. They studied the effectdelay product exists. Second, if the cwnd is not lim- of link failures due to mobility on throughput andited by four packets, the choice of a delay window showed through simulations that ELFN improvessize of 4 may no longer be suitable. In this paper, the performance of TCP. Xu et al. [11] proposed awe address the above issues and provide more effec- Neighborhood RED (NRED) scheme, whichtive and general solutions that apply to various extended the RED concept to the distributedenvironments. neighborhood queue, to address significant TCP The delayed ack has impact on the TCP sender. unfairness in ad hoc wireless networks. These mech-Since the receiver does not ack as frequently as in anisms are promising schemes to be integrated withthe standard TCP, the congestion window increas- our mechanism for more robustness against packeting rate for delayed ack is slowed down. Such slower loss and TCP fairness.probing rate improves TCP performance in ad hocnetworks, as reported in [13]. The conservative win- 3. TCP throughput vs. delay windowdow increase, however, hinders efficient transmis-sion in wired network where delay bandwidth In this section, we investigate the impact of theproduct may be large. In this paper, we solve this receiver ack delay window size on TCP perfor-problem and allow TCP-DCA to cope with ad hoc mance. The conclusion we draw is that, when theand hybrid wired/wireless networks via adaptive path length is short, TCP achieves better perfor-schemes. mance with a delay window as large as the entire We also study the impact of cwnd limit at the sender cwnd. When the path length increases, how-sender. A small sender cwnd can decrease interfer- ever, a large delay window triggers bursty transmis-ence and maximize pipeline effect. [8] revealed that sions, which results in mutual data packetthere exists an optimal TCP cwnd size that maxi- contention and higher losses. In fact, for long paths,mizes spatial channel reuse. Further increasing the there exists an optimal delay window size thatwindow size does not lead to better performance. achieves maximum TCP throughput. We verify theOn the contrary, it results in increased link layer delay ack impact using various network topologies,contention and degraded TCP throughput. In [14], including cross and grid topologies with variousthe optimal congestion window limit is determined flow patterns. Real testbed measurement resultsbased on the hop count for maximum pipeline effect are also presented to reinforce our conclusions.and the interference/transmission range ratio. In the Firstly, we study a basic scheme with fixed delaypaper, we will show that in our scheme TCP-DCA, window limit to illustrate the impact of the delaythe sender’s cwnd is not limited, and yet, performs window size on TCP performance, named as TCP-better than the case of the limited cwnd used in [3]. FDCA. We use static routing to investigate delayed TCP-DCA resides at TCP layer, and it has poten- ack performance without any routing interference.tial to be combined with other TCP enhancements Routing impact will be shown in Section 5.
  5. 5. 1102 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–11163.1. TCP with fixed delay window limit choose b as 0.8 and a as 1.5. The receiver also gen-(TCP-FDCA) erates an ack within 500 ms of the arrival of an unacknowledged data packet in accordance with TCP-FDCA maintains a variable delay window RFC2581 [1].‘‘w’’ representing the number of data packet arrivals One drawback to this approach is that the TCP-before acking at the receiver. This delay window w is FDCA receiver needs to be informed of sender’sbounded by a delay window limit, and also limited cwnd size to prevent delay window larger than cwndby the cwnd size to prevent the delay window from leading to unnecessary delaying at the receiver. Toexceeding the cwnd which results in delaying the address this problem, we propose two possibleack, but for possibly non-existent packets. If data methods. One is to imbed the cwnd size in an optionpackets arrive in order, the receiver generates one field of the packet header. The other is to reuse somecumulative ack for every w data packets. If an out TCP header field. For example, the sender couldof order packet is received, or a packet that fills a reuse the advertised window field in data packetgap in the sequence space of packets in the receiver header for ‘‘advertising’’ its cwnd size to the recei-buffer (that is, recovery from earlier packet loss), the ver. This method is not unrealistic due to the factreceiver acks immediately to inform the sender of that current TCP connection is mostly used forthe packet loss/recovery in a timely manner. The one direction, i.e. there is only data packets fromreceiver also keeps a fall-back delay ack timer which the sender to the receiver and no backward data,estimates the expected time to receive w data pack- so the advertised window field from the sender isets. At the TCP sender, when it receives a cumula- usually wasted. Even if two-way TCP data istive ack acknowledging w data packets, it updates included, it is still possible to reuse the advertisedthe cwnd and sends out a burst of at least w packets, window field, for example every other packet withprovided such packets are ready for transmission in one bit in the reserved field to indicate whetherthe sender buffer. cwnd or advertised window size is used. The lowed To get the delay timer period, the receiver moni- frequency of cwnd notification is not expected totors the data packet inter-arrival interval and com- affect TCP-FDCA much since TCP-FDCA receiverputes a smoothed interval through a low-pass does not need to know the exact cwnd so often, asfilter. The average inter-arrival interval is used to we will see later in the paper.set the ack delay timer based on the current delaywindow size. In TCP-FDCA, an accurate delay 3.2. Chain topologytimer is not needed and the timer is solely for fallback purpose. In fact, our inter-arrival time compu- In order to understand TCP-FDCA, its perfor-tation is rather simple and loose: the receiver sam- mance is shown over a chain topology in Ns2 [16].ples the inter-arrival time of any consecutively The chain topology is general used to study TCParrived data packets, not necessarily in-order pack- performance since TCP typically runs over a singleets. Therefore, the inter-arrival sample is an inflated path. Fig. 1 shows a chain example. The TCP con-value compared with inter-arrival between in-order nection is sourced at the first node (node 1) andpackets. A TCP-FDCA receiver smoothes such packets travel over the chain to the end node (nodeinflated inter-arrival samples through a low-pass 6). The interference range is 550 m and transmissionfilter range is 250 m. We place the nodes at 200 m inter- vals, so that nodes are 4 hops away can transmitI iþ1 ¼ bI iavg þ ð1 À bÞI s ; avg ð1Þ simultaneously without interference. Notice that awhere I avg is the average of inflated packet inter-ar- node that is 3 hops away is a ‘‘hidden node’’. IEEErival time (I s ). I avg is used to set delay ack timer (T w ) 802.11 is the underlying MAC. Data rate on thewhich defines the total time for receiving a whole de- wireless channel is 2 Mbps and one simulation runlay window of in-order data packets lasts 300 s. Each data point represents an averaged result of 5 simulation runs with different randomT w ¼ awI avg ; ð2Þ seeds. The packet size is 1000 bytes and the TCP-where w is the delay window size, a is a parameter to Newreno is adopted as it is the most popular TCPtolerate high dynamic packet delay. Obviously, the protocol nowadays. The delay window limit applieddelay ack timer is rather inflated and quite robust at the TCP receiver ranges from 1 to the currentto high inter-arrival variation. In the paper, we cwnd size.
  6. 6. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1103 1600 1hop 2hop 3hop 1400 Throughput (Kbps) 1200 1 2 3 4 5 6 1000 800 600Fig. 1. Chain topology. The solid-line circle denotes a node’s 400valid transmission range. The dotted-line circle denotes a node’s 1 2 3 4 5 6 7 8 9 10 ...CW Delay Window Limit (packets)interference range. Node 4’s transmission will interfere with node1’s transmissions to node 2. (a) Path Length h ≤ 3 350 4hop 5hop 6hop3.2.1. Single TCP flow 7hop 8hop TCP performance over wireless multihop inevita- 9hopbly depends on the path length (hop count). The Throughput (Kbps) 300longer the path is, the lower the throughput wouldbe. We present TCP-FDCA throughput as a func-tion of delay window limits on a path with differentlengths in Fig. 2. Fig. 2a shows that when a sender 250and a receiver are within 3 hops, TCP-FDCA getssteady performance gain by increasing the delaywindow size up to the entire cwnd size. For the 200one hop case, the fastest throughput increase can 1 2 3 4 5 6 7 8 9 10 ...CWbe seen when the delay window is small, say less Delay Window Limit (packets)than 5. The increasing trend becomes slower for (b) Path Length 10 > h >3delay windows larger than 5 and the throughput 240approaches the limit when the delay window reaches 10hop 12hopthe cwnd size (denoted by CW). The same trend is 230 14hop 16hopalso observed when the path length is 2 and 3. 220 18hop 20hopThe reason for this performance gain is that Throughput (Kbps)802.11 MAC provides nearly collision free packet 210transmissions for short paths. Since the interference 200range is larger than 2 times the transmission range, 190when the sender and receiver are within 2 hops,every node along the path can sense all other nodes 180transmissions. In this case, no hidden nodes exist, 170thus packet loss is minimal. When the hop lengthis 3, the TCP receiver is the only node hidden from 160 1 2 3 4 5 6 7 8 9 10 ...CWthe TCP sender. If the receiver acks only after Delay Window Limit (packets)receiving all packets in a cwnd, no data packet (c) Path Length 20 ≥ h ≥ 10can be interfered. The maximal performance gainis achieved when the receiver acks after receiving Fig. 2. TCP-FDCA throughput vs. delay window on chainall packets in a cwnd, and attains up to 25% topology. (a) Path length h 6 3. (b) Path length 10 > h > 3. (c) Path length 20 P h P 10.throughput gain relative to the TCP with delay win-dow at 1. Since the interference range is larger than the solve the hidden/exposed terminal problem. As thetransmission range, RTS/CTS cannot completely path becomes longer than 3 hops, packet collision
  7. 7. 1104 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116is unavoidable. For example, node 1 and node 4 are ver are used for 802.11b devices and the devices areinterfering nodes in Fig. 1, so simultaneous packet set to ad-hoc mode. The topology of the testbed is atransmissions on them will be interfered. The hidden chain and the route is statically configured. There isterminal results in packet loss and this problem one source laptop and one selected destination lap-becomes more severe for longer paths because a top among other 5 laptops depending on the num-packet has more chances to be interfered with. ber of hops in our experiments. We use ‘‘Iperf’’ toAnother problem is that when the sender receives generate FTP traffic with packet size of 1000 bytes.a cumulative ack, it immediately sends a burst of From the experiment results shown in Fig. 3, wepackets. The larger the delay window, the larger confirm that the TCP-FDCA throughput vs. recei-the burst and the more packet loss due to increased ver delay window follows the same trends as ininterfering. (Note that the packet burst size is the simulation results shown in Fig. 1.directly related with the receiver delay window since Fig. 4 compares TCP-FDCA throughput for 1it is at least equal to the size of the delay window.) hop and 5 hops paths from simulation and actual When the packet loss becomes high, the TCP- testbed, when delay window limit is equal to 1 andFDCA throughput gain from delaying ack is lost cwnd respectively. We note that the average differ-due to the increased packet losses. Fig. 2(b) shows ence between the testbed TCP throughput and thethis tradeoff of TCP-FDCA performance gain with simulation results is below 10%. Such difference isdelay window size for paths larger than 3 hops.When the hop count is 4 or 5, we do observe unsuc-cessful packet transmissions caused by interference, 1600however, since a TCP sender is able to recover 1hop 2hoppacket loss rather rapidly due to the small round 3hop 1400trip time (RTT), TCP-FDCA maintains perfor-mance gain by delaying ack for more data packets. 1200 Throughput (Kbps)After peak performance at certain delay window,the TCP-FDCA performance gets worse due to 1000more packet losses. Similar trend also exists forpaths longer than 5 hops, where TCP-FDCA 800achieves throughput gain only when the delay win-dow size is small; for large delay window size, delay- 600ing ack cannot maintain throughput gain because ofexcessive data packet losses. Further, now that RTT 400is larger, TCP-FDCA spends more time detecting 1 2 3 4 5 ...CW Delay Window Size (packets)packet loss and recovering lost packets by enteringfast retransmit/recovery in which only one packet (a) 1 to 3 hopis recovered per RTT. Therefore, for long paths, 370large delay window is not preferred. 4hop 5hop 360 We also show TCP-FDCA performance over a 350very long path h P 10 in Fig. 2(c) which has similarresults with Fig. 2(b). TCP-FDCA only gets perfor- 340 Throughput (Kbps)mance gain for small delay window size. For large 330delay window size, TCP-FDCA gets poor 320throughput. 310 3003.2.2. Real testbed verification We investigate the effectiveness of our TCP- 290FDCA in an actual ad-hoc network testbed. Our 280testbed consists of six laptops equipped with Ori- 270noco 802.11b PCMICA cards with channel rate of 1 2 3 4 5 ...CW Delay Window Size (packets)2Mbps. The laptops run Mandrake Linux distribu- (b) 4 and 5 hoption 7 with kernel version 2.4.3. Linux PCMCIApackage version 3.2.0 and Orinoco wavelan2-cs dri- Fig. 3. Real testbed measurement. (a) 1 to 3 hop. (b) 4 and 5 hop.
  8. 8. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1105 1500 d 3.3. More complex topologies and flow patterns 1 dCW We expand our study to scenarios of more com- plex topologies and flow patterns, including cross Total Throughput (Kbps) 1000 and grid topologies. For all cases, we observe the similar results to what is described above, i.e., when the path is short, TCP-FDCA achieves optimal throughput by delaying acks as much as possible, 500 up to the entire sender’s cwnd. On the other hand, when the path becomes longer, a large delay win- dow hinders performance gain and deteriorates TCP throughput gradually. We show that there 0 exists a certain delay window size, at which TCP- Simulation Experiment FDCA achieves optimal throughput performance. (a) 1 hop The following provides a summary of results on 300 multiple flows and various topologies. The perfor- d 1 mance over random topologies will be shown in Sec- d 250 CW tion 5.2. Total Throughput (Kbps) 200 3.3.1. Multiple TCP flows Fig. 5 exhibits result for 5 concurrent TCP- FDCA flows on a chain topology with hop count 150 varying from 3 to 7, and has similar results to Fig. 2. 100 3.3.2. Cross and grid topology Fig. 6 shows examples of cross and grid topolo- 50 gies with a 4 hop path for each TCP-FDCA flow, and the results with different delay window size are 0 Simulation Experiment shown in Fig. 7. Additionally the results from vary- (b) 5 hop ing path lengths are shown. Similar trend is observed again. We also run extensive simulations on cross Fig. 4. Simulation vs. experiment. (a) 1 hop. (b) 5 hop. and grid topologies with multiple overlapped flows instead of one flow. The results, not included here,mainly caused by parameter setting in the testbed also confirm the same trends discussed above.measurements. In our testbed experiments, RTS/CTS control packets are adopted for unicast data 500packets to overcome the hidden terminal problem 3hop 5hoponly if the packet size is above the minimum thresh- 7hop 450old 256 bytes. Since the size of TCP ack packet Aggregate Throughput (Kbps)(40 bytes) is below the minimum RTS/CTS threshold 400in Linux settings so that no RTS/CTS handshake isperformed when transmitting acks in testbed experi- 350ments. Compared with simulation results whereRTS/CTS is always performed regardless of packet 300size, such ‘‘zero’’ MAC overhead in testbed measure-ments has impact on the performance: the through- 250put gain derived from TCP-FDCA in the testbedmeasurements is lower than the corresponding results 200in the simulations because of the lack of RTS/CTS 1 2 3 4 5 6 7 8 9 10 ...CWreduction for acks in simulations. Other than this Delay Window Limit (packets)slight difference, the results are similar in simulation Fig. 5. TCP-FDCA throughput vs. delay window on chainand in testbed measurements. topology (5 flows).
  9. 9. 1106 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 8 Flow 1 7 TCP flow 1 0 1 2 3 4 Flow 2 TCP flow 2 6 5 Flow 3 (a) Cross To pology (b) Gri d TopologyFig. 6. More complex topologies. Left: cross topology with 4 hop path on each direction. 200 m distance between two adjacent nodes.Right: 5 · 5 grid topology, 200 m distance between horizontal and vertical adjacent nodes. (a) Cross topology. (b) Grid topology. 340 340 4hop 5x5 6hop 5x7 8hop 5x9 320 320 Aggregate Throughput (Kbps) Aggregate Throughput (Kbps) 300 300 280 280 260 260 240 240 220 220 200 200 1 2 3 4 5 6 7 8 9 10 ...CW 1 2 3 4 5 6 7 8 9 10 ...CW Delay Window Limit (packets) Delay Window Limit (packets) (a) Cross Topology (b) Grid Topology Fig. 7. TCP-FDCA throughput vs. delay window on complex topologies. (a) Cross topology. (b) Grid topology.4. TCP with adaptive delayed cumulative ack vation, we dynamically determine the delay window(TCP-DCA) size based on the hop count of a TCP connection and call it as TCP-DCA. For a short path (h 6 3), In this section we propose TCP-DCA with adap- TCP-DCA could delay ack for a whole cwnd totive delayed window according to the underlying get best performance; otherwise a small delay win-path information to optimize TCP performance. dow for long paths. Since TCP still gets slight ben-The issue of ack loss is also discussed and a simple efit by delaying more for moderate long pathsreceiver retransmission scheme is proposed. (3 < h 6 9), therefore the delay window could be slightly larger for such paths. TCP-DCA receiver4.1. TCP-DCA with adaptive delayed ack can get the path length information from the TTL field in TCP packet header or from the routing Up to now we have presented the tradeoff layer at the receiver node Table 1 lists the delay win-between TCP-FDCA throughput and delay window dow size applied in TCP-DCA according to the pathsize on different path lengths. Inspired by this obser- length.
  10. 10. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1107Table 1 mission timer period is set to 1 s. This ack retrans-Delay window at TCP-DCA receiver mission timer is started after sending an ack, andPath length (h) Delay window limit canceled after receiving a data packet.h63 Congestion window Until now all previous results were obtained3<h69 5 without ack retransmission. This is due to two facts:h P 10 3 first, the results with and without ack retransmission are almost the same for static networks. Mostly4.2. Ack loss because the ack loss is rare, and the ack retransmis- sion timer period is large (at least 1 s). Second, with- The standard TCP generates more acks than out the ack retransmission timer, it is easy toTCP-DCA, due to the cumulative property of the observe the sole impact of the delay window onack, one ack successfully received at the TCP sender TCP performance. In the following simulations,can makes up for all the preceding lost acks. Thus, the ack retransmission timer is enabled unlessthe ack loss in standard TCP is not serious. How- explicitly mentioned.ever, the number of acks in TCP-DCA is much lessthan standard TCP, and thus an ack loss has more 5. Performance evaluationnegative impact on TCP-DCA performance. Inorder to be robust to ack loss, a retransmission This section presents the TCP-DCA performancetimer at the receiver is adopted to retransmit a over wireless and hybrid networks. First, we showcumulative ack if necessary. TCP-DCA performance on static multihop wireless A challenge here is to estimate RTT at the recei- networks and compare it with TCP-DAA in [3]. Sec-ver which is needed for setting the ack retransmis- ond, we demonstrate TCP-DCA performance onsion timeouts. If TCP includes two-way data, the mobile ad hoc network, and show TCP-DCA per-receiver can get the accurate RTT measurement formance over several ad hoc routings. Third, wesince the sender acks the data immediately. If TCP extend the hop count based approach to an end-only has one-way data, RTT measurement at the to-end delay based scheme to further improvereceiver may not be straightforward. If the TCP TCP-DCA in hybrid wired/wireless networks. Last,timestamp option is used, the receiver could use it we propose a simple approach to address the friend-to estimate RTT, though such an estimate may be liness problem of TCP-DCA to TCP-Newreno withinflated if the sender does not send data packets standard delayed option.immediately after receiving an ack [17]. However,in TCP-DCA, the ack retransmission timer is only 5.1. Static ad hoc networka coarse timer for predicting when to retransmitacks, an accurate RTT measurement is not required In this section, we show TCP-DCA performanceand thus an inflated RTT can be tolerated. In the in static ad hoc networks. Meanwhile, we comparepaper, the timestamp option is used to estimate TCP-DCA with TCP-DAA and TCP-Newrenothe RTT for a TCP flow which has one-way data. (with and without standard delayed ack option The receiver computes the ack retransmission [1]). More specially, we use the name ‘‘originaltime based on this RTT measurement. We use the TCP’’ for TCP-Newreno without standard delayedfollowing formula to calculate the retransmission option, and TCP-STD-DA for TCP-Newreno withtimer period: standard delayed option. AODV routing is used unless otherwise stated. 7 1 TCP-DAA [3] is an interesting extension of [2]SRTTr ¼ SRTTr þ RTTr ; kþ1 k kþ1 8 8 and has shown good performance in static ad hoc 3 1 networks. It is the most recent work and the majorRTTvar ¼ RTTvar þ jRTTr À SRTTr j; kþ1 k kþ1 kþ1 4 4 differences between TCP-DAA and TCP-DCA are r r varRTOkþ1 ¼ SRTTkþ1 þ 4 Â RTTkþ1 ; listed in Table 2. For fair comparison, most simula- tions scenarios presented in this subsection werewhere RTTr is the RTT estimation at the receiver, shown in [3]. Each result is the average of five sim-SRTTr is the smoothed RTT. RTTvar and RTOr ulation runs.are RTT variance and retransmission timer period In Fig. 8, we compare TCP-DAA to TCP-DCAat the receiver. The minimum value of the retrans- in the chain topology with different hop count and
  11. 11. 1108 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116Table 2Design difference TCP-DAA TCP-DCASender Duplicate acks threshold to trigger retransmission is 2; CW Puts CW into advertised window field upper limit is 4; Retransmission (RTO) timer is increased fivefold in packet headerReceiver Delay window is adaptive from 2 and 4 based on loss event Delay window is adaptive on the path lengthnumber of concurrent flows. Although TCP-DCA is CWL and TCP-DAA achieve best performancedesigned without cwnd limit, we include TCP-DCA and their difference is small. They provide betterwith cwnd limit at 4 in this experiment, named TCP- performance, about 10–25%, than the standardDCA-CWL, to show a fair comparison with TCP- TCP (with and without delayed ack option).DAA. Note that in TCP-DAA, the cwnd limit is With static topology and steady traffic pairs, theset to 4 by default. Fig. 8a shows the performance variance of results is very small (less than 5%) so weof TCP-DCA over 3 hop chain. The aggregate omit its error bar results. Also note that TCP-DCA-throughput of TCP-DCA decreases when the num- CWL does not bring significant benefit over TCP-ber of flows increases. When there are few flows, DCA. Since the ack flow is decreased, the optimalsince each TCP-DCA generates as few acks as pos- cwnd size could actually increase (for details, pleasesible, the advantage of TCP-DCA is obvious. When refer to [14]). Although it may be interesting tomore flows coexist, the cwnd of each flow becomes investigate the optimal cwnd for TCP-DCA, wesmaller since they compete for the bandwidth, thus do not pursue it because our ultimate goal to designthe benefit of delayed ack reduces because more TCP-DCA without cwnd limit. Moreover, thisacks are generated. If the cwnd is below the cwnd property makes TCP-DCA distinct since selectinglimit in TCP-DCA-CWL, they have similar perfor- an optimal cwnd is non-trivial, which needs to knowmance. The performance of TCP-STD-DA is better a lot of underlying information to accomplish. Forthan original TCP, but worse than TCP-DCA and example, it requires the knowledge of transmis-TCP-DAA. TCP-DCA and TCP-DCA-CWL pro- sion/interference ratio [14] at the physical layervides better performance than other TCP variants. which is usually hard to obtain. It could also poten-Overall, TCP-DCA achieves best performance, up tially limit the application of TCP in a variety ofto 15% improvement over TCP-DAA, and 25% over wireless networks, such as that TCP with cwnd limitTCP-STD-DA respectively. Fig. 8b–c show the per- in wired and wireless scenario does not perform wellformance of TCP-DCA on a 5 and 7 hop path. The (will be shown in Section 5.4). Taking this intosame trend persists and TCP-DCA outperforms all account, we do not choose cwnd limit in TCP-other algorithms in most situations. DCA and thus in the following experiments, only Note that the cwnd limit on TCP-DCA does not TCP-DCA (no cwnd limit) is adopted.bring considerable benefit. For a short path inFig. 8a, the cwnd limit could considerably restrict 5.2. Mobile ad hoc networkthe TCP performance as the number of flows issmall. For a long path in Fig. 8b–c, the cwnd limit We have demonstrated that applying delayed ackonly provides slightly more performance gain for 2 scheme improves TCP performance in a static net-flows, and this advantage disappears for more flows. work, now we show that it can improve TCP perfor-From Fig. 8, the performance of TCP-DCA without mance in a mobile network as well. Though ourcwnd limit is better than that of TCP-DCA-CWL in delayed ack scheme is not specifically designed formost situations. It indicates that TCP-DCA can the TCP in mobile network, we show that ourachieve the distinguished performance without set- scheme works well in mobile scenarios.ting cwnd limit. In Fig. 10, we show the performance of the origi- We also give results for the grid topology. This nal TCP, TCP-STD-DA, TCP-DAA and TCP-grid topology is shown in Fig. 9a and 6 flows run- DCA running over three routing schemes: GPSR,ning on the grid. Fig. 9b compares the performance AODV and DSR. The experiment consists of 40of original TCP, TCP-STD-DA, TCP-DAA, TCP- nodes randomly moving within a 1000 m · 1000 mDCA-CWL and TCP-DCA, and we observe the area. Each node moves with the same speed withoutsimilar results as before. TCP-DCA, TCP-DCA- pause. The Random Waypoint mobility model [18]
  12. 12. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1109 550 TCP-DCA Flow 4 Flow 5 Flow 6 TCP-DCA-CWL TCP-DAA TCP TCP-STD-DA Flow 1 Aggregate Throughput (Kbps) 500 Flow 2 450 400 2 4 6 8 10 12 14 16 18 20 Flow 3 Number of Flows (a) 3 Hop Path (a) Grid Topology 300 TCP-DCA TCP-DCA-CWL TCP-DAA 290 TCP TCP- TCP-STD-DA DCA Aggregate Throughput (Kbps) 280 TCP- 270 DCA- CWL 260 TCP- 250 DAA TCP- 240 STD- DA 230 TCP 220 2 4 6 8 10 12 14 16 18 20 Number of Flows 0 100 200 300 400 500 600 700 (b) 5 Hop Path Aggregate Throughput (Kbps) 280 (b) Aggregate Throughput for TCP variants over TCP-DCA TCP-DCA-CWL Grid Topology TCP-DAA TCP 260 TCP-STD-DA Fig. 9. Performance comparison on grid topology. (a) Grid topology. (b) Aggregate throughput for TCP variants over grid Aggregate Throughput (Kbps) 240 topology. 220 but with different randomly generated mobility traces. We run the set of experiments with 40 differ- 200 ent mobility traces and plot the 95% confidence interval as error bars on the figures. 180 We illustrate results on speed 10 m/s and 20 m/s in Fig. 10 with one TCP flow, for other speeds and 160 2 4 6 8 10 12 14 16 18 20 multiple flows, the results are similar. From Fig. 10 Number of Flows we observe that the delayed cumulative ack contrib- (c) 7 Hop Path utes to the performance gain compared with otherFig. 8. Aggregate throughput for TCP variants over chain TCP variants. TCP-DCA produces at least 10% per-topology. (a) 3 hop path. (b) 5 hop path. (c) 7 hop path. formance gain over other TCP variants regardless of routing protocols and mobility speed, especially more gain for TCP over DSR. TCP-STD-DA isis used. All results displayed are calculated as the unsurprisingly consistently better than the originalaverage of 40 runs with the same traffic pattern, TCP without delayed ack. However, TCP-DAA
  13. 13. 1110 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 900 800 TCP-DCA TCP-DCA TCP TCP 800 TCP-STD-DA 700 TCP-STD-DA TCP-DAA TCP-DAA TCP-DCA-ACK-LOSS TCP-DCA-ACK-LOSS 700 600 Throughput (Kbps) Throughput (Kbps) 600 500 500 400 400 300 300 200 200 100 100 0 0 GPSR AODV DSR GPSR AODV DSR (a) 10 m/s (b) 20 m/s Fig. 10. TCP performance over mobile network. (a) 10 m/s. (b) 20 m/s.does not show consistent improvement across differ- acks are generated and more timeouts are likely toent routing protocols. It performs similarly as TCP- happen. Fig. 11 illustrates the idle time of TCP dur-STD-DA over GPSR, but does not show better ing the whole simulation time (400 s) for differentperformance than TCP (with or without standard TCP variants and routing schemes. As expected,delayed option) over DSR. TCP-DCA (considering ack loss) has least idle time In TCP-DCA, the receiver would probe the sen- over each routing scheme, which helps TCP-DCAder by retransmitting acks in the event of high maintain better throughput in a mobile network.packet loss (see Section 4.2). It prevents the sender Note that TCP-DCA-ACK-LOSS has similar idlefrom entering long timeout due to the severe packet time with other TCP variants, which confirms thatloss event. In Fig. 10, we also show the result of retransmission scheme is effective in improvingTCP-DCA without ack retransmission (TCP- TCP performance in mobile networks.DCA-ACK-LOSS) to confirm the effectiveness ofack retransmission. When packet loss is severe 5.3. Lossy network(e.g. TCP over DSR), ack retransmission consider-ably boosts the TCP-DCA’s performance. On the In wireless networks, the wireless link in factother hand, the ack retransmission does not help could become unreliable and error-prone. Aftermuch when packet loss is not severe (e.g. TCP over studying the performance of TCP-DCA underGPSR). Therefore, TCP-DCA only incurs more ack packet losses in mobile networks, we investigate itsretransmission overhead when needed, and works performance under lossy wireless link. BER (bitwell with packet losses in mobile networks. error rate) is used as the loss metrics at the wireless Comparing with static ad hoc networks in Sec- link and the error is assumed to be uniformly dis-tion 5.1, mobility poses more challenges for TCP. tributed and independent on each link. It is worthIn a mobile network, the loss of packets (or acks) pointing out that when a packet is received withmay be caused by temporary route loss as well as bit error, the IEEE 802.11 MAC layer helps innetwork congestion. Higher mobility causes more recovering packet loss by retransmissions until aroute loss and thus more packet losses. Since routes maximum retransmission limit is reached [19] orare likely to be lost frequently in high node mobility retransmission is successful. Therefore, when BERenvironments, and different routing algorithms have is low, the MAC retransmission scheme can easilydifferent capability to repair broken routes quickly, recover the packet and would not cause much prob-thus different TCP performance is observed over lem for TCP. While the BER is high, the heavydifferent routing schemes. Moreover, The frequent packet loss would knock down TCP performance.route breakages could put TCP into long idle state Fig. 12 illustrates a scenario where a single flowleading to poor TCP performance, especially for goes through 5 hop chain path under varyingTCP with untraditional delayed ack where fewer BER from very low BER to high BER. Each bar
  14. 14. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1111 350 TCP-DCA 350 TCP-DCA TCP TCP TCP-STD-DA TCP-STD-DA 300 TCP-DAA 300 TCP-DAA TCP-DCA-ACK-LOSS TCP-DCA-ACK-LOSS 250 250 Idle Time (second) Idle Time (second) 200 200 150 150 100 100 50 50 0 0 GPSR AODV DSR GPSR AODV DSR (a) 10 m/s (b) 20 m/s Fig. 11. TCP idle time. (a) 10 m/s. (b) 20 m/s. 300 TCP-DCA account the acknowledged data covered in the acks. TCP TCP-STD-DA Using delayed ack could potentially cause slow TCP-DAA 250 cwnd increase and thus hurt TCP performance. Therefore, the pure adaptive delay window based on the hop count appears not adequate for this sce- Throughput(Kbps) 200 nario. For example, in WLAN where 1 hop wireless 150 client can delay the cumulative ack for the whole cwnd, the cwnd at the sender could increase slowly, 100 particularly if a large propagation delay is encoun- tered in the wired part. Although slow increase for 50 cwnd is helpful for improving TCP performance in ad hoc networks as shown in our previous results, 0 it is not desirable for the hybrid network. In 2e-6 6e-6 2e-5 6e-5 Bit Error Rate RFC3465 [20] Allman proposed to increase the cwnd based on the number of bytes acknowledged Fig. 12. TCP performance under random loss. by the arriving acks rather than based on the num- ber of acknowledgments that arrive at the sender inis an averaged result of 20 random runs. Overall, the RFC2581 [1]. However, this approach potentiallyperformance of TCP-DCA is no worse than other causes large bursts if the delay window is large.variants, and quite robust to wireless loss. TCP- An appropriate delay window limit needs to beDAA also works very well unless the loss is too investigated in this scenario.heavy. With the increasing loss rate, all TCP vari- Another challenge of the hybrid network is thatants gracefully reduce their performance and the the hop count information from the packet headervariance of results increase. is no longer accurate for the wireless hops since it includes the wired path. It is possible for a wireless5.4. Hybrid (wired and wireless) network node to get hop count from the routing table to the base station (or gateway) to the wired network, In this section we study TCP-DCA in the wired however, this information is not guaranteed to beand wireless ad hoc environment. Since wired net- available all the has abundant bandwidth, it demands a much To address the problems in hybrid networks, welarger cwnd than the pure ad hoc network for effec- tailor and propose a novel receiver-side probe mech-tive TCP performance. In current TCP implementa- anism based on CapProbe in [21], and extend thetion, TCP sender increases the cwnd only based on previous hop-count based approach via the recei-the number of acks received while not taking into ver-side probe in hybrid networks.
  15. 15. 1112 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 The receiver-side probe works as follows: First Table 3the receiver passively estimate the wireless band- IEEE 802.11b MAC overhead (with long preamble), L is packet size, R is capacitywidth and minimum RTT. Second it computes theequivalent hop count based on the minimum RTT Data frame 192 ls + 8L/Rand wireless bandwidth, then the previous hop SIFS 10 lscount approach can be applied afterwards. DIFS 50 ls RTS 192 ls + 160/R Now we address the problem to estimate the end- CTS 192 ls + 112/Rto-end hybrid path bandwidth at the TCP receiver. ACK 192 ls + 112/RCapProbe [21] is a recently proposed bottleneckcapacity and path rate estimation technique shownto be both fast and accurate. It combines the use Table 4of time interval measurements and end-to-end delay Delay window at TCP-DCA receiver (delay-based, wirelessmeasurements to filter out bad packet pair probing bandwidth is at 2 Mbps and TCP data packet size is 1000 bytes)samples. It is proved to be suitable for wired and Minimum RTT (ms) Delay window limitlast-hop wireless networks. Inspired by CapProbe, RTTmin < 18 Congestion windowwe proposed a new approach at the TCP-DCA 18 6 RTTmin 6 60 5receiver without triggering any probing traffic. The RTTmin > 60 3idea is that after the receiver sends a cumulativeack, the sender would send a burst of packets. Theburst of packets can just serve as the packet pairprobing. Since the receiver knows the sequencenumber of the first burst packets, it can identifythe packet pair and estimate the bandwidth when Internet BS 1 2packet pair arrives. Our approach is based on theCapProbe, but it is different with CapProbe. First Fig. 13. Hybrid wired/wireless topology.our approach is imbed at the TCP receiver withoutany additional probing traffic. Moreover, ourapproach is a one-way (instead of round-trip inCapProbe) estimation technique, and it is expected 1500 TCP-DCA TCPto work for wired, hybrid and purely wireless TCP-STD-DA TCP-DAAnetworks. The other challenge is to estimate the minimum Throughput (Kbps) 1000RTT at the receiver, but this have been solved asdescribed in Section 4.2. After the wireless bandwidthand minimum RTT is obtained, the receiver derivesthe equivalent hop count by considering the TCP 500data and ack packet sizes. For example, with wirelessbandwidth of 2 Mbps, data packet size of 1000 bytesand ack size of 40 bytes, the minimum RTT for a 1wireless hop path is about 6 ms considering various 0overhead, such as header overhead at TCP (20 bytes), 1 hop 2 hopIP (20 bytes) and MAC (34 bytes) and MAC layer Wireless Hop Countfixed overhead shown in Table 3 (for details, please Fig. 14. Wired and wireless performance.refer to [22]). In Table 4, we listed the delay windowsize in a wireless network with capacity 2Mbps. In Fig. 13, we show a TCP connection from a running with different random seeds. Similar to Sec-wired network to a wireless network with up to 2 tion 5.1, the variance of results is very small so wewireless hops. The one-way propagation delay on omit its error bar results. Since TCP-DAA limitsthe wired link is 50 ms. The performance of TCP- the cwnd, the performance of TCP-DAA is limited.DCA, TCP-DAA and the standard TCP (with and TCP-DCA provides best performance in both caseswithout standard delayed ack option) shown in of 1 and 2 hop paths. Therefore, TCP-DCA isFig. 14, represents averaged result of 10 simulation extensible to hybrid networks instead of working