TCP Performance over Mobile Ad-Hoc
Networks
236340
Summer 2003
Submitted by:
Roy Dayagi 033454554
Uri Silberstein 034929505
Nir Hasson
038680344
2:14
TCP Performance over ad-hoc mobile networks.
1
Contents
1
2
Project motivation. ...............................................................................3
TCP Configurations and routing protocols used in project. ...............3
2.1
2.2
3
Simulation methodology.......................................................................6
3.1
3.2
3.3
3.4
4
Selective ACK conclusions.......................................................................... 18
Limited transmit conclusions. ...................................................................... 18
Explicit Congestion Notification (ECN), conclusions. ................................ 19
Topology size. .............................................................................................. 20
Future Work. ......................................................................................21
6.1
6.2
7
General Description. ...................................................................................... 7
Test runs description. ..................................................................................... 7
Results graphs. ............................................................................................... 7
Conclusions. .......................................................................................18
5.1
5.2
5.3
5.4
6
Overview of Constant parameters. ................................................................. 6
Scenarios description. .................................................................................... 6
Problems encountered. ................................................................................... 6
Throughput calculation. ................................................................................. 6
Simulation Results ................................................................................7
4.1
4.2
4.3
5
TCP Configurations. ...................................................................................... 3
Routing protocols. .......................................................................................... 4
Explicit Loss Notification (ELN)................................................................. 21
Signal Stability based Adaptive (SSA). ....................................................... 21
References. .........................................................................................22
2:14
TCP Performance over ad-hoc mobile networks.
2
1 Project motivation.
A wireless ad hoc network is a collection of autonomous nodes or terminals that
communicate with each other by forming a multihop radio network and
maintaining connectivity in a decentralized manner. Since the nodes
communicate over wireless links, they have to contend with the effects of radio
communication, such as noise, fading, and interference. Each node in a wireless
ad hoc network functions as both a host and a router, and the control of the
network is distributed among the nodes (there is no fixed base station or access
point that corresponds to the last hop wireless model). The network topology is in
general dynamic, because the connectivity among the nodes may vary with time
due to node departures, new node arrivals, and the possibility of having mobile
nodes. These characteristics of ad hoc networks face a problem for the TCP
protocol, which was primarily designed for wireless networks, which their
topology is much less dynamic, and therefore have more predictable nature.
An example for that is the congestion guesswork that the TCP protocol doing for
deciding if congestion did acquired. One of the signs that cause TCP to conclude
that congestion exists is a packet loss due to timeout. In wire line networks it is
rare that the reason for the loss did not caused by congestion (but because of bit
error for instance) in ad hoc networks that is not the case, the reason for the loss
are variant and not necessarily result of congestion (the packet may not even be
lost).
In this example we can see that a different strategy is needed to be implement in
the TCP protocol for the guesswork.
This gap between the current TCP protocol and the different environment that he
needed to be used (ad hoc networks) brings to performance degradation and
require adapting the protocol.
Our goal is to investigate several changes in TCP protocol over several routing
protocols analyze the performance, and to find a technique that improves the TCP
protocol behavior over a specific routing protocol.
2 TCP Configurations and routing protocols used in project.
2.1 TCP Configurations.
Our purpose in our work is to improve TCP performance in ad-hoc mobile
networks in a end to end approach, for this reason we were limited to TCP
features in order to improve the ad-hoc mobile network performance. In addition
our work relies on the ns and its abilities, therefore only TCP features which are
supported by the ns, were taken into account.
The following TCP configurations were used in project:
 Selective Acknowledgments (SACK) and Delayed Ack.
TCP SACK is a protocol enhancement, which allows receivers to specify
precisely which segments have been received, even in the presence of
packet loss. This allows the sender to overcome a multiple packet loss
2:14
TCP Performance over ad-hoc mobile networks.
3
situation.
 Explicit Congestion Notification (ECN).
In current TCP/IP networks, TCP relies on packet drops as the indication
of congestion. The TCP source detects dropped packets either from the
receipt of three duplicate acknowledgements (ACKs) or after the timeout
of a retransmit timer, and responds to a dropped packet by reducing the
congestion window. ECN idea is that the router will signal the
development of the congestion before a packet has to be discarded
The benefit is that the offered load is reduced without experiencing a
packet loss and a time out.

