CRITICAL EVALUATION AND ANALYSIS OF QUEUING DISCIPLINES ON PACKETS DELIVERY FOR DIFFERENT APPLICATIONS.

Transcription

1 African Journal of Science and Research,2015,(4)4:39-47 ISSN: Available Online: CRITICAL EVALUATION AND ANALYSIS OF QUEUING DISCIPLINES ON PACKETS DELIVERY FOR DIFFERENT APPLICATIONS. Adekunle Ajasin University, Department of Computer Science, Akungba-Akoko, Ondo-State, Nigeria :12,July,2015 Accepted: 25,Aug,2015 Abstract Communication network is a process of exchanging data between two or more devices via some forms of transmission medium using communication protocols [8]. The data could be in form of text, images, audio, video or numbers which can be grouped into FTP, , HTTP, VOIP or Video applications. The effectiveness of such data exchange will be proved if they are accurately delivered within specified time. While some senders will not really mind when the data is actually received by the receiving device, inasmuch it is acknowledged to have been received by the receiver. The time a data takes to get to a receiver could be very important to another sender, as any delay could cause serious problem or even in some cases rendered the data useless. The validity or invalidity of a data after delay will therefore definitely depend on the type of data (information).it is therefore imperative for the network device (such as router) to be able to differentiate among the packets which are time sensitive and those that are not, when they are passing through the same network. So, here is where the queuing disciplines comes to play, to handle network resources when such network is designed to service widely varying types of traffics and manage the available resources according to the configured policies.therefore, as part of the resources allocation mechanisms, a router within the network must implement some queuing discipline that governs how packets (data) are buffered while waiting to be transmitted. The implementation of t he queuing discipline will regulate how the packets are buffered while waiting to be transmitted. In achieving this, various queuing disciplines are being used to control the transmission of these packets, by determining which of the packets get the highest priority, less priority and which packets are dropped. The queuing discipline will therefore control the packets latency by determining how long a packet can wait to be transmitted or dropped. The common queuing disciplines are first-in-first-out queuing, Priority queuing and Weighted-fair queuing (FIFO, PQ and WFQ). This paper critically evaluates and analyse through the use of Optimised Network Evaluation Tool (OPNET) Modeller, Version 14.5 the effects of three queuing disciplines (FIFO, PQ and WFQ) on the performance of 5 different applications (FTP, HTTP, , Voice and Video) within specified parameters using packets sent, packets received and transmission delay as performance metrics. The paper finally suggests some ways in which networks can be designed to provide better transmission performance while using these queuing disciplines. Keywords: First-in-first-out queuing (FIFO), Optimised Network Evaluation Tool (OPNET),Priority queuing (PQ), Queuing discipline, Weighted-fair queuing (WFQ) INTRODUCTION As part of the resource allocation mechanisms in a network, each The purpose of every packet (data) sent across a network is to be router must implement some queuing discipline that governs how delivered to the receiver with its integrity intact. However, most times, packets are buffered while waiting to be transmitted. Each router in a the time it takes to get to the receiver could also be an issue, that is, network is expected therefore to implement some degree of queuing does the data get to the receiver on time or it is delay. discipline that controls how the packets are structured in recognising While some senders will not mind when the data is delayed, their priorities, in doing this; the network is expected to allow the inasmuch it is acknowledged to have been received. To other packets with high priority to be transmitted first and the ones with senders, the time a data takes to get to a receiver could be very lesser priority can then follow. important, as any delay could cause serious problem or even in The implementation of the queuing discipline should regulate how some cases rendered the data useless. The validity or invalidity of a the packets are buffered while waiting to be transmitted. In achieving data after delay will definitely depend on the type of the data this, various queuing disciplines are being used to control the (information). While some data are very sensitive to delay during transmission of these packets, by determining which of the packets transmission, some are not really so sensitive as such, and therefore get the highest priority, less priority and if possible, which packets some delay may not really do any harm to such data [7]. are dropped. The queuing discipline therefore controls the packets While applications such as voice and video are very sensitive to latency by determining how long a packet can wait to be transmitted delay, loss and jitter due to the time sensitivity of such applications, or dropped [10]. other applications such as FTP, HTTP and are not so Three different queuing disciplines are being examined in this sensitive to delay, inasmuch, the packets get to the receiver within a network scenarios to determine the effect of each discipline on reasonable time [9]. different traffic (application) using traffics delay, traffics sent and It is therefore imperative for the network device (such as router) to traffics received as a metric for measurement. The three queuing be able to differentiate among the packets, to know those that are disciplines to be considered are: First In-First Out (FIFO) Queuing, time sensitive or not when they are passing through the same Priority Queuing (PQ) and Weighted-Fair Queuing (WFQ). network. So, here is where the queuing disciplines comes to play, to The modelled networks are designed to support five different handle network resources that is designed to service varying types of traffics (applications) (FTP, HTTP, , Voice and Video) which traffics (applications) and manage the available resources according were simulated to determine the effect of each queuing discipline on to the configured policies. these applications performance.

