CODE TCP: A competitive delay-based TCP

(1)

CODE TCP: A competitive delay-based TCP

Yi-Cheng Chan

a,*

, Chia-Liang Lin

a

, Chia-Tai Chan

b

, Cheng-Yuan Ho

c a

Department of Computer Science and Information Engineering, National Changhua University of Education, No. 2, Shi-Da Road, Changhua City 500, Taiwan b

Institute of Biomedical Engineering, National Yang-Ming University, No. 155, Sec. 2, Linong Street, Taipei City 112, Taiwan c

Department of Computer Science, National Chiao Tung University, No. 1001 Ta Hsueh Road, Hsinchu City 300, Taiwan

a r t i c l e

i n f o

Article history:

Received 19 September 2008

Received in revised form 9 January 2010 Accepted 11 January 2010

Available online 18 January 2010 Keywords:

Congestion control TCP Reno TCP Vegas Fairness

Transport layer protocol

a b s t r a c t

TCP Vegas is a well-known delay-based congestion control mechanism. Studies have indicated that TCP Vegas outperforms TCP Reno in many aspects. However, Reno currently remains the most widely deployed TCP variant in the Internet. This is mainly because of the incompatibility of Vegas with Reno. The performance of Vegas is generally mediocre in environments where it coexists with Reno. Hence, there exists no incentive for operating systems to adopt Vegas as the default transport layer protocol. In this study, we propose a new variant of Vegas called COmpetitive DElay-based TCP (CODE TCP). This variant is compatible with Reno and it can obtain a fair share of network resources. CODE is a sender-sided modiﬁcation and hence it can be implemented solely at the end host. Simulations and experiments conﬁrm that CODE has better fairness characteristics in network environments in which it coexists with Reno while retaining the good features of Vegas.

1. Introduction

Transmission Control Protocol (TCP) is a connection-oriented, end-to-end, and reliable protocol. Nowadays, a majority of Internet trafﬁc is carried by TCP. Therefore, the behavior of TCP is tightly cou-pled with the overall Internet performance. To improve network efﬁ-ciency, many TCP variants have been proposed. Two of these variants are noteworthy. One is Reno[1], which has been widely deployed in the Internet; the other is Vegas[2], which claims to have a through-put that is 37–71% greater than that of Reno.

TCP Vegas is a delay-based congestion control mechanism. Un-like TCP Reno which uses a binary congestion signal, packet loss, to adjust its window size, Vegas adopts a more ﬁne-grained signal, queuing delay, to avoid congestion. Vegas can detect network con-gestion in the early stage and successfully prevent periodic packet loss that usually occurs in Reno. Delay-based congestion control schemes have attracted considerable attention because of their innovative control policy[3–10].

As compared to Reno, Vegas generally performs better with re-spect to overall network utilization[2], stability[11,12], fairness [11,12], throughput, packet loss[2], and burstiness[13]in homoge-neous environments. Vegas also outperforms TCP Newreno[14]. However, studies have shown that when Reno and Vegas connec-tions coexist in the same network, Reno obtains a greater amount

of bandwidth as compared to Vegas [12,15,16]. Consequently, although Vegas has been available for a few years, it has not been adopted widely because of its perceived incompatibility with Reno. To deal with the fairness problem, we propose a new mecha-nism called COmpetitive DElay-based TCP (CODE TCP), which is a variant of Vegas. Most of the operations in CODE TCP are similar to those in Vegas except that the two thresholds

a

and b are adap-tive to the state of the network. When CODE senses the occurrence of network congestion and it does not consider itself to be respon-sible for the congestion, it begins to increase

a

and b instead of reducing its own rate. This makes CODE behave more similarly to Reno. Therefore, if the competing source is Reno, CODE reacts against its aggressiveness and its performance does not decrease. Conversely, if the competing source is Vegas, after a transition per-iod, CODE recovers to a stable status as a Vegas source by reducing

a

and b. Changing the values of

a

and b instead of directly altering the value of its congestion window ðCWNDÞ should allow CODE to preserve the properties of Vegas in reaching an operating point.

The remainder of this paper is organized as follows. We de-scribe the related work in Section2. Section3presents a detailed description of the proposed mechanism, CODE TCP. Section4 pre-sents and discusses the results of both NS-2 simulations and exper-iments on a Linux platform. Finally, the conclusions are presented in Section5.

2. Related work

To ensure network efﬁciency, TCP controls its sending rate based on feedback from the network. In order to control the

* Corresponding author. Tel.: +886 4 7232105x7044; fax: +886 4 7211284. E-mail addresses:[email protected](Y.-C. Chan), [email protected]. edu.tw(C.-L. Lin),[email protected](C.-T. Chan),[email protected](C.-Y. Ho).

Contents lists available atScienceDirect

Computer Communications

(2)

sending rate, TCP estimates the available network bandwidth via a bandwidth estimation scheme. In TCP Reno, packet losses are used to detect network congestion while in TCP Vegas, the queuing de-lay is used to estimate the network condition. In this section, we present a summary of these two congestion control mechanisms and explain why they are incompatible. Then two algorithms, NewVegas[17]and Vegas-A[18], that attempt to solve the fairness problem between Vegas and Reno are described.

2.1. TCP reno

TCP Reno uses a congestion window ðCWNDÞ to control the amount of data transmitted in a round-trip Time ðRTTÞ and a imum window ðMWNDÞ that is set by the receiver to limit the max-imum value of CWND. The congestion control scheme of Reno can be divided into three phases: slow-start, congestion avoidance, and fast retransmission and fast recovery. In the interest of conciseness, we only describe the congestion avoidance phase since it is most closely related to our work. The descriptions of the other two phases can be found in[1].

Since the window size in the slow-start phase expands expo-nentially, packets sent at this increasing speed would quickly lead to network congestion. To avoid this, the congestion avoidance phase begins when CWND exceeds a preset slow-start threshold ðssthreshÞ. In this phase, CWND is incremented by 1=CWND packet every time an ACK is received in order to make CWND grow line-arly. This process continues until a packet loss is detected; subse-quently the scheme switches to the fast retransmission and fast recovery phase.