Limited Transmit.
In the Limited Transmit algorithm when two consecutive ACKs for the
same segment are received, a new segment is transmitted if the receiver
advertised window allows and if the amount of outstanding data is equal or
less than the congestion window plus two.
The main idea is to trigger the Fast Retransmit algorithm; even if there is
less then three duplicate ACKs (this is helpful in cases where the
congestion window is too small for the sender to receive three duplicate
ACKs) and by doing so avoid Retransmission Timeouts (RTOs).
2.2 Routing protocols.
Four routing protocols were used over the project – the DSR , DSDV, AODV and
TORA (see details in the following section). DSR considered having the second
best throughput performance according to research done by IBM India Research
Labs (SSA wasn’t chosen because it doesn’t supported by the ns). On the other
hand, DSDV found to have the worst throughput performance by the research, it
was used in our work from two reasons:
o It seems to be the protocol that needs a real boost in its performance.
o The ns supports ECN over this protocol.

Dynamic Source Routing (DSR)
Dynamic Source Routing employs source routing where in the source
determines the complete sequence of nodes through which a packet is to be
routed. Whenever a source has a packet to transmit, it checks its routing table
for a route to the destination. In case a route is not found then a route request
broadcast is initiated. On receiving this request, each node again broadcasts
this request by appending its address to the request packet until this packet
reaches the destination. The destination replies to the first request that reaches
it. It sends a route reply to the source containing the route from the source to
the destination. When this packet reaches the source a connection is
established and all subsequent packets contain the complete route in the packet
header. No routing information is maintained at the intermediate nodes. When
the data link layer at a particular node encounters a transmission failure, it
issues an error notification to the source and a new route search is initiated.

Destination Sequenced Distance Vector (DSDV).
2:14
TCP Performance over ad-hoc mobile networks.
4
In Destination Sequenced Distance Vector routing, each node maintains a
routing table wherein the next-hop information for each reachable destination
is maintained. Every node in the network periodically broadcasts its routing
table with monotonically increasing sequence numbers. An update is done
using the Bellman-Ford algorithm. A broken link can be detected if no
broadcasts have been received from the node for a while. On detection of a
broken link, all routes passing through that hop are assigned an infinity metric.

Ad-hoc On-demand Distance Vector (AODV).
Ad-Hoc On-demand Distance Vector routing [3] algorithm borrows its salient
features from DSR and DSDV. When a source needs a path to the destination,
it broadcasts a route request message enclosing a monotonically increasing
broadcast id and the last known sequence number to that destination. The
route request is broadcast until it reaches a node that has a route to the
destination with the destination sequence number higher than that enclosed in
the request. A route request propagating through the network establishes the
next-hop information for the reverse route to the source. A route reply
generated by the destination propagates along the reverse route and establishes
the forward route information at the intermediate nodes. Each node records
only the next hop for a destination and not the entire route as done in source
routing. Routing table information in AODV is restricted to the active nodes.
A neighbor is considered active if it originates or relays at least one packet for
the destination within the most recent active timeout period. Failure of a link
can be detected via hello messages or link layer detection. When a link goes
down, the upstream nodes are notified of the failure that destination is marked
as unreachable in the routing tables of these nodes.

Temporally Ordered Routing Algorithm (Tora).
Tora is a distributed routing protocol based on "link reversal" algorithm. At
every node a separate copy of TORA is run for every destination. When a
node needs a route to a given destination it broadcasts a QUERY message
containing the address of the destination for which it requires a route. This
packet travels through the network until it reaches the destination or an
intermediate node that has a route to the destination node. This recipient node
then broadcasts an UPDATE packet listing its height wrt the destination. As
this node propagates through the network each node updates its height to a
value greater than the height of the neighbor from which it receives the
UPDATE. This results in a series of directed links from the node that
originated the QUERY to the destination node. If a node discovers a particular
destination to be unreachable it sets a local maximum value of height for that
destination. Incase the node cannot find any neighbor having finite height wrt
this destination it attempts to find a new route. In case of network partition, the
node broadcasts a CLEAR message that resets all routing states and removes
invalid routes from the network.
2:14
TCP Performance over ad-hoc mobile networks.
5
3 Simulation methodology.
3.1 Overview of Constant parameters.
In our work, we have used simulations to study the performance of TCP over adhoc mobile networks. We have carried out the simulations in a network simulator
(ns version 2.26/19) from Lawrence Berkeley National Laboratory (LBNL).
Over the simulations we have used some constant parameters in order to give a
common base, so a comparison between the TCP configurations could be done.
3.2 Scenarios description.

