Architectures for Congestion-Sensitive Pricing of Network Services Thesis Defense by Murat Yuksel CS Department, RPI July 3 rd, 2002

Architectures for Congestion-Sensitive Pricing of Network Services 2 Overview Motivation Scope Studied Items Framework: Dynamic Capacity Contracting (DCC) Scheme: Edge-to-Edge Pricing (EEP) Distributed-DCC Architectures: PFCC, POCC Simulation Experiments Summary

Architectures for Congestion-Sensitive Pricing of Network Services 3 Motivation Need for new economic models and tools in the Internet: More flexible pricing architectures Building blocks with a range of pricing capabilities Adaptive pricing: A way of controlling user demand and network congestion Fairness: TCP vs. UDP, cost differences

Architectures for Congestion-Sensitive Pricing of Network Services 4 Studied Items Smart Market  Ch. 3 Dynamic Capacity Contracting (DCC) framework  Ch. 4 Edge-to-Edge Pricing (EEP) scheme  Ch. 4 Pricing intervals vs. congestion control by pricing?  Ch. 5 Two architectures: PFCC, POCC Distributed-DCC: PFCC  Ch. 6 Fairness issues  Ch. 6 Distributed-DCC: POCC  Ch. 7 Optimization analysis of EEP  Ch. 8 Optimization analysis of Distributed-DCC  Ch. 9 Smart Market  Ch. 3 Dynamic Capacity Contracting (DCC) framework  Ch. 4 Edge-to-Edge Pricing (EEP) scheme  Ch. 4 Pricing intervals vs. congestion control by pricing?  Ch. 5 Two architectures: PFCC, POCC Distributed-DCC: PFCC  Ch. 6 Fairness issues  Ch. 6 Distributed-DCC: POCC  Ch. 7 Optimization analysis of EEP  Ch. 8 Optimization analysis of Distributed-DCC  Ch. 9

Architectures for Congestion-Sensitive Pricing of Network Services 5 DCC Framework

Architectures for Congestion-Sensitive Pricing of Network Services 6 DCC Framework (cont ’ d) Solves implementation issues by: Short-term contracts, i.e. middle-ground between Smart Market and Expected Capacity Edge-to-edge coordination for price calculation Users negotiate with the provider at ingress points The provider estimates user ’ s incentives by observing user ’ s traffic at different prices A simple way of representing user ’ s incentive is his/her budget Budget estimation:

Architectures for Congestion-Sensitive Pricing of Network Services 7 DCC Framework (cont ’ d) The provider offers short-term contracts: is price per unit volume V max is maximum volume user can contract for T is contract length P v is formulated by “ pricing scheme ” at the ingress, e.g. EEP, Price Discovery V max is a parameter to be set by soft admission control

