1 / 22

TCP Vegas : New Techniques for Congestion Detection and Avoidance

TCP Vegas : New Techniques for Congestion Detection and Avoidance. Jaime Johnson Nathan Daniel Anil Koneri Yuhang Lin Vineeth Chander. Introduction. TCP protocol performance. Congestion window, congestion avoidance(CA) & detection(CD). TCP Vegas vs. Reno

emcdougal
Télécharger la présentation

TCP Vegas : New Techniques for Congestion Detection and Avoidance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TCP Vegas: New Techniques for Congestion Detection and Avoidance • Jaime Johnson • Nathan Daniel Anil Koneri • Yuhang Lin • Vineeth Chander

  2. Introduction • TCP protocol performance. • Congestion window, congestion avoidance(CA) & detection(CD). • TCP Vegas vs. Reno • Increase in overall throughput & decrease losses with efficient use of bandwidth. • Techniques for accurate RTT, new implementation for retransmission, window size modification, CD/CA, and spike suppression.

  3. Background & Motivation • Increase throughput and reduce losses using efficient available bandwidth. • In existing Reno RTT estimate is not accurate, biased against connections with longer delays • TCP Vegas emphasizes on packet delay rather than packet loss. • Better window size modification during retransmission.

  4. Problem Statement • In Reno, RTT estimates are not very accurate thereby affecting TCP performance. • Inefficient retransmissions. • Relative inefficient detection of losses. • Constantly updates window size • Can have many retransmissions of the same packet after that packet is dropped. • Leads to oscillation in window size, RTT resulting in inefficient bandwidth utilization.

  5. RTT Calculation • Vegas reads and records system clock each time a segment is sent. • When ACK arrives, reads clock again and calculates RTT using this time. • Using accurate RTT serves 2 purposes • More accurate timeout calculation • Helps in deciding to retransmit a dropped segment in a more timely order.

  6. New Retransmission Concept • Vegas retransmits without waiting for 3 duplicate ACKS (dup ACK). • When dup ACK is received Vegas compares the diff. bet. current time and time recorded to timeout value • If diff.> timeout, retransmits segment without waiting for 3 dup ACKs • Typically sender will never receive 3 dup ACKs, hence Reno retransmission technique is unreliable. • Vegas detects lost segments prior to retransmission without waiting for a dup ACK.

  7. Modifying Congestion Window Size • Congestion Window (CW) should be reduced only due to losses in current sending rate, not in previous higher sending rates. • In Reno, CW can be decreased more than once for losses in one RTT interval. • Vegas decreases CW if retransmitted segment was previously sent after last decrease. • Vegas is more reliable than Reno at detecting losses.

  8. Spike Suppression • TCP Reno self-clocking feature is dependent on the receipt of evenly-spaced ACK’s. • Because of the failure of this approach, the result in TCP Reno are spikes in the sending rate. • TCP Vegas suppresses these spikes by only allowing twice the ideal no. of bytes with the total number of bytes transmitted per RTT still bounded by the congestion window. • This spike suppression mechanism is only operational after slow start, as spikes are needed to keep up with the exponentially increasing transmission rate.

  9. Collision Detection (CD) • Vegas compares measured throughput rate with actual throughput. • No. of bytes in transit is directly proportional to expected throughput. • Vegas makes use of this idea to control the amount of extra data in the network. • If too much extra data, lead to retransmission • If too little extra data, connection cannot respond rapidly to temporary increases in bandwidth.

  10. Algorithm for CD • Base RTT = RTT of first segment • Expected throughput, • expected = Window Size/ Base RTT • Actual throughput, • Record sending time for a segment • Record no. of bytes transmitted between sending/receiving ACK • RTT calculated when ACK arrives • actual = no. of bytes / RTT • One calculation/ RTT

  11. Algorithm for CD contd. • Compare actual to expected • Diff = expected – actual • Diff is +ve or 0, if actual> expected change Base RTT to latest sampled RTT. • Lower and Upper thresholds α & β are defined • Diff < α, Vegas increases CW during next RTT • Diff > β,Vegas decreases CW during next RTT • α<diff<β, CW unchanged

  12. Congestion Avoidance (CA) • In terms of Collision Avoidance, TCP Vegas is proactive whereas TCP Reno is reactive. • TCP Vegas uses proactive collision avoidance by monitoring the increase in RTT delay, recalculating and checking the difference between the current RTT and average RTT for every two round-trip delays. • If this difference is greater, it then decreases the congestion window by 1/8, reducing the chances of packet loss by congestion before congestion actually occurs and packets are lost.

  13. Performance Evaluation • One-on-one: study how two TCP connections interfere with each other. • Start 1MB transfer, variable delay of 0s – 2.5s, start 300KB transfer • All four combinations: Reno/Reno, Reno/Vegas, Vegas/Reno, Vegas/Vegas were considered • Results were obtained and averaged for 12 runs, using 15 and 20 buffers in routers

  14. Results for One-on-One experiment • Vegas does not affect Reno’s throughput. • Reno’s throughput stays unchanged when competing with Vegas rather than itself. • Reno-Vegas retransmission drops significantly as compared to Reno/Reno • Vegas/Vegas retransmission is less than 1KB indicating CA mechanism works.

  15. Experiment with Background traffic • Network loaded with traffic • Protocol TRAFFIC running from Host1a to Host1b • 1MByte transfer running between Host2a and Host2b • Vegas-1,3 uses α=1, β=3 • Vegas-2,4 uses α=2, β=4 • 57 Runs using different tcplib and 10, 15, 20 buffers in the routers

  16. Results with Background Traffic • Vegas-1,3 had 53% better throughput than Reno • Only 49% losses • Little difference between Vegas-1,3 and Vegas-2,4

  17. Other Experiments • One on one with background traffic • Similar to the one on one experiment. Losses increased by 6% compared to 43%. • Two way background traffic • Performance: TCP Vegas> TCP Reno. Throughput ratio stayed the same, but lost ratio was better. • Different TCP buffer sizes • Buffer sizes varied between 50-5kb. • Vegas’ throughput proved to be more consistent over that of Reno.

  18. Internet Test Results • Results of 1MB transfers: Table 4 shows a 37-42 % increase in throughput and a 51-61 % retransmission compared to Reno. • Effect of transfer size of Vegas vs. Reno(table 5): Overall increase of Vegas over Reno is 37-71 %. • Retransmissions Vegas vs. Reno(table 5): 20 Kbytes retransmitted by Reno due to slow start. However, Vegas retransmission decreased linearly w.r.t transfer size.

  19. Related Work • Enhanced Gateway Congestion Control. • Enhanced Loss Recovery Algorithms (e.g. TCP New Reno). • The updated algorithms used for CD/CA based on RTT, which was similar to Tri-S. • Additional techniques: • Jain’s CARD: based on optimum window size. • Wang & Crowcroft’s Tri-S scheme. • Keshav’s packet-pair: estimating available bandwidth from delay between ACKs.

  20. Critique • Overall, the mechanisms that TCP Vegas implements is a great improvement to the TCP protocol. • The modified slow-start with CD, still possibility of lost segments. • CD depends on an accurate value for Base RTT. • Alternate approaches for linear increase/decrease mechanism of Vegas (CW) could be explored. • Values for α and β are just defined, no information on how to obtain or modify them depending on situation.

  21. Summary & Conclusions • The main goal of this experiment was to add on to the performance of Reno. Simulations and data gathered via experiments serves as the foundation for an updated version of Reno, called Vegas. • Based on experimental data, Vegas proved to be more efficient than Reno w.r.t throughput and retransmissions. • Vegas increased the throughput between 40-70% compared to Reno. • Losses reduced to 1/2 -1/5 of that of Reno.

  22. Questions…?

More Related