Neighbourhood Based Congestion Control In Multihop Wireless

Published Date: 02 Nov 2017

Abstract— Considering static multihop wireless mesh networks, complex interference from neighbourhood nodes can adversely affect the transport protocol performance. Since TCP does not explicitly account for this, it can results in starvation and unfairness over such networks. In this paper, we explore mechanism to achieve fair and efficient congestion control for multihop wireless mesh networks. First, we design an AIMD-based rate-control protocol called Wireless Control Protocol (WCP), which identifies wireless congestion as a neighbourhood phenomenon, not a local-node one and appropriately reacts to such congestion. The algorithm assigns the rates inversely proportional to the number of bottlenecks a flow passes through, among the neighbours and modifies the rate of flows and the RTT to achieve fairness among the flows within the same neighbourhood. Using analysis, simulations and real world deployments, several topologies were tested for the design. We found that our design yields rates that are both fair and efficient. The algorithm is then tested for flexibility among very large topologies.

Keywords— control, mesh, multihop, Wireless Control Protocol (WCP), wireless.

Introduction

Static multihop wireless mesh networks, constructed using Omni directional IEEE 802.11 radios, promise flexible edge connectivity to the Internet, enabling low-cost community networking in densely populated urban settings. They can also be rapidly deployed to provide a communications backbone where none exists, such as in a disaster recovery scenario.

However, their widespread adaptation has been limited by significant technical challenges. Transport protocols like TCP can perform poorly because of complex interference among neighbouring nodes. In particular, TCP does not explicitly account for the fact that congestion in a mesh network is a neighbourhood phenomenon. Consider the topology of Fig. 1, in which links connect nodes that can exchange packets with each other, perhaps with asymmetric reception rates. In this topology, it is easy to show in simulation and actual experiments that the TCP connection in the middle is almost completely starved (gets extremely low throughput) since it reacts more aggressively to congestion than the two outer flows.

Fig. 1. Stack topology Fig. 2. Achievable rate region

To understand the properties of a desirable solution to this problem, consider Fig. 2. The -axis plots the rate achieved by the middle flow, and the -axis for the outer two flows (by symmetry, these flows will achieve approximately the same rate for any scheme) of Fig. 1. Now, with a perfect MAC scheduler that has the same overhead as 802.11, it is intuitively clear that the rates achievable lie on or below the straight line shown in the figure (since an optimal scheduler would either schedule the two outer flows simultaneously or the flow in the middle). With 802.11, there is some loss of throughput due to contention, and the corresponding achievable-rate region bounds the rates achievable by the flows on this topology. TCP achieves rates that lie at one corner of this plot. We contend that, for this topology, a desirable solution is one that gets us close to the max-min fair rate allocation point, which corresponds to the intersection of the 45 degree line and the 802.11 achievable- rate curve.

In this paper, we explore mechanism for achieving such a solution in wireless mesh networks. Three considerations inform our choice of mechanisms. First, we do not make any changes to the widely used 802.11 MAC. Second, our approach is clean-slate. We conduct our explorations in the context of a rate-based protocol that incorporates some of TCP’s essential features (such as ECN and SACK), yet allows us to explore more natural implementations of the mechanisms for improving fairness and efficiency that we study in this paper. Finally, we restrict our explorations to plausibly implementable mechanisms.

Related Work

Early work on improving TCP performance in wireless networks focused on distinguishing between packet losses due to wireless corruption from loss due to congestion. More recent work, however, has addressed congestion control for mobile ad hoc wireless networks. One class of work concentrates on improving TCP’s throughput by freezing TCP’s congestion control algorithm during link-failure induced losses, especially during route changes [5]. However, unlike WCP, these proposals do not explicitly recognize and account for congestion within a neighbourhood. As a result, they would exhibit the same shortcomings of TCP as discussed in Section I.

Another class of work related to WCP addresses TCP performance issues for ad hoc networks with no link-failure induced losses using congestion metrics that include average number of back offs on a link [7], average number of retransmissions at the MAC layer [4], and the sum of the queuing and transmission delay at each intermediate node [3]. Even though these schemes do not recognize the need of congestion detection and signalling over a neighbourhood, their congestion metric implicitly takes some degree of neighbourhood congestion into account. However, congestion in wireless networks exhibits strong location dependency [8]. i.e., different nodes in a congested neighbourhood locally perceive different degrees of congestion. In the above schemes, flows traversing different nodes in a single congested neighbourhood would receive varying levels of congestion notification. In contrast, WCP explicitly shares congestion within a neighbourhood, ensuring that each flow in a single congested neighbourhood gets its fair share of the bottleneck bandwidth.