2.2. TCP vegas

TCP Vegas adopts a more sophisticated bandwidth estimation scheme that attempts to avoid congestion rather than react to it. It uses the measured RTT to accurately calculate the number of data packets that a source can send. Vegas features three improvements as compared to TCP Reno: (1) a modiﬁed slow-start mechanism, (2) an improved congestion avoidance mechanism, and (3) a new retransmission mechanism. Its window adjustment algorithm also consists of three phases. The CWND is updated based on the cur-rently executing phase.Fig. 1shows the state transition diagram of TCP Vegas. A connection begins with the slow-start phase. The window-adjustment phase transition is attributable to speciﬁc events, as depicted along the edges.

2.2.1. Slow-start

During the slow-start phase, Vegas allows a connection to quickly ramp up to the available bandwidth. However, in order to detect and avoid congestion during this phase, Vegas doubles its CWND only every other RTT. In between, the CWND remains ﬁxed so that a valid comparison of the Expected and Actual sending rates can be made. Vegas estimates a suitable amount of extra data to be maintained in the network pipe and controls the CWND accordingly. It records RTTs and sets the BaseRTT to the minimum RTT value measured. The amount of extra data ðDÞ is estimated as follows:

D

¼ ðExpected ActualÞ BaseRTT; ð1Þ

where Expected rate is the current CWND size divided by the BaseRTT, and Actual rate is the CWND divided by the newly mea-sured smoothed RTT.

This detection mechanism is applied during the slow-start phase to decide when to switch the phase. If the estimated amount of extra data is greater than the threshold

c

, Vegas reduces its CWND by one-eighth and transitions from the slow-start phase to the congestion avoidance phase.

2.2.2. Congestion avoidance

During the congestion avoidance phase, Vegas does not contin-ually increase the CWND. Instead, it attempts to detect incipient congestion by comparing the Actual rate with the Expected rate. The CWND is kept constant whenDlies between two thresholds

a

and b. IfDis greater than b, it is considered to indicate incipient congestion and thus the CWND is reduced. On the other hand, ifD

is lesser than

a

, the connection may be underutilizing the available bandwidth and thus the CWND is increased. CWND is updated on a per-RTT basis. The rule for updating CWND can be expressed as follows: CWND ¼ CWND þ 1; if

D

<

a

CWND 1; if

D

>b CWND; if

a

6

D

6b : 8 > < > : ð2Þ

2.2.3. Fast retransmission and fast recovery

TCP Vegas measures the RTT for every packet sent based on fine-grained timer values. By using fine-fine-grained RTT measurements, a timeout period is computed for each packet. When a duplicate ACK is received, Vegas checks whether or not the timeout period of the oldest unacknowledged packet has expired. If it has, the packet is retransmitted. This modification leads to packet retrans-mission after just one or two duplicate ACKs. When a non-duplicate ACK that is the first or second ACK after a fast retransmission is re-ceived, Vegas again checks for the expiration of the oldest unac-knowledged packet following which it may retransmit another packet.

After a packet retransmission is triggered by a duplicate ACK and the ACK of the lost packet is received, the CWND will be re-duced to alleviate the network congestion. Vegas sets the CWND in two cases. If a lost packet has been transmitted just once, the CWND will be three-fourth of the previous window size. Otherwise, it is considered to indicate more serious congestion, and CWND is set to one half of the previous window size. It should be noted that if multiple packet losses occur during one round-trip time and trig-ger more than one fast retransmission, the CWND will be reduced only for the ﬁrst retransmission.

(3)

If a loss episode is sufficiently severe for no ACKs to be received, these triggering the fast retransmission algorithm, the losses will be eventually identified by a Reno-style coarse-grained timeout. When this occurs, ssthresh is set to one half of CWND, following which CWND is reset to two; finally, the connection restarts from the slow-start phase.

2.3. Incompatibility of TCP vegas with TCP reno

Some previous works have demonstrated that TCP Vegas outperforms other implementations of TCP in many cases [2]. However, when a Vegas connection competes with other con-nections that use TCP Reno, it does not receive a fair share of bandwidth due to its proactive congestion avoidance mecha-nism [12,20,21].

Reno continues to increase the window size until a packet is lost. Packet losses mainly occur due to buffer overﬂows. This bandwidth estimation mechanism results in a periodic oscillation of window size and buffer-ﬁlling behavior. Thus, while Vegas at-tempts to maintain a smaller queue length, Reno keeps many more packets in the buffer on average, thus stealing greater bandwidth.

The Reno congestion avoidance scheme is aggressive in that it leaves little room in the buffer for other connections, while Vegas is conservative and attempts to occupy little buffer space. When a Vegas connection shares a link with a Reno connection, the Reno connection uses most of the buffer space; the Vegas connection interprets this as a sign of network congestion and slows down. This is the main reason why Vegas is not deployed widely despite having many desirable properties.

Several schemes have been proposed to deal with this incom-patibility problem. These can be divided into two categories. The ﬁrst type sets

a

and b to optimized values based on an analysis and on characteristics of the network environment such as buffer size at the router and number of connections passing through the router [15,16,22–24]. However, such schemes could not be de-ployed widely in the Internet due to certain problems. First, a connection may pass through a number of routers and thus it cannot determine which one is the real bottleneck. Second, if no router provides useful information, such schemes cannot func-tion properly. The second type attempt to solve the incompatibil-ity problem by dynamically adjusting

a

and b based on feedback from the network [17,18]. Such schemes attempt to detect whether or not Reno connections exist in the network. If Reno connections exist, they will compete with Reno in a more aggres-sive manner. When Reno connections leave the network, they will behave in a manner similar to Vegas. Such schemes are eas-ier to deploy because they do not require information from the router.

2.4. TCP NewVegas

