Billing Schemes Evaluation for Different Network Scenarios H. Abdalla Jr 1, A. Martins 1, P. Carvalho 1 G. Amvame-Nze 2, P. Solís Barreto 2, V. Macedo 2, C. Vianna 2, J. Sombra 2 Labcom-Faculty of Technology,, Electric Engineering School, University of Brasilia (UnB) Campus Universitário Darcy Ribeiro - Asa Norte 70910-900 - Brasília - DF Brasil 1 {abdalla,martins,paulo}@ene.unb.br 2 {georges,pris,vinicius,claudio,juliana}@labcom.unb.br Abstract In this paper, we present a discussion concerning the performance of four network scenarios for billing purposes. Using the results of an experimental platform based in a state of art open source MPLS-Diffserv implementations, we evaluate the different characteristics of each environment with different traffic flows and the impact in the billing process. We study the results of total revenue calculus on each scenario using two billing schemes: (1) charging per packet and (2) reducing the value corresponding to undelivered packets I. INTRODUCTION In the 80 s, researches focused on the technological development that would allow the availability of the variety of services encountered nowadays. The efforts towards developing appropriate billing systems were little. However, the necessity to cover expansion costs and the possibility of using charging methods to influence the users behavior in order to avoid congestion increased the interest in that area [1] The majority of the billing systems is flat rate-based, where the costumers are charged indistinctly, disregarding the real network resources utilization and the type of service which is provided. This method is so abundantly used due to simplicity as it does not required any charging, accounting and metering policies. Despite of that, it is not appropriate for implementing congestion control through charging[2][3]. The increasing demand for QoS (Quality of Service) induces the development of better adjusted billing mechanisms which discriminate each kind of traffic stimulating the users to choose the most appropriate type of service, avoiding resources use and excess resource allocation. As the traffic is differentiated based on performance requirements, a QoS discriminative billing mechanism is expected to charge differently for the different type of services[4]. In order to implement congestion control through charging, we must use a billing method that relates the bill to the real use of the resources. Based on this concept we can propose one simple method: charge per sent packet. Nevertheless, due to the difficulty of tracing each packet, another possible mechanism is to count only the dropped ones and reduce their corresponding value from a certain amount. In our discussion, we try to determine which QoS environment would provide the best revenue for the service provider also regarding the users satisfaction. We will evaluate four different scenarios: IP network (best effort only), IP network with Diffserv, MPLS scenario, MPLS and Diffserv scenario. This paper is organized as follows: the network topology and traffic patterns are presented in item II as well as the description of the different classes of traffic flows used. In item III, we present a description of each scenario and the results obtained on each experiment. In item IV, we present a discussion of the results and the revenue calculus in order to determine the best environment in which we could develop the most appropriate billing system for both the user and the provider. In item V, we present our conclusions and future work. II. THE NETWORK TOPOLOGY AND TRAFFIC PATTERNS The network used for the experiments is showed in figure 1. Five different networks compose this total environment: a PSTN(Public Switched Telephony Network), an ADSL(Assymetrical Digital Subscriber Line) access network, two local area networks (LANs), a wireless LAN and a MPLS/Diffserv core. All the networks are interconnected by the MPLS core, so in this way, we concentrate the traffic from different sources in an unique point. which simulates in some manner a real multiservice network. The MPLS/Diffserv core has four routers, based on the Linux Operating System Kernel 2.4.21 and the open source MPLS implementation, developed by the Broadband Communication Networks of the Information Technology Departament of the Gent University of Belgium[5]. The routers are four computers Pentium IV 2.1GHz and are interconnected by 10/100 Mbps links. The first router, label as LSR01 connects three LANs to the core, and the LSR03, via a radio link of 2 Mbps connects the fourth LAN. The routers LSR02 and LSR04 are the forwarding elements of the core. Since our links have 10/100 Mbits, and we wanted to produce an overloaded system, specially with losses, we decided to reduce these links to 1.2 Mbps, as stated in figure 1. The configuration files for this purpose were implemented using the CBQ (Class Based Queuing) discipline for traffic control in Linux systems. We createe routing tables with more or less 65500 entries on each router. Also, the routing cache was extremely reduced to less than 64 entries and a garbage loop traffic of 640KB was simulated on each router to overload the routing cache update process, with little update and flush intervals.
Figure 1: Network Topology We work with four applications. The first two applications are used for produce disturbances and the former two are used for evaluate the losses. The applications used to produce disturbances are VBR (Variable Bit Rate) traffic patterns, with several bursts that seek to overload the links in random intervals. The applications for evaluation are CBR (Constant Bit Rate) traffic patterns.. In table 1 is shown the traffic patterns used for the experiment. The time interval for all traffics is 60 seconds. obtained in this part of the experiment are shown in figure 2. TABLE 1: TRAFFIC PATTERNS Type Port Bandwidth Packet size CBR1 5000 64Kbps 256 bytes CBR2 6000 384Kbps 512 bytes VBR1 7000 1000Kbps 1024 bytes VBR2 8000 1000Kbps 1024 bytes Both of traffics VBR have periodical burst following and exponential distribution. In the case of VBR1, there were defined periodical bursts of 0.5secs on intervals of 3secs. For VBR2 the bursts have a duration of 1secs in intervals of 5secs. All the traffic originates in the different networks connected to LSR01 and terminates on the ROUTER_ENE. Both machines, LSR01 and ROUTER_ENE are synchronized using the chrony utility for Linux systems. A. IP Network-Best Effort III. RESULTS In this first scenario, we observed the bandwidth distribution and packet loss behavior in a simulated IP network with best effort policies. The packet losses results Figure 2: Packet Loss (percentual) IP Best Effort As a result of bandwidth limitation (1.2Mbps), packet loss occurred due to the burst traffic that caused resources dispute allocation and, as no traffic is treated differently from one another, all four traffic flows were damaged almost equally. The average loss for each flow is shown in table 2. TABLE 2: AVERAGE LOSS FOR IP BEST EFFORT CBR1 3,90 CBR2 1,40 VBR1 7,30 VBR2 12,40 2
B. IP Network Diffserv In this scenario, the traffic flows were classified as shown in table 3. TABLE 3: TRAFFIC CLASSIFICATION FOR DIFFSERV Traffic Bandwidth Type CBR1 64Kbps EF CBR2 384Kbps AF11 CBR12 1000Kbps BE VBR2 1000Kbps AF21 The CBR1 traffic generated from a VoIP application has the higher priority, EF (Expedited Forwarding), followed by CBR2 which states for a video streaming traffic classified as AF11 (Assured Forwarding Class 1). For clearer observation of the bandwidth limitation and packet classification, in this second environment, another CBR traffic was used instead of the VBR1 traffic in Table 1. The results obtained in this part of the experiment are shown in figure 3. Figure 4: Packet Loss (percentual) MPLS Just like in the IP network Best Effort scenario, all flows presented significant packet loss, as shown in table 5. D. MPLS and Diffserv TABLE 5: AVAREGE LOSS FOR MPLS CBR1 5,40 CBR2 3,90 VBR1 14,10 VBR2 21,0 Using the same traffic classification used in the Diffserv scenario (see Table 3), we observed the performance of Diffserv with MPLS. Again, EF and AF11 traffics were benefited as can be seen in Table 6. FFigure 3: Packet Loss (percentual) IP DiffServ Due to packet classification, we observed a greater percentage of packet loss in those flows with lower priority. The packets from both EF and AF11 traffic were hardly ever dropped, which is a really important characteristic for applications such as VoIP and video streaming. TABLE 4: AVAREGE LOSS FOR DIFFSERV CBR1 0 CBR2 0 CBR12 35,60 VBR2 22,60 C. MPLS scenario In this part of the experiment, we used the same traffic classification used in the IP network Best Effort scenario, shown in Table 1. The results obtained can be seen in figure 4. Figure 5: Packet Loss (percentual) MPLS with DiffServ 3
A. IP Network-Best Effort Calculus TABLE 6: AVAREGE LOSS FOR MPLS WITH DIFFSERV CBR1 0 CBR2 0 CBR12 36,70 VBR2 26,30 IV. REVENUE CALCULATIONS To evaluate each scenario focusing the revenue to the service provider, we assumed that the economic value of a packet is directly proportional to a standard value V and each scenario has its own proportionality constant C. When using packet classification, the price of a packet is proportional to the priority. We assumed the proportionality constant for each type of traffic shown in table 7. TABLE 7: PROPORTIONALITY CONSTANTS FOR DIFFSERV Traffic C BE 1 AF21 2 AF11 3 EF 4 For example, a packet from a VoIP application should be classified as an EF traffic, as it requires low latency and loss rate. So, the corresponding price for this packet would be 4V. In the IP Best Effort and the MPLS scenarios, all packets are treated equally, as there is no classification, so seems reasonable to use a mean constant of 2.5 for all packets indistinctly. To calculate the average number of dropped packets N for each flow, we will use the mean traffic rate in bps R, the average packet loss in percentage L, the mean packet size in bytes S and the experiment duration in seconds T as inputs, as shown in equation 1. N = [[( R / 8) * T ]/ S] * L (1) The number of sent packets (P) can be calculated as shown in equation 2. P = [[( R / 8) * T ]/ S]* (1 L) (2) In CBR Traffics, R equals to transmission rate. In VBR Traffics, R can be approximated using the burst transmission rate in bps Br, the burst duration in seconds Bt and the between bursts interval in seconds Bi, as shown in equation 3. R = ( Br * Bt) /( Bt + Bi) (3) Using the first billing scheme (charge per packet), the revenue will be the total sum of all sent packets economic values. In the second scheme, we reduce the dropped packets corresponding value from a certain amount M. The calculus of total revenue for the IP Network - Best Effort scenario used the data summarized in table 8, 9 and 10. TABLE 8: MAIN VARIABLES CBR TRAFFICS CBR1 64 60 256 0,039 73 1801 2.5 CBR2 384 60 512 0,014 79 5546 2.5 TABLE 9: MEAN RATE - VBR TRAFFICS VBR1 1000 0.5 3 143 TABLE 10: MAIN VARIABLES VBR TRAFFICS VBR1 143 60 1024 0,073 76 971 2.5 VBR2 167 60 1024 0,124 152 1071 2.5 shown in table 11. The first row and second row correspond to the first and second billing scheme respectively. TABLE 11: TOTAL REVENUE CALCULUS FOR BEST EFFORT 1 1801*(2.5V) + 5546*(2.5V) + 971*(2.5V) +1071*(2.5V)= 23472,5 V 2 M 73*(2.5V) - 79*(2.5V) - 76*(2.5V) - 152*(2.5V)= M 950 V B. IP Network Diffserv The calculus for the IP Network Diffserv scenario use the data shown in table 12, 13 and 14. TABLE 12: MAIN VARIABLES CBR TRAFFICS CBR1 64 60 256 0,0 0 1875 4 CBR2 384 60 512 0,0 0 5625 3 CBR12 1000 60 1024 0,356 2607 4717 1 TABLE 13: MEAN RATE - VBR TRAFFIC TABLE 14: MAIN VARIABLES VBR TRAFFIC VBR2 167 60 1024 0,226 276 947 2 shown in table 15. TABLE 15: TOTAL REVENUE CALCULUS FOR IP-DIFFSERV 1 1875*(4V) + 5625*(3V) + 4717*(1V) + 947*(2V)=30986 V 2 M 0*(4V) - 0*(3V) - 2607*(1V) - 276*(2V)=M 3159 V 4
C. MPLS scenario The calculus for the MPLS scenario use the data shown in table 15, 16 and 17. TABLE 15: MAIN VARIABLES CBR TRAFFICS CBR1 64 60 256 0,054 101 1774 2.5 CBR2 384 60 512 0,039 219 5405 2.5 TABLE 16: MEAN RATE - VBR TRAFFICS VBR1 1000 0.5 3 143 TABLE 17: MAIN VARIABLES VBR TRAFFICS VBR1 143 60 1024 0,141 147 900 2.5 VBR2 167 60 1024 0,21 257 966 2.5 shown in table 18. TABLE 18: TOTAL REVENUE CALCULUS FOR MPLS 1 1774*(2.5V) + 5405*(2.5V) + 900*(2.5V) + 966*(2.5V)= 22612.5 V 2 M 0*(4V) - 0*(3V) - 2607*(1V) - 276*(2V)=M 3159V D. MPLS and Diffserv The calculus for the MPLS - Diffserv scenario use the data shown in table 19, 20 and 21. TABLE 19: MAIN VARIABLES CBR TRAFFICS CBR1 64 60 256 0,0 0 1875 4 CBR2 384 60 512 0,0 0 5625 3 CBR12 1000 60 1024 0,367 2688 4636 1 TABLE 20: MEAN RATE - VBR TRAFFIC TABLE 21: MAIN VARIABLES VBR TRAFFIC VBR2 167 60 1024 0,263 321 901 2 shown in table 22. TABLE 22: TOTAL REVENUE CALCULUS FOR MPLS-DIFFSERV 1 1875*(4V) + 5625*(3V) + 4636*(1V) + 901*(2V)= 30813 V 2 M 0*(4V) - 0*(3V) - 2688*(1V) - 321*(2V)= M 3330 V V. CONCLUSIONS AND FUTURE WORK For billing purposes, we have two conclusions from the experimental results. For providing QoS benefits for both service provider and customer there are some considerations. In one side, the customer receives better performance in higher priority applications. On the other hand, packet with lower economic value is dropped more than those with higher value, probably raising the providers revenue. The results analysis demonstrates that MPLS, despite of the benefits that it provides in terms of latency and jitter, does not affect the drop of packets that much, hardly affecting the final revenue. In fact, comparing the revenues of IP Best Effort and MPLS scenarios, the first one has a better result. The same happens comparing Diffserv and MPLS with Diffserv scenarios. Also the results demonstrate that the Diffserv scenario has better performance for both the provider and the customer. When decided the best environment in which to develop a billing system, other aspect must be analyzed for that matter: in case of retransmission, should the customer be charged? Who should be charged in a call: who is calling, who is called or both? Voice and data services require charging methods that differentiate the price depending on the application and the QoS which is provided for it. Diffserv appears to be a feasible architecture for developing an adequate billing system. VI. REFERENCES [1] M. Falkner, M. Devetsikiotis e I. Lambadaris, An Overview of Pricing Concepts for Broadband IP Networks, Carleton University, IEEE Commucations Surveys, 2000 [2] M. C. Caesar, S. Balaraman and D. Ghosal, A Comparative Study of Pricing Strategies for IP Telephony, Departament of Computer Science, University of California at Davis, Paper 0-7803-6451-1/00 IEEE, 2000, pág. 344 349 [3] Usha.com, IP Billing, White Paper VoIP Billing, Available: http://www.ushacomm.com/voipbilling.pdf [4] P. Guha, S. Maitra, T. R Sahoo, J. Sharma, Billing and QoS Systems for Public Access 802.11 Networks, Dept. Of Computer Science, University of Arizona, Available:http://www.cs.arizona.edu/people/payalg/mobile/ final3.pdf [5] http://dsmpls.atlantis.rug.ac.be [6] Remco van de Meent, Prototyping the DiffServ MIB, Departament of Computer Science, University of Twente, 25th August 2001. Available http://wwwhome.cs.utwente.nl/~meentr/docs/rvdmeentmsc-thesis.pdf [7] Vitor Roque, Qualidade de Serviço em Redes IP, Departamento de Informática, Escola Superior de Tecnologia e Gestão/ I.P.G. Available:http://www.ipg.pt/user/~vitor.roque/Apresenta% C3%A7oes/QoS%20em%20Redes%20IP.pdf 5