# XCP-Winf and RCP-Winf: Improving Explicit Wireless Congestion Control

Authors: Luís Barreto
Journal: Journal of Computer Networks and Communications
 (2015)

---

## Abstract

Congestion control in wireless networks is strongly dependent on the dynamics and instability of wireless links. Therefore, it is very difficult to accurately evaluate the characteristics of the wireless links. It is known that TCP experiences serious performance degradation problems in wireless networks. Moreover, congestion control mechanisms that rely on network interaction and network parameters, such as XCP and RCP, do not evaluate accurately the capacity and available link bandwidth in wireless networks. In this paper we propose new explicit flow control protocols for wireless mesh networks, based on XCP and RCP. We name these protocols XCP-Winf and RCP-Winf. They rely on the MAC layer information gathered by a new method to accurately estimate the available bandwidth and the path capacity over a wireless network path. The estimation is performed in real time and without the need to intrusively inject packets in the network. These new congestion control mechanisms are evaluated in different scenarios in wireless mesh and ad hoc networks and compared against several new approaches for wireless congestion control. It is shown that both XCP-Winf and RCP-Winf outperform the evaluated approaches, showing its stable behavior and better channel utilization.


---

## Body

## 1. Introduction

Reliable transport protocols such as TCP were developed to perform well in traditional wired networks where packet losses occur mostly because of congestion [1]. However, networks with wireless and other lossy links also suffer from significant losses due to bit errors and handoffs. TCP responds to the losses by invoking congestion control and avoidance algorithms. This results in degraded end-to-end performance in wireless systems and networks [2].Recent efforts to design better congestion control have led to the origin of several explicit-feedback congestion control methods. These methods solicit active multibyte feedback from the routers to the end-hosts, delivering a precise and timely congestion signal that is used to accurately adjust flow sending rates. Therefore, they aim to achieve faster convergence, smaller packet loss rate, high link utilization, and better fairness between flows. Examples of these congestion control mechanisms that rely on network interaction are the explicit control protocol (XCP) [3] and the rate control protocol (RCP) [4]. Their main purpose is to generalize explicit congestion notification, where nodes inform each other about the degree of congestion. XCP decouples channel utilization from fairness control and requires the efficient estimation of the aggregate traffic behavior, that is, both available bandwidth and link capacity. RCP is a congestion control algorithm whose main key is to finish the flows as fast as possible. RCP dynamically updates the rate assigned to the flows, approximating a processor sharing in the presence of feedback. Although the support of explicit congestion control and network interaction is expected to lead to a more efficient congestion control in shared medium systems, such as wireless mesh and ad hoc networks, we have shown in [5] that this is not the case, since they are incapable of predicting effectively capacity in wireless networks, and also that they are not efficient and fair. This is due to the fact that the available capacity at a wireless link depends on the link rates at the neighboring edges. Ignoring this dependence will overestimate the available capacity and lead to poor performance and to instability. We believe that estimating the exact capacity of a link as a function of the link rates at the neighboring edges would provide accurate XCP- and RCP-like scheme to be implemented for wireless multihop networks.To support efficiency and stability of wireless networks, it is crucial to develop a congestion control scheme which provides efficient and accurate sharing of the underlying network capacity among multiple competing applications. Factors such as handoffs, channel allocation, and channel quality are directly related to link capacity. Being able to accurately monitor link capacity and available bandwidth and then use that information to perform accurate congestion control is a main challenge in wireless communications. In [6] we proposed thert-Winf algorithm, which is a new wireless inference mechanism, based onIdleGap [7], that is able to estimate available bandwidth and path capacity.rt-Winf uses the information included in RTS/CTS packets to measure the transmission time and obtain the link capacity and available bandwidth.In this paper we describe XCP-Winf and RCP-Winf, two new congestion control mechanisms based, respectively, on XCP and RCP, that are extended with the support of an accurate capacity and available bandwidth computation algorithm. The link capacity and available bandwidth obtained throughrt-Winf are transmitted, through cross layer techniques, to XCP and RCP that use that information in their native congestion control techniques. We show how new XCP-Winf and RCP-Winf functions can be built with this new information. The proposed congestion control approaches are evaluated in different simulated scenarios, mesh and ad hoc, and are evaluated against state-of-the-art congestion control mechanisms. The obtained results show that the integration ofrt-Winf allows clear improvement of XCP and RCP network performance against standard congestion control protocols and also against specific congestion protocols for wireless environments.In [8] we presented a base version of both XCP-Winf and RCP-Winf with preliminary results. In this paper we present a complete proposal: (1) we present thert-Winf approach with an evaluation through simulation and emulation in CMU wireless emulator [9]; (2) we describe and refine the conceptual approach of both XCP-Winf and RCP-Winf, with a new mathematical model; (3) we perform a complete evaluation of the congestion control approaches compared against state-of-the-art approaches such as XCP-b [10] and TCP-AP (TCP with adaptive pacing) [11]; (4) we complete the evaluation with the assessment of both XCP-Winf and RCP-Winf in terms of TCP-friendliness.The remaining of this paper is organized as follows. Next section, Section2, briefly presents the background and related work. Then, Section 3 describes thert-Winf algorithm andrt-Winf obtained results. In Section 4, howrt-Winf is integrated within both XCP and RCP is presented. Section 5 describes and discusses the results obtained through simulation, using mesh and ad hoc scenarios with different characteristics. Finally, Section 6 presents the conclusions and future work.


## 2. Related Work

### 2.1. Capacity and Available Bandwidth Estimation

AdHoc Probe [12],WBest [13],TSProbe [14], andIdleGap [7] are some examples of link estimation mechanisms for wireless networks. WhileWBest calculates both capacity and available bandwidth,AdHoc Probe provides only the path capacity of the wireless channel. However,WBest is known to be very intrusive when estimating the available bandwidth.TSProbe [14] is a new capacity estimation tool based onAdHoc Probe, but it is focused on time-slotted connections such as bluetooth or WIMAX.TSProbe uses the interaction between several link layer properties to deploy an adaptive probing scheme that utilizes payloads that vary in size. While accurate in time-slotted connections, it lacks efficiency in dynamic wireless environments.IdleGap takes into consideration the CSMA collision avoidance (CSMA-CA) scheme of wireless networks to obtain its available bandwidth. The idle nodes, which are waiting to transmit, use the network allocation vector (NAV) [15], which shows how long other nodes allocate the link in the IEEE 802.11 MAC protocol. The idle time in the wireless network can then be estimated from the NAV information.All the presented mechanisms were defined with the main purpose of only estimating available bandwidth and link capacity in specific network conditions. Some mechanisms can only estimate available bandwidth and others only estimate link capacity. In a wireless network environment, it is important to have a tool that can retrieve an accurate estimation of the busy time and the total elapsed time between communications. It is also important to have a mechanism that uses not only source information but also receiver information, as this is the only way to have a precise network status. It is therefore important to introduce the concept of network cooperation in network estimation tools. Another important issue is the effective calculation of the actual data rate that is used by each communication process.


### 2.2.  Congestion Control

The transmission control protocol (TCP) [16] is the most used congestion control protocol in computer networks. However, TCP assumes that the probability of a lost packet is higher than the one of a corrupted packet [17], which is not true in wireless networks. Several congestion control mechanisms were proposed to enhance TCP’s behavior in a wireless environment. Mechanisms like TCP-F [18], TCP-ELFN [19], TCP-BuS [20], and ATCP [21] represent some examples of protocols for wireless networks in general. They concentrate on improving TCP’s throughput by freezing TCP’s congestion control algorithm during link-failure induced losses, especially when route changes occur. These TCP developments differ in the manner in which losses are identified and notified to the sender and in their details of freezing TCP’s congestion control algorithm. Even though these schemes do not recognize the need of congestion detection and signaling over a neighborhood, their congestion metric implicitly takes some degree of neighborhood congestion into account.WCP [22] and WCPCap [22] are congestion control mechanisms developed for wireless mesh networks. WCP is AIMD based and, for every flow, the source maintains a rate R which represents the long term sending rate for the flow. The main issue of WCP is that it does not correctly evaluate the available rate, making an assumption that all links have equal rate. WCPCap estimates the available capacity within each neighborhood and distributes this capacity to contending flows, using a distributed rate controller. Available capacity in WCPCap is obtained through an analytical model presented in [23], which lacks sender and receiver node cooperation. Moreover, it does not take into consideration all the factors that influence the network dynamics, thus leading to inaccurate and overestimated values. New mechanisms like imTCP (in-line measurement TCP) [24] and TCP-AP (TCP with adaptive pacing) [11] have been proposed. ImTCP introduces a new bandwidth measurement algorithm that can perform in-line measurements. The available bandwidth estimation results from the arrival intervals of ACKs packets. However, these intervals in dynamic wireless environments can suffer high variation, thus introducing lack of accuracy. Another important drawback of imTCP is that it can only estimate available bandwidth. TCP-AP was developed taking only into consideration multihop wireless environments. A TCP-AP sender adapts its transmission rate using an estimate of the 4-hop propagation delay and the coefficient of variation of recently measured round-trip times, being very conservative, and not using efficiently the medium.For ad hoc networks, other congestion control techniques were developed, such as TPA (transport protocol for ad hoc networks) [25], COPAS [26], and LRED [27]. TPA congestion control mechanism is inspired by TCP, but it is optimized to minimize the number of required packet retransmissions, transmitting blocks using a window-based scheme. As TPA uses blocks on its operation, it can suffer high performance degradation as it does not consider information on link capacity and available bandwidth measurements. COPAS proposes a route selection scheme that attempts to find disjoint paths for different flows by assigning weights to links proportional to the average number of backoffs on the link. COPAS, therefore, needs to use a large amount of network information, thus being very aggressive to the network and requiring a large amount of processing. LRED uses an exponential weighted moving average of the number of retransmissions at the MAC layer as a measure of congestion while marking packets. LRED calculates dropped packets based only on its own perception, which makes LRED behavior inefficient and unstable.Recent research has recognized the importance of explicitly detect and signal congestion over a network. One example is the explicit wireless congestion control protocol (EWCCP) [28], which identifies the set of flows that share the channel capacity with flows passing through a congested node. EWCCP is, as TCP, an AIMD algorithm based protocol, which lacks the maximization of the network utilization to achieve the highest minimum rate possible. When in more dynamic environments, this is a main issue.An alternative to AIMD based approaches is schemes in which intermediate routers send explicit and precise feedback to the sources. Examples of such congestion control schemes are the explicit control protocol (XCP) [3] and the rate control protocol (RCP) [4].XCP was designed to extract congestion information directly from intermediate nodes (routers and/or switches). 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 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). WXCP [29] and XCP-b [10] are variants of XCP that measure indirect parameters such as queue sizes and number of link layer retransmissions, using very complex heuristics. The direct estimation of the link capacity will allow a more accurate XCP-like scheme to be implemented for wireless multihop networks.The rate control protocol (RCP) aims to deliver fast flow-completion or download times. RCP uses the same feedback principle of XCP and tries to emulate 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. More recently and taking into consideration RCP main properties, for wireless sensor networks (WSN), the wireless rate control protocol (WRCP) [30] mechanism has been proposed. WRCP uses explicit feedback based on capacity information to achieve a max-min fair rate allocation over a collection tree. In WRCP, a receiver capacity model is applied. This model associates capacities with nodes instead of links. The receiver model is also used to develop and implement the explicit and distributed rate-based congestion control protocol for wireless sensor networks.