The disadvantage of TCP Vegas in heterogeneous network sce-narios is that when the available bandwidth is fully utilized, it does not increase its own CWND while TCP Reno does, as shown inFig. 2. NewVegas [17] was originally designed to overcome the draw-backs of Vegas. The changes introduced in NewVegas are conﬁned to the congestion avoidance mechanism. Initially, NewVegas sets the thresholds

a

and b to default values

a

0and b0(set to 1 and

3, respectively). Whenever the target ACK arrives at the source, NewVegas updates the thresholds as given by the following pseu-docode, where RTT is the round-trip delay of the target packet and RTToldis the previous one. W is the current CWND and Woldis the

previous one. if (receive_dupack)

if (loss_event_is_true)

fast_ retransmission_ and_ recovery

a¼a0 b¼ b0 else if (D>b) W=W-1 elseif (D<a) W=W+1 else W=W

if (RTT > RTToldand W 6 Wold) a¼aþ 1

b¼ b þ 1

if (RTT 6 RTToldanda>a0) a¼a 1

b¼ b 1

The two thresholds are updated once every RTT. In the ﬁrst con-dition, if the congestion is increasing (last RTT greater than the pre-vious one) but NewVegas has not increased its CWND, it does not consider itself to be responsible for the network congestion. Then, the source is allowed to increase the number of packets it can keep in the bottleneck buffer by increasing the thresholds

a

and b. The thresholds

a

and b are both increased by 1 in order to follow the behavior of Reno in the congestion avoidance phase and thus insert an extra packet into the network.

On the other hand, in the second condition, if the RTT begins decreasing, it implies that either the other sources are also Vegas or some source has been switched off. Therefore, NewVegas can re-duce its two thresholds.

When timeout expiration occurs or three duplicate ACKs are received, the two thresholds are set to the initial values

a

0

and b0 and NewVegas restarts from the congestion avoidance

phase.

(4)

2.5. TCP Vegas-A

TCP Vegas uses ﬁxed values of 1 and 3 for thresholds

a

and b, respectively. The strategy of Vegas is to adjust the CWND to keep a small number of packets buffered at the router. The average number of packets buffered at the router is to be maintained with-in

a

and b. The main idea behind Vegas-A is that rather than ﬁxing

a

and b, they can be made dynamically adjustable and more adap-tive. At the start of a connection,

a

and b are set to 1 and 3, respec-tively. These values are then changed dynamically depending on the network conditions in an attempt to probe the network capac-ity. The detailed operation and pseudocode of Vegas-A is given below. if ðb >D>aÞ if (Tht>Thtrtt) W ¼ W þ 1 a¼aþ 1 b¼ b þ 1 else W ¼ W elseif ðD<aÞ if (a>1 and Tht>Thtrtt) W ¼ W þ 1 elseif (a>1 and Tht<Thtrtt) W ¼ W 1 a¼a 1 b¼ b 1 elseif (a¼ 1) W ¼ W þ 1 elseif (D>b) if (a>1) a¼a 1 b¼ b 1 W ¼ W 1 else W ¼ W

The notation Tht is the actual throughput rate at time t and

Thtrtt is the actual throughput rate measured one RTT before t.

The operation of Vegas-A appears reasonable and it can dynami-cally adjust its thresholds

a

and b. However, when Vegas-A and Reno share the same bottleneck, this may not always be the case. Consider the following case when one Vegas-A connection and one Reno connection share the same bottleneck. Assume thatD

of Vegas-A lies between

a

and b. If Reno keeps increasing its CWND every RTT, the throughput probed by Vegas-A decreases and thus it will not increase its thresholds

a

and b. Therefore, the performance of Vegas-A is limited by its

a

and b update algo-rithm. The performance of Vegas-A will be further examined in Section4.

3. CODE TCP

The proposed algorithm, CODE TCP, is inspired by the idea of NewVegas. In this section, we ﬁrst discuss the drawbacks of New-Vegas and then describe the operation of CODE TCP. The parameter analysis is described in the last subsection.

3.1. Drawbacks of NewVegas

TCP NewVegas appears to be compatible with TCP Reno. How-ever, the simulation results shown inFig. 3indicate otherwise. It is observed that NewVegas sends less packets as compared to Reno in a repetition cycle (period between two packet loss episodes), and therefore, the throughput of NewVegas is lower than that of Reno in this case. There are two drawbacks that lead to NewVegas having a lower throughput.

First, at the ith second, both NewVegas and Reno detected a packet loss. After a packet loss, NewVegas sets

a

and b to the de-fault values, that is,

a

0and b0. Consider the following case: since

NewVegas will adjust its thresholds

a

and b, assume that the max-imum values of

a

and b of NewVegas are 15 and 17 before a packet loss and

a

0and b0 are 1 and 3, respectively. In this case,D will

range from 15 to 17; assume thatDis 16. After the packet loss,

a

and b were immediately set to the default values 1 and 3, respec-tively. This will lead to CWND being decreased by 1 packet every RTT untilDlies between

a

and b while Reno will increase its CWND 1 packet every RTT. This situation occurs during the period be-tween the ith and jth seconds inFig. 3. This ﬁrst drawback prevents NewVegas from competing with TCP Reno.

The second drawback of NewVegas is that every time it in-creases the thresholds

a

and b, it requires another RTT to increase its CWND. It is impossible to increase CWND and the two thresh-olds

a

and b in the same RTT. As shown inFig. 4., which shows a ﬂowchart of the operation of NewVegas, if

a

and b are increased by one in the current RTT; CWND can be increased by one in the next RTT. Thus, W 6 Woldwould not hold at the next RTT, and

a

and b will not be increased. Therefore, NewVegas cannot increase its CWND by 1 packet every RTT while Reno can.

For example, consider the following case shown in Table 1. AssumeD is 5 while

a

and b are 5 and 7, respectively, in RTTj.

If

a

and b are increased by one in RTTj, they would be 6 and 8

in RTTjþ1. At RTTjþ1, since W remains the same before the

updat-ing algorithm, and assumupdat-ing that the variation of RTT is relatively small,Dwould remain 5. After the updating algorithm in the con-gestion avoidance phase at RTTjþ1, W would be increased by one

