Active Queue Management (AQM) based Congestion Control Protocol for

Wireless Networks

Prof.K.Manikandan
School of Computing Science & Engineering,
VIT University,
Vellore, Tamil Nadu
Email: masaleemdurai@vit.ac.in

Dr.M.A Saleem Durai

School of Computing Science & Engineering
VIT University, Vellore, Tamil Nadu.
Email: kmanikandan@vit.ac.in

Abstract

Congestion Control is one of the major issues in the Communication Networks. The Approaches toward the
Congestion control are End to End Congestion Control and Network assisted congested control. The Explicit
Congestion Control Protocol uses ECN bits for feedback to control congestion. But it uses multiple bits in the
header which faces certain obstacles in implementation.The Proposed optimized congestion control Protocol
(OCCP) uses only two ECN bits for giving feedback about congestion. The reduced usage of ECN bits in the
proposed system makes it easy to implement. The performance is also better than existing one. The proposed system
is implemented in Network Simulator. For the implementation of proposed system, NS2 discrete event simulation
tool is used and experimented with a variety of parameter settings.

Index Terms—AQM, Congestion Control, ECN, Optimized Congestion Control Protocol

1.Introduction

Congestion Control is one of the major issues in the Wireless Networks. Congestion occurs due to many reasons.
Congestive collapse is a condition where a packet switched computer network can reach, when little or no useful
communication is happening due to congestion. Problem of congestion can be solved before the congestion takes
place or after the congestion had takes place. The method of handling congestion after the occurrence of congestion
is termed as Congestion Control. The two approaches toward the Congestion control are End to End Congestion
Control and Network assisted congested control. In end-to-end approach the congestion is found from end-to-end
system loss and delay. This approach is used by TCP.
In Network Assisted Congestion Control routers give feedback about the congestion control to the end
systems. ECN allows end-to-end notification of network congestion without dropping packets. The Explicit
Congestion Control Protocol uses ECN bits for feedback to control congestion. But it uses multiple bits in the header
which faces certain obstacles in implementation in Wireless networks. The Proposed Protocol uses only two ECN
bits and provides better results compared to the existing system. The explicit congestion control protocol uses
multiplicative-increase multiplicative-decrease for efficiency and AIMD for fairness control. The proposed protocol
applies multiplicative-increase, additive-increase, and multiplicative-decrease policies in three regions of congestion
known as low-load, high-load, and overload regions, respectively.

2.Explicit Congestion control Protocol and its Limitations

TCP is the basic end-to-end transport protocol of the Internet, and its congestion control algorithm is fundamental
to efficient, high-performance and stable network. However, TCP has begun to reach its limits recently. As the
bandwidth-delay product increases, TCP becomes inefficient and prone to instability, regardless of the queuing
scheme. Recently, to solve the problems of TCP, a new congestion control protocol called Explicit congestion
control protocol has attracted much attention in the Internet community. By introducing explicit, non-binary
feedback from the network to the endpoints, it achieves several important advantages of function and performance.
First, Explicit congestion control protocol is most responsive in both start-up and "steady-state" operation, and is
able to achieve the maximum performance supported by the infrastructure under the widest range of challenging
conditions. Secondly it introduces a novel and general framework for resource management, rather than being a
modification or tuning of TCP. Third, by making bandwidth allocation explicit, it provides fairness to "equal" flows
when TCP would not, and implements a nearly cost-free service differentiation mechanism when that is what is
required.
While the current implementation of explicit congestion control protocol requires 16 bits of IP headers [8],
the proposed system uses the use of two ECN bits in the IP header. The usage of the more bits in IP header makes it
difficult to deploy. The proposed system is much easy to implement than the current one. Fundamentally, it remains
a window based protocol and is designed to regulate the with different congestion-control policies according to the
level of congestion in the network. The proposed system defines three levels of congestion: low-load, high-load, and
overload allowing for encoding the level of congestion into two ECN bits in the IP packet header. Upon arrival of a
packet, each capable router does: Compute the load factor of each of its links, Map each computed load factor to one
of the three congestion levels, and Update the ECN bits in the packet header.

