# Introduction

ommunication plays a major role in the ad-hoc networks and is used many applications. It account for a large proportion of energy usage. Energy is an important factor in the ad-hoc networks. It is very essential to lower the energy consumption in the adhoc networks. There are many techniques for reducing energy consumption and energy cost in adhoc networks. MAC protocols and routing protocols use energy based metrics.

These approaches reduces the energy cost. Aditionally the energy of the TCP also can be reduced as well. There are four variants in saving the energy. The four variants in saving the TCP energy are: Reno ,New Reno ,SACK ,and TCP-ECN-ELFN. SACK means selective acknowledgement. TCP-ECN-ELFN is a combination of ECN AND ELFN. ECN means Explicit Congestion Notification. ELFN is Explicit Link Failure Notification. ECN is a mechanism that enables the senders to respond quickly to the beginning congestion in the network. When the energy cost is measured there is a good throughput for this mechanism. There is a good total energy and idealized energy for this mechanism. The idealized energy is defined as the energy consumed by the sender for transmitting or sending or receiving. The other variant TCP-ECN-ELFN mechanism results in the lower energy consumption when compared to the SACK. The other variants of TCP that is Reno and New Reno also had a good throughput. In this paper we discuss about the energy model and summary of the various TCP variant mechanisms.


# II.


# Related Work

The link is an approach it includes the effect of ARQ AND FEC and the combination of the two in the ad-hoc networks. There are some link layer schemas to improve the energy behavior. The key idea is to discard the packet transmission when channel conditions are worsen. When the channel conditions is good then the packet transmission is resumed. The three implementations of TCP theno ,Reno, New Reno. This mainly focuses on the wired and the wireless environment.


# III.


# Over View of TCP Variants

At present all the TCP implementations depands on tahoe. Various algorithms are incorporated on TCP for slow start ,fast avoidance and fast retransmit and modifications in the formulas for estimation the RTT. RTT means round trip time. The TCP RENO is very much similar to the tahoe but there is a slight difference that is the fast retransmit algorithm this fast retransmit algorithm includes the fast recovery. When a sender receives three duplicate acknowledgment signals then it reduces by half. But as not like a tahoe it becomes the slow start. Thus the RENO increases the congestion rapidly by setting it to the minimum. Here the retransmit timer will turn off and this leads to the congestion and the low throughput.

TCP New Reno overcome the disadvantages of the RENO. A partial acknowledgments infers that there are some unacked packets in the senders window. In RENO a partial acknowledgment gives the sender the fast recovery in a view of the multiple packet losses. When ever the receiver gets a data is out of sequence then that unsequences data creates a hole in the buffer that is present at the receivers end. This is the reason why the reciver generates a duplicate acknowledgment. The receiver includes the starting and ending sequence addresses that is the sequence numbers. These sequence numbers are present in the SACK. The first block in the SACK represents the recently transmitted segment to the reciever. The remaining SACK blocks represents the recently reported blocks. This algorithm is helpful for TCP to recover from multiple segment losses of data with in one round trip time.

When the sender comes to know that there is a loss of the packet then it retransmits and reduces the congestion to half and does fast recovery in RENO and Year 2014
( D D D D D D D D )
New RENO. SACK has a variable named pipe it gives the number of packets in the flight. This pipe variable is increased by one that is incremented for the transmission and it is decreased by one that is decremented when it receives a duplicate zed energy cost is high for SACK.


# a) TCP-ECN-ELFN

It summarizes the changes made to the operation of TCP to include ECN and ELFN. We note that our implementation goes beyond simply adding ELFN and ECN to TCP -we no longer treat timeouts and triple duplicate ACKs as indications of congestion. Rather, we rely exclusively on ECN to ag network congestion. The table also describes the intuition behind these changes.


# i. Routing Failure

It describes the interplay between routing failure (due to link outage or propagation of stale routes) and TCP throughput, in detail. Briey, successive route failures (due to link failure) lead to timeouts hence resulting in a small congestion window.. Hence, the throughput of the connection is small. The proposed in and used by us is as follows. A route failure message is propagated back to the TCP sender from the intermediate node that detects the route failure. This message has the effect of freezing TCP's state and initiating the transmission of probe packets. When there is a response to the probe packet (i.e., the route is up), TCP's state is unfrozen and transmission resumes. This solution ensures that there are no timeouts(and hence no unnecessary retransmissions), and that the TCP sender begins sending packets soon after the route is up.