so thatDcould be kept between

a

and b. FromFig. 4., W 6 Wold

will not hold at RTTjþ1because W is increased by one and

a

and b

will remain the same. Thus, W will not change at RTTjþ2. This is

the second drawback of NewVegas that prevents it from

(5)

ing with Reno. This situation occurs during the time interval be-tween the jth and kth seconds inFig. 3. It is observed that the CWND of Reno increases at a greater rate than that of NewVegas during this period.

3.2. Operation of CODE TCP

Since we know the drawbacks of NewVegas when competing with Reno, we aim to revise NewVegas such that it can compete with Reno while maintaining the good characteristics of Vegas. This improved variant is called COmpetitive DElay-based TCP, or CODE TCP. The main difference between CODE and NewVegas is that when a packet loss is detected by three duplicate ACKs, the two thresholds

a

and b will be multiplied by the factor

, while NewVegas directly sets

a

and b to the default values.

is set to 0:68 based on a numerical analysis shown in the next sub-section. This modification is used to deal with the first drawback of NewVegas. The second modification is that when CODE finds that a Reno connection coexists in the network,

a

and b are in-creased by two to mitigate the effect of the second drawback of NewVegas, and thus, CODE may increase 2 packets every three RTTs.

These two modiﬁcations will make CODE more compatible with Reno and enable a greater performance improvement as compared to NewVegas, as shown inFig. 5. The operation of CODE is given by the following pseudocode.

if (receive_dupack) if (loss_event_is_true) fast_retransmission_and_recovery a¼

a b¼

b else if (D>b) W=W-1 elseif (D<a) W=W + 1 else W=W

if (RTT > RTToldand W 6 Wold) a¼aþ 2 b¼ b þ 2 if (RTT 6 RTToldanda>a0) a¼a 1 b¼ b 1 3.3. Numerical analysis of

In this section, we present a numerical analysis of the parame-ter

. Throughout our analysis, we adopt a dumbbell network topology. We assume a ﬂuid model and that the sources always have packets to transmit. There is no congestion in the ACK path, and therefore, the effect of ACK compression is negligible. One CODE connection and one Reno connection share the bottleneck. Both connections have the same round-trip delay.

We try to model CODE’s and Reno’s CWND with respect to a ‘‘round,” or equivalently, a ‘‘window transmission.” A round begins with the transmission of W packets (back-to-back), where W is the size of the congestion window in that round. A round ends when the source receives the ACK of the ﬁrst packet in that round, and then, the source starts sending a new packet of the next round. For the sake of simplicity, we do not consider the fast retransmis-sion and recovery phase, as shown inFig. 6. In addition, we also as-sume thatDis a function of CWND[15]so that it would be affected by the value of thresholds

a

and b.

Fig. 4. Flowchart of NewVegas operation.

Table 1

Evolution of the parameters of NewVegas.

RTT RTTj RTTj+1 RTTj+2 RTTj+3 RTTj+4 RTTj+5 Wold 20 20 21 21 22 22 a 5 + 1 6 6 + 1 7 7 + 1 8 b 7 + 1 8 8 + 1 9 9 + 1 10 D 5 5 6 6 7 7 W 20 21 21 22 22 23

(6)

FromFig. 6, we know that the ratio of CODE’s throughput ðkVÞ

and Reno’s throughput ðkRÞ can be expressed as the ratio of the

packets sent during a cycle. If we want CODE to get a fair share with Reno, we can simply set the ratio to 1, implying that CODE and Reno send the same number of packets during a cycle and have the same throughput, that is

kV kR ¼ Pk n¼iWVn Pk n¼iWRn ¼ 1; ð3Þ

where WVnand WRn are CODE and Reno’s window size in the nth

round. As shown inFig. 6, if we want CODE to get a fair share with Reno, the area of CODE and Reno during a cycle (ith round to kth round) should be the same. For the sack of simplicity, we focus on how to set the parameter

so that CODE and Reno can have the same area during a cycle. After a packet loss in NewVegas, the thresholds

a

and b are set to the default values; however in CODE, the thresholds are multiplied by the parameter

, having a value greater than 0 and lesser than 1.

For CODE, the CWND after a packet loss will be reduced to three-forth of the largest window size before it, that is

3

4 WVmax; ð4Þ

where WVmax is the maximum value of CWND before packet loss

during a cycle. Assume that after t rounds, CWND reaches the min-imum value, which is

WVmax ð5Þ

at jth round.

Since the area of CODE during a cycle can be divided into two parts (ith round to jth round and jth round to kth round), we calcu-late the areas separately.

Assuming that there are t rounds between ith and jth rounds, the average CWND through i to j is

3 4 WVmaxþ

WVmax 2 ¼ 3 þ 4

8 WVmax; ð6Þ

and therefore, the area between i and j is

3 þ 4

8

WVmax t: ð7Þ

For each cycle, CODE and Reno will experience the same number of rounds. Since Reno adds 1 packet to its CWND every round, the number of rounds through i to k can be expressed asWRmax

2 . WRmax

is the maximum value of CWND before the packet loss during a cy-cle. For the remaining area of CODE, the average CWND through j to k is

WVmaxþ WVmax 2 ¼

þ 1 2 WVmax: ð8Þ

The area between j and k is

þ 1 2 WVmax WRmax 2 t : ð9Þ

Therefore, the packets sent by CODE in a cycle can be expressed as the area between i and k inFig. 6. The total packets sent by CODE through i–k is 3 þ 4

8 WVmax t þ

þ 1 2 WVmax WRmax 2 t : ð10Þ

With regard to Reno, the case is much simpler. The rounds between i and k isWRmax

2 and the average CWND through i–k is

1

2WRmaxþ WRmax

2 ¼

3

4WRmax: ð11Þ

The total packets sent by Reno in a cycle is equal to the area through i–k, that is,

3 4WRmax WRmax 2 ¼ 3 8W 2 Rmax: ð12Þ

