International Journal of Applied Information Systems (IJAIS) – ISSN : 2249-0868

Foundation of Computer Science FCS, New York, USA

Volume 2– No.4, May 2012 – www.ijais.org

TCP Congestion Control through Bandwidth Estimation

Mechanism in MANET

Ramratan Ahirwal Ganesh Lokhande Yogendra Kumar Jain

Computer Science & Computer Science & Computer Science &
Engineering Engineering Engineering
Samrat Ashok Technological Samrat Ashok Technological Samrat Ashok Technological
Institute Institute Institute
Vidisha (M.P.) 464001 India Vidisha (M.P.) 464001 India Vidisha (M.P.) 464001 India

ABSTRACT over high-speed data network is a requirement for many

Mobile ad-hoc network is collection of temporary nodes that applications. These applications require high-bandwidth links
are capable of forming dynamic temporary network, self between network nodes. In 1981, for maintain the stability of
organize, and infrastructure less with nodes contains routing Internet all applications should be subjected to congestion
capability, improving the performance of Transmission control. Introduce by author J.Postel, TCP [2] is well-
Control Protocol (TCP) associated with the presence of multi- developed, extensively used and widely available Internet
hop MANET is one of the research challenges in wireless transport protocol. Unfortunately, TCP has many performance
mesh networks. Wireless mesh networks have large round trip problems when operated over multi-hop wireless mesh
time variations and these variations are dependent on the networks. In 2010, the principal problem of TCP lies in the
number of hops. The end-to-end TCP throughput degrades congestion control mechanism proposed by author Prasanthi.
rapidly with increase in number of hops. This is one of the S and Sang-Hwa Chung “An Efficient Algorithm for the
biggest problems of TCP over wireless mesh networks In this Performance of TCP over Multi-hop Wireless Mesh
paper we present method for avoid congestion in MANET Networks[1] It uses three duplicate acknowledgements and
environment using bandwidth estimation technique .In our retransmission timeout to detect packet loss and treats every
approach we use acknowledgement time intervals for packet loss as a congestion indication. Moreover, the TCP
bandwidth estimation in TCP flow, in our scheme we monitor sender drastically reduces its congestion window to Slow Start
the time spacing between received acknowledgements state due to frequent retransmission timeout, which degrades
(ACKs) at the sender node and find out the available the throughput of TCP.
bandwidth of the connection between sender to destination, if Retransmission timeout: Retransmission time out is basically
available bandwidth is less then the actual data size so we error message, retransmission time out means if our data
decrease the data size according to available bandwidth and packet sends to destination but didn’t receive all of the data
avoid congestion, and same time other sender node try to from you in time to make a continuous transmission the
communicate any destination through same available path important tasks that a TCP connection must perform is to
which is used by previously senders so new sender node and estimate a proper value of the retransmission time out (RTO).
all other previously communicated sender node sends data
according to available bandwidth of the intermediate nodes so The RTO is calculated based on the following formula gives
we increase the network performance and provides congestion in equation (1)
free communication. ……. (1)
Keywords Where SRTT (Smoothed Round Trip Time) is a low pass
Mobile ad hoc network, TCP, Hybrid, Congestion, filtered version of the round trip sample (RTTm) measured by
Congestion control, Reno, NewReno, Vegas. the TCP sender. RTTVAR (Round Trip Time Variation),
instead, represents an estimate of the standard deviation of the
1. INTRODUCTION round trip sample, and it is calculated by low-pass filtering
In the network, the wireless communications provide many the quantity | SRTT – RTTm |.
benefits to organizations and users such as portability and
flexibility, increased productivity, and lower installation costs. Recently work has focused on the problems associated with
Wireless local area network (WLAN) devices, for instance, TCP performance in the presence of wireless links and ways
allow users to move their laptops from one place to another to improve its performance. The performance degradation in
place within their offices without the need for wires and wireless mesh networks throughput as a TCP connection
without losing network connectivity. Less wiring means traverses a large number of wireless hops is now a major
greater flexibility, increased efficiency, and reduced wiring research issue [3, 4]. Our work focused on the performance of
costs. Ad hoc networks, for example those enabled by TCP over Multi-hop wireless mesh network where the
Bluetooth, allow data synchronization with network systems retransmitted packets are loss by retransmission timeout. We
and application sharing between devices. Handheld devices designed TCP scheme called a TCP Updated New Reno in
like personal digital assistants (PDA) and cell phones allow which we check bandwidth of the link and according to
remote users to synchronize personal databases and provide bandwidth we send data packet to actual destination.
access to network services such as wireless e-mail, Web
browsing, and Internet access. To moving bulk data quickly

