Problem Statements

In TCP Vegas, several problems may adversely affect the connection performance.

We summarize these problems as follows.

Rerouting: Since TCP Vegas estimates the BaseRTT to compute the expected throughput and adjust its window size accordingly. Thus it is very important to estimate the quantity accurately for Vegas connections. Rerouting may cause a change of the fixed delay¹ that could result in substantial throughput degradation.

When the routing path of a connection is changed, if the new route has a shorter fixed delay, it will not cause any serious problem for Vegas because most likely some packets will experience shorter round-trip time, and BaseRTT will be updated eventually. On the other hand, if the new route for the connection has a longer fixed delay, it would be unable to tell whether the increased round-trip time is due to network congestion or route change. The source host may misinterpret the increased round-trip time as a signal of congestion in the network and decrease its window size. This is just the opposite of what the source should do.

Persistent Congestion: Persistent congestion is another problem caused by the incorrect estimation of BaseRTT [9]. Overestimation of the BaseRTT in Vegas may cause a substantial influence on the performance. Suppose that a connection starts while many other active connections also exist, the network is congested and the packets are accumulated in the bottleneck. Then, due to the queuing delay caused by those packets from other connections, the packets of the new connection may experience a round-trip time that are considerably larger than the actual fixed

1The fixed delay is the sum of propagation delay and packet processing time along the round-trip path. In other words, the fixed delay is the round-trip time without queuing delay.

delay along the path. Hence, the window size of the new connection will be set to a value such that its expected amount of extra data lies between α and β; in fact, there may be much more extra data in the bottleneck queue due to the inaccurate estimation of the fixed delay. The situation can be more explicit described as follows.

TCP Vegas uses the following inequality to detect and control the extra data in the network pipe.

α ≤ (Expected − Actual) × BaseRT T ≤ β, (3.1) We can rewrite Eq. (3.1) as:

α ≤ CW N D × (1 − BaseRT T

RT T ) ≤ β. (3.2)

An overestimated BaseRTT will shrink the estimated amount of extra data (i. e., CW N D × (1 − BaseRT T /RT T )) and cause the Vegas source to misjudge that the network is not so congested. As a result, the Vegas source sets its window size larger than it should be and therefore puts more extra data on the bottleneck queue.

This scenario will repeat for each newly added connection, and it may cause the bottleneck node to remain in a persistent congestion. Persistent congestion is likely to happen in TCP Vegas due to its fine-tuned congestion avoidance mechanism.

Unfairness: Different from TCP Reno, TCP Vegas is not biased against the connections with longer round-trip time [9, 10]. However, there is still unfairness comeing with the nature of Vegas. According to the difference between the expected and actual throughputs, a Vegas source attempts to maintain an amount of extra data between two thresholds α and β by adjusting its congestion window size. The range between α and β induces uncertainty to the achievable throughput of connec-tions. Since Vegas may keep different amount of extra data in the bottleneck even for the connections with the same round-trip path. Thus, it prohibits better fairness achievement among the competing connections.

Furthermore, the inaccurate computation of expected throughput may also lead to unfairness. Recall that the computation of expected throughput is based on

accurately, it may affect the fairness achievement. When a new connection starts sending data while many other connections are also active, it may cause overesti-mation of the fixed delay and result in unfair distribution of bandwidth among the Vegas connections.

Network Asymmetry: Based on the estimated extra data kept in the bottle-neck, Vegas updates its congestion window to avoid congestion as well as to maintain high throughput. However, a roughly measured RTT may lead to a coarse adjust-ment of congestion window size. If the network congestion occurs in the direction of ACK (backward path), it may underestimate the actual throughput and cause an unnecessary decreasing of the congestion window size. Ideally, congestion in the backward path should not affect the network throughput in the forward path, which is the data transfer direction. Obviously, the control mechanism must be able to distinguish whether congestion occurs in the forward path or not and adjust the congestion window size more intelligently.

Incompatibility: TCP Vegas adopts a proactive congestion avoidance scheme, it reduces its congestion window before an actual packet loss occurs. TCP Reno, on the other hand, employs a reactive congestion control mechanism. It keeps increas-ing its congestion window until a packet loss is detected. Researchers [9, 35, 36]

have found that when Reno and Vegas perform head-to-head, Reno generally steals bandwidth from Vegas. This incompatibility between Vegas and Reno depress the adoption of Vegas on the Internet.

3.2 RoVegas

From the above discussion, we can find that the coarse estimation of fixed delay along the round-trip path, BaseRTT, results in problems such as issues of rerouting, per-sistent congestion, and unfairness. A Vegas source is unable to distinguish whether congestion occurs in the forward path or not, this further leads to unnecessary throughput degradation when the congestion occurs on the backward path. In this section, we propose a router-assisted congestion avoidance mechanism (RoVegas)

