Abstract

Congestion is a key topic in computer networks that has been studied extensively by scholars due to its direct impact on a network’s performance. One of the extensively investigated congestion control techniques is random early detection (RED). To sustain RED’s performance to obtain the desired results, scholars usually tune the input parameters, especially the maximum packet dropping probability, into specific value(s). Unfortunately, setting up this parameter into these values leads to good, yet biased, performance results. In this paper, the RED-Exponential Technique (RED_E) is proposed to deal with this issue by dropping arriving packets in an exponential manner without utilizing the maximum packet dropping probability. Simulation tests aiming to contrast E_RED with other Active Queue Management (AQM) methods were conducted using different evaluation performance metrics including mean queue length (), throughput (), average queuing delay (), overflow packet loss probability (), and packet dropping probability (). The reported results showed that E_RED offered a marginally higher satisfactory performance with reference to and than that found in common AQM methods in cases of heavy congestion. Moreover, RED_E compares well with the considered AQM methods with reference to the above evaluation performance measures using minimum threshold position () at a router buffer.

1. Introduction

With the fast development in computer hardware and data communications, Quality of Service (QoS) in computer networks has become an important concern for end users [1, 2]. QoS can be defined as the network performance for the different services sought by the user while data is traversing via this network [1]. QoS has different levels provided to the users based on the requirements of applications used, providers of network services, or Service Level Agreement (SLA) among users [2]. Best effort is one of the services used in the Internet to deliver packets and not differentiate between packets generated by different classes of service [3]. QoS can be evaluated by different metrics such as bandwidth, packet loss, jitter, and delay.

In modern communication and computer networks, different network applications have been developed such as voice over IP (VoIP), video conferencing, live video, e-mail, and file transfer. These applications require different QoS. For instance, VoIP, video conferencing, and live video necessitate high bandwidth and low delay and jitter. Moreover, network applications have low sensitivity to packet loss. On the other hand, the applications of e-mail and file transfer have high sensitivity to the requirements of packet loss and low sensitivity to bandwidth, delay, and jitter. Enhancing the performance of a network can be performed based on obtaining the QoS for that network. Many researchers have proposed congestion control techniques [49, 10‐‐12] that are implemented via simulation to enhance network performance with different QoS requirements [1, 13, 14]. Other congestion control techniques have been developed as analytical models to deal with QoS issues [1, 2]. For example, in [1518], the authors proposed discrete-time queue analytical models aimed at early control of congestion. Researchers [1, 19, 20] also developed analytical models to solve problems related to the delay in the computer network.

RED is one of the key AQM techniques that were proposed to enhance the classic drop-tail method [21] performance. Nevertheless, and despite superiority of RED over the drop-tail method, the advances in traffic service diversity have revealed the following performance issues associated with RED’s performance [2, 22].(1)Usually the key congestion measure (average queue length ()) used by RED varies according to the level of congestion. For instance, when is near to the , light congestion occurs, whereas if the is near the , heavy congestion occurs. These may cause the router buffer to overflow and, therefore, the dropping of arriving packets.(2)Another issue is tuning certain parameters of RED into specific values, that is, the maximum value of packet dropping (), to ensure a satisfactory performance. This produces biased results.(3)Often depends on the number of TCP connections. When the numbers of TCP connections are increased, the increases as well and may exceed the position; hence, every arriving packet is dropped.

This paper deals with the second problem described above which is tuning to a certain value to guarantee high yet biased QoS. We would like to minimize this problem by proposing a new method that relaxes the dependency on the and instead employs a new exponential measure called (see equation (5)) that is based on average queue length (). In particular, when is between the minimum and the maximum thresholds, the proposed congestion control method drops arriving packets exponentially. This will result in more realistic performance results rather than those that are biased. We call the proposed algorithm RED-Exponential (RED_E).

