TCP, XCP and RCP in Wireless Mesh Networks: An Evaluation ... - IPVC

TCP, XCP and RCP in Wireless Mesh Networks: An Evaluation Study Lu´ıs Barreto

Susana Sargento

Escola Superior de Ciˆencias Empresariais, Instituto Polit´ecnico de Viana do Castelo Av. Miguel Dantas, 4930 Valenc¸a, Portugal Email: [email protected]

Instituto de Telecomunicac¸o˜ es, Universidade de Aveiro Campus de Santiago, 3810-193 Aveiro, Portugal Email: [email protected]

Abstract—TCP is the most widely used congestion protocol in the Internet. However, TCP has some limitations, even in the wired world, such as not providing high utilizations in high bandwidth-delay product networks, and introducing high load and overhead in the network. Due to these limitations, several congestion protocols have been proposed. Some of the most known and recent protocols developed to provide faster and lighter congestion control are eXplicit Control Protocol (XCP) and Rate Control Protocol (RCP). These protocols have been proposed essentially to work in wired networks and environments; however, there are already new versions of XCP for wireless networks. Since these protocols have a large acceptation on the research field, and simultaneously, Wireless mesh networks (WMN) are in undergoing rapid progress, it is important to evaluate how XCP and RCP behave in these networks, as compared to TCP. This paper presents an evaluation study of TCP, XCP and RCP in WMNs, studying different WMN scenarios. Surprisingly, the results show that TCP is more efficient in mesh scenarios, being more fair and stable than XCP and RCP. To obtain the available network capacity, both XCP and RCP need that all nodes in the network cooperate, which increases network overhead, and reduces performance and fairness. Moreover, their capacity evaluation is not accurate in wireless networks. Index Terms—Congestion protocols, wireless networks, mesh networks, TCP, XCP, RCP, evaluation.

I. I NTRODUCTION The use of wireless networks has increased significantly in the past years. Wireless networks are more flexible, easy to deploy and scalable than traditional wired networks. However, they use air as the access media, which, being a shared medium, is more sensitive to interferences and to congestion. The developed congestion protocols do not take into account the problems and particularities of wireless networks. The Transmission Control Protocol (TCP) [1], the most widely used congestion protocol in the Internet, was developed for wired networks. TCP uses the The Van Jacobson [2] congestion control algorithms, which have been highly successful over many orders of magnitude of Internet bandwidth and delay. However, with the increase of computer networks, the high internet demand and the proliferation of wireless networks, TCP became unsuitable for highly dynamic environments (where nodes move around quickly and node participation and departure occurs frequently). Some of these performance problems led to the development of new congestion control protocols.

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

The eXplicit Control Protocol (XCP) [3] and the Rate Control Protocol (RCP) [4] are two of the most recent ones. They rely in network interaction for congestion control improvement, since they need intermediate nodes, such as routers, to work and interact to support the congestion control. In wired networks they increase efficiency in the congestion control. However, these protocols were developed taking only in consideration the characteristics of wired networks. Their efficiency relies in some of the wired network features that are different, or are not present, in wireless networks and particularly in wireless mesh networks. Wireless mesh networks (WMN) are in undergoing rapid progress, since they are dynamic and easy to deploy [5]. WMNs are comprised of two types of nodes: mesh routers and mesh clients. Other than the routing capability for gateway/bridge functions as in a conventional wireless router, a mesh router contains additional routing functions to support mesh networking. Although conventional wireless networks and WMN are built based on the same principles and similar hardware and software platforms, WMN increase and add many technical issues in congestion control, due, specially, to the fact that correspondent mesh clients are constantly moving and changing information with mesh routers. In this paper we present a performance study of TCP, XCP and RCP in WMNs. Our study is based on the results obtained by a set of simulations under ns-2 [6] in different scenarios, chain and mesh networks, fixed and mobile. The presented scenarios are not complex, but are sufficient to draw important conclusions: between these protocols, TCP is the one that behaves with higher stability, and with better results both in terms of throughput, delay and received packets rate. These results confirm that much work is still required to provide an efficient congestion protocol for WMNs: in order to increase accuracy in XCP and RCP, it is required to provide accurate mechanisms to efficiently evaluate the available bandwidth in these networks and decrease nodes communication overhead. The paper is organized as follows. Next section, section II, briefly presents the congestion control protocols to be evaluated and, also, some of the congestion control mechanisms specifically defined for WMNs. This section ends with the main reasons for choosing the evaluated protocols. Then, section III provides the evaluation study and describes the

