Architectures for Congestion-Sensitive Pricing of Network Services

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

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 • Vmax is maximum volume user can contract for • T is contract length • Pv is formulated by “pricing scheme” at the ingress, e.g. EEP, Price Discovery • Vmax 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 fij exiting at Egress j • To calculate it uses: • Congestion indications from Congestion Detector • Actual output rates of flows • Increase when fij 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 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. Architectures for Congestion-Sensitive Pricing of Network Services

49. Candidacy Issues • Prof. Sikdar commented on simulation settings in Ch. 3. • Re-designed and re-ran the experiments. • Prof. Szymanski suggested to explore new research dimensions on more economics by considering different parameters such as user’s elasticity. • Available in Ch. 8. • Prof. Ravichandran suggested to experiment Distributed-DCC with more simulations. • Available in Ch. 9. • Prof. Szymanski commented on simplistic modeling of network behavior used in Ch. 5. • Relaxed some of the assumptions and developed a second model. Architectures for Congestion-Sensitive Pricing of Network Services