Chapter 4. VoIP Metric based Traffic Engineering to Support the Service Quality over the Internet (Inter-domain IP network)

Chapter 4 VoIP Metric based Traffic Engineering to Support the Service Quality over the Internet (Inter-domain IP network) 4.1 Introduction Traffic Engineering can be defined as a task of mapping traffic flows onto an exiting physical topology [7,62,67]. A goal of Internet Traffic Engineering (TE) is how to use the network resources effectively i.e. using intelligent routing or/and Load-balancing algorithm for avoiding congested path [27,62,69]. This results in providing a better throughput and service quality. Additionally, one major challenge in designing of Internet TE is the realization of automated control capabilities that adapt quickly to significant changes in a network status, while still maintaining stability [1]. By the proposed approach, Internet TE methodology can be divided into two major parts [27,62,69]: a routing metric which is used to calculate a route cost; a load-balancing which is used to distribute traffic load over multi-path. Typically most TE methodologies are effective in a network under a single administrative domain (intra-domain routing) such as Internet Service Provider (ISP) since information of the link characteristics and input traffic matrix can be obtained to calculate the route cost [62]. In other words, most of proposed metric for route calculation is not appropriate over the Internet where the inter-domain routing is. In additional, most of route calculating criterions are designed using common network characteristics (e.g. bandwidth, delay, hops count) without considering the network characteristic which is specific to the application such as VoIP application [4,5,8,20,42,68]. This chapter presents VoIP metric based Traffic Engineering (VMTE) which is based on a novel VoIP metric for path calculation and load balancing for improving VoIP performance over multiple end-to-end paths on the Internet in order to exploit the availability of network resources in the Internet. The proposed method focuses on VoIP application and introduces the number of Qualified Packets: Qpkt as the VoIP metric to evaluate the end-to-end path capability for VoIP application. The packet whose end-to-end delay is less than 150 msec is the Qpkt. The adaptive packet generator is used to probe the Qpkt of each available end-to-end path. The additional traffic load causing by the probing pseudo packets will not given much impact to the current VoIP call session since it will be triggered only when changes in traffic pattern is appeared. The VoIP flows will be distributed over several end-to-end paths based on their path capabilities. Some adaptive controls are used to minimize the possible alternating of the specific VoIP flow over several paths in order to reduce the packet reorder at the destination as much as possible. Based on simulation results, the proposed VMTE can increase VoIP call sessions up to 58% and 33 % when compared to traditional per-packet and per-flow [63,65,66], respectively. The rest of this chapter is organized as follows. In section 2, we explain the details of the proposed model. In section 3, we present simulation model. Section 4 provides simulation result. Section 5 provides conclusions and future work. 35

4.2 VoIP Metric based Traffic Engineering (VMTE) 4.2.1 VoIP characteristic Recently, the usage of VoIP (Voice over IP) exponentially increases within inter-domain IP network like the Internet. While the VoIP is expected to be the replacement of Public Switching Telephone Network (PSTN) for voice-call services, the voice quality of VoIP is still a concern especially within the public IP network. The following 2 conditions should be met in order to provide the acceptable voice quality VoIP call/session - One-way packet delays between two end points should be less than 150 msec which is recommended by ITUT [35] - Packet loss should be less than 5 % of total packets [51]. It should be note that one-way packet delay whose delay less than 150 msec is an excellent sound quality [35,45]. The maximum tolerable value with annoying for the one-way packet delay is 400 ms [67,45]. 4.2.2 Qualified Packet (Qpkt) / Unqualified Packet (UQpkt) The proposed VMTE must evaluate several possible route/paths between 2 end points and distribute VoIP call over them in the most efficient manner. In order to estimate an accurate path capability for VoIP, the appropriate measure which reflects to the performance of VoIP call should be used. This chapter defines two notions as follows: a) Qualified packets (Qpkt) is defined as packets end-to-end delay 150 msec b) Unqualified packets (UQpkt) is defined as packets end-to-end delay > 150 msec including the packet loss. Since the packet loss is a packet whose delay takes to infinite. Note that a packet whose delay more than 150 msec e.g. 500 or 1500 msec gives the same effect to the VoIP performance as packet loss. The best route for VoIP application is a route which can transmits maximum No.Qpkt. On the other hand, the worst route is a route which can transmits minimum No.Qpkt. Fig. 4.1 shows the relationship between the effective delay (ED) and the number of transmitted packets over a specific end-to-end path. The number of packets whose delay less than 150 msec is Qpkt. The other is UQpkt. Since VoIP can tolerate up to 5 % of Qpkt according to the VoIP characteristic, the route capability (RC) for the specific end-to-end path is defined as the number of packets at the point where the number of UQpkt is equal to 5 % of the number of Qpkt as in point RC in Fig 4.1. Fig 4.1: the delay response function over a specific end-to-end path 36