## 2.1. Capacity and Available Bandwidth Estimation

AdHoc Probe [12],WBest [13],TSProbe [14], andIdleGap [7] are some examples of link estimation mechanisms for wireless networks. WhileWBest calculates both capacity and available bandwidth,AdHoc Probe provides only the path capacity of the wireless channel. However,WBest is known to be very intrusive when estimating the available bandwidth.TSProbe [14] is a new capacity estimation tool based onAdHoc Probe, but it is focused on time-slotted connections such as bluetooth or WIMAX.TSProbe uses the interaction between several link layer properties to deploy an adaptive probing scheme that utilizes payloads that vary in size. While accurate in time-slotted connections, it lacks efficiency in dynamic wireless environments.IdleGap takes into consideration the CSMA collision avoidance (CSMA-CA) scheme of wireless networks to obtain its available bandwidth. The idle nodes, which are waiting to transmit, use the network allocation vector (NAV) [15], which shows how long other nodes allocate the link in the IEEE 802.11 MAC protocol. The idle time in the wireless network can then be estimated from the NAV information.All the presented mechanisms were defined with the main purpose of only estimating available bandwidth and link capacity in specific network conditions. Some mechanisms can only estimate available bandwidth and others only estimate link capacity. In a wireless network environment, it is important to have a tool that can retrieve an accurate estimation of the busy time and the total elapsed time between communications. It is also important to have a mechanism that uses not only source information but also receiver information, as this is the only way to have a precise network status. It is therefore important to introduce the concept of network cooperation in network estimation tools. Another important issue is the effective calculation of the actual data rate that is used by each communication process.


## 2.2.  Congestion Control

The transmission control protocol (TCP) [16] is the most used congestion control protocol in computer networks. However, TCP assumes that the probability of a lost packet is higher than the one of a corrupted packet [17], which is not true in wireless networks. Several congestion control mechanisms were proposed to enhance TCP’s behavior in a wireless environment. Mechanisms like TCP-F [18], TCP-ELFN [19], TCP-BuS [20], and ATCP [21] represent some examples of protocols for wireless networks in general. They concentrate on improving TCP’s throughput by freezing TCP’s congestion control algorithm during link-failure induced losses, especially when route changes occur. These TCP developments differ in the manner in which losses are identified and notified to the sender and in their details of freezing TCP’s congestion control algorithm. Even though these schemes do not recognize the need of congestion detection and signaling over a neighborhood, their congestion metric implicitly takes some degree of neighborhood congestion into account.WCP [22] and WCPCap [22] are congestion control mechanisms developed for wireless mesh networks. WCP is AIMD based and, for every flow, the source maintains a rate R which represents the long term sending rate for the flow. The main issue of WCP is that it does not correctly evaluate the available rate, making an assumption that all links have equal rate. WCPCap estimates the available capacity within each neighborhood and distributes this capacity to contending flows, using a distributed rate controller. Available capacity in WCPCap is obtained through an analytical model presented in [23], which lacks sender and receiver node cooperation. Moreover, it does not take into consideration all the factors that influence the network dynamics, thus leading to inaccurate and overestimated values. New mechanisms like imTCP (in-line measurement TCP) [24] and TCP-AP (TCP with adaptive pacing) [11] have been proposed. ImTCP introduces a new bandwidth measurement algorithm that can perform in-line measurements. The available bandwidth estimation results from the arrival intervals of ACKs packets. However, these intervals in dynamic wireless environments can suffer high variation, thus introducing lack of accuracy. Another important drawback of imTCP is that it can only estimate available bandwidth. TCP-AP was developed taking only into consideration multihop wireless environments. A TCP-AP sender adapts its transmission rate using an estimate of the 4-hop propagation delay and the coefficient of variation of recently measured round-trip times, being very conservative, and not using efficiently the medium.For ad hoc networks, other congestion control techniques were developed, such as TPA (transport protocol for ad hoc networks) [25], COPAS [26], and LRED [27]. TPA congestion control mechanism is inspired by TCP, but it is optimized to minimize the number of required packet retransmissions, transmitting blocks using a window-based scheme. As TPA uses blocks on its operation, it can suffer high performance degradation as it does not consider information on link capacity and available bandwidth measurements. COPAS proposes a route selection scheme that attempts to find disjoint paths for different flows by assigning weights to links proportional to the average number of backoffs on the link. COPAS, therefore, needs to use a large amount of network information, thus being very aggressive to the network and requiring a large amount of processing. LRED uses an exponential weighted moving average of the number of retransmissions at the MAC layer as a measure of congestion while marking packets. LRED calculates dropped packets based only on its own perception, which makes LRED behavior inefficient and unstable.Recent research has recognized the importance of explicitly detect and signal congestion over a network. One example is the explicit wireless congestion control protocol (EWCCP) [28], which identifies the set of flows that share the channel capacity with flows passing through a congested node. EWCCP is, as TCP, an AIMD algorithm based protocol, which lacks the maximization of the network utilization to achieve the highest minimum rate possible. When in more dynamic environments, this is a main issue.An alternative to AIMD based approaches is schemes in which intermediate routers send explicit and precise feedback to the sources. Examples of such congestion control schemes are the explicit control protocol (XCP) [3] and the rate control protocol (RCP) [4].XCP was designed to extract congestion information directly from intermediate nodes (routers and/or switches). 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 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). WXCP [29] and XCP-b [10] are variants of XCP that measure indirect parameters such as queue sizes and number of link layer retransmissions, using very complex heuristics. The direct estimation of the link capacity will allow a more accurate XCP-like scheme to be implemented for wireless multihop networks.The rate control protocol (RCP) aims to deliver fast flow-completion or download times. RCP uses the same feedback principle of XCP and tries to emulate 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. More recently and taking into consideration RCP main properties, for wireless sensor networks (WSN), the wireless rate control protocol (WRCP) [30] mechanism has been proposed. WRCP uses explicit feedback based on capacity information to achieve a max-min fair rate allocation over a collection tree. In WRCP, a receiver capacity model is applied. This model associates capacities with nodes instead of links. The receiver model is also used to develop and implement the explicit and distributed rate-based congestion control protocol for wireless sensor networks.


## 3.rt-Winf

In this section we analyse the main principles and results ofrt-Winf, since it will be the basis of the new approaches for XCP-Winf and RCP-Winf.IdleGap [7] was the underlying basis for the development ofrt-Winf. The main purpose ofrt-Winf was to mitigateIdleGap main issues, being compatible with all systems and evaluating both the link capacity and the available bandwidth without overloading the network.rt-Winf considers the link capacity as the maximum sustainable data rate at a link. The available bandwidth is the unused portion of the link capacity.rt-Winf does not affect the OSI model and obtains all of the necessary information to calculate the path capacity and available bandwidth. One of the main issues ofIdleGap is that it uses theDataRate value of the IEEE802.11 header [31], whilert-Winf effectively calculates the capacity. The operational principles ofrt-Winf allow it to rely on the Request To Send (RTS)/Clear To Send (CTS) handshake or on small probe packets.


### 3.1. RTS/CTS Packets

