Application Tool for Prediction and Implementation of ...

Application Tool for Prediction and Implementation of QoS in IP Based Network Jaroslav Frnda1, Miroslav Voznak1, Martin Hlozak1, Jiri Slachta1, Jerry Chun-Wei Lin2 1

Department of Telecommunications, VSB – Technical University of Ostrava, 17. listopadu 15, 70833 Ostrava, Czech Republic {jaroslav.frnda, miroslav.voznak,martin.hlozak, jiri.slachta}@vsb.cz 2 Innovative Information Industry Research Center, School of Computer Science and Technology, Harbin Institute of Technology Shenzhen Graduate School, Shenzhen 518055, China [email protected]

Abstract. This paper deals with the application able to predict the quality of Triple play services in the network. Our previous results led to the creation of mathematical models for each service type (voice, video and data), and the application offered fast calculation of reached quality according to the objective evaluation methods. Because our application is still being developed and tested, the version described here offers a new features and measurement parameters. The verification of results was performed on two the most common network infrastructure vendors (Cisco and Huawei) and the new codecs were added too. The application can not only predict QoS parameters, but also generate the source code of particular QoS policy setting according to the user interaction and apply the policy to the routers in the network. The contribution of this paper lies in designing an extended version of SW tool capable of predicting the quality of Triple-play services in networks and configuring QoS policies on routers. Keywords. Application, Delay, E-Model, Network Performance Monitoring, Packet Loss, QoS, Triple Play, Voice Service

1

Introduction

Network convergence that took place during the early 90’s of the 20th century brought the new network concept based on IP called NGN (Next Generation Network). This concept allowed the transfer of formerly separate services (voice, video and data) by one common network infrastructure. However, this transition had to deal with some difficulties because packet networks based on IP protocol had not been designed to transfer delay-sensitive traffic. The difficulties appeared especially at the transfer of voice. Packet network has to use supplementary mechanisms securing the

quality of service during the transmission over the network, able to provide a highquality interactive communication similar to standard fixed lines (PSTN). QoS policies used for prioritization of time-sensitive data streams on routers seems to be a one of the techniques for securing at least minimal QoS level in a packet network. The second important factor is network monitoring. Constant network performance monitoring and intervening as needed, keep the impact of network behavior on the acceptable level. Therefore, the purpose of the application described in this paper is to provide an effective monitoring tool capable of predicting qualitative QoS parameters according to network status. The application aims to be an alternative to expensive monitoring tools, as well as a helpful tool for designing the network infrastructure and implementation of QoS policies on selected routers.

2

State of the Art

Last decade brought growing interest in multimedia services transfer through packet networks based on IP protocol. Nowadays, voice and video service as a component of Triple play make a significant part of total data sended via the network. Voice as the most sensitive service to an overall network status, depends on many QoS parameters. Particularly, jitter and packet loss have an important impact on voice quality [1], [3]. To achieve the satisfactory voice quality, the network architecture must be designed by using representative congestion management techniques. Congestion management features allow to control congestion by determining the order in which packets are sent out an interface based on priorities assigned to those packets. The main contribution of these works [1, 2, 3, 4] is to analyse of the impact of impairments mentioned above and effectiveness of particular QoS policy implementation. In order to implement methods for packet classification and prioritization, it is necessary to monitor the QoS parameters, by means network measurements. Evaluation of voice service according to the network behavior is based on the simplified version of calculation model based on recommendation ITU-T G.107 (also known as E-model) [5]. This model allows to evaluate the quality of speech, adjusting the model to be suitable especially for packet networks. The reason why network monitoring plays an important role in securing the QoS is depends both on a delay and jitter factor on network utilization. Works [6, 7] analyse in detail the impact of network utilization on the variable component of total delay and packet loss. This paper follows directly our previous experiments studying the impact of full network utilization and performance of data prioritization on the final quality of service [2]. For further upgrade of the prediction model, it was essential to focus on several new factors. The extended version of our application offers QoS prediction for additional voice codecs and the possibility of QoS policy implementation. We used our measurements results of two most commonly used network vendors too. According to the reliable information on Triple play quality in network calculated by our tool, the user can select and generate the implementation code for particular QoS policy for both vendors and send this configuration on the router. Because the inclina-

