Ba25315321

Vikram Narayandas, P.Leelavathi, P.Ravinder Kumar, S.Pradeep / International Journal of Engineering
Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com
Vol. 2, Issue 5, September- October 2012, pp.315-321
A Survey and Analysis study on Host-to-Host Congestion Control for
TCP Data Transmission
1
Vikram Narayandas 2 P.Leelavathi 3 P.Ravinder Kumar 4
S.Pradeep
1
Associate Professor, Department of CSE, Jayaprakash Narayan College of Engineering, Mahabubnagar, Andhra Pradesh.
2
Assistant Professor, Department of CSE, Sree Visheshwariah College of Engineering, Mahabubnagar, Andhra Pradesh
3
Associate Professor, Department of ECE, Jayaprakash Narayan College of Engineering, Mahabubnagar, Andhra Pradesh.
4
Assistant Professor Department of IT, Jayaprakash Narayan College of Engineering, Mahabubnagar, Andhra Pradesh

Abstract
The Transmission Control Protocol (TCP) that the TCP congestion control is performed in a
carries most Internet traffic, so performance of the distributed fashion; each end host determines its window
Internet depends to a great extent on how well TCP size by itself according to the information obtained from
works. Performance characteristics of a particular the network. In general, there are two major objectives in
version of TCP are defined by the congestion control the congestion control mechanism. The one is to avoid an
algorithm it employs. This paper presents a survey of occurrence of the network congestion, and to dissolve the
various congestion control proposals that preserve the congestion. if the congestion occurrence cannot be
original host-to-host idea of TCP—namely, that neither avoided. The other is to provide fair service to
sender nor receiver relies on any explicit notification connections. Keeping the fairness among multiple
from the network. The proposed solutions focus on a homogeneous/heterogeneous connections in the network is
variety of problems, starting with the basic problem of an essential feature for the network to be widely accepted.
eliminating the phenomenon of congestion collapse, and The fair service also involves detecting mis–behaving
also include the problems of effectively using the flows which do not properly react against the network
available network resources in different types of congestion and unfairly occupy the network
environments(wired, wireless, high-speed, long-delay, resources.(such as router buffer and link bandwidth).
etc.). In a shared, highly distributed, and heterogeneous In the previous, the sender sends the packets
environment such as the Internet, effective network use without the intermediate station. The data packets has been
depends not only on how well a single TCP based losses many and time is wasted. Retransmission of data
application can utilize the network capacity, but also on packets is difficulty. The standard already requires
how well it cooperates with other applications receivers to report the sequence number of the last in-order
transmitting data through the same network.. There delivered data packet each time a packet is received, even
have been enhancements allowing senders to detect fast if received out of order. For example, in response to a data
packet losses and route changes. Other techniques have packet sequence 5,6,7,10,11,12, the receiver will ACK the
the ability to estimate the loss rate, the bottleneck packet sequence 5,6,7,7,7,7. In the idealized case, the
buffer size, and level of congestion. The survey absence of reordering guarantees that an out-of-order
describes each congestion control alternative, its delivery occurs only if some packet has been lost. Thus, if
strengths and its weaknesses. the sender sees several ACKs carrying the same sequence
numbers (duplicate ACKs), it can be sure that the network
Index Terms—TCP, congestion control, congestion has failed to deliver some data and can act accordingly.
collapse, packet reordering in TCP, wireless high-speed In Proposed system we have designed,
TCP, Data transmission in TCP. developed, and implemented a compromised router
detection protocol that dynamically infers, based on
1. INTRODUCTION measured traffic rates and buffer sizes, the number of
In spite of a rapid growth of the Internet congestive packet losses that will occur.
population and an explosive increase of the traffic demand,
the Internet is still working without collapse. Of course, a The Host to Host congestion control proposals that build a
continuous effort to increase the link bandwidth and router foundation for all currently known host-to-host algorithms.
processing capacity is supporting the Internet growth This foundation includes:
behind the scenes. However, a most essential device for 1) The basic principle of probing the available network
achieving such a success is a congestion control resources,
mechanism provided by a transport– layer protocol, i.e., 2) Loss-based and delay-based techniques to estimate the
TCP (Transmission Control Protocol). In TCP, each end congestion state in the network, and
host controls its packet transmission rate by changing the 3) Techniques to detect packet losses quickly
window size in response to network congestion. A key is

