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 % increase in throughput and a % retransmission compared to Reno.
Effect of transfer size of Vegas vs. Reno(table 5): Overall increase of Vegas over Reno is %.
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…?