41
 International Journal of Applied Information Systems (IJAIS) – ISSN : 2249-0868
Foundation of Computer Science FCS, New York, USA
Volume 2– No.4, May 2012 – www.ijais.org

The paper is organized as follows: Section 2 Review work, When the bandwidth of intermediate nodes does not change,
Section 3 Provide Proposed scheme, 4 Simulation And TCP Reno periodically repeats the window increase and
Result, Section 5 about the Demonstration, Section 6 decrease. TCP Reno’s congestion window in terms of packet
Conclusion and Future Work, Section 7 References. loss rate (p) is calculated as:

2. REVIEW WORK .…. (4)

In this section, we focus on the function of TCP congestion
In equation (4), TCP Reno places a serious constraint on the
control algorithm in which we adjust the rate of transmitted
congestion window that can be achieved by TCP in realistic
packets with which the protocol sends packets into the
environments. For example, In TCP Reno connection with
network using a congestion control window. A good
1500-byte packets and 100ms RTT, to achieve a steady-state
congestion algorithm can fully utilize the bandwidth while
throughput of 1Gbps would require an average congestion
avoiding over-driving the network and thereby creating packet
window of 8300 segments, and an average packet loss rate of
losses. Since the congestion control mechanism has been
2 × 10−8. This requirement is unrealistic in current networks.
introduced in TCP by BSD UNIX, several TCP congestion
The congestion window requires more than 4000 RTT to
control algorithms are proposed. On a high level, existing
recover after a loss event which prevents efficient use of the
TCP congestion algorithms can be divided into three main
link bandwidth. TCP requires extremely small packet loss rate
categories based on the input of the control mechanism -
to sustain a large window which is not possible in real life
namely Loss-based TCP, Delay-based TCP and Hybrid TCP.
networks proposed by author Habibullah Jamal, Kiran Sultan
In 2004, Loss-based TCP includes the original TCP Reno
,” Performance Analysis of TCP Congestion Control
proposed by author L. Xu, K. Harfoush, and I. Rhee, TCP
Algorithms” [12]. TCP Reno perform very well over TCP
BIC [6], in 2003, TCP CUBIC, High Speed TCP [7], and
when packet losses are small but in case of multiple packet
Scalable TCP [8], etc. Among these Loss-based TCP variants,
losses in one window then Reno doesn’t perform very well .
TCP Reno and TCP CUBIC are widely deployed as standard
TCP algorithms and default TCP of Linux respectively. Using NewReno solve this multiple packet losses problem. New
packet loss as the symptom for network congestion, in Loss Reno is capable detect multiple packet losses Therefore is
based TCP decrease the congestion control window when much more efficient than Reno in the case of multiple packet
packet losses occur and increases the window otherwise. In losses. MANET suffers from multiple packet loss whenever
1994, Delay-based TCP including TCP Vegas proposed by nodes in the network change their position during
author L. S. Brakmo, S. W. O’Malley, and L. L. Peterson, communication. When nodes move from their position, they
“TCP Vegas: new techniques for congestion detection and may be unapproachable for a long time. In this case a number
avoidance the three key techniques employed by Vegas, and of packets meant for those nodes may get lost. TCP-New
presents the results of a comprehensive experimental Reno proposed by author Prasanthi. S and Sang-Hwa Chung
performance [9] and in 2006 by the author D. Wei, C. Jin, S. “An Efficient Algorithm for the Performance of TCP over
Low, and S. Hegde, “FAST TCP: motivation, architecture, Multi-hop Wireless Mesh Networks [1] has advantage of its
algorithms, performance,” [5] uses the queuing delay as the strategy to detect and handle multiple packet loss thereby
symptom of congestion. The queuing delay is defined as the avoiding continuous retransmission timeouts. It enters into
difference between the RTT and the propagation delay, i.e. fast-retransmit phase when it receives multiple duplicate
time actually required for a packet to be transmitted from the packets .but it does not exit this phase until all the packets
sender to the receiver. which were out standing at the time it entered fast recovery
get acknowledged. Thus it overcomes the problem of reducing
The Delay-based TCPs are more resilient to transient changes
the congestion window (CWND) multiples times by avoiding
of network conditions such as random packet losses and are
retransmission timeout. Fast recovery phase allows for
also suitable for high BDP networks introduce by author S. H.
multiple re-transmissions for single timeout. After entering
Low, L. L. Peterson, and L. Wang, “Understanding TCP
into this phase it checks the maximum segment which is
Vegas: a duality model” [10]. The down side of the approach
outstanding. If all the segments which were outstanding are
on the other hand is that, because increasing in queuing delay
acknowledged then it exits the fast recovery phase and sets
doesn’t necessarily immediately lead to packet loss (due to
CWND to ssthresh and continues congestion avoidance. It
buffers), when Delay-based TCP stations share the same
works in following four stages:
bottleneck with Loss-based TCP stations, between the time
when delay starts to increase and packet loss occurs, the Slow Start (SS): In Slow Start state, in initial the cwnd is
window for the Delay-based TCP will decrease while that for initialized to one packet after receiving acknowledgement it
the Loss-based TCP will not, leading to bandwidth cwnd is set one to two. This can be estimated as an
“starvation” for the Delay-based stations. exponential growth .When congestion window is greater
than ssthresh value then sender moves to Congestion
TCP Reno uses the TCP’s AIMD mechanism of increasing
Avoidance state.
the congestion window W by one segment per round-trip time
for each received ACK of send packet and halving the Congestion Avoidance: In the Congestion avoidance phase,
congestion window for each loss event per round-trip time. when three duplicate ACKs are received, the sender enters
TCP Reno maintains the congestion window as follows: fast-retransmit state.
Increase:
Slow
Slow Congestion Fast Fast
….. … (2) Start Avoidance Retrans Recover
Decrease: mit y