tion to NGN concept is huge, that is why monitoring of impacts on QoS efficiency and evaluation is highly important and necessary in order to secure the competitiveness of any multimedia services provider.

3

Methodology

Nowadays, practically, computer networks are not built only on a homogeneous infrastructure, but they use heterogeneous devices. The first version of our mathematical prediction model was based on Cisco devices, and we wanted to know if it is possible to use this model for the network devices of Huawei company. Our testing scenarios brought the verification of mathematical model used in the application by performing measurements in a topology with Huawei network items. The next part of measurements was dedicated to analyse packet loss tolerance on additional voice codecs. Implementation of the computational model was carried out in programming language C#. 3.1

Measured Parameters

E-model, defined by Recommendation G.107 by ITU-T [5], was used as an objective evaluation method for voice service. This recommendation also includes a set of recommended values which enable to simplify the calculation so that it corresponds with packet networks as follows: R = 93.35-ID - IE-EFF (1) Regarding of QoS in IP networks, transmission bandwidth, packet loss, network delay and variation in latency (jitter) are key parameters [3]. The goal of the QoS is to improve values of these transmission parameters. These parameters can be express in two factors used for R-factor calculation, namely in ID (2) and IE-EFF. ID = IDTE + IDD

(2)

The parameter IDTE represents the factor of impairment caused by echo (Echocancellation has been solved in ITU-T G.168 recommendation), and IDD represents the factor of impairment caused by the too long transfer delay. In generally, the factor Ie−eff represents impairment caused by low bit-rate codecs and actual packet loss ratio of the network.Typical score range of R-factor is from 50 (bad) to 100 (excellent). By keeping all the default values during the calculation, the R-factor reaches a final value of 93.35 [2]. In order to meet user’s expectations, the value of 70 or more is needed [5]. Except from the R-factor values, a rating scheme of 1 – 5 (5 is the best), called MOS (Mean Opinion Score), can be used as an evaluation scale. Conversion of the Rfactor values to MOS scale values is also described in G.107 recommendation. In our case, network delay is an important component of end to end delay in network. It represents queuing (processing) delay on routers and it is directly influenced by using QoS policies. Delay variation (Jitter) describes variability in the packet delivery time to the target node causes incorrect order. Packet loss occurs when one

or more packets of data traveling across a computer network fail to reach their destination. It is most often expressed as a percentage. As it can be seen in Fig. 1, we created network topology, which can be used to obtain the appropriate values of important parameters. Huawei AR3260

Huawei AR2220 192.168.1.0/24

.1

.2

10 Mbps .1 192.168.0.0/24

.1 10 Mbps

10 Mbps

192.168.2.0/24

Cisco Catalyst 2950

Cisco Catalyst 2950

10 Mbps

VoIP EP1 client .10

VoIP EP3 client .11

Video EP5 client .12

FTP server .13

HTTP server .14

IxChariot .20

10 Mbps

VoIP EP2 client .10

VoIP EP4 client .11

Video EP6 client .12

FTP client .13

HTTP client .14

RTP stream RTP stream RTP stream FTP stream HTTP stream

Fig.1. Network topology for QoS testing

