1. TCP Vegas: New Techniques for Congestion Detection and Avoidance
Team 1: Cheng-Lin Tsao and Ruhull Alam Bhuiyan

2. Introduction TCP Reno TCP Vegas Congestion control
Coarse timeout/retransmission
Need of creating losses
TCP Vegas
Congestion avoidance
Accurate timeout, timely retransmission
Congestion detection
5 techniques
40-70% better throughput, 1/2-1/5 losses

3. Background and Motivation
Knee and cliff
Congestion avoidance
Operate around knee
Congestion control
Operate on the left of cliff
Motivation
Limit of congestion control
Coarse timeout/retransmission

4. Technique 1, 2 More accurate RTT calculation
Reno: coarse-grained timer (500 ms)
1100ms to timeout and retransmit
Vegas: read/record clock on sending segments/receiving ACKs
<300ms to timeout and retransmit
New retransmission mechanism
Reno: 3 duplicate ACKs
Vegas: check timeout when receiving
duplicate ACK
1st or 2nd non-duplicate ACK after retransmission

5. Technique 3, 4 Modified window sizing on congestion Spike suppression
Reduce cwnd only due to losses at the current sending rate
Reduce cwnd only if retransmitted segment was sent after last decrease
Spike suppression
Multiple segments transmitted back-to-back
Large cumulative ACKs or ACK compression
Space segments evenly to prevent buffer overflow

6. Technique 5 Congestion detection Modified slow start Concept Algorithm
Expected = WindowSize / BaseRTT
Modified slow start

7. Performance Evaluation Model
Simulator
University of Arizona’s x-kernel framework
Full protocol stack
Protocol is modeled by actual C code
Traffic generation with tcplib
Tracing facility
Network configuration

8. TCP Reno with no other traffic
Slow start
Congestion control
(dashed) slow-start threshold
(dark gray) flow control window
Detect loss, decrease cwnd
Decrease cwnd to half and set ssthresh
(thin) actual # bytes in transit
(light gray) congestion control window
Linearly increase cwnd
(solid vertical) time when a retransmitted segment originally sent
Exponentially increase cwnd in every RTT
Incur packet loss
Incur packet loss
sending rate
Overrun router buffer
Overrun router buffer
Use more and more buffer

9. TCP Vegas with no other traffic
Slow start
Congestion avoidance
Increase cwnd
Enter linear increase/decrease mode
Exponentially increase cwnd in every other RTT
Steady sending rate
Actual > α
(gray) Expected throughput
congestion decision
(dashed) thresholds of throughput
(solid) Actual throughput
Actual throughput < γ
β < Actual < α
α < queue < β
Reduce sending rate before buffer overrun
Queue < α

10. Results (1) How 2 TCP connections interfere with each other
4 possible combinations
Reno/Vegas: a 300KB transfer using Reno contained within a 1MB transfer using Vegas
Reno’s throughput unchanged when competing with Vegas
Vegas doesn’t adversely affect Reno’s throughput

11. Results (2) Performance of TCP with background traffic
Two versions of Vegas
Vegas-1,3: α = 1 and β = 3
Improvement of Vegas over Reno
More than 50% improvement on throughput
Half the losses

12. Results (3) Measurements of TCP over the Internet
Connection between UA and NIH
17 hops
37-42% more throughput, 51-61% retransmissions

13. Related Work Proactive congestion detection Wang and Crowcroft, DUAL
Based on understanding of network changes as it approaches congestion
Wang and Crowcroft, DUAL
compare RTT to (min + max)/2
Jain, CARD
compare RTT and congestion window size
Wan and Crowcroft, Tri-S
compare throughput to window 1 segment smaller
Keshav, Packet-pair rate probing
estimate available bandwidth with two segments
Vegas measures and controls throughput
amount of extra data a connection has in transit

14. Critique and Discussions (1)
Unfairness problem
α and β are thresholds of extra data a connection has in transit
Including data of other connections
Unfairness among connections with different hop counts
Ex. R1~R4 have extra data of 1 segment, H1~H4 measure 2 extra data, H5 measures 4 extra data. H5 always reduces its sending rate while others remain the same. H1 H2 H3 H4 H5 R1 R2 R3 R4 H6

15. Critique and Discussions (2)
Linear or exponential decrease
Available bandwidth for each connection may drop exponentially due to critical changes, such as node failure R2 R1 R4 R3

16. Critique and Discussions (3)
Influence from application layer
Multimedia: steady data rate
HTTP: slower slow start
More accurate measurement and control
Why Expected throughput > available bandwidth?
Invalid BaseRTT when route changes
Optimal values of α, β, and γ?
UDP with congestion avoidance
Vegas decouples reliability and congestion control
link

17. Summary and Conclusions
Vegas is TCP with congestion avoidance
It controls extra data the connection occupies in the network
It has more accurate RTT and timely retransmission mechanism
Experiments and simulation both show 40-70% better throughput and half retransmission, compared to Reno

18. Expected throughput over-estimated
Expected throughput 240KBps
Available bandwidth only 200KBps
back