Simple CPS Billing Interface - CiteSeerX

Implementation of the Cumulus Pricing Scheme for Differentiated Services in a Modular Internet Charging System. David Hausheer1, Burkhard Stiller2,1 1 Computer Engineering and Networks Laboratory TIK, Swiss Federal Institute of Technology, ETH Zurich, Switzerland 2 Information Systems Laboratory IIS, University of Federal Armed Forces Munich, Germany E-Mail: [hausheer|stiller]@tik.ee.ethz.ch, [email protected]

1

Motivation and Introduction

Charging for Internet services determines the important mechanism, which enables Internet Service Providers (ISP) to implement their business models in a commercial fashion [2], [5]. Therefore, two distinct aspects need to be considered and integrated carefully: charging technology for handling all technology-related tasks and pricing models to define the economic dimension. The Charging and Accounting System (CAS) developed so far provides a generic and modular Internet charging system [6], [7]. It is suitable for dedicated adaptation to a variety of business and application scenarios, which are differentiated by various types of pricing schemes. The calculation of appropriate charges are based on such pricing schemes that form the major part of a business model for an ISP. Pricing schemes are applied to the transport of data in an IP network and they need to cope with a number of issues of the IP technology utilized as well as with customer’s behavior and ISP’s economic requirements and goals. In particular, the Cumulus Pricing Scheme (CPS) defines a flat rate pricing scheme enhanced by a long-term feedback mechanism, which allows usage deviations on short-time scales and optimizes a suitable balance between technology-driven effort and economic viability for charging Internet services [4]. Such slow-motion dynamic flat rate schemes are found on SLA contracts between customers and ISP. The developed scheme shows a simple, transparent, market-managed, and feasible Internet pricing scheme. The compliance of the contract is motivated and supported by a feedback mechanism, Cumulus Points (CP), and the liberty for deviations on short-time scales, due to statistical metering and average CP accumulation mechanisms. The CPS scenario has been developed and implemented in a test-bed consisting of Differentiated Services routers and hosts. The set of experiences gained are outlined and the implementation is discussed in this paper in detail.

2

The Cumulus Pricing Scheme (CPS)

Based on the fine design of those parts of CPS, which are considered at the most detailed level in [3], the following subsections describe the selection of applicable parameters and thresholds, the CPS integration into the CAS, and major implementation decisions. While the general idea of CPS is the combination of an initial contract between a customer and an ISP with a new type of feedback mechanism, which interacts with the customer behavior on different time-scales, CPS in particular reduces the measurements taking place over a short time-scale. This allows for a statistical and bound evidence on user behavior on a medium timescale. This evidence is expressed in terms of discrete Cumulus Points (CP), yet not triggering a reaction by themselves, but only as a result of their accumulation over a long time-scale.

2.1

CPS Fine Design

The CPS implemented in a test-bed determines a particular scenario for investigations and it can be described by a number of important system parameters, each of which needs to be specified depending on the actual aggregated traffic characteristics. The accounting interval TA specifies the frequency of collecting mediation records, i.e. traffic samples obtained from the traffic meter. TCh is the charging interval, which denotes the duration of a session in CPS, whereas TB denotes the billing interval, i.e. the period after which the customer will be informed on received Cumulus Points. Finally, the duration of a contract is termed TC. It is obvious that T A ≤ T Ch ≤ T B ≤ T C need to be complied with, but specific values for each parameter will always depend on technical considerations, user behavior, and economic decisions. In order to determine the amount of Cumulus Points being assigned to a specific service usage, CP thresholds ϑ n need to be introduced, which determine the strength of over- or under-utilization. The choice of reasonable values for parameters and thresholds determines the major effort for a customer-provider contract. Absolute thresholds are calculated, by assuming that traffic is described by the probability density function f ( x ) and the respective discrete probability distribution F ( x ) =

x

∫0 f(y) dy = Prob{ measured traffic ≤ x } . F(x) can be calculated by numerical integra-

tion of the respective histogram. Let η n describe the probability that the measured traffic is within the interval [ ϑ – n ;ϑ n ] . This yields absolute thresholds ϑ ± n = F

– 1  1 ± η n –1 ---------------- , where F describes the inverse probability distribution function.  2 

2.2

Embedding CPS into the CAS

ethz tariff

price mediation

session

m3i

org

charge_acc

examples