The proposed method is implemented using a simulation and a discrete-time queues approach [23]. The discrete-time queues approach is used to model the arrival and departure of packets in every single time unit called a slot. Further details on using the discrete-time queues approach with the proposed method is given in Subsection 4.1. The benefits of the proposed RED_E algorithm are as follows:(i)Calculating not involving using parameter , relaxing users’ subjectivity when setting up RED’s parameters;(ii)Enhanced performance measures of and when compared to RED and one of the RED-based AQM methods such as NLRED especially in cases where the value of packet arrival probability is very high.

This paper is organized as follows. Related work, including RED and NLRED methods, is introduced in Section 2. Section 3 presents the proposed RED_E. Simulation details are introduced in Section 4 as well as performance measures results. Finally, conclusions and future work are provided in Section 5.

2.1. RED and Nonlinear RED

RED is one of the known AQM techniques that was proposed to detect and control congestion [7]. RED relies on certain parameters to calculate its value. These parameters are , , , and . For every arriving packet at the router buffer, RED computes the value. When the value is less than the , no congestion occurs and thus no packets can be dropped. However, if the value is less than and equal to or larger than the , this gives an indication there is congestion, and the router buffer drops arriving packets probabilistically. Lastly, when the value of is equal to or greater than the , heavy congestion is presented, and every arriving packet will be dropped in order to manage this congestion. This is achieved either by dropping the arriving packets at the router buffer or by marking them using Explicit Congestion Notification (ECN) [18]. The pseudocode of the RED technique is shown in Algorithm 1.

(1)Initialisation stage
(2)For every arriving packet at a RED router buffer
Calculate the for this packet at the RED router buffer
Examine the queue status at a router buffer, is it empty or not
 if the queue at a RED router buffer is empty then
  Compute , where
  
 Else
  
3. Determine a congestion status at the RED router buffer
if value is less than value then
 Calculate value for the arriving packet as follows:
else if value is greater than or equal to value and less than value then
 Mark/Drop the arriving packet probabilistically regarding to value due to occurrence of congestion
else
 Mark/Drop every arriving packet due to occurrence of heavy congestion
4. When the RED router buffer becomes empty

Algorithm 1 shows that RED utilizes several factors to compute and . The factors are explained below:: current time.: starting idle time at the RED router buffer.: number of packets sent to the RED router buffer during an idle interval time.: number of packets arrived at the RED router buffer not dropped since the last packet was dropped.: instantaneous packet dropping probability.: initial packet dropping probability.: instantaneous queue length.: queue weight.: maximum value of .: linear function for the time.

One of the main issues of RED is that setting the parameters cannot guarantee stable performance under varying traffic loads [24]. This can be attributed to the linear packet dropping probability function that is often aggressive when the traffic load is light and not aggressive when the traffic is low, which may cause the value of average queue length to reach the value of the maximum threshold. To overcome this problem, [24] proposed Nonlinear RED (NLRED) that utilizes a nonlinear packet dropping function similar to those proposed in [4, 25]. The pseudocode of the NLRED method is given in Algorithm 2.

For each arriving packet
Compute the average queue length ()
if
 No packet will be dropped
else if
 Compute the packet dropping probability using quadratic function
 Drop the arriving packet with the computed probability
else
 Drop the arriving packet

Algorithm 2 shows the NLRED router buffer is working as RED’s router buffer when the value of is less than the or greater than or equal to the . In cases when the is between the and , then NLRED uses the quadratic function to compute the packet dropping probability, and this function is given inwhere is the maximum value of packet dropping probability. If the same value is used for in RED and in NLRED, then NLRED will be gentler than RED for all traffic loads since the packet dropping probability value of NLRED is less than that of RED. If the total of packet dropping probabilities of RED and NLRED are similar, then the value of will be set as follows:

The packet dropping probability functions of RED and NLRED methods are shown in Figure 1.

2.2. Other AQM Techniques

To solve the first shortcoming of RED, varies according to the level of congestion, so the Adaptive RED (ARED) technique was proposed in [8]. ARED aimed to stabilize the value at a specific level between the and positions. This may prevent the dropping of large numbers of packets.

