ISSN : 2249-2763
EISSN : 2249-2771
SINGH K.1*, KAUR G.2
1University College of Engineering, Patiala-147002, Punjab, India
2University College of Engineering, Patiala-147002, Punjab, India
* Corresponding Author : karamdeep1989@gmail.com
Received : 25-10-2012 Accepted : 06-11-2012 Published : 10-11-2012
Volume : 2 Issue : 1 Pages : 25 - 29
Int J Neural Network 2.1 (2012):25-29
Conflict of Interest : None declared
Differentiated Services architecture offers services at different levels. Packets are classified and treated differently, as defined in the Service Level Agreement (SLA). A traffic policy is created which defines the shaping, dropping and marking of packets. For Congestion Control in Differentiated services networks different variants of Random Early Detection (RED) Scheme are used. RED Scheme is an Active Queue Management Scheme, which can sense congestion before its occurrence and can take appropriate preventive action. In this paper the performance of three variants of RED scheme RED with In/Out with Coupled Queues (RIO-C), RED with In/Out with Decoupled Queues (RIO-D) and Weighted RED (WRED) are compared in terms of drop of packets.
Differentiated Services Networks, Congestion Control, Random Early Detection (RED), Network Simulator 2 (NS).
Congestion is caused by shortage of network resources. If the source transmits at rate higher than the service rate of the queue, the queue size will grow and due to this, incoming packets will face delays and thus congestion will be caused. Congestion Control is the mechanism, which allocates the resources of the network such that the performance is acceptable, when network is operating near capacity. Without the proper control mechanism the throughput will be less under heavy load conditions [1,2] .
In past few years, the internet has grown at an exponential rate, however most of the traffic has been “Best-Effort†type. In Best-Effort type traffic data packets have no preference or guarantee for reliability and timeliness of the delivery [3] . With the development of internet applications such as voice and video conferencing over internet, the need for Quality of Service (QoS) has increased [4] . There are two architecture types that are used to implement Quality of Service (QoS):
• Integrated Services Architecture (Inter-Serv).
• Differentiated Services Architecture (Diff-Serv).
Inter-Serv require per flow traffic handling at every hop along an application’s end-to-end path and RSVP signaling Protocol. RSVP signaling protocol is used for each flows explicit signaling. Inter-Serv Architecture suffers from scalability problems [5] . To avoid scalability problems the Diff-Serv Architecture was proposed. In Diff-Serv networks, complex decision making is done at network edge routers. The edge router marks the packets with different code points according to service level agreement and core routers implement the dropping decision [5,6] . The outline of this paper is as follows, Section 2 illustrates the Architectural concepts of Diff-Serv Networks with three precedence levels, Section 3 states the RED and its variants, Section 4 explains the Simulation topology used in the study, results and observations are given in Section 5 and Section 6, concludes this paper.
Architecture for differentiated services networks with three precedence levels.
The Diff-Serv architecture achieves scalability by maintaining class state information based on aggregates of traffic flows. Packets are classified and marked at the boundary of the network by implementing classification, marking, policing and shaping. The marking of packets decides the particular forwarding behavior at nodes along the path. Network resources are assigned to the traffic streams according to service provisioning policies that decide how traffic would be marked and to be conditioned upon entering the DS network. The service determines the set of characteristics of packet transmission across a set of one path or more paths within the network [7,8] .
In [Fig-1] , two different Diff-Serv domains are shown. Packets enter the DS domain 1 at the boundary ingrass node, where packets are classified, conditioned and assigned to Behavioral Aggregates (BA). All the packets that belong to a particular BA are marked with same value in the DS field in IP header. This DS field is also called Differentiated Services Code Point (DSCP). A BA is treated in a special manner in a domain. Diff-Serv domain is a set of DS nodes with service provisioning policy and set of Per-Hop behaviors (PHBs). Traffic rules are applied on the entering packets by ingrass nodes. The nodes through which traffic leaves a domain are called egrass nodes. The boundary nodes connect two different DS domains, whereas the internal nodes connect to either other interior nodes or ingrass/egrass boundary nodes. Boundary nodes enforce the policy on the traffic entering the domain by conditioning [7,8] .
Differentiated Services with three precedence levels is an extension to two-drop precedence. The edge devices monitor and mark packets of aggregated flows into one of green, yellow or red depending on the reservation rate and temporal sending rate of each color. Usually the reservation rate of yellow is set greater than the reservation rate for green. If the rate is greater than reservation rate for green but, less than reservation rate for yellow, the packet is marked as yellow. Otherwise, the packet is marked as red. The differentiation is provided by dropping first red packets, the yellows second and then green packets [6] . In this paper, we have implemented Time Sliding Window Three Color Marker (TSW3CM). It is implemented in edge ingrass/egrass routers for policing the traffic entering and leaving a particular domain. TSW3CM edge router takes two parameters Committed Information rate (CIR) and Peak Information rate (PIR) [6,11] . The Random Early Detection (RED) queue which is associated with DS maintains 3 Virtual queues, each for Class A, B & C traffic in every physical queue. The work in this paper is focused on comparison between different variants of Multi RED (MRED) queues.
As proposed by Floyd et al. [12] Random Early Detection (RED) is an Active Queue Management (AQM) Scheme. RED employs intelligent admission decision for every packet based on local algorithm. The RED gateways detect congestion by computing the average queue size and taking dropping/marking decisions based on this average queue size. The gateways upon sensing the congestion either drops packets or mark the packets by setting a bit in IP header. This dropping/marking decision is taken by RED gateway by comparing calculated average queue size against the minimum (MinTh) and maximum (MaxTh) thresholds according the following criteria [6,8,12] :
• When avg < MinTh, The Packet is Dropped.
• When Minth < avg < MaxTh, The packet is Dropped with Probability P(a)
• When MaxTh < avg, Packet is Dropped with Probability 1
Where avg = q * measured queue length + (1-q) * avg
p(b) = MaxP * ( avg-MinTh ) / ( MaxTh-MinTh),
p(b) = p(b) * ( packetsize / MaximumPacketSize ), and
p(a) = p(b) / ( 1- count * p(b)).
An estimation of the average queue size is computed for every incoming packet and updated at every packet arrival [12] . [Fig-2] shows the graphical representation of the RED scheme. The RED can be extended to Multi-Level RED (MRED) algorithm that can be used in differentiated services networks.
MRED is an extension of RED for differentiated services networks. In MRED, for different drop precedence’s, the drop probability for packets is calculated independently. Multiple set of RED parameters are maintained for multiple drop precedence. The average queue used for making decision can also be calculated using different methods [13] . These different methods of calculating average queue yield following variants of MRED:
RIO-C is configured with three sets of parameters for the all three drop precedence, one set for each precedence. The average queue for packets with different colors is calculated separately, such that average queue length of a particular color is calculated by adding its average queue to the average queue of the lower drop precedence i.e. for yellow packets, average queue size is computed using green and yellow packets. But, for green packets, the queue is calculated using only green color packets [14] .
RIO-D is similar to RIO-C, the only difference is that in RIO-D, average queue for each color is calculated independently. The average queue length is calculated using number of packets of that particular queue. i.e. The average queue length for green, yellow & red packets is calculated using number of green, yellow and red packets in that respective queue [8,14] .
In WRED only a single average queue is maintained for all arriving packets of all colors. For the arrival of green, red or yellow packet only a single average queue based on total number of packets of all precedence (red, yellow and green). However, multiple RED parameters are maintained for each color.
The RED parameters which were implemented for all RED variants during the whole simulation process in all scenarios are given as under in [Table-1] :
In this section the simulation setup used during this study is explained. The simulations were carried out over widely used simulator for network related simulation, network simulator 2 (Version 2.34) on Ubuntu 11.10 machine. The experimental setup used is shown in [Fig-3] :
In the experimental setup, there were N number of source nodes and destinations nodes. Each source node was connected to edge router 1(E1), whereas the destination nodes were connected to edge router 2 (E2). The link between edge router 1(E1) and core router (C) was considered as bottleneck link, which had capacity 4.5 Mbps and latency 5 ms. All links had physical buffer which can hold 50 packets. All the source nodes were configured to generate a number of TCP or UDP based flows depending on type of scenario being considered. Each flow was configured to send packets having packet size of 512 bytes. In this study, two types of scenarios were considered. In first type of scenario, number of nodes was increased and number of flows per source was kept constant and number of packets dropped was tabulated, whereas in the second type of scenario the setup has only single source node and destination node and number of flows was varied and number of packets dropped was tabulated. The % of packets dropped were calculated as per following formula [15] :
% age of Packets Dropped = Total Number of Packets Dropped / Total Number of Packets Sent (1)
The % of packets dropped indicate the relative performance of RED variants in various scenarios.
Several simulation scenarios were considered to find appropriate results. Firstly only FTP running over TCP flows were considered in both cases i.e. by increasing number of nodes and by number of increasing number of flows for a single source and destination network. After this, Constant Bit Rate (CBR) traffic was used to conduct simulations. Dropped packets at bottleneck link were tabulated and % of packets dropped or % Packet Loss was calculated for all precedence traffic. % Packet loss data was plotted in graphical form. An example of Simulation results generated in tabular form is shown below in [Table-2] :
As shown in [Table-2] , the results were generated in the tabular form. Packet drops for each class traffic was presented. Here ldrops (link drops) meant the dropping due to physical queue length exceeding the physical buffer. The edrops (early drops) were droppings due to RED mechanism. The statistics in All Class were combined statistics of all Traffic Classes (A, B and C). Total drops were sum of ldrops and edrops [16] . % of Packets Dropped for All Traffic Classes were calculated and used as metric in this work. Here node means both source and destination nodes. The results obtained during the study are given as under:
In this case the simulation was carried out by nodes running FTP applications over TCP flows:
Number of flows per node was kept constant at 80. The number of nodes was increased from 1 to 20. % of Packets dropped for All class traffic was noted. The simulation time was 5 seconds. Simulation results obtained during this scenario have been presented here in graphical form in [Fig-4] .
In [Fig-4] , when number of nodes was less RIO-D outperforms both RIO-C and WRED, as it dropped less number of packets. There were some fluctuations observed at higher number of nodes due to variable nature of TCP. It was observed from this scenario that RIO-D performs better as compared to WRED and RIO-C.
For a single source and destination network the number of FTP/TCP flows was increased from 1 to 80. The simulation time was 50 seconds. Simulation results obtained during this scenario have been presented here in graphical form in [Fig-5] :
As shown in [Fig-5] , as the number of FTP/TCP flows were increased RIO-D dropped less packets as compared to RIO-C and WRED. This behavior was mainly due to increase of Class C packets in All class traffic at large number of flows. For 80 number of flows, the RIO-D dropped 1.21% less packets as compared to WRED and RIO-C.
In this case sources were configured to run CBR/UDP flows. The CBR traffic sends data at a constant rate without any interruption in between [16] . The results obtained were as under:
In this scenario, number of nodes was increased from 0 to 20 and number of flows was kept constant at 20 per node. Simulation was conducted for 5 seconds. Each CBR/UDP flow sends data at rate 12.207 Kbps. Simulation results obtained during this scenario have been presented here in graphical form in [Fig-6] :
In [Fig-6] , as the number of nodes were increased RIO-D started performing better as compared to other two variants. When Number of nodes were increased beyond 10 nodes ldrops started increasing and thus after this there was very less difference in performance.
Number of CBR/UDP flows was increased from 1 to 20 for a single source and destination network in this scenario. Each flow send date at rate 12.207 Kbps. Simulation was carried out for 50 seconds. Simulation results obtained during this scenario have been presented here in graphical form in [Fig-7] :
As shown in [Fig-7] , when there was less number of flows no congestion occurred and thus, no packets were dropped. When number of flows was increased beyond 25 RIO-D scheme had lesser %age of Packets Dropped as compared to other two schemes. Thus, RIO-D performs better as compared to other two variants. It was observed from the study that the RED with In/Out with decoupled queues (RIO-D) performed better as compared to two other modes for all the simulation scenarios conducted for FTP/TCP and CBR/UDP traffics, as it dropped less number of packets.
In this paper the performance of different variants of Random Early Detection (RED) such as RIO-C, RIO-D and WRED was compared on the basis of packet droppings. The RED parameters for all three variants were kept same and various simulation scenarios were created using a variety of traffic including FTP/TCP and CBR/UDP at different transmission rates. It was observed from the study that RIO-D drops less number of packets as compared to other two variants RIO-C and WRED in most of the cases. It can be concluded from the study that RIO-D performs better as compared to other two variants in terms of percentage of packets dropped. There is always a trade-off between packet loss and latency. In This work only packet loss was considered, the latency was not analyzed. Work based on latency is under process.
[1] Jain R. (1990) IEEE Network Magazine, 24-30.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[2] Pitsillides A. and Sekerciouglu A. (2012) Fuzzy Logic Based Congestion Control.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[3] Firoiu V., Zhang X. (2000) Nortel Networks Technology Centre Technical Report, 1-20.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[4] Keping L., Qian W., Shiduan C. and Jialiang C. (2003) J. Computer Science & Technology, 18(2), 223-229.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[5] Raghavan S. (2011) Master of Science Thesis, Virginia Polytechnique Institute & State University, Blacksburg, Virginia, 1-107.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[6] Revathi T., Muneeswaran K. and Ramar K. (2011) Applied Soft Computing, 5457-5462.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[7] Blake S., Black D., Carlson M., Davies E., Wang Z. and Weiss W. (1998) Network Working Group, RFC 2475.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[8] Strauss M.D. (2005) Master of Science Thesis, University of Pretoria, Pretoria, 1-98.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[9] Hernanen J., Baker F., Weiss W. and Wroclawski J. (1999) Internet Engineering Task Force.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[10] Dave B. et al. (2002) Network Working Group, RFC 3246.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[11] Feng W., Seddigh B. and Nandy B. (2000) Network Working Group, RFC 2859.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[12] Floyd S. and Jacobson V. (1993) IEEE/ACM Transactions on Networking, 397-413.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[13] Durressi G.M., Jain A.R. and Lei C. (1999) Effect of Drop Precedence in Assured Forwarding.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[14] Elloumi O. et al. (1999) Internet Engineering Task Force.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[15] Makkar R.S. et al. (2000) Proceedings of ICCCN, Las Vegas, U.S.A.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
[16] Fall K. and Varadhan K. (2011) The VINT Project, 1-433.
» CrossRef » Google Scholar » PubMed » DOAJ » CAS » Scopus
 | Fig. 1- Two Diff-Serv Domains [8]. |
 | Fig. 2- RED Algorithm [8]. |
 | Fig. 3- Simulation Setup |
 | Fig. 4- % of Packets Drop Vs. No. of Nodes for FTP/TCP Traffic. |
 | Fig. 5- % of Packets Dropped Vs. Number of Flows for FTP/TCP Traffic |
 | Fig. 6- % of Packets Dropped Vs. Number of Nodes for CBR/UDP Traffic. |
 | Fig. 7- % of Packets Dropped Vs. Number of Flows for CBR/UDP Traffic. |
 | Table 1- MRED Parameters used in all simulation scenarios |
 | Table 2- Example of simulation results generated in tabular form |