351

obtained results, giving directions for future protocol enhancements. Finally, section IV presents the conclusions and future work. II. C ONGESTION C ONTROL P ROTOCOLS

Delta1

Delta1

Sender

Receiver

A. Transmission Control Protocol - TCP TCP is the most used congestion control protocol in computer networks. TCP uses the Additive Increase Multiplicative Decrease (AIMD) algorithm and the slow-start mechanism. It is able to also provide TCP congestion avoidance and recovery. Due to its AIMD strategy, TCP is known to have some limitations: unstable throughput, increased queueing delay, limited fairness. It is also worth to mention that it was developed in the early 1980s, and today’s application demands and network topologies differ greatly from the networks of that time. TCP and other congestion protocols assume that, in its operation and with today’s network improvements, the probability of a lost packet is higher than the one of a corrupted packet [7]. It must be noticed that such a corollary is not true in wireless networks. In a wireless network, packet loss is typically due to: wireless channel impairments causing bit errors, handoffs due to mobility and, of course, possibly congestion. TCP assumes that a packet loss is due to congestion in the network and, but not very often, packet reordering. As TCP mechanisms do not respond well to packet loss due to bit errors and handoffs, TCP-based applications suffer of poor performance. When a signal strength weakness or noise is inferred in a wireless network, burst errors can occur. This means that more than one packet will be lost and TCP will detect it as a timeout, resuming to the slow-start strategy, and reducing significantly network performance. Usually, in a wireless network, delay is very high when compared to a wired network, which causes very long and variable RTT times making TCP’s timeout mechanism not working well and leading to exacerbated linklevel retransmissions. Wireless networks also have, typically, asymmetric links, where the ACK link is slower than the data transmission link. This is very important in TCP as delayed ACKs can, and will, limit throughput in the fast link. B. eXplicit Congestion Protocol - XCP XCP was designed to extract congestion information directly from routers. According to [8], ”XCP achieves fairness, maximum link utilization and efficient use of bandwidth”. XCP is also scalable, as per-flow congestion state is carried in packets. However, XCP has its disadvantages: it is more difficult to deploy, since changes need to be made in all routers and end-systems in the network. A XCP network is composed of XCP sender hosts, receiver hosts and intermediate nodes where queuing from the sender to the receiver occurs. The intermediate nodes are usually routers, but, with the networking equipment developments, they can also be link-layer switches containing packet queues. XCP uses a feedback mechanism to inform the sender about the best network conditions, that is, the maximum throughput. This feedback is accomplished by the use of a congestion header

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

Delta2

Feedback: Delta2

Figure 1.

XCP operation.

in each packet sent. Along the path, intermediate nodes update the congestion header. When the packet reaches the receiver, it copies the network information, obtained from the last intermediate router, into outbound packets of the same flow (normally acknowledgment packets). The congestion header contains the following information: senders round-trip time (RTT) current estimation; senders current throughput or sending rate; delta throughput which is the network’s allocated change in throughput, calculated and updated by the routers; reverse feedback, which is the delta throughput of a packet that reaches the receiver - this value is returned to the sender, for example, in an acknowledgment packet. Bottleneck routers are the only ones that calculate re-allocation capacity for a specific flow. A bottleneck router in XCP is a router that has insufficient capacity to accept a flow’s desired or current throughput. Figure 1 shows a basic XCP system. The sender tries to increase the current congestion window by Delta1, it signals this request in the XCP congestion header. The next router in the path analyzes and forwards the packet to the other router. Since there is enough capacity to deal with the request, the router does not modify the header. The following router considers that Delta1 increase is excessive and modifies the congestion header, replacing Delta1 with Delta2, the maximum allowed throughput change for this particular flow, where Delta2 is smaller than Delta1. The receiver copies Delta2 and returns it to the sender as feedback, and then, the sender proceeds to adjust its congestion window. In this case, the second router is considered the bottleneck in the path. The calculation of the bandwidth adjustment required to a certain XCP flow is performed by two algorithms: the efficiency algorithm, and the bandwidth allocation algorithm. The efficiency algorithm periodically (every T seconds) calculates the amount of bandwidth AB that will be distributed among all flows during the next T seconds: q (1) T where C is the capacity of the link, input bw is the bandwidth actually used during the last period T , and q is the persistent queue or, in other words, the minimum queue length observed during the last T seconds. T is usually set to be the average RTT of the flows traversing this queue; α and β are constants. Due to capacity errors in shared-access media, such as 802.11, some modifications to the calculation of AB were proposed in XCP-b(blind) [9]. In XCP-b, the spare bandwidth AB = α · (C − input bw) − β ·