Gentle RED (GRED) technique [9] was proposed to reduce packets being dropped. This was accomplished by preventing the dropping of every arriving packet when the value equals the position as in RED [7]; instead, GRED drops arriving packets probabilistically based on values in the range of to 1.0.

Dynamic Random Early Drop (DRED) technique [5] was proposed to deal with dependency on the number of TCP connections; BLUE technique [6] was developed to offer better network requirements of packet loss rates and queue size than those of RED [7].

Effective RED (ERED) technique was proposed to reduce packet loss rates in a simple and scalable manner. The authors made a few changes to the packet dropping function of RED and the rest of RED’s parameters remain unchanged. They refined and controlled the packet dropping function using average queue size and instantaneous queue size parameters. Simulation results demonstrated that ERED achieved higher throughput and lower packet dropping than RED.

The authors of [27] proposed an AQM algorithm based on RED called NPD-RED. This algorithm is dependent on self-tuning feedback control for proportional and differential. NPD-RED relies on the current queue length and the instantaneous differential error signal to length of the buffer. The authors presented an analysis for stability of the system and also provided procedures for choosing the gains of the feedback of TCP/RED in order to maintain the current queue length. NPD-RED was compared with RED, using simulation NS2; the simulation results showed that NPD-RED outperformed RED with reference to average queue length, average throughput, and stability.

An AQM algorithm based on RED was proposed by [28]. This Improved Adaptive RED algorithm uses nonlinear smooth function for packet loss rate through exploiting the ascend demi-cauchy of fuzzy distribution. In the ARED algorithm, the increasing velocity of packet loss rate near the maximum threshold position is quick, whereas it is slow near the minimum threshold position. Also, the maximum value of packet dropping probability () of ARED modified the size of the mean queue and the target for adapting the altering of network conditions.

Two discrete-time queue analytical models based on RED, called RED-Exponential and RED-Linear, were aimed at improving RED’s issue in cases of heavy traffic were presented by [29]. These two analytical models dealt with this issue by using instantaneous queue length instead of average queue length as a congestion measure. The two models outperformed the classic RED regarding the performance results of mean queue length and average queuing delay when congestion occurs.

A learning-automata-like method for avoiding congestion incidence in wired networks called LALRED was introduced by [30]. The aim of LALRED was to enhance the value of average queue size used for congestion control and as such decrease the total packet loss at the queue.

An analytical framework model for RED queues using blended types of traffic such as TCP and User Datagram Protocol (UDP) was introduced by [31]. Steady-state goodput expressions for every flow and average queuing delay at every queue were obtained. The analytical framework was extended to include a class of RED queues, which offers different services for flows with multiple classes [31]. The analytical framework was validated with several network configuration simulations of RED. The results of these simulations showed that the analytical framework matched with several of the network configuration simulations of RED with a 5% value for mean error.

An adaptive queue management with random dropping method that uses information related to the average queue length and its rate of change was proposed [32]. This method was named AQMRD, and it uses the rate of change in the queue length as an extra parameter to detect the congestion. This method avoids the average queue length frequently exceeding the maximum threshold value by quickly responding to congestion thus avoiding buffer overflows.

An AQM method named ModRED that employs three dynamic packet dropping probabilities depending on the incoming traffic was presented by [33]. This method can use different traffic shapes. ModRED utilizes an Additive-Increase Multiplicative-Decrease (AIMD) algorithm with the purpose of using different packet dropping probability for dissimilar traffic loads [33]. Depending on the kind of traffic load, the packet dropping probability is calculated. ModRED handles congestion at the receiver side and as such it is used for TCP congestion control. ModRED provided better performance than RED with respect to throughput, goodput, packet delivery ratio, and delay simulation results.

A new RED method based on the Hemi-Rise Cloud model (CRED) was introduced by [34]. CRED uses a nonlinear packet loss approach, and this method enhances the uncertainty and sensitivity of the parameters. Controlling of network congestion and efficient use of network resources were accomplished [34]. CRED’s stability was investigated, and this showed that CRED might enhance the stability and it gives a more acceptable performance than either RED or ARED.