Our network topology consists of two Huawei routers (AR3260 and AR2220), two Cisco switches (Catalyst 2950), four VoIP clients, two Video clients, FTP client and server. During testing, all interfaces used only Ethernet-based protocol and speed of 10 Mbps for better full network utilization. In order to simulate voice and video traffic, IxChariot tool from Ixia company was used. Simultaneously, the first VoIP traffic stream was transmitted between VoIP endpoint EP1 and VoIP endpoint EP2, the second between VoIP EP3 and VoIP EP4. Video stream was transmitted between the EP5 and EP6 and the data service was generated by using FTP service. QoS policies were implemented on both routers, and this topology served us for verification of our prediction model for Huawei devices. If we wanted to add new voice codecs into the application, we had to make tests of packet loss robustness. For emulation of packet loss in the computer network, we used Linux tool, called Network Emulator (NetEm). Due to this Network Emulator, we could change values of packet loss using individual stepwise test. For every scenario, we performed ten individual tests of packet loss from 0% to 10% while each test was performed five times. For audio traffic, we chose the most used codecs G.711, G.711 with PLC, G.729, and AMR 12.2 kbps. G.711 is a primary codec used in telephony services using 64 kbps of network bandwidth. Packet Loss Concealment (PLC) algorithm is an appendix to G.711, and it can help hide transmission losses in a packetized network based on CELP. G.729 is low bandwidth codec using 8 kbps of bandwidth and mostly used as an alternative to G.711 codec for VoIP communication. AMR

codec is a hybrid speech codec using LPC and ACELP and nowadays is widely used in UMTS and LTE networks. Table 1. Different QoS configuration commands with descriptions Description Creating classes for defining appropriate traffic The definition of the type of traffic Creating appropriate traffic behavior Creating of traffic policy

Huawei configuration commands

[Huawei]traffic classifier

Cisco(config)#class-map

[Huawei-classifier-VOICEin]if-match { acl | dscp }

Cisco(config-cmap)#match { accessgroup | ip dscp }

[Huawei]traffic behavior [Huawei]traffic policy

Assigning class to policy-map

Setting appropriate policy Assigning class and behavior of traffic under a common policy Assigning a common policy to the interface

Cisco configuration commands

Cisco(config)#policy-map Cisco(config-pmap)#class

[Huawei-behavior-VOICEin]remark dscp | queue llq bandwidth { [pct ] | [transmission rate ] } | bandwidth { [percent ] | [transmission rate ] }

Cisco(config-pmap-c)#set dscp | priority { [percent ] | [transmission rate ] } | bandwidth { [percent ] | [transmission rate ] }

[Huawei-trafficpolicy-QueueOut]classifier behavior [Huawei-FastEthernet0/0/0]traffic-policy {inbound | outbound}

Cisco(config-if)#service-policy {inbound | outbound}

At first, we tested performance of QoS policies settings and compared to the results obtained if no policy was set. For voice flow, we chose Low-latency queuing (LLQ), which is useful for delay-sensitive and gave absolute preference over the other traffic. Video and FTP data flow used Class-Based Weighted Fair Queuing (CBWFQ), which can guarantee percentage transmission rate of the interface for every CBWFQ queue. The rest of the data flows (with no classification) were inserted into the special queue, called Weighted Fair Queuing (WFQ). For every unclassified data flows were automatically created an individual queue. For CBWFQ with priority queue LLQ were used two scenarios. Voice service got 7.5% and 10% of total transmission speed video 40% and 30 % respectively. The process of classifying packet and the subsequent use appropriate queue using Huawei devices is very similar to classifying packet of Cisco router. The input interface of this router marks every incoming packet. Based on IP

address, the IP packets get the appropriate value of DSCP (Differentiated services code point). According to this classification in IP header were the relevant IP packets queued and sent to the output interface. We found the different behavior and packet processing compared to Cisco. Huawei routers had smaller buffers for processing of IP packets. During the buffer overflow, packets were dropped. The disadvantage of this behavior was a high packet loss. Cisco routers have a much bigger buffer for processing of packets. Therefore, more packets are able to queued much longer. This behavior caused very low or no packets loss, but processing delay on the router was higher. QoS configuration commands are very similar to Cisco devices. Following table show up differences between this two big vendors. During the measurements, we mainly focused on critical parameters called Packet loss, Network Delay and Jitter. These calculated values were obtained from IxChariot tool and described below. As a default QoS policy on Ethernet interface, Cisco routers use Best effort policy based on FIFO (First In First Out) [8]. It is a connectionless model of delivery that provides no guarantees for reliability, delay or other performance characteristics. Routers from Huawei company use Custom Queuing (CQ) as a default QoS policy on Ethernet interface [1]. This different attitude causes that we must implement the configuration of CQ for Cisco, but for Huawei it is sufficient to create a packet classification by using DSCP and this policy will be set automatically. With CQ, a network administrator can control the available bandwidth on an interface when it is unable to accommodate the aggregate traffic enqueued. Associated with each output queue is a configurable byte count, which specifies how many bytes of data should be delivered from the current queue by the system before the system moves on to the next queue (maximum 16 queues). We used for each service type separate queue.