As introduced, the Charging and Accounting System (CAS) provides a generic and modular charging system in support of various pricing schemes applicable to different communication technologies [6]. It consists of two core components, i.e. an accounting component and a charge calculation component, each of which with an appropriate database. Additional components and interfaces allow for the adaption to various scenarios, without the need of changing the core system. The CAS leaves it up to the designer of a particular scenario, which types of services it is actually charging for. A specific pricing scheme can be applied to the CAS by instantiating respective components accordingly. In the CPS scenario the CAS needs to account for traffic flows, e.g., in terms of volume or bandwidth, and charge for the consumption of it over a time period (charging interval). This period is also termed a session, since for CPS the duration of all sessions are of equal size during the entire contract, e.g., a week or a month, and this dimension is usually much longer than the duration of a single flow. Figure 1 gives an overview on how the CPS scenario has been adapted to the CAS. All components termed with a org.m3i.examples.ethz.CPSdemo preceding “CPS” have been implemented based on the CAS generic structure. Data type components describe the CollectingCasModule CPSBilling CPSManager ChargeCalculation CPSCreator structure of the data being handled by the system. E.g., two Accounting components CPSSessionFragment and CPSSessionCharCSDaemon CSServerThread acterization provide data structures used by the CAS to CPSTariff Tariff store data elements in the databases. In the CPS scenario UDPCPSTariffWriter this may encompass volume or bandwidth data of the trafNeMaCServer CPSSessionCharacterisation SessionFragment fic measured and information about whom the traffic NeMaCDaemon CPSSessionFragment SessionCharacterisation belongs to and how it needs to be charged or described by, NeMaCServerThread e.g., user id, contract id, service id, and session id. Other Fluid Connector CPSConnector components need to produce and process this data, e.g., the Fluid2Mediation MediationRecord Record CPSMediationRecord CPSConnector component that connects the CAS to the mediation component. It is responsible for the combination Figure 1: Overview on the CPS Scenario Embedded in the CAS of session information provided by the CPSCustomer component with the flow data provided by the CPSMediation component. CPS-related mechanisms are implemented in the CPSTariff component, which provides thresholds and reaction rules, and in the CPSBilling component, which serves as an interface to the customer specifying red or green cumulus points, which a customer receives for a specific usage of the service and the accumulation of them over time.

2.3

CPS Implementation

The CPS scenario and the CAS were developed in Java 2. The code is portable and has successfully been tested on FreeBSD, Solaris, and Windows. For data storage the MySQL database were chosen. In order to provide a real and complete environment to run the CPS scenario other components needed to be obtained. Fluid serves as a Java interface to the traffic meter. It uses the SNMPv2 Java class library from AdventNet to communicate with the meter over the SNMP protocol. Fluid has been enhanced by a method getNextData that can be invoked to receive the flow data information. It creates a session with the meter, and performs synchronous and asynchronous SNMP queries to get the next flow records. The meter itself is performed by NeTraMet [1]. These records are handed over to the CPSMediation class. The CPSMediation class instantiates a Fluid object for every meter host to collect the measured flow data by that host. As NeTraMet only provides aggregated data over time, previous values need to be stored and mediation records are produced, while the difference between two entries is used. From time to time this internal storage of flow data needs to be cleaned up. Therefore, the time-out value of every flow is periodically checked using the method removeExpiredFlows. The CPSConnector class is mainly used to connect the CAS to the mediation component, i.e. the CPSMediation class. The mediation class is started as a thread to collect flow data. The CPSConnector class transfers mediation records created by the CPSMediation class to the accounting component to record them in the accounting database. In addition, the CPSConnector class appends necessary session information to mediation records. This information is provided by the CPSCustomer class described below. The methods addCustomer and removeCustomer provide a means to manage the customer table. The session information of current customers is compared with the actual flow information and appended to those records. The CPSBilling class collects charging records from the charging database and stores them periodically in a HTML document. This document serves as a billing interface to the customer. It could easily be changed or extended for dedicated usages. After this collection the charging record is assumed to be billed and the field of the charging record inside the database is set accordingly. If the cumulated charging records add up to less or more CPs than defined in the reaction threshold, the reaction rule is called and a contract re-negotiation needs to take place. All of this will be done in the collectAndProcessRecords method. Data type classes are passed around by the above described component type classes. The FlowDataEntry class is part of Fluid’s NeTraMet package and it is used by the Fluid class to store the flow information retrieved by the meter. The CPSMediationRecord class as well as the CPSSessionFragment class contain almost the same information as the FlowDataEntry class. They are used by various component classes to create new records. All data fields describing these classes in detail are shown in Table 1.

Variable

Description

Variable

Description

flowDataToOctets, flowDataFromOctets

Number of bytes for this flow since last query (for either direction)

flowDataToPDUs, flowDataFromPDUs

Number of packets for this flow since last query (for either direction)

flowDataToBandwidth, flowDataFromBandwidth

Average bandwidth for this flow (for either direction)

flowDataDSCP

Diffserv Code Point field of the IP header

flowDataSourcePeerAddress, flowDataSourceTransAddress

IP address and TCP/UDP port of the source host

flowDataDestPeerAddress, flowDataDestTransAddress