315 | P a g e

TCP standard specifies a sliding window based good understanding of how and when a protocol breaks
flow control. This flow control has several mechanisms. than when it works.
First, the sender buffers all data before the transmission, Security
assigning a sequence number to each buffered byte. -Security and privacy issues
Continuous blocks of the buffered data are packetized into -Sender authentication
TCP packets that include a sequence number of the first
data byte in the packet. Second, a portion (window) of the 2. Algorithms
prepared packets is transmitted to the receiver using the IP 2.1. Slow Start, Congestion Avoidance algorithms,
protocol. As soon as the sender receives delivery
confirmation for at least one data packet, it transmits a new
portion of packets. Finally, the sender holds responsibility
for a data block until the receiver explicitly confirms
delivery of the block. As a result, the sender may
eventually decide that a particular unacknowledged data
block has been lost and start recovery procedures (e.g.,
retransmit one or several packets). To acknowledge data
delivery, the receiver forms an ACK packet that carries
one sequence number and (optionally) several pairs of
sequence numbers. The former, a cumulative ACK,
indicates that all data blocks having smaller sequence
numbers have already been delivered. The latter, a Fig: 2.1.slow start and congestion avoidance
selective ACK explicitly indicates the ranges of sequence Slow Start and Congestion Avoidance algorithms.
numbers of delivered data packets. To be more precise, These provide two slightly different distributed host-to-
TCP does not have a separate ACK packet, but rather uses host mechanisms which allow a TCP sender to detect
flags and option fields in the common TCP header for available network resources and adjust the transmission
acknowledgment purposes. (A TCP packet can be both a rate of the TCP flow to the detected limits. Assuming the
data packet and an ACK packet at the same time.) probability of random packet corruption during
However, without loss of generality, we will discuss a transmission is negligible ( 1%), the sender can treat all
notion of ACK packets as a separate entity. detected packet losses as congestion indicators. In addition,
the reception of any ACK packet is an indication that the
Packet Sequence Numbers: network can accept and deliver at least one new packet
A packet sequence number is a 32 bit number in Thus the sender, reasonably sure it will not cause
the range from 1 through 2^32 û 1, which is used to congestion, can send at least the amount of data that has
specify the sequential order of a Data packet in a Data just been acknowledged. This in-out packet balancing is
Stream. A sender node assigns consecutive sequence called the packet conservation principle and is a core
numbers to the Data packets provided by the Sender element, both of Slow Start and of Congestion Avoidance
application. Zero is reserved to indicate that the data
session has not yet started. 2.2. Fast Packet Recovery algorithms

Data Queue:
A Data Queue is a buffer, maintained by a Sender
or a Repair Head, for transmission and retransmission of between any two nodes may be trivially ba
the Data packets provided by the Sender application. New
Data packets are added to the data queue as they arrive
from the sending application, up to a specified buffer limit.
The admission rate of packets to the network is controlled
by flow and congestion control algorithms. Once a packet
has been received by the Receivers of a Data Stream, it
may be deleted from the buffer.
-Must achieve good link utilization
-Must not starve competing flows.
Fig: 2.2Fast recovery algorithms
Scalability
The protocol should be able to work under a Fast Recovery algorithms, has a direct means to
variety of conditions Include multiple network topologies calculate the number of outstanding data packets using
Variable link speeds Receiver set size can be to the order information extracted from SACKs. Instead of the
of at least 1000 - 10000 It is more important to have a congestion window inflation technique, the FACK

