In this section, we first review the congestion control mechanisms of TCP Vegas in detail, the in-depth discussion of Vegas can be found in [25].
TCP Vegas [25] uses the difference in the expected and actual flow rates to
esti-mate the available bandwidth in the network. When the network is not congested, the actual flow rate would be close to the expected flow rate. On the other hand, if the actual rate is much smaller than the expected rate, it indicates that buffer in the network is being filled up and the network is approaching congestion. This dif-ference in flow rates can be calculated as Diff = Expected – Actual, where Expected and Actual are the expected and actual rates, respectively.
(i) Congestion Avoidance
In its congestion-avoidance phase, Vegas uses two threshold values, α and β (whose default values are 1 and 3, respectively), to control the adjustment of the congestion window size at the source host. Let d denote the minimum-observed packet round-trip time (also known as BaseRTT), D denote the actual RTT, and W denote the size of the congestion window size, then Expected = W/d and Ac-tual = W/D. In addition, W is measured in segments as is normally done in any TCP version. The estimated backlog of packets in the network queues can then be computed as
Δ = (Expected – Actual)× BaseRT T = W × (D − d)
D . (2.1)
For every RTT, the congestion-avoidance algorithm adjusts W as follows:
W ←
Conceptually, Vegas tries to keep at least α packets but no more than β packets queued in the network. Thus, when there is only one Vegas connection, W con-verges to a point that lies between window + α and window + β where window is the maximum window size without considering the queuing in the network.
(ii) Slow Start
Like Reno, Vegas uses a slow-start mechanism that allows a connection to quickly ramp up to the available bandwidth. However, unlike Reno, to ensure that the send-ing rate will not increase too fast to congest the network dursend-ing the slow start, Vegas
doubles its congestion window size only every other RTT, and calculates the differ-ence between the flow rates (Diff ) and Δ given in eqn. (2.1) in every other RTT.
When Δ > γ (whose default is 1), Vegas leaves the slow-start phase, decreases its congestion window size by 1/8 and enters the congestion-avoidance phase.
(iii) Fast Retransmit and Fast Recovery
In TCP Vegas, as in TCP Reno, a triple-duplicate ACK always results in packet retransmission. However, in order to retransmit the lost packets quickly, Vegas ex-tends Reno’s fast retransmission strategy. Vegas measures the RTT for every packet sent based on fine-grained clock values. Using these fine-grained RTT measurements, a timeout period for each packet is computed. When a duplicate ACK is received, Vegas checks whether the timeout period of the oldest unacknowledgement packet has expired. If so, the packet is retransmitted. This modification leads to packet retransmission after just one or two duplicate ACKs. When a non-duplicate ACK that is either the first or second ACK after a fast retransmission is received, Vegas again checks for the expiration of the timer and may retransmit another packet.
Note that packet retransmission due to an expired fine-grained timer is conditioned on receiving certain ACKs. This technique enables the faster detection of losses and recovery from multiple drops without restarting the slow start phase if the retrans-mission timer has not been expired. Hence, it allows dealing with the problem that Reno suffers from considerably, namely, multiple drops in the same data window.
After a packet retransmission is triggered by a dupack and the ACK of the lost packet is received, the congestion window size is reduced to alleviate the network congestion. There are two cases for Vegas to set the congestion window size. If the lost packet has been transmitted just once, the congestion window size will be three fourth of the previous size. Otherwise, Vegas considers the congestion as more serious, and one-half of the previous congestion window size is set as the current congestion window. Notably, in the case of multiple packet losses occurring during one RTT and triggering more than one fast retransmission, the congestion window is reduced only for the first retransmission.
duplicate ACK
IncrAmt = 0 Delta < alpha
IncrAmt = 0
CWND = NewCWND + NumDupACK CWNDCT = current time
Yes
Figure 2.2: Flowchart of the procedure for TCP Vegas upon receiving an ACK.
Table 2.1: Description of variables in Fig. 2.2.
Variable Description
ACKSeqNo sequence number of the last successfully received packet NumDupACK number of duplicate ACK
RTO duration of the coarse-grained retransmission timer FGRTO duration of the fine-grained retransmission timer
CWNDCT last congestion window adjustment time due to a packet loss detection SendTime sending time of the lost packet
Delta amount of extra data
LostSeqNo squence number of the lost packet
NumTransmit number of transmission times of the lost packet
NewCWND congestion window size that will be used as a lost packet is recovered IncrFlag a flag used to adjust congestion window every otherRTT
IncrAmt increment amount of congestion window size for each new ACK is received WorriedCtr a counter used to check FGRTO after a lost packet is recovered
CA FF
Figure 2.3: Phase transition diagram of TCP Vegas.
If a loss episode is severe enough that no ACKs are received to trigger the fast retransmit algorithm, the losses will be eventually identified by a Reno-style coarse-grained timeout. When this occurs, the slow start threshold is set to one-half of the congestion window size; then, the congestion window is reset to two and finally, the connection restarts from slow start. Figures 2.2 and 2.3 illustrate the detailed procedure of TCP Vegas after it received an ACK and the phase transition diagram of TCP Vegas, respectively. The description of variables used in Fig. 2.2 is listed in Table 2.1.