…….. (3) Figure 1 TCP Newreno Congestion Avoidance Steps

42
 International Journal of Applied Information Systems (IJAIS) – ISSN : 2249-0868
Foundation of Computer Science FCS, New York, USA
Volume 2– No.4, May 2012 – www.ijais.org

Fast Retransmit: In this stage the lost packet is retransmitted …… (6)

and ssthresh is set to maximum of FlightSize/2 or 2*SMSS,
where SMSS means sender’s maximum segment size and When acknowledgments of sending packets are delayed
FlightSize means amount of data that is unacknowledged at caused by congestion over heavy loaded route, then in our
any given time. Fast Recovery: In this stage, CWND is scheme we estimate available bandwidth from delay
increased by one for every duplicate acknowledgment and a difference between two received acknowledgements. We
new packet is transmitted, if allowed by CWND. It is assumed calculate it by subtracting delayed current acknowledgement
that in fast-recovery state, sender resets the retransmission time from previous acknowledgement time. If increase and
timer upon receiving a partial ACK. decrease difference between these two acknowledgements we
required set new data rate to avoid congestion over heavy
TCP NewReno perform well over multiple packet loss but loaded route in the network. From following equation (7)
NewReno suffer from the fact that it’s take one RTT to detect
each packet loss when acknowledgement for first ......... (7)
retransmitted segment is received only then can we deduce
which other segment was lost. To solve this problem we use Where is window size.
available bandwidth estimation technique in our updated TCP According to equation (7) the new data sending rate for next
NewReno scheme. packets will be changed according to this equation and if the
acknowledgment delay time increase then the
3. PROPOSED SCHEHE
In our proposed scheme we use acknowledgement time value will be decreases so the packets will be sent in network
intervals to estimation available bandwidth. This available according to the available bandwidth hence congestion will
bandwidth estimation helps to avoid congestion in the not occur in the path and every time this calculation
network. The available bandwidth is the amount of the share automatically adjust the data sending rate. For example
of the bandwidth that the flow can occupy without affecting assume initial is 500 bps, window size 20, =
other flows. In case of fully congested situation over 2sec. = 4sec. So, Δt=2
intermediate path node, the delay of acknowledgments
reception per estimated time period at the sender node can be = ;
affected to the fair share of bandwidth. In a fully congested
= 250 bps;
situation, fair share cannot be higher than achieved throughput
as it will affect other flows. But for partial congestion or no is assign to UBDSR and change value is 250bps.
congestion, the fair share is certainly higher than the achieved
throughput. means if we transmit data packet in ideal case Here threshold means ideal case data send’s by the sender
(without congestion) means normal data delivery to the node according to ideal available bandwidth we set cut-off
destination, but if any intermediate path node use by the any range, but after change available bandwidth because
other sender node at the same time on the same route due to remaining bandwidth used by another sender node so our new
increase data packet sending load on intermediate path node threshold (cut-off) set according to above equation. And
because first node already sending data packet on same control the data rate with congestion minimization on the
intermediate path node so first sender data delivery delay network.
will be increases and also if both sender send’s data greater
than the available bandwidth so grunted that data has been 3.1 Proposed Architecture
dropped and acknowledgement of sending packet will be Here we design basic architecture diagram for both cases
delay due to congestion on intermediate path node, to avoid NewReno and updated NewReno case, NewReno case if we
this situation we used bandwidth estimation technique to assume one sender node S2 sends data packet through I1 and
obtain available bandwidth of intermediate path nodes. If the I2 nodes to destination D2,. in ideal case S2 to I1 data rate is
delay of received acknowledgment of the sending packet at 50Mb/s and I1 to I2 data rate is 90Mb/s so that time no any
the sender node is increases, then in our approach we congestion on the network because sender S2 sends data in
calculate delay difference between previous acknowledgment maximum data rate 50Mb/s and I1 and I2 link bandwidth
and current acknowledgment send by the 90Mb/s is greater than the bandwidth S2 to I1. but after some
destination node, we assume Δt is delay difference of two time node S1 and S3 need to send data packet to destination
acknowledgement. So, we can calculate Δt as follows. D1 and D3 through I1 and I2 but I1 to I2 link maximum
90Mb/s data rate and here if all three sender S1, S2 and S3
……… (5) sends simultaneously data without know available bandwidth
so multiplex 160Mb data to I1 and that case I1 drop 70Mb
This delay difference used to estimate available bandwidth of data per second because congestion comes on to the
intermediate paths node for set new data sending rate
intermediate node I1. But next figure 3. Shows updated
according to the available bandwidth of the intermediate path
scheme of NewReno in that case if same situation given in
node to avoid congestion in the network. At the beginning
above description, node sends data packets through that
when we create connection and decide sender node and
intermediate node so sending packets will be delay and
destination node we considered d is data packet, t1 is time
received acknowledgments also delay at sender node sends
taken to data packet sending from sender node to destination
through destination node due to heavy loaded on intermediate
node through intermediate path node and t2 is time taken to
path nodes. So in our proposed scheme we calculate delay
acknowledgement to sender node from destination node
deference between acknowledgements at the sender node and
through intermediate path node and we assume UBDSR is ideal estimate available bandwidth of intermediate path nodes using
case basic data sending rate. So we can calculate UBDSR in bps delay interval of acknowledgements according to equation (6)
from following equation (6). and (7) and set new data sending rate to sends next data
packets from source to destination through intermediate path