Since we know that CODE will decrease its CWND by 1 in each round between i and j,

3

4 WVmax¼

WVmaxþ t: ð13Þ

Solving(13)for t, we obtain

t ¼ 3 4

WVmax: ð14Þ

Fig. 5. Changes in CWND of CODE and Reno for the same bottleneck.

(7)

Using the second modiﬁcation of CODE, CWND can increase by two every three RTTs, while in NewVegas, it can increase by one every other RTT; the slope of CODE between j and k is around two-thirds of that of Reno, and therefore, we assume that CODE will increase its CWND by two every three RTTs between j and k. Substituting (14)into(10), the total packets sent by CODE in a cycle is

3 þ 4

8 WVmax 3 4

WVmaxþ

þ 1 2 WVmax 3 2ð1

ÞWVmax: ð15Þ

Using(3) and (12), the relation between CODE and Reno is 3 þ 4

8 WVmax 3 4

WVmaxþ

þ 1 2 WVmax 3 2ð1

ÞWVmax¼ 3 8W 2 Rmax:

ð16Þ

Since we know the rounds of CODE and Reno during a cycle are the same, 3 4

WVmaxþ 3 2ð1

ÞWVmax¼ 1 2WRmax ð17Þ

Substituting(17)into(16), we obtain

34

2₅₄

_{þ 21 ¼ 0:} _ð18Þ

Solving(18), we ﬁnally obtain

0:68 or 0:91: ð19Þ

The value of 0.91 is unsuitable because it will make(14) unreason-able; the value of t cannot be negative. Since we assume that CWND is a function ofD, when a packet loss occurs in CODE, it will not set thresholds

a

and b to the default values

a

0and b0directly but

mul-tiply them by 0.68 so that CWND can decrease to a suitable value and then begin increasing.

4. Performance evaluation

In this section, we present the simulation results obtained using Network Simulator (NS-2)[25]and the Linux platform to verify the effectiveness of CODE TCP. The network topologies used in the sim-ulations are shown inFigs. 7 and 8. A set of real network experi-ments are also described at the end of this section.

In all of the following simulations, the TCP packet size is set to 1000 bytes, and the TCP congestion window is assumed to be not limited by the receiver window. Unless stated otherwise, we as-sume that the sources always have data to send (FTP source model).

4.1. One reno vs. one vegas/vegas-a/newvegas/CODE

First, we consider the network conﬁguration shown inFig. 7, in which one Reno connection competes with either one Vegas,

Vegas-A, NewVegas, or CODE connection. Each simulation scenario is repeated 20 times by randomly changing the start time of the connections. The connection start time ranges from 0 to 25 s. Since the start times of two competing connections are probably differ-ent, we calculate the average throughput of each connection from second 50 to 200. InFig. 9, we show the results of two connections competing in a single bottleneck by varying the bandwidth of the bottleneck link and setting the buffer size to 100 packets.

Since the two thresholds (

a

and b) of Vegas are ﬁxed at 1 and 3, respectively, Vegas will keep a maximum of three packets at the bottleneck, while Reno can use the rest of the buffer size. Because of this, Vegas has a considerably small throughput as compared to that of Reno, as shown inFig. 9(a).

The results of one Vegas-A connection competing with one Reno connection are shown inFig. 9(b). Although Vegas-A can alter its two thresholds

a

and b, the throughput that it can achieve is still considerably smaller than that of Reno.

Fig. 9(c) shows the results for a NewVegas connection that is af-fected by the two drawbacks described in Section 3; again, the throughput is found to be smaller than that of Reno. However, since NewVegas adjusts its thresholds dynamically, it achieves a noticeable improvement in throughput as compared to Vegas. In the simulation results shown in Fig. 9(d), we observe that the throughputs of CODE and Reno are close to each other.

To further study the simulation results, we also calculate the confidence intervals of the throughput ratio of each set of two competing connections. The corresponding 95% confidence inter-vals (CI) can be found in each sub-figure. If the throughput ratio is 1, then it implies that the two competing connections share the bottleneck link fairly. From the 95% CI of each sub-figure, we can find that the throughput ratio of CODE/Reno is closer to 1 than that of the other combinations.

4.2. Connections with different RTTs

In this subsection, we describe simulations performed for connections with different RTTs. The network conﬁguration is shown inFig. 8. We ﬁx the minimal round-trip delay of one con-nection and vary the minimal round-trip delay of the other connec-tion to determine the behavior of connecconnec-tions with different RTTs. Each simulation scenario is also repeated 20 times by randomly changing the start time of connections. The average throughputs of each competing connection between 50 and 200 s are shown inFigs. 10–13.

Since Vegas is restricted to its ﬁxed thresholds

a

and b, it can only queue a maximum of b packets at the bottleneck, thus induc-ing inefﬁciency when competinduc-ing with Reno. Based on the results shown in Figs. 10(a) and (b), irrespective of whether the RTT of Vegas is larger or smaller than that of Reno, Vegas always has a considerably smaller throughput than Reno.

Fig. 11(a) and (b) show the results of Vegas-A competing with Reno with different RTTs. It is obvious that Vegas-A cannot obtain a fair share of the bottleneck bandwidth.

Fig. 7. Dumbbell network topology used in simulations.

(8)

The results of NewVegas and Reno with different RTTs are shown inFig. 12(a) and (b). Since the throughput of NewVegas re-mains restricted because of its drawbacks, the performance

improvement is limited. Again, irrespective of whether the RTT of NewVegas is larger or smaller than that of Reno, NewVegas has a smaller throughput than Reno. It is notable that some ﬂuctuations

(9)

Fig. 10. Achieved throughput of two competing connections, Vegas and Reno.

(10)

Fig. 12. Achieved throughput of two competing connections, NewVegas and Reno.

(11)

(12)

exist in the measured throughputs. Although each simulation sce-nario is repeated 20 times, the random start times of competing connections induce uncertainty.