IP address and TCP/UDP port of the source host

isFirst, isLast

First / last record of a session

customerId

Customer number

contractId

Contract number (used for the tariff)

serviceId

Service number (reserved for later use)

sessionId

Session counter

recordSource

Host Name of the meter host

flowId

Flow number provided by the meter

Table 1: Variables and their Description of the CPSMediationRecord Class The CPSCustomer class has been created to provide session information used in the CAS as mentioned above. It is used by the CPSConnector to append necessary session information to mediation records. The session information of current customers is compared with the actual flow information and then appended to those records. The method startNextSession is used to start an additional session and increment the sessionStartTime by the sessionDurationTime. The CPSSessionCharacterization class collects all session fragments belonging to a session that have been pulled from the accounting database by the charge calculation. It extends the SessionCharacterisation class and, therefore, implements the initFromFragments method, which calculates total resource usage accumulating session fragments. This class is used by the charge calculation to create charging records. Major data fields are enlisted in Table 2. Variable

Purpose

totalUpVolume, totalDownVolume

Total number of bytes for the session in either direction.

totalUpPackets, totalDownPackets

Total number of packets for the session in either direction.

averageUpBandwidth, averageDownBandwidth Average bandwidth during the session in either direction.

Table 2: Variables of the CPSSessionCharacterisation Class In the Cumulus Pricing Scheme the user is not directly charged for usage, he pays a flat rate. But the set of thresholds mentioned above limit the consumption for over- and also underusage. The user is assigned red or green points, if her service usage exceeds a certain CP threshold value mentioned in the user contract. These cumulus points can also be accumulated over time. If they exceed a certain level, the reaction rule will be applied, e.g., the contract will be re-negotiated. The CPSTariff is used to carry the information on predefined service contracts, threshold values, and reaction rules. The main method to calculate CPs is getChargeAdvice, which is invoked by the charge calculation. It compares the service usage over a session with CP threshold values and assigns appropriate CPs.

3

Evaluation

By investigating in detail the flow of data, the implementation is CPSBilling Tariff Data evaluated. Therefore, it determines where and how data is processed e.g. Thresholds CPSSessionCharacterisation using. Figure 2 depicts this data flow. The traffic is measured by CPSTariff ChargeCalculation NeTraMet, which combines the traffic, i.e. the single packets into flows CPSSessionFragment based on rules that have been provided by NeMaC. Periodically, Fluid Session Data Accounting e.g. ContractId reads out traffic flows, using the SNMPv2 protocol for meter readers, ServiceId, UserId which are currently present on the meter host. This encompasses, e.g., CPSCustomer CPSConnector the number of accumulated bytes or packets for a flow specified by its CPSMediationRecord source and destination address. Since differential numbers instead of CPSMediation FlowDataEntry accumulated numbers need to be calculated for further processing, the Fluid flow data is transformed by the CPSMediation class into mediation SNMPv2 records using the difference of two consecutive flow entries. Up to now Flow Data e.g. Volume, NeTraMet the data processing is independent completely of the rest of any appliBandwidth Traffic cation, since the CPSMediation class is running as a thread on its own. DBS However with respect to practical implementation limitations, it must Figure 2: Data Flow in the CPS Scenario be considered that the internal data buffer of the CPSMediation class is not infinite and can overflow, if data is not collected continuously. The CPSConnector class fetches mediation records from the CPSMediation component and appends the session information to those records that belong to a certain customer. Records for which there are no appropriate owners are discarded. The CPSConnector class can also generate mediation records itself. For instance, a dummy record is generated to terminate a session, if it exceeds the session duration. In the accounting class, records provided by the CPSConnector are transformed into CPSSessionFragments

and stored in the accounting database. From there, the charge calculation collects all session fragments belonging to a session that has a start point and an end point and creates a CPSSessionCharacterisation. Moreover, it calculates the charge for the service usage during that session applying the CPS tariff used for the appropriate service contract. The result is stored in the charging database, from where the CPSBilling class gets the billing information. Based on this information a user interface is created to communicate the charge to the customer in terms of assigned CPs for every session being accumulated over time. The collected charging records from the charging database are stored periodically in a HTML document, which can easily be viewed in a web browser as shown in Figure 3. The assignment of CPs for a given traffic aggregation, which was artificially generated by DBS, have been compared with a simulation model for the assignment of CPs with similar statistical values representing the traffic mix. All results from the testbed experiments with the CPS implementation described above show an identical behavior as in those simulations. The influences of real traffic and the real environment was mainly due to the normal distribution of generated traffic and an self-similar nature of traffic being measured in a real subnetwork and injected into the test-bed. In addition, the following investigations have ben performed: (1) showing the performance of the CPS implementation by determining the monitoring the usage of memory, CPU, or network bandwidth, and identifying the potential bottlenecks and limitations of the approach; (2) comparing the output of the CPS pricing mechanism, i.e., the assignment of CPs using different kinds of traffic patterns as input; and (3) comparing CPS while varying various experiment parameters and time-scales as introduced in Section 2.1. Since the current CPS implementation determines a prototype and has not been optimized for a maximum of scalability and performance, this topic has been part of a different work on tuning and measuring CAS-internal processes and tasks. However, since CPS does not count every single packet, but rather measures traffic at certain intervals with a very high probability of getting a correct sample, CPS is able to produce extremely valuable results with less effort in terms of technical accounting and, therefore, the overall system performance is of less relevance.