352

is measured from variations of the persistent queue. This, of course, is an important drawback as the queue controller can only effectively measure queue variations when the medium is being fully utilized. This means that the system must be taken, somehow, to full utilization. XCP-b is more resource and time consuming, not being a very good option in very large deployments. C. Rate Control Protocol - RCP The Rate Control Protocol (RCP) is part of the 100x100 clean state project [10]. The mission of this project is to create blueprints for a network that goes beyond today’s Internet [10]. RCP, similarly to XCP, is a congestion control algorithm. The main goal of RCP is to deliver fast flow-completion times or download times. RCP was also designed having in mind typical flows of typical users in today’s Internet. RCP aims to improve web users flows, distributed computing and distributed file-systems, decreasing their transfer trime. RCP uses the same feedback principle of XCP and tries to emulate a processor sharing. However, it uses a different approach. Routers along the path do not determine incremental changes to the end-system’s throughput, but determine the available capacity and the rate at which the end-system should operate. Figure 2 shows a basic RCP system. In the beginning of the operation, the sender sets the desired rate with an infinite value. The next router calculates the available rate and overwrites the rate value in the congestion header. This value is then compared by the final router. If the value is smaller then the available rate, the router does not change the value in the congestion header. The rate value, in the congestion header, is only updated if the available rate has a smaller value. Finally, the receiver feedbacks the rate value in the acknowledgement packet. If the flow lasts longer than one RTT, the subsequent rates are piggy-backed on the data and acknowledgment packets. To determine the available rate, RCP relies on the router information. If that information is correct and if there are no delays between the link and the source, the available rate is simply: C (2) R (t) = N (t) where R (t) is the given rate out of the flows, N (t) the number of ongoing flows and C is the link capacity. However, as there is feedback delay and it is difficult to know NC(t) , an adaptive algorithm is used that updates the rate assigned to the flows, allowing to simulate processor sharing in the presence of feedback delay and not knowing the number of flows. For this processor sharing approximation, RCP determines the available rate by: h R (t) = R (t − d0 ) +

α · (C − y (t)) − β · ˆ (t) N

q(t) d0

i (3)

where d0 is a moving average of the RTT measured across all flows, R (t − d0 ) is the last updated rate, C is the link capacity,

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

Desired Rate

Available Rate

Sender

Available Rate

Receiver Feedback: Available Rate

Figure 2.

RCP operation.

