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 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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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

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.

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

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

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.

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.

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.

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.

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.

Questions…?