A RTS/CTS enabledrt-Winf mechanism relies on the RTS/CTS handshake to correctly retrieve the NAV values and uses the same node states as defined byIdleGap, that is, theSender,Onlooker, andReceiver states. In theSender state the node is transmitting data; in theReceiver state the node is receiving data; and in theOnlooker state the node is not participating in the transmission. The RTS/CTS handshake allowsrt-Winf to immediately start evaluating both link capacity and available bandwidth after the handshake completion time.The RTS/CTS packets have accurate duration values, which can be used to triggerrt-Winf calculations. To understand how RTS/CTS packets can be used by each node state, a set of handshake captures was performed. The obtained captures showed information on how each node state manages the received packets. CTS, DATA, and ACK packets are captured in the case of theSender state. In theReceiver state, a node is able to capture the RTS and the DATA packets, while a node in theOnlooker state is able to capture the complete set of packets: RTS, CTS, DATA, and ACK. This different knowledge implied the conception of different algorithms for each state. Then, we propose that each node state uses a different method to determine theIdle Rate, as can be seen in Table 1.Table 1
rt-Winf algorithm.
State
Available bandwidth
Capacity
Onlooker
Captured RTS packet?
C
Onlooker
=
S
T
ACK
-
T
CTS
-
2
T
SIFS
Yes
AB
=
C
Onlooker
×
1
-
∑
NA
V
RTS
T
Total
No
AB
=
C
Onlooker
×
1
-
∑
NA
V
CTS
T
Total
Sender
AB
=
C
Sender
×
1
-
∑
NA
V
CTS
T
Total
C
Sender
=
S
T
ACK
-
T
CTS
-
2
T
SIFS
Receiver
AB
=
C
Receiver
×
1
-
∑
NA
V
RTS
T
Total
C
Receiver
=
S
T
DATA
-
T
RTS
-
3
T
SIFSTo obtain the link capacity and the available bandwidth estimations, a node in theSender state relies on the NAV information of the CTS packets. Thus, aSender obtains the link capacity (CSender) using
(1)CSender=STACK-TCTS-2TSIFS,
where S is the DATA packet size, TACK is the actual clock time when the ACK packet is received, TCTS is the clock time of the CTS packet reception, and TSIFS is the duration of the occurred short interframe spacing (SIFS). The time when the channel is busy can then be represented by
(2)TBusy=TACK-TCTS-2TSIFS.When theSender obtains the capacity, it can determine the available bandwidth (AB) by
(3)AB=CSender×1-∑‍NAVCTSTTotal,
where NAVCTS is the NAV information on a CTS packet and TTotal represents the total elapsed transmission time obtained by the difference between the last captured ACK time and the initial transmission time.In theReceiver state a node uses the NAV information on the RTS packets to obtain the capacity (CReceiver), orIdle Rate, by
(4)CReceiver=STDATA-TRTS-3TSIFS,
where TRTS is the time when the RTS packet was received and TDATA is the clock information of the reception of the first DATA packet. TheReceiver available bandwidth estimation is then calculated through
(5)AB=CReceiver×1-∑NAVRTSTTotal,
where NAVRTS represents the NAV value on the RTS packet and TTotal is defined as the difference between the last sent ACK packet time and the initial RTS reception time.TheOnlooker state uses the NAV value according to the existence, or not, of the RTS packet to obtain both the available bandwidth and capacity. If a node in theOnlooker state captures a CTS packet of a communication without capturing the RTS packet, this implies that the communication is suffering from thehidden nodes problem. Thus, the algorithm will only use the NAV from the CTS packet to retrieve the correct values. AnOnlooker node obtains the link capacity (C) by
(6)COnlooker=STACK-TCTS-2TSIFS.If the node only captures a CTS packet, theAB is obtained by
(7)AB=COnlooker×1-∑NAVCTSTTotal,
where TTotal is equal to NAVCTS+TCTS+2SIFS. If theOnlooker receives a RTS packet, then
(8)AB=COnlooker×1-∑‍NAVRTSTTotal.AndTTotal is defined as NAVRTS+TRTS.Table2 shows, for a better understanding of the available bandwidth and capacity evaluation, the variable symbols and their description used inrt-Winf calculations.Table 2
rt-Winf variables.
Variable
Description
C
Capacity
C
Sender
Sender state capacity
C
Receiver
Receiver state capacity
C
Onlooker
Onlooker state capacity
AB
Available bandwidth
S
Packet size
T
Transfer
Transfer time
T
Total
Total elapsed time
T
ACK
Time of ACK packet
T
DATA
Time of DATA packet
T
BO
Backoff time
MSDU
MAC service data unit
NA
V
CTS
NAV value in CTS packet
NA
V
RTS
NAV value in RTS packet
T
CTS
CTS packet time
T
RTS
RTS packet time
T
MSDU
Delay per MSDU
T
80211b
Maximum 802.11b theoretical throughputA generalrt-Winf system, with its main functioning principles and states transitions, can be observed in Figure 1. The estimation process in theReceiver starts when a RTS packet is received. If the node transitions from theOnlooker state to theReceiver state, it stores theOnlooker state capacity (COnlooker) estimated value. First, the node stores the time at which it received the RTS packet (TRTS). Then, it sends a CTS packet to theSender initiating the communication process. When theReceiver receives the actual data, it stores its reception time (TDATA) and then, using the corresponding capacity estimation equation, it obtains its link capacity. If theReceiver has stored COnlooker, meaning that there was a transition from theOnlooker state to theReceiver state, the node compares its capacity estimation value (CReceiver) with COnlooker. If it returns a positive value, it updates the receiver capacity value to COnlooker; otherwise it uses its capacity estimated value of CReceiver. This process is described in (9). The node will always use the smallest value of the two capacities for better channel utilization:
(9)CReceiver-COnlookerif>0⟹CReceiver=COnlookerelseif<0⟹CReceiver=CReceiver.Figure 1
rt-Winf Sender,Receiver, andOnlooker state diagrams.Then theCReceiver value is sent to theSender on an ACK packet.In theSender state, and when a CTS packet is captured, the node starts to evaluate the available bandwidth and link capacity. First, the node stores the time at which the CTS packet is received (TCTS) and then starts to send the actual data. When it receives an ACK packet acknowledging data reception, it stores the time at which the ACK packet was received (TACK) and obtains from the received ACK packet header the CReceiver. Then, it uses the corresponding equation of Table 1 to estimate its link capacity (CSender).If the node goes to theSender state from theOnlooker, it first compares the CSender with stored capacity COnlooker. The node has to use the minimum value of the capacities. So, for obtaining that minimum value between CSender and COnlooker, the node subtracts the COnlooker value from the CSender value. If this value is positive, it means that the minimum value is equal to COnlooker; thus the node updates the CSender value to be equal to the COnlooker value. Otherwise, it maintains as the minimum capacity value its CSender capacity value. This operation is described in
(10)CSender-COnlookerif>0⟹CSender=COnlookerelseif<0⟹CSender=CSender.Then, it comparesCSender with the one received on the received ACK packet (CReceiver). For better channel use, it has to use the minimum capacity value; this avoids queue fill-ups and bottlenecks. If the node was not previously on theOnlooker state, it immediately compares its CSender capacity estimated value with the Creceiver value received on the ACK packet. If it returns a positive value, the sender updates its capacity to CReceiver; otherwise it uses the stored value of CSender:
(11)CSender-CReceiverif>0⟹CSender=CReceiverelseif(<0)⟹CSender=CSender.Finally, and with the stored capacity value, it determines the corresponding available bandwidth. This cooperation process between theSender and theReceiver is a great improvement when compared toIdleGap. The onlooking capacity is obtained as described in Table 1.


### 3.2.  Probe Packets

If RTS/CTS packets are not present,rt-Winf can use probe packets in order to retrieve the transfer time values. Probe packets can be sent between nodes. Probe packets are just sent in the beginning of the communication and, for each new communication, new probe packets are sent. To achieve good results, we use packets with 1500 bytes and frequency of 4 samples before the actual transmission starts (as stated in [12]). It must be noticed, however, that probe packets with reduced sizes can be used. The probe packets must be UDP generated packets with altered frame control IEEE 802.11 header: type data and subtype reserved. We use packets with frame control type set to 10 (data) and subtype to 1001 (reserved). This way theSender and theReceiver can successfully differentiate these packets from the ordinary data packets. The IEEE 802.11 standard defines that, for each successfully received packet, it must be sent a MAC ACK packet [31]. The whole process is very similar to the one with the RTS/CTS handshake.The process for determining the initial capacity lasts the duration of the period that corresponds to sending a packet and receiving its correspondent MAC ACK packet.The generated packets are used to retrieve the capacity(C) and available bandwidth (AB) values, according to the following:
(12)C=STTransfer,
where S is the packet size and TTransfer, the transfer time, is equal to TACK-TDATA, and(13)AB=1-∑ip‍TTransferTTotal×C,
where p is the number of packets transmitted and TTotal is the total elapsed time since the beginning of the process.The generated packets are only sent before a node starts a transmission and in the absence of traffic. This allows the system to initially determine the available bandwidth and capacity. Then, the existing traffic and the MAC layer ACK will be used to trigger the calculations. As NAV values are not correctly defined in DATA packets,rt-Winf uses clock time information to determine the busy time. Each node state has to manage independently its clock information. Therefore, NAV values are not considered in this specific implementation with probe packets. To be fully operational, bothSender andReceiver must be running thert-Winf mechanism.In a normal VoIP call using G.711 codec [32], the overhead introduced by this mechanism is ~1.66%. For a flow with more than 1 Mbps, the overhead is less than ~0.15%.


### 3.3.rt-Winf Results

We have implementedrt-Winf in the CMU wireless emulator [9] and in the ns-2 simulator [33]. The three states defined byrt-Winf mechanism and the cooperation between them and between the nodes was developed in C language. In basert-Winf, the system is configured with enabled RTS/CTS/ACK handshake packets. Inrt-Winf probe, probe packets are implemented. The maximum achievable data rate is set to 11 Mbps. Nodes are placed in such a distance that the path loss effect is considered negligible. Path capacity and available bandwidth are evaluated in different scenarios.For path capacity evaluation,rt-Winf results are compared againstAdHoc Probe results and maximum throughput (that represents the maximal theoretical throughput) in a simple 2 ad hoc nodes testbed. An UDP flow with constant bit rate (CBR) of 64 Kbps is transferred between the two nodes. According to [34], the maximal theoretical throughput is obtained through
(14)TH80211b=MSDUTMSDU,
where MSDU is the MAC service data unit.The maximum throughput represents, in ideal conditions, the maximum achievable capacity. Figure2 shows the path capacity results. With a CBR flow in the network, the expected capacity shall be lower than the maximum throughput. The simulations validate this assumption, showing thatrt-Winf results are close to the maximum throughput values. It is then possible to observe thatrt-Winf uses efficiently the information present in the channel, in order to obtain the resulting capacity. This is becausert-Winf measures more accurately the channel occupation time, as it takes into consideration all traffic flows. Compared to theAdHoc Probe mechanism, and with a similar probing time,rt-Winf gathers more information to perform the desired calculations, thus being able to be statistically more precise and less sensitive to flow variations.AdHoc Probe only takes into consideration its probing packets, which can suffer dispersion and collisions, introducing a negative impact on the capacity evaluation.Figure 2
AdHoc Probe andrt-Winf path capacity estimation.Path capacity and available bandwidth evaluations are also conducted on a wireless mesh scenario (Figure3). The two mobile nodes,Mobile Node 1 andMobile Node 2, communicate with each other through two mesh nodes that are responsible for the routing and link management. The mobile nodes are in such a distance that the traffic is always routed by the mesh nodes.Figure 3
Wireless mesh scenario.Path capacity results are shown in Figure4, and available bandwidth results are shown in Figure 5. Figure 5 contains the results ofrt-Winf,IPerf UDP [35], andIdleGap. Maximum throughput values are also presented, being considered as an upper bound of the result, as described before.IPerf UDP results are considered the lower bound.Figure 4
Path capacity in the wireless mesh scenario.Figure 5
Available bandwidth in the wireless mesh scenario.As observed in Figure4,rt-Winf is less sensitive to variations when compared toAdHoc Probe. This is becausert-Winf is taking into consideration all packets in the network and is measuring the channel occupation time of each packet, whileAdHoc Probe is only considering the packets that it generates, thus being more sensitive to flow variations.The results presented in Figure5 allow observing howIdleGap is not effectively measuring the available bandwidth.IdleGap values have a small variation but are near to theDataRate value. Inrt-Winf, it is possible to observe how the results vary through time. Those results are within an upper bound, the maximum theoretical throughput, and a lower bound,IPerf UDP.To observe the impact ofrt-Winf with probe packets in a wireless mesh scenario and to allow a valuable comparison between the emulator and simulator results, simulations in the ns-2 simulator [33] were also conducted. Asrt-Winf is based onIdleGap, the simulations also allow a baseline comparison of those mechanisms. In the simulations, a FTP transfer from a source to a sink is used, with different simultaneous flows. The maximum throughput is calculated using ns-2 default values and using (14). Figure 6 summarizes the obtained results. Each value is an average of 20 runs lasting 300 seconds of simulated time and nodes are stationary. As observed,IdleGap results are almost equal to the maximal theoretical throughput, as it is using the IEEE802.11 headerDataRate value in the calculations. These results validate the ones obtained with the CMU emulator, since the results for 1 flow in Figure 6 are similar to the ones of Figure 4. In the simulations withrt-Winf probes, probe packets with different sizes are used. The results show thatrt-Winf with probe packets is also efficiently measuring the capacity, and its values are very similar to thert-Winf mechanism working with RTS/CTS control packets.Figure 6
Ns-2 capacity results.


## 3.1. RTS/CTS Packets