4

Summary and Conclusions

Simple CPS Billing Interface CPS Billing Interface

The contribution of this paper determines that the Cumulus Pricing Scheme CPS as a pricing mechanism to charge for Internet services does not only convince as a concept, but is impleStorageTimeStamp AverageUpBandwidth CPs Total CPs mentable in an efficient manner and runs in a real environment 2002-01-21 15:47:04.0 197595.7675448029 1 with minimal efforts on the technical side. CPS is a clear trade-off 2002-01-21 15:47:34.0 185428.48754475053 1 between economic requirements, usability, and technical feasibil2002-01-21 15:48:14.0 191021.6035427978 2 ity, while optimizing a viable balance. The design and prototypi2002-01-21 15:48:54.0 148503.2971595294 0 cal implementation of the CPS scenario revealed that it can be 2002-01-21 15:49:24.0 187590.54303988442 0 adapted to the structure of a generic charging system like the 2002-01-21 15:50:04.0 152440.97013856962 -2 CAS. Due to CPS’s modular design and the simplicity of the con2002-01-21 15:50:35.0 204693.99932172845 0 cept it was possible to create together a scalable and flexible traf2002-01-21 15:51:15.0 196400.47806267627 1 fic charging scenario. The configuration parameters addressed Figure 15:51:55.0 3: CPS Billing Interface to the Customer 2002-01-21 145766.50656698222 -1 can be varied according to customer-provider contract negotiations, which provides CPS as a configurable approach for different services and usage patterns. The evaluation of the concept and its implementation showed that CPS has been tested successfully on a FreeBSD and Solaris test-bed. Even other platforms may be used due to the implementation of the CAS and CPS in portable Java code. Experiments performed within the test-bed reached a good performance and verified those results from simulations. Acknowledgements This work has been performed in the framework of the EU IST project Market Managed Multi-service Internet (M3I, IST-1999-11429), where ETH Zürich has been funded by the Swiss Bundesministerium für Bildung und Wissenschaft, Bern under grant no. 99.0536. Thanks are addressed to P. Reichl for various CPS-related discussions, detailed input to Section 2.1, and J. Pandey for an initial, prototypical implementation. Many helpful comments have been received from J. Gerke, Hasan, P. Kurtansky, and the M3I project (http://www.m3i.org).

References [1] [2] [3] [4] [5] [6] [7]

N. Brownlee: Network Traffic Meter (NeTraMet) and NeTraMet Manager/Collector (NeMaC) version 4.3; URL http://www2.auckland.ac.nz/net/Accounting/ntm.Release.note.html, February 2001. J. MacKie-Mason, H. Varian: Pricing Congestible Network Resources; IEEE Journal on Selected Areas in Communications, Vol. 13, No. 7, July 1995, pp 1141 – 1149. P. Reichl, P. Flury, J. Gerke, B. Stiller: How to Overcome the Feasibility Problem for Tariffing Internet Services: The Cumulus Pricing Scheme; IEEE International Conference on Communications, Helsinki, Finland, June 11-15, 2001. P. Reichl, B. Stiller: Edge Pricing in Space and Time: Theoretical and Practical Aspects of the Cumulus Pricing Scheme; 17th International Teletraffic Congress, Salvador da Bahia, Brazil, Vol. 17, December, 2001. S. Shenker, D. Clark, D. Estrin, S. Herzog: Pricing in Computer Networks: Reshaping the Research Agenda; ACM Computer Communication Review, Vol. 26, No. 2, April 1996, pp 19 – 43. B. Stiller, P. Reichl. J. Gerke, P. Flury: A Generic and Modular Internet Charging System for Differentiated Services and a Seamless Integration of the Cumulus Pricing Scheme; Journal of Network and Systems Management, Vol. 3, No. 9, pp 293 - 325, September 2001. B. Stiller, J. Gerke, P. Reichl, P. Flury: Management of Differentiated Services Usage by the Cumulus Pricing Scheme and a Generic Internet Charging System; IEEE/IFIP Symposium on Integrated Network Management (IM’2001), Seattle, Washington, U.S.A., pp 93 - 106, May 14-17, 2001.