1

TCP-Vegas
1
Presented By:
Md. Mahbub Alam (0411052052)
Zahid Hasan (0411052053)
Shamsuddin (0411052075)
Supervised By:
Dr. Md. Humayun Kabir
Associate Professor
Department of CSE
BUET, Dhaka
2 2
Outline:
What is TCP-Vegas
Algorithm of TCP-Vegas
Comparison of TCP-Vegas with TCP-Reno
New Retransmission Mechanism
Congestion Avoidance Mechanism
Modified Slow-Start Mechanism
Problems with TCP-Vegas
Re-routing
Persistent Congestion
Conclusion

3
TCP-Vegas:
TCP-Vegas developed over TCP-Reno and Claimed that TCP-
Vegas achieves 37 to 71 percent higher throughput than TCP-
Reno.
Several changes made to TCP-Vegas over TCP-Reno
Retransmission Mechanism
Congestion Avoidance Mechanism
Slow-start mechanism
Vegas uses the difference between the expected and actual flow
rates to estimate the available bandwidth in the network.
Idea is that when the network is not congested, actual flow rate
is close to the expected flow rate. Otherwise, actual flow rate
will be smaller than expected flow rate.
TCP-Vegas uses this difference to estimate the congestion level
in the network & update the window size accordingly.
4
TCP-Vegas: Algorithm
For every RTT, Vegas calculates
1) Expected Throughput:




2) Actual Throughput: Measured throughput (< Expected throughput)




3) Calculate Difference

Window Congestion Current WindowSize
packet a of RTT Actual RTT Where
RTT
WindowSize
Actual
=
=
=
,
Window Congestion Current WindowSize
RTTs all of Minimum BaseRTT Where
BaseRTT
WindowSize
Expected
=
=
=
,
( )BaseRTT Actual Expected Diff =
5
TCP-Vegas: Algorithm(Contd.)
Based on Diff, source updates its window size as follows:




Threshold values, and , can be specified in terms of number of
packets rather than flow rate.

>
< +
=
otherwise CWND
Dif f if CWND
Dif f if CWND
CWND |
o
1
1
CWND
BaseRTT
RTT

Expected
Actual
Diff
= 60 packets
= 20 ms
= 30 ms

= 3000 packets/s
= 2000 packets/s
= 20 packets
| o s s 0 , Where
6
If Actual throughput is much smaller than the expected
throughput, then it is likely that network is congested and
source should reduce the flow rate.
On the other hand, If Actual throughput is too close to the
expected throughput, then connection may not be utilizing
the available bandwidth and hence should increase the flow
rate.
When ACK is received, Vegas calculates the RTT and decide
to retransmit in the following situations:
When it receives dupACK, Vegas checks if RTT > timeout, then
without waiting for 3 dupACK, it immediately retransmits the packet.
When non-dupACK is received, if it is 1
st
or 2
nd
ACK after a
retransmission, Vegas again checks to see if the RTT > timeout. If it
is, then Vegas retransmits the packet.

TCP-Vegas: (Contd.)
7
TCP-Vegas: (Contd.)
window
SS
time
CA
8
TCP-Reno
Basic ideas
Fast recovery avoids slow start
dupACKs: fast retransmit + fast recovery
Timeout: fast retransmit + slow start
slow start
retransmit
congestion
avoidance
FR/FR
dupACKs
timeout
9
cwnd
Slow Start Congestion
Avoidance
Time
inflating cwnd with dupACKs
deflating cwnd with a new ACK
(initial)
ssthresh
new ACK
fast-retransmit
fast-retransmit
new ACK
timeout
TCP-Reno (Contd.)
After receiving 3 dupACKS:
Retransmit the lost segment.
Set ssthresh = cwnd /2.
Set cwnd = ssthresh,
and ndupacks = 3
If dupACK arrives:
++ ndupacks
Transmit new segment, if allowed.
If new ACK arrives:
ndupacks = 0
Exit fast recovery.
If RTO expires:
ndupacks = 0
slow-start(ssthresh = cwnd/2,
cwnd = 1 )
10
TCP-Vegas Techniques
Fast retransmission
Congestion avoidance
Slow-start
11
New Retransmission Mechanism
Reno: when receiving n (usually 3) duplicate ACKs.
Vegas:
when receiving duplicate ACK, checks if timeout expired
and if so, retransmits immediately.
when receiving a non-duplicate ACK (1
st
or 2
nd
after
retransmission) , checks if timeout expired and if so,
retransmits.
RTT Measurement
Reno: coarse-grained timer.
Vegas: fine-grained clock values.
More accurate calculations of timeout,
resulting faster detection of lost segments
12
Retransmission example
Rcvd ACK for Packet 10 (11 and 12 are in transit).
Send packet 13 (which is lost).
Rcvd ACK for Packet 11. Send packet 14.
Rcvd ACK for Packet 12. Send packet 15 (which is lost)
Should have gotten ACK for packet 13
Rcvd dup ACK for packet 13 (due to packet 14).
Vegas checks timeout for packet 13 and retransmits it.
(Reno would need to wait for the 3
rd
dup ACK)
Rcvd ACK for packet 13 and packet 14.
Vegas checks timeout for packet 15 and retransmits it.
(Reno would need to wait for the 3
rd
dup ACK)
One RTT
One RTT
13
Reno: possible to decrease the congestion window
more than once during one RTT.
Vegas: in case of multiple segment loss and more than
one fast retransmission the congestion window is
reduced only for the first fast retransmission.


New Retransmission Mechanism (contd.)
14
Congestion detection
Reno: reactive uses the loss of segments as a signal that
there is congestion in the network.
Vegas: proactive tries to detect incipient congestion by
comparing the measured throughput to its notion of
expected throughput.

Algorithm: We already see that
Congestion avoidance Mechanism
15
Congestion window increase
Reno: doubles congestion window size every RTT.
Vegas: doubles congestion window size every other
RTT (valid comparison of the expected and the actual
rates).
Modified Slow-Start
Detect and avoid congestion
during slow-start
16
TCP-Vegas Problem
Problem 1: Re-routing
What if the route used by a Vegas connection
changes?
If new route is shorter, no issues
BaseRTT gets updated and Vegas continues to operate normally
If new route is longer, BaseRTT has really increased.
We have a problem
17
Imagine connection as being a data pipe.
Vegas window size is the volume of pipe + extra data.
Suppose a longer route is selected for the connection.
Correct Behavior: Window size should increase to keep
pipe full.
Vegas Behavior: Misinterprets throughput decrease (RTT
increase) to represent congestion
Problem 1: Re-routing (Contd.)
18
Solution to Re-routing Problem
Solution Idea: If minimum RTT for N consecutive pkts
is consistently higher than BaseRTT,
Update BaseRTT
Increase window size proportionately
19
Problem 2: Persistent Congestion
1) Network is already congested when Vegas connection
starts.
2) Vegas incorrectly estimates BaseRTT
3) Vegas overestimates window size
4) New connections increase congestion. Correct strategy
would be to back off.
What if the network is already congested when a
Vegas connection starts?
20
Solutions to Persistent Congestion
problem
Use of Random Early Detection (RED) in routers to limit
queue build-up
The solution proposed for the re-routing problem
Increases the congestion even further and may cause all
connections to back-off
A coarse timeout will cause a connection to enter Slow
Start, reducing its impact on the congestion
21 21
Thank you