3. Literature Review and Related Works

The Explicit Control Protocol (XCP) was developed to overcome the limitations of TCP, such as unstable
throughput, low utilization, limited fairness, and large persistent queue length. However, Low proves that the
explicit congestion control protocol equilibrium solves a constrained max-min fairness problem, in a multi-
bottleneck environment, it may also cause some bottleneck links to be underutilized, and a flow may only receive a
small fraction of its maxmin fair bandwidth allocation. To address this problem, Zan proposes [1] an improved
version of it, which shuffles bandwidth only among flows that are bottlenecked at current routers. According to the
robust control theory, with the help of a recently developed Lyapunov-Krasovskii functional, an explicit congestion
control bandwidth compensation algorithm based on state feedback was proposed. The synthesis problem is reduced
to a convex optimization scheme expressed in terms of linear matrix inequalities (LMI).
Many of the recently proposed high performance congestion control protocols rely on an estimation of the
available link bandwidths. However, wireless networks are characterized by bandwidth variations due to the
openness of air links. Experiments have clearly shown that operating over variable bandwidth wireless links can lead
to a significant performance degradation of congestion control protocols. Such degradation is typically manifested in
the form of exhibiting oscillatory behavior. Other work proposes the use of an Extended Kalman Filter (EKF) [2] to
filter out the impact of bandwidth variations from the operation of wireless congestion control protocols. The EKF-
based Bandwidth Estimation (EBE) scheme can predict link capacity by monitoring the persistent queue size of a
wireless link thereby eliminating the need for directly measuring the real-time bandwidth. The implementation of
EBE is done with NS-2 and integrates it with explicit congestion control protocol.
Many high performance congestion control protocols require the estimation of the available link
bandwidth. While such estimated information is needed by the routers in router-assisted protocols, it is only used by
the end nodes in end-to-end protocols. The EBE scheme proposed in this paper introduces a passive protocol-
agnostic link capacity estimation method for use by congestion control protocols while minimizing the impact of
change to such protocols. Rather than directly measuring the link capacity, EBE takes the router’s persistent queue
size or the end-node’s perceived RTT as its input based on the characteristic of the utilizing protocol. While the
former is usually used for router-assisted protocols such as explicit congestion control protocol, the latter can be
used for end-to-end congestion control protocols such as TCP BIC. The former case is taken as it represents a more
complicated task in comparison to the latter case. Thus, the target protocols for using EBE include router-assisted
protocols operating in variable bandwidth wireless networks. Specifically, the key components of the proposed EBE
scheme are
(1) EKF Predictor: An EKF is used to estimate and predict the real-time persistent queue size.
(2) Link Capacity Monitor: To feed the EKF, EBE keeps track of the average persistent queue size computed
during the last control interval.
(3) EBE provides a queue maintainer that can detect the link bandwidth increase while maintaining a reasonable
queue size.

