- Email: [email protected]
Improve throughput of TCP-Vegas in multihop ad hoc networks
Computer Communications 31 (2008) 2581–2588
Contents lists available at ScienceDirect
Computer Communications journal homepage: www.elsevier.com/locate/comcom
Improve throughput of TCP-Vegas in multihop ad hoc networks q Lianghui Ding a, Xinbing Wang a,*, Youyun Xu a,b, Wenjun Zhang a a b
Department of Electronic Engineering, Shanghai Jiaotong University, Dongchuan Road 800, Shanghai 200240, China Nanjing Institute of Communication Engineering, PLA University of Science and Technology, Nanjing, PR China
a r t i c l e
i n f o
Article history: Received 24 September 2007 Received in revised form 28 March 2008 Accepted 29 March 2008 Available online 7 April 2008 Keywords: TCP Vegas Throughput Ad hoc DSR
a b s t r a c t Performance of TCP-Vegas is not satisfactory in multihop ad hoc networks over IEEE 802.11 MAC protocol. We analyze the problem with a unified network model and a TCP source window model. We observe that Vegas cannot maintain the optimal window with maximum average throughput when the network capacity is smaller than the reset slow start threshold of Vegas. The aggregate throughput of all traffics decreases as the load of network increases. The main reasons lie in Vegas’s large minimum congestion window, large reset slow start threshold and aggressive window increase policy. All of them induce overload of the network, which cause packet losses at MAC layer and over-reaction at routing layer. These in return result in the breakup of end-to-end connections and reduce the throughput. To fix these problems, we propose a modified TCP protocol based on TCP-Vegas for multihop ad hoc networks, called Vegas-W. We extend congestion window to fraction with a rate control timer under the TCP sending process. Probing mechanisms of legacy TCP-Vegas in both slow start and congestion avoidance phases are changed to increase congestion window after receiving more than one ACK. Furthermore, we update slow start threshold by tracking stable window. We evaluate the performance of Vegas-W through ns-2. Extensive simulation results show that Vegas-W can improve the throughput up to 87% over legacy TCP-Vegas over a variety of topologies including chain, grid, star, dumbbell and hammer, etc. Ó 2008 Elsevier B.V. All rights reserved.
1. Introduction The performance of legacy TCP over multihop ad hoc networks is not satisfactory due to the special features of wireless networks, such as hidden terminal and exposed terminal problems, transmission errors, mobility of nodes, topology variations and routing instability, etc [1]. However, most wireless applications rely on legacy TCP to communicate with TCP-dominant wired hosts, and it is likely that TCP will remain as the major transport protocol for the clients of 802.11 networks [2]. Hence, the analysis and improvement of TCP performance over multihop ad hoc networks is important and valuable. Researchers have done much work on TCP performance in multihop ad hoc networks in recent yeas [1,3–7]. Most of the previous research mainly considered the problem from the perspective that features of wireless networks and protocols at MAC and routing layers affect the performance of TCP. Packet losses caused by router breakage or transmission errors were distinguished from those due to congestion and treated with policies different from congestion avoidance. This category of enhancements is suitable for all
q
This work is supported by the NSF China (No. 60702046). * Corresponding author. Tel.: +86 21 34204517; fax: +86 21 3420 4456. E-mail addresses: [email protected] (L. Ding), [email protected] (X. Wang), [email protected] (Y. Xu), [email protected] (W. Zhang). 0140-3664/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2008.03.026
legacy TCP variations, which consider packet losses as the indication of network congestion. Another usually ignored reason for poor TCP performance in wireless ad hoc networks is the aggressive window increase policy of TCP itself. Nahm et al. [2] reported this results and proposed the strategy using small increase step to improve the throughput of TCP-Newreno in that paper. However, rate control mechanisms of TCP variations are different from each other and hence their performance in multihop ad hoc networks is not the same. Application of TCP in multihop ad hoc networks requires special consideration for the particular TCP variation. Window-based TCP-NewReno [8] and delay-based TCP-Vegas [9] are two widely used transport protocols. The strategy FeW proposed in [2] is suitable to TCP-Newreno and the performance based TCP-Newreno is limited. As to Vegas, only some experimental results were presented in [10,11]. Those results showed that Vegas outperforms other TCP protocols in most scenarios for its window adjustment based on round trip time (RTT) variations. To the best of our knowledge, there has been no literature considering the specific features of Vegas in multihop ad hoc networks in depth and proposing related improved algorithms. Hence, in this paper, we focus on analyzing the influence of TCPVegas itself on the poor TCP throughput and propose new algorithms on TCP itself to improve the throughput. First, we analyze the behavior of Vegas in multihop ad hoc networks with a unified network framework and a TCP source window model. We express
2582
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
the long term throughput as the sum of products of stationary probability and average throughput on each window size. Then based on that, we derive the throughput maximization principle, which is that TCP sources should keep on the window with maximum average throughput with the probability as high as possible. Since the behavior of the existing Vegas in multihop ad hoc networks violates this principle, the aggregate throughput of all flows drops as the load of the network increases. Large minimum window, large reset slow start threshold W rth and aggressive window increase policy are the main reasons for the throughput drop. They induce overload of the network and cause severe collisions at the MAC layer and over-reaction at the routing layer, which in return result in the low throughput. Based on the analysis, we propose a modified Vegas, called Vegas-W, which improves TCP-Vegas in four aspects for multihop wireless circumstances: (i) we extend the congestion window to fraction with a rate control timer under the TCP sending process; (ii) we change probing mechanism in the slow start phase by keeping the congestion window constant until the number of received ACKs is larger than a threshold; (iii) window increase in the congestion avoidance phase is also changed similar to that in the slow start phase, but with a larger threshold; (iv) we update the slow start threshold W th to keep track of the stable window. The simulation results show that Vegas-W improves throughput of Vegas significantly over a wide variety of scenarios. The rest of the paper is organized as follows. The background information about TCP-Vegas and related work is described in Section 2. Section 3 presents analytical model and our Vegas-W algorithm. We evaluate the performance of Vegas-W through ns-2 in Section 4. This paper is concluded in Section 5. 2. Background and related work 2.1. TCP-Vegas TCP-Vegas [9] is a delay-based transport protocol, which adjusts its congestion window according to the phases it performs and the gap D between the real and estimated sending rates. Three thresholds a, b and c are defined in Vegas. TCP senders compare D with c in slow start phase and with a, b in congestion avoidance phase to determine window adjustments. The estimation of the gap is done once per RTT period. Vegas sets BaseRTT to the minimum of all measured round trip times (RTTs) and computes the Expected rate as Expected ¼ w=BaseRTT, where w denotes window size. Let RTT a denote the average measured RTT, then Vegas calculates the Actual rate as Actual ¼ w=RTT a . Then the gap between real and estimated sending rates is D ¼ ðExpected ActualÞ BaseRTT. In slow start phase, the congestion window is smaller than the slow start threshold W th . When receiving a new ACK and D is less than c, TCP senders increase w by one. If not, Vegas decreases the window size by a specific percentage p, sets W th to be the reset value W rth , and switches to the congestion avoidance phase. Slow start is initiated at the very beginning or after a timeout event and ends when the window is larger than W th . Vegas implements timeout mechanism by a coarse grain timer, which is checked once per 500 ms. The window update in slow start phase can be described as in (1). W þ 1; if D < c W¼ ð1Þ W ð1 pÞ; if D >¼ c When TCP sender is in congestion avoidance phase and receives a new ACK, Vegas increases the window by 1=W if D is less than a, decrements it by 1=W if D is larger than b, and keeps it unchanged when D falls between a and b. Detail is shown in (2).
8 1 > : W W1 ;
if D <¼ a if a < D < b if D >¼ b
ð2Þ
Another two effective congestion avoidance mechanisms are fast retransmit and fast recovery, which retransmit lost data packets when receiving three duplicate ACKs without waiting for timeout. Besides coarse grain timeout mechanism, Vegas performs retransmission with another fine grain timer via time stamp included in packets, which allows Vegas to retransmit faster than other TCP variations with only coarse grain timer. More details about Vegas are refer to [9,12]. 2.2. Related work Previous research on TCP in multihop ad hoc networks was mainly on distinguishing between packet losses caused by router breakage or transmission errors and those due to real network congestion. TCP protocol was heuristically modified in [13,14]. Retransmit timer was fixed after retransmitting once rather than increasing exponentially in [13]. The out-of-order events detected were interpreted as an indication of router failure in [14]. Feedback at network layer was adopted for notification of routing breakage in [1,6]. Upon receiving route failure messages, TCP sources snooze all its variables and stop transmitting anymore to shield the effects of multihop ad hoc networks. In the meanwhile, interaction between the TCP layer and the link layer has been considered in many papers. Control frames of the MAC layer were utilized to conduct the flow control at the network layer in [15]. It was observed in [16] that RTT is limited by the number of round trip hops. Fu et al. showed that the maximum throughput can be achieved under a specific window limit in [3] and LRED algorithm was adopted for dropping packets as that in RED [17]. Zhai et al. reported that TCP window may be less than one in multihop ad hoc networks and rate based transport control based on channel busyness ratio was proposed to improve the performance [7]. In addition, some research has been done on analyzing and improving the performance of a particular TCP variation in multihop ad hoc networks. Performance of different TCP variations with distinct routing protocols is compared in [10 and 11]. Nahm et al. observed the interaction between TCP, routing and MAC layers and proposed FeW with small window increase step based on windowbased TCP-NewReno. However, the performance of delay-based TCP-Vegas in multihop ad hoc networks has not been studied in depth. Interaction between Vegas ends and the network, and that between TCP-Vegas and MAC protocols have not been totally addressed. Hence, in this paper, we investigate the behavior of Vegas in multihop ad hoc networks and propose Vegas-W aiming at improving its throughput.
3. Vegas-W 3.1. Unified network framework Interaction between TCP ends and the network can be described with the unified network framework shown in Fig. 1, which consists of three components: TCP sources, network and TCP receivers. Network is a container of data and ACK packets with limited resources, which drop packets according to the load with related stochastic probability. All the TCP sources compose the load ‘injection’ to the network with rate kd , as shown in Fig. 1. All the TCP receivers feedback ACKs to senders through the network with rate ka . TCP
2583
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
Source 1
λd
Source 2
Receiver 1
RREQ RREP RERR etc
Routing
Collision Retransmission
MAC
Channel Error
PHY
Source n
Receiver 2
λa Receiver n
achieved, when w equals to the optimal value W . Since the window size in multihop ad hoc networks is usually small, the probability of duplicate ACKs is low. Hence, it can be neglected and we do not consider it here. Let pðiÞ denote the stationary probability and T w ðiÞ denote the average throughput in state i with window wðiÞ. Then, the average throughput T can be calculated as in (3). X T¼ pðiÞT w ðiÞ ð3Þ i
Data
ACK
Fig. 1. Model of unified network framework.
sources adjust the sending rates, which are controlled by congestion windows, based on the states of ACKs (lost, new or dup) and variations of RTT, and then change the load of the network accordingly. The figure is similar to that in [12], while the factors affecting the performance of TCP includes the special ones of wireless ad hoc networks. Since the rate of ACK ka is determined by the data rate kd , the load of the network is determined by sending rates of all the TCP sources. The capacity of the network is limited by physical channel states, wireless spatial reuse ratio, MAC contention resolution algorithms, and routing protocols, etc. According to the results in [3], there should be a load threshold of the network on which maximum throughput can be achieved. Dividing the load threshold by the packet size and the number of TCP flows, we define W for each flow as the optimal congestion window, on which the aggregate throughput of all flows is maximized. 3.2. TCP window model For a Vegas source with maximum window W m ¼ 8, the window dynamics can be described as a continuous Markov chain shown in Fig. 2, which is similar to that in [12]. The circles denote different states, and the values in them are the congestion widow sizes.The states with 0 are for timeout, where the value 0 means there are no new transmissions and ACKs in timeout periods. The states with light borders correspond to normal states without any loss. The states included in the two squares are the slow start states with W th ¼ 2 and W th ¼ 4. The vertically aligned chain of states with 0 in thick borders are for exponential back off. The horizontal aligned states with thick borders correspond to window reduction in fast retransmit when receiving duplicate ACKs. When the load is different, the collision at the MAC layer using 802.11 (CSMA/CA) as the protocol will be distinct, and the RTT will not always be constant as in wired networks. For the window size w, assuming there are n possible RTTs, each of which is RTTðnÞ with probability pðnÞ, then the average throughput with w will be P T w ¼ n w pðnÞ 1=RTTðnÞ. The maximum throughput T m is
Since (3) is a linear equation and both pðiÞ and T w ðiÞ are positive, it is easily concluded that the maximum throughput is reached when stationary probability p of the window W is maximized, which is called maximization principle here. This means that if TCP sources stay on W for longer time, the aggregate throughput will be higher. 3.3. Interaction between TCP ends and network Follow we analyze the interaction between TCP ends and the network based on simulation results over a 7-hops chain topology as shown in Fig. 3. Different number of flows are placed from the same source node 0 to the same destination node 7 to reflect the distinct load of the network. The aggregate throughput of all the flows are shown in Table 1. Intuitively, the capacity of the network should be shared by all the flows and the whole throughput should keep almost constant. But the results in Table 1 show that the aggregate throughput of all the flows decreases as the number of flows increases. One main reason is the overload caused by self-governed TCP sources. We analyze this problem by the average distribution of the window size as shown in Fig. 4. The zero probability of w ¼ 1 is due to that the minimum window is 2 here. The TCP source with only 1 flow spends about 99% of all the simulation time on w ¼ 3 and can stabilize on it. The throughput in the scenario with only 1 flow is close to the maximum throughput analyzed in [18], hence the
1
0
3
2
6
5
4
7
Fig. 3. 7-Hops chain topology.
Table 1 Throughput of TCP-Vegas over 7-hops chain topology Number of flows
1
2
4
8
TCP-Vegas (Kbps)
206.8
165.3
102.4
79.4
1-flow
1.0
0
0
0
2
3
4
5
6
Wth = 2 1
2
3
4
5
6
7
8
Distribution Probability
2-flow 4-flow
0.8
8-flow
0.6 0.4 0.2
0 0
0
0.0
2
0 1
Wth = 4
2
Fig. 2. Transformation of TCP source window.
0
1
2
3
4
5
6
Window Size Fig. 4. Average distribution of window size over the 7-hop chain topology.
2584
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
optimal window size W 1 for 1 flow is approximately 3. For scenario with more than 1 flow, the window size of 3 should be shared equally by all the flows and the operating window should be less than 2. However, the minimum effective congestion window is 2 as shown in Fig. 4. This indicates that the operating window of scenarios with more than 1 flow is much larger than the optimal value. The large operating windows are caused by following three reasons: large minimum congestion window, large reset slow start threshold W rth and aggressive window increase policy. In TCP-Vegas, both default minimum congestion window and reset slow start threshold W rth are 2, while the optimal congestion window is less than 2. This contradiction forces TCP sources working on large windows and induce overload of the network. In addition, the aggressive window increase policy induces the rise of the congestion window from 2 to 3, 4 and even 5, and aggravates the problem. The reason for this phenomenon is that the congestion window is increased when receiving a new ACK and the value of D meets the requirement. However, in wireless ad hoc networks, RTT is not so stable as in wired networks. The RTT’s distribution of one flow with w ¼ 2 in the scenario with 8 flows over the 7-hops chain topology is shown in Fig. 5. The values of RTT is distributed in a large area and thus increasing w based on only one D meeting the requirement is aggressive, which will induce more serious overload of the network. Besides above analysis, we do some simple modifications on Vegas to show that removing the influence of them can improve the end-to-end throughput. The modifications include four categories: (1)MOD 1: set the minimum congestion window to be 1; (2) MOD 2: set the reset slow start threshold W rth to be 1; (3) MOD 3: combination of MOD 1 and MOD 2; (4) MOD 4: limit the maximum congestion window to be 2 besides MOD 3. The throughput after these 4 modifications are shown in Table 2. The results of MOD 1 and MOD 2 show that one kind of modification only improves the throughput a little when the number of flows is larger than 1, while decreases the throughput with 1 flow. The throughput of MOD 2 is same to that of TCP-Vegas because that the minimum window equalling 2 is larger than W rth and MOD 2 does not affect the operation of TCP-Vegas. The results of MOD 3 and MOD 4 show that combined modifications improve the throughput significantly. The throughput of MOD 4 in the scenario with 8 flows is less than MOD 3, because the limited congestion window reduces the probability of catching the bandwidth by only a portion of the flows. Above simulation results and analysis show that legacy Vegas violates the maximization principle for listed three reasons. Accord-
Fig. 5. RTT’s distribution of one flow with cwnd ¼ 2 in the scenario with 8 flows over 7-hops chain.
Table 2 Throughput after modifications over 7-hops chain topology Number of flows (Kbps)
1
2
4
8
TCP-Vegas MOD 1 MOD 2 MOD 3 MOD 4
206.8 192.6 206.8 192.6 194.5
165.3 158.9 175.9 193.5 194.2
102.4 103.3 95.9 187.8 191.5
79.4 87.1 86.2 120.5 113
ingly, some simple modifications can improve the throughput significantly. However, the simple change of TCP-Vegas is only suitable for the specific topology and reduces the throughput in some scenarios. Hence, a dynamic TCP protocol which can combine the advantages of all the modifications and can adapt to complicated scenarios is needed. 3.4. Vegas-W Based on the observation above, we propose our Vegas-W algorithm in this section. Its improvement consists of four aspects: fractional window support, slower start, moderate congestion avoidance, and W th update. With fractional window support, window is extended to less than 1, which aims at reducing the impact of large minimum window problem. Slower start and moderate congestion avoidance increase window based on more than one D meeting requirement of thresholds to solve the aggressive window increase problem. Besides, speeds of window increase in slow start phase and congestion avoidance phase are distinguished for different features. W th update avoids too slow window increase when W is larger than W rth . 3.4.1. Fractional window support In wireless ad hoc networks, W may be fractional, and even less than one, which requires that TCP sources send fractional number of packets in one RTT. Impact of decimal part when W > 1 is not as serious as that when W < 1, because integer number of packets in one RTT when W < 1 will induce severe overload of the network. Hence, fractional window support proposed only considers fractional window when W is less than 1. Minimum window in Vegas-W is set to be 1 to support fractional window. We assume that N fw consecutive timeout events occurring with window equal to one is an indication of fractional window requirement. For simplicity, window is set to be 0.5 after the indication. A rate control timer is placed under the TCP sending process, which is called when window is less than one and stopped otherwise. Period of the timer is set to be RTT divided by window size and updated once every RTT based on the time stamp included in packets. When timeout occurs, TCP sources send a data packet and reschedule the timer. 3.4.2. Slower start In slow start phase, legacy Vegas increases window when the receives a new ACK and smoothed D is less than c, which is aggressive as explained before. Slower start proposed in Vegas-W probes network with more than one RTT and keeps window unchanged until the number of received ACKs is larger than a threshold. Let ns denote the number of received ACKs satisfying D < c in slow start phase. Let N s denote the window increase threshold. When ns is less than N s and calculated D per RTT is less than c, window keeps constant and ns increases by 1. When ns is larger than N s , the window increases by 1, and ns is reset to be 0. Window is decreased by percentage p same with that in Vegas. The slower start process can be described as in (4).
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
8 > < W; W ¼ W þ 1; > : W ð1 pÞ;
2585
if D < c & ns <¼ N s if D < c & ns > N s
ð4Þ
if D >¼ c
3.4.3. Moderate congestion avoidance Let nCA denote the number of received ACKs satisfying D < a in congestion avoidance phase. Let N CA denote the window increase threshold. When nCA is less than N CA and D is less than a, window keeps constant and nCA increases by 1. When nCA is larger than N CA , the congestion window increases by 1=W, and nCA is reset to be 0. When D falls between a and b, nCA keeps unchanged. Other operations is same to Vegas. The moderate congestion avoidance can be described as in (5). 8 W þ W1 ; > > > < W; W¼ > > > : W W1 ;
if D <¼ a & nCA > N CA if a < D < b or D <¼ a & nCA <¼ N CA
ð5Þ
if D >¼ b
With moderate congestion avoidance, we slow down the window increase speed in congestion avoidance phase and try to make the window stabilize on the optimal window W for long time with large window increase threshold N CA . Congestion avoidance and slow start are two phases in TCP protocol with different features. In congestion avoidance phase, TCP sources have estimated the bandwidth of the network and try to oscillates around the stable window. Hence the increase step should be small to avoid inducing overload of the network. In slower start phase, TCP sources have not known the network state and W may be large. If the window increases as slow as that in congestion avoidance phase, bandwidth will be wasted after random occurring timeout. Thus, window increase in slow start phase should be quicker. Different window increase threshold N s and N CA are used to reflect distinct features of the two phases. 3.4.4. W th Update In legacy Vegas, W th is set to be one half of the window when timeout occurs. This is suitable for wired networks where packet loss is caused by only buffer overflow. In wireless ad hoc networks, packets can be dropped for physical channel error or collision at MAC layer, which are not the indication of real congestion. W th should not always be halved strictly when timeout occurs. For a static wireless ad hoc network with stationary traffics, bandwidth is relatively fixed. Window increase is slow after application of Moderate congestion avoidance in Vegas-W, and large gap between W th and W will waste bandwidth. In addition, relatively large W rth compared to W is a reason for poor performance, which still exists when slower start is adopted. Thus, current W th adjustment method in legacy Vegas should be modified to be suitable for multihop ad hoc networks. W th update proposed adjusts W th tracking W . For estimating the real optimal window W is difficult, stable window is taken as W when TCP sources stabilize on it for time longer than a threshold, where the time is normalized by RTT. W th update comprises two parts: one is for W th reset when receiving a new ACK, another is for W th decrement when timeout occurs. Let nsCA denote the number of stable RTT periods on window W s in congestion avoidance phase. When D is between a and b, nsCA increases by 1, or it keeps constant. When nsCA is larger than a threshold NSCA , W th is set to the window size and nsCA is set to be 0. When current window is larger than W s , nsCA is set to be 0 and W s is set to be current window size. W th update when receiving a new ACK is shown in Fig. 6.
Fig. 6. W th update when receiving a new ACK.
Fig. 7. W th update when timeout occurs.
Let toss denote the number of consecutive timeout events with window less than W th . When toss is larger than a threshold TOss , W th decreases by 1 and toss is set to be 0. W th update when timeout occurs is shown in Fig. 7. 4. Simulation and results In this section, we evaluate Vegas-W and compare it with legacy TCP-Vegas and FeW over a wide variety of scenarios. Due to the space limit, we present the main results as follows, and more results are referred to our technical report [19].
2586
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
4.1. Simulation setup We implement our algorithm into ns-2 [20] simulator and evaluate the performance over DSR [21], which is a widely used on demand routing protocol. IEEE 802.11 [22] is set as the MAC layer protocol. Both basic rate and data rate at 802.11 MAC layer are set to be 2 Mbps. Other parameters are kept as default in ns-2. Long-lived TCP flows (of 500 s) are evaluated over chain, grid and random topologies. The receiving range is 250 m and carrier sensing range is 500 m. The wireless propagation model is the two ray ground model. The packet size is 1024 bytes. The three thresholds a, b and c are set to be 1, 3 and 1, and parameter p in slow start phase is set to be 1=8 as default. Selection of parameters in Vegas-W should consider the tradeoff between algorithm dynamics and network stabilization. Based on simulation results, we choose the value as follows. N fw for fractional window decision is set to be 2. N s and N CA for moderate window increase are set to be 10 and 100 to distinguish window increase policies in different phases. The two parameters NSCA and TOss for W th update are set to be 100 and 2, respectively. 4.2. Chain topology Chain is a common topology with limited resources and shared by different TCP flows. We examine Vegas-W algorithm over chain topology with the number of hops from 4 to 16. Different number of flows are placed on the chain to explain the distinct load. All the TCP flows are placed from the same source node to the same destination node at the edges of the chain. The number includes 1, 2, 4 and 8. The throughput of Vegas-W, TCP-Vegas and FeW over the
chain topology is shown in Fig. 8. Generally, the throughput decreases as the number of hops increases, which is different from some analytical results that the throughput is nearly constant when the number of hops is larger than 4. Theoretically, the capacity of a wireless ad hoc network is determined by the spatial reuse factor. However, the end-to-end throughput is determined by the interaction among TCP, routing and MAC protocols, wireless channel states, and techniques used on the physical layer. As the number of hops increases, the delay of controlling sending rates increases, the time occupied by the path establishment increases, the number of packets lost caused by path broken increases. Hence, the end-to-end throughput decreases although the number of hops is larger than 4. We can see that in Fig. 8, when the number of flows is 8 and network load is heavy, throughput of Vegas-W is better than that of Vegas by about 62% and better than FeW by about 22% on average. Based on above results, the optimal window W 8 for 8 flows is less than one. Fractional window support of Vegas-W extends congestion window to less than 1. W th update adjusts W rth to 1 and slows down the window increase speed. Combination of these two new mechanisms obtains high throughput gain. When the number of flows is 4 and network load is moderate, throughput of Vegas-W is better than that of Vegas by about 87% on average. The optimal window W 4 is less than and close to 1, while the initial window of legacy Vegas is 2, which induces more packets on flight than the network capacity. The modification of minimum window from 2 to 1, slower start and moderate congestion avoidance make TCP sources inject appropriate load to the network and improve the throughput.
a
b
c
d
Fig. 8. Throughput comparison of Vegas-W, Vegas and FeW over chain topology with DSR and 95% confidence interval. (a) 8 flows, (b) 4 flows, (c) 2 flows, (d) 1 flow.
2587
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
4.3. Grid topology We test Vegas-W algorithm on 7 7 grid topology with DSR, as shown in Fig. 9(a). The distance between each neighboring nodes on dash lines is 200 meters. The scenarios with 2, 8 and 14 flows are tested over this grid topology. The number of flows 2ðparallelÞ means the two traffics are placed at the central horizontal line from the same source to the same destination. When the number of flow is 2ðcrossÞ, 4 and 14, traffics are placed evenly and symmetrically with equal horizontal and vertical number of flows. The throughput of Vegas, Vegas-W and FeW is shown in Fig. 9(b). Vegas-W obtains higher throughput than Vegas especially when the number of flows is large. The percentages are 4%, 9% and 13%, respectively, when the number of flows is 2ðcrossÞ, 4 and 14. When the number of flows is 2ðparallelÞ, the throughput of Vegas-W is a little smaller than Vegas. Compared to FeW, Vegas-W obtains higher throughput than FeW by about 15% and 6%, respectively, when the number of flows is 2ðparallelÞ and 2(cross). However, when the number of flows is 4 and 14, the improvement is smaller than other two. This is because that when the number of flows. 4.4. Random topology One hundred fifty nodes are placed randomly on a 2000 M 2000 M square area, with 8, 16, 32 and 50 flows with random sources and destinations.
aA
0
1
2
3
4
5
6
1200 1000
Throughput (Kbps)
When the number of flows is 2 and network load is slightly heavy, throughput of Vegas-W is larger than Vegas about 27%. The reason is same with that in scenario with 4 flows. When the numbers of flows are 4 and 2, the throughput of Vegas-W is similar to that of FeW. This is because the optimal window is between 1 and 2, the window adjustment strategy of Vegas-W is similar to FeW. When there is only one flow over the chain and the load is light, both Vegas-W and Vegas almost obtain same throughput and the throughput of them is better than FeW by about 7%. For this scenario, W 1 is larger than W rth ¼ 2 of legacy Vegas, and TCP sources can stabilize on it in most of the time. So loss probability will be small and the system will run fluently. Separation of different window increase thresholds in slow start and congestion avoidance phases and W th update mechanisms of Vegas-W reserve this stable property of Vegas and make Vegas-W obtain close throughput. Vegas-W and TCP-Vegas with the property of stable window obtains higher throughput than FeW without this property.
F
400
0 8
16
32
50
Number of Flows Fig. 10. Throughput comparison of Vegas-W, Vegas and FeW over random topology with DSR and 95% confidence interval.
Fig. 10 shows that Vegas-W obtains higher throughput than Vegas and FeW. But the differences are not so obvious as that over chain topology. That’s because of two main reasons. One is the near-far phenomenon, which means that the throughput is dominated by the flows with small numbers of hops. Another is the uniform distribution of the positions of flows, which means that the probability there are scenarios with heavy load as in chain topology is small. Since the structure features of the random topology is not very obvious, the results here just show Vegas-W is applicable to real networks with random topologies. 5. Conclusion In this paper, we analyze the poor performance of Vegas over wireless ad hoc networks via simulation together with a unified network framework and the TCP source window model. We identify the major reasons as large minimum window, large reset slow start threshold W rth and aggressive window increase policy. We then propose a new algorithm, called Vegas-W, which considers the special features of wireless ad hoc networks and improves legacy Vegas in four aspects: fractional window support, slower start, moderate congestion avoidance and W th update, respectively. We evaluate Vegas-W through ns-2, and compare it with legacy Vegas and FeW with DSR over a wide range of topologies with different network load. The simulation results show that Vegas-W obtains higher throughput than Vegas up to 87% and than FeW up to 22%.
400
Throughput (Kbps)
E
600
b
B
D
800
200
450
C
Vegas Vegas-W FeW
Vegas Vegas-W FeW
350 300 250 200 150 100 50 0 2(prallel)
G
2(cross)
41
4
Number of Flows
Fig. 9. Grid topology and throughput comparison of Vegas-W, Vegas and FeW over grid topology with DSR and 95% confidence interval. (a) Grid topology. (b) Throughput comparison.
2588
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
How to set up a more comprehensive mathematic model and analyze the interactions between TCP sources and network, and the interactions between TCP, routing and MAC protocols over multihop wireless circumstances are left as the future work. Acknowledgments We appreciate the anonymous reviewers’ constructive and valuable suggestions. This work is supported by the National Natural Science Foundation of China under the grant (No. 60625103, 60702046), and Science and Technology Commission of Shanghai Municipality (STCSM) under the Grant No. 05DZ22102; China Ministry of Education (No. 20070248095); Shanghai Jiaotong University Young Faculty Funding (No. 06ZBX800050); Shanghai Jiaotong University Pre-Research Funding; Qualcom China Research Grant. References [1] G. Holland, N. Vaidya, Analysis of tcp performance over mobile ad hoc networks, in: Proceedings of the IEEE/ACM MOBICOM, August 1999. [2] K. Nahm, A. Helmy, C.-C. Jay Kuo, TCP over multihop 802.11 networks: issues and performance enhancement, in: Proceedings of the ACM MobiHoc, UrbanaChampaign, IL, USA, May 2005. [3] Z. Fu, P. Zerfos, H. Luo, S. Lu, L. Zhang, M. Gerla, The impact of multihop wireless channel on tcp throughput and loss, in: Proceedings of the IEEE INFOCOM, San Francisco, USA, March 2003. [4] K. Xu, M. Gerla, L. Qi, Y. Shu, Enhancing tcp fairness in ad hoc wireless networks using neighborhood red, in: Proceedings of the MobiCom, San Diego, California, USA, September 2003. [5] Z. Fu, X. Meng, S. Lu, How bad tcp can perform in mobile ad hoc networks, in: IEEE International Symposium on Computers and Communications (ISCC’02), Taormina, Italy, July 2002. [6] K. Chandran, S. Raghunathan, S. Venkatesan, R. Prakash, A feedback-based scheme for improving TCP performance in ad hoc wireless networks, in: IEEE Pacific-Rim Conference on Multimedia, vol. 8, no. 1, February 2001.
[7] H. Zhai, X. Chen, Y. Fang, Rate-based transport control for mobile ad hoc networks, in: Proceedings of the IEEE WCNC, New Orleans, LA USA, March 2005. [8] S. Floyd, T. Henderson, RFC2582: the NewReno modification to TCP’s fast recovery algorithm, April 1999. [9] L.S. Brakmo, S.W. O’Malley, L.L. Peterson, TCP vegas: new techniques for congestion detection and avoidance, in: Proceedings of the ACM SIGCOMM, October 1994. [10] M. Yahia, J. Bíró, Behavior of TCP algorithms on ad-hoc networks based on different routing protocols (MANETS) and propagation models, in: Proceedings of the ICWMC, Bucharest, Romania, July 2006. [11] M. Berger, S. Lima, A. Manoussakis, J. Pulgarin, B. Sanchez, A performance comparison of TCP protocols over mobile ad hoc wireless networks, in: Proceedings of the CERMA, Cuernavaca, Mexico, December 2006. [12] A. Wierman, T. Osogami, Jörgen Olsén, A unified framework for modeling TCPVegas, TCP-SACK, and TCP-Reno, in: Proceedings of the MASCOTS, Orlando, FL, USA, October 2003. [13] T.D. Dyer, R.V. Boppana, A comparison of TCP performance over three routing protocols for mobile ad hoc netwoks, in: Proceedings of the ACM MobiHoc, October 2001. [14] F. Wang, Y. Zhang, Improving TCP performance over mobile ad-hoc networks with out-of-order detection and response, in: Proceedings of the ACM MobiHoc, Lausanne, Switzerland, June 2002. [15] H. Zhai, Y. Fang, Distributed flow control and medium access in multihop ad hoc networks, IEEE Trans. Mobile Comput. 5 (11) (2006) 1503–1514. [16] K. Chen, Y. Xue, K. Nahrstedt, On setting TCP’s congestion window limit in mobile ad hoc network, in: Proceedings of the IEEE ICC, Anchorage, Alaska, May 2003. [17] S. Floyd, V. Jacobson, Random early detection gateways for congestion avoidance, IEEE/ACM Trans. Netw. 1 (4) (1993). August. [18] J. Li, C. Blake, D.S.J. De Couto, H.I. Lee, R. Morris, Capacity of ad hoc wireless networks, in: Proceedings of MobiCom, Rome, Italy, July 2001. [19] L. Ding, X. Wang, Y. Xu, W. Zhang, Y. Liu, Improve throughput of TCP-Vegas in multihop ad hoc networks, Department of Electronic Engineering, Shanghai Jiaotong University, China, Technical Report, 2007. Available from:. [20] The Network Simulator – ns2. Available from: . [21] D. Johnson, D. Maltz, Y. Hu, The dynamic source routing for mobile ad hoc networks, IETF Internet Draft, July 2004. Available from: . [22] IEEE 802.11 WG, Part 11: Wireless lan medium access control (mac) and physical layer (phy) specification, Standard, IEEE, August 1999.
Contents lists available at ScienceDirect
Computer Communications journal homepage: www.elsevier.com/locate/comcom
Improve throughput of TCP-Vegas in multihop ad hoc networks q Lianghui Ding a, Xinbing Wang a,*, Youyun Xu a,b, Wenjun Zhang a a b
Department of Electronic Engineering, Shanghai Jiaotong University, Dongchuan Road 800, Shanghai 200240, China Nanjing Institute of Communication Engineering, PLA University of Science and Technology, Nanjing, PR China
a r t i c l e
i n f o
Article history: Received 24 September 2007 Received in revised form 28 March 2008 Accepted 29 March 2008 Available online 7 April 2008 Keywords: TCP Vegas Throughput Ad hoc DSR
a b s t r a c t Performance of TCP-Vegas is not satisfactory in multihop ad hoc networks over IEEE 802.11 MAC protocol. We analyze the problem with a unified network model and a TCP source window model. We observe that Vegas cannot maintain the optimal window with maximum average throughput when the network capacity is smaller than the reset slow start threshold of Vegas. The aggregate throughput of all traffics decreases as the load of network increases. The main reasons lie in Vegas’s large minimum congestion window, large reset slow start threshold and aggressive window increase policy. All of them induce overload of the network, which cause packet losses at MAC layer and over-reaction at routing layer. These in return result in the breakup of end-to-end connections and reduce the throughput. To fix these problems, we propose a modified TCP protocol based on TCP-Vegas for multihop ad hoc networks, called Vegas-W. We extend congestion window to fraction with a rate control timer under the TCP sending process. Probing mechanisms of legacy TCP-Vegas in both slow start and congestion avoidance phases are changed to increase congestion window after receiving more than one ACK. Furthermore, we update slow start threshold by tracking stable window. We evaluate the performance of Vegas-W through ns-2. Extensive simulation results show that Vegas-W can improve the throughput up to 87% over legacy TCP-Vegas over a variety of topologies including chain, grid, star, dumbbell and hammer, etc. Ó 2008 Elsevier B.V. All rights reserved.
1. Introduction The performance of legacy TCP over multihop ad hoc networks is not satisfactory due to the special features of wireless networks, such as hidden terminal and exposed terminal problems, transmission errors, mobility of nodes, topology variations and routing instability, etc [1]. However, most wireless applications rely on legacy TCP to communicate with TCP-dominant wired hosts, and it is likely that TCP will remain as the major transport protocol for the clients of 802.11 networks [2]. Hence, the analysis and improvement of TCP performance over multihop ad hoc networks is important and valuable. Researchers have done much work on TCP performance in multihop ad hoc networks in recent yeas [1,3–7]. Most of the previous research mainly considered the problem from the perspective that features of wireless networks and protocols at MAC and routing layers affect the performance of TCP. Packet losses caused by router breakage or transmission errors were distinguished from those due to congestion and treated with policies different from congestion avoidance. This category of enhancements is suitable for all
q
This work is supported by the NSF China (No. 60702046). * Corresponding author. Tel.: +86 21 34204517; fax: +86 21 3420 4456. E-mail addresses: [email protected] (L. Ding), [email protected] (X. Wang), [email protected] (Y. Xu), [email protected] (W. Zhang). 0140-3664/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2008.03.026
legacy TCP variations, which consider packet losses as the indication of network congestion. Another usually ignored reason for poor TCP performance in wireless ad hoc networks is the aggressive window increase policy of TCP itself. Nahm et al. [2] reported this results and proposed the strategy using small increase step to improve the throughput of TCP-Newreno in that paper. However, rate control mechanisms of TCP variations are different from each other and hence their performance in multihop ad hoc networks is not the same. Application of TCP in multihop ad hoc networks requires special consideration for the particular TCP variation. Window-based TCP-NewReno [8] and delay-based TCP-Vegas [9] are two widely used transport protocols. The strategy FeW proposed in [2] is suitable to TCP-Newreno and the performance based TCP-Newreno is limited. As to Vegas, only some experimental results were presented in [10,11]. Those results showed that Vegas outperforms other TCP protocols in most scenarios for its window adjustment based on round trip time (RTT) variations. To the best of our knowledge, there has been no literature considering the specific features of Vegas in multihop ad hoc networks in depth and proposing related improved algorithms. Hence, in this paper, we focus on analyzing the influence of TCPVegas itself on the poor TCP throughput and propose new algorithms on TCP itself to improve the throughput. First, we analyze the behavior of Vegas in multihop ad hoc networks with a unified network framework and a TCP source window model. We express
2582
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
the long term throughput as the sum of products of stationary probability and average throughput on each window size. Then based on that, we derive the throughput maximization principle, which is that TCP sources should keep on the window with maximum average throughput with the probability as high as possible. Since the behavior of the existing Vegas in multihop ad hoc networks violates this principle, the aggregate throughput of all flows drops as the load of the network increases. Large minimum window, large reset slow start threshold W rth and aggressive window increase policy are the main reasons for the throughput drop. They induce overload of the network and cause severe collisions at the MAC layer and over-reaction at the routing layer, which in return result in the low throughput. Based on the analysis, we propose a modified Vegas, called Vegas-W, which improves TCP-Vegas in four aspects for multihop wireless circumstances: (i) we extend the congestion window to fraction with a rate control timer under the TCP sending process; (ii) we change probing mechanism in the slow start phase by keeping the congestion window constant until the number of received ACKs is larger than a threshold; (iii) window increase in the congestion avoidance phase is also changed similar to that in the slow start phase, but with a larger threshold; (iv) we update the slow start threshold W th to keep track of the stable window. The simulation results show that Vegas-W improves throughput of Vegas significantly over a wide variety of scenarios. The rest of the paper is organized as follows. The background information about TCP-Vegas and related work is described in Section 2. Section 3 presents analytical model and our Vegas-W algorithm. We evaluate the performance of Vegas-W through ns-2 in Section 4. This paper is concluded in Section 5. 2. Background and related work 2.1. TCP-Vegas TCP-Vegas [9] is a delay-based transport protocol, which adjusts its congestion window according to the phases it performs and the gap D between the real and estimated sending rates. Three thresholds a, b and c are defined in Vegas. TCP senders compare D with c in slow start phase and with a, b in congestion avoidance phase to determine window adjustments. The estimation of the gap is done once per RTT period. Vegas sets BaseRTT to the minimum of all measured round trip times (RTTs) and computes the Expected rate as Expected ¼ w=BaseRTT, where w denotes window size. Let RTT a denote the average measured RTT, then Vegas calculates the Actual rate as Actual ¼ w=RTT a . Then the gap between real and estimated sending rates is D ¼ ðExpected ActualÞ BaseRTT. In slow start phase, the congestion window is smaller than the slow start threshold W th . When receiving a new ACK and D is less than c, TCP senders increase w by one. If not, Vegas decreases the window size by a specific percentage p, sets W th to be the reset value W rth , and switches to the congestion avoidance phase. Slow start is initiated at the very beginning or after a timeout event and ends when the window is larger than W th . Vegas implements timeout mechanism by a coarse grain timer, which is checked once per 500 ms. The window update in slow start phase can be described as in (1). W þ 1; if D < c W¼ ð1Þ W ð1 pÞ; if D >¼ c When TCP sender is in congestion avoidance phase and receives a new ACK, Vegas increases the window by 1=W if D is less than a, decrements it by 1=W if D is larger than b, and keeps it unchanged when D falls between a and b. Detail is shown in (2).
8 1 >
if D <¼ a if a < D < b if D >¼ b
ð2Þ
Another two effective congestion avoidance mechanisms are fast retransmit and fast recovery, which retransmit lost data packets when receiving three duplicate ACKs without waiting for timeout. Besides coarse grain timeout mechanism, Vegas performs retransmission with another fine grain timer via time stamp included in packets, which allows Vegas to retransmit faster than other TCP variations with only coarse grain timer. More details about Vegas are refer to [9,12]. 2.2. Related work Previous research on TCP in multihop ad hoc networks was mainly on distinguishing between packet losses caused by router breakage or transmission errors and those due to real network congestion. TCP protocol was heuristically modified in [13,14]. Retransmit timer was fixed after retransmitting once rather than increasing exponentially in [13]. The out-of-order events detected were interpreted as an indication of router failure in [14]. Feedback at network layer was adopted for notification of routing breakage in [1,6]. Upon receiving route failure messages, TCP sources snooze all its variables and stop transmitting anymore to shield the effects of multihop ad hoc networks. In the meanwhile, interaction between the TCP layer and the link layer has been considered in many papers. Control frames of the MAC layer were utilized to conduct the flow control at the network layer in [15]. It was observed in [16] that RTT is limited by the number of round trip hops. Fu et al. showed that the maximum throughput can be achieved under a specific window limit in [3] and LRED algorithm was adopted for dropping packets as that in RED [17]. Zhai et al. reported that TCP window may be less than one in multihop ad hoc networks and rate based transport control based on channel busyness ratio was proposed to improve the performance [7]. In addition, some research has been done on analyzing and improving the performance of a particular TCP variation in multihop ad hoc networks. Performance of different TCP variations with distinct routing protocols is compared in [10 and 11]. Nahm et al. observed the interaction between TCP, routing and MAC layers and proposed FeW with small window increase step based on windowbased TCP-NewReno. However, the performance of delay-based TCP-Vegas in multihop ad hoc networks has not been studied in depth. Interaction between Vegas ends and the network, and that between TCP-Vegas and MAC protocols have not been totally addressed. Hence, in this paper, we investigate the behavior of Vegas in multihop ad hoc networks and propose Vegas-W aiming at improving its throughput.
3. Vegas-W 3.1. Unified network framework Interaction between TCP ends and the network can be described with the unified network framework shown in Fig. 1, which consists of three components: TCP sources, network and TCP receivers. Network is a container of data and ACK packets with limited resources, which drop packets according to the load with related stochastic probability. All the TCP sources compose the load ‘injection’ to the network with rate kd , as shown in Fig. 1. All the TCP receivers feedback ACKs to senders through the network with rate ka . TCP
2583
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
Source 1
λd
Source 2
Receiver 1
RREQ RREP RERR etc
Routing
Collision Retransmission
MAC
Channel Error
PHY
Source n
Receiver 2
λa Receiver n
achieved, when w equals to the optimal value W . Since the window size in multihop ad hoc networks is usually small, the probability of duplicate ACKs is low. Hence, it can be neglected and we do not consider it here. Let pðiÞ denote the stationary probability and T w ðiÞ denote the average throughput in state i with window wðiÞ. Then, the average throughput T can be calculated as in (3). X T¼ pðiÞT w ðiÞ ð3Þ i
Data
ACK
Fig. 1. Model of unified network framework.
sources adjust the sending rates, which are controlled by congestion windows, based on the states of ACKs (lost, new or dup) and variations of RTT, and then change the load of the network accordingly. The figure is similar to that in [12], while the factors affecting the performance of TCP includes the special ones of wireless ad hoc networks. Since the rate of ACK ka is determined by the data rate kd , the load of the network is determined by sending rates of all the TCP sources. The capacity of the network is limited by physical channel states, wireless spatial reuse ratio, MAC contention resolution algorithms, and routing protocols, etc. According to the results in [3], there should be a load threshold of the network on which maximum throughput can be achieved. Dividing the load threshold by the packet size and the number of TCP flows, we define W for each flow as the optimal congestion window, on which the aggregate throughput of all flows is maximized. 3.2. TCP window model For a Vegas source with maximum window W m ¼ 8, the window dynamics can be described as a continuous Markov chain shown in Fig. 2, which is similar to that in [12]. The circles denote different states, and the values in them are the congestion widow sizes.The states with 0 are for timeout, where the value 0 means there are no new transmissions and ACKs in timeout periods. The states with light borders correspond to normal states without any loss. The states included in the two squares are the slow start states with W th ¼ 2 and W th ¼ 4. The vertically aligned chain of states with 0 in thick borders are for exponential back off. The horizontal aligned states with thick borders correspond to window reduction in fast retransmit when receiving duplicate ACKs. When the load is different, the collision at the MAC layer using 802.11 (CSMA/CA) as the protocol will be distinct, and the RTT will not always be constant as in wired networks. For the window size w, assuming there are n possible RTTs, each of which is RTTðnÞ with probability pðnÞ, then the average throughput with w will be P T w ¼ n w pðnÞ 1=RTTðnÞ. The maximum throughput T m is
Since (3) is a linear equation and both pðiÞ and T w ðiÞ are positive, it is easily concluded that the maximum throughput is reached when stationary probability p of the window W is maximized, which is called maximization principle here. This means that if TCP sources stay on W for longer time, the aggregate throughput will be higher. 3.3. Interaction between TCP ends and network Follow we analyze the interaction between TCP ends and the network based on simulation results over a 7-hops chain topology as shown in Fig. 3. Different number of flows are placed from the same source node 0 to the same destination node 7 to reflect the distinct load of the network. The aggregate throughput of all the flows are shown in Table 1. Intuitively, the capacity of the network should be shared by all the flows and the whole throughput should keep almost constant. But the results in Table 1 show that the aggregate throughput of all the flows decreases as the number of flows increases. One main reason is the overload caused by self-governed TCP sources. We analyze this problem by the average distribution of the window size as shown in Fig. 4. The zero probability of w ¼ 1 is due to that the minimum window is 2 here. The TCP source with only 1 flow spends about 99% of all the simulation time on w ¼ 3 and can stabilize on it. The throughput in the scenario with only 1 flow is close to the maximum throughput analyzed in [18], hence the
1
0
3
2
6
5
4
7
Fig. 3. 7-Hops chain topology.
Table 1 Throughput of TCP-Vegas over 7-hops chain topology Number of flows
1
2
4
8
TCP-Vegas (Kbps)
206.8
165.3
102.4
79.4
1-flow
1.0
0
0
0
2
3
4
5
6
Wth = 2 1
2
3
4
5
6
7
8
Distribution Probability
2-flow 4-flow
0.8
8-flow
0.6 0.4 0.2
0 0
0
0.0
2
0 1
Wth = 4
2
Fig. 2. Transformation of TCP source window.
0
1
2
3
4
5
6
Window Size Fig. 4. Average distribution of window size over the 7-hop chain topology.
2584
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
optimal window size W 1 for 1 flow is approximately 3. For scenario with more than 1 flow, the window size of 3 should be shared equally by all the flows and the operating window should be less than 2. However, the minimum effective congestion window is 2 as shown in Fig. 4. This indicates that the operating window of scenarios with more than 1 flow is much larger than the optimal value. The large operating windows are caused by following three reasons: large minimum congestion window, large reset slow start threshold W rth and aggressive window increase policy. In TCP-Vegas, both default minimum congestion window and reset slow start threshold W rth are 2, while the optimal congestion window is less than 2. This contradiction forces TCP sources working on large windows and induce overload of the network. In addition, the aggressive window increase policy induces the rise of the congestion window from 2 to 3, 4 and even 5, and aggravates the problem. The reason for this phenomenon is that the congestion window is increased when receiving a new ACK and the value of D meets the requirement. However, in wireless ad hoc networks, RTT is not so stable as in wired networks. The RTT’s distribution of one flow with w ¼ 2 in the scenario with 8 flows over the 7-hops chain topology is shown in Fig. 5. The values of RTT is distributed in a large area and thus increasing w based on only one D meeting the requirement is aggressive, which will induce more serious overload of the network. Besides above analysis, we do some simple modifications on Vegas to show that removing the influence of them can improve the end-to-end throughput. The modifications include four categories: (1)MOD 1: set the minimum congestion window to be 1; (2) MOD 2: set the reset slow start threshold W rth to be 1; (3) MOD 3: combination of MOD 1 and MOD 2; (4) MOD 4: limit the maximum congestion window to be 2 besides MOD 3. The throughput after these 4 modifications are shown in Table 2. The results of MOD 1 and MOD 2 show that one kind of modification only improves the throughput a little when the number of flows is larger than 1, while decreases the throughput with 1 flow. The throughput of MOD 2 is same to that of TCP-Vegas because that the minimum window equalling 2 is larger than W rth and MOD 2 does not affect the operation of TCP-Vegas. The results of MOD 3 and MOD 4 show that combined modifications improve the throughput significantly. The throughput of MOD 4 in the scenario with 8 flows is less than MOD 3, because the limited congestion window reduces the probability of catching the bandwidth by only a portion of the flows. Above simulation results and analysis show that legacy Vegas violates the maximization principle for listed three reasons. Accord-
Fig. 5. RTT’s distribution of one flow with cwnd ¼ 2 in the scenario with 8 flows over 7-hops chain.
Table 2 Throughput after modifications over 7-hops chain topology Number of flows (Kbps)
1
2
4
8
TCP-Vegas MOD 1 MOD 2 MOD 3 MOD 4
206.8 192.6 206.8 192.6 194.5
165.3 158.9 175.9 193.5 194.2
102.4 103.3 95.9 187.8 191.5
79.4 87.1 86.2 120.5 113
ingly, some simple modifications can improve the throughput significantly. However, the simple change of TCP-Vegas is only suitable for the specific topology and reduces the throughput in some scenarios. Hence, a dynamic TCP protocol which can combine the advantages of all the modifications and can adapt to complicated scenarios is needed. 3.4. Vegas-W Based on the observation above, we propose our Vegas-W algorithm in this section. Its improvement consists of four aspects: fractional window support, slower start, moderate congestion avoidance, and W th update. With fractional window support, window is extended to less than 1, which aims at reducing the impact of large minimum window problem. Slower start and moderate congestion avoidance increase window based on more than one D meeting requirement of thresholds to solve the aggressive window increase problem. Besides, speeds of window increase in slow start phase and congestion avoidance phase are distinguished for different features. W th update avoids too slow window increase when W is larger than W rth . 3.4.1. Fractional window support In wireless ad hoc networks, W may be fractional, and even less than one, which requires that TCP sources send fractional number of packets in one RTT. Impact of decimal part when W > 1 is not as serious as that when W < 1, because integer number of packets in one RTT when W < 1 will induce severe overload of the network. Hence, fractional window support proposed only considers fractional window when W is less than 1. Minimum window in Vegas-W is set to be 1 to support fractional window. We assume that N fw consecutive timeout events occurring with window equal to one is an indication of fractional window requirement. For simplicity, window is set to be 0.5 after the indication. A rate control timer is placed under the TCP sending process, which is called when window is less than one and stopped otherwise. Period of the timer is set to be RTT divided by window size and updated once every RTT based on the time stamp included in packets. When timeout occurs, TCP sources send a data packet and reschedule the timer. 3.4.2. Slower start In slow start phase, legacy Vegas increases window when the receives a new ACK and smoothed D is less than c, which is aggressive as explained before. Slower start proposed in Vegas-W probes network with more than one RTT and keeps window unchanged until the number of received ACKs is larger than a threshold. Let ns denote the number of received ACKs satisfying D < c in slow start phase. Let N s denote the window increase threshold. When ns is less than N s and calculated D per RTT is less than c, window keeps constant and ns increases by 1. When ns is larger than N s , the window increases by 1, and ns is reset to be 0. Window is decreased by percentage p same with that in Vegas. The slower start process can be described as in (4).
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
8 > < W; W ¼ W þ 1; > : W ð1 pÞ;
2585
if D < c & ns <¼ N s if D < c & ns > N s
ð4Þ
if D >¼ c
3.4.3. Moderate congestion avoidance Let nCA denote the number of received ACKs satisfying D < a in congestion avoidance phase. Let N CA denote the window increase threshold. When nCA is less than N CA and D is less than a, window keeps constant and nCA increases by 1. When nCA is larger than N CA , the congestion window increases by 1=W, and nCA is reset to be 0. When D falls between a and b, nCA keeps unchanged. Other operations is same to Vegas. The moderate congestion avoidance can be described as in (5). 8 W þ W1 ; > > > < W; W¼ > > > : W W1 ;
if D <¼ a & nCA > N CA if a < D < b or D <¼ a & nCA <¼ N CA
ð5Þ
if D >¼ b
With moderate congestion avoidance, we slow down the window increase speed in congestion avoidance phase and try to make the window stabilize on the optimal window W for long time with large window increase threshold N CA . Congestion avoidance and slow start are two phases in TCP protocol with different features. In congestion avoidance phase, TCP sources have estimated the bandwidth of the network and try to oscillates around the stable window. Hence the increase step should be small to avoid inducing overload of the network. In slower start phase, TCP sources have not known the network state and W may be large. If the window increases as slow as that in congestion avoidance phase, bandwidth will be wasted after random occurring timeout. Thus, window increase in slow start phase should be quicker. Different window increase threshold N s and N CA are used to reflect distinct features of the two phases. 3.4.4. W th Update In legacy Vegas, W th is set to be one half of the window when timeout occurs. This is suitable for wired networks where packet loss is caused by only buffer overflow. In wireless ad hoc networks, packets can be dropped for physical channel error or collision at MAC layer, which are not the indication of real congestion. W th should not always be halved strictly when timeout occurs. For a static wireless ad hoc network with stationary traffics, bandwidth is relatively fixed. Window increase is slow after application of Moderate congestion avoidance in Vegas-W, and large gap between W th and W will waste bandwidth. In addition, relatively large W rth compared to W is a reason for poor performance, which still exists when slower start is adopted. Thus, current W th adjustment method in legacy Vegas should be modified to be suitable for multihop ad hoc networks. W th update proposed adjusts W th tracking W . For estimating the real optimal window W is difficult, stable window is taken as W when TCP sources stabilize on it for time longer than a threshold, where the time is normalized by RTT. W th update comprises two parts: one is for W th reset when receiving a new ACK, another is for W th decrement when timeout occurs. Let nsCA denote the number of stable RTT periods on window W s in congestion avoidance phase. When D is between a and b, nsCA increases by 1, or it keeps constant. When nsCA is larger than a threshold NSCA , W th is set to the window size and nsCA is set to be 0. When current window is larger than W s , nsCA is set to be 0 and W s is set to be current window size. W th update when receiving a new ACK is shown in Fig. 6.
Fig. 6. W th update when receiving a new ACK.
Fig. 7. W th update when timeout occurs.
Let toss denote the number of consecutive timeout events with window less than W th . When toss is larger than a threshold TOss , W th decreases by 1 and toss is set to be 0. W th update when timeout occurs is shown in Fig. 7. 4. Simulation and results In this section, we evaluate Vegas-W and compare it with legacy TCP-Vegas and FeW over a wide variety of scenarios. Due to the space limit, we present the main results as follows, and more results are referred to our technical report [19].
2586
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
4.1. Simulation setup We implement our algorithm into ns-2 [20] simulator and evaluate the performance over DSR [21], which is a widely used on demand routing protocol. IEEE 802.11 [22] is set as the MAC layer protocol. Both basic rate and data rate at 802.11 MAC layer are set to be 2 Mbps. Other parameters are kept as default in ns-2. Long-lived TCP flows (of 500 s) are evaluated over chain, grid and random topologies. The receiving range is 250 m and carrier sensing range is 500 m. The wireless propagation model is the two ray ground model. The packet size is 1024 bytes. The three thresholds a, b and c are set to be 1, 3 and 1, and parameter p in slow start phase is set to be 1=8 as default. Selection of parameters in Vegas-W should consider the tradeoff between algorithm dynamics and network stabilization. Based on simulation results, we choose the value as follows. N fw for fractional window decision is set to be 2. N s and N CA for moderate window increase are set to be 10 and 100 to distinguish window increase policies in different phases. The two parameters NSCA and TOss for W th update are set to be 100 and 2, respectively. 4.2. Chain topology Chain is a common topology with limited resources and shared by different TCP flows. We examine Vegas-W algorithm over chain topology with the number of hops from 4 to 16. Different number of flows are placed on the chain to explain the distinct load. All the TCP flows are placed from the same source node to the same destination node at the edges of the chain. The number includes 1, 2, 4 and 8. The throughput of Vegas-W, TCP-Vegas and FeW over the
chain topology is shown in Fig. 8. Generally, the throughput decreases as the number of hops increases, which is different from some analytical results that the throughput is nearly constant when the number of hops is larger than 4. Theoretically, the capacity of a wireless ad hoc network is determined by the spatial reuse factor. However, the end-to-end throughput is determined by the interaction among TCP, routing and MAC protocols, wireless channel states, and techniques used on the physical layer. As the number of hops increases, the delay of controlling sending rates increases, the time occupied by the path establishment increases, the number of packets lost caused by path broken increases. Hence, the end-to-end throughput decreases although the number of hops is larger than 4. We can see that in Fig. 8, when the number of flows is 8 and network load is heavy, throughput of Vegas-W is better than that of Vegas by about 62% and better than FeW by about 22% on average. Based on above results, the optimal window W 8 for 8 flows is less than one. Fractional window support of Vegas-W extends congestion window to less than 1. W th update adjusts W rth to 1 and slows down the window increase speed. Combination of these two new mechanisms obtains high throughput gain. When the number of flows is 4 and network load is moderate, throughput of Vegas-W is better than that of Vegas by about 87% on average. The optimal window W 4 is less than and close to 1, while the initial window of legacy Vegas is 2, which induces more packets on flight than the network capacity. The modification of minimum window from 2 to 1, slower start and moderate congestion avoidance make TCP sources inject appropriate load to the network and improve the throughput.
a
b
c
d
Fig. 8. Throughput comparison of Vegas-W, Vegas and FeW over chain topology with DSR and 95% confidence interval. (a) 8 flows, (b) 4 flows, (c) 2 flows, (d) 1 flow.
2587
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
4.3. Grid topology We test Vegas-W algorithm on 7 7 grid topology with DSR, as shown in Fig. 9(a). The distance between each neighboring nodes on dash lines is 200 meters. The scenarios with 2, 8 and 14 flows are tested over this grid topology. The number of flows 2ðparallelÞ means the two traffics are placed at the central horizontal line from the same source to the same destination. When the number of flow is 2ðcrossÞ, 4 and 14, traffics are placed evenly and symmetrically with equal horizontal and vertical number of flows. The throughput of Vegas, Vegas-W and FeW is shown in Fig. 9(b). Vegas-W obtains higher throughput than Vegas especially when the number of flows is large. The percentages are 4%, 9% and 13%, respectively, when the number of flows is 2ðcrossÞ, 4 and 14. When the number of flows is 2ðparallelÞ, the throughput of Vegas-W is a little smaller than Vegas. Compared to FeW, Vegas-W obtains higher throughput than FeW by about 15% and 6%, respectively, when the number of flows is 2ðparallelÞ and 2(cross). However, when the number of flows is 4 and 14, the improvement is smaller than other two. This is because that when the number of flows. 4.4. Random topology One hundred fifty nodes are placed randomly on a 2000 M 2000 M square area, with 8, 16, 32 and 50 flows with random sources and destinations.
aA
0
1
2
3
4
5
6
1200 1000
Throughput (Kbps)
When the number of flows is 2 and network load is slightly heavy, throughput of Vegas-W is larger than Vegas about 27%. The reason is same with that in scenario with 4 flows. When the numbers of flows are 4 and 2, the throughput of Vegas-W is similar to that of FeW. This is because the optimal window is between 1 and 2, the window adjustment strategy of Vegas-W is similar to FeW. When there is only one flow over the chain and the load is light, both Vegas-W and Vegas almost obtain same throughput and the throughput of them is better than FeW by about 7%. For this scenario, W 1 is larger than W rth ¼ 2 of legacy Vegas, and TCP sources can stabilize on it in most of the time. So loss probability will be small and the system will run fluently. Separation of different window increase thresholds in slow start and congestion avoidance phases and W th update mechanisms of Vegas-W reserve this stable property of Vegas and make Vegas-W obtain close throughput. Vegas-W and TCP-Vegas with the property of stable window obtains higher throughput than FeW without this property.
F
400
0 8
16
32
50
Number of Flows Fig. 10. Throughput comparison of Vegas-W, Vegas and FeW over random topology with DSR and 95% confidence interval.
Fig. 10 shows that Vegas-W obtains higher throughput than Vegas and FeW. But the differences are not so obvious as that over chain topology. That’s because of two main reasons. One is the near-far phenomenon, which means that the throughput is dominated by the flows with small numbers of hops. Another is the uniform distribution of the positions of flows, which means that the probability there are scenarios with heavy load as in chain topology is small. Since the structure features of the random topology is not very obvious, the results here just show Vegas-W is applicable to real networks with random topologies. 5. Conclusion In this paper, we analyze the poor performance of Vegas over wireless ad hoc networks via simulation together with a unified network framework and the TCP source window model. We identify the major reasons as large minimum window, large reset slow start threshold W rth and aggressive window increase policy. We then propose a new algorithm, called Vegas-W, which considers the special features of wireless ad hoc networks and improves legacy Vegas in four aspects: fractional window support, slower start, moderate congestion avoidance and W th update, respectively. We evaluate Vegas-W through ns-2, and compare it with legacy Vegas and FeW with DSR over a wide range of topologies with different network load. The simulation results show that Vegas-W obtains higher throughput than Vegas up to 87% and than FeW up to 22%.
400
Throughput (Kbps)
E
600
b
B
D
800
200
450
C
Vegas Vegas-W FeW
Vegas Vegas-W FeW
350 300 250 200 150 100 50 0 2(prallel)
G
2(cross)
41
4
Number of Flows
Fig. 9. Grid topology and throughput comparison of Vegas-W, Vegas and FeW over grid topology with DSR and 95% confidence interval. (a) Grid topology. (b) Throughput comparison.
2588
L. Ding et al. / Computer Communications 31 (2008) 2581–2588
How to set up a more comprehensive mathematic model and analyze the interactions between TCP sources and network, and the interactions between TCP, routing and MAC protocols over multihop wireless circumstances are left as the future work. Acknowledgments We appreciate the anonymous reviewers’ constructive and valuable suggestions. This work is supported by the National Natural Science Foundation of China under the grant (No. 60625103, 60702046), and Science and Technology Commission of Shanghai Municipality (STCSM) under the Grant No. 05DZ22102; China Ministry of Education (No. 20070248095); Shanghai Jiaotong University Young Faculty Funding (No. 06ZBX800050); Shanghai Jiaotong University Pre-Research Funding; Qualcom China Research Grant. References [1] G. Holland, N. Vaidya, Analysis of tcp performance over mobile ad hoc networks, in: Proceedings of the IEEE/ACM MOBICOM, August 1999. [2] K. Nahm, A. Helmy, C.-C. Jay Kuo, TCP over multihop 802.11 networks: issues and performance enhancement, in: Proceedings of the ACM MobiHoc, UrbanaChampaign, IL, USA, May 2005. [3] Z. Fu, P. Zerfos, H. Luo, S. Lu, L. Zhang, M. Gerla, The impact of multihop wireless channel on tcp throughput and loss, in: Proceedings of the IEEE INFOCOM, San Francisco, USA, March 2003. [4] K. Xu, M. Gerla, L. Qi, Y. Shu, Enhancing tcp fairness in ad hoc wireless networks using neighborhood red, in: Proceedings of the MobiCom, San Diego, California, USA, September 2003. [5] Z. Fu, X. Meng, S. Lu, How bad tcp can perform in mobile ad hoc networks, in: IEEE International Symposium on Computers and Communications (ISCC’02), Taormina, Italy, July 2002. [6] K. Chandran, S. Raghunathan, S. Venkatesan, R. Prakash, A feedback-based scheme for improving TCP performance in ad hoc wireless networks, in: IEEE Pacific-Rim Conference on Multimedia, vol. 8, no. 1, February 2001.
[7] H. Zhai, X. Chen, Y. Fang, Rate-based transport control for mobile ad hoc networks, in: Proceedings of the IEEE WCNC, New Orleans, LA USA, March 2005. [8] S. Floyd, T. Henderson, RFC2582: the NewReno modification to TCP’s fast recovery algorithm, April 1999. [9] L.S. Brakmo, S.W. O’Malley, L.L. Peterson, TCP vegas: new techniques for congestion detection and avoidance, in: Proceedings of the ACM SIGCOMM, October 1994. [10] M. Yahia, J. Bíró, Behavior of TCP algorithms on ad-hoc networks based on different routing protocols (MANETS) and propagation models, in: Proceedings of the ICWMC, Bucharest, Romania, July 2006. [11] M. Berger, S. Lima, A. Manoussakis, J. Pulgarin, B. Sanchez, A performance comparison of TCP protocols over mobile ad hoc wireless networks, in: Proceedings of the CERMA, Cuernavaca, Mexico, December 2006. [12] A. Wierman, T. Osogami, Jörgen Olsén, A unified framework for modeling TCPVegas, TCP-SACK, and TCP-Reno, in: Proceedings of the MASCOTS, Orlando, FL, USA, October 2003. [13] T.D. Dyer, R.V. Boppana, A comparison of TCP performance over three routing protocols for mobile ad hoc netwoks, in: Proceedings of the ACM MobiHoc, October 2001. [14] F. Wang, Y. Zhang, Improving TCP performance over mobile ad-hoc networks with out-of-order detection and response, in: Proceedings of the ACM MobiHoc, Lausanne, Switzerland, June 2002. [15] H. Zhai, Y. Fang, Distributed flow control and medium access in multihop ad hoc networks, IEEE Trans. Mobile Comput. 5 (11) (2006) 1503–1514. [16] K. Chen, Y. Xue, K. Nahrstedt, On setting TCP’s congestion window limit in mobile ad hoc network, in: Proceedings of the IEEE ICC, Anchorage, Alaska, May 2003. [17] S. Floyd, V. Jacobson, Random early detection gateways for congestion avoidance, IEEE/ACM Trans. Netw. 1 (4) (1993). August. [18] J. Li, C. Blake, D.S.J. De Couto, H.I. Lee, R. Morris, Capacity of ad hoc wireless networks, in: Proceedings of MobiCom, Rome, Italy, July 2001. [19] L. Ding, X. Wang, Y. Xu, W. Zhang, Y. Liu, Improve throughput of TCP-Vegas in multihop ad hoc networks, Department of Electronic Engineering, Shanghai Jiaotong University, China, Technical Report, 2007. Available from: