A Bounded Local Adaptive Packet Pricing (BLAPP) Scheme for IP Networks

Transcription

1 A Bounded Local Adaptive Packet Pricing (BLAPP) Scheme for IP Networks CHANAN GLEZER, YUVAL ELOVICI, YEHUDA BEN-SHIMOL* Departments of Information Systems Engineering and *Communication Systems Engineering Ben Gurion University of the Negev Beer Sheva, ISRAEL Abstract: - This article presents a novel congestion-based pricing scheme for IP networks, termed Bounded Local Adaptive Packet Pricing (BLAPP). The BLAPP scheme enables IP users to limit their expenses on routing packets by enforcing a price limit in the packet s header. BLAPP extends the LAPP scheme in which payment is collected on a per-packet basis in each router on the packet's path. In both protocols, each router changes its price for each service level in response to its congestion at a specific output port. Finally, the BLAPP scheme is analyzed using network simulations of traffic congestions. The analysis suggests that BLAPP exhibits a correlation between user expenses and QoS properties such as RTT, especially when the network is congested. Thus, a user may control his or her QoS using payments without having to allocate network resources on a per-session basis (e.g., RSVP protocol). Key Words: IP-pricing, IP-billing, Quality of Service (QoS), Differentiated Services (DiffServ), Service Level Agreement (SLA), Internet Service Provider (ISP). 1. Introduction The impressive scalability of the Internet infrastructure is in large part due to a design philosophy that advocates a simple architecture for the core of the network, with most of the intelligence and state management implemented in the end systems (nms.lcs.mit.edu/publications/cm-osdi2000/ cm-osdi2000.pdf). Adopting this approach resulted in Internet traffic almost doubling every year [1,2,3]. The stable increase in traffic volume eventually stretches the ability of most Internet service providers (ISPs) to keep pace with soaring demand and congestion during peak times [3,5]. In order to cope with the congestion, mechanisms for detecting congestion, as well as managing and pricing bandwidth are needed [6]. Currently, most ISPs use flat-rate pricing schemes [7, 8,14] based on the duration of usage, access speeds, number of ports used, or the allocated bandwidth capacity [7]. Flat pricing results in a problematic situation where many light users pay for traffic consumption by heavy users. Moreover, flat pricing discourages innovation, is not efficient or meaningful when appended to value-added services, and does not optimize the consumption of network resources [8,9]. The development of more sophisticated pricing mechanisms is bounded by the sophistication of network resource management. As a case in point, the Internet nowadays copes with congestion either by way of "best-effort" traffic queues or by delaying traffic (buffering) up to a certain threshold which can trigger packet dropping [10]. All in all, adopting the above two mechanisms for handling network congestion may result in degraded service level without affecting the price paid by users. One way to associate the actual QoS provided to users with the price charged is to employ QoS protocols guaranteeing a requested service level. Such protocols enable allocating network resources on a per-session basis (e.g., RSVP protocol) [11]. Nevertheless, such an approach suffers from the following drawbacks: allocated resources are not fully utilized due to inefficient definition of the user s requirements; the process of managing resources for each session/flow overloads the routers; and finally, many users may not be able to obtain guaranteed services from the network when all the resources allocated for such services are already in use. Much of related work has been focused on QoS-based pricing schemes for IP networks [4,12, 13]. The Paris-Metro Pricing [15,16,17] provides QoS for user groups by setting different prices for sub-networks. Smart-Market Pricing [10,18] splits user charges into: a fixed price to cover the connection costs; a relatively small charge in proportion to the amount of traffic to cover incremental costs; and an additional usage cost when the network is congested. Edge-Pricing [19] exploits approximations such as time-of-day or path-todestination in an attempt to differentiate user

