TCP Performance in Wireless multi-hop Networks

Introduction

Early research showed TCP suffers poor Performance in wireless networks because of packet losses and corruption caused by wireless inducted errors Further studies searched for mechanism to improve TCP performance in cellular wireless systems Other researches investigated other network problems that negativly affect TCP performance, such as bandwidth asymmetry and large round trip times, which are prevalent in satelite networks During the presentaition we adress another network charackteristic that impacts TCP performance, which is common in mobile ad hoc networks: link failures due to mobility First present performance analysis of standart TCP over mobile ad hoc networks Then present analysis of the use of explicit notification techniques to counter the affects of link failures

Simulation Environment and Methodology

For simulations the ns network simulator from Lawrence Berkles National Laboratory was used, with extensions from the MONARCH project at Carnegie Mellon Extensions include a set of mobile ad hoc network routing protocols, an implementation of BSDs ARP protocol, an 802.11 MAC Layer, a radio propagation model and mechanisms to model node mobility using pre-computed mobility patterns that are fed to the simulation at run time No modifications were made to the simulator (accept minor bug fixes that were necessary) All results based on a network configuration consisting of TCP-Reno over IP on an 802.11 wireless network, with routing provided by the Dynamic Source Routing (DSR) protocol and BSDs ARP protocol (used to resolve IP adresses to MAC adresses) Objective was to observe TCPs performance in the presence of mobility inducted failures in a plausible network environment, for which any of the proposed mobile wireless ad hoc routing protocols would have sufficed Network model consists of 30 nodes in 1500x300 meter flat, rectangular area Nodes move according to random waypoint mobility model In random waypoint model each node x picks a random destination and speed in the area and travels to destination in straight line Once x arrives, it pauses, picks another destination and goes on No pause, so every node is always in moving All nodes communicate with identical half duplex wireless radios, which are modeld after 802.11 based Wave Lan wireless radios, with a bandwith of 2Mbps and nominal transmission radius of 250m TCP packet size was 1460bytes, maximum window was eight packets All simulation results based on average throughput of 50 scenarios or patterns Each pattern, generated randomly, designates the initial placement and heading of each of the nodes over simulated time Used same pattern for different mean speeds For a given pattern at different speeds, same sequence of movements (and link failures) occur Speed of each node is uniformly distributed in an interval of 0,9v - 1,1v for some mean speed v

Performance Metric

Throughput as performance metric used TCP throughput ussually less than optimal due to TCP senders inability to accurate determine the cause of a packet loss TCP sender assumes that all packets losses are caused by congestion When link on TCP route breaks, TCP sender reacts as if congestion was the cause, reducing its congestion window and, in instance of a timeout, backing-off its retransmission timeout (RTO) Therefore, route changes due to host mobility can detrimental impact on TCP performance To gauge impact of route changes on TCP perfomance, we derived an upper bound on TCP throughput, the expected throughput TCP throughput measure obtained by simulation is then compared with expected throughput Expected throughput was obtained as the following: - First simulated a static (fixed) network of n nodes that formed a linear chain containing n-1 wireless hops - Nodes used 802.11 protocol for medium access - Then a one-way TCP data transfer was performed between the two nodes at the ends of the linear chain, and the TCP throughput was measured between these nodes

Hops	Throughput (Kbps)	Table 1 shows measured TCP throughput as a function of number of hops, averaged over ten runs Throughput decreases rapidly when number of hops is increased from 1, then stabilizes once the number of hops becomes large
1	1463.0
2	729.0
3	484.4
4	339.9
5	246.4
6	205.2
7	198.1
8	191.8
9	185.3
10	182.4

Our objective here is to use these measurements to determine expected troughput Expected throughput is a function of mobility pattern For instance, if two nodes are always adjacent and move together, the expected thoughput for the TCP connection between them would be identical to that for one hop in Table 1

expected throughput = ${\frac {\sum _{i=1}^{\infty }T_{i}*t_{i}}{\sum _{i=1}^{\infty }t_{i}}}$

Measurement of TCP-Reno Throughput

TCP throughput should monotonically degrade as speed increase Throughput drops sharply as mean speed increased from 2 m/s to 10 m/s When mean speed increase from 10 m/s to 20 m/s and 30 m/s th averaged over 50 runs decreases only sligthly Counter intuitive result: In fact throughput could have potentially increased with speed Following observations are to be seen: although, for any given speed, the points may be located near or far from the diagonal line (expected throughput), when speed is increased, the points tend to move away from the diagonal, signifying a degradation in th For given speed, certain mobility patterns achieve th close to 0, although other mobility patterns (with the same mean speed) are able to achieve a higher throughput Even at high speeds, some mobility patterns result in high throughput that is close to the expected throughput If two nodes move together, the link between them will not break, regardless of their speed

Mobility Induced Behaviours

Observing examples of mobility induced behaviours There are several possible explanations (due to the variety of used protocols, such as 802.11 MAC, ARP, DSR and TCP on top of them) Throughput: Function of data acknowledged to the sender The following scenario results in almost zero throughput (due to route failures of some TCP packets)

Event	Time (secs)	Node	SeqNo	Pkt	Reason of dropping
s	0.000	1	1	tcp
D	0.191	5	1	tcp	NRTE
s	6.000	1	1	tcp
r	6.045	2	1	tcp
s	6.145	2	1	ack
D	6.216	21	1	ack	NRTE
s	18.000	1	1	tcp
s	42.000	1	1	tcp
s	90.000	1	1	tcp
D	120.000	15	1	tcp	END
D	120.000	16	1	tcp	END
D	120.000	25	1	tcp	END

s – send, r – receive, D – dropped, NRTE – no route found

First conclusion:

Clear: Characteristics of the routing protocol have an eminent impact on TCP Performance Biggest problem: Caching and propagation of stale routes TCP sender's routing protocol is unable to quickly recognize and purge stale routes This gets even more complicated, when the intermediate nodes are allowed to respond to route requests with their own stale routes in cache (amplified by overhearing propagated stale routes and spreading the wrong information around) Upon further inspection it was recognizable that the routing protocol regularly fails, when the minimum path increases in length, independent of the mean speeds In case the nodes move closer DSR can maintain the route, in case they diverge DSR does not search another route until an error occurs Thus, the TCP sender repeatedly times-out and backs-off The problem should be familiar to all reactive routing protocols

Solutions:

Using more effective cache maintenance strategies Including simple techniques like dynamically adjusting the route cache timeout mechanism (depending on the observed route failure rate) The use of negative route information The use of signal strength information First improve routing protocols, then look at TCP

Explicit Feedback

Explicit Feedback is a technique for signaling congestion, corruption due to wireless transmission errors and link failures due to mobility.

Here we take a brief look at Explicit Link Failure Notification - ELFN.

Objective: Provide the TCP sender with information about link and route failures so that it can avoid responding to the failures as if congestion occurred Different ways in implementing the ELFN message: - Very simple one: a "host unreachable" ICMP message as a notice to the sender - Another way: a message piggy-backed on the message, which is already sent from the routing protocol The approach in this case: The DSR route failure message carries parts of the TCP/IP headers of the packet (by which the notice was instigated), including sender and receiver addresses (to identify the connection), ports and the TCP sequence number