# ii. Out of Order Packets

Mobility of nodes can cause packets belonging to the same connection to be routed along different routes. This can result in the receiver getting out-oforder packets which causes duplicate ACKs to arrive at the sender. Likewise, packet loss due to link-layer errors can result in triple duplicate ACKs or timeouts. On receiving three duplicate ACKs, the sender reduces its congestion window by a half and retransmits the out-ofsequence packet while in the case of timeouts, the window is reduced to one or two segments. This congestion avoidance behavior has the net e_ect of reducing the throughput of the connection (due to the smaller congestion window) and thus increasing overall energy consumption. We believe that the appropriate _x for this problem is for the TCP sender to retransmit the sending packet but not adjust its congestion window. We made this modification to TCP-ECN-ELFN in our implementation.


# iii. Network Congestion

A problem with our approach above is that if the triple duplicates (or timeout) were generated as a result of packet drops due to congestion, then the solution of simply retransmitting the packet without reducing the congestion window will have negative consequences (this is the reason why TCP reduces its congestion window). In our design, we rely on explicit congestion notification to signal imminent congestion along a route2. Here, a node whose buffer occupancy. crosses some threshold, sets a bit (the CE bit) in all data packets it sees. Receivers reect this ag back in the ACKs they generate by setting the ECN-ECHO bit. Upon receiving an ACK with the ECN-ECHO bit set, TCP senders enter a recovery phase in which they reduce the congestion win down by a half. The sender sets a CWR (Congestion Window Reduced) bit in new data packets. If the receiver sees an other CE bit set in a future packet and sees that the sender had sent a CWR bit, this indicates that there is still congestion in the network. The receiver again sets the ECN-ECHO bit in new ACKs thus forcing the sender to enter another recovery phase. This can go on until the sender's window has shrunk to one or two segments. 
			© 2014 Global Journals Inc. (US)
		
		
			

				


* 
	
		Performance of tcp over different routing protocols in mobile ad-hoc networks
		
			AshishAhuja
		
		
			SulabhAgarwal
		
		
			Jatinder PalSingh
		
		
			RajeevShorey
		
	
	
		IEEE Vehicular Technology Conference
				Tokyo, Japan
		
			2000. May 2000
		
	




* 
	
		A comparison of tcp performance over three routing protocols for mobile ad hoc networks
		
			DThomas
		
		
			RajendraVDyer
		
		
			Boppana
		
	
	
		ACM Symposium on Mobile Ad Hoc Networking and Computing (MOBIHOC)
				
			October 2001
		
	




* 
	
		Energy eAEciency and through put for tcp traAEc in multi-hop wireless networks
		
			SoravBansal
		
	
	
		Proceedings INFOCOM 2002
				INFOCOM 2002New York, NY
		
			2002
		
	




* 
	
		Simulation-based comparison of tahoe, reno, and sack tcp
		
			KFall
		
		
			SFloyd
		
	
	
		ACM Computer Communications Review
		
			26
			3
			
			July 1996
		
	




* 
	
		TCP and explicit congestion noti_cation
		
			SFloyd
		
	
	
		ACM Computer Communication Review
		
			24
			5
			
			1994
		
	




* 
	
		Tcp performance in wireless multi-hop networks
		
			MGerla
		
		
			KTang
		
		
			RBagrodia
		
	
	
		IEEE WMCSA'99
				New Orleans, LA
		
			Feb. 1999
		
	




* 
	
		Analysis of TCP performance over mobile ad hoc networks
		
			GavinHolland
		
		
			NitinHVaidya
		
	
	
		ACM Mobile Computing and Networking (MOBICOM'99)
				
			1999
			
		
	




* 
	
		Adaptive link layer strategies for energy eAEcient wireless networking
		
			MSrivastava
		
		
			PLettieri
		
		
			CSchurgers
		
	
	
		Wireless Networks
				
			1999
			5
			
		
	




* 
	
		Issues in the implementation of selective acknowledgements for tcp
		
			LRizzo
		
		
			1996