Two other pieces of work, however, have recognized the importance of explicitly detecting and signalling congestion over a neighbourhood. NRED [6] identifies a set of flows that share channel capacity with flows passing through a congested node. However, it identifies only a subset of the contending flows: It misses flows that traverse two-hop neighbours of a node without traversing its one-hop neighbours. Moreover, the mechanism to regulate the traffic rates on these flows is quite a bit more complex than ours (it involves estimating a neighbourhood queue size and using RED-style marking on packets in this queue). Finally, unlike WCP, NRED requires RTS/CTS, is intimately tied to a particular queue management technique (RED), might require special hardware for channel monitoring, and has not been tested in a real implementation. EWCCP [2] correctly identifies the set of flows that share channel capacity with flows passing through a congested node. EWCCP is designed to be proportionally fair, and its design as well as its proof of correctness assumes that the achievable rate region of 802.11 is convex. As Fig. 2 shows, however, this is not necessarily true. Moreover, EWCCP has also not been tested in a real implementation.

An easy way to comply with the conference paper formatting requirements is to use this document as a template and simply type your text into it.

Design

In this section, we first discuss the design and implementation of WCP, an AIMD-based rate-control protocol that incorporates many of the features of TCP, but differs significantly in its congestion control algorithms.WCP is a rate-based congestion control protocol for static multihop wireless mesh networks that use the 802.11 MAC. In this section, we assume that the link rates of all the links are equal and auto-rate adaptation is turned off. In WCP, for every flow, the source maintains a rate that represents the long-term sending rate for the flow. WCP is AIMD-based, so the source additively increases on every ACK reception and multiplicatively decreases upon receiving a congestion notification from routers (intermediate forwarding nodes). Routers signal congestion by setting a congestion bit in the packet header of ongoing packets. Unlike existing congestion control techniques, WCP has novel algorithms for detecting and signalling congestion at the intermediate routers, as well as for adapting rates at sources in response to congestion signals.

Congestion in Multihop Wireless Networks:

In a wireless network, since neighbouring nodes share the wireless channel, the available transmission capacity at a node can depend on traffic between its neighbours. More precisely, congestion in wireless networks is defined not with respect to a node, but with respect to transmissions from a node to its neighbour. In what follows, we use the term link to denote a one-hop sender–receiver pair. Thus, in Fig. 1, we say that a transmission from 5 to 6 is along the link 5 → 6. Congestion in wireless networks is defined not with respect to a node, but with respect to a link i → j (L i → j).

Thus, (L i → j), for a mesh network using an 802.11MAC, is defined as the following: the set of all incoming and outgoing links of i, j, all neighbours of i, and all neighbours of j. Note that L i → j includes i → j. Moreover, this relationship is symmetric.

Congestion Detection and Sharing

If link i → j is congested, it shares this information with all links in L i → j. Packets traversing those links are marked with an explicit congestion notification so that sources can appropriately adapt the rates of the corresponding flows. A router detects congestion on its outgoing link using a simple threshold scheme. It maintains an exponentially weighted moving average (EWMA) of the queue size, qAvg i → j, for every outgoing link as

qAvg i → j = (1- Wq) * qAvg i → j + Wq * qInst i → j

where qInst i → j is the instantaneous queue size for link and Wq is the EWMA weight. A link is congested when its average queue size is greater than a congestion threshold K. We choose queue size as a measure of congestion for two reasons: It has been shown to work sufficiently well in wireless networks [9] and is a more natural choice for detecting congestion per link compared to, say, channel utilization, which measures the level of traffic around a node.

When a router i detects that i → j is congested, it needs to share this information with nodes at the transmitting ends of links in L i → j. This is achieved by piggybacking congestion information on each outgoing packet that neighbours snoop. Specifically, each node maintains the congestion state of its entire outgoing and incoming links. Nodes can locally determine (from queue size) the congestion state of their outgoing links. For nodes to obtain congestion state on their incoming links, every node during an outgoing packet transmission along a link includes congestion state of that link in the outgoing packet. In addition, every node also includes the following information in each outgoing packet: a bit indicating if any outgoing or incoming link from the node is congested and the identity of the link (sender and receiver of the link), and a bit indicating if any outgoing or incoming link from any of the node’s neighbours is congested and the identity of the link. This latter bit is calculated from information obtained by using the former bit from neighbours. In the event of more than one link being congested at a node, it is sufficient for the node to select of only one of these links. Information shared in this manner is sufficient for any node in to receive congestion notification when link is congested.