2 40 Queuing s A. First In First Out (FIFO) This queuing discipline did not consider any factor in the process of transmitting packets, rather it respect the order in which the packets arrives, and therefore transmit them according to the packets arriving schedules. The idea of FIFO queuing is that the first packet that arrives at a router is the first packet to be transmitted. Given that the amount of buffer space at each router is finite, if a packet arrives and the queue (buffer space) is full, then the router discards (drops) that packet. This is done without regard to which flow the packet belongs to or how important the packet is [1]. FIFO queuing discipline is the default queuing discipline used by the routers on many networks unless otherwise configured for other queuing mechanism because it is very simple to implement. Although, as fair as the discipline want to be to the packets by respecting their arrival time for transmission, it always lead to some sort of delay, loss or even jitter for some sensitive packets though arriving late but cannot afford to wait because of their sensitivity to delay which could rendered the packets invalid or useless if it failed to get to the receiving node at the appropriate time. B. Priority Queuing (PQ) PQ is a simple variation of the basic FIFO queuing. The idea is to mark each packet with a priority; the mark could be carried in the Internet Protocol (IP) Type of Service (ToS) field of the packet. The routers then implement multiple FIFO queues, one for each priority class. Within each priority, packets are still managed in a FIFO manner. This queuing discipline allows high priority packets to cut to the front of the line. This discipline can be considered as a queuing discipline that gives highest priority to the packets that are more sensitive to delay, loss or jitter to ensure that they are transmitted across a network more quickly while giving lesser priority to those packets that are less sensitive to such factors as delay, loss or jitter. PQ tends to operate under four queue systems namely: high, medium, normal, and low. Packets are placed on each of these queue positions based on their priority (sensitivity). Packets that are not rated by this priority list mechanism will be placed on a normal queue. The algorithm gives higher-priority queues absolute preferential treatment over low-priority queues during packets transmission. PQ is assumed to be relatively efficient method for prioritizing very few traffics as it also tend to cause delay, loss and jitter for lower priority packet because the queuing method tends to delay less sensitive packets and can completely starve some traffics (Packets) from being transmitted [2]. C. Weighted-Fair Queuing (WFQ) The idea of the fair queuing (FQ) discipline is to maintain a separate queue for each flow currently being handled by the router. The router then services these queues in a round-robin manner. WFQ allows a weight to be assigned to each flow (queue). This weight effectively controls the percentage of the link s bandwidth each flow will get. We could use type of service (ToS) bits in the IP header to identify that weight [12]. Voice and video traffics (applications) must make use of either PQ or WFQ to transmit them because of their real-time streaming nature and therefore very sensitive to delay, loss and jitter as the receiving node cannot afford to wait for long to receive the data that had been sent by a sender. Any delay for applications like videoconferencing will be very apparent, causing the video signal to jerk [4]. So, in the process of transmitting such packets through networks with various other traffics, priorities must always be given to them, so that the receiving node can receive the packet without any delay whatsoever. Simulation Environment And Performance Metric The experimental evaluation and analysis is conducted using discrete event simulation software called Optimized Network Evaluation Tool (OPNET) Modeller Version 14.5, a network and application management design and evaluation software suite from OPNET Technologies Inc. It provides dynamic simulation of communication devices, protocols, technologies, and architectural performance in a virtual network environment [3]. Although, other various software platform tools (Simulators) such as NS, GloMoSim, Qualnet, OMNET++, J-Sim among others are being employed in the networks model and application simulation and evaluation, while some of these tools are open source tools others are commercial tools that need to be licenced through purchase, however, the choice of which simulator to be used will be purely driven by the user s (researcher) requirements. In this experimental analysis, OPNET was chosen as the preferred simulation platform tool for several reasons, such as: 1)It is a well-established and professional commercial suite for network and applications simulation. It is actually regarded as the most widely used commercial simulation environment because much of the proposed hardware as well as protocols are pre-tested in the software domain. 2)The OPNET tool features an interactive development environment that allows the design and evaluation of networks, devices, protocols, and applications that supports an extensive number of protocols. 3)Since most non-commercial (Open Source) simulators suffer from lack of good documentation and support, they also support fewer protocols, so using a commercial simulator like OPNET will be very helpful in case of troubles during the design and evaluation of networks and applications [6]. 4)More importantly, OPNET Tool has ability to execute, monitor and compare several scenarios in a concurrent manner, which is very useful in this (simulated) scenarios. Several metrics can be used in evaluating the effects of queuing disciplines on various network applications, but for the purpose of this paper, the performance metrics considered are based on the: Packets Sent, Packets Delay and the Packets. These metrics are chosen because they measures a transmission policy s effectiveness and are important when dealing with Constant Bit Rate (CBR) applications such as real-time audio and video applications which are parts of the applications supported by the network in consideration [5]. The network is designed to support and service FTP, HTTP, , Video and Voice applications for the traffics analysis while the applications are all considered with varying traffic loads DESIGN OF NETWORK MODELS The network is a campus size (Scale) internet network that is meant to perform some specialized functions (applications). The applications that the network is expected to use are as follows: 1) File Transfer Protocol (FTP) Application (Heavy & Light) 2) Hypertext Transfer Protocol (HTTP) including browsing

