SLAs and Auction Mechanisms in CATI

Transcription

1 SLAs and Auction Mechanisms in CATI Noria Foukia 1, David Billard 1 Pr. Juergen Harms 1 Centre Universitaire d Informatique CUI, University of Geneva, Switzerland 1 [foukia billard]@cui.unige.ch Abstract Last year we present the new FNRS project, CATI (Charging and accounting Technology for the Internet). This new paper gives the state of progress of CATI. In this paper we focus our attention on a few points mentioned above, namely: we describe briefly the final CATI architecture interfacing IntServ and DiffServ technologies; we particularly focus on the topic concerning the charging and the accounting: we described in the previous paper the new RSVP extensions for charging and accounting; now we explain how we use these extensions in the framework of a new market-based pricing model which is based on auction and respects the principle of the incentive compatibility. In these scope we will provide new evaluation results achieved in CATI; we will show how to allow Virtual Private Network (VPN) management with QoS support using the Broker architecture in DiffServ as well as the Service Level Agreement (SLA). 1. Introduction The project, CATI (Charging and accounting Technology for the Internet) consists of the two projects CAPIV (Charging and Accounting Protocols in the Internet and in Virtual Private Networks) and MEDeB (Management, Evaluation, Demonstrators, and Business Models).The goals of CATI is the design, the implementation and the evaluation of charging and accounting and management mechanisms for value-added Internet services and Virtual Private Networks (VPN) [1]. These mechanisms were supposed to enable: high-quality Internet transport by economic incentives for E.Commerce scenarios Virtual Private network (VPN) management business models for packet-based Internet including cost and pricing models appropriate security and trust models proof of concepts by means of an IP-Phone as a sample application This new paper gives the state of progress of CATI. At the present time, many results have been achieved of which: final CATI architecture definition based on the IntServ over DiffServ model extension of IntServ model with charging, accounting and pricing objects mechanisms VPN management with QoS support business, security, and trust model definition definition of User Interface and metrics Among all these results, a number of new and intermediate results have been achieved concerning especially the Quality-of-Service (QoS) provisioning and that of a DiffServ-VPN core network taking care of the customers as well as of the Internet Service Providers (ISPs). The aspects of multiprovider models have been taken care of explicitly by the description of SLAs, their negotiation, their trading and their scopes. Another multiprovider aspect deals with the design and simulation of pricing model behaviors for dynamic market prices. It is achieved through the implementation of a new approach called CHiPS (Connection-Holder-is-Preferred-Scheme). The present paper is split into the following: section 1 gives the overview of the CATI issues and architecture. Section 2 presents the multiprovider pricing model proposed in CATI. Section 3 describes the VPN management with DiffServ-QoS support based on hierarchy of Bandwidth Brokers (BBs) which negotiate the SLAs. The last section draws the conclusion underlining the key achievements in CATI.

2 2. Problem Overview The objectives of CATI is to propose high quality transport with economic incentives for E-Commerce scenarios. For that purpose, charging, accounting and management mechanisms for value-added Internet services are required. The adopted approach in CATI tries to merge the Integrated Services architecture (IntServ) in the stub network as well as the Differentiated Services architecture (DiffServ) in the core network. For the IntServ approach we used the extensions of the Resource Reservation Protocol (RSVP) to carry relevant data for charging and pricing based on flows. These extensions were already mentioned in the paper [2], we presented last year. Since one year, the DiffServ approach focuses on appropriate signalling which considers BBs as well as SLAs as important components for a charging solution. Finally the IntServ/DiffServ interoperability for multi-provider scenarios is proposed with IntServ at the stub network and DiffServ interconnecting multiple ISPs in the core network, where transparent networking security is achieve through VPNs (Figure 1). Figure 1: Overall CATI Architecture 3. New RSVP Extension for Market-Based Pricing Model CHiPS The core architecture for CATI has been developed, based on bandwidth brokers and service level agreements being able to operate aggregated provisioning of network resources in a secure, scalable, and dynamic way. The access architecture utilizes the IntServ model as discussed in the previous section. A related micro-payment scheme, specially devoted to the payment of utilized network resources and based on micro cheques transported in a signaling protocol has been studied in the related MicPay project [3]. Due to these payment system extensions of the IntServ signalling protocol RSVP, a user can reserve resources and can be charged for the use of the network accordingly, even in a multi-provider environment. However, once the user utilizes all the technology to dynamically reserve and pay for network resources, the method to calculate the price of the service remains open. On one hand, how much the user has to pay is still mainly relying on flat fees, which do not reflect the real costs for the use of a network or its communication services. On the other hand, the notion of highly dynamic prices for communication services in such a networking environment seems to offer challenges for incentive-compatible pricing schemes. Therefore, the design and evaluation of a dynamic pricing model in a multi-provider scenario is a central task of interest. This paper focuses on dynamic pricing, which can be formulated as at a given time, the scarcer a resource is, the higher is the cost of using this resource, and conversely Design Objectives of CHiPS In this framework, the scheme CHiPS (Connection-Holder-is-Preferred-Scheme) has been designed as a flowbased dynamic pricing model using auctions in a multi-provider scenario [4] [5]. CHiPS reuses the smart market concept of [6], while extending in the following manner. CHiPS allows for the adaptation of bids to the currently valid market-price without loosing the central objective of the incentive compatibility.