Environment configuration.
There are some crucial environment parameters (area size, total nodes
number, number of TCP connections and nodes’ velocity) that affect the
TCP performance dramatically over ad-hoc mobile networks. In order to
explore the TCP configuration’s effect, we have created various scenarios,
which are differing, only in some of the above parameters.
TCP performance is sensitive to frequent topology change and congestion.
All the above parameters have direct effect over topology and congestion,
and for that reason we have changed those parameters in our scenarios.

Automatic Scenarios Generator.
During our work, we faced a real need for an automatic tool, which
generates enormous amount of random scenarios differing in chosen
parameters. A tool for that purpose was developed, called ‘ automatic
scenarios generator’.

VB program, and work mode.
The ASG tool generates the scenarios in the following way; it generates
random initial positions for all the nodes, generates random movements
and of course sets the desired TCP configuration.
In order to have accurate analysis, the ASG generates as many random
scenarios as needed, and allows us to save the scenario and its output files.
ASG demo:
3.3 Problems encountered.
During our work we discovered the abilities and the limitations of the ns, such
as: number of sources and total nodes on single scenario, DSDV routing
protocol failed to run properly on NT version of the ns.
We wanted to use ECN enhancement, and for that reason ns version 2.26 had to
be used. This version appears to be unstable, some scenario configurations
failed to run (there is limitation on parameters like: area size, number of
sources, number of TCP connections etc.).
3.4 Throughput calculation.
In general, our formula for calculation is the sum of the total TCP packets (in
bytes), which were received by every destination or router node divided by the
scenario run time.
In more details, the tcl files (scenarios) generated by ASG produce traces file
during their run. These files are parsed by perl scripts system, which took out
2:14
TCP Performance over ad-hoc mobile networks.
6
the relevant lines from each file and calculate the throughput as described
above.
The relevant lines, in trace file, consist in their first column r (received), in the
seventh TCP and in the eighth column the size of the TCP packet in bytes.
A relevant line example:
r 1.135127009 _7_ AGT
--- 37 tcp 1040 [13a 7 0 800] ------- [0:6 7:0 32 7] [2 0] 1 0
4 Simulation Results
4.1 General Description.
As we mentioned before, we used the ASG to generate different random scenarios
for each parameter configuration. Prototype files were first generated according
to the following parameters: area size, number of total nodes and number of
sources. Those prototypes contained random initial position of each node and
their random movements. After the prototype files were created, we generated
run files based on those prototypes files. Doing so, we had the ability to compare
between the different TCP configurations over the same scenario.
Several random scenarios needed to eliminate the influence of corner cases, and
to have the ability getting to right conclusions. In our work each network
environment and TCP configuration contained 10 random scenarios.
4.2 Test runs description.
Those environment configurations were chosen:
 Nodes’ velocity: 5 m/s, 15 m/s and 30 m/s.
 Area size: 1500*1000m², 500*400m² and 600*400m².
 Total nodes number: 25 and 11.
 Number of sources: 10, 6 and 1.
4.3 Results graphs.
In this section each graph has the same environment configurations and only
changes are in the TCP configurations. The TCP configurations are:
 BASE: a basic configuration.
 SACK: new Reno TCP with selective acknowledgment and delayed Ack.
 LT:
new Reno TCP with limited transmit.
 ECN: new Reno TCP with explicit congestion notification.
Note: Not all routing protocols in the ns support the ECN option.
2:14
TCP Performance over ad-hoc mobile networks.
7
4.3.1 Routing protocol: DSR.
4.3.1.1 Environment configurations: area size 500m*400m, total nodes
25 and one source.
In this configuration is no significant difference in the throughput the reason for
that is that when one source node transmits, no series congestion can be
produced.
throughput
Velocity 30 m/s
300000
250000
200000
150000
100000
50000
0
BASE
SACK
LT
1
2
3
4
5
6
7
8
9
10
senario
Throughput
Velocity 15 m/s
300000
BASE
200000
SACK
100000
LT
0
1
2
3
4
5
6
7
8
9
10
Scenario
Throughput
Velocity 5 m/s
300000
250000
200000
150000
100000
50000
0
BASE
SACK
LT
1
2
3
4
5
6
7
8
9
10
Scenario
4.3.1.2 Environment configurations: area size 500m*400m, total nodes
25, 10 sources.
 In this configuration we are witnessing to the greater impact