3 African Journal of Science and Research, 2015,(4)4: ) Video Application including video conferencing and other multimedia applications 4) VoIP Application including IP telephony technology 5) Application (Heavy) The network is designed to consist of four subnets with each network (subnet) performing different functions (Applications) at different levels. However, all the four subnets are connected with central (ISP) internet and linked to central campus servers. Since there are four different subnets within the central network and each subnet offering different application functions, the subnets are therefore designed separately putting in mind the various applications that the subnets will be used for. The following under listed components were used in designing the network: 1)Ethernet Servers: these are used as servers to provide various application services needed in the network, such as FTP, VoIP, Video and applications. Therefore, the servers will serve as FTP Server, Web Server, and Video Server. 2)QoS Attribute Configuration Node: this defines the attribute configuration details for protocols that are supported at the Internet Protocol (IP) layer. It defines different queuing profiles such as FIFO, PQ, WFQ, etc. 3)Ethernet4_slip8_gtwy: which acts as the router through which the networks are connected (the servers and the workstations) to form internetwork. 4)PPP_DS1 Link: this bidirectional PPP_DS1 link is used to connect the routers with each other through IP Cloud or to connect the routers with the internet. 5)10Base-T Link: this bidirectional link is used to connect the servers and subnets with the routers. 6)Application Configuration Node: this is used to specify applications that the network will be used for using the available application types. In the process of creating the application, the name and necessary description of the application are specified. 1)Profile Configuration Node: this node is used to create the users profile which must be specified in the network to generate the application layer traffic using the applications specified in the application configuration object (Node). 2)10BaseT_LAN Object: this represents Ethernet LAN which is regarded as a complete network, however in this scenario; the 10BaseT_LAN is used to design the subnet by configuring it to meet the individual subnet application requirements and allows the traffic to be directed to external servers. The object contain 10 clients by default which can be reset to any appropriate number of clients by assigning appropriate numbers to it to meet the subnet s required number of clients to be served and the object operates at 10Mbps. The object supports various applications such as FTP, Video, VoIP, , Database, among others. IP32_Cloud: which represent a model of IP cloud supporting up to 32 serial line interfaces at a selectable data rate through which IP traffic can be modeled.the IP packets arriving on any cloud interface are routed to the appropriate output interface based on their destination IP address [3]. The model can support the following protocols UDP, TCP, IP, OSPF, RIP, BGP, and IGRP among others [11]. A. Design of the Subnets 1. Subnet 1 The subnet 1 is designed with the clients workstations using the 10BaseT_LAN Object and the clients number is set to 20, to allow 20 users (workstations) for the network. The network will support 3 application profiles which are configured in the application configuration object: FTP (Heavy), HTTP (Heavy) and Video Application. The workstations (in a switched based topology) are linked to the internet through the West Router using a bidirectional 10BaseT Link. 2. Subnet 2 The subnet 2 is designed using 10BaseT_LAN Object (A switched based topology ethernet LAN) to create the clients workstations and the clients number is set at 10 to allow 10 users (workstations) for the network. The network will support Video Application as the main application support service. The clients traffic is directed to the external server (Video Server) that will serve the workstations The workstations (in a switched based topology) are linked to the internet (IP32_Cloud) through the West Router using a bidirectional 10BaseT Link 3. Subnet 3 The subnet 3 is also designed using 10BaseT_LAN Object to create the clients workstations. The clients number is set to 15, to allow 15 users (workstations) for the network. The network will support VoIP, , FTP and HTTP Applications as the main application support service. The clients traffics are directed to the external servers (Web and FTP Servers) that will serve the workstations, while the VoIP, and HTTP Applications will be served by the Web Server, the FTP Application will be served by the FTP Server. The workstations (in a switched based topology) are linked to the internet through the West Router using a bidirectional 10BaseT Link. 4. Subnet 4 The subnet 4 is designed using 10BaseT_LAN Object (A switched based topology ethernet LAN to create the clients workstations. The clients number is set to 10 to allow 10 users (workstations) for the network. The network will support VoIP Application as the main application support service. The clients traffic is directed to the external server that will serve the workstations. The workstations (in a switched based topology) are also linked to the internet through the West Router using a bidirectional 10BaseT Link. B. Design of the Central Network 1. Parent Network The parent (Actual) network which carries four different subnets that are performing various applications is designed connecting the four subnets to various servers that will serve the subnets based on the applications services that are be supported. The servers and the subnets are connected together by two routers (named west Router and East Router) through IP32_Cloud using PPP_DS1 Link. The PPP_DS1 Link is used to connect two nodes running internet protocol (IP). The parent network comprises of the four subnets are as shown in the fig. 1 below. Fig. 1 The Parent Network

4 42 The two routers are placed appropriately to connect the subnets and the servers together across internet (IP32_Cloud) and are configured to perform a FIFO operation on the QoS Scheme on all IP interfaces across all the links through the bidirectional PPP_DS1 Link that joined them together. The servers are named FTP, Video and Web servers to serve different applications on the subnets and the network as a whole. The Servers will support different applications based on the configuration requirements, the supported applications are as follow: 1) FTP Server serves FTP Applications 2) Video Server serves video applications 3) Web Server serves VoIP, HTTP and Applications. The servers are individually configured to meet these requirements. 2. Application Configuration The application configuration object is set to allow the network to perform five different application functions: FTP, HTTP, , VoIP and Video Application as follows. In assigning an appropriate method of delivery to various applications under the ToS, the FTP, and HTTP Applications are assigned with Best of Service, which means that all efforts will be made to deliver the packet but the delivery is not guaranteed while that of Video application is assigned with streaming multimedia (4) which allows the client browser or workstation plug-in to start displaying the video before the entire packet is transmitted. A PCM (Pulse Code Modulation) quality speech is assigned to voice in the VoIP Application description hierarch being the procedure (coding method) used to digitize the speech before transmitting it over the network, while the QoS is assigned with Interactive Voice (6) which uses interactive method for internet telephony callers. The table for the application configuration for the network is as shown in table (i) below Table (I)Network Application Configuration Application Parameters Value High load FTP File size Constant ( ) Inter-request time Constant (10) ToS Best of Effort Page Inter-arrival Time Constant (5) HTTP (Seconds) ToS Best of Service Value Low resolution video Video Destination name Video destination Frame size info. 128x120 Pixels ToS Streaming Multimedia (4) Value High load VoIP Talk Spurt Length (Secs) Default Voice frame/packet 1 ToS Interactive voice (6) Compression Delay 0.02 (Secs) Decomp. Delay (Secs) Profile Configuration The users profiles for the whole network are also created in the profile configuration object using the application specifications from the application configuration object to allow network to perform the required application functions. The networks profile configuration is shown in fig. 2 below Fig(2)The Network s Profile Configuration The table for the profile configuration for the network is as shown in table (ii) below Table (ii) Network profile configuration Profile Parameters FTP HTTP Video VoIP Name Application Start Time Offset Constant (5) Duration (Seconds) End of Profile Repeatability Once at start time Operation Mode Simultaneous Start Time Offset Constant (100) 4. Quality of Service Configuration The purpose of designing this network model is to analyse the effect of different queuing disciplines on the performance of the various applications; the first network scenario is designed to use FIFO queuing discipline as shown in fig. 3(a). In order to test for the other queuing disciplines (Priority Queuing and Weighted-Fair Queuing), two separate network models are created, this is achieved by duplicating the FIFO discipline network to produce Priority Queuing and Weighted-Fair Queuing networks. The networks are created by reconfiguring the routers, hanging the QoS scheme into Priority Queuing and Weighted-Fair Queuing mechanism respectively as shown in the fig. 3(b) and (c) below. Send group size Constant (1) Receive group size Constant (1) size (byte) Constant (10000) ToS Value Silence Length (Secs) Best of Effort PCM Quality Speech Default Fig. 3(a). FIFO Queuing