The results of CODE and Reno competing with the same bottle-neck with different RTTs are shown inFig. 13(a) and (b). It is well known that when Reno connections compete at the same

(13)

bottleneck, a connection with a small RTT would be more favorable than one with a large RTT.Fig. 13(a) indicates that CODE is prefer-able. However, the result shows that CODE does not steal too much bandwidth from Reno and only takes its fair share. InFig. 13(b), the RTT of Reno is smaller than that of CODE. Although Reno’s RTT is smaller and favorable, CODE can maintain a relative fair share with Reno as compared to the others.

The corresponding 95% confidence intervals of throughput ratio for the results inFigs. 10–13are calculated and shown in each sub-figure. From the 95% CI of each sub-figure, we also find that CODE is more compatible with Reno as compared to the other Vegas variants.

4.3. Bottleneck with different buffer sizes

In this subsection, we test the fairness of two connections that share the same bottleneck under different buffer size settings. The network conﬁguration is shown inFig. 7. Each simulation scenario is repeated 20 times by randomly changing the start time of the connections. The average throughputs of each competing connec-tion between 50 and 200 s are shown inFig. 14.

Vegas uses ﬁxed values of

a

and b, and therefore, it always at-tempts to keep the number of packets between

a

and b at the bot-tleneck buffer. The values of

a

and b are set at 1 and 3, respectively, while Reno uses the remainder of the bottleneck buffer. From the results shown inFig. 14(a), it can be concluded that when the buf-fer size is small, Vegas may maintain a tolerable throughput. How-ever, when the buffer size is increased, the throughput of Vegas worsens.

Vegas-A can alter the values of its two thresholds

a

and b. When the buffer size is small, Vegas-A outperforms Reno. However, Ve-gas-A cannot compete well with Reno when the buffer size is large. The results are shown inFig. 14(b). It appears that the buffer size is a key factor inﬂuencing the performance of Vegas-A. It is also worth noting that when the buffer size is 60 packets, the through-puts of two competing connections are closer than in other circum-stances. We infer that this may be caused by the random connection start times. The connection start time affects Vegas-A’s performance when it competes with Reno.

From the results of NewVegas shown inFig. 14(c), we can con-clude that NewVegas outperforms Reno when the buffer size is small. However, as the buffer size increases, Reno is favored, and hence, it takes advantage of NewVegas. Therefore, Reno obtains more bandwidth from NewVegas. InFig. 14(d), we observe that CODE achieves a higher throughput than Vegas-A or NewVegas.

The 95% conﬁdence intervals of the throughput ratio for the re-sults inFig. 14are calculated and shown in each sub-ﬁgure. It ap-pears that none of the delay-based TCPs can fairly share the

bottleneck with Reno under different buffer size settings. However, CODE maintains a more stable behavior and always achieves a higher throughput than Reno. Although this feature may encourage network users to adopt CODE TCP, the reasons of leading to this feature need to be further studied.

4.4. Varied ratio of connection numbers

In this subsection, we describe simulations of 10 connections sharing the same bottleneck. Some of the sources are Reno and the others are either Vegas, Vegas-A, NewVegas, or CODE. The net-work conﬁguration is shown inFig. 7. InFig. 15, we show the aver-age throughput of connections with a varying number of Reno connections to test the behavior of the other four Vegas variants. Each simulation scenario is also repeated 20 times by randomly changing the start time of the connections.

Vegas connections control their window sizes according to the observed RTTs and calculate the number of packets buffered at the bottleneck. Each connection attempts to keep the number of queued packets in the router buffer between

a

and b. As RTT in-creases because of the increasing queuing delay, Vegas connections continue to decrease their window sizes. On the other hand, Reno connections continue to increase their window sizes irrespective of the increasing RTT; because of this, the window sizes of the Vegas connections continue to decrease until a packet loss occurs.

Vegas-A also cannot compete well with Reno in these scenarios. Although NewVegas can dynamically adjust its thresholds

a

and b, as the queuing delay increases, its algorithm may not function instantaneously. Vegas, Vegas-A, and NewVegas cannot obtain their fair share even if the number of Reno connections is relatively small as compared to the number of Vegas/Vegas-A/NewVegas connections. The respective results are shown in Fig. 15(a)–(c). On the other hand, the result shown inFig. 15(d) indicates that CODE achieves a reasonable fairness irrespective of the number of Reno connections. The same inference can also be obtained from the 95% conﬁdence intervals of throughput ratio those are pre-sented in each sub-ﬁgure.

4.5. Fairness feature in homogeneous scenarios

The simulations presented in this subsection are intended to verify whether or not CODE preserves a good fairness feature in a manner similar to NewVegas and Vegas when only the same vari-ant sources exist in the network.

Fig. 16shows the changes in the CWND of two CODE connec-tions that share the same bottleneck. It is found that CODE pre-serves the good characteristics of Vegas and it can be stable in a homogeneous network environment. When only CODE sources

(14)

exist in the network, they behave like Vegas.Fig. 16shows that a peak exists around second 20. This is because CODE uses the min-imum of the RTTs measured within the last window of transmitted packets to update the thresholds and it is thus sensitive to network variations.

To evaluate the fairness among connections, we use the fairness index proposed in[26]. Given a set of throughputs ðx1;x2; . . . ;xnÞ,

the fairness index of the set is deﬁned as:

F ¼ð Pn i¼1xiÞ 2 n Pn_i¼1x2 i : ð20Þ

The value of the fairness index lies between 0 and 1. If the through-puts of all connections are the same, the index will be 1.

In this simulation, we adopt the network topology shown in Fig. 7, and the network environment is similar to that described in the last subsection except that the bandwidth is variable. Ten connections of the same TCP variant start at the same time and share the same bottleneck. From the simulation results shown in Table 2, we observe that CODE maintains the fairness feature and behaves in a similar manner to NewVegas and Vegas in a homoge-neous scenario.