RED is sensitive to its parameters and the traffic, so when traffic load is low, then bandwidth is underutilized. However, when traffic load is high, this will give a large delay [26]. Three-section random early detection (TRED) method based on nonlinear RED was proposed in [26]. In TRED, packet dropping probability function is split into three parts with the aim of discriminating between different loads: light, moderate, and high. This distinguishing between loads aims to obtain a tradeoff in the throughput and delay among low and high loads.

3. The Proposed RED-Exponential Technique

As mentioned previously in Section 1, RED has drawbacks that contribute in deterioration of its performance. This paper deals with the second problem (presetting RED’s parameters), to ensure achieving a realistic performance without the need to tune parameters to a certain value, in particular, the . Therefore, the RED_E method was developed, which employs the as the congestion measure. Yet it differs on the way packets are dropped whenever a packet arrives at a router buffer, particularly when the value is equal to or larger than the and less than the . In this scenario, classic RED drops packets probabilistically using the following equations.

In equations (3) and (4), is the initial packet dropping probability and, in equation (4), represents the number of packets which arrived at the router buffer and have not dropped since the last packet was dropped [7]. On the other hand, RED_E as shown in Algorithm 3 does not utilize the parameter in computing as employed in RED and many of its successors. Instead of calculating as equation (3), RED–E employs its own computed as shown in equation (5).

(1)Initialisation stage
(2)For every arriving packet at a RED-Exponential router buffer
Calculate the for this packet at the RED-Exponential router buffer
Examine the queue status at a router buffer, is it empty or not
 if the queue at a RED-Exponential router buffer is empty then
  Compute , where
  
 Else
  
(3)Determine a congestion status at the RED-Exponential router buffer
if value is less than value then
 Calculate value for the arriving packet as follows:
else if value is greater than or equal to value and less than value then
 Mark/Drop the arriving packet probabilistically regarding to value due to occurrence of congestion
else
 Mark/Drop every arriving packet due to occurrence of heavy congestion
(4)When the RED-Exponential router buffer becomes empty

It can be seen in equation (5) that RED_E no longer uses the parameter, which is typically set in the preliminary stage as in RED to guarantee satisfactory performance. RED_E drops arriving packets exponentially using equations (4) and (5). Figures 2 and 3 display the mechanism versus the mechanism for RED and RED_E, respectively. The proposed technique increases the value exponentially from 0.0 to 1.0 as the value increases from the value to the value. The pseudocode of RED_E, given in Algorithm 3, has other goals besides removing the biased results by presetting the parameters, such as offering a more satisfactory performance in heavy congestion scenarios.

4. Simulation Results

4.1. Simulation Setup

RED, NLRED, and RED_E methods are simulated using a single queue node system that is shown in Figure 4. One packet can arrive and/or depart at a time unit called a slot that is used in a discrete-time queue [23]. The implementations of RED, NLRED, and proposed methods are conducted based on discrete-time queues in the Java environment. Packets interarrival and service times are geometrically distributed with means and , respectively, where is the probability of packet arrival in a slot and is the probability of packet departure in a slot. The arrival process used in both methods is the Bernoulli process [23]. In Figure 4, the finite capacity of a single queue node for RED, NLRED, or RED_E is packets. First come, first served (FCFS) is the queuing discipline which is used in RED, NLRED, or RED_E.

4.2. Parameter Settings

The parameters of RED, NLRED, and RED_E are tuned in Table 1.

In Table 1, the values vary between 0.18 and 0.93, with half of these values (i.e., 0.18, 0.33, and 0.48) being less than and the rest (i.e., 0.63, 0.78, and 0.93) being greater than . These and values were set in order to test the performance measure results when 1) and 2) (congestion scenarios). is set to 20 packets to test congestion with small buffer sizes. is triple that of as in [8]. The and in Table 1 are set to the values as in [7]. The is set to a value calculated using equation (2). The set value of number of slots is given in order to guarantee it reaches a steady state.

4.3. Simulation Environment