5 African Journal of Science and Research, 2015,(4)4: are almost the same. The traffics were gradually generated as the system was switch on with steady increase for about two minutes before the traffics started experiencing some degree of variation or fluctuation. The fluctuation in the pattern of sending the traffics was between 500, ,000bytes/sec, and this continued throughout the period of the simulation. The application generated high volume of traffics, which showed that the application was heavily used as shown in the fig. 5(a) Fig. 3(b). Priority Queuing Fig. 3(c). Weighted-Fair Queuing Principle SIMULATION INVESTIGATION AND ANALYSIS In simulating the network to observe the performance of the applications as defined, the network was simulated for a period of one hour as shown in fig. 4 One hour was chosen in order to give the simulation enough time to demonstrate its expected performance which will be able to produce sufficient results that will enable a comprehensive analysis of the network s performance. The effect of different queuing disciplines on the applications (FTP, Video, VoIP, and HTTP) performance are shown through the graph and analyzed.. Fig. 5(a). FTP Traffics Sent On the other hand, the traffics received on the various queuing disciplines were a bit lower than the traffics that were sent, this happened across the three disciplines. The traffics were being received as they were being sent in the first 2 minutes and thereafter stopped increasing but rather being received in a relatively constant manner with some degree of fluctuation or variation which also corresponds to the sent pattern. Though, some delay was experienced across the three disciplines as the receiving traffics were between 400, ,000bytes/sec as against the sent rate of 500, ,000bytes/sec. Also, PQ discipline is a bit ahead of the other two disciplines as regards the rate of traffics received between the ranges of 400, ,000. Fig. 4. Network Simulation Time A. FTP Application The traffics sent by the application on the three queuing disciples Fig. 5(b). The FTP Traffics and Delay The delay experienced in the FTP application on the three queuing disciplines can be considered to be low, as there is no much