sack has to the throughput performance impact.
 Limited transmit does not improve TCP performance.
2:14
TCP Performance over ad-hoc mobile networks.
8
Velocity 30m\s
throughput
220000
210000
BASE
200000
SACK
190000
LT
180000
170000
1
2
3
4
5
6
7
8
9
10
scenario
Velocity 15m/s
220000
throughput
210000
200000
BASE
190000
SACK
180000
LT
170000
160000
1
2
3
4
5
6
7
8
9
10
scenario
throughput
Velocity 5m/s
220000
215000
210000
205000
200000
195000
190000
185000
180000
BASE
SACK
LT
1
2
3
4
5
6
7
8
9
10
scenario
2:14
TCP Performance over ad-hoc mobile networks.
9

As can seen in the following graph, SACK has a greater impact over high
velocities.
% throughput improvment
% average throughput improvment
1.06
1.05
1.04
1.03
1.02
1.01
1
0.99
0.98
0.97
0.96
SACK
Limited transmit
30
15
5
Velocity
4.3.1.3 Environment configurations: area size 1500*1000, total nodes
25, 10 sources.

Throughput in general has increased due to the area size changes.
Velocity 30 m/s
800000
throughput
700000
600000
500000
BASE
400000
SACK
300000
LT
200000
100000
0
1
2
3
4
5
6
7
8
9
10
senario
2:14
TCP Performance over ad-hoc mobile networks.
10
throughput
Velocity 15 m/s
700000
600000
500000
400000
300000
200000
100000
0
BASE
SACK
LT
1
2
3
4
5
6
7
8
9
10
senario
throughput
Velocity 5 m/s
700000
600000
500000
400000
300000
200000
100000
0
BASE
SACK
LT
1
2
3
4
5
6
7
8
9
10
senario

A Comparison between throughput improvements over two area sizes –
500m*400m and 1500m*1000m, both with 10 sources out of total 25 nodes.
% average throughput improvment
% avg. throughput
improvment
1.15
1.1
1.05
1
SACK 500*400
SACK 1500*1000
LT 500*400
LT 1500*1000
0.95
0.9
30
15
5
Velocity
2:14
TCP Performance over ad-hoc mobile networks.
11
4.3.2 Routing protocol: DSDV.
4.3.2.1 Environment configurations: area size 600m*400m, total nodes
11, 6 sources.
Velocity 30m/s
185000
throughput
180000
175000
BASE
170000
SACK
165000
LT
160000
ECN
155000
150000
1
2
3
4
5
6
7
8
9
10
scenario
throughput
Velocity 15m/s
190000
185000
180000
175000
170000
165000
160000
155000
150000
BASE
SACK
LT
ECN
1
2
3
4
5
6
7
8
9
10
scenario
throughput
Velocity 5m/s
190000
188000
186000
184000
182000
180000
178000
176000
174000
172000
BASE
SACK
LT
ECN
1
2
3
4
5
6
7
8
9
10
senario
2:14
TCP Performance over ad-hoc mobile networks.
12

Throughput average improvement comparison over DSDV:
% throughput improvment
DSDV avg. throughput improvement
1.03
1.025
1.02
1.015
1.01
1.005
1
0.995
0.99
0.985
0.98
SACK
LT
ECN
30
15
5
Velocity
4.3.3 Routing protocol: AODV.
4.3.3.1 Environment configurations: area size 600m*400m, total nodes
11, 6 sources.
Velocity 30m/s
throughput
170000
165000
AODV_BASE_30
160000
AODV_SACK_30
155000
AODV_LR_30
150000
AODV_ECN_30
145000
1
2
3
4
5
6
7
8
9
10
senario
2:14
TCP Performance over ad-hoc mobile networks.
13
Velocity 15m/s
throughput
175000
170000
AODV_BASE_15
165000
AODV_SACK_15
160000
AODV_LR_15
AODV_ECN_15
155000
150000
1
2
3
4
5
6
7
8
9
10
senario
Velocity 5m/s
throughput
175000
170000
AODV_BASE_5
165000
AODV_SACK_5
160000
AODV_LR_5
AODV_ECN_5
155000
150000
1
2
3
4
5
6
7
8
9
10
senario
2:14
TCP Performance over ad-hoc mobile networks.
14
4.3.4 SACK improvement comparison.
SACK improvement over different routing protocols. (All with the same
topology: 600m*400m, 6 sources out of total 11 nodes)
% throughput avg.
improvment
TCP throughput with SACK over routing protocols.
250000
200000
DSR
AODV
DSDV
150000
100000
50000
velocity 30
velocity 15
velocity 5
velocity
% throughput avg.
improvment
SACK improvment over routing protocols
1.08
1.07
1.06
1.05
1.04
1.03
1.02
1.01
1
0.99
DSR
AODV
DSDV
velocity 30
velocity 15
velocity 5
velocity