4.2.3 Route Capability Estimation In the proposed VMTE, the delay response function, f(x), of each possible end-to-end paths is maintained by the sender node. Multiple rounds of probing pseudo packets (Ppkt) are used to create such function. The sender node will generate probing packets and send them to the receiver via the considering end-to-end path. The volume of the first round of probing packets will start at 50 % of the current available bandwidth as in Fig 4.2. Fig.4.2: the number of probing packets starts at 50 % of the rest bandwidth with their TOS equal to 0 in order to minimize the additional packets and the effect with the existing voice packets The Type of Service (TOS) filed [67] of probing packet is set to 0 in order to minimize their effects to current traffic. The receiver measures packet delay of the probing packets and calculate the Effective Delay for this round of the probing as Eq (4.1) ED n = D n + δj n (4.1) D n : the mean of delay of all probing packets in the n th round in the unit of msec. J n : the mean of delay variation (jitter) [20] of all probing packets in the n th round in the unit of msec. ED n : the effective delay of probing in the n th round in the unit of msec. δ: the penalty factor of the jitter to the delay. Since the path with more jitter gives the worse performance to VoIP call, δ is a parameter, which reflects this fact. Note that 400 msec is used as the cut-off delay of all probing packets which do not reach at the receiver within the time. The value of 400 msec is the possible maximum delay which may occur in the VoIP call according to [35,45,67]. Fig.4.3: the probing packets generated from the source to the destination. Then, a reply packet is sent back from destination to source in order to inform the source that No. Probing packets (Ppkt) generated should be increased, decreased or stop. 37

The receiver will send back the reply containing the ED of this probing round as in Fig 4.3. The sender will record a pair of (No.probing packet, ED) in this probing round. Then the sender will increase or decrease volume of probing packets by 10 % at the second probing round, the third probing round according to their delay. The sender will increase number of probing packet if the previous delay is less than 150 msec. At least 3 rounds should be done in order to create the delay response function f(x) for the specific end-to-end path. The detail of Route Capability Estimation can be found in appendix D. The response function can be represented by the polynomial regressive function [47] as Eq (4.2). f(x) = a 0 + a 1 x +..a N x N (4.2) a n : the coefficients which can be calculated directly from the observed data (data sets) N: the order of regressive function. It should be noted that regressive programming can be found in Appendix E In the simulation, the linear (N=1), the quadratic (N=2) and the cubic (N=3) are used. Based on the regressive function f i (x), the route capability of the specific end-to-end path i th (RC i ) can be calculated by Eq (4.3) RC i = 1.05 f i (x=150 msec) (4.3) It should be noted that the above Eq. (4.3) is based on assumption that packet loss should be less than 5 % of total packets [51]. If there is a requirement of higher voice quality, the Eq.(4.3) can be adjusted according to the packet loss constraint. 4.2.4 Route Capability Change Detection Since route capability of a specific end-to-end path can be changed according to the real traffic flow over the path, there is a need for a mechanism to detect such changes. In VTME, the receiver will periodically calculate the ED of the real VoIP packets and send it back to the sender. The sender will try to compare the current ED and the value calculated from the delay response function f i (x). If the different is more than the pre-defined, number of packet threshold (P i ) for the pre-defined change threshold (C i ) time in row, the sender will trigger to generate the probing packets for rebuilding the new delay response time f i (x) again. The parameter P i and C i are used to minimize probing packets and filters the surge in traffic pattern. 4.2.5 VoIP call (flow) Distribution Based on the route capability estimation in the previous section, the sender keeps the route capability of each specific end-to-end path (i), i.e. RC i. In VMTE method, the sender will distribute all VoIP traffic over these several paths by per-flow concept. The flow defined as the traffic in the same VoIP call or session. The sender will use the RC i as a reference weight for the VoIP flow distribution process as in Fig 4.4 38