for TCP Vegas to deal with these problems. The details of the proposed mechanism are described as follows.

3.2.1 Proposed Mechanism

TCP Vegas estimates a proper amount of extra data to be kept in the network pipe and controls the congestion window size accordingly. The amount is between two thresholds α and β, as shown in Eq. (3.1). When backward congestion occurs, the increased backward queuing time will affect the Actual throughput and enlarge the difference between the Expected throughput and Actual throughput. It results in decreasing the congestion window size. Since the network resources in the backward path should not affect the traffic in the forward path, it is unnecessary to reduce the congestion window size when only backward congestion occurs.

A measured RTT can be divided into four parts: forward fixed delay (i. e., propagation delay and packet processing time), forward queuing time, backward fixed delay, and backward queuing time. To utilize the network bandwidth efficiently, we redefine the Actual throughput as

Actual⁰ = CW N D RT T − QTb

, (3.3)

where RTT is the newly measured round-trip time, QTb is the backward queuing time, and CWND is the current congestion window size. Consequently, the Actual⁰ is a throughput that can be achieved if there is no backward queuing delay along the path.

To realize our scheme, we define a new IP option named AQT (accumulate queuing time) to collect the queuing time along the path. According to the general format of IP options described in [44], the fields of an AQT option are created as in Fig. 3.1. The option type and length fields indicate the type and length of this IP option. The AQT field expresses the accumulated queuing time that a packet experienced along the routing path. The AQT-Echo field echoes the accumulated queuing time value of an AQT option that was sent by the remote TCP.

1 Byte 1 Byte 3 Bytes

3 Bytes AQT

(Accumulated Queuing Time) Option Length

AQT-Echo Option Type

Figure 3.1: Fields of an AQT option.

A probing packet is a normal TCP packet (data or ACK) with AQT option in its IP header. When a RoVegas source sends out a probing packet, it sets the AQT field to zero. An AQT-enabled router (i. e., a router that is capable of AQT option processing) adds the queuing delay of a received probing packet to the AQT field. The queuing time is computed based on the queuing disciplines. The details regarding how to compute the queuing time of each received probing packet in various queuing disciplines is beyond the scope of our discussion.

Whenever a RoVegas destination acknowledges a probing packet, it inserts an AQT option into the ACK. The AQT-Echo field is set to the value of the AQT field of the received packet, then the AQT field is reset to zero. Through the AQT-enabled routers along the round-trip path, a RoVegas source is able to obtain both the forward queuing time (the value of AQT-Echo field) and backward queuing time (the value of AQT field) from the received probing packet. Moreover, for each probing packet received by a RoVegas source, the BaseRTT can be derived as follows:

BaseRT T = RT T − (AQT + AQT-Echo). (3.4) Notice that, the derived BaseRTT of a connection will be identical for each probing packet received when both the route and size of the probing packets are fixed. The derived BaseRTT of RoVegas represents the actual fixed delay along the round-trip path, if the path of a connection is rerouted and the fixed delay is changed, the newly derived BaseRTT may reflect the rerouting information. As a result, the issue of rerouting can be solved. Furthermore, since each connection of RoVegas is able to measure the fixed delay without bias, the problem of persistent

congestion can be avoided and the fairness among the competitive connections can also be improved.

To avoid the unnecessary reduction of congestion window size, the proposed router-assisted congestion avoidance mechanism is described as follows:

• Derive the Expected throughput that is defined as the current congestion win-dow size divided by BaseRTT.

• Calculate the Actual⁰ as the current congestion window size divided by the difference between the newly measured RTT and backward queuing time.

• Let Dif f = (Expected − Actual⁰) × BaseRT T .

• Let wcur and wnext be the congestion window sizes for the current RTT and the next RTT, respectively. The rule for congestion window adjustment is as follows:

RoVegas relies on probing packets to probe the network status, therefore, how often a probing packet will be sent for a connection is an important issue. Since the window adjustment of RoVegas is performed on per-RTT basis. Inserting probing packets frequently makes the proposed mechanism robust against the network congestion, however, it also imposes more overhead on RoVegas. For the overhead induced by the probing packets, we consider the worst case that every packet with the AQT option. If the data packet size is 1500 bytes, which is the maximum transmission unit of Ethernet, the overhead ratio of data packets is 8/1500, which is about 0.53

%. In the practical implementation, the number of the probing packets per-RTT can be dynamically adjusted depending on the network status. That is, the more severe the backward congestion is, the more frequent the AQT option should be

inserted into a data packet. Through this way, the overhead induced by the AQT option can be reduced to an even smaller amount.

We make every packet to be a probing packet and demonstrate that the proposed mechanism is effective to improve the performance of TCP Vegas by the results of both analysis and simulation shown in Sections 3.4 and 3.5.