43
 International Journal of Applied Information Systems (IJAIS) – ISSN : 2249-0868
Foundation of Computer Science FCS, New York, USA
Volume 2– No.4, May 2012 – www.ijais.org

nodes according to available bandwidth of intermediate path …… Dn

nodes and minimize the congestion and packet drop rate of the
mobile ad-hoc network (4) Step 4: attach routing protocol as AODV to the sender
nodes
(5) Step 5: Broadcast routing packet through all radio range
Congestion
nodes.
case Drop data
S1 D1 (6) Step 6: Check radio range and next neighbour if out of
10Mb/s range go to step 11

90Mb/s (7) Step 7: if yes accept RREQ packet from neighbour and
S2 I1 I2 D2 forward to next neighbour.
50Mb/s

NS-2.31
100Mb/s Simulator
S3 D3

Figure 2- Architecture of TCP/Newreno Scheme Mobile Node = M

. Sender = S Destination= D
Congestion
case
S1 Ack D1 Set Routing AODV

10Mb/s Estimate available

Bandwidth according Broadcast RREQ to
90Mb/s delay defer of ACK
S2 I1 I2 Neighbour
D2 using eq. (6) & (7)
50Mb/s Delay Ack
100Mb/s No
If Range<=250
Change sending rate Delay Ack Set new data
&& Neighbr to D
D3 Sending rate
Out of Range
S3 Yes

Send TCP Pkt Accept RREQ & Fwd

