AN EXPLICIT LINK FAILURE
NOTIFICATION WITH DYNAMIC CACHE
UPDATE SCHEME TO IMPROVE TCP
PERFORMANCE USING
DSR PROTOCOL IN MANET
Suneel C Shinde1*, JoshiVinayak B2, Nayak Ramesh S3,Hanumanthappa.J4
1
Dos in Computer Science, University of Mysore, Manasagangothri, Mysore, INDIA
Research Associate, Dept.of Computer Science Mangalore University, Mangalagangothri, Mangalore, INDIA
Asst.Professor, Dept.of Computer Science & Engg., Shreedevi Inst.of Technology, Mangalore, INDIA
Senior Grade Lecturer, Dos in Computer Science, University of Mysore, Manasagangothri, Mysore, INDIA
ABSTRACT
In today’s most of the Adhoc networks needs the reliable connection to transfer the data. Most number of data packets loss is experienced in the Adhoc networks due to Transfer control protocol(TCP)’s high channel error rate and link failure. To improve TCP performance in Adhoc networks a number of schemes have been proposed, where Adhoc networks use the multi-hop wireless connectivity, where the network has quickly changing network topology. ELFN (Explicit Link Failure Notification) is one mechanism to manage link failures with dynamic cache update scheme to improve the TCP performance considerably. In this paper, we propose a mechanism which significantly increases the throughput of TCP’s performance with ELFN based Dynamic cache update scheme using Dynamic source routing protocol. Our simulation results using ns-2 simulator, mentions that our scheme can handle link failures in effective way, and improves TCP’s performance considerably
KEYWORDS
TCP-ELFN, TCP, Adhoc TCP, DSR, Explicit link failure notification.
1. INTRODUCTION
A Mobile Adhoc Network (MANET) is a network is network composed of mobile nodes mainly characterized by the absence of centralized coordination or fixed infrastructure, which makes any node in the network act as potential router. MANETs are also characterized by a dynamic, random and rapidly changing topology. In MANETs, communication link between mobile nodes always require over multi-hop paths.Since no infrastructure exists and node may cause frequent link failure. These complex networks of moving nodes have lead to complications with the throughput of TCP data flows. These problems are caused by the mobility because mobile nodes create a much more complex traffic flow which often leads to link failures and route changes. This mobility results in performance reduction because of TCP’s inability to recognize the difference between link failure and congestion. This has become a major problem today and must be taken into consideration.
In this paper we propose an ELFN based mechanism, which dynamically update the cache information of router and sends a notification of failure links to TCP, So that TCP will not do the usual congestion control routine. It does that by telling the source node about the failed link so that it can take action accordingly. The notification can be done in a number of ways. One way is to send an ELFN message, encapsulated in an ICMP "host unreachable" message, back to the sending node. Another way is to piggyback the notice at the back of a message that the routing is already sending to the sender, if the routing protocol is working that way. Such as DSR, described below.
When the sending node receives such a message, instead of doing the normal decrease of the sending window and the other measures done when there are lost packets, it freezes the sending window and sends out probe packets periodically to check if the link is up again. When the link is re-established, the communication continues without the throughput decrease that would normally have been the case. The organization of this paper is as follows: Section 2 gives an overview of TCP problem issues in MANET and Section 2.2 gives an brief idea of DSR protocol. Section 3 describes the Dynamic Cache update Scheme, Section 4 presents a simulation environment and methodology In Section 5, we discuss the performance evalouation of paper and the consequent results and, in Section 6, we present our conclusions.
2. TCP PROBLEM ISSUES IN MANET
Firstly to over come the problem of poor performance of TCP in MANET, it is important that first we get some knowledge about the problems that TCP suffer in MANET. Hence here we are going to explain some of the reasons for TCP poor performance in MANET.
Link failure: When node moves in MANET, it causes link failure. TCP has an inability that it can not differentiate between link failures and congestion. So every time link failure occurs, TCP take it as congestion.
Packet loss: Broken routes cause consecutive packet loss. TCP Vegashas one way to escape from consecutive packet loss, which is Timeout.
Invalid Routes: when a broken link occurs in MANET, the routing protocol (for example DSR) try search for new routes and reestablish the broken route. When DSR selects an invalid route, it causes consecutive timeouts. In such scenario TCP Retransmission Timeout value is backed off and thus it degrades link utilization.
Corruption caused by wireless induced errors
Bandwidth asymmetry
Large round-trip time
To address the problem of link failure and invalid route selection, two different solutions has been given – ELFN (Explicit Link Failure Notification)[1] and Dynamic cache update using DSR (Dynamic Source Routing) protocol.
Explicit Failure notification is a way to make TCP better handle cases when there are link failures, which is common in Adhoc networks. Since all nodes acting as routers have the full TCP/IP protocols stack, they have access to the routing protocols of the IP layer. The routing protocol can detect the link failure when the next node in the connection goes out of range, and the packet cannot be delivered. It sends the route error notification (RRER), which is flooded to all of the nodes including the source node. This error notification however does not reach the transport protocol, and it is only used by routing protocol to update the routing table. The TCP/IP protocols stack can be altered to use the RRER packet as the link failure notification. After the modifications, when the RRER packet is received, TCP can distinguish this link failure from the congestion. It can enter the “standby” mode by freezing the regular transmission of the packets until the connection is reestablished and then resume the transmission. The routing protocol can be modified to carry additional information in RRER packets, similar to the “host unreachable” ICMP message such as: sender address and port. This can identify at the sender of which connection this message is for. When sender receives the RRER packet and it detects that it is the source of the original message, it can notify the TCP layer about this link failure. TCP will probe the connection in a chosen probe intervals. When the acknowledgement packet is received TCP can leave the “standby” mode and restore the communication at the state as it was before the link failure.
2.2. DSR Protocol Overview
DSR protocol work in two phases: route discovery and route maintenance
• Route Discovery : When a mobile node S wants to send data to any other node D in a network and there is no route known by S to communicate with node D then it initiate route discovery process to find route so that S will start communication with D node.
• Route Maintenance : When node S knows the route to node D but before starting transmission it detects that route cannot be used any more due to dynamic topology of network route maintenance is used. Route maintenance will detect that source route has been broken due to any reason and node S knows any other route to access node D then that route will be used otherwise it can initiate route discovery to find the route. The route discovery and route maintenance will be done totally on demand of source node. There is no concept for periodic update messages in DSR so it prevent overheads caused by control message and approaches zero when there not involves mobility factor. In case of mobility DSR will be scaled accordingly for discovering routes. For single route discovery process, a node (who initiated route discovery) may learn more then one routes for a single destination. These multiple routes allow source node to utilize them when one route is not working and also prevent overheads involve for new route discovery.
2.3. Route Caching in DSR
3. THE DYNAMIC UPDATE SCHEME USING DSR
For this section,We present the dynamic cache update algorithm.We define a broken link as a forward or backward link.A broken link is a forward link for a route if the flow using the route crosses the link in the same direction as the flow detecting the link failure;otherwise,it is a backward link.For these two types of links, the operation of the algorithm is symmetric.
Here we take an example of network where there are some nodes ,
Fig 1. Routing Cache in DSR
We use S-D for SourceDestination and DP for DataPackets in thet tables describing the content of caches Node A initiates a route discovery to node E and E sends a ROUTE REPLY to A.Each node forwarding the ROUTE REPLY createsa cache table entry.For instance , node C creates an entry consisting of four fields: the route consisting of the downstream links,the source and destination pair, the number of data packets the node has
Forwarded using the route, and which neighbor will learn which links through the ROUTEREPLY.
When node A receives the ROUTE REPLY, it creates a cache table entry,
When node A uses this route to send the first data packet, it increments DataPackets to1.Each Intermediate node receiving thefirst datapacket updates its cachetable entry.For instance,node C increments DataPackets to1,adds the upstreaml inks to route CDE, and removes the Reply Record entry,as the complete route indicates that the upstream nodes, A and B, have cached the downstream links, CDE.
When node E receives the first data packet, it creates a cache table entry,
When a node on this route receives the second data packet, it increments DataPackets to 2 .Assume that, after transmitting at least two data packets for flow 1, node C receives a ROUTE REQUEST from G with source F and destination E. Before sending a ROUTE REPLY to node G, node C adds a Reply Record entry to its cache.
Before sending a ROUTE REPLY to node F, node G creates n a cache table entry
When node F receives the ROUTE REPLY, it creates a cache table entry,
When node C receives a ROUTE REQUEST from I with source H and destination A, it adds the second Reply Record entry to its cache
Fig.2. a network used for examples.
When node F receives a ROUTE REQUEST from node K with source J and destination D, it extends its cache entry,
4. SIMULATION ENVIRONMENT AND METHODOLOGY
Our Simulations in the experiments are carried out using the Network Simulator, ns2 Ns2 is a discrete event simulator targeted at networking research. Ns2 provides substantial support for simulation of TCP, routing, and multicast protocols over wired and wireless (local and satellite) networks widely used for the research related to computer networks. It allows creating different scenarios, and also supports protocol level enhancement and modification of simulator, support for data gathering and data analysis, which would otherwise be costly and difficult task for the researchers.
We have recompiled the ns version 2.29.2 by plugging the code of ELFN provided by the primary author of [3]. And then we have added Dynamic Cache update scheme in TCP sender side.
4.1 Simulation Idea
We use a network topology to analyze our Dynamic cache Update Scheme. Each node is kept fixed 200 m apart from its adjacent node. All the nodes communicate using half-duplex wireless communication, which have a bandwidth of 4 Mbps and a nominal transmission range of 250 m. TCP packet size of 1460 bytes is used. Four different maximum window values: 2, 4, 8, and 16, and three different hop values: 5, 6, and 7 are taken.
4.2 Implementation Methodology
Ns version 2.29.2 has been used for simulation. How simulation is carried out and how required result data are gathered from the output files are discussed here. Simulation Input: TCL scripts are used to specify scenarios, configure hosts, activate traffic sources and sinks, gather statistical data and run simulations.
The first data packet serves as a “synchronization signal,” indicating that the upstream nodes have cached the down-
Simulation Output: The output of the simulation using ns is a trace file, which contains traces from all layers. New trace format, which includes mostly all required details, has been used.
Figure 3. Highest sequence number comparison of three TCP flows: TCP Vegas, “TCP Vegas with ELFN”, and “TCP Vegas with ELFN and Dynamic Update Scheme” over 5 hop network topology.
Figure 5. Highest sequence number comparison of three TCP flows: TCP Vegas, “TCP Vegas with ELFN”, and “TCP Vegas with ELFN and Dynamic Update Scheme” over 7 hop network topology.
5.PERFORMANCE RESULTS AND OBSERVATIONS
From the results, as shown in Fig. 3, 4, and 5, it is observed that the “TCP Vegas+ELFN+Dynamic Caching” achieves better performance as compared to TCP Vegas in each 5 hop, 6 hop and 7 hop topology for higher value of window_ (maximum window size). For instance, over 5 hop topology at maximum window size value 4, the “TCP Reno+ELFN+Dynamic caching” reaches at sequence number 823 while TCP Reno is at 442. In this case the “TCP Reno+ELFN+Dynamic caching” has performance improvement by 381 packets. In same way the “TCP Reno+ELFN+Dynamic caching” also achieves better performance as compared to “TCP Vegas with ELFN” over many combinations of window and hop values. The “TCP Vegas with ELFN” has performance below standard TCP Vegas over 4 hop connection at maximum window size value 8. While in this case “TCP Reno+ELFN+Dynamic Caching” has very good performance as compared to both TCP Vegas and “TCP Vegas with ELFN”.In all three cases, there is not much difference in the highest sequence number reached by three TCP versions at window_ value 2. At window_ value 2, the probability of occurring link failure due to channel contention is relatively less as compared to higher window_ values. Due to this reason, not much difference in TCP performance is observed at window_ value 2 over all three: 5 hop, 6 hop, and 7 hop connections.
Our Dynamic Caching mechanism gives better performance as compared to standard TCP Vegas over all three: 5 hop, 6 hop, and 7 hop connections at window_ value greater than 2. However, over 7 hop connection at window_ value 4 and 16, the TCP Vegas with ELFN performs better than the “TCP Vegas with ELFN and Dynamic Caching”. On any n hop connections, the number of intermediate flows that can be active at a time is n mod 3 as the RTS-CTS mechanism of MAC layer does not solve the problem of exposed terminal problem. We leave this issue for further research to the enhanced version of this Dynamic Caching mechanism.
This implementation of Dynamic Caching has considered a dynamic probing mechanism based on probe count. The time duration of probe interval is kept fixed depending on probe count value. However, choosing initial probe time duration as a function of RTT would be a good choice. The number of retries after which MAC layer detects link failure can also be considered as parameter affecting the TCP performance over static environment.
In this paper, we proposed an ELFN-based Dynamic cache update mechanism. It provides dynamic probing of probe packet and helps in quickly continuing the use of channel in link failure cases which are not due to route failure but due to channel contention. We implemented proposed Dynamic cache update mechanism in ns-2 network simulator. Our Dynamic cache update mechanism has good results as compared to the standard TCP Vegas in all the cases that we considered. The Dynamic cache update also works well as compared to original ELFN with a few exceptions. As the problem of channel contention occurs on even a single multi hop connection at higher maximum window size value, our Dynamic cache update mechanism can be very useful over ad hoc networks. Further research is needed to understand the effect of initial probe timer value dependent on RTT and also the effect of number of retries after which MAC layer detects link failure and the simulation tests it can be concluded, that the ELFN+Dynamic cache update mechanism in general increases the overall throughput of data transfer at the application layer. It increases it for different topologies of the network and can be used in different network conditions like congestion, link breakage and multiple hops communication as well as in the mix of the above. As it was noted in results of the document, Explicit Link Failure +Dynamic cache update mechanism improves mean throughout for all the patterns, and not just a few. This indicates that ELFN + Dynamic cache update mechanism can be used in a wide range of ad hoc network topologies and situations.
REFERENCES
[1] G. Holland and N. Vaidya, “Analysis of TCP Performance over Mobile Ad Hoc Networks”, Proceedings of ACM MOBICOM 999, pp. 219-230, August 1999.
[2] S. Das, C. Perkins, E. Royer, “Performance Comparison of Two On-Demand Routing Protocols for Ad Hoc Networks”, in IEEE Personal Communications Magazine special issue on Ad hoc Networking, pp. 16-28, February 2001.
[3] K. Ramakrishnan, S. Floyd, D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, 2001 [4] M. Allman, V. Paxson, W. Stevens “TCP Congestion Control” RFC 2581, April 1999
[5] R. Caceres, L. Iftode, “Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments”, IEEE Journal on Selected Areas in Communications, June 1995
[6] Jin-Hee Choi and Chuck Yoo, "TCP-aware Source Routing in Mobile Ad Hoc Networks," iscc, p. 69, Eighth IEEE Symposium on Computers and Communications, 2003
[7] TCP/IP Illustrated, Volume 3 - W. Richard Stevens [8] Behrouz A. Forouzan - TCP/IP Protocol Suite
[9] D. Maltz, J. Brooch, J. Jetcheva, and D. Johnson, “The Effects of On-Demand Behavior in Routing Protocols for Multihop Wireless Ad Hoc Networks,” IEEE J. Selected Areas in Comm., vol. 17, no. 8, pp. 1439-1453, 1999.
[10] M. Marina and S. Das, “Performance of Routing Caching Strategies in Dynamic Source Routing,” Proc. Second Int’l Workshop Wireless Networks and Mobile Computing, pp. 425-432, 2001.
[11] D. Johnson and D. Maltz, “Dynamic Source Routing in Ad Hoc Wireless Networks,” Mobile Computing, T. Imielinski and H. Korth, eds, chapter 5, pp. 153-181, Kluwer, 1996.
