Ba25315321
Upcoming SlideShare
Loading in...5
×
 

Ba25315321

on

  • 252 views

 

Statistics

Views

Total Views
252
Views on SlideShare
252
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Ba25315321 Ba25315321 Document Transcript

    • 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 PradeshAbstract The Transmission Control Protocol (TCP) that the TCP congestion control is performed in acarries most Internet traffic, so performance of the distributed fashion; each end host determines its windowInternet depends to a great extent on how well TCP size by itself according to the information obtained fromworks. Performance characteristics of a particular the network. In general, there are two major objectives inversion of TCP are defined by the congestion control the congestion control mechanism. The one is to avoid analgorithm it employs. This paper presents a survey of occurrence of the network congestion, and to dissolve thevarious congestion control proposals that preserve the congestion. if the congestion occurrence cannot beoriginal host-to-host idea of TCP—namely, that neither avoided. The other is to provide fair service tosender nor receiver relies on any explicit notification connections. Keeping the fairness among multiplefrom the network. The proposed solutions focus on a homogeneous/heterogeneous connections in the network isvariety 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–behavingalso include the problems of effectively using the flows which do not properly react against the networkavailable network resources in different types of congestion and unfairly occupy the networkenvironments(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 packetsenvironment such as the Internet, effective network use without the intermediate station. The data packets has beendepends not only on how well a single TCP based losses many and time is wasted. Retransmission of dataapplication can utilize the network capacity, but also on packets is difficulty. The standard already requireshow well it cooperates with other applications receivers to report the sequence number of the last in-ordertransmitting data through the same network.. There delivered data packet each time a packet is received, evenhave been enhancements allowing senders to detect fast if received out of order. For example, in response to a datapacket losses and route changes. Other techniques have packet sequence 5,6,7,10,11,12, the receiver will ACK thethe ability to estimate the loss rate, the bottleneck packet sequence 5,6,7,7,7,7. In the idealized case, thebuffer size, and level of congestion. The survey absence of reordering guarantees that an out-of-orderdescribes each congestion control alternative, its delivery occurs only if some packet has been lost. Thus, ifstrengths and its weaknesses. the sender sees several ACKs carrying the same sequence numbers (duplicate ACKs), it can be sure that the networkIndex 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 on1. 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 acontinuous 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 networkachieving 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 theTCP (Transmission Control Protocol). In TCP, each end congestion state in the network, andhost controls its packet transmission rate by changing the 3) Techniques to detect packet losses quicklywindow size in response to network congestion. A key is 315 | P a g e
    • 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 TCP standard specifies a sliding window based good understanding of how and when a protocol breaksflow control. This flow control has several mechanisms. than when it works.First, the sender buffers all data before the transmission, Securityassigning a sequence number to each buffered byte. -Security and privacy issuesContinuous blocks of the buffered data are packetized into -Sender authenticationTCP packets that include a sequence number of the firstdata byte in the packet. Second, a portion (window) of the 2. Algorithmsprepared packets is transmitted to the receiver using the IP 2.1. Slow Start, Congestion Avoidance algorithms,protocol. As soon as the sender receives deliveryconfirmation for at least one data packet, it transmits a newportion of packets. Finally, the sender holds responsibilityfor a data block until the receiver explicitly confirmsdelivery of the block. As a result, the sender mayeventually decide that a particular unacknowledged datablock has been lost and start recovery procedures (e.g.,retransmit one or several packets). To acknowledge datadelivery, the receiver forms an ACK packet that carriesone sequence number and (optionally) several pairs ofsequence numbers. The former, a cumulative ACK,indicates that all data blocks having smaller sequencenumbers have already been delivered. The latter, a Fig: 2.1.slow start and congestion avoidanceselective 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 detectflags and option fields in the common TCP header for available network resources and adjust the transmissionacknowledgment purposes. (A TCP packet can be both a rate of the TCP flow to the detected limits. Assuming thedata packet and an ACK packet at the same time.) probability of random packet corruption duringHowever, without loss of generality, we will discuss a transmission is negligible ( 1%), the sender can treat allnotion 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 thePacket 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 causethe range from 1 through 2^32 û 1, which is used to congestion, can send at least the amount of data that hasspecify the sequential order of a Data packet in a Data just been acknowledged. This in-out packet balancing isStream. A sender node assigns consecutive sequence called the packet conservation principle and is a corenumbers to the Data packets provided by the Sender element, both of Slow Start and of Congestion Avoidanceapplication. Zero is reserved to indicate that the datasession has not yet started. 2.2. Fast Packet Recovery algorithmsData Queue: A Data Queue is a buffer, maintained by a Senderor a Repair Head, for transmission and retransmission of between any two nodes may be trivially bathe Data packets provided by the Sender application. NewData packets are added to the data queue as they arrivefrom the sending application, up to a specified buffer limit.The admission rate of packets to the network is controlledby flow and congestion control algorithms. Once a packethas been received by the Receivers of a Data Stream, itmay be deleted from the buffer.-Must achieve good link utilization-Must not starve competing flows. Fig: 2.2Fast recovery algorithmsScalability The protocol should be able to work under a Fast Recovery algorithms, has a direct means tovariety of conditions Include multiple network topologies calculate the number of outstanding data packets usingVariable link speeds Receiver set size can be to the order information extracted from SACKs. Instead of theof at least 1000 - 10000 It is more important to have a congestion window inflation technique, the FACK 316 | P a g e
    • 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-321maintains three special state variables (Fig H, the highest packets from the initial congestion window aresequence number of all sent data packets—all data packets acknowledged. More formally, the New Reno algorithmwith sequence number less than H have been sent at least adds a special state variable to remember the sequenceonce; (2) F, the forward-most sequence number of all number of the last data packet sent before entering the Fastacknowledged data packets—no data packets with Recovery state. This value helps to distinguish betweensequence 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 detection3. Methodology: were successfully delivered and any new loss would reflect1. 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 losseson any kind of explicit signaling from the network.1 The in the original bundle of packets.proposed algorithms introduce a wide variety of techniquesthat 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 valueRTT, the RTT variation, bottleneck buffer sizes, and is overestimated, the TCP packet loss detection mechanismcongestion level becomes very conservative, and performance of individual flows may severely degrade. In the opposite case, when the2 .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 thebecoming congested. In the special case where the flow overall congestion in the networkcontrol limit (the so-called receiver window) is less thanthe 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 requirepackets. Although this is a formal definition of the real that TCP receivers immediately reply to all out-of-orderTCP rate bound, we will only consider the congestion data packets with reports of the last in order packet awindow as a rate limiting factor, assuming that in most duplicate ACK , the loss can be detected by the Fastcases the processing rate of end-hosts is several orders of Retransmit algorithm , almost within the RTT interval. Inmagnitude higher than the data transfer rate that the other words, assuming the probability of packet reorderingnetwork can potentially offer. Additionally, we will and duplication in the network is negligible; the duplicatecompare different algorithms, focusing on the congestion ACK s can be considered a reliable loss indicator. Havingwindow dynamics as a measure of the particular this new indicator, the sender can retransmit lost datacongestion 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 differentwhich is to reduce consumption of network resources in RTTs. There are several notions of ―RTT fairness‖. Onecomplex congestion situations. But this expectation rests notion is to achieve the equal bandwidth sharing where theon the assumption that congestion states, as deduced from two competing flows may share the same bottleneckeach detected loss, are independent, and in the example bandwidth even if they have different RTTs. This propertyabove this does not hold true. All packet losses from the may not be always desirable because long RTT flows tendoriginal data bundle (i.e., from those data packets to use more resources than short RTT flows since they areoutstanding 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 inverselyThus, the second and third losses from the example above proportional to the RTT ratios. This proportional fairnessshould be treated only as requests to retransmit data and makes more sense in terms of the overall end-to-endnot 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 sharenot guarantee the instant release of network resources. All ratio should be within some reasonable bound so that nopackets sent before the congestion window reductions are flows are being starved because they travel a longerstill in transit. Before the new congestion window size distance. Note that RTT-fairness is highly correlated withbecomes effective, we should not apply any additional rate the amount of randomness in packet losses (or in otherreduction policies. This can be interpreted as reducing the words, the amount of loss synchronization).congestion window no more often than once per one-waypropagation delay or approximately RTT/2 . Reno’s Fast 5. Data Transmission in TCPRecovery. It solves the ambiguity of congestion events by Data is multicast by a Sender on the Datarestricting the exit from the recovery phase until all data Multicast Address. Retransmissions of data packets may be 317 | P a g e
    • 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-321multicast by the Sender on the Data Multicast Address or with the dynamic global tree parameters, PACK provides abe multicast on a Local Control Channel by a Repair Head. set of algorithms that carefully control and manage thisIn 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 bothGeneric Router Assist is enabled, the routers may provide function as selective acknowledgements of the window ofNACK suppression and allow dynamically scoped contiguous sequence numbers that have not yet been fullyretransmission to just the subset of Receivers and Repair acknowledged. The only difference between the packetHeads 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 ofhave joined. A Repair Head is responsible for receiving tree wide parameters controlling their maximum rate ofand 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 beimplement option, a Repair Head may also function as a generated per data packet sent. The higher R is, the fasterReceiver, and pass these data packets to an attached positive acknowledgements will be generated all the wayapplication. 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. NACKsthe Local Control Channel of one or more Repair Heads in should be implemented as part of any implementation, andaddition 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 aprocess Retransmission packets sent to this address. If the random interval before sending a NACK. If the ReceiverReceivers Repair Head fails and it transfers to another receives the retransmitted data before the NACK timerRepair Head, this minimizes the number of data packets it expires, the Receiver cancels the NACK. This reduces theneeds 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 to5.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 achild nodes ACKs or NACKs that a Data packet was configurable time period. If it does not have the missingmissed, the Repair Head retransmits the Data packet or, if packet, it forwards the NACK to its parent, and multicastsFEC is enabled, an FEC parity packet. The Repair Head or a control packet to its children to suppress any furtherSender multicasts the Retransmission packet on its NACKs for that packet from them. The Repair Headmulticast Local Control Channel. In the event that a Repair forwards only one NACK for a missing Data packet withinHead receives a retransmission and knows that its children a specified period of time. If more than one packet hasneed this repair, it re-multicasts the retransmission to its been detected as missing before the NACK is sent, thechildren. 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 FECon a network whose routers support dynamically scoped algorithms, but does not transmit the parity packets until aretransmissions through Generic Router Assist. loss is detected. The parity packets are then transmittedDynamically Scoped Retransmissions use soft state kept in and are able to repair different lost packets at differentthe routers to constrain the Retransmission to only the Receivers. This is a powerful tool for providing scalabilitychildren that have requested them through a NACK. in the face of independent loss. When implemented, it is aDynamically Scoped Retransmissions are known to be simple matter to also provide proactive FEC whichsusceptible to router topology changes. Therefore, only the automatically transmits a certain percentage of parityfirst retransmission of a packet is sent via this mechanism. packets along with the data. This is particularly usefulThereafter, only the above two mechanisms should be when a high minimum error rate is expected, or when lowused. This will allow the protocol to provide connectivity latency is particularly important. Both of these areeven 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, which5.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 configurationmulticast protocols has been that of controlling the parameters, this allows receivers to decode a combinationpotential explosion of control traffic. There is a of Data and parity packets, to generate each window offundamental tradeoff between the latency with which Data packets. Proactive FEC packets are parity packetslosses can be detected and repaired, and the amount of sent as global retransmissions at the same time a windowcontrol traffic generated by the protocol. In conjunction of Data packets are sent. Reactive FEC packets are sent 318 | P a g e
    • 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-321either from a Repair Head or a Sender, in response to none of the sessions are active, then the Receiver sendsrequests for retransmissions. If using reactive FEC, a Heartbeat Response packets to its parent. If a ReceiversRepair Head must first have all the packets in a window parent node does not receive a ACK, NACK or a Heartbeatbefore it can respond to any request for retransmission. Response packet within a specified time interval, theThe ACK and NACK bitmaps, combined with the parent detects the failure of the Receiver and removes theinformation in the headers of the Data packets, provides child from its child list. PACK supports an option whicheach Repair Head with enough information to determine allows the nodes in the PACK tree to acquire the addresseswhich parity packets the RH must compute and send in and location of its ancestors in the control tree and theresponse to requests for retransmission. addresses of its parents siblings. If a PACK nodes parent fails, then the node can use the acquired information to join5.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 anprevent the Senders from overflowing the Receivers alternate Repair Head of the PACK tree, or it can try tobuffers 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 bycombination of a transmission window for flow control, the binding between a receiver and its repair head. Whenand the dynamic rate control algorithms specified in the this binding is established, the repair head agrees toCongestion Control (CC) BB for congestion control. These provide retransmission of missed packets for the receiveralgorithms have been proven to meet all the requirements starting from a specific (receiver requested) sequencefor flow and congestion control, including being safe for number. At this time, the repair head MUST not haveuse in a general Internet environment, and provably fair discarded any data packet starting from this sequencewith TCP. number. Subsequently, a repair head needs to discard olderThe Sender application provides the minimum and packets from its buffer from time to time. The followingmaximum 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, thatslow receivers are being ejected), or higher than the packet is considered stable. When the whole sub-tree ofmaximum rate. If a Receiver is not able to keep up with the receivers below a repair head have received a packet, it isminimum rate for a period of time, the CC BB algorithms considered as "strictly stable". PACK provides no explicitwill cause it to leave the group. Receivers that leave the support for this strict sense of stability (note this form ofgroup 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 the5.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 shouldeach session. This is done by each repair head start from (smaller than the current sequence number). Thiscounting/aggregating its (sub tree) membership count and pair of sequence numbers forms a sender-suggestedpropagating it up the tree to the sender. The propagation up recovery window. A repair head must not discard anythe tree is piggybacked on the regular PACK (ACK and packet before it becomes stable. Per binding agreement orNACK) packets. session wide configuration, a repair head may be allowed to discard a packet when it moves outside of the sender5.7 Sender node failure detection and Repair Head recovery window. When a repair heads buffer is filled upfailure 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 packetsperiodically send Null Data packets on the Data Multicast must be discarded and recovered later.Address. If a Receiver or a Repair Head fails to receiveData packets or Null Data packets for a session sent by the 6. NACK-based ReliabilitySender, the Receiver detects a Sender failure. Each Repair This building block defines NACK-based lossHead node sends Heartbeat packets to its child nodes on its detection/notification and recovery. The major issues itmulticast Control Tree. If the child nodes do not receive addresses are implosion prevention (suppression) andany Heartbeats from their parent Repair Head, they detect NACK semantics (i.e. how packets to be retransmittedfailure of the parent. should be specified, both in the case of selective and FEC loss repair). The NACK suppression mechanisms used by5.8. Receiver node failure detection and Repair Head PACK are unicast NACKs with multicast confirmation anddiscovery exponentially distributed timers. These suppression A Receiver node sends ACKs and (optionally) mechanisms primarily need to both minimize delay whileNACKs for each of the active sessions that it has joined. If also minimizing redundant messages. They may also need 319 | P a g e
    • 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-321to have special weighting to work with Congestion survey on congestion control for mobile ad hocFeedback. 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,‖ IEEEas 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, ―Aexplicit 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, ―Anthat sequence number. The protocol instantiation may, at overview of packet reordering in transmissionits discretion, group multiple NACK notifications in to a control protocol (TCP): problems, solutions, andsingle NACK packet. For PACK, NACKs are chal- lenges,‖ 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, ―InternetResponse 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 controlpacket, it notifies the protocol instantiation to send either a comparative survey,‖ IEEE Trans. Common.,data retransmission or, if it doesnt 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 insets 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’stime that a retransmission is sent. This algorithm should fast recovery algorithm,‖ RFC, 2004.also work with requests for retransmissions that come inthe form of ACKs, as the algorithms and packet formats Author’s Information:for both are identical, with the exception of the suppressionmechanisms used.7. CONCLUSION In this paper we have presented a survey of 1. Vikram Narayandas M.Tech (CN) from Shadanvarious approaches to TCP congestion control that do not College of Engineering, R.R Dist, B.Tech (CSIT) fromrely 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 atchanged 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 inphenomenon 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 Cloudpart 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 onprinciples. We showed that technology advances have honorary basis of GJCST.He is Associate Editor forintroduced new challenges for TCP congestion control. IJMRA. He has Published 12 papers in InternationalFirst, we discussed several solutions ―good‖ flow rate and Journals.using this rate as a baseline to distinguish betweencongestion or random packet loss. Second, we reviewed agroup of solutions with the most research interest over therecent past. These proposals aim to solve the problem ofpoor utilization of high-speed or long-delay networkchannels by TCP flows. Finally we showed datatransmission in TCP. 2.P.Leelavathi M.Tech(CSE) from Nishitha College ofREFERENCES: 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
    • 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-321visheshwariah College of Engineering Her areas of interestinclude computer networks and communications ,wirelessnetworks, signal processing .data mining ,sensor networks.3.P.Ravinder Kumar M.Tech(WMC) from vardhamancollege of engineering ,B.Tech(ECE) from JayaPrakashNarayana College of Engineering Currently he is workingas Associate Professor at Jayaprakash narayan college ofengineering And has 9 years of Experience in teaching .His areas of interest include computer networks andcommunications, wireless networks, signal processing.4.S.Pradeep M.Tech CSE from Jaya prakash NarayanaCollege of Engineering & Technology B.Tech from jayaprakash narayana College of Engineering. Currently he isworking as Assistant Professor at Jaya prakash NarayanaCollege of Engineering. His areas of interest include Datamining, Network Security, Software Engineering andSensor Network. 321 | P a g e