A RTS/CTS enabledrt-Winf mechanism relies on the RTS/CTS handshake to correctly retrieve the NAV values and uses the same node states as defined byIdleGap, that is, theSender,Onlooker, andReceiver states. In theSender state the node is transmitting data; in theReceiver state the node is receiving data; and in theOnlooker state the node is not participating in the transmission. The RTS/CTS handshake allowsrt-Winf to immediately start evaluating both link capacity and available bandwidth after the handshake completion time.The RTS/CTS packets have accurate duration values, which can be used to triggerrt-Winf calculations. To understand how RTS/CTS packets can be used by each node state, a set of handshake captures was performed. The obtained captures showed information on how each node state manages the received packets. CTS, DATA, and ACK packets are captured in the case of theSender state. In theReceiver state, a node is able to capture the RTS and the DATA packets, while a node in theOnlooker state is able to capture the complete set of packets: RTS, CTS, DATA, and ACK. This different knowledge implied the conception of different algorithms for each state. Then, we propose that each node state uses a different method to determine theIdle Rate, as can be seen in Table 1.Table 1
rt-Winf algorithm.
State
Available bandwidth
Capacity
Onlooker
Captured RTS packet?
C
Onlooker
=
S
T
ACK
-
T
CTS
-
2
T
SIFS
Yes
AB
=
C
Onlooker
×
1
-
∑
NA
V
RTS
T
Total
No
AB
=
C
Onlooker
×
1
-
∑
NA
V
CTS
T
Total
Sender
AB
=
C
Sender
×
1
-
∑
NA
V
CTS
T
Total
C
Sender
=
S
T
ACK
-
T
CTS
-
2
T
SIFS
Receiver
AB
=
C
Receiver
×
1
-
∑
NA
V
RTS
T
Total
C
Receiver
=
S
T
DATA
-
T
RTS
-
3
T
SIFSTo obtain the link capacity and the available bandwidth estimations, a node in theSender state relies on the NAV information of the CTS packets. Thus, aSender obtains the link capacity (CSender) using
(1)CSender=STACK-TCTS-2TSIFS,
where S is the DATA packet size, TACK is the actual clock time when the ACK packet is received, TCTS is the clock time of the CTS packet reception, and TSIFS is the duration of the occurred short interframe spacing (SIFS). The time when the channel is busy can then be represented by
(2)TBusy=TACK-TCTS-2TSIFS.When theSender obtains the capacity, it can determine the available bandwidth (AB) by
(3)AB=CSender×1-∑‍NAVCTSTTotal,
where NAVCTS is the NAV information on a CTS packet and TTotal represents the total elapsed transmission time obtained by the difference between the last captured ACK time and the initial transmission time.In theReceiver state a node uses the NAV information on the RTS packets to obtain the capacity (CReceiver), orIdle Rate, by
(4)CReceiver=STDATA-TRTS-3TSIFS,
where TRTS is the time when the RTS packet was received and TDATA is the clock information of the reception of the first DATA packet. TheReceiver available bandwidth estimation is then calculated through
(5)AB=CReceiver×1-∑NAVRTSTTotal,
where NAVRTS represents the NAV value on the RTS packet and TTotal is defined as the difference between the last sent ACK packet time and the initial RTS reception time.TheOnlooker state uses the NAV value according to the existence, or not, of the RTS packet to obtain both the available bandwidth and capacity. If a node in theOnlooker state captures a CTS packet of a communication without capturing the RTS packet, this implies that the communication is suffering from thehidden nodes problem. Thus, the algorithm will only use the NAV from the CTS packet to retrieve the correct values. AnOnlooker node obtains the link capacity (C) by
(6)COnlooker=STACK-TCTS-2TSIFS.If the node only captures a CTS packet, theAB is obtained by
(7)AB=COnlooker×1-∑NAVCTSTTotal,
where TTotal is equal to NAVCTS+TCTS+2SIFS. If theOnlooker receives a RTS packet, then
(8)AB=COnlooker×1-∑‍NAVRTSTTotal.AndTTotal is defined as NAVRTS+TRTS.Table2 shows, for a better understanding of the available bandwidth and capacity evaluation, the variable symbols and their description used inrt-Winf calculations.Table 2
rt-Winf variables.
Variable
Description
C
Capacity
C
Sender
Sender state capacity
C
Receiver
Receiver state capacity
C
Onlooker
Onlooker state capacity
AB
Available bandwidth
S
Packet size
T
Transfer
Transfer time
T
Total
Total elapsed time
T
ACK
Time of ACK packet
T
DATA
Time of DATA packet
T
BO
Backoff time
MSDU
MAC service data unit
NA
V
CTS
NAV value in CTS packet
NA
V
RTS
NAV value in RTS packet
T
CTS
CTS packet time
T
RTS
RTS packet time
T
MSDU
Delay per MSDU
T
80211b
Maximum 802.11b theoretical throughputA generalrt-Winf system, with its main functioning principles and states transitions, can be observed in Figure 1. The estimation process in theReceiver starts when a RTS packet is received. If the node transitions from theOnlooker state to theReceiver state, it stores theOnlooker state capacity (COnlooker) estimated value. First, the node stores the time at which it received the RTS packet (TRTS). Then, it sends a CTS packet to theSender initiating the communication process. When theReceiver receives the actual data, it stores its reception time (TDATA) and then, using the corresponding capacity estimation equation, it obtains its link capacity. If theReceiver has stored COnlooker, meaning that there was a transition from theOnlooker state to theReceiver state, the node compares its capacity estimation value (CReceiver) with COnlooker. If it returns a positive value, it updates the receiver capacity value to COnlooker; otherwise it uses its capacity estimated value of CReceiver. This process is described in (9). The node will always use the smallest value of the two capacities for better channel utilization:
(9)CReceiver-COnlookerif>0⟹CReceiver=COnlookerelseif<0⟹CReceiver=CReceiver.Figure 1
rt-Winf Sender,Receiver, andOnlooker state diagrams.Then theCReceiver value is sent to theSender on an ACK packet.In theSender state, and when a CTS packet is captured, the node starts to evaluate the available bandwidth and link capacity. First, the node stores the time at which the CTS packet is received (TCTS) and then starts to send the actual data. When it receives an ACK packet acknowledging data reception, it stores the time at which the ACK packet was received (TACK) and obtains from the received ACK packet header the CReceiver. Then, it uses the corresponding equation of Table 1 to estimate its link capacity (CSender).If the node goes to theSender state from theOnlooker, it first compares the CSender with stored capacity COnlooker. The node has to use the minimum value of the capacities. So, for obtaining that minimum value between CSender and COnlooker, the node subtracts the COnlooker value from the CSender value. If this value is positive, it means that the minimum value is equal to COnlooker; thus the node updates the CSender value to be equal to the COnlooker value. Otherwise, it maintains as the minimum capacity value its CSender capacity value. This operation is described in
(10)CSender-COnlookerif>0⟹CSender=COnlookerelseif<0⟹CSender=CSender.Then, it comparesCSender with the one received on the received ACK packet (CReceiver). For better channel use, it has to use the minimum capacity value; this avoids queue fill-ups and bottlenecks. If the node was not previously on theOnlooker state, it immediately compares its CSender capacity estimated value with the Creceiver value received on the ACK packet. If it returns a positive value, the sender updates its capacity to CReceiver; otherwise it uses the stored value of CSender:
(11)CSender-CReceiverif>0⟹CSender=CReceiverelseif(<0)⟹CSender=CSender.Finally, and with the stored capacity value, it determines the corresponding available bandwidth. This cooperation process between theSender and theReceiver is a great improvement when compared toIdleGap. The onlooking capacity is obtained as described in Table 1.


## 3.2.  Probe Packets

If RTS/CTS packets are not present,rt-Winf can use probe packets in order to retrieve the transfer time values. Probe packets can be sent between nodes. Probe packets are just sent in the beginning of the communication and, for each new communication, new probe packets are sent. To achieve good results, we use packets with 1500 bytes and frequency of 4 samples before the actual transmission starts (as stated in [12]). It must be noticed, however, that probe packets with reduced sizes can be used. The probe packets must be UDP generated packets with altered frame control IEEE 802.11 header: type data and subtype reserved. We use packets with frame control type set to 10 (data) and subtype to 1001 (reserved). This way theSender and theReceiver can successfully differentiate these packets from the ordinary data packets. The IEEE 802.11 standard defines that, for each successfully received packet, it must be sent a MAC ACK packet [31]. The whole process is very similar to the one with the RTS/CTS handshake.The process for determining the initial capacity lasts the duration of the period that corresponds to sending a packet and receiving its correspondent MAC ACK packet.The generated packets are used to retrieve the capacity(C) and available bandwidth (AB) values, according to the following:
(12)C=STTransfer,
where S is the packet size and TTransfer, the transfer time, is equal to TACK-TDATA, and(13)AB=1-∑ip‍TTransferTTotal×C,
where p is the number of packets transmitted and TTotal is the total elapsed time since the beginning of the process.The generated packets are only sent before a node starts a transmission and in the absence of traffic. This allows the system to initially determine the available bandwidth and capacity. Then, the existing traffic and the MAC layer ACK will be used to trigger the calculations. As NAV values are not correctly defined in DATA packets,rt-Winf uses clock time information to determine the busy time. Each node state has to manage independently its clock information. Therefore, NAV values are not considered in this specific implementation with probe packets. To be fully operational, bothSender andReceiver must be running thert-Winf mechanism.In a normal VoIP call using G.711 codec [32], the overhead introduced by this mechanism is ~1.66%. For a flow with more than 1 Mbps, the overhead is less than ~0.15%.


## 3.3.rt-Winf Results

We have implementedrt-Winf in the CMU wireless emulator [9] and in the ns-2 simulator [33]. The three states defined byrt-Winf mechanism and the cooperation between them and between the nodes was developed in C language. In basert-Winf, the system is configured with enabled RTS/CTS/ACK handshake packets. Inrt-Winf probe, probe packets are implemented. The maximum achievable data rate is set to 11 Mbps. Nodes are placed in such a distance that the path loss effect is considered negligible. Path capacity and available bandwidth are evaluated in different scenarios.For path capacity evaluation,rt-Winf results are compared againstAdHoc Probe results and maximum throughput (that represents the maximal theoretical throughput) in a simple 2 ad hoc nodes testbed. An UDP flow with constant bit rate (CBR) of 64 Kbps is transferred between the two nodes. According to [34], the maximal theoretical throughput is obtained through
(14)TH80211b=MSDUTMSDU,
where MSDU is the MAC service data unit.The maximum throughput represents, in ideal conditions, the maximum achievable capacity. Figure2 shows the path capacity results. With a CBR flow in the network, the expected capacity shall be lower than the maximum throughput. The simulations validate this assumption, showing thatrt-Winf results are close to the maximum throughput values. It is then possible to observe thatrt-Winf uses efficiently the information present in the channel, in order to obtain the resulting capacity. This is becausert-Winf measures more accurately the channel occupation time, as it takes into consideration all traffic flows. Compared to theAdHoc Probe mechanism, and with a similar probing time,rt-Winf gathers more information to perform the desired calculations, thus being able to be statistically more precise and less sensitive to flow variations.AdHoc Probe only takes into consideration its probing packets, which can suffer dispersion and collisions, introducing a negative impact on the capacity evaluation.Figure 2
AdHoc Probe andrt-Winf path capacity estimation.Path capacity and available bandwidth evaluations are also conducted on a wireless mesh scenario (Figure3). The two mobile nodes,Mobile Node 1 andMobile Node 2, communicate with each other through two mesh nodes that are responsible for the routing and link management. The mobile nodes are in such a distance that the traffic is always routed by the mesh nodes.Figure 3
Wireless mesh scenario.Path capacity results are shown in Figure4, and available bandwidth results are shown in Figure 5. Figure 5 contains the results ofrt-Winf,IPerf UDP [35], andIdleGap. Maximum throughput values are also presented, being considered as an upper bound of the result, as described before.IPerf UDP results are considered the lower bound.Figure 4
Path capacity in the wireless mesh scenario.Figure 5
Available bandwidth in the wireless mesh scenario.As observed in Figure4,rt-Winf is less sensitive to variations when compared toAdHoc Probe. This is becausert-Winf is taking into consideration all packets in the network and is measuring the channel occupation time of each packet, whileAdHoc Probe is only considering the packets that it generates, thus being more sensitive to flow variations.The results presented in Figure5 allow observing howIdleGap is not effectively measuring the available bandwidth.IdleGap values have a small variation but are near to theDataRate value. Inrt-Winf, it is possible to observe how the results vary through time. Those results are within an upper bound, the maximum theoretical throughput, and a lower bound,IPerf UDP.To observe the impact ofrt-Winf with probe packets in a wireless mesh scenario and to allow a valuable comparison between the emulator and simulator results, simulations in the ns-2 simulator [33] were also conducted. Asrt-Winf is based onIdleGap, the simulations also allow a baseline comparison of those mechanisms. In the simulations, a FTP transfer from a source to a sink is used, with different simultaneous flows. The maximum throughput is calculated using ns-2 default values and using (14). Figure 6 summarizes the obtained results. Each value is an average of 20 runs lasting 300 seconds of simulated time and nodes are stationary. As observed,IdleGap results are almost equal to the maximal theoretical throughput, as it is using the IEEE802.11 headerDataRate value in the calculations. These results validate the ones obtained with the CMU emulator, since the results for 1 flow in Figure 6 are similar to the ones of Figure 4. In the simulations withrt-Winf probes, probe packets with different sizes are used. The results show thatrt-Winf with probe packets is also efficiently measuring the capacity, and its values are very similar to thert-Winf mechanism working with RTS/CTS control packets.Figure 6
Ns-2 capacity results.