Special things are used in this simulation such as packet arrival probability and packet departure probability in discrete-time queues. Such special things were not employed by existing simulators. Moreover, these special things can be applied in simulation environments such as Java, and for this reason Java has been chosen as the simulation environment of RED, NLRED, and RED_E methods in this paper.

4.4. Results Analysis

A warming-up period is conducted before generating the performance measure results. When the system reaches a steady state, the performance measure results are then obtained. Each performance measure result represents the arithmetic mean of ten time runs for each value. For every run, a seed value is changed utilizing a random number generator to remove any biased results. A decision on which method offers better satisfactory results is reached only using the setting values of .

RED, NLRED, and RED_E algorithms are compared with reference to the following performance measures: , , , , and . The abbreviation denotes mean queue length; is the throughput that represents the number of packets that have been successfully passed through a queue node for every time unit; is the average queuing delay for packets; is the probability of packet loss due to buffer overflow; and is the packet dropping probability before a router buffer becomes full. This comparison aims to evaluate RED_E performance in different congestion situations and without utilizing the parameter.

Figures 59 show the performance measure results (, , , , and ) versus for RED, NLRED, and the RED_E. The column chart type is used rather than scatter chart type due to the performance measure results of the compared methods being slightly different based on , and these differences are shown more clearly by using column chart type than scatter chart type. The performance measures are functions of .

4.4.1. Performance Evaluation Results Based on Varying Values

After analyzing Figures 5 and 7, RED, NLRED, and the proposed RED_E provide similar and results when is less than or equal to 0.33. In other words, RED and RED_E give similar and results in noncongestion situations at a router buffer of a queue node. This is due to both RED and E_RED dropping the same numbers of packets before the router buffer is full (see Figure 9), that is, zero, and loses the same number of packets due to overflow (see Figure 8), that is, zero.

When is greater than 0.33 and less than or equal to 0.48, RED provides a slightly lower and results than NLRED and RED_E since RED drops slightly more packets than NLRED and RED_E before the buffer is full. RED_E and NLRED gave similar results concerning and because RED_E and NLRED drop similar packets before the buffer is full. Moreover, RED, NLRED, and RED_E lose comparable number of packets due to overflow ().

When is larger than 0.48 and less than 0.63, NLRED provides slightly smaller and results among the compared methods because of the previously mentioned reason. RED and RED_E have analogous and results. RED and NLRED lose fewer packets than RED_E, and this is because the router buffers of RED and NLRED are overflowed on number of occasions, less than that of RED_E. Furthermore, RED_E has fewer dropped packets than RED and NLRED, and both RED and NLRED drop similar packets before their router buffers are full.

When is greater than 0.63 such as , RED_E achieves the most satisfactory measured performance among the compared methods in terms of and results since RED_E maintains less mean queue length. Additionally, NLRED to some extent gave better results for and than RED because of the previous mentioned reason. RED provides higher result than NLRED and RED_E since RED’s buffer overflows more times than NLRED and RED_E. NLRED has a reduced result than RED_E. In addition, RED drops fewer packets than the other two methods, and RED_E has slightly better result than that of NLRED. In the presence of heavy congestion such as such as , RED_E accomplishes lower , and results than RED or NLRED due to RED_E dropping a higher number of packets () than either RED or NLRED. Furthermore, NLRED produces better , , and results than RED since NLRED drops further packets than RED.

It is noted in Figure 6 that RED, NLRED, and RED_E offer similar results in the existence of congestion or without congestion.

4.4.2. Performance Evaluation Results Based on Varying Values

Further simulation tests between RED, NLRED, and RED_E based on different values for to evaluate their effect on performance results were conducted. was set to 0.78 since this value can produce heavy congestion and we needed to evaluate the effectiveness of the parameter on the compared techniques in the presence of heavy congestion. The was set to different values, ranging from 3 to to observe the effectiveness of each value on the performance measure results. The performance measure results of RED, NLRED, and RED_E versus values are given in Figures 1014. The chart type used in this subsection is scatter because the results of the compared methods can be shown clearly.

