QoS Mechanism for RTP voice and RTP video based on Queuing Techniques

QoS Mechanism for RTP voice and RTP video based on Queuing Techniques

Asuquo, Philip M. Department of Electrical/Electronic &Computer Engineering, University

of Uyo,Akwa Ibom, Nigeria

Aneke, Chikezie Department of Electrical/Electronic &Computer Engineering, University

of Uyo,Akwa Ibom,

Akpabio, Itoro K. Department of Electrical/Electronic &Computer Engineering, University

of Uyo Akwa Ibom, Nigeria.

AbstractReal time voice and real time video are two main types of real time data which is utilized in the existing age of information technology, this paper will look at providing a QoS mechanism such that the quality of voice and video are maintained while transmitting through the network. The network design and the experimental split up methodology were carefully done in order to retrieve the result. Equal importance for RTP voice and RTP video are given in the experimental design. The results were clearly analysed and in depth explanation given for each and every experiment carried out. The comparative graphs were plotted for delay, jitter and packet loss for real time voice and real time video along the experiments, and detailed explanation are given for the behaviour observed in the graphs.

KeywordsQoS,Queuing,Jitter; Delay, Packet Loss, RTP, UDP

1. INTRODUCTION

   The traffic across the internet is increasing day by day. Information is available in abundance and the users utilizing the information are also abundant. Traffic is of different types like Hypertext transfer protocol, user datagram protocol, transmission control protocol, real time protocol and so on. During the 80s and the beginning of 90s, the need for file transfer protocol and HTTP type of data was enormous and Quality of service (QoS) mechanisms were focused on providing a better rate for those traffics. In later 90s, voice data were being utilized by the network users in abundance, these voice data are termed as real time data or time sensitive dataand QoS were tuned to provide a better solution for voice data. In this decade, video traffic has gained interest towards the users and is growing at a massive rate.Recent survey says that four years from now more than 80% of the traffic will be of video streaming [1]. LIVE programs and video conferences are being utilized now and these types of videos also fall into the category of real time data. The importance of real time audio and video are to be considered equally and better QoS mechanisms have to be implemented to minimise the delay in real time videos [2].

   Real time data can be classified into real time voice data, real time interactive video data and real time video streaming. The real time voice data is used by IP phones, soft phones and PSTN phones for transmitting voice across the network [3].These type of voice communication is a two way

   communication. It also uses RTP protocol [4] with various codec such as G.711, G.729, G.723, G.726, G.721 for transmitting voice data [4]. Interactive video is used by applications such as telepresence, video chatting environment and so on. Interactive video is also a two way communication [5]. Real time video streaming is mainly utilized for live telecast and this type of communication is unicast or multicast (one way communication) otherwise known as video on demand[6]. The most common of various encoding techniques that can be utilized for transmitting the video traffic over the internet are MPEG 1, 2 & 4 and H.264/AVC [7].

   This project will look at implementing an additional queuing technique to the existing QoS model so that the transmission of video and audio can take place simultaneously with less jitter, delay and packet loss. The rest of this paper is organized as follows. In Section II, some related works from other Researchers will be looked at. Section III will provide the methodology which comprises of the experimental design and experiments. Section IV will give Result analysis of different experiments conducted. Section V provides Discussion and Evaluation while Conclusions are presented in Section VI.