Fig.4.4: a distributor balances the number of VoIP flows over multiple paths according to a value RC of each path based on per-flow concept. Table 4.1 shows the distribution table for balancing the number of VoIP flows over multiple paths in some case. The expected of flow on a specific path (i) is calculated as Eq (4.4) V i = TVpkt RC i TRC (4.4) V i : the number of flow on a specific path i RC i : the route capability of the path i TVpkt : the total of VoIP flows between sender and receiver TRC : the sum of all route capabilities. The current distribution weight for a specific path i (D i ) cab be calculated as Eq (4.5) D i = V i - C i (4.5) C i : the current number of flows for a specific path i in the distribution table. When a voice packet needs to be distributed, the sender will lookup in the distribution table. If the flow id of that packet is in the distribution table, its corresponding path will be selected for the packet. Otherwise, the path with maximum D i will be selected. As a result, packets within the same flow will be kept sending on the same path as much as possible. This will minimize packet reordering at the receiver node. 39

4.3 Simulation Model 4.3.1 Network Configuration Every VoIP call sessions between 2 end points will be distributed over multiple available ISPs as in Fig 5. The background traffics described in subsection 3.2 are feeded into each ISP network in order to emulate several scenario of ISPs traffic load. The generated VoIP traffic for each VoIP call sessions (VoIP flow) is as follows: 50 packets per second (pps) are generated for each flow with the voice packet size 66 bytes and packet interval 20 msec [15,18]. The life-time for each call is 1.5 minutes [15,18]. The value of δ in Eq (1) is given as 1. More detail of network parameter can be found in appendix F.3. 4.3.2 Background Traffic Fig.4.5: network configuration in the simulation. In the simulation, the following background traffic models are used A) Background traffic was produced based on the traffics measured at the Bellcore Morristown research and Engineering facility on October 10 and Auguest 9, 1987 [33]. These traces include one million packets with the sizes from 64 bytes to 1518 bytes. Packet interval of background traffic is an exponential distribution. The mean value of packet interval of background traffic with an exponential distribution was 3.8 msec. IP packet length distribution can be found in [33]. The mean frame length of pseudo-traffic was 254 bytes. Traffic simulation can be found in appendix F.2.3 B) The background traffic has the same distribution function as A) with additional fluctuation factor over 2 parameters. The µ f is the fluctuation factor of mean packet interval randomized in range of (1, f max ) while the T f is the fluctuation factor of time period randomized in range of (0, T max ). The mean value of packet interval µ int will be 3.8µ f over the period of T f in this background traffic as in Fig 4.6. Fig. 4.6 shows the number of remaining constant in value of packet interval. 40

C) The background traffic was based on the characteristics of the Internet pattern over time ranges 24 hours in MCI s backbone [63] and the average packet per second (pps) for each mean packet interval (ms) in table 2. The average packet volumes (pps) for 24 hours on domestic and international link are roughly shown in Fig 4.7. Table 4.2 shows the load of background traffic (kbps), No. packet per second (pps) for each mean packet interval (ms). Fig. 4.7 shows values of mean packet interval (ms), the packet volume (pps) for 24 hours on domestic and international link based on traffic characteristic in [63] and average packet per second (pps) in table 4.2 4.3.3 Simulation Cases The following four simulation cases have been conducted. Four million tests have been done for each case. Case 4.3.3.1, there are 4 available ISP paths for connecting between 2 sites with a) Bandwidth parameter: 1 Mbps for each ISP. b) Background traffic: as mentioned in subsection 3.2 type A). c) VoIP flow (session): 1-80 flows 41