## 4. XCP-Winf and RCP-Winf

To improve the performance of congestion control techniques in dynamic wireless networks, we define a new congestion control approach, based on XCP and RCP. The solution proposed adopts the explicit congestion control scheme enhanced with the interaction of a link and available bandwidth estimation mechanism. As both base XCP and RCP do not rely on an effective link capacity estimation tool [36], they begin to use the link capacity at the interface to compute the rate feedback: this introduces capacity overestimation which will generate inflated feedback, and the senders will send more traffic than the link can transfer. In the new approach,rt-Winf estimates the available bandwidth that will be used by the congestion control mechanisms to update their transmit rate. The estimation mechanism is integrated both atSender,Receiver, andOnlooker nodes.rt-Winf estimation values are obtained in the MAC layer, and therefore this information has to be accessed by XCP-Winf and RCP-Winf. Thert-Winf information is sent to the network layer through a simple, but effective, cross layer communication process. For this communication system, a shared database architecture is used, with a set of methods to get/insert information in a database accessible by all protocol layers. One example of such architecture is theMobileMan cross layered network stack [37].A generic XCP-Winf/RCP-Winf mechanism relies on the main functioning principles of XCP and RCP and is represented in Figure7.rt-Winf inserts the available bandwidth and the link capacity information in the shared database and then XCP-Winf and RCP-Winf access that information and use it to update their functions. In the following subsections we present the algorithms performed on both XCP-Winf and RCP-Winf mechanisms.Figure 7
XCP-Winf/RCP-Winf system.For a better understanding of the implemented functions described in the following sections, Table3 shows the variable symbols and its description.Table 3
XCP-Winf and RCP-Winf variables.
Variable
Description
T
H
change
Calculated throughput change
T
H
inverse
Inverse throughput
ϕ
Total input traffic
H
RCP
RCP header size
H
IP
IP header size
T
pacing
Pacing interval
Γ
RTT by throughput
S
Packet size
M
Maximum segment size
q
Queue size
q
˘
Instant queue
T
RTT
Sender estimate of the round-trip time (RTT)
T
RTT
-
AverageTRTT
T
ci
Maximum allowable control interval
T
e
Queue estimation timer
T
m
Time between the transmission of two consecutive packets
T
RTT
Sender estimate of the round-trip time (RTT)
T
DIFS
IEEE 802.11 DCF interframe space time
T
SIFS
IEEE 802.11 short interframe space time
T
backoff
IEEE 802.11 backoff time
C
winf
rt-Winf obtained capacity
C
desired
Packet desired capacity change
C
φ
Amount of capacity shuffled
C
change
Allocated feedback change
C
w
Weighted link capacity
C
extra
Extra bandwidth consumed due to backoff
A
B
winf
rt-Winf obtained available bandwidth
F
Aggregated feedback
R
RCP rate
p
f
Positive feedback factor
n
f
Negative feedback factor
f
p
Positive feedback
f
n
Negative feedback
C
W
Sender
Sender congestion window


### 4.1. XCP-Winf Functions

This section describes the proposed XCP-Winf functions. The main changes are performed on the XCP Sender and XCP router functions. The XCP Sender uses theSender state of thert-Winf algorithm and the XCP router uses theOnlooker state. The XCP-Winf Receiver is responsible for copying the throughput value required by the sender (in the packet), represented by Cdesired, to the reverse feedback field of outgoing packets. A XCP-WinfReceiver operates in a similar way as a XCPReceiver. When acknowledging a packet, the XCP-Winf Receiver copies the congestion header from the data packet to the corresponding acknowledgment packet and acknowledges the data packet in the same way as a TCP receiver.When operating as a XCP-Winf Sender, several calculations need to be performed for each packet. In a XCP-Winf system, the necessary change in the throughput(THchange) is obtained by
(15)THchange=Cdesired-CwinfCwinf×TRTT/M,
where TRTT is the current round-trip time (RTT) and M is the maximum segment size used on the network. Cwinf is the link capacity obtained fromrt-Winf and Cdesired is a desired change in the capacity value that might be supplied by an application or it might be the speed of the local interface. If no additional capacity is needed or desired, Cdesired will be equal to zero, and the packet will be immediately sent. If the value of THchange exceeds the available bandwidth value ABwinf, obtained byrt-Winf, it is reduced to the current value of ABwinf.The XCP-Winf router/node system operations in theOnlooker state are divided into four moments: when a packet arrives, when a packet departs, when the control interval timeout packet arrives, and when it is required to assess the persistent queue. Once more,rt-Winf available bandwidth and capacity are used in the calculations. On a packet arrival, the total input traffic (ϕ) seen at the XCP queue is incremented by the size of the packet received. The sum of the inverse throughput is used for capacity allocation. The inverse throughput constitutes a lower bound for the throughput for any balanced fair network and can be defined as the sum of the inverse residual capacities on the link. The inverse throughput (THInverse) uses the capacity value obtained byrt-Winf and the packet size (S), allowing having more precise values when compared to standard XCP:
(16)∑i=1i=n‍THinverse=SiCwinfi,
where n is the number of packets received. Another important parameter is the sum of TRTT by throughput; this parameter is used to obtain the control interval; on its calculation, it usesrt-Winf capacity values:
(17)∑i=1i=n‍Γ+=TRTTi×SiCwinfi.This algorithm also checks if the round-trip time(TRTT) of each flow is exceeding the maximum allowable control interval (Tci), with a default value of 0.5 seconds. If the round-trip time exceeds the threshold, the maximum allowable control interval to avoid delays when new flows are started is updated to
(18)∑i=1i=n‍Γ+=Tci×SiCwinfi.When operating on theOnlooker state and when the control timer expires,rt-Winf values are used to determine the aggregated feedback (F). The aggregated feedback value depends on the link available bandwidth. The aggregate feedback represents the desired variation, on number of bytes, that the traffic is able to allow in a time interval, normally the average RTT. A XCP-Winf router obtains the aggregate feedback [3] based onrt-Winf information:
(19)F=α×Cwinf-ABwinf-β×qTRTT-,
where α and β are constant parameters, q represents the queue value, TRTT¯ represents the average RTT, and q/TRTT- represents the persistent queue. ABWinf is the available bandwidth value of thert-Winf mechanism.Then, as stated in [3], the amount of capacity that will be shuffled (Cφ) in the next control interval is obtained. This allows new flows to acquire capacity in a full loaded system. This parameter is obtained by max⁡(0,0.1×ABwinf-|Fwinf|). This will allow obtaining the increase—positive feedback scale factor (pf)—or decrease—negative feedback scale factor (nf)—on the traffic:
(20)pf=Cφ+max⁡F,0∑Ψ,nf=Cφ+max⁡-F,0ϕ.When a packet departs, the node has to calculate a per-packet capacity change that will be compared to theTchange value in the packet header. As stated in [3], “using the AIMD rule, positive feedback is applied equally per flow, while negative feedback is made proportional to each low’s capacity.’’ The allocated feedback (Cchange) for the packet is the positive per-packet feedback (fp) minus the negative per-packet feedback (fn). The positive feedback is obtained using pf and the flows interpacket time; then
(21)fp=pf×SCwinf.The negative feedback is obtained using the packet size and thenf:
(22)fn=nf×S.Thus, the capacity change requested is(23)Cchange=fp-fn.This value may be positive or negative. The node verifies whether the packet is requesting more capacity (via the packet’sCdesired field) than the node has allocated. If so, this means that the sender’s desired throughput needs to be reduced and verified againstrt-Winf available bandwidth (ABwinf). If the node has allocated more capacity than the available bandwidth, the desired throughput is updated to thert-Winf available bandwidth. If the allocated capacity is less than the available bandwidth, the Cdesired field in the packet header is updated with the feedback allocation.XCP-Winf, as XCP, needs to calculate a queue that does not drain in a propagation delay, which is the persistent queue. This queue is intended to be the minimum standing queue over the estimation interval. Each time a packet departs, the queue length(q˘) is checked and the minimum queue size is calculated. When the queue estimation timer Te expires, the persistent queue length is equal to the minimum queue value over the last Te interval. For obtaining the duration of the Te interval, the capacity value ofrt-Winf is used:
(24)Te=max⁡q,TRTT¯-q˘Cwinf/2.Comparing XCP-Winf with XCP, it is possible to conclude that both use the same principles but differ in the way link capacity and available bandwidth are obtained and used.


### 4.2.  RCP-Winf Functions