6 44 delay experienced by the application on the three queuing disciplines. The table (iii) illustrates the FTP traffics transmissions and delay for the three different queuing disciplines. Table (iii)ftp traffics transmissions and delay Queuing Delay Byte/Sec Sent Byte/Sec FIFO Low 500, , , ,000 PQ Low 500, ,000-1,000, ,000 WFQ Low 400, , , ,000 Time B. HTTP Application There was no real delay experience in the HTTP application on the three queuing disciplines, as the same amount of traffics generated at every point (time) were all received accordingly. The traffics generated by the HTTP application on the three queuing disciples are relatively the same with very minor variation. The number of traffics generated immediately the system was switch on were high at around 60,000byte/sec and immediately the traffic continued to decrease as the system stabilise, after about two minutes the traffics came down to a relatively stable and constant level in between 10,000 bytes/sec. the rate at which the traffics were sent was relatively constant and uniform with minimum fluctuation or variation and stay between 10,000 bytes/sec throughout the period of the simulation. The traffics received from the HTTP application on the various queuing disciplines were relatively the same, as there is no real different between the traffics (bytes/sec) received by each queuing discipline. The rate at which the traffics were received was proportional to the rate at which the traffics were sent at every point in time from the moment the system was switch on to the last minute of the simulation, this shows that there was no sign of any delay at all across the three queuing discipline. Since HTTP application is not considered delay sensitive, like video or VoIP applications, the relatively the same amount of traffics received by the three mechanisms can be considered to be a result of the fact that no priority was given to the application across the disciplines, and therefore were all sent across according to their arrival time. In fact, it can be deduced from the fig. 6(a & b), that HTTP application provides the best performance or service and that clients using the application enjoy the best service. Fig. 6(a). HTTP Traffics Sent Fig. 6(b). HTTP Traffics The table (iv) shows the behaviours of HTTP traffics transmissions and delay for the three different queuing disciplines. Table (iv)http Traffics Transmissions And Delay Queuing Delay Byte/Sec Sent Byte/Sec Time FIFO Very Low 10,000 10,000 PQ Very Low 10,000 10,000 WFQ Very Low 10,000 10,000 C. Application There was no visible delay experience in the application on the three queuing disciplines, the same amount of traffics generated at every point (time) were all received accordingly. The traffics generated by the application on the three queuing disciples are relatively the same. The number of traffics generated immediately the system was switch on were high at around 180,000byte/sec in the first few seconds but came down about two minutes later to between 80, ,000bytes/sec. the rate at which the traffics were sent was relatively constant and uniform with minimum fluctuation or variation stay between 80, ,000 throughout the period of the simulation. The traffics received from the application on the various queuing disciplines were relatively the same, as there is no much different between the traffics (bytes/sec) received by each queuing discipline. The rate at which the traffics were received was proportional to the rate at which the traffics were sent at every point in time from the first minute to the last minute of the simulation, this shows that there was no sign of any delay at all across the three queuing discipline. Since application is not considered delay sensitive, the relative the same amount of traffics received by the three mechanism can be considered to be a result of the fact that no priority was given to the application across the disciplines, and therefore were all sent across according to their arrival time. The fig. 7(a & b) demonstrates the behaviours of the application on the three disciplines.