316 | P a g e

maintains three special state variables (Fig H, the highest packets from the initial congestion window are
sequence number of all sent data packets—all data packets acknowledged. More formally, the New Reno algorithm
with sequence number less than H have been sent at least adds a special state variable to remember the sequence
once; (2) F, the forward-most sequence number of all number of the last data packet sent before entering the Fast
acknowledged data packets—no data packets with Recovery state. This value helps to distinguish between
sequence number above F have been delivered. partial and new data ACKs.The reception of a new data
ACK means that all packets sent before the error detection
3. Methodology: were successfully delivered and any new loss would reflect
1. Tcp Host to host Network a new congestion event. A partial ACK confirms the
Host-to-host principle, meaning they do not rely recovery from only the first error and indicates more losses
on any kind of explicit signaling from the network.1 The in the original bundle of packets.
proposed algorithms introduce a wide variety of techniques
that allow senders to detect loss events, congestion state, 4. Calculate RTO & RTT Module:
and route changes, as well as measure the loss rate, the 3.4.1; RTO -Retransmission timeout estimate. If this value
RTT, the RTT variation, bottleneck buffer sizes, and is overestimated, the TCP packet loss detection mechanism
congestion level becomes very conservative, and performance of individual
flows may severely degrade. In the opposite case, when the
2 .Congestion Collapse value of the RTO is underestimated, the error detection
TCP sender’s estimate of the number of data mechanism may perform unnecessary retransmissions,
packets the network can accept for delivery without wasting shared network resources and worsening the
becoming congested. In the special case where the flow overall congestion in the network
control limit (the so-called receiver window) is less than
the congestion control limit (i.e., the congestion window), 3.4.2. RTT -Round-trip time after sending the lost packet.
the former is considered a real bound for outstanding data The RTO, by definition, is greater than RTT. If we require
packets. Although this is a formal definition of the real that TCP receivers immediately reply to all out-of-order
TCP rate bound, we will only consider the congestion data packets with reports of the last in order packet a
window as a rate limiting factor, assuming that in most duplicate ACK , the loss can be detected by the Fast
cases the processing rate of end-hosts is several orders of Retransmit algorithm , almost within the RTT interval. In
magnitude higher than the data transfer rate that the other words, assuming the probability of packet reordering
network can potentially offer. Additionally, we will and duplication in the network is negligible; the duplicate
compare different algorithms, focusing on the congestion ACK s can be considered a reliable loss indicator. Having
window dynamics as a measure of the particular this new indicator, the sender can retransmit lost data
congestion control algorithm effectiveness without waiting for the corresponding RTO event.

3. Congestion Avoidance & Packet Recovery Module: We measure the fairness in sharing the bottleneck
Congestion control algorithm, the purpose of bandwidth among competing flows that have different
which is to reduce consumption of network resources in RTTs. There are several notions of ―RTT fairness‖. One
complex congestion situations. But this expectation rests notion is to achieve the equal bandwidth sharing where the
on the assumption that congestion states, as deduced from two competing flows may share the same bottleneck
each detected loss, are independent, and in the example bandwidth even if they have different RTTs. This property
above this does not hold true. All packet losses from the may not be always desirable because long RTT flows tend
original data bundle (i.e., from those data packets to use more resources than short RTT flows since they are
outstanding at the moment of loss detection) have a high likely to travel through more routers over a longer path.
probability of being caused by a single congestion event. Another notion is to have bandwidth shares inversely
Thus, the second and third losses from the example above proportional to the RTT ratios. This proportional fairness
should be treated only as requests to retransmit data and makes more sense in terms of the overall end-to-end
not as congestion indicators. resource usage. Although there is no commonly accepted
Moreover, reducing the congestion window does notion of RTT-fairness, it is clear that the bandwidth share
not guarantee the instant release of network resources. All ratio should be within some reasonable bound so that no
packets sent before the congestion window reductions are flows are being starved because they travel a longer
still in transit. Before the new congestion window size distance. Note that RTT-fairness is highly correlated with
becomes effective, we should not apply any additional rate the amount of randomness in packet losses (or in other
reduction policies. This can be interpreted as reducing the words, the amount of loss synchronization).
congestion window no more often than once per one-way
propagation delay or approximately RTT/2 . Reno’s Fast 5. Data Transmission in TCP
Recovery. It solves the ambiguity of congestion events by Data is multicast by a Sender on the Data
restricting the exit from the recovery phase until all data Multicast Address. Retransmissions of data packets may be

317 | P a g e

multicast by the Sender on the Data Multicast Address or with the dynamic global tree parameters, PACK provides a
be multicast on a Local Control Channel by a Repair Head. set of algorithms that carefully control and manage this
In order to provide NACK suppression and to work with traffic, preventing control traffic explosion.
proactive FEC, retransmissions are always multicast. If Despite their different names, ACKs and NACKs both
Generic Router Assist is enabled, the routers may provide function as selective acknowledgements of the window of
NACK suppression and allow dynamically scoped contiguous sequence numbers that have not yet been fully
retransmission to just the subset of Receivers and Repair acknowledged. The only difference between the packet
Heads that have missed a packet. A Repair Head joins all headers is a single flag.
of the Data Multicast Addresses that any of its descendants ACK packet frequency is controlled by setting a number of
have joined. A Repair Head is responsible for receiving tree wide parameters controlling their maximum rate of
and buffering all data packets using the reliability generation. The primary parameter is the ratio parameter,
semantics configured for a stream. As a simple to R, for the maximum number of ACK packets to be
implement option, a Repair Head may also function as a generated per data packet sent. The higher R is, the faster
Receiver, and pass these data packets to an attached positive acknowledgements will be generated all the way
application. For additional fault tolerance, a Receiver back to the sender. This induces more back-channel traffic.
MAY subscribe to the multicast address associated with ACKs must be enabled for any Data Session. NACKs
the Local Control Channel of one or more Repair Heads in should be implemented as part of any implementation, and
addition to the multicast address of its parent. In this case it may be enabled for any given Data Session. If enabled,
does not bind to this Repair Head or Sender, but will then on detection of a lost packet, a Receiver waits a
process Retransmission packets sent to this address. If the random interval before sending a NACK. If the Receiver
Receiver's Repair Head fails and it transfers to another receives the retransmitted data before the NACK timer
Repair Head, this minimizes the number of data packets it expires, the Receiver cancels the NACK. This reduces the
needs to recover after binding to the new Repair Head. chance that multiple Receivers generate a NACK for the
same packet. Repair Head node multicasts a Data packet to
5.1. Local Retransmission its children as soon as it gets a NACK request for that
If a Repair Head or Sender determines from its packet, unless it retransmitted that packet previously in a
child node's ACKs or NACKs that a Data packet was configurable time period. If it does not have the missing
missed, the Repair Head retransmits the Data packet or, if packet, it forwards the NACK to its parent, and multicasts
FEC is enabled, an FEC parity packet. The Repair Head or a control packet to its children to suppress any further
Sender multicasts the Retransmission packet on its NACKs for that packet from them. The Repair Head
multicast Local Control Channel. In the event that a Repair forwards only one NACK for a missing Data packet within
Head receives a retransmission and knows that its children a specified period of time. If more than one packet has
need this repair, it re-multicasts the retransmission to its been detected as missing before the NACK is sent, the
children. NACK will request all of the missing packets.

5.2 .Dynamically Scoped Retransmission 5.4. Integrated Forward Error Correction
Dynamically Scoped Retransmission may be used This feature encodes data packets with FEC
on a network whose routers support dynamically scoped algorithms, but does not transmit the parity packets until a
retransmissions through Generic Router Assist. loss is detected. The parity packets are then transmitted
Dynamically Scoped Retransmissions use soft state kept in and are able to repair different lost packets at different
the routers to constrain the Retransmission to only the Receivers. This is a powerful tool for providing scalability
children that have requested them through a NACK. in the face of independent loss. When implemented, it is a
Dynamically Scoped Retransmissions are known to be simple matter to also provide proactive FEC which
susceptible to router topology changes. Therefore, only the automatically transmits a certain percentage of parity
first retransmission of a packet is sent via this mechanism. packets along with the data. This is particularly useful
Thereafter, only the above two mechanisms should be when a high minimum error rate is expected, or when low
used. This will allow the protocol to provide connectivity latency is particularly important. Both of these are
even during router topology changes, albeit with less optionally supported in PACK.
efficiency. FEC is organized around windows of packets. PACK Data
packets include an FEC offset window field, which
5.3 .Control Traffic Management identifies the offset of a given packet within an FEC
One of the largest challenges for scaleable reliable window. Combined with the FEC session configuration
multicast protocols has been that of controlling the parameters, this allows receivers to decode a combination
potential explosion of control traffic. There is a of Data and parity packets, to generate each window of
fundamental tradeoff between the latency with which Data packets. Proactive FEC packets are parity packets
losses can be detected and repaired, and the amount of sent as global retransmissions at the same time a window
control traffic generated by the protocol. In conjunction of Data packets are sent. Reactive FEC packets are sent

318 | P a g e

either from a Repair Head or a Sender, in response to none of the sessions are active, then the Receiver sends
requests for retransmissions. If using reactive FEC, a Heartbeat Response packets to its parent. If a Receiver's
Repair Head must first have all the packets in a window parent node does not receive a ACK, NACK or a Heartbeat
before it can respond to any request for retransmission. Response packet within a specified time interval, the
The ACK and NACK bitmaps, combined with the parent detects the failure of the Receiver and removes the
information in the headers of the Data packets, provides child from its child list. PACK supports an option which
each Repair Head with enough information to determine allows the nodes in the PACK tree to acquire the addresses
which parity packets the RH must compute and send in and location of its ancestors in the control tree and the
response to requests for retransmission. addresses of its parent's siblings. If a PACK node's parent
fails, then the node can use the acquired information to join
5.5 Flow and Congestion Control an alternate control node. When a child node detects
Flow and congestion control algorithms act to failure of its parent node, it can try to reconnect to an
prevent the Senders from overflowing the Receivers' alternate Repair Head of the PACK tree, or it can try to
buffers and to force them to share the network fairly and reconnect directly to the Sender.
safely with other TCP and RM connections. PACK uses a The reliability semantics PACK provides are defined by
combination of a transmission window for flow control, the binding between a receiver and its repair head. When
and the dynamic rate control algorithms specified in the this binding is established, the repair head agrees to
Congestion Control (CC) BB for congestion control. These provide retransmission of missed packets for the receiver
algorithms have been proven to meet all the requirements starting from a specific (receiver requested) sequence
for flow and congestion control, including being safe for number. At this time, the repair head MUST not have
use in a general Internet environment, and provably fair discarded any data packet starting from this sequence
with TCP. number. Subsequently, a repair head needs to discard older
The Sender application provides the minimum and packets from its buffer from time to time. The following
maximum rate limits as part of the global parameters. A two factors influence when to discard an old packet: a)
Sender will not transmit at lower than the minimum rate Stability - When all receivers immediately subordinate to
(except possibly during short periods of time when certain the repair head have acknowledged receipt of a packet, that
slow receivers are being ejected), or higher than the packet is considered stable. When the whole sub-tree of
maximum rate. If a Receiver is not able to keep up with the receivers below a repair head have received a packet, it is
minimum rate for a period of time, the CC BB algorithms considered as "strictly stable". PACK provides no explicit
will cause it to leave the group. Receivers that leave the support for this strict sense of stability (note this form of
group MAY attempt to rejoin the group at a later time, but reliability is also referred to as "pessimistic reliability"). b)
SHOULD NOT attempt an immediate reconnection. Sender recovery window - Each data packet carries two
sequence numbers: one is the sequence number of the
5.6. Notification of Confirmed Delivery current data packet, and the other is the sender
PACK provides a simple membership count for recommended sequence number where recovery should
each session. This is done by each repair head start from (smaller than the current sequence number). This
counting/aggregating its (sub tree) membership count and pair of sequence numbers forms a sender-suggested
propagating it up the tree to the sender. The propagation up recovery window. A repair head must not discard any
the tree is piggybacked on the regular PACK (ACK and packet before it becomes stable. Per binding agreement or
NACK) packets. session wide configuration, a repair head may be allowed
to discard a packet when it moves outside of the sender
5.7 Sender node failure detection and Repair Head recovery window. When a repair head's buffer is filled up
failure detection: and none of the packets can be discarded (due to stability
A Sender node that has no data to send will or recovery window requirements), newly arrived packets
periodically send Null Data packets on the Data Multicast must be discarded and recovered later.
Address. If a Receiver or a Repair Head fails to receive
Data packets or Null Data packets for a session sent by the 6. NACK-based Reliability
Sender, the Receiver detects a Sender failure. Each Repair This building block defines NACK-based loss
Head node sends Heartbeat packets to its child nodes on its detection/notification and recovery. The major issues it
multicast Control Tree. If the child nodes do not receive addresses are implosion prevention (suppression) and
any Heartbeats from their parent Repair Head, they detect NACK semantics (i.e. how packets to be retransmitted
failure of the parent. should be specified, both in the case of selective and FEC
loss repair). The NACK suppression mechanisms used by
5.8. Receiver node failure detection and Repair Head PACK are unicast NACKs with multicast confirmation and
discovery exponentially distributed timers. These suppression
A Receiver node sends ACKs and (optionally) mechanisms primarily need to both minimize delay while
NACKs for each of the active sessions that it has joined. If also minimizing redundant messages. They may also need

