Abstract
TCP Vegas is not used, because it can’t be deployed alongside TCP Reno or TCP Cubic
TCP Vegas: Reducing Latency
- Key insight: if sending faster than the network can deliver, packets will be queued
- TCP Reno and Cubic wait until the queue overflows and packets are lost before slowing down
- TCP Vegas watches for the increase in delay as the queue starts to fill up → slows down before the queue overflows
- Queues are smaller → lower latency
- Packets are not lost, so don’t need retransmission
- Only affects congestion avoidance; slow start unchanged
Congestion Control
Measure BaseRTT
- The smallest time between sending a packet and getting its acknowledgement
- BaseRTT will be from a packet delivered without much queueing Calculate ExpectedRate =
- The congestion window, W, determines how many packets are sent each RTT
- If the network can support this sending rate, the complete window should be delivered within the RTT Measure ActualRate
- Bytes sent divided by actual RTT, for each packet
- Measure how fast packets are actually received, based on acknowledgements returned
- ActualRate ≤ ExpectedRate since packets can’t be delivered faster than they’re sent
Compare ExpectedRate with ActualRate and adjust window: • If ExpectedRate - ActualRate < R1 then additive increase to window • Data arriving at close to expected rate, can likely send faster • If ExpectedRate - ActualRate > R2 then additive decrease to window • Data arriving slower than it’s being sent, slow down • Parameters R1 and R2, where R1 < R2, critical to performance
Limitations:
Delay-based congestion control is a good idea in principle • Reduces latency • Reduces packet loss But loss- and delay-based congestion control don’t cooperate • TCP Reno and TCP Cubic aggressively increase queue sizes • Increases RTT and reduces ActualRate as measured by TCP Vegas • Forces TCP Vegas to slow down; cycle repeats → TCP Vegas sending rate drops to zero over time