2 charges. Priority Pricing [20-23] enables users to set a subjective "value" for their traffic by selecting a priority level, however, there is no guarantee regarding QoS. Expected Capacity Pricing [24] is based on the expected capacity provisioned by the network. Finally, Responsive Pricing [25] relies on user reactions to price changes in order to increase network efficiencies. Nevertheless, the pricing schemes described above cannot guarantee that users will be charged precisely according to the service level they consume. Moreover, many of the schemes require collecting plenty of data in order to manage charges accurately. This article proposes the BLAPP scheme which attempts to overcome the above shortcoming by supporting a bounded, price-per-service billing scheme for routing IP packets. The charge for routing packets is managed at the packet level using electronic money, namely, a cumulative route price. The cumulative route price is updated at every hop and hop. In addition, a hop price charged by a given router on a packet's path should change according to network congestion in the immediate vicinity of that router. As a result, higher congestion would increase the price of the overall routing task. BLAPP extends the extant LAPP scheme [1, 2] by enabling a user to limit his or her expenses on routing packets using a price limit stored in the packet s header. Investigating the effect of this limit on the system's performance is the main goal of this article. The remainder of this article is organized as follows. Section 2 reviews the LAPP pricing scheme. Section 3 presents the BLAPP pricing scheme. In section 4 we investigate the QoS properties as a function of the price limit using network simulations. Conclusions and future work are discussed in section The LAPP Scheme The LAPP scheme [1,2] is analogous to a toll-road where each router is placed at the entrance to the next toll-road. When a driver reaches a toll point he or she can decide whether to drive on a faster road (i.e., higher service level) for a higher price or on a slower road (i.e., lower service level) for a lower price. The driver s decision depends on his or her subjective utility function. In the case of IP billing using the LAPP scheme, each packet carries electronic money data used to pay routers along the path in return for their routing services. In order to support charging of each packet for the service it receives, an appropriate billing system is needed where routers should be able to collect and transact billing information. Fig. 1 illustrates the billing process when using LAPP. Dashed links represent connections between the routers and the billing system. Each router has a single field used to accumulate the payments for its services. The router increases this field as well as the Cumulated charge field of each transiting packet it serves. There is no need to retain any information about the user in the router itself. When the packet arrives at the last hop (i.e., destination s ISP), information about the user identity and the content of the packet's Cumulated charge field is sent to the central billing system. Each router periodically sends its cumulated charge to the central billing system, which in turn increases the account of that router. Such a mechanism generates low overhead traffic over the network as no billing information is stored in the routers regarding each packet, except for a single field that stores the cumulated charge. In order to manage the billing of each packet along its route from source to destination, the following data is appended to each packet: User identity field Used by the billing system to identify the user. Cumulated charge field Carries the total amount of electronic money the user will be charged for serving this packet. This field is being updated by routers handling the packet. User 1 User 2 User 25 1Mb/s 1Mb/s 1Mb/s (I) (II) (III) Billing System 2Mb/s Router 3 Router 4 Router 5 Router 2 Router 1 Router 6 (ISP 1) Router 7 (V) (ISP 2) (IV) Fig. 1: IP Billing Based on LAPP Scheme Server 1 Server 2 Server 3 Under the LAPP scheme, every router should autonomously map the provisioned QoS with the actual payment charged to a user. The LAPP scheme has the following two modes of operation. 1. Fixed: Each router charges the user only for the actual service the router is able to provide on a per-packet basis and the price of each service level is fixed. 2. Adaptive: The pricing scheme is enhanced to support an adaptive price per service level according to congestion in the router. Higher

