TCP Vegas: Performance Considerations

1
TCP Vegas Performance Considerations

• Dhaval Doshi

2
Introduction

• TCP and Window based Flow Control
• Self clocking
• Variable window size determines the source rate
• Dynamic Adaptability the solution.

3
TCP Reno

• Implementation Mechanisms
• Slow start
• Congestion Avoidance
• Fast transmit / Fast Recovery

4
TCP Vegas

• Introduced in 1994 as an alternative to TCP Reno
• Improves upon the 3 mechanisms of TCP Reno
• Uses queuing delay unlike the loss probability
  used by Reno

5
TCP Vegas (contd.)

• Adopts a bandwidth estimation scheme that tries
  to avoid congestion
• Improved retransmission with timely detection of
  loss
• Detect congestion and reduce throughput to
  prevent losses

6
Slow-start mechanism

• To be able to detect and avoid congestion during
  slow-start phase, Vegas allows exponential growth
  only every other RTT
• Changes to linear increase/decrease mode when the
  actual rate falls below the expected rate by the
  equivalent of one router buffer
• Successful in preventing losses during the
  initial slow-start phase

7
Congestion Avoidance mechanism

• To correct the oscillatory behavior of Reno
• Difference in flow rates
• (Expected Actual) Base RTT
• Base RTT minimum observed RTT
• Adjusting the size of the Congestion Window
• cwnd 1 if Diff lt a
• cwnd cwnd 1 if Diff gt ß
• cwnd otherwise (a Diff ß)
• a 1, ß 3 by default

8
Congestion Recovery and Retransmission

• Retransmits almost 5 times fewer segments than
  Reno
• A window size of 2 packets is used at
  initialization and after a time-out
• Records the time each packet is sent. On receipt
  of duplicate ACK, sender retransmits oldest
  unacknowledged packet if it was sent long ago
  than a specified fine grain timer value.
• Fine grain timer detects losses earlier unlike
  triple-duplicate ACK

9
Congestion Recovery and Retransmission (contd.)

• Congestion window size reduced only if the time
  since the last window size reduction is more than
  the current RTT
• Reduces window size by about 25

10
Compatibility with TCP Reno

• Vegas does not receive a fair share of bandwidth
  when it competes with TCP Reno due to its
  conservative congestion-avoidance mechanism
• Culprits default values of a 1, ß 3
• These values need to be determined by trade-off
  mechanism.
• If a ß, congestion window oscillates
• If diff(a,ß) is too large, a greater stability
  region is created affecting the fairness

11
Performance Comparison
12
Performance Comparison
13
Performance metrics

• Throughput
• TCP Vegas achieves 37 to 71 better throughput
  on the Internet
• Achieved not by stealing bandwidth but by
  efficient usage of available bandwidth
• Fairness
• If k of the n users receive equal throughput and
  remaining n - k users receive zero throughput,
  fairness index is k / n.
• Vegas is no less fair than Reno

14
Performance metrics (contd.)

• Stability
• Vegas is better at recognizing and avoiding
  congestion unlike Reno which rather creates
  congestion
• If the load increases such that each connection
  can only send less than one maximum segment worth
  of data, Vegas behaves like Reno

15
Performance metrics (contd.)

• Queue Behavior
• Persistent queues can be formed at the bottleneck
  router as Vegas tries to occupy between one and
  three extra buffers along the path for each
  connection
• Internet latency could be adversely affected
• Overheads
• Managing Queue used for early segment loss
  detection and running congestion avoidance code

16
What the future holds?

• Guaranteed bandwidth to real-time connections
• Non-real time data transfer over the Internet
  scores over real-time and hence these
  applications can use Vegas to compete against
  each other for Bandwidth
• It would be unreasonable for a real-time
  application to request minimally acceptable
  bandwidth guarantee and then use Vegas to acquire
  additional bandwidth as the current load allows
• Usage of selective ACKs to decrease unnecessarily
  retransmitted packets
• Newer models in Research

17
Conclusion

• Does not necessarily perform lower than Reno
• Allows backward compatibility with TCP but not
  desirable with DropTail and RED
• Does not adapt to route changes. Slows down when
  it is supposed to speed up
• Lot of experimentation and tweaking required
• Yet to be implemented fully on the Internet

18
References

• Steven H. Low, Larry L. Peterson, Limin Wang,
  Understanding Vegas a duality model
• Charalampos Samios, Mary K. Vernon, Modeling the
  Throughput of TCP Vegas
• Lawrence S. Brakmo, Larry L. Peterson, TCP Vegas
  End to End Congestion Avoidance on a Global
  Internet
• W. Feng, S. Vanichpun, Enabling Compatibility
  Between TCP Reno and TCP Vegas
• http//www.cs.utk.edu/jahangee/vegas.html