y (t) is the measured input traffic rate during the last update interval (d0 in this case), q (t) is the instantaneous queue size, ˆ (t) is the router’s estimate of the number of ongoing flows N (i.e., number of flows actively sending traffic) at time t, and α, β are parameters chosen for stability and performance. RCP is particularly well suited for bursty traffic: since bandwidth allocation is instantaneous, small transfer such as web pages take less time to be transmitted with RCP than using TCP or XCP. Such dynamic behavior, however, comes at the cost of increased jitter, as queues oscillate to compensate the variation of flows over the network. D. Congestion control for WMNs New and specific congestion control procedures and mechanisms in WMNs have been defined. Some of these congestion control mechanisms, although not developed on purpose for WMNs, try to enhance TCP behavior in WMNs. Mechanisms like TCP-F [11], TCP-ELFN [12], TCP-BuS [13], ATCP [14] represent some examples of protocols for wireless networks. ATP [15] concentrates in TCP performance issues in adhoc networks with no link-failure induced losses. ATP is a rate based congestion control mechanism using explicit rate feedback to network sources. Although this mechanism does not explicitly define the need of congestion detection and signaling, its metric implicitly needs to use some congestion into account. More recent research has recognized the importance of explicitly detect and signal congestion over a network. One example of such research is Explicit Wireless Congestion Control Protocol (EWCCP) [16]. This mechanism identifies the set of flows that share the channel capacity with flows passing through a congested node. EWCCP assumes that the achievable rate region of 802.11 is convex, thus being proportionally fair. It must be referred that EWCCP has not been yet tested in a real implementation. E. Discussion Many efforts have been done to improve, in wired and wireless networks, TCP behavior. XCP is one of the most well known mechanisms, widely recognized as being a major advance in Internet congestion. XCP tries to achieve maximum link utilization and tries to deliver a zero bandwidth waste due to packet losses. RCP is a novel, also considered the state of the art on congestion control algorithm, designed to be more efficient than XCP. RCP was designed having in consideration typical flows of typical network users. Both XCP and RCP were designed having only in consideration wired links, and,

353

due to their popularity, it is of extreme importance to know their behavior when a WMN is present and compare with the most used network congestion protocol, TCP. From the mechanisms proposed especially for wireless networks, all have some drawbacks that need to be dealt with. Moreover, in mobile scenarios, mobile nodes may be attached to different types of networks along the time. A mechanism specially designed for WMNs is not efficient in other types of networks, and interoperability problems are in place. As TCP is still the most used congestion protocol, in wireless and wired environments, and as XCP and RCP were designed to improve TCP performance and behavior, it is of extreme importance to know, and understand, how XCP and RCP behave in a dynamic and wireless environment. Both XCP and RCP have not yet been widely studied in Wireless Mesh Networks, and their behavior is still not well documented in such type of networks. Therefore, we decided to use TCP, XCP and RCP for this evaluation, and to not evaluate mechanisms especially proposed for wireless networks. Thus, allowing us to find future directions for defining a new congestion control mechanism able to operate efficiently in WMNs and completely interoperable with the ones of wired networks.

BS

node_0

node_1

node_2

Figure 3.

node_3

node_4

Chain topology.

Mobile_0

Mesh_0

Mesh_3

Mobile_1

Mobile_4

Mesh_4

Mobile_3

Mesh_2

Mesh_1

Mobile_2

III. E VALUATION This section presents the results, obtained with ns-2 simulations. We evaluate throughput, average delay and average number of received packets for TCP, XCP and RCP in different scenarios with and without mobility. These metrics represent extremely important fundamental performance characteristics to conclude on the behavior of these congestion protocols in WMNs. A. Simulation Scenarios In the simulations we used two different scenarios, one with a base station and fixed communicating nodes (Figure 3 - chain topology) and various mesh topologies scenarios. The mesh topologies defined were: a grid of 5, 9, 12 and 16 fixed mesh nodes. In all mesh topologies, it was used a combination of 3, 4, 5, 6 and 7 mobile nodes. Figure 4 represents a mesh topology of 5 mesh nodes and 5 mobile nodes. In the chain topology, all nodes are sources and sinks, and they all communicate with each other; they were separated by a distance of 200 meters between each other. In the mesh scenarios only the mobiles nodes were sources and sinks. The routing protocol used is the Destination-Sequence DistanceVector (DSDV) [17]. All simulations last 300 seconds and no control packets (RTS/CTS) are used. The configured default transmission range is 250 meters, the default interference range is 500 meters, and the channel data rate is 11 Mbps. For the data transmissions, it is configured an FTP application with packets of 1440 bytes. In the mobility scenarios, the ns-2 setdest tool is used. This tools generates a random node movement pattern. We configure setdest with a minimum speed of 10

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

Figure 4.

Topology 5 Mesh Nodes - 5 Mobile Nodes.