3 congestion would increase the price of the service and each user would be charged accordingly, again on a per-packet basis. Some of the extant QoS solutions in IP networks are based on polling service consumption data from various communication devices (such as routers and firewalls), analyzing the collected data and charging accordingly [26]. The drawback of such solutions is that not all network devices can be accessed by the central billing system and that the collected information contains large number of records needed to be checked, aggregated and sent to the central location on the network [26]. Contrary to existing solutions, in the LAPP pricing scheme charging is done locally in each router on a per-packet basis without polling information from other communication devices. Each router acts as an autonomous service provider and independently sends its aggregated billing information to a central billing site from time to time. 3. The BLAPP Scheme LAPP introduces substantial benefits to both users and ISPs compared with fixed a pricing scheme [1, 2]. Whenever the congestion is low, users would pay less than they would when the price is fixed for each service level. As network congestion builds up, the price will increase due to competition on network resources and the ISP revenues will increase. In addition, a user using fewer resources (e.g., less bandwidth) from the network would pay less than "heavy" users. Nevertheless, it is not realistic to assume that a user would pay any price demanded by a router, especially when congestion raises the price significantly. A common human behavior is to forgo high QoS when it is too expensive, and move to a less expensive service offering degraded but still acceptable quality. The proposed BLAPP scheme enables users to set an upper bound on their total routing costs per service level by assigning a value to the Money Limit field in the packet s header. Each router on the packet's route increments the packet s Cumulated charge field. Whenever the Cumulated field reaches the value of the packet s Money limit field, or whenever there is no room left in the appropriate queue, the packet is degraded to the closest service level the user can afford. If no additional charges can be made, the packet is assigned to the best-effort queue. BLAPP requires a QoS mechanism capable of managing the required service level for each packet. In our design, DiffServ (Differentiated Services) was adopted as the QoS mechanism. DiffServ classifies packet streams into different classes and allocates resources on a per-class basis [27,28]. Each router has several queues (per output port), one for each service level associated with a specific Code Point (CP) value. Whenever a packet arrives, it is entered an appropriate queue according to its CP. The router manages the queues using a Weighted Round Robin (WRR) algorithm. If the target queue is full and cannot receive the incoming packet, the packet is degraded and delivered to a queue associated with a lower service level. The lowest service level possible in BLAPP is "Best-effort" and it is associated with the queue having the smallest weight in the WRR algorithm. In addition, we assume the existence of a predefined Service Level Agreement (SLA) between the user and the service provider. Under the SLA, a user and a provider agree on the service level that will be assigned to each of the user s applications and the price charged for each service level [29]. An IP router operating under the BLAPP scheme modifies the price of serving a packet at each service level based on dynamic congestion conditions. We assume that the price-congestion relationship is described by a non-linear function p i =f(l i ) where p i is the price of serving a packet in queue i, and l i is the instantaneous load (queue length in bytes) at queue i. A router attempts to direct the packet to the proper queue according to its CP (service level). If the queue is full then the packet will be directed to a queue of a lower service level which is available at the moment. The charge is made according to the service level of the queue that actually serves the packet. Performance measures that affect perceived user satisfaction are bandwidth, end-to-end delay, jitter (delay variance) and packet loss. Since degraded packets enter queues with smaller allocated bandwidth, the RTT is expected to increase accordingly. Packets carrying the same CP may be served at different service levels on their route due to congestion changes over time, thus abrupt changes in jitter values may appear. In the following section we exploit network simulations in order to investigate the influence of the money limit on the QoS observed by a user and on the ISP's revenue. 4. Evaluation of BLAPP BLAPP was evaluated using the Network-Simulator 2 (NS-2) simulation tool. The topology simulated represents a single DiffServ domain with 25 users, each connected to an ISP through a 1Mbit/sec duplex link (see Fig. 1). All other links were 5Mbit/sec except the link between router 4 and router 5, which

4 was set to 2Mbit/sec in order to create a bottleneck and congestion near router 4. The following three typical Internet applications generated the network traffic: Multimedia, HTTP (WWW surfing) and FTP. Best-effort traffic was generated as background traffic. When a user s FTP application was set to on, it generated packets endlessly until it was set to off. Each FTP packet size was 1000 bytes and 10 pages were accessed in each user s HTTP session. The idle time between two excessive pages was set according to an Exponential distribution with a mean of 1sec. Each page consisted of eight objects. The size of each object was set according to a Pareto distribution with mean of 10Kbyte, and the idle time between accessing two successive objects by the HTTP server was set according to Exponential distribution with a mean of 0.01sec. The Multimedia application was simulated by a constant bit rate (CBR) generator which generates traffic according to a deterministic 64Kbit/sec rate and a constant 40 bytes packet size. Best-effort traffic was generated according to a Poisson distribution with a mean of 40ms idle time between two successive packets and each packet size was 512 bytes. Each router supported four service levels that differ in bandwidth available for each service level. A Weighted Round Robin (WRR) scheduler was used as the queuing management policy at each router. Careful presetting of the WRR scheduling algorithm was used to divide the total bandwidth between the service levels (high queue 66.66%, medium queue 20%, low queue 10%, best effort queue 3.33%). In addition, we used relatively large drop-tail queues (random early discarding was not implemented in this research). As mentioned before, the mapping between the application and the router s queues is done using the CP value in the IP header. Table 1 summarizes the SLA settings in the simulation. Packet degradation was performed to a lower queue in congruence with the DiffServ settings. For example, according to the SLA, each Multimedia packet was charged 0.02 monetary units. The actual charge might have been less in case the high service level queue was full and the Multimedia packet was degraded to a medium service level queue. Application Service Level Queue Packet handling Charge (monetary units/packet) 1 Multimedia High HTTP Medium FTP Low Other traffic Best-effort 0 Table 1 SLA settings. Fig. 2 Service level price as a function of congestion at each router In the BLAPP scheme, the price of each service level is congestion dependent. The price-congestion relationship used in our simulation is described in Fig. 2. Users are required a limit to the total amount of money they are charged for each packet. This limit is stored at the IP header optional field. In our simulations we set the following limits on the total charge for each type of application: FTP Packet monetary units (sufficient to pay for two highly congested routers on the path). HTTP Packet monetary units (sufficient to pay for four highly congested routers on the path). Multimedia monetary units (sufficient to pay for five highly congested routers on the path). We hypothesized that limiting the payment would lead to lower performance in congested situations. Performance degradation might be observed by users as longer delays and higher packet-loss ratio. Longer delays are caused by moving packets to queues of lower service levels (no sufficient money to pay for higher service levels). Packet loss is increased due to packet discarding (no room for poor packets). The graphs in Figures 3a, 3b, 3c, 4a, 4b, 4c, 5a, 5b, and 5c depict the total cumulated charge, end-to-end delay performance, and packet drop performance, for FTP, HTTP and multimedia applications as a function of the Money Limit in the packets header. The measures were taken after 700 second of simulation running for different limit values (measurements for each application were taken with different limits at each simulation run, while the other applications packets where set to a constant limit).