2. RELATED WORK

   In recent years, many researches have been conducted in different areas of QoS to enhance the increasing need of transmission of information in real time. One of the QoS Techniques identified other than congestion avoidance, policing and shapingwere queuing methods. Also in [8] and [9], queuing mechanisms identified were First In First Out (FIFO), Priority Queuing (PQ), Custom Queuing, Weighted Fair Queuing (WFQ), Class-Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ). [10], identified other queuing algorithms which include Self Clocked Fair Queuing (SCFQ), Worst case fair WFQ (WF2Q), Worst Case fair WFQ plus (WF2Q+), Round Robin (RR), Weighted RR (WRR), Deficit WRR (DWRR) and the results from the comparative analysis of three queuing mechanisms FIFO, PQ and WFQ.WFQ experiment shown that WFQ technique has a superior quality than the other techniques but it is not appropriate for delay sensitive traffic such as voice in VOIP application. PQ gives the best result for delay sensitive data so it is suitable for VOIP. Whereas FIFO is simple and fast queuing mechanism in which there is no need of reordering

   and configuring the packets. So WFQ gives good performance in FTP, Video conferencing and many more applications.

   Also in voice traffic [9], after presenting a short overview of congestion management algorithms used by routers, went ahead to evaluate three algorithms by using OPNET IT Guru Academic Edition application simulation environment and the result shows that LLQ is the most efficient algorithm for voice data transfer. NS2 was used to prove the effect of different queuing disciplines on the performance of voice over internet using Multipath Dynamic Algorithm and Simulations results confirmed that; improving the QoS of voice traffic using the Priority and Weighted-fair queues are the best suitable scheduling schemes since the values of the parameters are within the tolerable range in terms of delay, jitter, packet loss [11]. Stateless Aggregate Fair Marking with Multiple Queue Priority Scheduler (SAMQ) for Differentiated service (DiffServ) networks was proposed and simulated in NS-2[12]. Here, the flows are categorized as higher-priority or lower priority by a priority scheduler and the lower priority flows are handled by Stateless Aggregate Fair Marking technique while the higher priority flows are handled by MQFQ technique

   In [13], three Priority Queuing (PQ) based scheduling algorithms which include PQ itself, LLQ and WRRPQ (Weighted Round Robin with Priority queuing) were simulated and analysis performed while considering delay, packet loss and the possibility of their usage. The analysis verified that Priority Queuing employs strict priority for all flows; as such the lower priority traffic will suffer from high delay except high priority traffic is controlled. The LLQ combines PQ and WFQ and can help to ensure delay bounds for high priority traffic such as VoIP, emergency calls while granting traffic with lower priority entrance to output capacity. WRRPQ which is a combination of PQ and WRR (Weighted Round Robin) as another algorithm that offers strict priority to high priority traffic is needed for networks with constant packet size like ATM.

   Two Priority queues can also be configured inside LLQ and allocated different bandwidth percentages and the overall percentage must not exceed 33 % and this is known as Dual LLQ[14].The main advantage here is that dual LLQ provides maximum throughput for both voice and video traffics[15].