3 Using auction mechanisms for end-to-end flows, supported by connections crossing more than one ISP, leads to a number of specific problems. Basically, it is necessary to perform separate auctions at least at all ISPs involved, which should be performed in an asynchronous fashion. Since a central scheme for their technical synchronization will remain too difficult, economic rules should be applied, which are in their nature decentralized in an open market environment. A practical approach for supporting the user participating in an auction for networking resources requires to set a spending cap for a requested flow. This spending cap limits the financial means to be spent for a communication service. Of course, being able to obtain the right to use a set of specified resources in the network, in a multi- ISP scenario, requires to win a set of auctions. Therefore, the (global) spending cap has to be subdivided in an efficient way into separate bids for each of these auctions. Finally, the loss of only one (local) auction has to be handled in order to prevent the entire connection from being torn down because of local fluctuations in the market Integration of Pricing and Reservations This dynamic pricing approach has been integrated recently into the currently used RSVP protocol by introducing new RSVP objects to satisfy the requirement for auctions. These new objects are able to transport pricing and bidding information, and RSVP messages are used to exchange bids. Figure 2 summarizes all different message sequences using RSVP in a multi-provider connection using auctions, but without CHiPS. ISP1 ISP 2... ISP n-1 ISP n PATH Message "Quote Phase" RESV Message "Collect Market Price" Time "Bid Phase" PATH Message "Set Bidfactor" RESV Message "Collect Market Price and Auction Result" "Bid Phase" PATH Message "Set Bidfactor" RESV Message "Collect Market Price and Auction Result" Figure 2: RSVP Message Sequence Extensions for Auctions Concerning the flow of messages, two phases are distinguished from the sender to the receiver and from the receiver to the sender Determining the Bid Factor in the Quote Phase A classical first PATH message is sent from the sender to the receiver choosing the routing and asking at each intermediate node whether sufficient resources are available for the sender. On the return path, the RESV message collects the current market-price m i of each link l i and sums it up in a newly defined sum object as follows: sum = m i Once the RESV message reaches the original sending node on its way back, a new factor, the bid factor, is calculated according to the formula: bidfactor = ( spending cap) ( sum) In this case, the spending cap determines the amount of money the user is willing to pay for the entire connection. This bid factor is envisioned as the optimal distribution factor or weight for the spending cap among all interconnected links, determining the path from the sender to the receiver.