7 African Journal of Science and Research, 2015,(4)4: Fig. 7(a). Traffics Sent sensitive, it was therefore given greater degree of priority, this is shown from the fig. 8(b) as the traffics received on the PQ discipline is the same as the amount sent without any delay or loss. However, the traffics received on the WFQ discipline is less compare with the amount sent because less priority was given to the application at the discipline, so 250,000bytes/sec of traffics were received as against the 400,000 that were sent. In the same manner, the traffics received on the FIFO discipline was the least because at this discipline, no priority was given therefore there would have been high congestion on the network leading to much of the traffics being dropped. Therefore only around 160,000bytes/sec were successfully delivered. However, the rate at which these traffics were delivered became constant and uniform just after a minute of starting the system as shown in the fig. 8(b). Fig. 7(b). Traffics The table (v) shows the patterns and volume of traffics transmissions and delay for the three different queuing disciplines Table (v) traffics transmissions and delay Queuing Delay Byte/Sec Sent Byte/Sec FIFO None 80,000-80, , ,000 PQ None 80,000-80, , ,000 WFQ None 80,000-80, , ,000 Time D. VoIP Application The delay experienced in the VoIP application on the three queuing discipline do have significant different, there is real delay experienced by the application on the FIFO and WFQ queuing disciplines as against that of the PQ which experience no significant delay, this can be seen from the fig. 8(a & b). All the 400,000bytes/sec traffics sent were received at the PQ queuing discipline immediately without any delay. In WFQ and FIFO, 250,000 and 160,000 (bytes/sec) were received respectively as against the 400,000byte/sec that was sent. The traffics sent by the application on the three queuing disciples are the same on all the queuing disciplines at 400,000bytes/sec. The traffic of 400,000byte/sec were generated almost immediately the system started and after about a minute the traffic is being sent constantly and at a uniform rate over the network without any interference at 400,000bytes/sec throughout the duration of the simulation as shown in the fig. 8(a). The packets received on the various queuing disciplines differ considerably from one another because voice is considered as delay Fig. 8(a). VoIP Traffics Sent Fig. 8(b). VoIP Traffics The table (vi) below shows the behaviours of VoIP application on delay, traffics sent and traffics received. Table (vi)voip Traffics Transmissions And Delay Queuing Delay Byte/Sec Sent Byte/Sec Time FIFO Higher 400, ,000 PQ None 400, ,000 WFQ High 400, ,000 E. Video Application Video application is also considered as delay sensitive, the delay experienced in the Video application on the three queuing discipline do have significant different, as there is real delay experienced by the application on the three queuing disciplines. The application generated the highest amount of traffics across the three disciplines. The packets sent by the application on the three queuing disciplines are different on the individual queuing disciplines. Traffics