Rate Adaptation:

In WCP, sources perform rate adaptation. Our contribution is to correctly determine the timescales at which these operations are performed. The novel aspect of our contribution is that these timescales are determined by the RTTs of flows traversing a congested neighbourhood.

A source S in WCP maintains a rate rf for every flow f originating at S. It linearly increases the rate every tai seconds, where tai is the control interval for additive increase

rf = rf + α

where α is a constant. The choice of tai is an important design parameter in WCP. To enable fairness, WCP introduces the notion of a shared RTT. Denote by rrtAvg i → j the average RTT of all the flows traversing the link i → j.

rttAvg i → j =

where F i → j is the set of flows traversing link i → j. For each link i → j, node compute the shared RTT, rttmaxAvg i → j, as the maximum RTT among all links in L i → j. In other words, this quantity measures the largest average flow RTT across the set of links that shares the channel with i → j. Our definition conservatively chooses the largest control interval in the neighbourhood.

For all flows traversing link i → j, the router includes rttmaxAvg i → j in every packet header only if it exceeds the current value of that field in the header. The source uses this value for tai. Thus, tai is the largest shared RTT across all the links that the flow traverses. This ensures that the value of the control interval for a flow is no less than the highest RTT of any flow with which it shares a wireless neighbourhood.

Upon receiving a packet with a congestion notification bit set, a source reduces the rate rf by half and waits for the control interval for multiplicative decrease tmd before reacting again to any congestion notification from the routers. tmd must be long enough so that the source has had time to observe the effect of its rate reduction. Moreover, for fairness, flows that traverse the congested region1 must all react at roughly the same timescale. To ensure this, WCP also computes a quantity for each link that we term the shared instantaneous RTT, denoted by rttmaxInst i → j.This is computed in exactly the same way as the shared RTT, except that the instantaneous RTT is used rather than the average RTT. The former is a more accurate indicator of the current level of congestion in the network and is a more conservative choice of the timescale required to observe the effect of a rate change. As before, routers insert this shared instantaneous RTT into the packet header only if it exceeds the current value. Sources set tmd to be the value of this field in the packet header that triggered the multiplicative decrease. If a flow traverses multiple congested regions, its multiplicative decreases are clocked by the neighbourhood with the largest shared instantaneous RTT.

Computation of rttmaxAvg i → j (rttmaxInst i → j) requires sharing "link RTTs," rttAvg i → j (rttInst i → j), among all nodes in L i → j requiring significant overhead. However, its definition permits a natural optimization. Similar to congestion sharing as discussed, every node includes in each outgoing packet only the maximum of rttAvg i → j (rttInst i → j) over all incoming and outgoing links of the node and the maximum of rttAvg i → j (rttInst i → j) over all incoming and outgoing links of all the neighbours of the node. This allows for a low overhead distributed calculation of shared RTT (instantaneous RTT) over all the nodes in L i → j.

Finally, we describe how the source uses the value rf. WCP aims to assign fair goodputs. Naively sending packets at the rate rf assigns fair throughputs, but packet losses due to channel error or interference can result in unequal goodputs. Instead, WCP sends packets at a rate rf / p, where p is the empirically observed packet loss rate over the connection. Intuitively, this goodput correction heuristic sends more packets for flows traversing lossy paths, equalizing flow goodputs. Other rate-based protocols use more sophisticated loss-rate computation techniques to perform similar goodput correction.

D: Implementation:

We could have retrofitted congestion and RTT sharing in TCP. However, the complexity of current TCP implementations, and the fact that TCP performs error recovery, congestion control and flow control using a single window-based mechanism, made this retrofit conceptually more complex. Given that our goal was to understand the issues underlying congestion in mesh networks, incremental deployment was not paramount. Thus, at the cost of some additional packet header overhead, we decided to explore a clean-slate approach. Our implementation uses a rate-based protocol for congestion control, but uses an implementation of TCP SACK for error recovery, a window-based flow control mechanism exactly like TCP, and the same RTO estimation as in TCP.

Conclusions

The Congestion control has been area for networking researchers for nearly three decades. Congestion control in wireless mesh networks is harder than in wired networks. In this paper, we have taken significant steps toward understanding congestion control for mesh networks. Our main contribution is implementation of fair and efficient rate control for mesh networks that yields nearly optimal throughputs. We plan to further investigate the kind of fairness achieved by WCP over very large topologies.