4 Bid Phase The next PATH message contains the calculated bid factor in a new bid factor object. It is initialized once and saved at each node or in general, at every single ISP on its way to the receiver. As usual, the next RESV message is returned back to the sender collecting again all current market prices of each link l i and transmitting the sum to the source. At the source, the new bid factor is calculated and updated in the bid factor object of the next PATH message of the next Bid Phase, and so on. Only if the sender succeeds in the first complete cycle of Quote Phase and Bid Phase, can he start to transmit data until he finishes his communication or he cannot cope any more with the current market price The Connection Holder Problem Indeed, the fundamental enhancement compared to the classical RSVP protocol, is the computation of the current market price of each link, which is done locally at each provider. Users state the price they are willing to pay (the bid factor of the Bid Phase) for the resource they want to reserve. Afterwards, according to the concept of Generalized Vickrey Auctions [7], an auction mechanism establishes the current market price locally in routers or a dedicated router of the ISP. The flow will be transported, if the sender will win all local auctions. This performs economically excellent, however, it shows a major drawback, since a user already connected loses the entire connection, if he loses locally a single auction. This situation could easily happen, if new bidders arrive with higher bid factors than the ones that are currently using the link participating at the auction. This basic problem is avoided by CHiPS. The idea is to assign a slight priority to users already being connected, by giving them a second chance to keep the connection. This is performed by allowing for the improvement of their local bids, if those become too low according to the current market price. Hence, users that have lost a local auction need to be asked, whether they are willing to improve their bid for that auction afterwards above the current market price, while their respective connections are not torn down for the moment, but remain connected for one more auction cycle. Users may indeed be able to make a higher bid for specific auctions, because of two reasons: firstly, dividing the global spending cap equally among all auctions means that all the other bids might be higher than the respective local market prices. Therefore, it is possible to reshuffle this money to the auction it is needed for. Secondly, according to the concept of Generalized Vickrey Auctions, winning users normally pay less than their bids. Hence the spending cap that forms the basis for determining the bids, actually leaves some space for so-called extraordinary expenses. To be able to shuffle this gap between spending cap and real expenses towards critical places along the connection, a new bid structure has been introduced in CHiPS: b i = a i + m i f In this formula b i determines the current price the user is willing to pay for the link l i, f is the factor expressing a bid relative to the current or the previous market price, m i is the locally valid market price at ISP i, and a i is initialized to zero. Basically, a i determines an extra budget, the user could use, if he looses locally an auction on the link l i. In order to understand this new bid structure, the previous bid structure is re-used, including the bid factor. Assuming the latest definition: bidfactor = ( spending cap) ( sum) Thus, without any extra budget, b i was previously expressed as b i = m i bidfactor, because we could consider that the bid factor expresses the user bid weighted according to the current market price. Thus, the spending cap was split equally to all the links l i according to their current market prices. This new structure could be considered as a fictive one, taking into account the extra budget the user is willing to pay. Moreover, the new bid structure provides an elegant solution for the issue of signalling, where the sender is willing to increment his bid at the auction he has just lost. If a user loses a local auction for the use of the link l i, an RSVP message is transmitted from ISP i to both the sender and the receiver of that connection. This message contains the absolute value d of the difference between the price b i and the new valid market price for the link l i. On its way to the sender and the receiver, the message requests from every ISP, which are involved in the current connection, to subtract this value from the local a i. If the sender accepts to increase his spending cap for the link l i, by the value of d (i.e. he agrees to the rebidding procedure that will save his connection), he sends a rebidding RSVP message, which asks each ISP to increase a i by d. This mechanism ensures that only the bid responsible for the lost auction is changed, exactly by the necessary amount. Moreover, as the local a i is larger than 0 from now on, this means that each subsequent bid for this specific auction is slightly higher than it would be in the normal (equally distributed) case. This is justified by the fact that the respective auction has turned out to be critical, i.e. subject to unforeseen fluctuations of the market price.

5 3.4. Simulation and Results CHiPS has been investigated by a simulation tool for flow-based dynamic pricing schemes called flowsim [8]. A number of preliminary results are reported in the following paragraphs Topology The simulation topology of the chosen traffic scenario takes the following points into consideration: Different senders are able to send flows to different receivers. A congestion situation can happen in order to justify the auction mechanism. All link capacities are derived from real life scenarios: e.g., typically 155 Mbits/s in a backbone network. The sender, the receiver and all ISPs are represented by a single node in the topology. The sender can use different routes to connect to the receiver (useful in case of congestion of a link). The topology proposed in Figure 3 satisfies all of the above mentioned issues Bottleneck 8 13 Figure 3: Topology of the Simulation Scenario Simulation Context The following simulation parameters are used for the first set of evaluations: The required bandwidth per flow is set to 256 kbits/s. A new flow is generated every 4 seconds. The entire simulation has a duration of 30 minutes. An average duration of flow is 600 seconds. The mean arrival rate of the flow is 0.25 seconds. Normal links have a bandwidth of 155 Mbits/s. The link between nodes 4 and node 6 determines a bottleneck, because its capacity is reduced accordingly, down to 2 Mbits/s in the extreme case. All flows are started from two users (nodes 0 and 1). The receiver is for both senders the node Simulation Results Among a set of simulations [9], CHiPS was compared with other auction model without the notion of extra budget. The traffic summary is presented for the similar congested scenario with two users. In the first and quite simple case, both users have the same spending-cap (Table 1). Obviously, auctions running under CHiPS rarely interrupt running flows. This shows one interruption with CHiPS compared to 46 interruptions without CHiPS. In the second case, user 0 has doubled the spending cap (Table 2). In a fair scenario, the total cost of the congestion is approximately split equally among the two users. It is obvious that user 1 who has a lower spending-cap hardly has a chance to get his traffic to the receiver. That is why