Fig. 17presents the changes in the CWND of two TCP connec-tions that share the same bottleneck (5 Mb/s). The new connection arrives at the bottleneck link that is occupied by the previously started connection in equilibrium. Both Vegas and CODE can achieve equilibrium and fairly share the bottleneck after a tran-sient period. The trantran-sient period of CODE is longer than that of Vegas because CODE TCP needs to detect whether or not the new competition comes from Reno. The bottleneck queue status shown inFig. 18also reveals the same information. After a transient per-iod, both Vegas and CODE maintain a stable bottleneck queue. It is notable that CODE attains a buffer utilization that is as low as that of Vegas.

4.6. Experiments on the Linux platform

In this subsection, we adopt Fedora 6 with kernel 2.6.18.8 to implement CODE TCP and TCP NewVegas. Since Linux kernel 2.6.18.8 already has a built-in Vegas module, the implementa-tion is easier. In addiimplementa-tion, FreeBSD uses ipfw as a packet ﬁlter and thus we can use it to emulate the router and set the band-width, delay, and queue length at the bottleneck. We also adopt

Table 2

Variation of fairness index value of 10 competing connections with the bottleneck bandwidth.

Bandwidth (Mb/s) Code NewVegas Vegas

5 0.99 0.99 0.97 10 0.97 0.96 0.97 15 0.98 0.98 0.95 20 0.99 0.98 0.95 25 0.99 0.98 0.97 30 0.99 0.96 0.97 35 0.99 0.98 0.99 40 0.99 0.99 0.99 45 0.99 0.99 0.99 50 0.99 0.97 0.99

Fig. 17. Changes in the CWND of two TCP connections for the same bottleneck. A new connection arrives at the bottleneck link that is occupied by the previously started connection in equilibrium.

(15)

Iperf, a bandwidth measurement tool, to run the simulations. The network configuration for the experiments is shown in Fig. 7. One computer is set to be a server (sender) and the other is a client (receiver). A server and a client represent a traffic pair. Two traffic pairs share the same bottleneck and start at the same time.

The experiment results are obtained by varying the bandwidth of the bottleneck link with a queue length of 100 packets and a link delay of 23 ms.Fig. 19(a)–(c) show the results of one Reno connec-tion competing with a Vegas, NewVegas, and CODE connecconnec-tion, respectively.

The experimental results shown inFig. 19are similar to those of the NS-2 simulation in Section 4.1. In all the experiments, the throughput of CODE almost equals that of Reno, confirming the result of the numerical analysis and the good agreement with the NS-2 simulations. NewVegas was affected by the two drawbacks described in Section3, and therefore, its throughput is small as com-pared to that of Reno and it is difficult to obtain a fair share with Reno. However, NewVegas can adjust it thresholds dynamically, and therefore, its throughput can be higher than that of Vegas. The thresholds of Vegas are fixed and therefore it will keep at most three packets at the bottleneck while Reno can use the rest of the buffer size. Therefore, Vegas has a much lower throughput as compared to that of Reno.

4.7. Results on the Internet

Since we have implemented CODE TCP on a Linux platform, the measurements of Vegas/CODE competing with Reno can be

performed over the Internet. Speciﬁcally, two FTP clients upload ﬁles having sizes of 53,612 kB each to an FTP server. One FTP cli-ent uses Vegas or CODE as its transport protocol, and the other uses Reno. The two FTP clients start at the same time and thus compete for resources of the same network path over the Inter-net. The FTP server is at National Changhua University of Educa-tion (NCUE), and the FTP clients are at NaEduca-tional Chiao Tung University (NCTU), as shown in Fig. 20. The two universities are approximately 100 km apart.

We conduct 10 successive rounds of measurement. Each round consisted of two independent experiments. In one, Vegas competes with Reno, while in the other, CODE competes with Reno.Table 3 summaries the results. The throughput of each sample is calculated dividing the file size (53,612 kB) by the file transfer time. When competing with Vegas, by using its more aggressive congestion avoidance scheme, Reno has a considerably higher throughput than Vegas. It should be noted that although the average through-put of Reno is 1.59 times that of Vegas, it does not seem to agree with the simulation results, such as shown inFig. 9(a). In our real network experiments, FTP clients with different TCP variants start at the same time and send files having equal sizes to the FTP server. The FTP client with Reno completes its transmission first. The FTP client with Vegas then utilizes the network resources released by Reno. Therefore, the throughput of Vegas is not very poor. From Ta-ble 3, we conclude that the average throughputs of Reno and CODE are almost equal. Furthermore, from the confidence intervals under different confidence levels, we find that the competing results of CODE and Reno are quite stable. These results confirm the effec-tiveness of CODE.

(16)

5. Conclusion

In this study, we propose a new TCP variant, COmpetitive DE-lay-based TCP (CODE TCP), that is more compatible with Reno and may get its fair share of network resources. CODE is a sen-der-sided modification and hence it can be easily implemented at the end host. Accordingly, CODE can be easily deployed in the Internet. It provides rather flexible control and also retains the good features of the original Vegas. Simulations and experiments confirm that CODE can dynamically adjust Vegas thresholds to overcome the unfairness problem when coexisting with Reno.

An issue that has not been addressed in the present work is the behavior of CODE in networks with non-persistent trafﬁc sources. The slow-start mechanism of CODE is the same as that in Vegas. It appears that Reno may gain an advantage because of its more aggressive start-up. Implementing Reno’s slow-start in CODE would reduce this disadvantage. However, this may affect some features of CODE, such as its stability and fairness. In addition, transmission in high bandwidth-delay product networks has be-come increasingly popular. Quickly adjusting the transmission rate to the bandwidth on the bottleneck link is an important issue for any new TCP variant. Therefore, we intend to design a new

(17)

slow-start mechanism and adapt CODE to high-speed networks in the future.

References

[1] W. Stevens, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, in RFC 2001, January 1997.

[2] L.S. Brakmo, L.L. Peterson, TCP Vegas: end to end congestion avoidance on a global internet, in: IEEE Journal on Selected Areas in Communications, vol. 13, issue 8, August 1995, pp. 1465–1480.