319 | P a g e

to have special weighting to work with Congestion survey on congestion control for mobile ad hoc
Feedback. networks,‖ Wireless Communications and
Mobile Computing, vol. 7, no. 5, p. 655, 2007.
6.1. NACK BB Algorithms [2]. A . Al Hanbali, E. Altman, and P. Nain, ―A
Exponential Back Off. When a packet is detected survey of TCP over ad hoc networks,‖ IEEE
as lost, an exponentially distributed timer is set, based on Commun. Surveys Tutorials, vol. 7, no. 3, pp.
the algorithms. This timer is biased based on the input 22–36, 3rd quarter 2005.
congestion weighting factor. If either a packet or an [3] J. Widmer, R. Denda, and M. Mauve, ―A
explicit suppression message with the same sequence survey on TCP-friendly congestion control,‖
number is detected before the timer goes off, the timer is IEEE Network, vol. 15, no. 3, pp. 28–37,
cancelled. NACK Generation. When a timer goes off, the May/June 2001.
protocol instantiation is notified to generate a NACK for [4]. K.-C. Leung, V. Li, and D. Yang, ―An
that sequence number. The protocol instantiation may, at overview of packet reordering in transmission
its discretion, group multiple NACK notifications in to a control protocol (TCP): problems, solutions, and
single NACK packet. For PACK, NACKs are challenges,‖ IEEE Trans. Parallel Distrib. Syst.,
implemented as a unicast packet with a multicast vol. 18, no. 4, pp. 522–535, April 2007.
confirmation response. [5] S . Low, F. Paganini, and J. Doyle, ―Internet
Response to a Retransmission Request. When a Repair congestion control,‖ IEEE Control Syst. Mag.,
Head or other possible retransmission agent receives the vol. 22, no. 1, pp. 28–43, February 2002.
first NACK from another group member for a given [6]. M. Gerla and L. Kleinrock,―Flow control
packet, it notifies the protocol instantiation to send either a comparative survey,‖ IEEE Trans. Common.,
data retransmission or, if it doesn't have the packet for vol. 28, no. 4, pp. 553–574, April 1980.
retransmission, an optional suppression message. It then [7] J . Nagle, ―RFC896—Congestion control in
sets an embargo timeout, tied to the RTT to the furthest IP/TCP internet works,‖ RFC, 1984.
Receiver, during which other requests for the same packet [8] S .Floyd, T.Henderson, and A.Gurtov,
will be ignored. The length of this embargo doubles each ―RFC3782the New Reno modification to TCP’s
time that a retransmission is sent. This algorithm should fast recovery algorithm,‖ RFC, 2004.
also work with requests for retransmissions that come in
the form of ACKs, as the algorithms and packet formats Author’s Information:
for both are identical, with the exception of the suppression
mechanisms used.

