FXRED is a modification of RED algorithm which is used to control the congestion in the network. The main difference between RED and FXRED is that the latter uses a flexible threshold value instead of a fixed threshold value. The threshold value is calculated using the average queue size and the average packet size. The algorithm is described in the paper Flexible Random Early Detection Algorithm for Queue Management in Routers.
In the proposed FXRED, the router's queue with finite capacity is divided into four segments (A, B, C, D) via threshold values
Just like traditional RED and its other variants, in FXRED, average queue length
There are some other parameters that are used in the algorithm:
-
$\lambda(t)$ : Total data arrival rate in the queue at time$t$ . -
$\mu$ : Bandwidth of the bottleneck link. -
$\rho(t)$ :$\rho(t) = \lambda(t)/\mu$
Based on traffic load, three states are defined:
A dumbbell shaped topology is used where all the source nodes are connected to a single router and similarly all the destination nodes are connected to a single router. Both the routers are connected to each other through a link. The topology is shown below.
Nodes are randomly generated in a square area. For each simulation, a node is selected as source and a number of random nodes are selected as destination. Node configurations are as follows:
Node Movement
: StaticWireless MAC Type
: IEEE 802.15.4Routing Protocol
: DSDVAgent
: TCPApplication
: FTP
An example of the topology is shown below.
To study the effect of different parameters on the performance of the network, the following parameters are varied in the simulation:
Base Parameters:
Number of Nodes
: 20Number of Flows
: 10Packets Per Second
: 100Coverage Area
: Tx_Range = 250
Keeping one of the base parameters constant, the other parameters are varied in each simulation as follows:
Number of Nodes
: 20, 40, 60, 80, 100Number of Flows
: 10, 20, 30, 40, 50Packets Per Second
: 100, 200, 300, 400, 500Coverage Area
: Tx_Range, 2x Tx_Range, 3x Tx_Range, 4x Tx_Range, 5x Tx_Range
The following modifications are made in the NS-2 code to implement the FXRED algorithm:
Two files are changes in the ns2.35/queue
directory:
-
In
struct edp
the following two variables are added:/* * Parameters for FXRED */ double c; /* FXRED: constant c which should be greater than 2 */ int fxred; /* FXRED: enable/disable FXRED */
-
To keep track of the number of bytes arrived since the last time a packet was dropped, the following variables are added in
struct edv
int count_bytes; /* # of bytes since last drop */ double count_start_time; /* time when the count is 0 */
Notice that the
count
variable is already there to keep track of the number of packets arrived since the last time a packet was dropped. -
A new method in
REDQueue:Queue
is added to calculate data arrival rate:/* * Calculate data arrival rate */ double getDataArrivalRate();
Only the class REDQueue
is modified. The following changes are made:
-
To pass parameter from tcl file to the class, the following code is added in
REDQueue::REDQueue()
:bind("c_", &edp_.c); bind_bool("fxred_", &edp_.fxred);
-
The two new parameters are initialized in
REDQueue::initparams()
:edp_.fxred = 0; edp_.c = 2.0; edv_.count = 0; edv_.count_bytes = 0;
-
In
REDQueue::reset()
just below the lineedv_.count = 0;
the following line is added:edv_.count_bytes = 0; edv_.count_start_time = Scheduler::instance().clock();
These two lines are added everywhere where
edv_.count = 0;
is present. -
The
REDQueue::calculate_p_new()
is modified to calculate the probability function of FXRED.double REDQueue::calculate_p_new(double v_ave, double th_max, int gentle, double v_a, double v_b, double v_c, double v_d, double max_p) { double p; if (edp_.fxred) { double miu = link_->bandwidth(); double rho = getDataArrivalRate() / miu; double gamma = 1; double err = 0.01; double c = edp_.c; if (rho < 1.0 - err) gamma = 0.15; else if (rho > 1.0 + err) gamma = c; int k = pow(c, 1 / gamma); double epsilon = pow(c, -gamma); double th_min = edp_.th_min; double delta = (th_max + th_min) / 2; if (v_ave < th_min) p = 0.0; else if (th_min <= v_ave && v_ave < delta) { p = pow((v_ave - th_min) / delta, k); p *= 1 - epsilon; } else if (delta <= v_ave && v_ave < th_max) { p = 2 * epsilon * (v_ave - delta) / (th_max - th_min); p += 1 - epsilon; } else p = 1.0; } else { // default RED implementation } return p; }
-
REDQueue::modify_p()
:double REDQueue::modify_p(double p, int count, int count_bytes, int bytes, int mean_pktsize, int wait, int size) { if (edp_.fxred) { p /= (1 - count * p); } else { // default RED implementation } return p; }
-
Finally, the new definition of the function
REDQueue::getDataArrivalRate()
is added:/* * Calculates and returns the data arrival rate in bytes/sec. */ double REDQueue::getDataArrivalRate() { double elapsed_time = Scheduler::instance().clock() - edv_.count_start_time; if (elapsed_time == 0.0) return 0; double rate = edv_.count_bytes / elapsed_time; return rate; }
From the graphs found after analysing wired topology, we can see that the proposed algorithm works better in terms of end to end average delay but it has a higher drop ratio. This is because the proposed algorithm is more aggressive in dropping packets. The proposed algorithm also has a higher throughput than the default RED algorithm. In terms of delivery ratio, both algorithms have a similar performance.
On the other hand, wireless topology suggests quite a different result. The proposed algorithm has a higher end to end average delay than the default RED algorithm. Delivery ratio and throughput are also lower in FXRED. Drop ratio and energy consumption are slightly higher too.
As we use RED algorithms to control congestion, the dumbbell shaped wired topology is more suitable for simulating the performance of RED algorithms. So, we can rely on the results found in wired topology to conclude that the proposed algorithm is slightly better than the default RED algorithm.