Estimate Available bandwidth to Nxt Neigbr
using Delay Difference of Ack

If Neighbr = D
Figure 3- Architecture of TCP/U_NewReno Scheme
No
3.2 Flow Graph for our Approach Yes
Here we create flow graph 4 according to our algorithm very
first we create mobile node and then sender and receiver node, Send ACK Send Pkt according ideal Send TCP Pkt
sender node call the routing module and generate route basic sending rate eq. (6)
request packet, that time sender broadcast routing packet to its
all neighbour if nodes belong in 250 meter range, if we find
destination so that create routing table and sends routing No
acknowledgement to actual sender node, after that sender
node sends data packet through newly created routes to Send TCPACK
If ACK
destination, After destination node sends acknowledgement to
Yes DELAY?
destination, But our module also check bandwidth of each
node, if any node available bandwidth less than the data rate
of sender node so each intermediate node inbuilt
acknowledgement packet with bandwidth information and Figure 4 Flow Graph for our Module
send to sender node, so that sender node minimize the data (8) Step 8: If Destination Find out create routing table
rate and efficiently utilize available bandwidth with minimize
congestion or avoid congestion on the network. Here above (9) Step 9: Send positive acknowledgment to source node for
approach we use and enhanced the performance of the data sending
network.
(10) Step 10: according to acknowledgment sender set data
Steps of Flow Graph: rate and send it to destination so congestion not comes on the
network.
(1) Step 1: Use NS-2.31 simulator for simulation
(11) Step 11: If received acknowledgments delayed at sender
(2) Step 2: Generate mobile node = M node we estimate available bandwidth of intermediate path
(3) Step 3: Create Senders S1…… Sn and destination D1 nodes using delay interval of acknowledgements and set new
data sending rate to avoid congestion in network.

44
 International Journal of Applied Information Systems (IJAIS) – ISSN : 2249-0868
Foundation of Computer Science FCS, New York, USA
Volume 2– No.4, May 2012 – www.ijais.org

(12) Step 12: Out of range

(13) Step 13: Simulation End //Destination sends TCP ACK to sender node

3.3 Algorithm for Efficient Way TCP Goto Sender (Rx-TCP-ACK);