Notice the SACK improvement over DSR routing protocol in compare to the
improvement over other routing protocols.
2:14
TCP Performance over ad-hoc mobile networks.
15
4.3.5 Topology size.

Unlike prior assumptions, there were unexpected throughput results on
different network’s area sizes. We expected that on large areas the throughput
would decrease. However as the results show that the opposite occurs.
DSR Throughput over different area size
throughput
200000
150000
400*500
100000
1500*1000
50000
0
1
2
3
4
5
6
7
8
9
10
scenario

Trying to figure out this phenomena we did some test runs over various
network’s area sizes.
throughput
Throughput as function of area size.
160000
140000
120000
100000
80000
60000
40000
20000
0
400*500
1500*1000
2500*2000
5000*4000
area size
2:14
TCP Performance over ad-hoc mobile networks.
16
4.3.6 Routing protocol: TORA.

The run results shows that this routing protocol performance is highly
sensitive to topology. Therefore conclusive conclusions could not be made
regarding TCP performance using this routing protocol. The following graph
demonstrates the performance sensitivity to topology in TORA routing
protocol.
Velocity 15m\s
140000
throughput
120000
100000
BASE
SACK
LT
ECN
80000
60000
40000
20000
0
1
2
3
4
5
6
7
8
9
scenario
2:14
TCP Performance over ad-hoc mobile networks.
17
5 Conclusions.
5.1 Selective ACK conclusions.

The selective ACK enhancement showed the best TCP performance
improvement. Its performance out-goes over all routing protocols and
topologies that were examined in this project.

In ad-hoc mobile networks there is a high probability for packets loss due to
high bit error rate, and frequent topology changes. SACK is mainly helpful
during some packets loss in the same sending window. SACK prevents the
sender to re-transmit packets that were already received, and help the sender
to recover from several packets loss and avoid time-out.
SACK had shown up to 12% performance improvement while using high
velocities. In high velocities frequent topology changes occur which causes for
packets loss.

SACK showed best performance improvement over the DSR routing
protocol. DSR showed better throughput than other routing protocols,
therefore we conclude that its TCP connections had bigger sending window
(cwnd size), in such cases SACK can perform better.

5.2 Limited transmit conclusions.
The Limited transmit had poorly throughput performance in our research,
(Similar to the base throughput and even on some scenarios had lower
throughput). Our assumption for this phenomenon is that the Limited transmit
was not needed in most of the scenarios, and on some scenarios was too
aggressive. The limited transmit goal is to improve the effectiveness of TCP
over small windows, and to enter a fast retransmit mode when receiving less
then three duplicate ACKs avoiding the need for Retransmission timeouts
(RTOs).
Studies has shown that Limited transmit is very effective when the duration of
the connection is short (for example on HTTP 1.0 the congestion window of a
TCP sender is typically small), because TCP sender cannot probe the available
bandwidth, due to the small amount of data to be sent.
For that reasons and for the fact that our simulation dealt with ftp connection
that had transferred large files we assumed that the Limited transmit was not
needed and maybe was too aggressive in our scenarios.
A small improvement was shown when the throughput calculation ignored TCP
packets that routers received.
2:14
TCP Performance over ad-hoc mobile networks.
18
5.3 Explicit Congestion Notification (ECN), conclusions.