4

Results

As it was mentioned above, simplified E-model consist of two factors influence the final score of R-factor. Parameter ID can be expressed like function between the absolute delay and obtained R-factor value [9]. When the value of absolute delay is higher than the recommended boundary 150 ms, voice quality goes rapidly down [9]. This relation is the same for all voice codes. For adding new voice codecs, we need to focus on the packet loss impact on voice codec. Figure 2 shows the packet loss impairment factor IE−EFF on voice codecs G.711 and G.729 achieved from previous work [2], and newly added codecs G.711 with PLC and AMR codec. The results of measurements showed following regressive equations: For codec G.711 PLC Y = a + (b ∗ X) , Y = IE−EFF a = 0.0789377

X = packet loss (%) b = 2.38358

R2 = 99.13 %

(3)

For codec AMR 12.2 kbps Y = √(a + (b ∗ X ) ) , Y = IE−EFF a = 35.3068

R2 = 99.51 %

(4)

X = packet loss (%) b = 225.352

50 45 40 35 30 25 20 15 10 5 0 0

1

2

3 G.711PLC

4 5 Packet loss [%] AMR

6

G.711

7

8

9

G.729

Fig.2. IE−EFF factor for voice codecs

The measurements of QoS Policy effectiveness on Huawei routers show, that automatically set CQ policy does not achieve the same level of performance than on Cisco routers. Especially packet loss rate is too high for securing a good voice quality. On the other side, different Huawei behavior described in section 3.1 reaches better results for both CBWFQ policy scenarios. Actually, CBWFQ is very preferred QoS policy and our results confirmed that Huawei is ready to be a full-fledged competitor for the Cisco and it can be a part of heterogeneous network cooperating with Cisco routers. Table 2 also shows predicted values from our application and as it can be seen, prediction of network delay is similar with real values. Jitter buffer represents recommended size of De-jitter buffer on receiving side, that should be at least 1.5 bigger than average measured jitter value [10]. Because Huawei routers need less buffer size than routers from Cisco, we must edit and calculate the different size for Cisco router and Huawei. These results will help us to prepare better model will correspond with real behavior in the network.

Table 2. Comparison of results between Cisco, Huawei and prediction model

Name of Policy

Huawei

Cisco

Application

Network Packet Jitter delay Loss [%]

Network Jitter delay buffer

Network delay

Jitter

Packet Loss [%]

CQ

14.8

2.9

6.1

9.3

5.5

0.6

10

10

CBWFQ

11.9

3.6

0.04

17.2

18

0.02

15

30

12

5

0.07

14.39

23.5

0.01

15

35

CBWFQ1

NOTE: DELAY AND JITTER VALUES ARE EXPRESSED IN MILLISECONDS

4.1

Configuration of Network Components from Implemented SW

For the purpose of the configuration of network devices from developed application, it was necessary to decide whether the application should use conventional methods for its configuration or to use modern NETCONF protocol. Future implementations of this application should support both methods. For the first implementation, we have chosen the conventional method using the CLI via SSH protocol since the Huawei routers used in this project does not support NETCONF protocol, even if the vendor documentation declares it. The main idea of the configuration and communication framework in the implemented application is to separate its logic from the configuration content. In the first project iteration, we are aiming for the configuration of devices running any remote CLI. The application design has to reckon with the future changes which assumes the future support of NETCONF protocol. A naive implementation that uses Secure Shell is preferred since Huawei devices used for this project does not support NETCONF protocol. The application provides an implementation of simple template engine for which the templates and the values are provided. Thus, we do not interfere with the configuration and communication side of the application, which does only the same repetitive algorithm for passing through generated configuration to remote CLI.