RCP-Winf updates RCP operations, usingrt-Winf link capacity values. A RCP-Winf Receiver operates in the same way as a standard RCP Receiver. The RCP-Winf Receiver just updates the RCP congestion header with the bottleneck rate, that is, the rate of the most congested link, in the ACK packet, and then sends it to the sender.RCP-Winf relies only on link capacity evaluation and there is no need for determining the aggregate feedback(F); thus there is also no need for explicitly using the available bandwidth. A RCP-Winf implementation also keeps unchanged the standard operations performed by RCP routers when a packet arrives and departs.When operating as a sender, RCP-Winf needs to perform operations that allow it to modulate the congestion window. The RCP-Winf Sender will evaluate the desired change in throughputCdesired, through the value obtained in the ACK packet congestion header field and the link capacity obtained by thert-Winf, gathered through the cross layer communication process:
(25)Cwinf-Cdesired≤0.According to this evaluation, RCP-Winf will update or not the desired change in throughput. If the evaluation returns a negative value, theCdesired value will be updated to the Cwinf value. Then, it modulates the sender congestion window (CWSender):
(26)CWSender=Cdesired×TRTTM+HRCP+HIP,
where HRCP is the RCP header size (12 bytes) and HIP is the IP header size. Then, it calculates the pacing interval (Tpacing) that will be used to send packets from the queue:
(27)Tpacing=MCdesired.When the rate timer of a RCP-Winf router expires, the node first gets thert-Winf capacity values. Then, it assumes that the aggregate incoming traffic rate is defined by thert-Winf capacity value (Cwinf). Next, it obtains the average round-trip time of the traffic that has arrived in the rate estimation interval (Te). After that, the node updates the RTT estimate (TRTT¯) and then it updates the rate value that will be offered to the flows (R) using thert-Winf capacity:
(28)R=R×1+TeTRTT-×α×Cw×Cwinf-Cwinf-β×qTRTT-×Cw×Cwinf-1TeTRTT-.The node tests the rate value and updates it. The rate value cannot be under a minimum rate value(Rmin⁡) or above a weighted (Cw) link capacity value:
(29)ifR<Rmin⁡⟹R=Rmin⁡elseifR>Cw×Cwinf⟹R=Cw×Cwinf.Then, the node decides the length of the next rate estimation interval. Before finishing, the node resets the variables and restarts the timer.Cw controls the target link-utilization and can be any value in the range 0.95<Cw<1. It is important to choose a value less than 1 as it allows some comfort to drain excess traffic before building up a queue. In extreme congestion scenarios, the minimum rate value allowed (Rmin⁡) is considered to be
(30)Rmin⁡=00.1×MTUTRTT¯,
where MTU is the maximum transmission unit. The result of the operation will be the value of the minimum rate.A RCP-Winf router also has to perform per-packet operations, namely, when a packet arrives and when a packet departs. Whenever a packet arrives carrying a valid round-trip time, its value is added to the stored sum of RTTs and the number of packets carrying a valid RTT is incremented. This allows for a more precise calculation of the average RTTs. This is also the normal operation of a RCP standard system. RCP-Winf router uses the obtained values ofrt-Winf as their underlying value. When a packet requests an unspecified value or a value that exceeds the link capacity, the system is updated with thert-Winf obtained capacity value; that is,
(31)Cdesired=Cwinf.


## 4.1. XCP-Winf Functions

This section describes the proposed XCP-Winf functions. The main changes are performed on the XCP Sender and XCP router functions. The XCP Sender uses theSender state of thert-Winf algorithm and the XCP router uses theOnlooker state. The XCP-Winf Receiver is responsible for copying the throughput value required by the sender (in the packet), represented by Cdesired, to the reverse feedback field of outgoing packets. A XCP-WinfReceiver operates in a similar way as a XCPReceiver. When acknowledging a packet, the XCP-Winf Receiver copies the congestion header from the data packet to the corresponding acknowledgment packet and acknowledges the data packet in the same way as a TCP receiver.When operating as a XCP-Winf Sender, several calculations need to be performed for each packet. In a XCP-Winf system, the necessary change in the throughput(THchange) is obtained by
(15)THchange=Cdesired-CwinfCwinf×TRTT/M,
where TRTT is the current round-trip time (RTT) and M is the maximum segment size used on the network. Cwinf is the link capacity obtained fromrt-Winf and Cdesired is a desired change in the capacity value that might be supplied by an application or it might be the speed of the local interface. If no additional capacity is needed or desired, Cdesired will be equal to zero, and the packet will be immediately sent. If the value of THchange exceeds the available bandwidth value ABwinf, obtained byrt-Winf, it is reduced to the current value of ABwinf.The XCP-Winf router/node system operations in theOnlooker state are divided into four moments: when a packet arrives, when a packet departs, when the control interval timeout packet arrives, and when it is required to assess the persistent queue. Once more,rt-Winf available bandwidth and capacity are used in the calculations. On a packet arrival, the total input traffic (ϕ) seen at the XCP queue is incremented by the size of the packet received. The sum of the inverse throughput is used for capacity allocation. The inverse throughput constitutes a lower bound for the throughput for any balanced fair network and can be defined as the sum of the inverse residual capacities on the link. The inverse throughput (THInverse) uses the capacity value obtained byrt-Winf and the packet size (S), allowing having more precise values when compared to standard XCP:
(16)∑i=1i=n‍THinverse=SiCwinfi,
where n is the number of packets received. Another important parameter is the sum of TRTT by throughput; this parameter is used to obtain the control interval; on its calculation, it usesrt-Winf capacity values:
(17)∑i=1i=n‍Γ+=TRTTi×SiCwinfi.This algorithm also checks if the round-trip time(TRTT) of each flow is exceeding the maximum allowable control interval (Tci), with a default value of 0.5 seconds. If the round-trip time exceeds the threshold, the maximum allowable control interval to avoid delays when new flows are started is updated to
(18)∑i=1i=n‍Γ+=Tci×SiCwinfi.When operating on theOnlooker state and when the control timer expires,rt-Winf values are used to determine the aggregated feedback (F). The aggregated feedback value depends on the link available bandwidth. The aggregate feedback represents the desired variation, on number of bytes, that the traffic is able to allow in a time interval, normally the average RTT. A XCP-Winf router obtains the aggregate feedback [3] based onrt-Winf information:
(19)F=α×Cwinf-ABwinf-β×qTRTT-,
where α and β are constant parameters, q represents the queue value, TRTT¯ represents the average RTT, and q/TRTT- represents the persistent queue. ABWinf is the available bandwidth value of thert-Winf mechanism.Then, as stated in [3], the amount of capacity that will be shuffled (Cφ) in the next control interval is obtained. This allows new flows to acquire capacity in a full loaded system. This parameter is obtained by max⁡(0,0.1×ABwinf-|Fwinf|). This will allow obtaining the increase—positive feedback scale factor (pf)—or decrease—negative feedback scale factor (nf)—on the traffic:
(20)pf=Cφ+max⁡F,0∑Ψ,nf=Cφ+max⁡-F,0ϕ.When a packet departs, the node has to calculate a per-packet capacity change that will be compared to theTchange value in the packet header. As stated in [3], “using the AIMD rule, positive feedback is applied equally per flow, while negative feedback is made proportional to each low’s capacity.’’ The allocated feedback (Cchange) for the packet is the positive per-packet feedback (fp) minus the negative per-packet feedback (fn). The positive feedback is obtained using pf and the flows interpacket time; then
(21)fp=pf×SCwinf.The negative feedback is obtained using the packet size and thenf:
(22)fn=nf×S.Thus, the capacity change requested is(23)Cchange=fp-fn.This value may be positive or negative. The node verifies whether the packet is requesting more capacity (via the packet’sCdesired field) than the node has allocated. If so, this means that the sender’s desired throughput needs to be reduced and verified againstrt-Winf available bandwidth (ABwinf). If the node has allocated more capacity than the available bandwidth, the desired throughput is updated to thert-Winf available bandwidth. If the allocated capacity is less than the available bandwidth, the Cdesired field in the packet header is updated with the feedback allocation.XCP-Winf, as XCP, needs to calculate a queue that does not drain in a propagation delay, which is the persistent queue. This queue is intended to be the minimum standing queue over the estimation interval. Each time a packet departs, the queue length(q˘) is checked and the minimum queue size is calculated. When the queue estimation timer Te expires, the persistent queue length is equal to the minimum queue value over the last Te interval. For obtaining the duration of the Te interval, the capacity value ofrt-Winf is used:
(24)Te=max⁡q,TRTT¯-q˘Cwinf/2.Comparing XCP-Winf with XCP, it is possible to conclude that both use the same principles but differ in the way link capacity and available bandwidth are obtained and used.


## 4.2.  RCP-Winf Functions

RCP-Winf updates RCP operations, usingrt-Winf link capacity values. A RCP-Winf Receiver operates in the same way as a standard RCP Receiver. The RCP-Winf Receiver just updates the RCP congestion header with the bottleneck rate, that is, the rate of the most congested link, in the ACK packet, and then sends it to the sender.RCP-Winf relies only on link capacity evaluation and there is no need for determining the aggregate feedback(F); thus there is also no need for explicitly using the available bandwidth. A RCP-Winf implementation also keeps unchanged the standard operations performed by RCP routers when a packet arrives and departs.When operating as a sender, RCP-Winf needs to perform operations that allow it to modulate the congestion window. The RCP-Winf Sender will evaluate the desired change in throughputCdesired, through the value obtained in the ACK packet congestion header field and the link capacity obtained by thert-Winf, gathered through the cross layer communication process:
(25)Cwinf-Cdesired≤0.According to this evaluation, RCP-Winf will update or not the desired change in throughput. If the evaluation returns a negative value, theCdesired value will be updated to the Cwinf value. Then, it modulates the sender congestion window (CWSender):
(26)CWSender=Cdesired×TRTTM+HRCP+HIP,
where HRCP is the RCP header size (12 bytes) and HIP is the IP header size. Then, it calculates the pacing interval (Tpacing) that will be used to send packets from the queue:
(27)Tpacing=MCdesired.When the rate timer of a RCP-Winf router expires, the node first gets thert-Winf capacity values. Then, it assumes that the aggregate incoming traffic rate is defined by thert-Winf capacity value (Cwinf). Next, it obtains the average round-trip time of the traffic that has arrived in the rate estimation interval (Te). After that, the node updates the RTT estimate (TRTT¯) and then it updates the rate value that will be offered to the flows (R) using thert-Winf capacity:
(28)R=R×1+TeTRTT-×α×Cw×Cwinf-Cwinf-β×qTRTT-×Cw×Cwinf-1TeTRTT-.The node tests the rate value and updates it. The rate value cannot be under a minimum rate value(Rmin⁡) or above a weighted (Cw) link capacity value:
(29)ifR<Rmin⁡⟹R=Rmin⁡elseifR>Cw×Cwinf⟹R=Cw×Cwinf.Then, the node decides the length of the next rate estimation interval. Before finishing, the node resets the variables and restarts the timer.Cw controls the target link-utilization and can be any value in the range 0.95<Cw<1. It is important to choose a value less than 1 as it allows some comfort to drain excess traffic before building up a queue. In extreme congestion scenarios, the minimum rate value allowed (Rmin⁡) is considered to be
(30)Rmin⁡=00.1×MTUTRTT¯,
where MTU is the maximum transmission unit. The result of the operation will be the value of the minimum rate.A RCP-Winf router also has to perform per-packet operations, namely, when a packet arrives and when a packet departs. Whenever a packet arrives carrying a valid round-trip time, its value is added to the stored sum of RTTs and the number of packets carrying a valid RTT is incremented. This allows for a more precise calculation of the average RTTs. This is also the normal operation of a RCP standard system. RCP-Winf router uses the obtained values ofrt-Winf as their underlying value. When a packet requests an unspecified value or a value that exceeds the link capacity, the system is updated with thert-Winf obtained capacity value; that is,
(31)Cdesired=Cwinf.


## 5. Simulation Results