3. METHODLOGY

   In this section the methodology of the experiments are explained in depth. TheExperimental Design showingthe overall design is thoroughlydescribed including Network Diagram. Different experiments conducted will also be explained. The results obtained from these experiments are analysed in the next section. All the experiments were conducted in real time scenarios with the actual devices.

   1. Experimental Design

      The overall system design comprises of two Cisco 2811 series routers running Cisco IOS version 12.4 and these routers were used to send and receive the traffic for carrying out the analysis, Cisco 1900 series switches utilized as layer two devices were also used for connecting multiple systems on either side of the designed network. Video server and client running VLC media player was configured as the video server

      and the video client for transmitting and receiving real time data (RTP) and the video was sent in unicast mechanism from server to client. Also there were two Cisco IP communicator used for making voice calls across the network and the real time (RTP) voice traffic wasgenerated by these CIPCs. Finally, there is UDP server and client configured with JPerf for generating UDP traffic across the network. The JPerf client generates the UDP traffic and the JPerf server receives the UDP traffic.

      Before implementing the actual traffic in the designed network two PCs were connected with the layer two switches, all the traffic generators were checked to ensure they were working by configuring one as a client and the other as a server.

      Fig. 1 Network Diagram

      The two major reasons for using two routers were to measure the actual delay, jitter and packet loss irrespective of serialization delay and processing delay which occurs if more number of routers are present in the network and secondly, the QoS was configured in all the core routers in order to obtain results which can be analysed.The IP addressing scheme was done with VLSM. The network 192.168.1.0 /29 was connected to router R1andetwork 192.168.1.8 /29 was connected to router R2.Static route is configured between the two routers to avoid the traffic generated by the routing protocols.The video server and UDP client were placed in the same side (router R2) as the video server for generating unicast videos (RTP) and JPerf client was used for generating UDP traffic whereas CIPC phones send and receive the RTP voice traffic. Therefore, traffic leaving from router R2 are RTP video, RTP voice and UDP.

   2. Experiments

   Five experiments that were conducted to obtain the results for comparison are presented below:

   In ExperimentI as shown below, two CIPCs were configured on either side of the network, the number assigned to CIPC connected to R1was 123 and the number assigned to CIPC connected to R2 was 456. Router R1 (192.168.1.6) was assigned as the default gateway for CIPC with number 123 and router R2 (192.168.1.14) was assigned as the default gateway for CIPC with number 456. Dial pears were configured on both routers so that the phones can communicate in both directions. The codec used is G.729 with 20 ms sample size. There are a couple of reasons for using this codec; firstly, this codec utilizes less bandwidth and is recommended for congested links. Secondly, even if there is a packet loss not much of quality is affected whereas in 40ms sample size if there is packet loss the amount of information is

   twice when compared to 20ms sample size. The physical speed of the link was 2 Mbps (default) and the bandwidth of the link was 1.544 Mbps (default). The only traffic passing through the pipe was RTP voice. The bandwidth, delay, jitter and packet loss are being measured for analysis.

   Fig. 2 Layout of Experiment I

   In Experiment II as shown below,two PCs were connected on either side of the network with IP address 192.168.1.1 and 192.168.1.9 connected to R1 and R2 respectively. Ping test was carried out first to check the connectivity between the two PCs. Server 192.168.1.9 was made to generate real time video traffic and client 192.168.1.1 was made to receive the real time video traffic. VLC was used for generating and receiving the real time video traffic. The physical speed of the link was 2 Mbps (default); the bandwidth of the link was 1.544 Mbps (default). The only traffic passing through the pipe was RTP video traffic. The bandwidth, delay, jitter and packet loss were measured for analysis.

   Fig. 3 Layout of Experiment II

   In Experiment III below,three PCs were connected on each side of the network as shown in the layout (figure 4), each PC was used for generating and receiving RTP voice, RTP video and UDP traffic respectively and JPerf was used for generating receiving UDP traffic across the network. Jperf client was configured to transmit 2 Mb of constant traffic and QoS wasnot implemented in this experiment. The physical speed of the link is 2 Mbps (default) and the bandwidth of the link is 1.544 Mbps (default). The traffic passing through the pipe were RTP voice, RTP video and UDP traffic. The delay, jitter and packet loss were measured in both video and voice for analysis.

   Fig. 4 Layout of Experiment III

   Also, in experiment IV, all the traffic RTP voice, RTP video and UDP were present in the network similar to experiment III but the only difference was the implementation of QoS. LLQ was implemented in this experiment so that real time voice traffic gets high priority than all the other traffics. CBWFQ

   was allocated with equal amount of bandwidth for both real time video and the UDP traffic. The physical speed of the link was 2 Mbps (default) and the bandwidth of the link is 1.544 Mbps (default). The traffic passing through the pipe were RTP voice, RTP video and UDP traffic. The delay, jitter and packet loss were being measured in both video and voice for analysis.

   Fig. 5 Layout of Experiment IV

   Fig. 6 Layout of Experiment V

   Whereas in experiment V as shown in figure 6, though all the traffic RTP voice, RTP video and UDP were present in the network similar to experiment III but the only difference was in the implementation of QoS. Dual LLQ was implemented in the experiment such that real time voice and real time video are given priority over other traffics in the network. The bandwidth priority inside the LLQ between voice and video were varied with three sub experiments (experiment A, B and C). The traffic passing through the pipe were RTP voice, RTP video and UDP traffic. The delay, jitter and packet loss are being measured in both video and voice for analysis. The sub experiments were analysed for results and a comparative study was carried out and the results obtained.