Fig.3. Diagram of communication between the application and router

Fig.4. Graphical design of the application

Currently, besides the mentioned implementation, the application is prepared to support editing configuration on remote devices. The basic approach is depicted in Figure 3. Architecture is divided into two separate parts – template and communication part. The template part accepts data streams in a form of template file and values file. When the data streams are passed through the template engine, the configuration is generated and given to communication framework. The communication framework does all the logic in the SSH session or NETCONF session, transmits all the configuration data and closes the session.

5

Conclusion

The main goal of this paper was to upgrade our SW tool that served as a simulation model for computing an objective QoS parameters of Triple play services in IP network. In order to develop our SW application for the routers of Huawei company, it was necessary to create real computer network and apply appropriate QoS policy. Based on many measurements we obtained appropriate values, which were used for extension of our mathematical prediction model. Concerning to cover the wide spectrum of the most used voice codecs, we performed new tests and added new voice codecs into the application. Due to this application ISP can predict objective QoS parameters of triple play services and help to him in network design. The application also allows to generate the configuration of selected QoS policy and saves time during the implementation of QoS techniques on routers in the network. The next step should be a performance analysis of the new video codec H.265 (HEVC) that is the successor of today used codecs MPEG-2 and MEPG-4 (H.264). Our goal is to predict QoS not only for the most used voice codecs but also for all video codes typically used for video streaming.

Acknowledgement The research research leading to these results has received funding from the grant SGS reg. no. SP2015/82 conducted at VSB-Technical University of Ostrava, Czech Republic and by the project reg. no. MK4005611 aiming at research and cooperation between universities in China and VSB-Technical University of Ostrava.

References 1. Hany, U., Hossain, S., Saha, P.K.: QoS optimization and performance analysis of NGN. In Proceedings of Electrical and Computer Engineering (ICECE), pp. 364-367, (2010) 2. Frnda, J.,Voznak, M., Sevcik, L.: Network Performance QoS Prediction. In: Advances in Intelligent Systems and Computing, Volume 297, pp. 165-174, (2014) 3. Karam, M., Tobagi, F.: Analysis of delay and delay jitter of voice traffic in the Internet. In: Computer Networks 40: 711-726, (2002) 4. Sun, L., Ifeachor E.C.: Perceived speech quality prediction for voice over IP-based networks. In: ICC 2002, Volume 4, pp. 2573-2577, (2002) 5. ITU-T G.107, The E-model, a computational model for use in transmission planning, ITU-T Recommendation G.107, ITU-T Geneva, (2010) 6. Kovac, A., Halas, M., Orgon, M., Voznak, M.: E-model MOS Estimate Improvement through Jitter Buffer Packet Loss Modelling. In: Advances in Electrical and Electronic Engineering, Volume 9, Issue 5, pp. 233-242, (2011) 7. Abdelkefi, A., Jiang, Y.: A Structural Analysis of Network Delay. In Proceedings of Communication Networks and Services Research Conference (CNSR), pp. 41-48, (2011) 8. Mancas, C., Mocanu, M., Mancas, D.: Congestion avoidance in multimedia networks. In Proceedings of 11th Roedunet International Conference, pp. 1-5, (2013) 9. Voznak, M.: E-model modification for case of cascade codecs arrangement. In: International Journal of Mathematical Models and Methods in Applied Sciences, Volume 5, Issue 8, pp. 1439-1447, (2011) 10. Kyrbashov, B., Baronak, I., Kovacik, M., Janata, V.: Evaluation and investigation of the delay in voip networks. In Radioengineering, Volume 20, Issue 2, pp. 540-547, (2011)