The protocol, Double-Packet Congestion control Protocol (DPCP) [3] uses two ECN bits and is capable of
relaying a more precise congestion feedback compared to earlier the proposed Explicit Congestion-control Protocol.
By distributing congestion related information into a series of packets, DPCP is able to circumvent the limitations of
explicit congestion control protocol. A congestion level is carried by a chain of two packets and each packet
provides two bits out of four bits of information associated with a congestion level. Utilizing a simple and practical
design, routers are made responsible for computing and distributing congestion signaling into two packets. At an end
node, a congestion level can be retrieved by concatenating a group of two ECN bits together from a set of packets.
The key concepts of the DPCP can be subdivided into the following:
(1) Segmentation and Reassembly of LF: As DPCP distributes the LF among a chain of packets, LF needs to be
segmented and reassembled at routers and end nodes. To keep backward compatibility, the utilized SR scheme
allows for easy exception handling and downgradability to the original explicit congestion control protocol.
(2) Packet ordering management: DPCP relies on the feedback distributed in a chain of packets. To retrieve the
correct LF, the relative ordering of packets has to be assessed and managed. DPCP provides a simple and efficient
mechanism that allows for easily identifying the packet ordering of a chain. Most importantly, there is no need to
buffer packets for maintaining the ordering of packets belonging to a chain internally at the routers.
(3)Exception handling: During transmission, exceptions such as packet loss and Out of Order (OO) packet delivery
may occur. By detecting the appropriate ordering of packets at the end nodes, DPCP reacts appropriately to
exceptions in order to avoid failure.
The new framework for congestion control, called Binary Marking Congestion Control (BMCC) [4] for high
bandwidth-delay product networks is proposed. The basic components of BMCC are
(1) A packet marking scheme for obtaining high resolution congestion estimates using the existing bits available in
the IP header for Explicit Congestion Notification
(2) A set of load-dependent control laws that use these congestion estimates to achieve efficient and fair bandwidth
allocations on high bandwidth-delay product networks, while maintaining a low persistent queue length and
negligible packet loss rate. It presents analytical models that predict and provide insights into the convergence
properties of the protocol.
BMCC maintains low bottleneck queue and negligible packet loss rate. It outperforms MLCP, SACK+RED/ECN
and in some cases RCP in terms of AFCT for typical Internet flow sizes. With BMCC, each router periodically
computes the load factor on its output links. To achieve efficient and fair bandwidth allocation with high
convergence speeds, a high resolution estimate of the computed load factor is needed.

BMCC uses a packet marking scheme called Adaptive Deterministic Packet Marking (ADPM) to obtain
congestion estimates with up to 16-bit resolution using the existing two ECN bits. ADPM conveys signals with a
lower Mean Square Error (MSE) than competitors such as REM and RAM. It monitors side information, such as the
IP id field, and uses that to interpret the ECN bit of each packet differently, as proposed by Thommes and Coates.
Each arriving packet at the receiver carries a bound on the value of the load factor at the bottleneck. The receiver’s
estimate of the load factor is updated whenever a new packet provides a tighter bound. The load factor estimate is
echoed back to the sources via acknowledgement packets using TCP options. Based on this value, sources apply
load-dependent Multiplicative Increase (MI), Additive Increase (AI) and Multiplicative Decrease (MD). Unlike in
explicit congestion protocol, the parameters of these control laws depend on the high resolution estimate of the load
factor. When the load factor is small, sources increase their rates rapidly to fill the bottleneck capacity. Otherwise,
sources apply AIMD to achieve fairness. The rates of adjustment are chosen to ensure RTT fairness.
In Wireless LAN connected with Internet, the anomaly of wireless channel and the greedy nature of closed
loop control in TCP lead to the congestion problem and significant unfair bandwidth distribution between TCP
flows.
Deployed in intermediate routers, ECN scheme provides the explicit congestion notification to the TCP sender. The
ECN scheme has been proven to be an effective mechanism to enhance the performance of TCP. Based on the ECN
scheme, a novel congestion control algorithm is proposed [5].
ECN mechanism is expanded by using the two bits to display the congestion level, so the ECT(0) and
ECT(1) will have different meaning in this mechanism to reflect the busy degree of Ad hoc network channel, and
also, the senders have more fine information about network state and can respond the feedback more accurately. The
control mechanism is less cost and friendlier to TCP protocol. And also the data flow fluctuation is smaller. In the
renovation mechanism, which is called TCP- 3sates/ECN2 in the paper, the codepoint '00' still indicates a packet
without using ECN. The other three codepoints can represent the three states of a link: available, busy, and
congestion. We call the modified mechanism as ECN2. In busy state, the senders can keep their sending rate to
fluctuate in a small range so that the resources in the link can be adequately utilized without much oscillation. The
traditional AIMD scheme has been improved to let the end hosts properly adjust sending rate [6].