As we have mentioned before and as the name implies the ECN designed so
the source will have the ability to know about congestion before it’s packets
discarded. During our work on the project we have run enormous scenarios
and no a real improvement using ECN was viewed. There are some reasons
that could cause to that situation:
o RED is strong enough for signaling the sources for congestion and
therefore ECN can not contribute dramatically.
o RED seems to be difficult to tune, and adding ECN to RED in mobile
ad hoc networks were the topology is very dynamic make it more
difficult to use it in an optimal manner (we tried to tuned main RED
queue parameters and still no significant result).
o A quite high loss packets environment as in the ad hoc mobile network
causes loss of TCP ACK packets with the ECN field set which
eliminate the power of ECN.
2:14
TCP Performance over ad-hoc mobile networks.
19
Topology size conclusions.
5.4
As seen on run results, the throughput depends on network dimensions. On the
contrary to our first assumption the throughput increased when network
dimensions grew, however the throughput behavior is not linear.
Throughput as function of area size.
throughput
200000
150000
100000
50000
0
400*500
1500*1000
2500*2000
5000*4000
area size
In our scenarios each source sends packets to all other nodes in the
network. In
400m*500m topology we assume that each source can send its data to all
nodes through other nodes (that act like routers), in such cases nodes are busy
serving as routers and in transferring routing packets rather than sending data.
On the other hand in 2500m*2000m topology there is a network partitioning
and the source sends data to its neighbors and there are few indirect
connections. When topology grows to 5000m*4000m, there is throughput
degradation due to heavy network partitioning.
A test case was created in order to confirm our assumption and it contains a
“fixed” scenario that differs from the random 5000m*4000m topology
scenario, with the following change: there are two nodes (sender s, receiver r)
that are directly connected all over the run.
Random scenario vs. "Fixed " scenario
throughput
150000
100000
50000
0
random
fixed
This test result shows that throughput is sensitive to network partitioning as
occurs in 5000m*4000m topology.
2:14
TCP Performance over ad-hoc mobile networks.
20
6 Future Work.
6.1
Explicit Loss Notification (ELN)
We know that the TCP receiver sends cumulative acknowledgments (ACKs)
for successfully received segments, with which the TCP sender determines
which segments have been successfully arrived. The TCP sender identifies the
loss of segments either by receiving duplicate ACKs or by timeout. TCP reacts
to packet losses by retransmit lost packets and entering a congestion control
mode. In traditional wired networks the performance was fine because packet
losses where usually caused by network congestion, however this days there
are many wireless networks where this assumption does not work, a high bit
error rate or nodes mobility became the dominate cause of packet loss. TCP
cannot distinguish between packet loss due to wireless errors or congestion
ones. Therefore there is a need for the TCP to distinguish between those
causes and determine how to react to the packet losses. The Explicit loss
notification (ELN) allows the TCP sender to determine the cause of the loss,
and respond respectively. There are several ways to implement the ELN but
none of them is implemented in the ns.
(Planned to be implemented on next ns version).
6.2 Signal Stability based Adaptive (SSA).
In Signal Stability based Adaptive routing [5], every node maintains a Routing
Table wherein the destination and the next hop information is stored. Along
with this, a Signal Table is also maintained where a record of the neighbors is
kept and they are classified as strongly or weakly connected. This is done on
the basis of periodic link layer beacons received by a node from its neighbors.
The SSA protocol uses the stability of links as a route selection criterion.
When a source has data to send to a destination, for which there is no entry in
the route cache, it broadcasts route search packets to its neighbors. The nodes
receiving these packets broadcast the route search if it is received from a
strongly connected neighbor and the request has not been propagated
previously. When a host moves out of the range of its neighbors or shuts
down, the neighbors recognize that the host is unreachable. The routing table
and the signal table are accordingly modified and a route error packet is sent to
the source. On receiving this error notification the source initiates a new route
search.
2:14
TCP Performance over ad-hoc mobile networks.
21
7 References.
1. http://www.isi.edu/nsnam/ns/doc/ - the Berkley University site regarding ns.
2.
3.
4.
5.
6.
7.
8.
“Performance comparison of two on demand routing protocols for ad hoc networks” by Das,
Perkins and Royer.
“TCP over Ad Hoc network” by Marco Zuniga.
“Performance of TCP over different routing protocols in mobile ad hoc networks” by IBM
India research labs.
“A comparison of mechanisms for improving TCP performance over wireless links” by
Balakrishnan, Padmanabhan, Seshan and Katz.
“Analysis of TCP performance over mobile ad hoc networks” by Holland and Vaidya.
http://www.cs.wpi.edu/~rek/Adv_Nets/Summer2003/RED.pdf
A performance study of explicit congestion notification with heterogeneous TCP flows
– Worecester Polytechnic Institute.
2:14
TCP Performance over ad-hoc mobile networks.
22