This section introduces the simulation setup to evaluate the performance of the proposed congestion control mechanisms and the simulation results. The results are obtained using the ns-2 [33] simulator. To evaluate the performance, three metrics are used: throughput, delay, and number of received packets. The proposed control mechanisms, XCP-Winf and RCP-Winf, are evaluated against the base protocols, TCP, XCP, and RCP, and against the XCP-b and TCP-AP protocols, which are especially developed for wireless networks.Different wireless mesh and ad hoc scenarios were used. The parameters of the simulations are presented in Table4. 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, an FTP application with packets of 1500 bytes or a constant bit rate (CBR) application is used. The mobility is emulated through the ns-2setdest tool to provide a random node movement pattern. We configuresetdest with a minimum speed of 10 m/s, a maximum speed of 30 m/s, and a topology boundary of 1000 × 1000 meters. All results were obtained from ns-2 trace files, with the help oftrace2stats scripts [38] adapted to our own needs. The routing protocol used was the destination-sequence distance-vector (DSDV) [39]. The presented results show the mean values obtained through different simulation runs with different seeds and the 95% confidence interval.Table 4
Simulation environment.
Simulation parameters
Topology area
1000 m× 1000 m
Simulation time
300 sec.
Simulation repetition
30 times
Ad hoc scenario number of mobile nodes
8, 16, 32, 64, 128, 256
Mesh scenario number of mobile nodes
3, 4, 5, 6, 7
Mesh scenario number of mesh fixed nodes
5, 9, 12, 16
Mesh nodes position
Random
Path loss model
Two-ray
Mobility model
Random way point
Maximum movement speed
30 m/s
Mac layer
IEEE 802.11
Propagation model
Two-ray ground
Routing protocol
DSDV


### 5.1. Mesh and Ad Hoc Scenarios Results

Next we present, analyze, and compare the results of the congestion control approaches in the mesh topology scenario. The mesh topologies defined comprise a grid of 5, 9, 12, and 16 fixed mesh nodes. In all mesh topologies, a combination of 3, 4, 5, 6, and 7 mobile nodes is used. Figure8 represents a mesh topology of 5 mesh nodes and 5 mobile nodes. The mobile nodes are simultaneously sources and sinks. The results show throughput, delay, and the number of received packets.Figure 8
Topology of 5 mesh nodes, 5 mobile nodes.Figures9(a), 9(b), and 9(c) show the previously referred performance metrics for five different scenarios. In each scenario, a fixed number of 16 mesh nodes and a variable number, from 3 to 7, of mobile nodes were used. Each mobile node, as previously stated, is simultaneously sending and receiving data.Mesh scenario: 16 mesh nodes, variable number of mobile nodes.
(a)
Throughput
(b)
Delay
(c)
Received packetsThe obtained results show that the integration ofrt-Winf in XCP and RCP improves significantly their behavior, which makes XCP and RCP behave more efficiently and with better channel utilization, which also leads to less channel losses (more received packets). The use ofrt-Winf in the mesh nodes (Onlooker state) makes the feedback mechanism more accurate, as all nodes in the network can determine available bandwidth and capacity and send that information to the other nodes that are participating in the communication. Both XCP-b and TCP-AP have better results than TCP and standard XCP and RCP. However, they are outperformed by both XCP-Winf and RCP-Winf. TCP-AP is the most conservative one and obtains worse results on the number of received packets. XCP-b relies on the maximum buffer size of nodes, and therefore, with the current scenario conditions, XCP-b is less efficient and less accurate than both XCP-Winf and RCP-Winf.To evaluate XCP-Winf and RCP-Winf when using CBR applications, an UDP application (simulating a VoIP application) is configured, for the 16 mesh nodes scenario and variable number of mobile nodes. Figure10 shows the obtained results. Withoutrt-Winf enabled, XCP obtains better results than RCP for a lower number of mobile nodes. This is due to the fact that RCP was developed having in mind Internet bursts traffic. With less mobile nodes exchanging information, the number of collisions is lower, and less retransmissions and burst traffic are present in the network. It is also possible to conclude that both XCP and RCP are not evaluating correctly the link capacity and do not have the necessary mechanisms to overcome this situation. Withrt-Winf, the throughput results are considerably better. However, it can be seen that XCP and RCP have lower performance in controlling congestion when the traffic is UDP.Figure 10
CBR throughput in mesh scenario: 16 mesh nodes, variable number of mobile nodes.Once more, RCP-Winf reflects its base development for bursty traffic. The CBR application is sending data at a constant rate; with more mobile nodes sending data, more collisions will occur and more bursts of traffic will be present in the network. This situation will allow RCP to react more precisely and, with more mobile nodes, to have better throughput results. The results also show that XCP-b is better suited when the number of mobile nodes is small. The results show that TCP-AP, though specially developed for wireless environments, has very poor results. This is because a TCP-AP sender adapts its transmission rate using an estimate of the 4-hop propagation delay and the coefficient of variation of recently measured round-trip times. This means that TCP-AP is very conservative, not using efficiently the medium.The congestion control approaches are also evaluated in ad hoc scenarios using CBR UDP 64 Kbps flows. The scenarios are composed of 8, 16, 32, 64, 128, and 256 nodes, and for each scenario there are 4, 8, 16, 32, 64, and 128 simultaneous flows. The flows are randomly generated through the ns-2gencbr.tcl tool. The mobility was also dynamically generated through different seed values. The obtained results are presented in Figures 11(a), 11(b), and 11(c).Ad hoc scenario: variable number of flows.
(a)
Throughput
(b)
Delay
(c)
Received packetsFrom the obtained results, it is possible to conclude that standard XCP and RCP have the same behavior when the traffic is UDP; however, the integration ofrt-Winf makes them react differently as they both use the information from the MAC sublayer in a different way. It is also possible to see that, withrt-Winf integrated, both XCP and RCP can receive more packets, which reflects a lower rate of lost packets. This is due to the fact that XCP-Winf and RCP-Winf, with accurate link capacity and available bandwidth, are using more efficiently the medium and improving each node queue management. As more packets are transmitted, more throughput is obtained and the medium is better used: it is possible to infer that both XCP-Winf and RCP-Winf are more stable and fair. In the same conditions, it is possible to send more information with a higher rate. It must be noticed that the results also reflect the mobility randomness, where more nodes are in each other’s influence area. Another factor that is influencing the results is the routing information and the exchanged routing messages: as flows increase, the collisions and delay also increase, which is also reflected in throughput values. Once more, XCP-b obtains good results when the network is not heavily utilized, where XCP-b increases its available bandwidth and, consequently, its rate. However, with more nodes and flows in the network, XCP-b behavior is less efficient due to the higher number of losses, reducing the flow rate. With respect to TCP-AP, its behavior is also degraded as the number of flows increases: while the throughput results are improved, they are obtained with less received packets.


### 5.2.  Building Scenario Results

For a more real evaluation, we defined a new mesh network scenario to simulate a public building, with public services and a public garden (Figure12). According to Table 4, the different parameters are the following: the numbers of mobile nodes are 10, 20, and 30; the fixed mesh nodes are 6 and two different flows are used. In this scenario, mobile nodes start to transmit in a random way and their transmission lasts 240 seconds. The mesh nodes position is randomly defined in the inside area. A randomly chosen mesh node is shut down for 100 seconds during the simulation period. Two types of flows are used, to represent a light traffic flow (4 CBR 64 Kbps flows, sent each 400 ms) and a heavy traffic flow (4 CBR 128 Kbps flows, sent each 100 ms).Figure 12
Building layout simulation.The obtained results of the light traffic flows are shown in Figures13(a), 13(b), and 13(c); the results of the heavy traffic flows are presented in Figures 14(a), 14(b), and 14(c). As can be observed from the results, the integration ofrt-Winf in both XCP and RCP improves their standard behavior. Since the nodes that are not participating in the communication enter theOnlooker state and evaluate the network performance, it is possible to have a state by state and rate by rate overall performance evaluation. Asrt-Winf uses three different states and network cooperation, it is possible to have a more effective and efficient hop by hop performance evaluation. This results in a more efficient evaluation and use of the channel capacity. As XCP-Winf and RCP-Winf also have more capability to adapt to the changing conditions of the network, this is expressed in better transmitting rates and better channel usage. XCP-b has again poor performance for high load scenarios: XCP-b is not taking into consideration packet loss, considering packet loss as a buffer overflow, thus having a more inefficient behavior and introducing unnecessary capacity slowdowns on the network. TCP-AP presents good overall results. However, it obtains those results with a considerable reduction in received packets, which indicates that TCP-AP is more conservative and is not efficiently using the medium.Public building light flow: variable number of mobile nodes.
(a)
Light flow throughput
(b)
Light flow delay
(c)
Light flow received packetsPublic building heavy flow: variable number of mobile nodes.
(a)
Heavy flow throughput
(b)
Heavy flow delay
(c)
Heavy flow received packets


### 5.3. Utility Results

As TCP is the most used and deployed congestion control protocol on the Internet, it is important (as described in [40]) to analyze how XCP-Winf and RCP-Winf flows interact and compete with TCP. For this purpose, we use the average data rate over time for each flow, thus allowing observing how bandwidth is being managed between TCP and thewinf proposals. This is calledutility of a networking protocol.Two scenarios were defined: one using XCP-Winf and TCP and the other using RCP-Winf and TCP. The two scenarios consist of a 1000 m × 1000 m area, divided into three distinct parts: an area of 250 m × 250 m where there are two mobile node sources, one with TCP and the other with XCP-Winf or RCP-Winf; a middle area of 500 m × 500 m with two mobile nodes with thert-Winf mechanism activated (the average data rate is measured on these two nodes, as they will have TCP andwinf-like flows competing); finally, another area of 250 m × 250 m for the mobile nodes sinks. Each source generates two FTP flows with packets of 1500 bytes. The simulation lasts for 120 seconds.Figures15(a) and 15(b) show the obtained results. It is possible to observe that on both situations TCP flow grows faster and gains more bandwidth on the beginning: this is because TCP’s congestion mechanisms are not evaluating correctly the network status (TCP is trying to fill the nodes queues, expecting that packet loss due to queue overflow will indicate congestion). However, RCP-Winf and XCP-Winf are evaluating, and measuring consistently, how the network is behaving and adjusting the bandwidth requirements to that information. As RCP-Winf is based on RCP with its bursty traffic development, it has a more unstable behavior during the initial instant of the simulation; as more traffic is present on the network, RCP-Winf becomes more stable.Utility results.
(a)
XCP-Winf utility results
(b)
RCP-Winf utility resultsThe results also show that thewinf mechanisms are TCP-friendly on the long term and are adjusting to the unfairness nature of TCP. XCP-Winf reacts earlier to these constraints and starts to compete for the same bandwidth as TCP earlier than RCP-Winf. However, it must be noticed that the results show that both RCP-Winf and XCP-Winf take some time to allow a fair share of bandwidth between their native flows and TCP. It is advisable that this fair share is obtained as quickly as possible, thus allowing a more efficient share and coexistence of network resources.


## 5.1. Mesh and Ad Hoc Scenarios Results