It is noted from Figures 10, 12, and 13 that RED offers higher , , and results than NLRED and RED_E for all values. This is because the RED router buffer drops fewer packets than NLRED and RED_E (see Figure 14). In addition, RED_E provides smaller and results than NLRED when the value is 3 or 4, and these values represent the farthest given values from the . In case that the value of is set to 8 (the nearest value to the ), then NLRED generates lower and results than that of RED_E; this is due to the length of mean queue of NLRED being smaller than that of RED_E. The performance results of NLRED and RED_E regarding and are comparably similar when the value is set to 5, 6, and 7 (halfway between the and the ). NLRED generates a smaller than that of RED_E when the is set to the farthest value from the , whereas derived smaller than NLRED when the is given as 4.

It is clear from Figure 14 that RED drops fewer packets than NLRED or RED_E since both NLRED and RED_E offer smaller results than RED. RED_E obtains smaller than NLRED when the is given to a value that is the farthest value from the . However, NLRED achieves smaller than RED_E when the value is set to 4.

For the other values (5, 6, 7, and 8), both NLRED and RED_E generate similar and results since they lose and drop a similar number of packets. In addition, performance results for RED, NLRED, and RED_E are similar regardless of the value and stabilized on value and are not affected by the parameter. Lastly, results for RED, NLRED, and RED_E are decreased if the value of the is increased. It can be inferred that the performance measures’ results of RED, NLRED, and the RED_E are all affected by the parameter except for the results (see Figure 11).

5. Conclusions and Future Work

This research paper addressed one of the AQM problems in congestion, namely, the configuration of the parameter to generate a good yet biased performance. We proposed a new exponential AQM method called RED-Exponential (RED_E) to minimize reliance of these methods on the parameter. The proposed technique differs from RED and its successors by dropping arriving packets in an exponential manner rather than tuning the parameter. This exponential packet dropping process will minimize the dependency on pretuned parameters, particularly the parameter, when calculating the performance measures of the AQM methods.

Simulation results have been generated to measure the advantages and disadvantages of RED_E. The focus of the simulation results was on utilizing different and values to measure the performance of RED, NLRED, and RED_E in different situations (no congestion, light congestion, and heavy congestion). The key metrics used to measure the performance of the considered AQM techniques are , , , , and . Hereunder is the summary of the results.

RED_E enhanced the performance measures results with reference to and when heavy congestion occurred and offered better and results than RED or NLRED.

When , RED_E outperformed RED and NLRED with reference to and results. Also, NLRED provided the best result among the compared methods, whereas RED produced the most satisfactory result. In the case , RED_E obtained the most acceptable , , and results compared with RED and NLRED, while RED presented better result than NLRED and RED_E.

When light congestion exists (), RED slightly outperformed RED_E with regard to and results, whereas RED_E and NLRED have similar and results. However, when , RED outperformed NLRED and RED_E with reference to and results. Moreover, both RED and NLRED outperformed RED_E regarding to results, whereas RED_E outperformed RED and NLRED in results.

The considered techniques offered similar results when heavy congestion occurred. In addition, RED, NLRED, and RED_E offered similar , , , , and results when there was no congestion in a router buffer.

In addition, NLRED and RED_E provided better , , and performance results than RED using different values of the parameter. For instance, RED_E offered marginally higher results and marginally lower than those of NLRED when the was set to the farthest value from the , and it generated slightly lower results and slightly higher than those of NLRED when the was set to the second farthest value from the . For the other given values of the (5, 6, 7, and 8), both RED_E and NLRED produced similar and results.

The results of , , and of RED, NLRED, and RED_E techniques increased as long as the value of the is increased, whereas the results decreased when the is increased. Hence the results of RED, NLRED, and RED_E have been impacted by the parameter except in the case of the metric.

In the near future, we intend to develop the RED_E in order to further improve performance results based on dynamic values of the , , and .

Data Availability

There are no data availabile.

Conflicts of Interest

The authors declare that they have no conflicts of interest.