4.Proposed Approach
The source sends the packet data to the destination node. The data packets reach the router. Once the data packets
are reached, the router calculates the load factor for all the links. Based on the load value it maps the congestion
region and edits the ECN bits. The Sink sends feedback via acknowledgement packets to the source node. Then the
sender reduces/increases the transmission rate according to the feedback obtained. The whole process is
continuously repeated and the transmission rates are changed according to the congestion region identified.
The proposed system defines three levels of congestion: low-load, high-load, and overload allowing for
encoding the level of congestion into two ECN bits in the IP packet header. A more congested downstream router
can further change the level of congestion by overwriting it. Finally, the receiver signals the sender with the
congestion information via acknowledgment packets. Consequently, the proposed system applies three congestion-
control policies: MI in the low-load region, AI in the high-load region, and MD in the overload region. The MI
region is utilized to eliminate the slow start characteristic of TCP, while AI and MD regions preserve the fairness
characteristics of TCP. The four design principles of the proposed system are: 1. Transparency to applications, 2.
Easy integration with the Linux kernel, 3. Friendliness to other transport protocols, 4. Preserving backward
compatibility.The proposed approach for OCCP is shown in Fig 4.1
 Fig 4.1 Proposed OCCP Approach

5.Simulation

The Proposed Protocol (OCCP) uses only two ECN bits for giving feedback about congestion. The reduced usage
of ECN bits in the proposed system makes it easy to implement. The performance is also better than existing one.
The proposed system is implemented in Network Simulator. For the implementation of proposed system, NS2 [7]
discrete event simulation tool is used and experimented with a variety of parameter settings. In all of the
experiments, each data packet has a size of 1040 bytes and each acknowledgment packet has a size of 40 bytes.
 Fig 5.1:Wired system model
The scenario is a single bottleneck network topology, with ten forward and ten reverse flows.

Fig 5.2: Dumbell Topology

The network parameters set in the scenario are:
Bottleneck Link : 1
Bottleneck Bandwidth : 10 Mbps
No. of Forward Flows : 10
No. of Reverse Flows : 10
Delay : 10ms
Round Trip Time : 100ms

6. Performance Evaluation

6.1 Explicit Congestion Control Protocol

The Simulations are done and the data required for plotting graphs are taken from trace file using awk command.
The following values are calculated for both explicit congestion control protocol and proposed system are Packet
Delivery Fraction, Throughput, and link utilization
1. Packet Delivery Fraction: The ratio between the packet received and the packet sent is known as Packet delivery
fraction. The no of packets sent and received are calculated using the trace file. The packet delivery fractions for
each links in the network are calculated. The value of packet delivery fraction is almost 100 for all the links in
the network.
2. Throughput: The throughput for the explicit congestion control protocol in the single bottleneck topology is
Average Throughput [kbps] = 33057.10 Start Time=0.0 Stop Time=60.00.
3. End to End Delay: End-to-end delay refers to the time taken for a packet to be transmitted across
a network from source to destination. The End to end delay for the explicit congestion control protocol is plotted
using GNU plot [8].

Fig 6.1: End to End Delay for Explicit Congestion Control Protocol.

4. Jitter: Jitter represents the variance of delay of the transferred packet. The following graph describes the variance
of delay in the explicit congestion protocol.
 Fig 6.2: Jitter for Explicit Congestion Control Protocol.

6.2 Proposed approach(OCCP)

1. Packet Delivery Fraction: The ratio between the packet received and the packet sent is known as Packet delivery
fraction. The packet delivery fractions for each links in the network are calculated. The packet delivery fraction
is almost 100 for all the links in the network.
2. Throughput: The throughput for the proposed system in the single bottleneck topology is Average Throughput
[kbps] = 45623.76 Start Time=0.0 Stop Time=60.00
3. End to End Delay: End-to-end delay refers to the time taken for a packet to be transmitted across the network
from source to destination.
 Fig 6.3: End to End Delay for OCCP

4. Jitter: Jitter represents the variance of delay of the transferred packet. The following graph describes the
variance of delay in the proposed system.

Fig 6.4: Jitter for OCCP