m/s, a maximum speed of 30 m/s and a topology boundary of 800x800 meters. All results were obtained from ns-2 trace files, with the help of trace2stats scripts [18] adapted to our own needs. In the next sub-section we present, analyze and compare the chain and the mesh topology results. Section III-C presents the detailed mesh topology results, and section III-D presents future directions to build an efficient congestion control protocol. B. Chain vs Mesh Topology This section compares the results of both chain and mesh topologies. The instant throughput results obtained for the chain topology are illustrated in Figure 5. These results show that RCP has the best performance; however, it must be noticed that it is obtained with less packets sent and received. The worst performance is the one of XCP. In this scenario, RCP is less dependent from network interaction than XCP. We also observe that TCP has a more stable and efficient behavior, noted by the throughput distribution. For scenario comparison purposes, we present throughput results for a flow in a mesh topology with 5 mesh and 5 mobile nodes. As illustrated in Figure 6, TCP uses more efficiently the medium for data transmissions, allowing more transmissions within the time range. These considerations reflect the fairness behavior of TCP, which is larger in this particular situation, than the one of XCP and RCP.

354

10000

C. Mesh Topology Scenarios

Throughput (Kbps)

1000

100

10

1

0.1

0

10

20

30 TCP

Figure 5.

40 50 Time (s) XCP

60

70

80

90

RCP

Chain Topology, node 0 to node 2 Throughput.

10000

1000

Throughput (Kbps)

100

10

1

0.1

0.01

0

50

100 TCP

150 Time (s) XCP

200

250

300

RCP

Figure 6. 5 Mesh Nodes - 5 Mobile Nodes Topology, node 0 to node 2 Throughput.

Another important consideration is the fact that in the chain topology there is a Base Station (BS) to manage the communications. The BS manages all link reservations and the queue length, acting as a router, thus allowing XCP and RCP to have a more stable behavior. In a mesh network, the mesh routers are not responsible for link reservation; this is self managed by mesh nodes. This greedy process of management of queues length, when compared to a BS, results in the introduction of latency and lost packets, making XCP and RCP losing important feedback information, behaving poorly in these situations. XCP and RCP rely in cross layer information for an effective congestion control. As said before, mesh routers are not specially concerned in retrieving this information to end-toend nodes. Their main function is to keep a routing path alive, generating several routing messages. These messages increase the link load, resulting in queues overfilled and increased collisions. As TCP does not rely in feedback information, its mechanisms work normally under these situations, while XCP and RCP, without reliable feedback information, have a significant degradation in their congestion control evaluation.

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

This section presents different scenarios of mesh topologies, with different number of fixed and mobile nodes. This topology is chosen for a deeper evaluation due to its higher dynamicity. In this section we present throughput, delay and the number of received packets, through their mean value and 95% confidence interval, and varying both number of fixed and mobile nodes. Figure 7, Figure 8 and Figure 9 show the previously referred performance metrics for scenarios with 16 mesh nodes and a variable number of mobile nodes (from 3 to 7 mobile nodes). Figure 10, Figure 11 and Figure 12 show the same results for scenarios with a fixed number of 7 mobile nodes and a variable number of mesh nodes (5, 9, 12 and 16 mesh nodes). The obtained results show that TCP has a very regular and fair behavior, while RCP and XCP are less efficient, less fair and sometimes show a very erratic and irregular behavior. Although while regarding throughput, the conclusion of more efficiency is not very clear from the delay and number of received packets, TCP has a very clear and improved performance when compared with both XCP and RCP. As previously mentioned, it is possible to outperform fairness with throughput and bandwidth allocation. Thus, combining Figure 7 with Figure 8, and combining Figure 10 with 11, it is possible to conclude that TCP is much more fair than XCP and RCP (better delay and throughput results), allowing more flows to be involved in the transmission process. Figure 9 and Figure 12 are very relevant, as they show that, with TCP, there are fewer packet losses. This is clearly due to TCP operation and its AIMD strategy. As XCP and RCP need, to operate, that all nodes in the network exchange information, the number of collisions increases, leading to higher losses. The irregular behavior of XCP and RCP is also the result of an incorrect evaluation of the available link capacity, channel utilization and channel losses (considering a loss as a packet loss and not a packet corruption or interference), making the nodes to use, incorrectly, the maximum configured capacity and using incorrectly the transmission medium. By the observation of the previous figures, it is also possible to notice that RCP and XCP have good throughput values, but these values are directly related to less sent and received packets and to worse delay values. It is evident that in the mesh topologies, where routing messages are exchanged between network participants, XCP and RCP are more unstable, less efficient and less fair than TCP. D. Future Directions The study presented in this paper clearly and surprisingly shows that TCP has a better behavior than XCP and RCP. However, we know that TCP is not a good congestion control protocol for these networks: TCP is also not suitable for these environments, since it does not behave correctly when there are losses due to weak signal strength or interference. One of the XCP and RCP problems is the wrong inference of