5 Fig. 3(a) Total cumulated charge, after 700 seconds, for FTP packets as a function of the limit in the packets header Fig. 4(a) Total cumulated charge, after 700 seconds, for HTTP packets as a function of the limit in the packets header Fig. 3(b) Packet drop in equilibrium state (after 700 seconds) for FTP packets as a function of the limit in the packets header Fig. 4(b) Packet drop in equilibrium state (after 700 seconds) for HTTP packets as a function of the limit in the packets header Fig. 3(c) End to end delay in equilibrium state (after 700 seconds) for FTP packets as a function of the limit in the packets header Fig. 4(c) End to end delay in equilibrium state (after 700 seconds) for HTTP packets as a function of the limit in the packets header

6 Fig. 5(a) Total cumulated charge, after 700 seconds, for multi-media packets as a function of the limit in the packets header Fig. 5(b) Packet drop in equilibrium state (after 700 seconds) for multi-media packets as a function of the limit in the packets header Fig. 5(c) End to end delay in equilibrium state (after 700 seconds) for multi-media packets as a function of the limit in the packets header The graphs in Figures 3a, 4a, 5a suggest that the total cumulated charge increases when the money limit in the packet header increases. In addition, one can notice that the marginal increase of the cumulated charge decreases as the money limit increases. This observation can be explained by the fact that as the limit increases, more packets are charged based on the requested payment by the routers and fewer packets are degraded due to the money limit. The graphs in Figures 3b, 4b, 5b suggest that the percentage of packet drop decreases when the money limit increases. This result can be explained by the fact that whenever the money limit increases, fewer packets are degraded and dropped to lower QoS queues. The graphs in Figures 3c, 4c, 5c suggest that the end to end delay decreases when the money limit increases. This result can be explained by the fact that whenever the money limit increases, packets are "richer" and have more money to pay for the requested QoS. As a result, they suffer from shorter delays. 5. Discussion This article presented the BLAPP scheme which enables TCP/IP users to limit their charge on routing packets. Such a limit serves as a load- balancer when congestion builds up in various application queues. Users who choose to limit their total packet charge discern performance degradation in various performance measures such as lower bandwidth, higher delay, and packet loss. Additional research is needed to explore interrelations between various pricing functions and network congestion. Moreover, research should be conducted in order to investigate the willingness of users to pay for network resources under congested traffic conditions. Such research requires modeling user's dynamic behavior under different network circumstances. In order to capture the uncertainty in user behavior, BLAPP should be able to handle user back-offs which result in aborted downloads, or,alternatively, handle long multimedia transfers which are not aborted at any case and severely hamper performance. The complexity and uncertainty mentioned above call for dynamic bandwidth provisioning by way of adaptive user behavior modeling ( s03model.htm). References: [1] Y. Elovici, Y. Ben Shimol, A. Shabtai, Local Adaptive Packet Pricing (LAPP) Scheme for IP-Networks, Working Paper, Department of ISE, Ben Gurion University of the Negev, [2] Y. Elovici, Y. Ben-Shimol, A. Shabtai,

7 Per-Packet Pricing Scheme for IP Networks, 10th International Conference on Telecommunications ICT'2003. [3] K.G. Coffman and A.M. Odlyzko, Growth of the Internet, AT&T Labs - Research, July [4] M. Falkner, M. Devetsikiotis and I. Lambadaris, An Overview of Pricing Concepts for Broadband IP- Networks, IEEE Communications Surveys, vol. 3, No. 2, April [5] O. Vasquez, Billing for IP Services Remains a Challenge, Business Communication Review, pp , December [6] G. Philip, Seven Comments on Charging and Billing, Communication of the ACM, pp , November [7] P.C. Fishburn and A. M. Odlyzko, Dynamic Behavior of Differential Pricing and Quality of Service options for the Internet, Proc. of first International Conference on Information and Computation Economies, ACM Press, [8] R. Edell and P. Variaya, Providing Internet Access: What we Learn from INDEX, IEEE Network, April [9] B. Stiller, T. Braun, M. Gunter and B. Plattner, The CATI Project: Charging and Accounting Technology for the Internet, 5 th European Conference on Multimedia Applications, Services, and Techniques, Vol. 1629, pp , May [10] J.K. Mackie-Mason and H.R. Varian, Pricing Congestible Network Resources, IEEE JSAC, vol. 13, no. 7, pp , September [11] D. McDysan, QoS & Traffic Management in IP & ATM Networks, McGraw-Hill, [12] I.Ch. Paschalidis and Y. Liu, Pricing in Multi-Service Loss Networks: Static Pricing, Asymptotic Optimality and Demand Substitution Effects, IEEE/ACM Transactions on Networking, Vol. 10, No. 3, pp , June [13] T. Basar and R. Srikant, Revenue-Maximizing Pricing and Capacity Expansion in a Many Users Regime, INFOCOM, [14] L. Anania and R.J. Solomon, Flat: The Minimalist Price, Internet Economics, MIT Press, pp , [15] A.M. Odlyzko, A Modest Proposal for Preventing Internet Congestion, AT&T Labs Internal Report, Florham Park, NJ, September [16] A.M. Odlyzko, Paris Metro Pricing for the Internet, Proc. of the ACM Conference on Electronic Commerce, pp , [17] A. Odlyzko, The Economics of the Internet: Utility, utilization, Pricing and Quality of Service, October 1999, [18] J.K. Mackie-Mason and H.R. Varian, Pricing the Internet," International Conference on Telecommunication System Modeling, pp , March [19] S. Shenker, D. Clark, D. Estrin and S. Herzog, Pricing in Computer Networks: Reshaping the Research Agenda, ACM Computer Communications Review, vol. 26, No. 2, April [20] A. Gupta, D. O. Stahl and A.B. Whinston, Pricing of Services on the Internet, University of Texas, Austin, Texas, Tech Rep. pp , [21] A. Gupta, D. O. Stahl and A.B. Whinston, Priority Pricing of Integrated Services Networks, Internet Economics, MIT Press, pp , [22] R. Cocchi, S. Shenker, D. Estrin and L. Zhang, Pricing in Computer Networks: Motivation, Formulation and Example, ACM/IEEE Transactions on Networks, vol. 1, [23] R. Cocchi, S. Shenker, D. Estrin and L. Zhang, A Study of Priority Pricing in Multiple Service Class Networks, Proc. of SIGCOMM, Oxford University Press, September [24] D.D. Clark, Internet Cost Allocation and Pricing, Internet Economics, MIT Press, Cambridge, Massachusetts, pp , [25] J. MacKie-Mason, L. Murphy and J. Murphy, Responsive Pricing in the Internet, Internet Economics, MIT Press, pp , [26] S. Limor, Meeting the IP-Network Billing Challenge, September 1999, net.com/tmcnet/articles/xacct1298.htm. [27] K. Kilkki, Differentiated Services for the Internet, MacMillan Technical Publishing, [28] B. Davie and Y. Rekhter, MPLS Technology and Applications, Morgan Kaufmann, [29] C. Courcoubetis and V.A. Siris, Managing and pricing service level agreements for differentiated services, Proc. of 6 th IEEE/IFIP International Conference of Quality of Service (IWQoS'99), London, UK, May-June 1999.