6.3Comparison Graphs
1. Throughput: The throughput comparison graph for explicit congestion control protocol and proposed is given
below

Fig 6.5: Throughput comparison for explicit congestion control protocol and OCCP

2. Link Utilization: The link utilization percentage for the proposed and existing are calculated and they are plotted
as graph.

Fig 6.6: Link Utilization comparison for explicit congestion control protocol and OCCP

6.4 Congestion Window

 The congestion window is plotted as graph. The graph describes the usage of MI in the low-load region, AI in
the high-load region, and MD in the over load region.

Fig 6.7: Congestion window

7. Conclusion and Future work

From the above graphs and calculated values the performance of the Proposed system OCCP is evaluated. The
average throughput of the proposed protocol is much higher than the existing XCP. The link utilization percentage is
also comparatively higher compared to the existing one. The Packet Delivery Ratio for both the systems does not
vary much. The jitter for the existing one has a sharp change when it is heavily loaded with traffic. The jitter for the
proposed is same as throughout the end of the simulation. The Jitter for the proposed is better than the explicit
congestion control protocol. The end to end delay for proposed is very much better than the current one. The graph
shows a steady end to end delay in the proposed one, where the existing has a huge variation in the graph during
heavy loads. In overall the proposed solution shows better performances than the existing one. In case of packet
drops the multiple bottleneck scenarios are simulated and the packet drops are very much less compared to that of
explicit congestion control protocol.
There are many network attacks possible in the existing system. Many misbehaving users can dominate
bandwidth allocation on shared link. Problems like Abusing Host and Lying Host are serious problems in networks.
These works can be added to the current system. Security work for black hole threat problem can also be done
References
[1] Seungwan ryu,Christopher rump,chunming qiao “Advances in Active Queue Management (AQM) Based TCP Congestion
Control, Elsevier, Telecommunication Systems 317–351, 2010.
[2] Ki Hwan Yuma,_, Yuho Jin b, Eun Jung Kimb, Chita R. Das “Integration of admission, congestion, and peak power control
in QoS-aware Clusters” J. Parallel Distrib. Comput. 1087-1099, 2010
[3] Hairui Zhou, Guanzhong Dai, Fanghong Ye and Huixiang Zhang, “S-XCP: Improving XCP to Achieve Efficient and Fair
Bandwidth Allocation”, IEEE GLOBECOM, 2009.
[4] Zhipeng Huang Xiaolong Li Homayoun Yousefi’zadeh, “Robust EKF- BasedWireless Congestion Control”, IEEE ICC, 2010.
[5] Xiaolong Li Homayoun Yousefi’zadeh, “Distributed ECN-Based Congestion Control”, IEEE ICC, 2009.
[6] Ihsan Ayyub Qazi, Taieb Znati, “Congestion Control using Efficient Explicit Feedback”, IEEE INFOCOM, 2009.
[7] Jiawei Huang and Jianxin Wang, “An ECN-Based Congestion Control Algorithm for TCP Enhancement in WLAN”, IEEE
International Conference on High Performance Computing and Communications, 2009.
[8] Weirong LIU Min WU Jun PENG Guojun WANG, “A Stable Congestion Control Mechanism in Ad Hoc Network”, IEEE ,
2009 Second International Conference on Information and Computing Science.
[9] Network Simulator 2 (NS2), http://www.isi.edu/nsnam/ns/Christo Wilson, Chris Coakley and Ben Y. Zhao, “Fairness Attacks
in the Explicit Control Protocol”, IEEE, 2009.
[10] Ahmed Khurshid, Md. Humayun Kabir, and Md. Anindya Tahsin Prodhan, “An Improved TCP Congestion Control
Algorithm forWireless Networks”, IEEE Vol 1.2, pp 382 – 386, 2009.
[11] Li Yun, Zhang Rui, Liu Zhanjun, Liu Qilie, “An Improved TCP Congestion Control Algorithm Over Mixed Wired/Wireless
Networks”, IC-BNMT, 2009.