355

1000

Throughput(Kbps)

Throughput(Kbps)

1000

100

10

3

3.5

4

4.5 5 5.5 Number of Mobile Nodes

6

XCP Avg. Throughput

TCP Avg. Throughput

6.5

10

7

4

RCP Avg. Throughput

6

8

10 Number of Mesh Nodes

14

16

RCP Avg. Throughput

Figure 10. Average Throughput Statistics - 7 Mobile Nodes, Variable Number of Mesh Nodes. 100000

10000

10000 Delay (ms)

100000

Delay (ms)

12

XCP Avg. Throughput

TCP Avg. Throughput

Figure 7. Average Throughput Statistics - 16 Mesh Nodes, Variable Number of Mobile Nodes.

1000

100

1000

3

3.5

4

TCP Avg. Delay

4.5 5 5.5 Number of Mobile Nodes XCP Avg. Delay

6

6.5

100

7

RCP Avg. Delay

6

8

10 Number of Mesh Nodes XCP Avg. Delay

12

14

16

RCP Avg. Delay

Figure 11. Average Delay Statistics - 7 Mobile Nodes, Variable Number of Mesh Nodes. 10000

Number of Packets

100000

10000

1000

4

TCP Avg. Delay

Figure 8. Average Delay Statistics - 16 Mesh Nodes, Variable Number of Mobile Nodes.

Number of Packets

100

3

3.5

4

4.5 5 5.5 Number of Mobile Nodes

TCP Avg. Recv. Packets XCP Avg. Recv. Packets

6

6.5

7

RCP Recv. Packets

1000

4

6

8

10 Number of Mesh Nodes

TCP Avg. Recv. Packets XCP Avg. Recv. Packets

12

14

16

RCP Avg. Recv. Packets

Figure 9. Average Received Packets Statistics - 16 Mesh Nodes, Variable Number of Mobile Nodes.

Figure 12. Average Received Packets Statistics - 7 Mobile Nodes, Variable Number of Mesh Nodes.

available bandwidth in wireless (and also mesh) networks. For this purpose, cross layer communication may help: MAC layer can use and be a source of good available rate planning and decision to improve the calculation of the available bandwidth

of the channel. One possible information is the one obtained by the Network Allocation Vector (NAV). As referred by [19], the NAV is a timer that indicates the amount of time the medium will be reserved. This important information combined, for

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

356

