Enhancing TCP Fairness: TCP Vegas+ Implementation


Enhancing TCP Fairness: Implementing and Evaluating TCP Vegas+ in NS3
Introduction
Network simulators provide researchers and engineers with powerful tools to test protocol modifications without affecting real-world networks. NS3 (Network Simulator 3) stands out as one of the most comprehensive open-source network simulators, enabling detailed analysis of transport layer protocols like TCP. Our project focused on addressing a critical fairness issue between TCP variants that has long hindered the deployment of promising protocols.
The TCP Vegas vs Reno Fairness Problem
TCP is the backbone of our internet, handling reliable data transmission for most applications. However, not all TCP variants are created equal. The classic TCP Reno implements an aggressive congestion avoidance mechanism, rapidly increasing its congestion window until packet loss occurs. In contrast, TCP Vegas uses a more proactive approach, monitoring Round-Trip Time (RTT) variations to detect congestion before losses occur.
While Vegas offers several advantages—reduced packet loss, lower queuing delay, and greater stability—it suffers from a significant drawback when competing with Reno flows. When both variants share the same bottleneck link, Vegas’ conservative approach causes it to receive significantly less bandwidth than Reno.
Our measurements showed:
- Vegas flows achieve only 22-35% of the throughput of Reno flows in mixed environments
- The Jain’s Fairness Index drops to 0.68 when Vegas competes with Reno (compared to 0.92+ for homogeneous connections)
- Buffer occupancy is dominated by Reno packets (78% vs 22%) despite equal flow counts
TCP Vegas+: A Dual-Mode Solution
We implemented TCP Vegas+, a modified version of TCP Vegas that dynamically adjusts its aggressiveness to compete fairly with Reno while preserving Vegas’ inherent stability advantages. The implementation introduces:
- Dual operational modes:
- Moderate Mode: Preserves original Vegas behavior, ideal for steady-state operation
- Aggressive Mode: Adopts Reno-like behavior when competing with aggressive flows
- Intelligent mode switching based on network conditions:
- Monitors RTT trends to detect competing aggressive flows
- Switches to moderate mode upon congestion detection
- Adaptive threshold mechanism:
- Uses a configurable countmax parameter (default: 5) to control sensitivity
- Prevents oscillation through hysteresis logic
Implementation Details
The modification required surgical changes to NS3’s TCP module:
// Core logic in tcp-vegas.cc (simplified)
if (m_cntRtt > m_countMax && baseRtt > m_minRtt && !m_aggressive) {
// Switch to aggressive mode when RTT consistently increases
m_aggressive = true;
NS_LOG_INFO ("Vegas: Switching to aggressive mode");
} else if (m_inFastRec && m_aggressive) {
// Return to moderate mode after packet loss
m_aggressive = false;
m_cntRtt = 0;
NS_LOG_INFO ("Vegas: Switching to moderate mode");
}
We modified four key files:
tcp-vegas.cc
- Core algorithm modifications (194 lines changed)tcp-socket-base.cc
- Socket handling additions (83 lines changed)tcp-socket-base.h
- Interface declarations (35 lines changed)tcp-socket-state.h
- State tracking enhancements (42 lines changed)
Experimental Setup
We conducted extensive simulations using diverse network topologies:
- Dumbbell topology with multiple sending and receiving nodes
- Point-to-point links with 20Mbps bandwidth and 5ms delay
- Bottleneck link with varying buffer sizes (50-500 packets)
- Mixed flow configurations with 2-20 concurrent connections
Parameters varied:
- Number of TCP flows (2, 5, 10, 15, 20)
- Flow type ratios (Reno:Vegas+)
- Bottleneck buffer sizes
- Simulation duration (30-300 seconds)
All simulations were repeated 10 times with different random seeds to ensure statistical validity.
Results and Performance Metrics
1. Fairness Improvement
The Jain’s Fairness Index (JFI) improved significantly:
Scenario | Original Vegas vs Reno | Vegas+ vs Reno | Improvement |
---|---|---|---|
2 flows | 0.68 | 0.89 | 30.9% |
5 flows | 0.72 | 0.91 | 26.4% |
10 flows | 0.75 | 0.93 | 24.0% |
15 flows | 0.77 | 0.94 | 22.1% |
20 flows | 0.79 | 0.95 | 20.3% |
2. Throughput Analysis
Vegas+ achieved competitive throughput without sacrificing network efficiency:
Metric | TCP Reno | TCP Vegas | TCP Vegas+ |
---|---|---|---|
Average throughput (Mbps) | 16.8 | 13.2 | 16.3 |
Throughput stability (std dev) | 3.2 | 1.5 | 1.8 |
Bandwidth share when competing (%) | 78.4 | 21.6 | 48.7 |
3. Network Efficiency Metrics
Vegas+ maintained Vegas’ efficient use of network resources:
Metric | TCP Reno | TCP Vegas | TCP Vegas+ |
---|---|---|---|
Avg queue occupancy (packets) | 38.4 | 12.6 | 15.2 |
Packet retransmissions (%) | 4.8 | 1.2 | 1.9 |
End-to-end delay (ms) | 78.6 | 42.1 | 45.3 |
4. Impact of countmax Parameter
The countmax parameter provides a tunable tradeoff between fairness and efficiency:
countmax value | Fairness Index | Packet Loss (%) | Throughput (Mbps) |
---|---|---|---|
3 | 0.91 | 2.1 | 16.5 |
5 | 0.93 | 1.9 | 16.3 |
7 | 0.94 | 1.7 | 16.1 |
10 | 0.95 | 1.4 | 15.8 |
5. Performance Across Different Environments
Vegas+ demonstrated robust performance across different network conditions:
Network Type | Fairness Improvement | Bandwidth Utilization |
---|---|---|
Wired (P2P links) | 26.4% | 97.8% |
Wireless (802.11n) | 18.7% | 94.2% |
High delay (100ms) | 24.1% | 96.3% |
Variable bandwidth | 25.3% | 95.9% |
Conclusions and Implications
Our implementation of TCP Vegas+ successfully addresses the long-standing fairness issues that have limited the deployment of TCP Vegas, while preserving its core benefits. The key achievements include:
- Near-perfect fairness: Improved Jain’s Fairness Index from 0.68 to 0.93 (average)
- Competitive throughput: Achieved 97% of Reno’s throughput while maintaining Vegas’ stability
- Preserved efficiency: Maintained low queue occupancy (15.2 packets) and reduced packet loss (1.9%)
- Tunable behavior: Countmax parameter allows for network-specific optimization
Most importantly, Vegas+ demonstrates that it’s possible to maintain the proactive congestion control advantages of delay-based TCP variants while addressing their competitive disadvantages. This opens the door for wider deployment of these algorithms in real-world networks, potentially reducing global internet congestion.
Future work will focus on testing Vegas+ in larger topologies, implementing the algorithm in the Linux kernel, and exploring its performance in data center environments where small queuing delays are critical.
Acknowledgments
This research was conducted as part of the CSE-322 Computer Networks Sessional course at BUET. The authors would like to thank the course instructors for their guidance and the NS3 community for their comprehensive documentation and support.
The complete project code and documentation is available on GitHub.