TCP Vegas is a rate-based congestion control mechanism. It can detect network congestion in the early stage and successfully prevents periodic packet loss that usually occurs in TCP Reno. TCP Vegas features three improvements as compared with TCP Reno: (1) a new retransmission mechanism, (2) an improved congestion avoidance mechanism, and (3) a more effective slow-start mechanism. We summary the design principles of TCP Vegas as follows.
TCP Vegas adopts a more sophisticated bandwidth estimation scheme that tries to avoid rather than to react to congestion. It uses the measured round-trip time (RTT ) to accurately calculate the amount of data packets that a source can send. Its window adjustment algorithm consists of three phases: slow-start (SS), congestion avoidance (CA), and fast retransmit and fast recovery (FF). The congestion window is updated based on the currently executing phase.
During the congestion avoidance phase, TCP Vegas does not continually increase the congestion window. Instead, it tries to detect incipient congestion by comparing the actual throughput to the expected throughput. Vegas estimates a proper amount of extra data to be kept in the network pipe and controls the congestion window size accordingly. It records the RTT and sets BaseRTT to the minimum of ever measured round-trip times. The amount of extra data (∆) is estimated as follows:
∆ = (Expected − Actual) × BaseRT T, (2.1) where Expected throughput is the current congestion window size (CWND) divided by BaseRTT, and Actual throughput represents the CWND divided by the newly measured smoothed-RTT. The CWND is kept constant when the ∆ is between two thresholds α and β. If ∆ is greater than β, it is taken as a sign for incipient congestion, thus the CWND will be reduced. On the other hand, if the ∆ is smaller than α, the available bandwidth may be under utilized. Hence, the CWND will be increased. The updating of CWND is per-RTT basis. The rule for congestion window adjustment can be expressed as follows:
CWND =
During the slow-start phase, TCP Vegas is similar to TCP Reno that allows a connection to quickly ramp up to the available bandwidth. However, to ensure that the sending rate will not increase too fast, TCP Vegas doubles the size of its congestion window only every other RTT. A similar congestion detection mechanism
0 2 4 6 8 10 12 14 16 18
0 1 2 3 4 5
Time (s)
CWND (Packets)
Figure 2.3: TCP Vegas’ window evolution.
is applied during the slow-start to decide when to switch the phase. If the estimated amount of extra data is greater than γ, TCP Vegas leaves the slow-start phase, reduces its congestion window size by 1/8 and enters the congestion avoidance phase.
By keeping a proper amount of extra data in the network, TCP Vegas does not generate packet loss by itself. Ideally, it can maintain a stable window size as well as fully utilize the network resources if the network resources remain constant. An example of TCP Vegas’ window evolution in a stable network environment can be referred to Fig. 2.3.
As in TCP Reno, a triple-duplicate acknowledgement (ACK) always results in packet retransmission. However, in order to retransmit the lost packets quickly, TCP Vegas extends TCP Reno’s fast retransmission strategy. TCP Vegas measures the RTT for every packet sent based on grained clock values. Using the fine-grained RTT measurements, a timeout period for each packet is computed. When a duplicate ACK is received, TCP Vegas will check whether the timeout period of the oldest unacknowledgement packet is 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 the first or second ACK after a fast
CA FF
New ACK / Coarse-grained Timeout /
Idle
New ACK Duplicate ACK
Triple Duplicate ACK / Fine-grained Timeout
Coarse-grained Timeout / Idle
New ACK
Triple Duplicate ACK / Fine-grained Timeout Coarse-grained Timeout /
Idle CWND >= SSTHRESH /
Delta > gamma
SS
START
Figure 2.4: Phase transition diagram of TCP Vegas.
retransmission is received, TCP Vegas will again check 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 the reception of certain ACKs.
After a packet retransmission was triggered by a duplicate ACK and the ACK of the lost packet is received, the congestion window size will be reduced to alleviate the network congestion. There are two cases for TCP Vegas to set the CWND.
If the lost packet has been transmitted just once, the CWND will be three fourth of the previous congestion window size. Otherwise, it is taken as a sign for more serious congestion, and one half of the previous congestion window size will be set to CWND. Notably, in case of multiple packet losses occurred during one round-trip time that trigger more than one fast retransmission, the congestion window will be reduced only for the first retransmission.
If a loss episode is severe enough that no ACKs are received to trigger fast
Table 2.2: Variable description of Fig. 2.5.
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 other RTT
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
retransmit algorithm, eventually, the losses will be identified by Reno-style coarse-grained timeout. When this occurs, the slow-start threshold (SSTHRESH ) will be set to one half of current CWND, then the CWND will be reset to two, and finally the connection will restart from slow-start.
Figure 2.4 shows the phase transition diagram of TCP Vegas. A connection begins with the slow-start phase. The window-adjustment phase transition is owing to the specific events as depicted along the edges.
TCP congestion control is mainly based on the feedback of ACKs. The control procedure will be triggered whenever an ACK is received by the connection source.
Figure 2.5 illustrates the detailed procedure of TCP Vegas as it receives an ACK.
The description of variables used in Fig. 2.5 is shown in Table 2.2.
duplicate ACK
IncrAmt = 0 Delta < alpha
IncrAmt = 0 IncrAmt = 1/CWND
tag next Pkt SeqNo
CWND = CWND + IncrAmt update FGRTO
CWND = NewCWND + NumDupACK CWNDCT = current time
Yes
Figure 2.5: Flowchart of the procedure for TCP Vegas upon receiving an ACK.