d) Number of intermediate routers between 2 sites: randomized in range of 2-4 nodes with uniform distribution. e) Delay parameters: o CODEC delay: 25 msec o Internet delay: 3 msec o Link propagation delay: 0.5 1 msec with uniform distribution o Node delay for VoIP packets: 0.5 msec o Jitter buffer at VoIP receiver: 40 msec Case 4.3.3.2, the same as subsection 3.3.1, except that the background traffic type B) has been used. Case 4.3.3.3, the same as subsection 3.3.1, except that the background traffic type C) has been used. Case 4.3.3.4, similar to the subsection 3.3.1 with available ISP paths from 2 up to 10. The number of VoIP flows (session) at full load tests is 40, 80, 120, 160 and 200 flows in case of 2, 4, 6, 8 and 10 ISP paths, respectively. 4.4 Performance Evaluation 4.4.1 Performance evaluation on throughput in experiment 1 without the fluctuate factor Fig.4.8: Comparison of VoIP throughput among per-packet, per-flow, VMTElinear, VMTE-quadratic, and VMTE-cubic method. Fig 4.8 shows the number of qualified packet (No.Qpkt) of the proposed method (VMTElinear, VMTE quadratic and VMTE cubic) and the exiting methods (per-flow and perpacket [63,65,66]) in the simulation case 4.3.3.1. One hundred percent of No.Qpkt means that all VoIP packets reach at the end point with in 150 msec recording to VoIP specification. This happens when only injected to the system. When the number of VoIP flows increases, the No.Qpkt of all methods decreases More VoIP flows will result more rate of decrease. When the No.Qpkt begins lower then 95%, the sound quality of VoIP flows (session) begins setting worse. Note that 95% of packet loss is acceptable for good sound quality of VoIP according to the specification. For the VoIP flows of existing per- 42

packet and per-flow are only 38 and 45, respectively make No.Qpkt lower then 95%. However, the proposed VMTE can maintain VoIP sound quality until the number of flow reaches 60. This reflects the fact that VMTE can dynamically change ISP path according to the measure which maps directly to the VoIP performance the VoIP throughput gain of VMTE over the per-packet and the per-flow are about 58% and 33 %, respectively. 4.4.2 Performance evaluation on throughput in experiment 2 with the fluctuate factor Fig.4.9: Comparison of the number of accepted VoIP flows among VMTElinear, VMTE-quadratic, and VMTE-cubic after the fluctuation factors are implemented by using the µ f in range of 1 to 0.5 and T f in range of 0 to 4. Fig 4.9 shows the performance of the proposed VMTE when background traffic becomes more fluctuated as in simulation case 4.3.3.2. The No.flows is the No.VoIP flows which make the No.Qpkt as 95%. When the value of VoIP flows of µ f and T f are 1 and 0 respectively, the number of VoIP flows of VMTE-quadratic is 60. This is the result as of Fig 4.8. As expected, more flows can be achieved when background traffic become more periodic (less fluctuated, i.e. more T f ). Less flow can be achieved when background traffic become more fluctuated, i.e. less µ f. 4.4.3 Performance evaluation on throughput in experiment 3 The performance of the proposed VMTE in the real background traffic as in simulation case 4.3.3.3 has show in Fig 4.10. The result has the same trend as of Fig 4.8, even though the VMTE achieves less throughput gain over the existing per-packet and per-flow. However, that gain is still significant. 43

