Asymmetric Networks
4.1 Enhanced Vegas
To improve the performance in backward path congestion, there are two critical issues of TCP Vegas: (1) how to estimate the backward queueing delay from the measured round-trip time and (2) how to make use of the estimation to adjust the congestion window size. For the issue (2), we adopt the same policy as that in the previous chapter. The Actual throughput is redefined as
Actual0 = CW N D
RT T − QT (backward), (4.1)
where RTT is the newly measured RTT, QD(backward) is the backward queuing time, and CWND is the current congestion window size. The Actual0 is therefore a throughput that can be achieved if there is no backward queuing delay along the path.
To solve the issue (1), we make use of the TCP timestamps option to obtain the backward queuing time. When a connection source sends a packet, it inserts a timestamp into the TCP header. As the destination acknowledges this packet, it copies the forward timestamp and adds a backward timestamp to the ACK packet.
Assume there is a TCP source a and its destination b. Let tab and tba be the end-to-end trip time of the forward data packet and the backward ACK packet respectively.
We can acquire tab by subtracting the forward timestamp from backward timestamp
(i.e., system time of source a when it receives this ACK packet). Assume tdab is the difference of system clocks in source a and destination b, and tab(M in) (tba(M in)) denotes the minimum tab (tba) that the source a ever measured. The trip time of a packet between two hosts is consisted of the fixed delay time and the queuing delay time. Let tab(F D) (tba(F D)) denotes the fixed delay time from a (b) to b (a) and tab(QD) (tba(QD)) represents the forward (backward) queuing time from a (b) to b (a). We have the following equations:
queuing delay tab(QD) (tba(QD)) approaches zero, therefore we obtain
tab(M in), and tba(M in) all can be measured by source a. Thus the forward queuing time tab(QD) and the backward queuing time tba(QD) can be derived from Eq. (4.2) and Eq. (4.3) as follows:
tab(QD) = tab−tab(M in)
tba(QD) = tab−tba(M in) . (4.4) The tba(QD) is just the QD(backward) that we need in Eq. (4.1). Furthermore, the BaseRTT can be more precisely estimated by the sum of tab(F D) and tba(F D) (i.e., the sum of tab(M in) and tba(M in)). To Avoid the unnecessary reduction of TCP congestion window size, the rule for congestion window adjustment of En-hanced Vegas is same as Eq. (3.5).
The proposed mechanism estimates BaseRTT and queuing time on both di-rections based on tracking the minimum end-to-end trip time (i.e., tab(M in) and tba(M in)). However, if the clock speed is different between the source and the destination, the accumulated time differences caused by clock skews may result in
Vegas / Enhanced Vegas
Figure 4.1: Network configuration for the simulations.
incorrect measurement of minimum end-to-end trip time. Certain efficient algo-rithms have been proposed to estimate clock skews from network delay measure-ments [48, 49]. Let Ca and Cb be the clock speed of source a and destination b respectively. The clock ratio is denoted by ρ, ρ = Cb/Ca . Then we have the following equations to adjust the minimum end-to-end trip time:
We perform the simulations using ns-2 [46] to compare the throughputs between Vegas and our proposed Enhanced Vegas. A VBR source is used to generate the backward traffic. This VBR source is an exponentially distributed ON-OFF source.
During ON periods, the VBR source sends data at 2 Mb/s. Several VBR sources with different average sending rates are used to examine our mechanism. All param-eters of both Vegas and Enhanced Vegas are the same. Without loss of generality, the packet size is set at 1 Kbytes. To ease the comparison, we assume that the sources always have data to send. The network configuration we used is shown in
0 200 400 600 800 1000 1200
0 25 50 75 100 125 150 175 200
Time (s)
Throughput (Kb/s)
Vegas
Enhanced Vegas
Figure 4.2: Throughput comparison between Vegas and Enhanced Vegas with the backward traffic load 0.9.
In the first simulation, we use a VBR source with 900 Kb/s average sending rate to examine the throughput of Vegas and Enhanced Vegas separately. A source from either Vegas or Enhanced Vegas starts sending data at 0 second, while VBR source starts at 50 second. By observing the result in Fig. 4.2, when traffic source is Vegas only, it can achieve high throughput and stabilize at 1,000 Kb/s until the VBR source starts sending data. However, it shows that performance of Vegas drops dramatically as the VBR traffic starts. On the contrary, Enhanced Vegas maintains a much higher throughput than Vegas. During the active period of VBR source, the average throughput of Vegas is 325 Kb/s and Enhanced Vegas is 767 Kb/s. Since the traffic pattern of the VBR source keeps the same when the throughput of Vegas or Enhanced Vegas is examined. Thus there are some synchronized fluctuations of throughput for Vegas and Enhanced Vegas. The simulation results demonstrate that the proposed scheme significantly improves the throughput of Vegas when the backward path is congested.
In the second simulation, we evaluate the average throughput of Vegas and En-hanced Vegas with different backward traffic loads separately. Sources of either
0 200 400 600 800 1000 1200
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Traffic Load of VBR Source
Average Throughput (Kb/s)
Vegas
Enhanced Vegas
Figure 4.3: Average throughput versus backward traffic load for Vegas and Enhanced Vegas.
Vegas or Enhanced Vegas and VBR start at 0 second. The VBR traffic loads vary from 0 to 1. The simulation period is 200 seconds for each sample point. From the simulation results shown in Fig. 4.3, we can find that the Enhanced Vegas obtains a much higher average throughput than TCP Vegas, especially when the backward traffic load is heavy. For example, when the backward traffic load is 1, Enhanced Vegas achieves a 12 times higher average throughput than that of Vegas.
4.3 Chapter Summary
In this chapter, we propose an end-to-end approach of TCP Vegas for asymmetric networks. Comparing with other studies [29, 30, 47, 26], Enhanced Vegas provides a much easier way to improve the connection throughput when the backward path is congested. The simulation results show the effectiveness of our proposed mechanism.
Nevertheless, clock skew issue is still a problem of Enhanced Vegas, such as the convergence speed of the clock ratio measurement. In the future research, we will