A Feedback Based Scheme For Improving TCP Performance In
Ad-Ho c Wireless Networks
Kartik Chandran Sudarshan Raghunathan S. Venkatesan
Ravi Prakash
Computer Science Program
University of Texas at Dallas
Richardson, TX 75083-0688
e-mail:
f
chandran,rsud,venky,ravip
g
@utdallas.edu
Abstract
Ad-hoc networks are completely wireless networks of
mobile hosts, in which the topology rapid ly changes
due to the movement of mobile hosts. This frequent
topology may lead to sudden packet losses and delays.
Transport protocols like TCP have been built mainly
for reliable, xed networks. Hence, when used in ad-
hoc networks, TCP misinterprets this loss as conges-
tion and invokes congestion control. This leads to un-
necessary retransmissions and loss of throughput. To
overcome this problem, a feedback scheme is proposed,
so that the sourcecan distinguish between route failure
and network congestion. When a route is disrupted,
the source is sent a Route Failure Notication(RFN)
packet, al lowing it to freeze its timers and stop sending
packets. When the route is re-established, the source
is informed through a Route Re-establishment Noti-
cation (RRN) packet, upon which it resumes by un-
freezing timers and continuing packet transmissions.
The simulated performance of TCP on ad-hoc net-
works with and without feedback is compared and re-
ported. It is observed that in the event of route fail-
ures, as the route re-establishment time increases, the
use of feedback provides signicant gains in through-
put as wel l as savings in unnecessary packet transmis-
sions. Several further enhancements and directions for
future work are also sketched.
1 Intro duction
Ad-hoc networks consist of a set of mobile hosts com-
municating amongst themselves using wireless links,
without the use of any other communication supp ort
facilities (such as base stations). They are also called
This work was supp orted in part bytheTexas Advanced
Technology Program under GrantNo. 9741-052 and by NSF
under Grant No. CCR-9796331.
mobile radio networks or multi-hop wireless networks.
Two mobile hosts (MHs) are said to be within range
andsaidtobe neighb ors of each other if each can re-
ceive the other's transmission. Every MH behaves in
a co-op erative fashion by acting as a router allowing
packets destined to other MHs to pass through it.
The topology of an ad-hoc network changes every time
a mobile host's movement results in establishment
of new wireless links (mobile host moves within the
range of another) or link disconnections (mobile host
moves out of the range of another whichwas within its
range). The rate of top ology change is dep endenton
the extent of mobility of the hosts and the transmis-
sion range of the hosts. Routes are heavily dependent
on the relative location of MHs. Hence, routes may
be repeatedly invalidated in a sp oradic and arbitrary
fashion due to the mobility of hosts. The mobilityofa
single no de may aect several routes that pass through
it.
Ad-hoc networks have b een studied extensively in the
context of routing and a number of routing proto cols
have b een prop osed for ad-hoc networks including dis-
tance vector schemes [16], link reversal [6], TORA [15],
dynamic source routing [11], routing using a virtual
backbone [7], zone routing [9] and cluster based rout-
ing [13].
In this pap er, we consider the problem of maintain-
ing
reliable end-to-end communication
in ad-ho c
networks, similar to that provided by TCP over the
Internet. The end-to-end communication problem has
been studied in the context of cellular wireless net-
works and anumber of mo dications and extensions
to regular TCP for such networks have been prop osed
[1,2,3,4,18,19]. It is desirable to use TCP directly
even in ad-hoc networks in order to provide seam-
less p ortability to applications like le transfer, email
and WWW browsers written using standard TCP li-
braries. Hence, it is of interest to study the behavior
of TCP in the context of ad-hoc networks and evaluate
the eect of the dynamic top ology on TCP's p erfor-
mance in order to determine whether it is feasible to
use TCP as it is in the ad-ho c network domain. Our
preliminary studies and results indicate that as a re-
sult of frequent and unpredictable route disruptions,
TCP's p erformance is indeed substantially degraded
both in terms of throughput and go odput (the ratio
of useful data received at the destination and the to-
tal data transmitted by the source) [3]. We therefore
propose a
feedback based
scheme for overcoming this
problem. Our simulation experiments show that the
use of feedbackmechanisms along with TCP can result
in substantial p erformance improvements.
Section 2 describes the ad-ho c network mo del and as-
sumptions. Section 3 discusses the behavior of TCP in
ad-hoc networks and Section 4 explains the proposed
approach for improving TCP p erformance. In Section
5, the simulation model, exp eriments and observations
are presented and discussed, followed by conclusions
and prop osed future extensions in Section 6.
2 Mo del and Assumptions
For the forthcoming discussions, we make the follow-
ing assumptions:
1. An ad-hoc network consists of
n
MHs, each of
which is equipp ed with wireless communication
capability. Each MH broadcasts its packets on the
wireless channels. No assumption is made about
the medium access proto col.
2. The wireless links are bidirectional. This implies
that all the mobile hosts have the same trans-
mission range. Otherwise, the
weaker
hosts can
receive the transmissions of
stronger
hosts but not
vice versa, if they are suciently far away.
3. A reliable data link layer proto col is implemented
over the unreliable wireless links by using, say,
link level acknowledgement and retransmission.
Therefore, we assume that if a packet cannot b e
delivered at the link layer, the higher layers will
be duly informed.
4. A suitable routing proto col from among those
mentioned in Section 1 is implemented to estab-
lish and maintain routes b etween a source and a
destination. We will require the routing proto col
to perform certain actions in addition to forward-
ing packets, whichmay include sending feedback
messages to transport entities. The routing pro-
tocol may maintain redundantroutesbetween dif-
ferent sources and destinations.
5. When a packet cannot b e sent on a link despite
the presence of a reliable link layer proto col, we
treat the situation as the failure of the link due to
mobility. The routing protocol is then responsible
for adapting and maintaining routes between all
sources and destinations. We assume that when
a route failure occurs, a
nite time elapses until
the route is restored
and communication can be
resumed.
6. All packets carry the source and destination id's
so that the network layer can identify the source
and destination address of each packet.
3 TCP in Ad-ho c Networks
TCP is a reliable, stream-oriented transp ort layer pro-
tocol which has b een designed for use over xed, low
error networks like the Internet. Route failures and
disruptions are very infrequent as the network is xed.
Therefore, packet loss, which is detected by TCP as a
timeout, can be reliably interpreted to b e a symptom
of congestion in the network; in resp onse, TCP invokes
congestion control mechanisms [10, 12, 17]. In other
words,
TCP does not distinguish between congestion
on the one hand and packet loss due to transmission
errors or route failures on the other
. This inability
of TCP to distinguish b etween two distinct problems
exhibiting the same symptom results in performance
degradation in ad-ho c networks, as described later in
the section.
In an ad-hoc network, packet losses are frequentinthe
error-prone wireless medium, but the eect of these
losses can b e reduced using reliable link layer proto-
cols. The greater problem is that of route failures,
which can occur very frequently and unpredictably
during the lifetime of a transport session, depending
on the relative motion of MHs in the network. In
general, whenever the mobility of an MH invalidates
a route(s), the re-establishment of the route by the
underlying routing proto col will take a nite amount
of time. During this p eriod of time, no packets can
reach the destination through the existing route. This
will result in the queuing and p ossible loss of pack-
ets/acknowledgements. This in turn will lead to time-
outs at the source which will be interpreted by the
transport proto col as congestion.
Consequently the source will:
1.
Retransmit
unacknowledged packets upon timing
out.
2. Invoke
congestion control
mechanisms that in-
clude exponential backo of the retransmission
timers and immediate shrinking of the window
size, thus resulting in reduction of the transmis-
sion rate.
3. Enter a slow start recovery phase to ensure that
the congestion has reduced b efore resuming trans-
mission at the normal rate.
This is undesirable for the following reasons:
When there is no route available, there is no need
to retransmit packets that will anyway not reach
the destination.
Packet retransmission wastes precious MH bat-
tery p ower and scarce bandwidth.
In the p eriod immediately following the restora-
tion of the route, the throughput will be unnec-
essarily low as a result of the slow start recovery
mechanism even though there is actually no con-
gestion in the network.
4 A Feedback Based Approach
From the preceding discussion, it is clear that treat-
ing route failure as congestion and invoking conges-
tion control is not advisable as
congestion control and
route failure are disparate phenomena which have to
be hand led independently and separately
. Therefore,
we propose a scheme bywhich the source is informed
of the route failure so that it does not
unnecessarily
invoke congestion control and can refrain from sending
any further packets until the route is restored
. Feed-
back based schemes for TCP have already been pro-
posed in the form of explicit congestion notication
(ECN) [8] for xed networks and EBSN [3] in cellular
networks. As we do not haveareliable backbone in
case of ad-hoc networks, neither of these metho ds is
directly applicable in our case. Therefore, we propose
a feedback based scheme for handling route failures in
ad-hoc networks termed as
TCP-Feedback
or TCP-
F, which is described below:
Consider, for simplicity, a single bulk data transfer
session, where a source MH is sending packets to a
destination MH. As soon as the network layer at an
intermediate MH (henceforth referred to as the failure
point or FP) detects the disruption of a route due to
the mobilityofthenext MH along that route, it ex-
plicitly sends a
Route Failure Notication (RFN)
packet to the source and records this event. Each
intermediate no de that receives the RFN packet in-
validates that particular route and prevents incom-
ing packets intended for that destination from passing
through that route. If the intermediate no de knows
of an alternate route to the destination, this alternate
route can now be used to support further communi-
cation and the RFN is discarded. Otherwise, the in-
termediate no de simply propagates the RFN towards
the source.
On receiving the RFN, the source goes into a
snooze
state and p erforms the following steps:
1. It completely stops sending further packets (new
or retransmissions).
2. It freezes (i) all of its timers, (ii) the send window
of packets (iii) values of other state variables such
as retransmit timer value and window size and
(iv) starts a
route failure timer
which corresp onds
to a worst case route reestablishment time. The
timeout value of this timer can be a parameter
whose value dep ends on the underlying routing
protocol.
The source remains in this snooze state until it is no-
tied of the restoration of the route through a
Route
Re-establishment Notication (RRN)
packet as
explained b elow:
Let one of the intermediate no des that has previously
forwarded an RFN to the source, learn ab out a new
route to the destination (through a routing update).
This intermediate no de then sends an RRN packet to
the source (whose identity it had previously stored).
All further RRNs received by this intermediate node
to the same source are discarded. Any other node
that receives the RRN simply forwards it towards the
source.
As soon as the source receives the RRN, it changes
to an active state from the sno oze state - it restarts
the timers from their frozen values (and do es not
reset
the timers) and resumes the transmission based on the
stored sender window and timeout values. These steps
in eect reduce the eect of TCP's congestion control
mechanism when transmission re-starts. Communi-
cation now resumes at the same rate as that b efore
the route failure occurred. The route failure timer en-
sures that the source do es not indenitely remain in
the sno oze state waiting for an RRN which may be
delayed or lost.
Wehave conducted simulation exp eriments based on
TCP-F and have compared it with basic TCP. Our re-
sults, which are describ ed in the next section, suggest
that our approach results in signicantimprovements
in throughput as well as go odput.
5 Simulated Performance
5.1 Simulation Mo del
To study the b ehavior of TCP and compare its perfor-
mance with that of the proposed TCP-F mechanism,
we simulated a single unidirectional bulk transfer ses-
sion. The source sends a continuous stream of data to
the destination through the ad-ho c network. Since we
are only interested in studying transp ort protocol b e-
havior, we view the network as a
black box
(containing
a xed numb er of nodes between source and destina-
tion) that emulates the b ehavior of an ad-hoc network
from the viewp oint of a transp ort entity. The recong-
uration of the network (due to the movement of MHs)
manifests itself in the form of route failures and route
re-discoveries. The transp ort entity sees this eect
in the form of sudden packet losses and delays. The
actual lo cation of the route failure is a random param-
eter and route re-establishment time and frequency of
failures are parameters of the simulation. No assump-
tion is made about the routing proto col used by the
underlying network layer.
5.2 Implementation
Simulation Parameters:
For our exp eriments, we
use a xed packet size of 200 bytes and data rate
of 12.8 Kbps which are reasonable values for wireless
networks [3].The number of hops b etween the source
and destination is set to 10 and the corresp onding
window size is 4 KBytes (20 packets). We have as-
sumed that the network in our simulation does not
suer from congestion. Consequently,anypacket loss
is attributed to route failure only. The input param-
eters to the simulation are the
failure rate
(number
of failures in the total time of simulation) and
route
re-establishment delay (RRD)
.The simulation is
carried out for a p eriod of 100 seconds.
The simulation is event-driven and proceeds as follows:
\Transmission" of a packet leads to a SEND eventat
the source which in turn schedules an ACK event and
a TIMEOUT event. The timestamp of the ACK event
is calculated as follows:
t
AC K
=
t
SEN D
+ delay based
on numb er of hops, data rate and packet size + ran-
dom variance (of upto 10% of total time to account
for packet delays). The timestamp of the TIMEOUT
event is based on TCP's timeout estimation mecha-
nism. Dep ending on the conditions as describ ed be-
low, one of the aboveevents (ACK/TIMEOUT) will
be valid and the other event is then discarded. In
order to simulate the reconguration of the network
due to mobility, route failure events are p eriodically
generated. The route is \re-established" after a de-
lay corresp onding to the RRD. Based on the current
time instant, location and duration of the failure and
the timestamp of a SEND event, we can determine
whether a packet reached the destination successfully
and if an ACK was successfully received at the source.
Once we have determined which packets are \lost",
their ACK events are then deleted from the event
queue.
Over this mo del, we implemented basic TCP (along
with it's retransmission scheme) and the prop osed
TCP-F. We then ran the simulation for both cases
using dierent values of failure interval (i.e. number
of failures in the perio d of observation) and route re-
establishmentdelay (RRD). It was ensured that b oth
TCP and TCP-F were simulated under the same con-
ditions.
5.3 Observations
Figure 1shows the behavior of TCP with and without
feedback as a function of RRD. The graph indicates
that TCP-F performs much better than TCP as the
value of RRD increases. This is because as the RRD
value increases, more packets and acknowledgements
are lost due to route failure, leading to more timeouts
and greater exponential backo in case of TCP,which
drastically aects p erformance. By using feedback,
TCP-F is able to control this backo by ensuring that
the sender's state is frozen for a substantial p ortion of
the route failure perio d, during whichitdoesnotre-
spond to timeouts. Figures 4 and 5 for an RRD value
of 2 seconds and with 5 failures distributed uniformly
during the simulation time, clearly illustrate the above
behavior. We also found that the
improvement in per-
formance of TCP-F over regular TCP increases with
data rate
. The intuitive explanation for this is that for
agiven time interval, the number of packets passing
through the network increases with data rate. Conse-
quently, if we consider a failure that lasts
t
seconds,
the number of packets that are lost in time
t
increases
with data rate, which leads to further performance
degradation in TCP. Therefore,
as data rates in wire-
less media increase, feedback is likely to provide even
greater benets
.
0.6
0.7
0.8
0.9
1
1.1
1.2
1.3
1.4
1.5
0 0.5 1 1.5 2 2.5 3
Throughput (KBytes/s)
Route re-establishment delay (RRD) (seconds)
4 Failures: TCP
4 Failures: TCP-F
0
2
4
6
8
10
12
0 0.5 1 1.5 2 2.5 3
Percentage of retransmitted packets
Route re-establishment Delay (RRD) (seconds)
4 Failures: TCP
4 Failures: TCP-F
Figure 1: Throughput and retransmissions for 4 failures with data rate of 12.8 Kbps
0.5
0.6
0.7
0.8
0.9
1
1.1
1.2
1.3
1.4
1.5
0 0.5 1 1.5 2 2.5 3
Throughput (KBytes/s)
Route re-establishment delay (RRD) (seconds)
7 Failures: TCP
7 Failures: TCP-F
0
2
4
6
8
10
12
14
0 0.5 1 1.5 2 2.5 3
Percentage of retransmitted packets
Route re-establishment Delay (RRD) (seconds)
7 Failures: TCP
7 Failures: TCP-F
Figure 2: Throughput and retransmissions for 7 failures with data rate of 12.8 Kbps
5.4 Discussions
The use of feedback raises some interesting issues that
are discussed b elow.
1.
Eect of multiple failures on the same route:
It is
always p ossible that multiple route failures o ccur
independently along dierent links of the route.
This is however not a serious concern in case of
TCP-F as the source will then receive an RFN
from the nearest FP and b ehave accordingly. The
communication will then resume only after the
source receives an RRN from that FP, which
means that the route has b een restored.
2.
The eect of congestion on the feedback mecha-
nism:
It is p ossible that in a congested network,
the RFN and RRN packets may be lost or de-
layed. However, this is not a concern since ba-
sic TCP at the source will detect congestion and
invoke congestion control. This behavior is de-
sirable as we are only attempting to distinguish
packet loss due to congestion from that due to
route failure; we are not interfering with TCP's
congestion control mechanism in anyway.
3.
Eect of failure on multiple transport connec-
tions:
In the current discussion, we have con-
sidered a single transp ort connection in the sim-
ulation analysis. However, in a real life situa-
tion, there maybeanumb er of transport connec-
tions that use the same route/link. Thus, a single
route/link failure is likely to aect a number of
transport connections. This raises the following
questions:
(a) Howdowe determine all sources aected by
the failure ?
(b) Howdowe inform these sources?