8 46 were generated immediately the system started and after about a minute the traffics are being sent constantly and at a uniform rate over the network while the 8.5million bytes/sec were being sent on PQ discipline, the amount being sent on FIFO and WFQ is the same at 10.4million bytes/sec, and that continued throughout the duration of the simulation as shown in the fig. 9(a) The packets received on the various queuing disciplines differ greatly and seriously lower compared to the amount of traffics sent. The different between the traffics sent and traffics received proved that serious delay and jitter did happened which definitely led to lot of drops in the traffics. From about 10.4million bytes/sec traffic sent on FIFO and WFQ, only around 180,000bytes/sec were received at relatively constant and uniform rate. However, the situation was more worrisome on the PQ discipline as only around bytes/sec traffic was received. The results on the fig. 9(b) showed that a very poor service or performance was recorded by the video application across all the queuing disciplines. Fig. 9(a). Video Traffics Sent Fig. 9(b). Video Traffics The table (vii) below shows the behaviours of Video application on delay, traffics sent and traffics received Table (vii)video Traffics Transmissions And Delay Queuing Delay Byte/Sec Byte/Sec Time Sent FIFO Very High 10.4million 180,000 PQ Extremely 8.6million High WFQ Very High 8.6million 180,000 CONCLUSION AND RECOMMENDATION A. Conclusion Having comprehensively compared the results of the simulation to observe the effects of the three queuing disciplines (FIFO, PQ and WFQ) on various applications (FTP, HTTP, , VoIP and Video), it is very clear that there is no observed delay on the application on all the three queuing disciplines as all the traffic sent were full received on the receiving node at the corresponding time that they were sent. Also, on the FTP application, the delay was minimal, at 20 minutes of the simulation, an average of 750,000 byte/sec of traffic was sent of which 600,000 byte/sec was received at the receiving node, the delay resulted to some traffics not delivered and this occurred along all the three queuing disciplines. In the HTTP application, the delay observed was very low and insignificant along the three queuing disciplines, though there was some fluctuations along the path which might have been caused by the medium in which the traffics travelled, in all, the traffics sent was almost all received at the right time. It can be concluded that the clients enjoyed fast browsing. On the other hand, in the VoIP application, the delay along the three queuing disciplines varies considerably, while there is absolutely no delay on the PQ, as all the traffics sent were received at the right time. The delay on the WFQ is high as about 260,000bytes/sec was received from the 400,000bytes/sec that was sent, leaving around 140,000bytes/sec behind the schedule time. However, the delay is mostly felt on the FIFO disciplines as less than half of the traffics sent were received.160,000bytes/sec from 400,000bytes/sec. Since, VoIP (Voice) application is very sensitive to delay, it can be concluded that the network has given priority to the application, thereby allowing all those on the (Priority Queue) PQ to be transmitted and given less priority to the WFQ and even lesser priority to the FIFO. It is therefore very clear, that the best way of transmitting (sending) VoIP application will be through PQ discipline. The situation was so terrible in the video application; the delay was extremely high along all the three queuing disciples, the majority of the traffics sent were not received at all. Despite the fact that the application is so sensitive to delay, even the PQ was unable to deliver traffics to the receiving node, rather it was even worst at the PQ discipline. However, the assumption was that the general poor performance of the three disciplines may have much to do with the equipment used in building the network rather than the queuing disciplines. B. Recommendation From the design of this above network scenarios and the comparison of the various results obtained across different queuing disciplines, it can clearly be said that while the users on the FTP, HTTP and applications on this network will be satisfied with performance of these applications, particularly those using the HTTP application. That cannot be said of the users on the VoIP and Video applications, as there were large amount of traffics drop. However, this problem was rectified by the PQ disciple on the VoIP application as the users on this discipline received excellent service. Although, part of these traffics delay and drop in the VoIP and Video applications might be as a result of sending these traffics across IP protocol, which is met to carry data rather than voice or video and by this does not provide real-time guarantee of transmission but best of effort services, therefore, the process of converting these analogue packets to digital (data) and vice versa will take some time, though in nanoseconds and the time taken to wait for all the traffics before they are transmitted. Good enough, part of these problems have been solved be providing queuing discipline that will give these applications some priority over others thereby reducing the delay to be experienced. So,