Next we present, analyze, and compare the results of the congestion control approaches in the mesh topology scenario. The mesh topologies defined comprise a grid of 5, 9, 12, and 16 fixed mesh nodes. In all mesh topologies, a combination of 3, 4, 5, 6, and 7 mobile nodes is used. Figure8 represents a mesh topology of 5 mesh nodes and 5 mobile nodes. The mobile nodes are simultaneously sources and sinks. The results show throughput, delay, and the number of received packets.Figure 8
Topology of 5 mesh nodes, 5 mobile nodes.Figures9(a), 9(b), and 9(c) show the previously referred performance metrics for five different scenarios. In each scenario, a fixed number of 16 mesh nodes and a variable number, from 3 to 7, of mobile nodes were used. Each mobile node, as previously stated, is simultaneously sending and receiving data.Mesh scenario: 16 mesh nodes, variable number of mobile nodes.
(a)
Throughput
(b)
Delay
(c)
Received packetsThe obtained results show that the integration ofrt-Winf in XCP and RCP improves significantly their behavior, which makes XCP and RCP behave more efficiently and with better channel utilization, which also leads to less channel losses (more received packets). The use ofrt-Winf in the mesh nodes (Onlooker state) makes the feedback mechanism more accurate, as all nodes in the network can determine available bandwidth and capacity and send that information to the other nodes that are participating in the communication. Both XCP-b and TCP-AP have better results than TCP and standard XCP and RCP. However, they are outperformed by both XCP-Winf and RCP-Winf. TCP-AP is the most conservative one and obtains worse results on the number of received packets. XCP-b relies on the maximum buffer size of nodes, and therefore, with the current scenario conditions, XCP-b is less efficient and less accurate than both XCP-Winf and RCP-Winf.To evaluate XCP-Winf and RCP-Winf when using CBR applications, an UDP application (simulating a VoIP application) is configured, for the 16 mesh nodes scenario and variable number of mobile nodes. Figure10 shows the obtained results. Withoutrt-Winf enabled, XCP obtains better results than RCP for a lower number of mobile nodes. This is due to the fact that RCP was developed having in mind Internet bursts traffic. With less mobile nodes exchanging information, the number of collisions is lower, and less retransmissions and burst traffic are present in the network. It is also possible to conclude that both XCP and RCP are not evaluating correctly the link capacity and do not have the necessary mechanisms to overcome this situation. Withrt-Winf, the throughput results are considerably better. However, it can be seen that XCP and RCP have lower performance in controlling congestion when the traffic is UDP.Figure 10
CBR throughput in mesh scenario: 16 mesh nodes, variable number of mobile nodes.Once more, RCP-Winf reflects its base development for bursty traffic. The CBR application is sending data at a constant rate; with more mobile nodes sending data, more collisions will occur and more bursts of traffic will be present in the network. This situation will allow RCP to react more precisely and, with more mobile nodes, to have better throughput results. The results also show that XCP-b is better suited when the number of mobile nodes is small. The results show that TCP-AP, though specially developed for wireless environments, has very poor results. This is because a TCP-AP sender adapts its transmission rate using an estimate of the 4-hop propagation delay and the coefficient of variation of recently measured round-trip times. This means that TCP-AP is very conservative, not using efficiently the medium.The congestion control approaches are also evaluated in ad hoc scenarios using CBR UDP 64 Kbps flows. The scenarios are composed of 8, 16, 32, 64, 128, and 256 nodes, and for each scenario there are 4, 8, 16, 32, 64, and 128 simultaneous flows. The flows are randomly generated through the ns-2gencbr.tcl tool. The mobility was also dynamically generated through different seed values. The obtained results are presented in Figures 11(a), 11(b), and 11(c).Ad hoc scenario: variable number of flows.
(a)
Throughput
(b)
Delay
(c)
Received packetsFrom the obtained results, it is possible to conclude that standard XCP and RCP have the same behavior when the traffic is UDP; however, the integration ofrt-Winf makes them react differently as they both use the information from the MAC sublayer in a different way. It is also possible to see that, withrt-Winf integrated, both XCP and RCP can receive more packets, which reflects a lower rate of lost packets. This is due to the fact that XCP-Winf and RCP-Winf, with accurate link capacity and available bandwidth, are using more efficiently the medium and improving each node queue management. As more packets are transmitted, more throughput is obtained and the medium is better used: it is possible to infer that both XCP-Winf and RCP-Winf are more stable and fair. In the same conditions, it is possible to send more information with a higher rate. It must be noticed that the results also reflect the mobility randomness, where more nodes are in each other’s influence area. Another factor that is influencing the results is the routing information and the exchanged routing messages: as flows increase, the collisions and delay also increase, which is also reflected in throughput values. Once more, XCP-b obtains good results when the network is not heavily utilized, where XCP-b increases its available bandwidth and, consequently, its rate. However, with more nodes and flows in the network, XCP-b behavior is less efficient due to the higher number of losses, reducing the flow rate. With respect to TCP-AP, its behavior is also degraded as the number of flows increases: while the throughput results are improved, they are obtained with less received packets.


## 5.2.  Building Scenario Results

For a more real evaluation, we defined a new mesh network scenario to simulate a public building, with public services and a public garden (Figure12). According to Table 4, the different parameters are the following: the numbers of mobile nodes are 10, 20, and 30; the fixed mesh nodes are 6 and two different flows are used. In this scenario, mobile nodes start to transmit in a random way and their transmission lasts 240 seconds. The mesh nodes position is randomly defined in the inside area. A randomly chosen mesh node is shut down for 100 seconds during the simulation period. Two types of flows are used, to represent a light traffic flow (4 CBR 64 Kbps flows, sent each 400 ms) and a heavy traffic flow (4 CBR 128 Kbps flows, sent each 100 ms).Figure 12
Building layout simulation.The obtained results of the light traffic flows are shown in Figures13(a), 13(b), and 13(c); the results of the heavy traffic flows are presented in Figures 14(a), 14(b), and 14(c). As can be observed from the results, the integration ofrt-Winf in both XCP and RCP improves their standard behavior. Since the nodes that are not participating in the communication enter theOnlooker state and evaluate the network performance, it is possible to have a state by state and rate by rate overall performance evaluation. Asrt-Winf uses three different states and network cooperation, it is possible to have a more effective and efficient hop by hop performance evaluation. This results in a more efficient evaluation and use of the channel capacity. As XCP-Winf and RCP-Winf also have more capability to adapt to the changing conditions of the network, this is expressed in better transmitting rates and better channel usage. XCP-b has again poor performance for high load scenarios: XCP-b is not taking into consideration packet loss, considering packet loss as a buffer overflow, thus having a more inefficient behavior and introducing unnecessary capacity slowdowns on the network. TCP-AP presents good overall results. However, it obtains those results with a considerable reduction in received packets, which indicates that TCP-AP is more conservative and is not efficiently using the medium.Public building light flow: variable number of mobile nodes.
(a)
Light flow throughput
(b)
Light flow delay
(c)
Light flow received packetsPublic building heavy flow: variable number of mobile nodes.
(a)
Heavy flow throughput
(b)
Heavy flow delay
(c)
Heavy flow received packets


## 5.3. Utility Results

As TCP is the most used and deployed congestion control protocol on the Internet, it is important (as described in [40]) to analyze how XCP-Winf and RCP-Winf flows interact and compete with TCP. For this purpose, we use the average data rate over time for each flow, thus allowing observing how bandwidth is being managed between TCP and thewinf proposals. This is calledutility of a networking protocol.Two scenarios were defined: one using XCP-Winf and TCP and the other using RCP-Winf and TCP. The two scenarios consist of a 1000 m × 1000 m area, divided into three distinct parts: an area of 250 m × 250 m where there are two mobile node sources, one with TCP and the other with XCP-Winf or RCP-Winf; a middle area of 500 m × 500 m with two mobile nodes with thert-Winf mechanism activated (the average data rate is measured on these two nodes, as they will have TCP andwinf-like flows competing); finally, another area of 250 m × 250 m for the mobile nodes sinks. Each source generates two FTP flows with packets of 1500 bytes. The simulation lasts for 120 seconds.Figures15(a) and 15(b) show the obtained results. It is possible to observe that on both situations TCP flow grows faster and gains more bandwidth on the beginning: this is because TCP’s congestion mechanisms are not evaluating correctly the network status (TCP is trying to fill the nodes queues, expecting that packet loss due to queue overflow will indicate congestion). However, RCP-Winf and XCP-Winf are evaluating, and measuring consistently, how the network is behaving and adjusting the bandwidth requirements to that information. As RCP-Winf is based on RCP with its bursty traffic development, it has a more unstable behavior during the initial instant of the simulation; as more traffic is present on the network, RCP-Winf becomes more stable.Utility results.
(a)
XCP-Winf utility results
(b)
RCP-Winf utility resultsThe results also show that thewinf mechanisms are TCP-friendly on the long term and are adjusting to the unfairness nature of TCP. XCP-Winf reacts earlier to these constraints and starts to compete for the same bandwidth as TCP earlier than RCP-Winf. However, it must be noticed that the results show that both RCP-Winf and XCP-Winf take some time to allow a fair share of bandwidth between their native flows and TCP. It is advisable that this fair share is obtained as quickly as possible, thus allowing a more efficient share and coexistence of network resources.


## 6. Conclusions

In this paper we presented a study that demonstrates that using MAC layer information in congestion control, through a cross layer communication process, can be an important factor of network performance improvement. This MAC layer information resorts to CTS/RTS/ACK messages handshake or on small probes to know each node’s channel allocation, and it allows accurate determining of the links capacity and available bandwidth. This information is then used by congestion control mechanisms based on explicit congestion notifications, XCP and RCP, to accurately determine the network status and act accordingly.The evaluation results of XCP-Winf and RCP-Winf, obtained through ns-2 simulations, show that thert-Winf algorithm improves significantly XCP and RCP behavior, making them more efficient and stable. To obtain the available network capacity, both XCP and RCP need all nodes in the network to cooperate, which increases network overhead, specially when dealing with special wireless environments, such as wireless mesh networks and ad hoc networks. Usingrt-Winf, which works in the MAC layer, it is possible to perform link capacity and available bandwidth calculations without interfering in the network dynamics, allowing significant improvement of XCP and RCP performance. It was also possible to conclude that XCP-Winf and RCP-Winf behave more efficiently and use the network available information more effectively than XCP-b and TCP-AP, two protocols specifically designed for wireless environments. It is then possible to conclude that both XCP-Winf and RCP-Winf outperform XCP-b and TCP-AP in terms of medium usage, thus allowing a more stable behavior and a faster convergence to the active network conditions.As future work, we plan to extend the evaluation with the analysis of the effect of collision probability and the improvement of the results when introducing this effect on the congestion control approaches and also to work on the improvement of XCP-Winf and RCP-Winf utility results, allowing having a much more efficient coexistence with TCP flows with thert-Winf versions of XCP and RCP. An effort will also be made in optimizing other protocols behavior, such as TCP-AP, with the integration ofrt-Winf real time and in-line information. As this work presents mainly results obtained through simulation evaluation, future work might also involve exploring the implementation of the proposed solutions against other routing protocols and also implement them directly in the Linux Kernel, allowing creating a small testbed for testing and evaluating the solutions in real environments and in different conditions.



---

*Source: 925207-2015-01-12.xml*