example, with the times provided by RTS/CTS packets and/or probing packets, can be very important to improve the congestion protocol performance. This cross-layer communication mechanism would, then, allow the congestion protocol to decide if it would increase or decrease rate communication, improving throughput and fairness as bandwidth allocation would also be improved. Another problem observed in the evaluation was the lack of feedback information in these transport protocols. Mesh routers interaction keeping track of feedback information, using for example routing protocol messages for validating feedback information, would, surely, improve XCP- and RCPlike protocols performance in WMNs. Another point to have in consideration, regarding this aspect, is that the correct determination of the available bandwidth implies the correct definition of the network achievable capacity, thus queues in all nodes need to be small, leading to more precise feedback information with better channel utilization. IV. C ONCLUSIONS AND F UTURE W ORK This paper presented a performance and fairness evaluation study, in wireless mesh networks, of the most popular congestion control protocol, TCP, against new congestion control techniques, namely XCP and RCP, that use network interaction for rate adaptation. Different strategies were used for the evaluation. Initially, a static network was used, and then different mesh topologies with both fixed and mobile nodes were tested. Our results show that TCP is more efficient than XCP and RCP in mesh scenarios. TCP is more fair and stable than XCP and RCP. This is due to the AIMD strategy of TCP. XCP is the less efficient protocol, as it increases delay in the communications. To obtain the available network capacity, both XCP and RCP need that all nodes in the network cooperate, which increases network overhead, specially when dealing with wireless mesh networks. Moreover, TCP, RCP and XCP are not taking into consideration losses due to interference or weak signal strength; this is more relevant in XCP and RCP as they need to evaluate the available capacity. Finally, the nodes in XCP and RCP are not evaluating precisely network capacity, thus leading to a poor network performance. We believe that new techniques for congestion control can be developed and can increase congestion control performance. We are currently studying and applying new congestion control techniques to these control protocols, making use of cross-layer information and techniques to provide accurate mechanisms to evaluate the available bandwidth in dynamic networks, as it is the case of WMNs.

[5] I. F. Akyildiz and X. Wang, “A survey on wireless mesh networks,” IEEE Radio Communications, September 2005. [6] “The network simulator - ns-2,” Information Sciences Institute, 2001. [Online]. Available: http://www.isi.edu/nsnam/ns/ [7] B. A. Fourouzan, TCP/IP Protocol Suite, 2nd ed. McGraw-Hill Higher Education, 2002. [8] A. Falk and D. Katabi, Specification for the Explicit Control Protocol (XCP), draft-falk-xcp-spec-03.txt, Information Sciences Institute Internet-Draft. [Online]. Available: http://www.isi.edu/isixcp/docs/draftfalk-xcp-spec-00.html [9] F. Abrantes and M. Ricardo, “A simulation study of XCP-b performance in wireless multi-hop networks,” ACM workshop on QoS and security for wireless and mobile networks, 2007. [10] “100x100 clean state project.” [Online]. Available: http://100x100network.org/ [11] K. Chandran, S. Raghunathan, S. Venkatesan, and R. Prakash, “A feedback based scheme for improving TCP performance in ad-hoc wireless networks,” in IEEE ICDCS, 1998. [12] G. Holland and N. Vaidya, “Analysis of TCP performance over mobile ad hoc networks,” in Wireless Networks, 2002. [13] D. Kim, C.-K. Toh, and Y. Choi, “TCP-BuS: Improving TCP performance in wireless ad hoc networks,” in Journal Of Communications And Networks, 2001. [14] J. L. Sun and S. Singh, “ATCP: TCP for mobile ad hoc networks,” 1999. [15] K. Sundaresan, V. Anantharaman, H. yun Hsieh, and R. Sivakumar, “ATP: A reliable transport protocol for ad hoc networks,” IEEE Transactions on Mobile Computing, 2005. [16] K. Tan, F. Jiang, Q. Zhang, and X. Shen, “Congestion control in multihop wireless networks,” IEEE Transactions on Vehicular Technology, 2006. [17] C. E. Perkins and P. Bhagwat, “Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers,” ACM SIGCOMM, 1994. [18] M. Fiore, “trace2stats.” [Online]. Available: http://www.tlcnetworks.polito.it/fiore/index.html [19] M. S. Gast, 802.11 Wireless Networks - The Definitive Guide, 4th ed. O’reilly, 2002.

R EFERENCES [1] J. Postel, “Transmission control protocol,” RFC 793, Defense Advanced Research Projects Agency. [2] V. Jacobson and M. J. Karels, “Congestion avoidance and control,” ACM SIGCOMM Computer Communication Review, August 1988. [3] D. Katabi, M. Handley, and C. Rohrs, “Congestion control for high bandwidth-delay product networks,” ACM SIGCOMM, August 2002. [4] N. Dukkipati and N. McKeown, “Why flow-completion time is the right metric for congestion control,” ACM SIGCOMM, 2006.

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

357