1 / 49

Architectures for Congestion-Sensitive Pricing of Network Services

Architectures for Congestion-Sensitive Pricing of Network Services. Thesis Defense by Murat Yuksel CS Department, RPI July 3 rd , 2002. Overview. Motivation Scope Studied Items Framework: Dynamic Capacity Contracting (DCC) Scheme: Edge-to-Edge Pricing (EEP) Distributed-DCC

zena
Download Presentation

Architectures for Congestion-Sensitive Pricing of Network Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related