TCP with delayed ack for wireless networks

1. Available online at www.sciencedirect.com
Ad Hoc Networks 6 (2008) 1098–1116
www.elsevier.com/locate/adhoc
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 2007
Abstract
This paper studies the TCP performance with delayed ack in wireless networks (including ad hoc and WLANs) which
use IEEE 802.11 MAC protocol as the underlying medium access control. Our analysis and simulations show that TCP
throughput does not always benefit from an unrestricted delay policy. In fact, for a given topology and flow pattern, there
exists an optimal delay window size at the receiver that produces best TCP throughput. If the window is set too small, the
receiver 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 degrading
the throughout. In wireless networks, packet losses are also related to the length of TCP path; when traveling through a
longer path, a packet is more likely to suffer interference. Therefore, path length is an important factor to consider when
choosing 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, and
provide more significant gain in mobile networks. The proposed schemes are simple and easy to deploy. The real testbed
experiments 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; Friendliness
1. 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 terminal
the Internet. TCP was originally designed for wired problems, and frequent route breakages caused by
links 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: cjw@ee.ucla.edu (J. Chen), gerla@cs.
pose various methods to make TCP survive in such
ucla.edu (M. Gerla), yenglee@cs.ucla.edu (Y.Z. Lee), medy@cs. challenging environments. In this paper, we focus
ucla.edu (M.Y. Sanadidi). on studying the effect of delayed acks on TCP
1570-8705/$ - see front matter Ó 2007 Elsevier B.V. All rights reserved.
doi:10.1016/j.adhoc.2007.10.004

2. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1099
performance. Then based on our findings, we pro- in turn causes severe packet interference with each
pose adaptive schemes that address the aforemen- other. When packet loss rate becomes high, the
tioned factors effectively. benefit of delaying acks, via reducing ack packets,
In standard TCP the receiver generates one ack disappears. Consequently, TCP performance
for each data packet, or more popularly, two in- degrades after reaching the peak at the optimal
order 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 delayed
works. In multihop wireless networks, however, this ack impact on TCP performance over multihop
mechanism 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 proposed
ied to improve TCP performance [2,3]. However, schemes only reside in transport layers at the end
this field is not fully exploited and many issues hosts, thus no modification on intermediate nodes
remain unsolved. Some important questions is needed.
include: what is the relation between delayed acks However, TCP with untraditional delayed ack
and TCP performance, how to choose the proper (with delay window larger than 2) would cause
delay window (the number of in-order data packets friendliness to the standard TCP. Since TCP sender
to be waited for before generating an ack) for TCP, increases the congestion window (cwnd) by usually
and how to deal with the loss of acks in multihop counting the number of acks received in the current
wireless 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 cwnd
acks on TCP over wireless links. We investigate than the standard TCP. If they coexist, the TCP
TCP performance and delayed ack related packet with untraditional delayed ack would not get fair
loss characteristics, under various wireless network share with the standard TCP. The unfriendliness
scenarios 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 the
ship between TCP throughput and delayed ack over problem with a simple and intelligent end-to-end
multihop wireless links. We reveal several interest- receiver-side detection mechanism. If the receiver
ing findings, which are tremendously beneficial to detects other competing traffic, it switches to the
deeply understand TCP behavior in wireless multi- standard TCP, and vice versa. With this adaptive
hop networks, and to design enhanced TCP proto- switching scheme, the friendliness of the standard
cols. First, we found that TCP does not always TCP and our proposed adaptive delayed ack scheme
benefit from arbitrary delaying of acks. In fact, for is significantly improved.
a given network topology and flow pattern, there Another challenge for TCP with adaptive
exists an optimal delay window size at the receiver, delayed ack comes from mobile ad hoc networks.
at which TCP achieves maximum throughput. Sec- Although delayed acks may potentially improve
ond, since 802.11 does not guarantee collision free TCP throughput regardless of underlying routing
packet 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 to
a 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. 1100 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116
mobility 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 cannot
erated. 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 in
ack loss issue in mobile networks. Meanwhile, the ad hoc multihop wireless paths [8]. Many research
performance of various TCP schemes are presented efforts have been made to adapt TCP to the unique
over 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 even
Greedy Perimeter Stateless Routing (GPSR) [7]. lower-layer assistance, for example, MAC support
The 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, typically
promising to be scalable, and robust to node 40 bytes, the transmission of TCP ack packets
mobility. 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 be
ack up to a certain number of data packets, we reduced, data packets would suffer less collisions
undergo a more complete and optimized study to resulting in higher throughput. Several approaches
understand 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 to
ios. 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 TCP
for both static/mobile wireless and hybrid networks, throughput is achieved when one ack acknowledges
and taking the ack loss and friendliness into account the full cwnd. However, the scheme did not address
as 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 will
lows. Background work is provided in Section 2. show in this paper, TCP does not always benefit
A 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 delayed
network topologies and traffic patterns. We present ack scheme which was further improved in [3] where
our 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 adjusts
cussed. 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 receiver
networks as well. Several enhancements are pre- delays acking until it receives a certain number of
sented to improve TCP-DCA’s efficiency and data packets, ranging from 2 to 4 packets. When
friendliness. Section 6 discusses a few issues to fur- there is no packet loss, the TCP-DAA receiver waits
ther improve TCP with untraditional delayed ack. for more data packets (up to 4) before generating an
We 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 sender
ered in proper sections. automatically cuts the cwnd when packet loss
occurs, i.e. automatically adapting to the channel
2. 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 performance.
in ad hoc network, packet loss caused by buffer In [3], the ack time is set to be one average packet
overflow is rare. Instead, it is more likely due to inter-arrival time. That is, an ack is generated when
medium contention as shown in [8]. The fundamen- no data packet arrives after one average packet
tal problem resides in the limitations of IEEE 802.11 inter-arrival time since last unacknowledged data
MAC. Since the interference range is usually longer packet. In wireless networks, the inter-arrival time

4. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1101
is 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 with
enough 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 fixed
delayed 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. Chandran
TCP-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-establishment
cwnd, which is fixed at four packets. The similar notifications to provide feedback to TCP, and thus
delay 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 improve
desires further clarification and improvement. First, throughput. Holland and Vaidya [10] evaluated an
although 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 over
and wireless network where a high bandwidth multi-hop ad-hoc networks. They studied the effect
delay product exists. Second, if the cwnd is not lim- of link failures due to mobility on throughput and
ited by four packets, the choice of a delay window showed through simulations that ELFN improves
size of 4 may no longer be suitable. In this paper, the performance of TCP. Xu et al. [11] proposed a
we address the above issues and provide more effec- Neighborhood RED (NRED) scheme, which
tive and general solutions that apply to various extended the RED concept to the distributed
environments. 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 with
the standard TCP, the congestion window increas- our mechanism for more robustness against packet
ing rate for delayed ack is slowed down. Such slower loss and TCP fairness.
probing rate improves TCP performance in ad hoc
networks, as reported in [13]. The conservative win- 3. TCP throughput vs. delay window
dow increase, however, hinders efficient transmis-
sion in wired network where delay bandwidth In this section, we investigate the impact of the
product 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 the
and 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 packet
there 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 that
window size does not lead to better performance. achieves maximum TCP throughput. We verify the
On 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 various
the optimal congestion window limit is determined flow patterns. Real testbed measurement results
based 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 delay
paper, we will show that in our scheme TCP-DCA, window limit to illustrate the impact of the delay
the 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. 1102 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116
3.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’s
bounded by a delay window limit, and also limited cwnd size to prevent delay window larger than cwnd
by the cwnd size to prevent the delay window from leading to unnecessary delaying at the receiver. To
exceeding the cwnd which results in delaying the address this problem, we propose two possible
ack, but for possibly non-existent packets. If data methods. One is to imbed the cwnd size in an option
packets arrive in order, the receiver generates one field of the packet header. The other is to reuse some
cumulative ack for every w data packets. If an out TCP header field. For example, the sender could
of order packet is received, or a packet that fills a reuse the advertised window field in data packet
gap 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 fact
receiver acks immediately to inform the sender of that current TCP connection is mostly used for
the packet loss/recovery in a timely manner. The one direction, i.e. there is only data packets from
receiver 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 is
ets. At the TCP sender, when it receives a cumula- usually wasted. Even if two-way TCP data is
tive ack acknowledging w data packets, it updates included, it is still possible to reuse the advertised
the cwnd and sends out a burst of at least w packets, window field, for example every other packet with
provided such packets are ready for transmission in one bit in the reserved field to indicate whether
the 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 to
tors the data packet inter-arrival interval and com- affect TCP-FDCA much since TCP-FDCA receiver
putes a smoothed interval through a low-pass does not need to know the exact cwnd so often, as
filter. The average inter-arrival interval is used to we will see later in the paper.
set the ack delay timer based on the current delay
window size. In TCP-FDCA, an accurate delay 3.2. Chain topology
timer is not needed and the timer is solely for fall
back 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 TCP
arrived data packets, not necessarily in-order pack- performance since TCP typically runs over a single
ets. 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) and
packets. A TCP-FDCA receiver smoothes such packets travel over the chain to the end node (node
inflated inter-arrival samples through a low-pass 6). The interference range is 550 m and transmission
filter range is 250 m. We place the nodes at 200 m inter-
vals, so that nodes are 4 hops away can transmit
I iþ1 ¼ bI iavg þ ð1 À bÞI s ;
avg ð1Þ
simultaneously without interference. Notice that a
where I avg is the average of inflated packet inter-ar- node that is 3 hops away is a ‘‘hidden node’’. IEEE
rival time (I s ). I avg is used to set delay ack timer (T w ) 802.11 is the underlying MAC. Data rate on the
which defines the total time for receiving a whole de- wireless channel is 2 Mbps and one simulation run
lay window of in-order data packets lasts 300 s. Each data point represents an averaged
result of 5 simulation runs with different random
T 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 TCP
tolerate high dynamic packet delay. Obviously, the protocol nowadays. The delay window limit applied
delay ack timer is rather inflated and quite robust at the TCP receiver ranges from 1 to the current
to high inter-arrival variation. In the paper, we cwnd size.

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
600
Fig. 1. Chain topology. The solid-line circle denotes a node’s 400
valid 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 node
1’s transmissions to node 2. (a) Path Length h ≤ 3
350
4hop
5hop
6hop
3.2.1. Single TCP flow 7hop
8hop
TCP performance over wireless multihop inevita- 9hop
bly depends on the path length (hop count). The
Throughput (Kbps)
300
longer the path is, the lower the throughput would
be. We present TCP-FDCA throughput as a func-
tion of delay window limits on a path with different
lengths in Fig. 2. Fig. 2a shows that when a sender 250
and a receiver are within 3 hops, TCP-FDCA gets
steady performance gain by increasing the delay
window size up to the entire cwnd size. For the
200
one hop case, the fastest throughput increase can 1 2 3 4 5 6 7 8 9 10 ...CW
be 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 >3
delay windows larger than 5 and the throughput
240
approaches the limit when the delay window reaches 10hop
12hop
the cwnd size (denoted by CW). The same trend is 230 14hop
16hop
also observed when the path length is 2 and 3. 220
18hop
20hop
The reason for this performance gain is that
Throughput (Kbps)
802.11 MAC provides nearly collision free packet 210
transmissions for short paths. Since the interference 200
range is larger than 2 times the transmission range,
190
when the sender and receiver are within 2 hops,
every node along the path can sense all other nodes 180
transmissions. In this case, no hidden nodes exist,
170
thus packet loss is minimal. When the hop length
is 3, the TCP receiver is the only node hidden from 160
1 2 3 4 5 6 7 8 9 10 ...CW
the 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 ≥ 10
can be interfered. The maximal performance gain
is achieved when the receiver acks after receiving Fig. 2. TCP-FDCA throughput vs. delay window on chain
all 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 the
transmission range, RTS/CTS cannot completely path becomes longer than 3 hops, packet collision