9 African Journal of Science and Research, 2015,(4)4: from the above scenarios, for the performance of these applications to be improved, the following recommendations are offered: i)that since the PQ queuing discipline seem to be the best method of transmitting VoIP, the network could be designed in such a way that Subnets that only supports VoIP application respectively can be connected to the internet and servers through separate router and configure their QoS scheme to be PQ queuing discipline. This I believe will reduce the time taken for the router to sort out the packets for priority assignment before sending, as all the traffics coming into this router will have the same degree of priority and therefore will be transmitted to the receiving node through the principle of first in first out. This process will look like a FIFO mechanism inside PQ mechanism. The method will definitely reduce delay and traffic drop, therefore given improved applications performance ii)the link used in the above network to connect the east router and the west router is the bidirectional PPP_DS1 which has an average speed of Mbps. The network would better be served by using a bidirectional link of PPP_DS3 which has higher speed ( Mbps) than the PPP_DS1, this will allow packets to get to the east router faster and quickly prioritise for transmission to the appropriate subnet. iii)the link used in the above network to connect the subnets with the east router is the bidirectional 10BaseT which has a maximum operating speed of 10 Mbps. The link can be increased to 100BaseT which can operate to a maximum speed of 100 Mbps for those subnets (2 & 4) that primarily supports applications that are more sensitive to delay, this will increase the rate at which the traffic get to the subnets thereby reduce the delay and associated loss of traffic. iv)for those subnets which supports varying applications with different degree of sensitivity like subnet 1 and subnet 3, separate and dedicated workstations can be assigned to those applications with high sensitivity to delay and then connect the dedicated workstations directly to the router(s), this will create a dedicated traffics flow for the applications (Video and VoIP) and increase the rate of traffics transmission on the applications. Reference 1)Queuing s: Order of Packet Transmission and Dropping (pdf). Available at: booklet /lab9.pdf(accessed 05 April, 2015) 2)Kritika, S., Nitin, B., Namarta, K Performance Evaluation of WLAN Scenarios in OPNET Modeler. International Journal of Computer Applications ( ). Volume 22 No.9 May Available at: pdf (Accessed 24 March, 2015). 3)OPNET Technologies Configuring Applications and Profiles (pdf).available at: /~ziochr/ network_lab/configuring_applications.pdf (Accessed 24 March, 2015) 4)Athanasios. V, Yan. Z, Thrasyvoulos. S Delay Tolerant Networks: Protocols and Applications (Wireless Networks and Mobile Communications). Boca Raton, FL CRC Press. 5)Noreen, P Voice Traffic over Mobile Ad Hoc Networks: A Performance Analysis of the Optimized Link State Routing Protocol. AFIT/GCE/ENG/ Ohio, Wright-Patterson Air Force Base. 6)Sarkar, N.I, Halim, S. A Simulation of computer networks: simulators, methodologies and recommendations, The Proceeding of 5th International Conference on Information Technology and Application. 2008: Cairns, Australia. p )Kathiravan. K, Thamarai. S, Selvam. A TCP performance analysis for mobile adhoc network using on-demand routing protocols. Ubiquitous Computing and Communication Journal, pp April )Martha, R Introduction to Telecommunications. 2 nd Edition. New Jersey. Prentice Hall. 9)El-Sayed. H.M Performance evaluation of TCP in mobile ad hoc networks: A proceeding of a Second International Conference on Innovations in Information Technology Seoul, South Korea. 10)Ahmad. A, Eitan. A, Philippe. N A Survey of TCP over Mobile Ad Hoc Networks. Cedex (France). INRIA Sophia Antipolis. 11)Williams, S Data and Computer Communications (International Edition). 7th Edition. Harlow. Pearson Education Ltd. 12)Simon, H Communication Systems. 4 th Edition. New Jersey. John Wiley & Sons.