Fig.4.10: Comparison of VoIP throughput among per-packet, per-flow, VMTElinear, VMTE-quadratic, and VMTE-cubic. 4.4.4 Performance evaluation on additional packets Table 4.3 and Fig 4.11 try to compare the volume of the probing packet used to collect the path capability information and the volume of VoIP packet. Only 3.5% of the probing packet is generated when the number of VoIP flow is 10. The volume of the probing packet decreases when the number of VoIP flows increases. This is because the VMTE tries to use the sending packets to collect the path information and only generates probing packet when the change of traffic pattern reaches to the specified threshold (Pi & Ci). Anyway, these thresholds can be change to be appropriate to the real network environment. Fig.4.11: Comparison of the number of Ppkt and Vpkt when the number of VoIP flows is equal to 50 flows within 90 sec. Table 4.3: shows No. VoIP flows, No. actual voice packets (Vpkt), and No. probing packets (Ppkt) 44

4.4.5 Performance evaluation on throughput in experiment 4 Fig.4.12: Comparison of VoIP throughput at nearly full load among perpacket, per-flow, VMTE-linear, VMTE-quadratic, and VMTE-cubic. The Fig 4.12 shows that, in the case simulation 4.3.3.4, the proposed VMTE still function properly when the number of ISP paths increases. This Fig shows only the point whose VoIP flows are at the full load, compared to the total available bandwidth in each case. The performance of VMTE becomes more significant, compared to the existing per-flow and per-packet when number of ISP paths increase. This can be seen from this Fig where there is more difference in No.Qpkt of these methods, when ISP paths increase. 4.4.6 Performance evaluation on throughput in experiment 5 In this experiment, we apply the VMTE approach on the intra-domain IP network in order to compare the performance between the GDSA and VMTE approach in the simulation case 4.3.3.4. There are two comparisons: the network throughput and average of VoIP packet delay. 45

4.4.6.1 Average delay of VoIP packet Fig.4.13: shows performance evaluation on average VoIP packets delay (msec) Overall, it can been seen that the GDSA (first approach) gives better average delay of VoIP compared with VMTE (second approach). Fig. 4.13 shows average VoIP packet delay of GDSA, VMTE, and Per-flow compared with Per-packet decreased to 31 %, 24 %, and 16 %, respectively. This is because the load balancing of GDSA is based on per-application which classifies application as belong one of two classes and provides the best path for first class while the balancing of VMTE is based on the traditional per-flow without concept of separating VoIP from other application. In other words, VMTE is no attempt to minimize the problem of serialization delay for VoIP with classification. However, the VMTE gives better average delay compared with traditional per-flow load balancing and per-packet. This is because the traditional per-flow tries to balancing traffic based on only resource usage while VMTE has a concept of forwarding VoIP flow according to the VoIP capability of each path. 46

4.4.6.2 Network Throughput Fig.4.14: Comparison of VoIP throughput among per-packet, per-flow, VMTE, GDSA. Overall, it can been seen that the VMTE (second approach) gives better network throughput compared with GDSA (first approach). Fig. 4.14 shows network throughput of GDSA, VMTE, and Per-flow compared with Per-packet decreased to 6.4 %, 3.2 %, and 2.8 %, respectively. This is because load balancing of VMTE is based on the traditional perflow while load balancing of GDSA is based on per-application. Additionally, network throughput of the VMTE approach and traditional per-flow are nearly the same. It should be noted that with VTME approach, only VoIP flow is distributed according to VoIP capability of each path while other applications are distributed by the traditional per-flow which uses the resource usage of each path as the distribution criteria. 4.5 Conclusion This chapter presents a novel VoIP metric criterion for estimating the end-to-end path capability for VoIP in order to avoid the congestion path and balance the voice packets over multiple ISP paths. Since the metric criterion of VMTE is based on the VoIP characteristic requirement, balancing the voice packets over multi-path can be done more efficiently. Based on experiment results, the proposed VMTE offers better throughput and service quality for VoIP when compared with the existing load-balancing tools. In addition, the proposed VMTE can keep its good performance even in the environment where there is high fluctuation in traffic and several paths have been used for the load balancing. 47