6 he has a marginal cost compared to the one of the user 0. As long as the user 0 (unfair user) can fill the capacity of the link alone, he has to pay the full amount he offers. Table 1: Traffic Summary for the Congested Scenario with Two Users Link 4 6 Without CHiPS With CHiPS Accepted connections Refused connections Interrupted connections 46 1 Income node E E+11 Cost User E E+10 Cost User E E+10 Taking the numbers of interrupted connections, it has been shown that CHiPS prevents a currently active connection from being torn down abruptly. In the following it will be examined that the incentive compatibility of CHiPS is still valid and a multi-provider context can be achieved. Table 2: Traffic Summary for the Congested Scenario with Two Users. User 0 Doubled the Spending Cap Link 4 6 Without CHiPS With CHiPS Accepted connections Refused connections Interrupted connections 40 1 Income node E E+11 Cost User E E+11 Cost User E E Incentive Compatibility of CHiPS The following case is considered at this stage. If a user will get a profit by trying to fool the market, i.e. to offer a higher spending-cap that he is really willing to pay at the end, the incentive compatibility will not be achieved. Let us consider the defined variable s 1, which is the strategic factor. A user i expresses his spending-cap by the multiplication of the valuation and the strategic factor : D i D i = s i v i v i The utility function is expressed by the difference between the valuation and the price the user will pay at the end of the auction. Figure 4 shows the user s utility function according to the strategic factor with CHiPS. Figure 4: User Utility as a Function of the Strategic Factor

7 Since all bids are considered in the fictitious auction, the price paid by the allocated reservation equals essentially the correct market price. The utility has a local maximum where the strategic factor equals 1. For that reason, the user gains the highest utility by being honest and offering exactly the price he is willing to pay. This fact gives rise to think that the concept of incentive compatibility [7] is preserved by the CHiPS scheme. This concept is enhanced by the multi-provider aspect for CHiPS. Indeed a badly behaving node or ISP in the network (maybe an ISP which tends to increase its revenue by causing congestion or an ISP which lacks for capacity) could be easily found because the extra budget factor is distributed among all ISPs. CHiPS gives at least the possibility to know about effects an ISP does to other ISPs. CHiPS does not allow to renegotiate the quality during the call: CHiPS allows the user to change (increase) his price (spending-cap) with a new bid during the current communication, but as it is based currently on RSVP, it doesn t allow to change dynamically the quality users require for the same communication. The user is not allowed to lower his quantity with a new bid, as long as he has a successful bid in the auction. Therefore, the incentive compatibility is valid for static resource usages for a single connection. 4. VPN Management with DiffServ-QoS Support using the Broker Architecture as well as the Service Level Agreement 4.1. RSVP Interface for the Differentiated Service In CATI the IntServ resource reservation is successfully extended with a resource payment mechanism, that allows cost sharing between end-users. But Integrated Service allow only based flow reservation which does not scale to the core backbones (Internet). Resource reservation in the core network is more suitable using the Differentiated Service architecture. To do that, we present in CATI [10] a prototype implementation for mapping RSVP reservation to DiffServ reservation (Figure 5). In the stub network, an extended RSVP daemon (RSVP-DiffServ gateway - RDG) monitors the RESV messages and contacts the appropriate BB of the DiffServ architecture. The BB maps the IntServ reservation to a DiffServ reservation. That is the BB at the ingress router (Linux boxes in the scheme), is responsible to decide how to handle the received requests according to negotiated SLAs (source and destination addresses, network provisioning, accounting, reservation method). Figure 5: Single ISP Scenario with two DiffServ and two Linux routers 4.2. VPN-DiffServ Network In CATI, we propose to use a VPN-DiffServ architecture to address the problem of providing QoS and resource provisioning [11]. As we know, the Internet was not design to guarantee QoS, the design of new protocols and services are necessary to add the QoS to the Internet. Recently, the emergence of the Differentiated Services for IP backbones allows different levels of QoS. In this scope, the reserved flows are aggregated to big tunnels or VPNs between the border routers. The BB which aggregates flows has to resize the tunnel according to the actual load of the network as well as to the specific service type. Bandwidth Brokers as proposed in the DiffServ framework negotiate the SLAs and use local mechanisms to grant the agreed Per-Hop-Behaviour (PHB) for in-profile traffic. Therefore they have to reserve network resource. We propose to provision and allocate resource dynamically both at the edge and in the interior of the VPN-Diff- Serv network in order to support end-to-end QoS for the VPN connection. The user specifies his requirements as a range of quantitative services in SLAs for the VPN connections because the user is unable to predict the load