Architectures for Congestion-Sensitive Pricing of Network Services 8 DCC Framework (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 9 DCC Framework (cont ’ d) Key benefits: Does not require per-packet accounting Requires updates to edges only enables congestion pricing by edge-to-edge congestion detection techniques deployable on diff-serv architecture of the Internet

Architectures for Congestion-Sensitive Pricing of Network Services 10 Edge-to-Edge Pricing (EEP) At Ingress i, given and : Balancing supply (edge-to-edge capacity) and demand (budget for route ij) If is congestion-based (i.e. decreases when congestion, increases when no congestion), then becomes a congestion-sensitive price. formulation above is optimal for maximization of total user utility.

Architectures for Congestion-Sensitive Pricing of Network Services 11 Optimality of EEP System problem: subject to Logarithmic utility function: Single-bottleneck case: Multi-bottleneck case:

Architectures for Congestion-Sensitive Pricing of Network Services 12 Optimality of EEP (cont ’ d) Elasticity Demand-price elasticity: Utility-bandwidth elasticity: For a surplus-maximizing user:

Architectures for Congestion-Sensitive Pricing of Network Services 13 Optimality of EEP (cont ’ d) Non-Logarithmic utility function: Since,. Single-bottleneck case: Multi-bottleneck case: Simply estimate and calculate prices accordingly.. Be more conservative in capacity, if more elasticity.

Architectures for Congestion-Sensitive Pricing of Network Services 14 Distributed-DCC DCC + distributed contracting, i.e. flexibility of advertising local prices Defines: ways of maintaining stability and fairness of the overall system Operates on a per-edge-to-edge flow basis Major components: Ingresses Egresses Logical Pricing Server (LPS)

Architectures for Congestion-Sensitive Pricing of Network Services 15 Distributed-DCC (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 16 Distributed-DCC (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 17 Distributed-DCC (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 18 Distributed-DCC (cont ’ d) Congestion-Based Capacity Estimator: Estimates available capacity for each flow f ij exiting at Egress j To calculate it uses: Congestion indications from Congestion Detector Actual output rates of flows Increase when f ij generates congestion indications, decrease when it does not, e.g.:

Architectures for Congestion-Sensitive Pricing of Network Services 19 Distributed-DCC (cont ’ d) Flow Cost Analyzer: ARBE Flow ’ s cost: # of traversed bottlenecks, links, or amount of queueing delay Algorithm for Routing-sensitive Bottleneck-count Estimation (ARBE): Assume same severity for bottlenecks Assume “ increment ” instead of “ marking ”

Architectures for Congestion-Sensitive Pricing of Network Services 20 Distributed-DCC (cont ’ d) Fairness Tuner: Punish the flows causing more cost! Punishment function: A particular version by using from ARBE: Max-min fairness, when Proportional fairness, when

Architectures for Congestion-Sensitive Pricing of Network Services 21 Distributed-DCC (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 22 Distributed-DCC (cont ’ d) Capacity Allocator Receives congestion indications, and Calculates allowed capacities for each flow Hard to do w/o knowledge of interior topology In general, Flows should share capacity of the same bottleneck in proportion to their budgets Flows traversing multiple bottlenecks should be punished accordingly

Architectures for Congestion-Sensitive Pricing of Network Services 23 Distributed-DCC (cont ’ d) An example Capacity Allocator: Edge-to-edge Topology-Independent Capacity Allocation (ETICA). Define for flow : Define as congested, if.

Architectures for Congestion-Sensitive Pricing of Network Services 24 Distributed-DCC (cont ’ d) An example Capacity Allocator: (cont ’ d) Allowed capacity for flow : Intuition: If a group of flows are congested, then it is more probable that they are traversing the same bottleneck. Assumes no knowledge about interior topology.

Architectures for Congestion-Sensitive Pricing of Network Services 25 Architectures: PFCC, POCC Level of congestion control reduces sharply as pricing interval increases, i.e. almost no contribution to congestion control after 40RTT Highly variant Internet traffic makes it more difficult Two possible tracks to follow: Pricing for Congestion Control (PFCC): congestion pricing behind intermediaries Pricing over Congestion Control (POCC): overlay pricing over an underlying edge-to-edge congestion control mechanism

Architectures for Congestion-Sensitive Pricing of Network Services 26 Architectures: PFCC, POCC (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 27 Distributed-DCC: PFCC Users need to employ intermediaries. LPS must operate at very small time-scale. So, scalability becomes an issue for: LPS # of flows There are n(n-1) flows for a diff-serv domain with n edge routers. LPS can be scaled in two ways: Fully distributed LPS: LPS on each edge router, i.e. n LPSs. Partially distributed LPS: local LPSs for a group of edge routers, i.e. k < n LPSs.

Architectures for Congestion-Sensitive Pricing of Network Services 28 Distributed-DCC: POCC Problems: Parameter mapping Edge queues Solutions for Distributed-DCC over Riviera [Harrison et al.]: Parameter mapping: Let be the fraction of capacity that must be given to. Set Riviera ’ s parameters as:

Architectures for Congestion-Sensitive Pricing of Network Services 29 Distributed-DCC: POCC (cont ’ d) Edge queues: Subtract necessary capacity from in order to drain the edge queue headed on. Alternatively (or simultaneously), mark packets at the edge when the edge queue exceeds a threshold. This will indirectly reduce the estimated capacity.

Architectures for Congestion-Sensitive Pricing of Network Services 30 Distributed-DCC: PFCC vs. POCC Distributed-DCC: PFCCDistributed-DCC: POCC LPS must operate at small time- scales. LPS may operate at large time- scales. LPS must be scaled because of its operational time-scale. It is not necessary to scale LPS. Framework can achieve a range of fairness in rate allocation. Fairness is limited and depends on the underlying congestion control mechanism. Bottleneck queues at network core are large. Bottleneck queues at network core are small. Does not need to manage edge queues. Need to manage edge queues.

Architectures for Congestion-Sensitive Pricing of Network Services 31 Simulation Experiments We want to illustrate: Steady-state properties of PFCC and POCC: queues, rate allocation PFCC ’ s fairness properties Performance of PFCC ’ s capacity allocator ETICA in terms of adaptiveness. For PFCC, Distributed-DCC ’ s PFCC version. For POCC, Distributed-DCC over Riviera.

Architectures for Congestion-Sensitive Pricing of Network Services 32 Simulation Experiments (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 33 Simulation Experiments (cont ’ d) Propagation delay is 5ms on each link Packet size 1000B Users generate UDP traffic Interior nodes mark when their local queue exceeds 30 packets. User with a budget b maximizes its surplus by sending at a rate b/p. For each contracting period, users ’ budgets are randomized with truncated-Normal. Contracting 4s, observation 0.8s, LPS 0.16s. k is 25, i.e. a flow stays in congested states for 25 LPS intervals, or one contract period.

Architectures for Congestion-Sensitive Pricing of Network Services 34 Simulation Experiments (cont ’ d) Single-bottleneck experiments: 3 user flows Flow budgets 30, 20, 10 respectively for flows 0, 1, 2. Simulation time 15,000s. Flows get active at every 5,000s. For POCC, edge queues mark when exceeding 200 packets.

Architectures for Congestion-Sensitive Pricing of Network Services 35 Simulation Experiments (cont ’ d) PFCC

Architectures for Congestion-Sensitive Pricing of Network Services 36 Simulation Experiments (cont ’ d) PFCC

Architectures for Congestion-Sensitive Pricing of Network Services 37 Simulation Experiments (cont ’ d) PFCC

Architectures for Congestion-Sensitive Pricing of Network Services 38 Simulation Experiments (cont ’ d) POCC

Architectures for Congestion-Sensitive Pricing of Network Services 39 Simulation Experiments (cont ’ d) POCC

Architectures for Congestion-Sensitive Pricing of Network Services 40 Simulation Experiments (cont ’ d) POCC

Architectures for Congestion-Sensitive Pricing of Network Services 41 Simulation Experiments (cont ’ d) POCC

Architectures for Congestion-Sensitive Pricing of Network Services 42 Simulation Experiments (cont ’ d) Simulate PFCC only, since Riviera does not support weighted allocation for multi- bottleneck topologies. Multi-bottleneck experiment 1: 10 user flows with equal budgets of 10 units. Simulation time 10,000s. Flows get active at every 1,000s. All the other parameters are the same as in the PFCC experiment on single-bottleneck topology.  is varied between 0 and 2.5.

Architectures for Congestion-Sensitive Pricing of Network Services 43 Simulation Experiments (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 44 Simulation Experiments (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 45 Simulation Experiments (cont ’ d) Multi-bottleneck experiment 2: 4 user flows Simulation time 30,000s. Increase capacity of node D from 10Mb/s to 15Mb/s. All flows get active at the starts of simulation. Initially all flows have equal budget of 10 units. Flow 1 temporarily increases its to 20 units between times 10,000 and 20,000.  is 0.

Architectures for Congestion-Sensitive Pricing of Network Services 46 Simulation Experiments (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 47 Simulation Experiments (cont ’ d)

Architectures for Congestion-Sensitive Pricing of Network Services 48 Summary Need for new economic models. Deployability of adaptive pricing is a problem. A new adaptive pricing framework, Distributed-DCC: Middle-ground between Smart Market and Expected Capacity. Deployable on a diff-serv domain. A range of fairness capabilities. Two possible architectures to solve time- scale issues: PFCC, POCC.