Communication }
Step1: Create mobile node = M;
Else {
Step2: Set routing protocol = AODV; // for Routing
Destination unreachable;
Protocol
Routing table not exit;
Step3: Set sender = S; // S € M
}
Step4: Set Destination = D; // D € M
Step11: Sender (Rx-TCP-ACK)
Step5: Initialize radio range = 250m;
If (TCP-Ack is delay)
Step6: Set MAC = 802.11; // for Media access {
Control Estimate available bandwidth
Step7: Sender B_RREQ to next-> neighbour; Send TCP data through Minimize new TCP
While (next->neighbour <= 250 || next->neighbour! = Sending-Rate;
Destination) }
{ Else
Accept route requested packet; {
Forward B_RREQ to next neighbour; Send data through basic sending- Rate;
If (next->neighbour == Destination) }
{Create route table; End Simulation;
Check more than one route table;
4. SIMULATION AND RESULT
Send (R_ACK to sender node through We have simulate our work using the simulation NS-2.31
more than one path) network simulator and we have considered different
} parameter to analyze the result .these parameter given in
following table 1. In normal case we have use no of nodes 10
Else { Check route request limit time; , the simulation time is 100 second, packet size 512 bytes and
we have simulate to the Updated TCP New Reno technique on
these parameter and find out the result show in the form of
If (RRLT>= Route search time)
graphs and tables of the congestion window , throughput,
{Exit 0 ;} ,packet drop rate , packet sending rate in MANET .
} Table 1.Simulation parameter
} Sr. No Simulation Environment Parameter
// after connection establish between sender to destination we 1 Simulator Used NS-2.31
apply TCP/Newreno for reliable and congestion control
2 Number of Nodes 10
3 Dimension of simulated 100m×100m
Step8: Attach application data = FTP; //File area
transfer 4 Routing Protocol AODV
Protocol 5 Simulation Time 100 sec.
Step9: Set Agent = TCP/Newreno; //Newreno send 6 Transport Layer TCP , UDP
Data according to available 7 Congestion Window NewReno,U_NewReno
bandwidth Type
8 Traffic Type CBR (3pkt/s)
Step10: Check sender routing table ();
9 Packet Size 512 bytes
If (r_table ==true)
10 Number Of traffic 530
{
connections
Send (TCP pkt to given route at basic 11 Node Movement at random
sending rate) Maximum Speed (m/s)
12 Transmission Range 250m
Destination receives (TCP pkt)

45
 International Journal of Applied Information Systems (IJAIS) – ISSN : 2249-0868
Foundation of Computer Science FCS, New York, USA
Volume 2– No.4, May 2012 – www.ijais.org

In our scheme we have simulate the result using available In graph 7 we analysis second TCP connection on the bases of
bandwidth estimation technique we have obtained the result of above parameter and find out our updated Newreno approch
different parameters that gives improve result than previous give result according to intemediate node bandwidth.
New Reno scheme. These parameters show result in the form
of graphs and tables.

4.1 TCP Congestion Window Analysis

In our simulation we create two TCP connections with New
Reno and NewReno update scheme and analyze the
comparative result between them. That result shows x-
coordinate as simulation time in seconds and y-coordinate
represents congestion window, according to result output
NewReno technique gives constant congestion window from
(0-to- 72) second and after 72 second window size only 10
that result at the time of TCP connection one in figure 5 ,Here
we also compare that result through updated NewReno
technique , this time our result improve in different- different
simulation time and fall because we apply bandwidth
estimation mechanism in NewReno technique so each TCP
sender node change self congestion window according to
intermediate node bandwidth but average result of our scheme
is improved and we minimize the congestion of the network
and increase the packet reception ratio.
Figure 6. TCP Conection -2 Analysis

Here we represent TCP connection analysis in table 3 and

table conclude that updated Newreno gives better result as
comapre to newreno mechanism.

Table 3. TCP Conection -2 Analysis

TCP Connection-2 Analysis

Time NewReno Update_Newreno

1.02147 1 1

5.00548 1 1

10.0015 4 20

Figure 5. TCP Conection -1 Analysis 25.0463 20 20

Here we represent TCP connection analysis in table 2 and 40.0392 20 28

table conclude that updated Newreno gives better result as
comapre to newreno mechanism. 75.0095 3 14

Table 2. TCP Conection -1 Analysis 99.8787 3 16

TCP Connection-1 Analysis

Time NewReno Update_NewReno 4.2 Throughput Analysis
This metric represents the total number of bits forwarded to
1.02147 1 10
higher layers per second. It is measured in bps. It can also be
5.00548 20 26 defined as the total amount of data a receiver actually receives
from sender divided by the time taken by the receiver to
10.0015 20 30 obtain the last packet. In our simulation we use TCP/New
25.0463 20 40 Reno and TCP/U_New Reno mechanism and find out our
updated New Reno approach gives better result on the bases
40.0392 20 45 of throughput that concludes if we use bandwidth estimation
and according to bandwidth data sending technique apply so
75.0095 10 47 our result is very good.
99.8787 10 56

46
 International Journal of Applied Information Systems (IJAIS) – ISSN : 2249-0868
Foundation of Computer Science FCS, New York, USA
Volume 2– No.4, May 2012 – www.ijais.org

Table 5 TCP Packets Send Vs Receives Analysis

TCP Packet Analysis

Sender Node TCP Packet TCP Packet Sends

Sends NewReno Updated NewReno

4 2035 2534

6 1074 1079

Total Packet 3109 3613

Sends

Receiver TCP Packet TCP Packet Receive

Figure 7. Througput Analysis Node Receive Updated NewReno
In table 4 we show the throughput analysis in discrete event of NewReno
time and we get updated TCP New Reno mechanism gives
better throughput at each point as compare to previous TCP 2 1048 1041
NewReno mechanism.
9 2023 2515

Table 4. Througput Analysis Table Total Packet 3071 3556

Receive
Throughput Analysis Table

Time NewReno Update_NewReno

5. ABOUT THE DEMONSTRATION
1.02147 0.97 0.98 In this demo, we analyze TCP congestion control technique
5.00548 725.4 732.507 using updated New Reno and New Reno technique and we get
the result our approach gives best result as compare to
10.0015 696.563 835.75 previous approach. We also use two TCP connection and
parameter as through put.
25.0463 679.835 902.681
6. CONCLUSION AND FUTURE WORK
50.0392 645.22 864.286 In this paper, we have discussed and analyzed issue related to
the TCP congestion control over MANET environment
75.0095 653.162 703.745 through extensive simulation using ns-2. updated New Reno
technique adopts available bandwidth estimation algorithm at
99.8787 591.144 612.295
the sender side to optimize the packet drop rate and
congestion window size and to improve the TCP throughput ,
packet sending rate when network congestion is detected .The
4.3 TCP Sender And Reciver Packet simulation results have confirmed that updated TCP New
Analysis Reno technique has a significant improvement over TCP New
Reno . We conclude that Updated New Reno technique give
That table 5 shows comparison between NewReno and best performance of TCP congestion control over MANET
Updated NewReno, here we create two TCP connections with bandwidth information provide to the sender node so that
node four and six as a sender and two and nine as receivers at sends data according to available bandwidth. Our approach
NewReno case total 3109 packets sends but the update New case throughput is very good as compare to previous New
Reno case 3613 packets sends it means 16% packets sending Reno technique and also decrease packet drop rate. In This
increases and same receiving percentage increases. paper we simulate with two TCP connections case in future
we also analyze denser network case. here we only use
bandwidth estimation mechanism with the acknowledgement
base but acknowledge comes only TCP time if we apply UDP
connection so our module does not work because UDP can’t
gives any acknowledgement so in future we also work UDP
case congestion control scheme and analyze the best possible
result. In future we control congestion through routing
overhead minimization so we apply various location aware
routing protocol like LAR (location aware routing) Dream
routing etc. and minimize the congestion.

47
 International Journal of Applied Information Systems (IJAIS) – ISSN : 2249-0868
Foundation of Computer Science FCS, New York, USA
Volume 2– No.4, May 2012 – www.ijais.org

7. ACKNOWLEDGMENTS [7] S. Floyd, “High Speed TCP for large congestion

The authors are thankful to Samrat Ashok Technological windows,” RFC 3649, December 2003.
Institute, Vidisha (M.P.) India for extending their supports in [8] T. Kelly, “Scalable TCP: improving performance in high
this article. speed wide area networks,” ACM SIGCOMM Computer
Communication Review, vol. 33, no. 2, pp. 83–91, April
8. REFERENCES 2003.
[1] Prasanthi. S and Sang-Hwa Chung “An Efficient
Algorithm for the Performance of TCP over Multi-hop [9] L. S. Brakmo, S. W. O’Malley, and L. L. Peterson, “TCP
Wireless Mesh Networks” 609-735, IEEE 2010. Vegas: new techniques for congestion detection and
avoidance,” in Proceedings of ACM SIGCOMM’02.
[2] J.Postel. Transmission Control Protocol. Network ACM, August 31-September 02 1994, pp. 24–35.
Working Group, Request for Comments: 793, Sep.1981.
[10] S. H. Low, L. L. Peterson, and L. Wang, “Understanding
[3] R.Draves, J.Pandhye and B.Zill, “Routing in Multi-Radio TCP Vegas: a duality model,” Journal of the ACM, vol.
Multi-hop Wireless Mesh Networks”, MOBICOM 2004. 49, no. 2, pp. 207–235, 2002.
[4] V.Kawadia and P.R.kumar,”Experimental Investigations [11] The Network Simulator ns-2
into TCP Performance over Wireless Multihop http://www.isi.edu/nsnam/ns/
Networks”, Proc. Of ACM SIGCOMM,2005
[12] Habibullah Jamal, Kiran Sultan ,” Performance Analysis
[5] D. Wei, C. Jin, S. Low, and S. Hegde, “FAST TCP: of TCP Congestion Control Algorithms”
motivation, architecture, algorithms, performance,” INTERNATIONAL JOURNAL OF COMPUTERS AND
IEEE/ACM Transactions on Networking, vol. 14, no. 6, COMMUNICATIONS, Issue 1, Volume 2, 2008
pp. 1246–1259, 2006.
[13] C. Casetti, M. Gerla, S. Mascolo, M.Y. Sanadidi, and R.
[6] L. Xu, K. Harfoush, and I. Rhee, “Binary Increase Wang. TCP Westwood: End-to-End Congestion Control
Congestion Control (BIC) for fast, long distance for Wired/Wireless Network. In Wireless Networks
networks,” in Proceedings of IEEE INFOCOM’04, journal, volume 8, page 467, 2002.
March 2004, pp. 2514–2524.

48