8 between the VPN endpoints. That is, the user who wants to establish a VPN between two stub networks and who does not know exactly the resource he needs can specify his requirements in term of range of bandwidth to his access ISP. The ISP could offer the possibility to the user to select such range of bandwidth and to activate the service dynamically on the fly, which is more flexible to the user s point of view. For supporting such services, we propose a Bandwidth Broker based automated provisioning systems in order to partition the capacity at the edge nodes to various classes of VPNs and manage them efficiently to allow resource sharing among the groups. At the edge nodes, each VPN connection uses certain amount of resource according to the SLAs. But there is the need to provision the interior nodes of the transit core network to allow the required provisioning at the edge nodes. For that, we proposed a two-layered model for VPN-DiffServ provisioning: one layer for the edge node provisioning and one layer for interior node provisioning using the BB architecture; a BB prototype has been deployed which provide the required provisioning and the connection admission based on user preferences and negotiated SLAs (Figure 6). Figure 6: Components of a Bandwidth Broker for Resource Provisioning 4.3. Major Components In this prototype, the admission process checks resource availability at the edge nodes but also the availability of quantitative resource at each node in the interior network. For that, the system needs to keep track of existing connections and available resources. It should also update the relevant databases to reflect the most recent network state. The different components which play a role are: The SLA database that contains the user identification and specifies the maximum amount of bandwidth one can have to build a VPN-DiffServ tunnel. That is, the user can choose any available option without the possibility to exceed the maximum amount. A connection database which contains a list of currently active VPNs. If a request arrives for a new VPN connection or for a VPN termination, the BB makes its decision after checking if this connection already exists or not. The storage of the established connections allows to know how much resources have been used by VPN users at the edge and interior nodes. The resource databases contains the record of quantitative resource provisioned and current resource consumption of various router interfaces (edge and interior). The topology database contains default and alternate routing paths for various VPNs source destination pairs Systems flows and Connections A user sends a connection request to the BB for a new request from the web or using any other signalling mechanism such as RSVP. This request contains user id, user password, source and remote address for the tunnel, amount of bandwidth and encryption method. The BB contacts the SLA database that is responsible for validating the user and his request. If the user is identified correctly, (his source and remote address conform the contract, the bandwidth request is less or equal to the agreed traffic contract), the BB sends a positive response. After his validation, the BB sends a signal to the configuration daemon (CD) to check its status (busy, available or down). If the CD is available, the BB contacts the connection database to allocate an encrypted tunnel of certain amount. The resource database responds to the BB and either allocates the resource or denies, based on availability. If end-to-