[3] D. Kim, H. Bae, C. Toh, Improving TCP-Vegas performance over MANET routing protocols, in: IEEE Transactions on Vehicular Technology, vol. 56, issue 1, January 2007, pp. 372–377.

[4] C. Yuan, L. Tan, L. Andrew, W. Zhang, M. Zukerman, A generalized FAST TCP scheme, in Computer Communications, vol. 31, issue 14, September 2008, pp. 3242–3249.

[5] D.X. Wei, C. Jin, S.H. Low, S. Hegde, FAST TCP: motivation, architecture, algorithms, performance, in: IEEE/ACM Transactions on Networking, vol. 14, issue 6, December 2006, pp. 1246–1259.

[6] N. Bigdeli, M. Haeri, AQM controller design for networks supporting TCP vegas: a control theoretical approach, in: ISA Transactions, vol. 47, issue 1, January 2008, pp. 143–155.

[7] R. Awdeh, Compatibility of TCP Reno and TCP Vegas in wireless ad hoc networks, in: IET Communications, vol. 1, issue 6, Dec. 2007, pp. 1187– 1194.

[8] L. Ding, X. Wang, Y. Xu, W. Zhang, Improve throughput of TCP-Vegas in multihop ad hoc networks, in: Computer Communications, vol. 31, issue 10, June 2008, pp. 2581–2588.

[9] S. Herrena-Alonso, M. Rodriguez-Perez, A. Suarez-Gonzalez, M. Fernandez-Veiga, C. Lopez-Garcia, Improving TCP Vegas fairness in presence of backward trafﬁc, in: IEEE Communications Letters, vol. 11, issue 3, March 2007, pp. 273–275.

[10] S. Liu, T. Basar, R. Srikant, TCP-Illinois: A loss- and delay-based congestion control algorithm for high-speed networks, in: Performance Evaluation, vol. 65, issues 6–7, June 2008, pp. 417–440.

[11] G. Hasegawa, H. Miyahara, Fairness and stability of congestion control mechanisms of TCP, in: Proceedings of IEEE INFOCOM’99, vol. 3, 1999, pp. 1329–1336.

[12] J. Mo, R.L.V. Anantharam, J. Walrand, Analysis and comparison of TCP Reno and Vegas, in: Proc. of IEEE INFOCOM’99, vol. 3, March 1999, pp. 1556–1563. [13] W. Feng, P. Tinnakornsrisuphap, The failure of TCP in high-performance

computational grids, in: Proc. of Supercomputing’00, pp. 37–37, November 2000.

[14] Y. Chan, C. Lin, C. Ho, Quick Vegas: improving performance of TCP Vegas for high bandwidth-delay product networks, in: IEICE Transactions on Communications, vol. E91-B, issue 4, April 2008, pp. 987–997.

[15] W. Feng, S. Vanichpun, Enabling compatibility between TCP Reno and TCP Vegas, in: Proceedings of the IEEE Symposium on Applications and the Internet, January 2003, pp. 301–308,.

[16] Y.C. Lai, C.L. Yao, Performance comparison between TCP Reno and TCP Vegas, in: Computer Communications, vol. 25, issue 18, December 2002, pp. 1765–1773.

[17] A. DeVendictis, A. Baiocchi, M. Bonacci, Analysis and enhancement of TCP Vegas congestion control in a mixed TCP Vegas and TCP Reno network scenario, in: Performance Evaluation, vol. 5, issue 3–4, August 2003, pp. 225–253.

[18] K. Srijith, L. Jacob, A. Ananda, TCP Vegas-A: improving the performance of TCP Vegas, in: Computer Communications, vol. 28, issue 4, March 2005, pp. 429–440.

[20] Y.C. Lai, C.L. Yao, The performance comparison between TCP Reno and TCP Vegas, in: Seventh International Conference on Parallel and Distributed Systems’00, July 2000, pp. 61–66.

[21] K. Takagaki, H. Ohsaki, M. Murata, Analysis of a window-based ﬂow control mechanism based on TCP Vegas in heterogeneous network environment, in: Proceedings of the IEEE ICC’01, vol. 10, June 2001, pp. 3224–3228. [22] G. Hasegawa, K. Kurata, M. Murata, Analysis and improvement of fairness

between TCP Reno and Vegas for deployment of TCP Vegas to the internet, in: Proceedings of the ICNP, pp. 177–186, November 2000.

[23] Y.C. Lai, Improving the performance of TCP Vegas in a heterogeneous environment, in: Proceedings of the IEEE ICPADS, June 2001, pp. 581–587. [24] E. Weigle, W. Feng, A case for TCP Vegas in high-performance

computational grids, in: High Performance Distributed Computing, August 2001, pp. 158–167.

[25] Network Simulator 2 (NS-2), Available from <http://www.isi.edu/nsnam/ns>. [26] R. Jain, A. Durresi, G. Babic, Throughput fairness index: an explanation, Available from <http://www.cis.ohio-state.edu/~jain/atmf/a99-0045.htm>, February 1999.

Fig. 20. Real test-bed network.

Table 3

Throughput (KB/s) of two competing connections over the internet. Round Reno vs. Vegas Reno vs. CODE 1 547.23 315.69 546.66 542.51 2 553.59 339.91 548.96 551.91 3 552.21 381.16 535.13 540.28 4 552.14 358.31 544.94 548.57 5 555.34 275.88 546.05 551.51 6 552.82 368.05 546.25 542.45 7 553.80 343.03 545.71 548.23 8 552.98 315.91 546.04 549.97 9 551.96 390.85 546.92 543.66 10 552.39 380.89 546.41 540.12 Avg. 552.45 346.97 545.31 545.92 99% CI 552.45 ± 1.71 346.97 ± 29.59 545.31 ± 3.03 545.92 ± 3.74 95% CI 552.45 ± 1.30 346.97 ± 22.52 545.31 ± 2.31 545.92 ± 2.85 90% CI 552.45 ± 1.09 346.97 ± 18.90 545.31 ± 1.94 545.92 ± 2.39