4. RESULTS ANALYSIS

   1. Experiment 1

      As there are no other traffic except the voice, the total bandwidth was dedicated for voice RTP. According to Cisco, the bandwidth to be used by the G.729 codec with 20 ms sample over the Ethernet is 31.2 Kbps.

      Fig. 7 Bandwidth Utilization of RTP voice with CDP

      The observed bandwidth usage from figure 7 was approximately 31.8 kbps which is fairly acceptable as there are other traffics such as ICMP, CPD, loop, STP and Skinny. By the in depth observation of figure 7, there are regular and continuous spikes approximately every 60 seconds. To find the reason for the cause of spikes the call was terminated and the bandwidth was monitored.

      Fig. 8 Bandwidth Utilisation with no Traffic in the Network

      Fig. 9 Bandwidth utilised by turning CDP off

      Surprisingly the spikes were still there even after terminating the call. Looking at figure 8, it confirms that the spikes caused by Cisco Discovery protocol (CDP) packet which contains the information about the Fast Ethernet port of the switch through which the PCs were connected to the router. There by turning the CDP off in both switches, voice call is made across the test bed. The recordings prove that the spikes disappeared and the voice call was distributed along the 31.8 kbps line as sown in figure 9.

      Also, the delay and jitter coincides with each other with maximum jitter 10.98 milliseconds and maximum delay of 71 milliseconds whereas the mean jitter observed was 3.36 ms and the mean delay observed was 19.99 msec. Shown below are the graphs of jitter and delay across the network.

      Fig.10 Delay when only Voice Traffic is there in the network

      Fig. 11 Jitter when only Voice Traffic is there in the network

      Eventhough there are few spikes, the jitter and delay shown in (figure 10 and figure 11) are below the standards mentioned by Cisco (acceptable delay < 150 ms and acceptable jitter <30 ms). The packet loss measured was 0 % as there are no other traffic other than the voice traffic in the pipe.

   2. Experiment 2

      The bandwidth here is not consistent as seen in experiment I result. The reason for this is the codec, the codec used by voice RTP is CS-ACELP (G.729) in which the voice samples are sent in continuous burst. Therefore no matter what type or intensity of voice being sent, the bandwidth usage remains consistent. Video sent in this experiment is of MPEG-2 format and the bandwidth usage does not remain constant, resulting in variation of bandwidth usage as shown in figure 12.

      Fig. 12 Bandwidth Utilisation of RTP Video with no other Traffic

      The RTP video traffic was captured using wireshark and the graph plotted using matlab. The packets sent during the video transfer are ICMP, RTP (video), STP and Loop (observed using wireshark). STP was sent by the switch to all the clients attached whereas the ICMP packet was sent by the source (192.168.1.1) to the destination (192.168.1.9) to check whether the client is alive or not. Loop packets were sent by the router. The jitter and delay are in the acceptable range as shown by the figure 13 and figure 14, with zero percent packet loss. The video clarity is excellent.

      Fig. 13 Jitter when only Video Traffic is there in the Network

      Fig. 14 Delay when only Video Trafficis there in the Network

      Jitter and delay graph (figure 13 and figure 14) shows an initial peak, so a detailed look is taken at the initial few seconds no new packets where passed in the network. The experiment was repeated several number of times with the same video chunk and initial peaks remain the same to prove that these peaks are not due to the network. Two PCs were connected back to back with Ethernet cable and the same experiment was conducted.

      Fig. 15 Jitter in Video when two PCs are linked back to back

      Fig. 16 Delay in Video when two PCs are linked back to back

      The graph obtained for delay and jitter in figure 15 and figure 16 are similar to the graph obtained in figure 13 and figure 14, therefore it proved that the initial peaks were not due to the network.

   3. Experiment 3

      In the third experiment, the video transfer was made as unicast and real time. The bandwidth in the serial link was set as 2 mbps and the UDP traffic was generated in 2 Mbps fixed rate. No marking, priority or queuing technique was being implemented. By default the queuing technique in the slow speed links (serials) was weighted fair queuing (WFQ).

      The graphs below in figure 17 and figure 18 depicts the delay and jitter for both voice and video RTP data. The jitter and delay in both voice and video are high (for voice, average delay: 24.55, average jitter: 6.52;for video, average delay: 34.25, average jitter: 7.82) when compared to experiment I and II results. The delay and jitter in video were so high in comparison to the voice traffic. The packet loss for video traffic was 15.7% whereas the packet loss for voice traffic was 0.2%.

      Fig. 17 Delay in Voice and Video without QoS

      Fig. 18 Jitter in Voice and Video without QoS

      The reason for this was, all the traffics are treated as the same without any priority in WFQ. As the voice packets are large in number, marked as EF and small in size,it was better than the unmarked large video and UDP packets.

      Observation of packets transmitted during the experiment showed that, the voice packets were marked as EF (expended forwarding) by the Cisco CIPC phone, skinny traffic were marked as AF31 and the ICMP packets were marked as CS6 by the router. Video and UDP packets were marked default (00 best effort traffic) by the router. The marking of packets has a greater impact on dropping the packets.

   4. Experiment 4

      In experiment 4 Low Latency Queuing (LLQ) was implemented with the exact scenario of experiment 3. The traffic was kept constant. As the video and the UDP packets are not being marked by the router, a policy map wasembedded on the Fast Ethernet port (the port through which all three types traffic enters) of the router in inward

      direction. Inside the policy map, the class map video is marked as CS4 and the class map UDP marked as AF33. The transmission is triggered to check the marking of the packets.

      LLQ was implemented on interface serial 0/3/0 of R2, the reason for implementing LLQ on R2 alone is that the video server that generates RTP video traffic, the UDP Jperf client that generates UDP traffic and the CIPC that generates and receives the RTP voice traffic were all connected to R2. Whereas R1 was connected to video client that receives RTP video traffic, Jperf server that receives UDP traffic, and CIPC that generates and receives the RTP voice traffic. Therefore R1 generates only voice traffic.Policy map for LLQ was implemented in outward direction of the serial in R2. The class map voice-RTP matched with voice packets (DSCP EF) was given priority 33. The class map video-RTP matched with video packets (DSCP CS4) was given bandwidth 20. The class maps call signaling, critical data and UDP traffic were matched with DSCP AF31, CS6 and AF33 were allocated bandwidth 10, 10 and 20 respectively.

      Fig 19 Delay in Voice and Video by implementing LLQ

      Fig. 20 Jitter in Voice and Video by implementing LLQ

      As observed in figure 19 and 20,the delay and jitter for voice is minimised and the flow of RTP voice datawas controlled when compared to figure 17 and figure 18 obtained in experiment III. The mean jitter and delay for voice in LLQ was 5.37 and 19.8 respectively. The packet loss was 0%. The reason for the controlled flow is LLQ implementation on R2. The Delay and Jitter in figure 19 and 20 for video was nearly the same when compared to figure 17 and figure 18 of experiment III but the packet loss was reduced from 15.7 % (experiment III) to 10.2% (experiment IV).

      Fig. 21 Packet loss in Video using Wire shark capture

      Looking at the packets transmitted, it was observed that approximately 100 video packets are sent per second and the size of video packet is 1.337 kilobytes. If the video quality is to be increased, priority should be given for video as it was given to voice in the following experiments.

   5. Experiment 5

      In experiment 5 dual LLQ was configured in addition to the experiment 4. In the output policy map,dual LLQ was implemented by which the first queue was allocated for voice and the second queue was allocated for video. The reason for implementing dual LLQ is to improve the video quality by not reducing the voice quality. 30%bandwidth priority was allocated for the LLQ, both RTP video and RTP voice are made to share the 30% bandwidth provided for LLQ. 30 % bandwidth in 2 Mb link is 615 Kb. Thethree experiments conducted in order to analyse the voice and video quality they include:

      1. 10% bandwidth to video and 20 % bandwidth to voice in LLQ

      2. 15% bandwidth to video and 15 % bandwidth to voice in LLQ

      3. 20% bandwidth to video and 10 % bandwidth to voice in LLQ

   The video quality improved to a greater extent after placing the video inside LLQ.In all the three experiment (a, b and c) the video quality showed a great improvement when it was compared to previous experiments III and 4. In experiment 5 (a), the mean delay, mean jitter and Packet loss for video are26.42, 6.71, and 3.7 % respectively. The mean delay, mean jitter and max jitter for voice are 20.03, 5.51 and 10.80 respectively. In experiment V (b), the mean delay, mean jitter and Packet loss for video are 25.31, 5.92, and 3.3 % respectively. The mean delay, mean jitter and max jitter for voice are 20, 5.62 and 13.47 respectively. In experiment (c), the mean delay, mean jitter and Packet loss for video are 23.82, 4.74, and 2.7 % respectively. The mean delay, mean jitter and max jitter for voice are 20.04, 5.72 and 18.73 respectively. The packet loss for RTP voice remains constantly 0 %. The main reason for this is the voice packets are very small and the number of calls made is one (the amount of bandwidth allocated is high in all three experiments when compared to the amount of bandwidth utilised by the voice calls as observed in experiment . The graph below

   depicts the comparison of delay and jitter for all three experiments (a, b and c).

   Fig.22 Comparative Graph of Delay in Voice and Videowith Bandwidth Priority 10, 15 and 20 % byimplementing dual LLQ

   Fig. 23 Comparative Graph of Jitter in Voice and Video with Bandwidth Priority 10, 15 and 20 % by implementing dual

   LLQ

   Figure 22 and figure 23 above provides the comparison of jitter and delay for video with 10 %, 15 % and 20 % priority against voice. As voice data has a very minor variation in all the three experiments (a, b and c), it is kept constant. As the delay in figure 22of 15 % and 20 % bandwidth priority of video overlaps with each other, it is not clearly visible. The jitter and delay in figure 22 and figure 23are observed to reduce as the bandwidth priority of video is increased in LLQ but the jitter in voice is slightly increasing as the bandwidth priority is reduced for voice in LLQ. Even if there is a slight difference in voice, it is to be considered as the voice traffic is significantly low as only one voice call is made. If three or four voice calls are made, the difference will considerably be high.

   From figure 24 below, the mean delay in voice remains almost constant (20 msec) whereas the mean delay in video drops from 26 to 24 msec as the bandwidth priority is increased. The main reason for this constancy in mean delay of voice is amount of voice calls made.

   Fig. 24 Comparison of Mean Delay in Voice and Video when the Bandwidth Priority is changed inside LLQ

   Fig. 25 Comparison of Mean Jitter in Voice and Videowhen the Bandwidth Priority is changed inside LLQ

   The figure 25above depicts the comparison of mean jitter in voice and video when the bandwidth priority is increased inside the LLQ. The mean jitter in voice increases as the priority is decreased due to the design of LLQ. The mean jitter does not show a massive difference because the number of calls made is one. There will be a notable difference in jitter as the number of voice calls increases. The mean jitter observed in figure 20 of experiment IV (only voice inside LLQ) is 5.37 which is almost equal to the mean jitter observed in the (figure

   1. above. The jitter in video decreases as the amount of bandwidth increases. More amount of video packets are being placed in the TX ring as the number of packets sent from LLQ increases with the increase in the bandwidth percentage of real time video traffic.

      The graph in figure 26 below portrays the comparison of packet loss in video and voice when the bandwidth priority is increased inside the LLQ. The packet loss for video gradually decreases as the bandwidth priority increases.When the quality of video was compared with experiment andthis result shows that the quality here has drastically increased.

      Fig. 26 Comparison of Packet Loss in Voice and Video when the Bandwidth priority is changed inside LLQ

      experiments, instead of high quality, low quality videos with multiple senders and receivers could have been implemented to represent the actual and existing scenario. The number of voice calls made is one (very low); this is the prime reason for unaffected voice quality. If three or more number of voice calls is made across the network voice quality would have been affected.

5. DISCUSSIONS AND EVALUATION

   The Distributed low latency queuing (DLLQ) was unable to be implemented due to the lack of 7000 series routers in the laboratory. Real time video streaming used in the experiments is one way video transfer instead of one way streaming, interactive video (two way video transfers) could have been implemented. The high quality video is being used in all the

   Table 1 Tabular form Comparison of Packet loss and the Video Quality

   Video	Packet loss	Video quality
   video with UDP and RTP voice without QOS	15.70%	Very Poor
   Video with UDP and RTP voice with LLQ priority 33 % for voice, 20% bandwidth for video and 20 % bandwidth for UDP.	10.20%	Poor
   video with UDP and RTP voice with dual LLQ priority 10 % for video and 20 % for voice	3.70%	Good
   Video with UDP and RTP video with dual LLQ priority 15 % for voice and 15 % for video	3.30%	Good
   Video with UDP and RTP video with dual LLQ priority 20 % for video and 10 % for voice	2.70%	Very good

   The table 1 abovedescribes the relationship between the packet loss and the video quality of video as observed in experiments III, IV and V (a, b and c). The packet loss in voice remains constantly at zero as the bandwidth allocated for one voice call is high in all three experiments (a, b and c).

6. CONCLUSION

From figure 7, 8 and 9 of experiment I, it is true that the Cisco discovery protocol (CDP) causes a regular glitch in the RTP voice traffic. The irregular bandwidth usage of figure 12 and the reason for initial peaks in jitter and delay of video traffic figure 7, 8, 9 and 10 is being explained in detail by conducting various tests in experiment II. In experiment III, both real time video and voice are been sent without QoS, packets such as RTP voice, ICMP and skinny are marked EF, AF31 and CS6 by default. In experiment IV, marking of video and UDP traffic has been implemented along with LLQ 33 % bandwidth priority for voice and the results are being discussed (figure 19 and 20) in details. In experiment V, dual LLQ is implemented for voice and video traffic. Three sub experiments (a, b and c) are carried out by changing the priority of bandwidth inside LLQ for voice and video. The

results are plotted in a comparative graph (figure 22 and 23) and analysed in detail. The mean delay, mean jitter and packet loss for voice and video are plotted by changing the bandwidth priority in dual LLQ (figure 24, 25 and 26) and an in depth explanation has been provided for the behaviors observed.

REFERENCES

1. Brown, Karen. 2006. "Cisco Adds Compact Router to Cable Mix." Multichannel News 27, no. 35: 26. Film & Television Literature Index with Full Text,

   EBSCOhost

2. Wallace, K. (2009) Authorized self-study guide : Cisco Voice over IP (CVOICE). 3rd edn. Indianapolis, IN: Cisco Press.

3. Kaza, R. & Asadullah, S. (2005) Cisco IP telephony : planning, design, implementation, operation, and optimization. Indianapolis, Ind.: Cisco.

4. Light, J. & Bhuvaneshwari, A. (2004) Performance analysis of audio codecs over real-time transmission protocol (RTP) for voice services over Internet protocol: Communication Networks and Services Research, 2004. Proceedings. Second Annual Conference on. 19-21 May 2004.

5. Polycom (2008) Codec Choices for High Definition Voice Telephony. [Online]. Available at: http://www.polycom.com/global/documents/whitepapers/co decs_white_paper.pdf

6. Isomura, M., Imai, N., Yoshihara, K., Kawahara, Y. & Asami, T. (2010) Extension of Service Migration Method for Video on Demand Service: Ninth International Conference on Networks (ICN),. 11-16 April 2010. IEEE.

7. Fujitsu (2008) Video coding technologies. [Online]. Available at:

   http://jp.fujitsu.com/group/labs/downloads/en/business/acti vities/activities-4/fujitsu-labs-imagevoice-007-en.pdf

8. Onyków, P. (2013). Ensuring quality of service in computer networks based on IPv4 and IPv6. XV International PhD Workshop OWD 2013, 1922 October 2013. Polycom (2008) Codec Choices for High Definition Voice Telephony.

9. Szilágyi, S. (2013). Analysis of the algorithms for congestion management in computer networks. Carpathian Journal of Electronic and Computer Engineering 6/1 (2013) 3-7 3

10. Rastogi, S. and Srivastava, S. (2013). Comparative Analysis of Different Queuing Mechanisms In Heterogeneous Networks. International Journal of Advanced Research in Computer and Communication Engineering

11. Vijayakumar M. Karthikeyan V. and Omar M. (2013). Implementation of Queuing Algorithm in Multipath Dynamic routing architecture for effective and secured data transfer in VoIP. International Journal of Engineering Trends and Technology (IJETT) – Volume4Issue4-

    April 2013 Vol. 2, Issue 8, August 2013

12. Sivasubramaniam, N. And Senniappan, P. (2013). Stateless Aggregate Fair Marking Scheduler For Differentiated Service Networks. Journal Of Computer Science, 9 (1): 63-73, 2013. Doi:10.3844/Jcssp.2013.63.73 Published Online 9 (1) 2013 (Http://Www.Thescipub.Com/Jcs.Toc)

    ISSN 1549-3636

13. Balogh, T. and Medvecký, M. (2010). Comparison of Priority Queuing Based Scheduling Algorithms. Elektrorevue Vol. 1, No. 1, April 2010. ISSN 1213-1539

14. Cisco (2006a) Implementing Cisco Quality Of Service: Student Guide. Cisco, Volume 1:2, version 2.2. Fujitsu (2008) Video coding technologies. [Online]. Available at: http://jp.fujitsu.com/group/labs/downloads/en/business/acti vities/activities-4/fujitsu-labs-imagevoice-007-en.pdf

15. Szigeti, T. and Hattingh, C. (2004) End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs. Cisco, Networking Technology.

16. Zhikao, R., Minghua, L., Chen, Y. & Hongbo, S. (2009) The Real Time Video Transmission System Based on H.264: International Conference on Web Information Systems and Mining, 2009. WISM 2009.