7. 1104 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116
is unavoidable. For example, node 1 and node 4 are ver are used for 802.11b devices and the devices are
interfering nodes in Fig. 1, so simultaneous packet set to ad-hoc mode. The topology of the testbed is a
transmissions on them will be interfered. The hidden chain and the route is statically configured. There is
terminal 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’’ to
Another 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, we
packets. 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 in
interfering. (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 1
it 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 and
FDCA 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 the
this tradeoff of TCP-FDCA performance gain with simulation results is below 10%. Such difference is
delay 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,
1600
however, since a TCP sender is able to recover 1hop
2hop
packet loss rather rapidly due to the small round 3hop
1400
trip 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
1000
more packet losses. Similar trend also exists for
paths longer than 5 hops, where TCP-FDCA 800
achieves throughput gain only when the delay win-
dow size is small; for large delay window size, delay- 600
ing ack cannot maintain throughput gain because of
excessive data packet losses. Further, now that RTT 400
is larger, TCP-FDCA spends more time detecting 1 2 3 4 5 ...CW
Delay Window Size (packets)
packet loss and recovering lost packets by entering
fast retransmit/recovery in which only one packet (a) 1 to 3 hop
is recovered per RTT. Therefore, for long paths, 370
large delay window is not preferred. 4hop
5hop
360
We also show TCP-FDCA performance over a
350
very long path h P 10 in Fig. 2(c) which has similar
results with Fig. 2(b). TCP-FDCA only gets perfor- 340
Throughput (Kbps)
mance gain for small delay window size. For large 330
delay window size, TCP-FDCA gets poor 320
throughput.
310
300
3.2.2. Real testbed verification
We investigate the effectiveness of our TCP- 290
FDCA in an actual ad-hoc network testbed. Our 280
testbed consists of six laptops equipped with Ori- 270
noco 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 hop
tion 7 with kernel version 2.4.3. Linux PCMCIA
package 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. 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
500
packets to overcome the hidden terminal problem 3hop
5hop
only if the packet size is above the minimum thresh- 7hop
450
old 256 bytes. Since the size of TCP ack packet
Aggregate Throughput (Kbps)
(40 bytes) is below the minimum RTS/CTS threshold
400
in Linux settings so that no RTS/CTS handshake is
performed when transmitting acks in testbed experi-
350
ments. Compared with simulation results where
RTS/CTS is always performed regardless of packet
300
size, such ‘‘zero’’ MAC overhead in testbed measure-
ments has impact on the performance: the through-
250
put gain derived from TCP-FDCA in the testbed
measurements is lower than the corresponding results
200
in the simulations because of the lack of RTS/CTS 1 2 3 4 5 6 7 8 9 10 ...CW
reduction 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 chain
and in testbed measurements. topology (5 flows).

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 Topology
Fig. 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 to
tive 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 paths
receiver retransmission scheme is proposed. (3 < h 6 9), therefore the delay window could be
slightly larger for such paths. TCP-DCA receiver
4.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 path
size on different path lengths. Inspired by this obser- length.

10. J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116 1107
Table 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, and
Path length (h) Delay window limit canceled after receiving a data packet.
h63 Congestion window Until now all previous results were obtained
3<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. Mostly
4.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 to
TCP-DCA, due to the cumulative property of the observe the sole impact of the delay window on
ack, 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 unless
the ack loss in standard TCP is not serious. How- explicitly mentioned.
ever, the number of acks in TCP-DCA is much less
than standard TCP, and thus an ack loss has more 5. Performance evaluation
negative impact on TCP-DCA performance. In
order to be robust to ack loss, a retransmission This section presents the TCP-DCA performance
timer at the receiver is adopted to retransmit a over wireless and hybrid networks. First, we show
cumulative 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 on
sion 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, we
since 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 improve
receiver 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 with
inflated 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 network
a coarse timer for predicting when to retransmit
acks, an accurate RTT measurement is not required In this section, we show TCP-DCA performance
and thus an inflated RTT can be tolerated. In the in static ad hoc networks. Meanwhile, we compare
paper, the timestamp option is used to estimate TCP-DCA with TCP-DAA and TCP-Newreno
the 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 ‘‘original
time based on this RTT measurement. We use the TCP’’ for TCP-Newreno without standard delayed
following formula to calculate the retransmission option, and TCP-STD-DA for TCP-Newreno with
timer 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 major
RTTvar ¼ RTTvar þ jRTTr À SRTTr j;
kþ1 k kþ1 kþ1
4 4 differences between TCP-DAA and TCP-DCA are
r r var
RTOkþ1 ¼ SRTTkþ1 þ 4 Â RTTkþ1 ; listed in Table 2. For fair comparison, most simula-
tions scenarios presented in this subsection were
where 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-DCA
at the receiver. The minimum value of the retrans- in the chain topology with different hop count and

11. 1108 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116
Table 2
Design difference
TCP-DAA TCP-DCA
Sender 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 header
Receiver Delay window is adaptive from 2 and 4 based on loss event Delay window is adaptive on the path
length
number of concurrent flows. Although TCP-DCA is CWL and TCP-DAA achieve best performance
designed without cwnd limit, we include TCP-DCA and their difference is small. They provide better
with cwnd limit at 4 in this experiment, named TCP- performance, about 10–25%, than the standard
DCA-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, the
set to 4 by default. Fig. 8a shows the performance variance of results is very small (less than 5%) so we
of 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 optimal
since each TCP-DCA generates as few acks as pos- cwnd size could actually increase (for details, please
sible, the advantage of TCP-DCA is obvious. When refer to [14]). Although it may be interesting to
more flows coexist, the cwnd of each flow becomes investigate the optimal cwnd for TCP-DCA, we
smaller since they compete for the bandwidth, thus do not pursue it because our ultimate goal to design
the benefit of delayed ack reduces because more TCP-DCA without cwnd limit. Moreover, this
acks are generated. If the cwnd is below the cwnd property makes TCP-DCA distinct since selecting
limit in TCP-DCA-CWL, they have similar perfor- an optimal cwnd is non-trivial, which needs to know
mance. The performance of TCP-STD-DA is better a lot of underlying information to accomplish. For
than 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 layer
vides 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 of
to 15% improvement over TCP-DAA, and 25% over wireless networks, such as that TCP with cwnd limit
TCP-STD-DA respectively. Fig. 8b–c show the per- in wired and wireless scenario does not perform well
formance of TCP-DCA on a 5 and 7 hop path. The (will be shown in Section 5.4). Taking this into
same 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 in
Fig. 8a, the cwnd limit could considerably restrict 5.2. Mobile ad hoc network
the TCP performance as the number of flows is
small. For a long path in Fig. 8b–c, the cwnd limit We have demonstrated that applying delayed ack
only 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 our
cwnd limit is better than that of TCP-DCA-CWL in delayed ack scheme is not specifically designed for
most situations. It indicates that TCP-DCA can the TCP in mobile network, we show that our
achieve 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 40
of original TCP, TCP-STD-DA, TCP-DAA, TCP- nodes randomly moving within a 1000 m · 1000 m
DCA-CWL and TCP-DCA, and we observe the area. Each node moves with the same speed without
similar results as before. TCP-DCA, TCP-DCA- pause. The Random Waypoint mobility model [18]

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 other
Fig. 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 is
is used. All results displayed are calculated as the unsurprisingly consistently better than the original
average of 40 runs with the same traffic pattern, TCP without delayed ack. However, TCP-DAA

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 to
ent 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 different
performance 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-DCA
der 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 idle
from entering long timeout due to the severe packet time with other TCP variants, which confirms that
loss event. In Fig. 10, we also show the result of retransmission scheme is effective in improving
TCP-DCA without ack retransmission (TCP- TCP performance in mobile networks.
DCA-ACK-LOSS) to confirm the effectiveness of
ack 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 fact
other hand, the ack retransmission does not help could become unreliable and error-prone. After
much when packet loss is not severe (e.g. TCP over studying the performance of TCP-DCA under
GPSR). Therefore, TCP-DCA only incurs more ack packet losses in mobile networks, we investigate its
retransmission overhead when needed, and works performance under lossy wireless link. BER (bit
well 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 worth
In a mobile network, the loss of packets (or acks) pointing out that when a packet is received with
may be caused by temporary route loss as well as bit error, the IEEE 802.11 MAC layer helps in
network congestion. Higher mobility causes more recovering packet loss by retransmissions until a
route loss and thus more packet losses. Since routes maximum retransmission limit is reached [19] or
are likely to be lost frequently in high node mobility retransmission is successful. Therefore, when BER
environments, and different routing algorithms have is low, the MAC retransmission scheme can easily
different 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 heavy
different 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 flow
leading to poor TCP performance, especially for goes through 5 hop chain path under varying
TCP with untraditional delayed ack where fewer BER from very low BER to high BER. Each bar

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 in
is an averaged result of 20 random runs. Overall, the RFC2581 [1]. However, this approach potentially
performance 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 be
DAA 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 that
ants gracefully reduce their performance and the the hop count information from the packet header
variance of results increase. is no longer accurate for the wireless hops since it
includes the wired path. It is possible for a wireless
5.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 be
and wireless ad hoc environment. Since wired net- available all the time.
work has abundant bandwidth, it demands a much To address the problems in hybrid networks, we
larger 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 the
tion, 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. 1112 J. Chen et al. / Ad Hoc Networks 6 (2008) 1098–1116
The receiver-side probe works as follows: First Table 3
the receiver passively estimate the wireless band- IEEE 802.11b MAC overhead (with long preamble), L is packet
size, R is capacity
width and minimum RTT. Second it computes the
equivalent hop count based on the minimum RTT Data frame 192 ls + 8L/R
and wireless bandwidth, then the previous hop SIFS 10 ls
count 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/R
to-end hybrid path bandwidth at the TCP receiver. ACK 192 ls + 112/R
CapProbe [21] is a recently proposed bottleneck
capacity and path rate estimation technique shown
to be both fast and accurate. It combines the use
Table 4
of time interval measurements and end-to-end delay
Delay window at TCP-DCA receiver (delay-based, wireless
measurements 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 limit
last-hop wireless networks. Inspired by CapProbe,
RTTmin < 18 Congestion window
we proposed a new approach at the TCP-DCA
18 6 RTTmin 6 60 5
receiver without triggering any probing traffic. The RTTmin > 60 3
idea is that after the receiver sends a cumulative
ack, the sender would send a burst of packets. The
burst of packets can just serve as the packet pair
probing. Since the receiver knows the sequence
number of the first burst packets, it can identify
the packet pair and estimate the bandwidth when Internet BS 1 2
packet pair arrives. Our approach is based on the
CapProbe, but it is different with CapProbe. First Fig. 13. Hybrid wired/wireless topology.
our approach is imbed at the TCP receiver without
any additional probing traffic. Moreover, our
approach is a one-way (instead of round-trip in
CapProbe) estimation technique, and it is expected 1500
TCP-DCA
TCP
to work for wired, hybrid and purely wireless TCP-STD-DA
TCP-DAA
networks.
The other challenge is to estimate the minimum
Throughput (Kbps)
1000
RTT at the receiver, but this have been solved as
described in Section 4.2. After the wireless bandwidth
and minimum RTT is obtained, the receiver derives
the equivalent hop count by considering the TCP
500
data and ack packet sizes. For example, with wireless
bandwidth of 2 Mbps, data packet size of 1000 bytes
and ack size of 40 bytes, the minimum RTT for a 1
wireless hop path is about 6 ms considering various
0
overhead, such as header overhead at TCP (20 bytes), 1 hop 2 hop
IP (20 bytes) and MAC (34 bytes) and MAC layer Wireless Hop Count
fixed overhead shown in Table 3 (for details, please Fig. 14. Wired and wireless performance.
refer to [22]). In Table 4, we listed the delay window
size 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 we
wireless hops. The one-way propagation delay on omit its error bar results. Since TCP-DAA limits
the 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 cases
without standard delayed ack option) shown in of 1 and 2 hop paths. Therefore, TCP-DCA is
Fig. 14, represents averaged result of 10 simulation extensible to hybrid networks instead of working