7. CONCLUSION
In this paper we have presented a survey of 1. Vikram Narayandas M.Tech (CN) from Shadan
various approaches to TCP congestion control that do not College of Engineering, R.R Dist, B.Tech (CSIT) from
rely on any explicit signaling from the network. The Sree Datta college of Engineering, Hyderabad and.
survey highlighted the fact that the research focus has Currently he is working as Associate Professor at
changed with the development of the Internet, from the Jayaprakash Narayan College of Engineering,
basic problem of eliminating the congestion collapse Mahabubnagar. And he has 6 years of experience in
phenomenon to problems of using available network Teaching. His areas of interest include Computer networks,
resources effectively in different types of environments wire less networks, Data mining, Network Security,
(wired, wireless, high-speed, long-delay, etc.). In the first Software Engineering, Sensor Networks, and Cloud
part of this survey, we classified and discussed proposals Computing. He is the membership of IJMRA, IACSIT,
that build a foundation for host-to-host congestion control ISTE, IAENG, and CSTA. He is Peer reviewer on
principles. We showed that technology advances have honorary basis of GJCST.He is Associate Editor for
introduced new challenges for TCP congestion control. IJMRA. He has Published 12 papers in International
First, we discussed several solutions ―good‖ flow rate and Journals.
using this rate as a baseline to distinguish between
congestion or random packet loss. Second, we reviewed a
group of solutions with the most research interest over the
recent past. These proposals aim to solve the problem of
poor utilization of high-speed or long-delay network
channels by TCP flows. Finally we showed data
transmission in TCP.
2.P.Leelavathi M.Tech(CSE) from Nishitha College of
REFERENCES: Engineering M.Sc (computers) from osmania University
Currently She is working as Assistant Professor at Sree
[1}. C. Lechers, B. Scheuermann, and M. Mauve, ―A

320 | P a g e

visheshwariah College of Engineering Her areas of interest
include computer networks and communications ,wireless
networks, signal processing .data mining ,sensor networks
.

3.P.Ravinder Kumar M.Tech(WMC) from vardhaman
college of engineering ,B.Tech(ECE) from JayaPrakash
Narayana College of Engineering Currently he is working
as Associate Professor at Jayaprakash narayan college of
engineering And has 9 years of Experience in teaching .
His areas of interest include computer networks and
communications, wireless networks, signal processing.

4.S.Pradeep M.Tech CSE from Jaya prakash Narayana
College of Engineering & Technology B.Tech from jaya
prakash narayana College of Engineering. Currently he is
working as Assistant Professor at Jaya prakash Narayana
College of Engineering. His areas of interest include Data
mining, Network Security, Software Engineering and
Sensor Network.

321 | P a g e

Ba25315321

More Related Content

What's hot

Similar to Ba25315321

Ba25315321