9 end resource allocation is needed the interior resource database is invoked. If everything goes fine, appropriate routers are configured accordingly SLA Definition in CATI Bandwidth Brokers as proposed in the DiffServ framework negotiate the SLAs. Between two ISPs or an ISP and a end-user, this SLA is a contract which specifies what service is performed during which period at what cost. In our scenario we define SLAs at each ISPs by the following parameters [12]: A traffic description which gives the support for the Per-Hop-Behaviour (PHB) and QoS parameters (bandwidth or delay) for describing a specific traffic. A geographical information from the ISP s network to the destination. A duration of the SLA: the SLA will terminate after the specified duration in the contract. The cost of the agreement: the SLA is associated with a price computed according to a local pricing model as well as to some business strategy. 5. Conclusion The work in CATI and its proposed solutions is compliant as far as possible with a number of standards and quasi standards products. The proof-of-concept for a valid usage-sensitive pricing scheme as well as a suitable and efficient charging and accounting implementation has been performed by means of an IP telephony as a sample application. In particular, CATI has achieved up to now the following key issues, ranging from important conceptual work and evaluations, including its documentation, to prototypal implementations: Definition of an Integrated CATI scenario and architecture for IntServ/DiffServ models in support of charging, accounting, and VPN management mechanisms which is complemented by a security, a trust, and a business model. Development and implementation of charging and accounting extensions in reservation which are demonstrated by a sample IP telephony application and a graphical user Interface. Design and implementation of VPN service management based on hierarchy of brokers which is demonstrated by a Web-based VPN configuration user interface. Acknowledgments This work has been performed in the framework of the project Charging and Accounting Technology for the Internet CATI (CAPIV /1 and MEDeB /1) which is funded by the Swiss National Science Foundation, SNF, Berne, Switzerland.The authors also like to acknowledge contributions of their project colleagues from the following organizations: Computer Engineering and Networks Laboratory, ETH Zürich:G. Frankhauser, G. Joller, P. Reichl, N. Weiler, D. Schweikert; IBM Research Laboratory, Zürich, Communication Systems: G.Dermler; Institute of Computer Science, Information and Communication Management, University of Zürich: H. Kneer, C. Matt, U. Zurfluh: Institute of Computer Science and Applied Mathematics IAM, University of Bern: F. Baumgarter, M. Kasumi, I. Khalil; SWITCH, Zürich: S. Leinen. References [1] B. Stiller, T. Braun, M. Günter, B. Plattner: The CATI Project: Charging and Accounting Technology for the Internet; 5th European Conference on Multimedia Applications, Services, and Techniques (ECMAST 99); Madrid, Spain, May 26 28, 1999, LNCS, Springer, Heidelberg, Germany, Vol. 1629, pp [2] N.Foukia, D. Billard: Charging and Accounting Technology for the Internet: The CATI Project; HPOVUA 1999; June [3] H. Petersen, M. Michels, D. Som, G. Fankhauser, B. Stiller, N. Weiler, R. Cantini, F. Baessler, D. Konstantas, J.-H. Morain: MicPay Micropayments for Correlated Payments; Informatik/Informatique, SI Publication, Switzerland, December 1999, No. 6. [4] P. Reichl, G. Fankhauser, B. Stiller: Auction Models for Multi-Provider Internet Connections; 10. GI/ITG Fachtagung Messung, Modellierung und Bewertung von Rechen- und Kommunikationssystemen (MMB'99), Trier, Germany, September 22-24, 1999, Session 4a: Internet. [5] N.Foukia, D, Billard, P. Reichl, B. Stiller: User Behavior for a Pricing Scheme in a Multiprovider Scenerio; Workshop on Internet Service Quality Economics; MIT, Boston, USA, December 2-3, 1999.

10 [6] J. K. MacKie-Mason: A Smart Market for Resource Reservation in a Multiple Quality of Service Information Network; Technical Report, University of Michigan, U.S.A., September [7] N. Brownlee, C. Mills, G. Ruth: Traffic Flow Measurement: Architecture; RFC 2063, January [8] D. Schweikert: QOS Routing and Pricing in Large Scale Internetworks; Diploma Thesis, ETH Zürich, TIK, March [9] B. Spielman: Design and Evaluation of Efficient Pricing Schemes for Integrated Internet Services; Diploma Thesis, ETH Zürich, TIK, Summer [10] R. Balmer, F. Baumgarter, M. Günter, T. Braun: RSVP Interface for the Differentiated Service VPN; Project Deliverable CATI-IAM-IM-I , March 15, [11] I. Khalil, T. Braun: Resource Provisioning in VPN-DiffServ Networks; Project Deliverable CATI-IAM-DE-I , March 15, [12] G. Fankhauser, D. Schweikert, B. Plattner: Service Level Agreement Trading for Differentiated Services Architecture: Computer Engineering and Networks Lab, Swiss Federal Institut of Technology, Zürich, Switzerland.