1 / 33

Distributed-Dynamic Capacity Contracting: A congestion pricing framework for Diff-Serv

Distributed-Dynamic Capacity Contracting: A congestion pricing framework for Diff-Serv. Murat Yuksel and Shivkumar Kalyanaraman Rensselaer Polytechnic Institute, Troy, NY. Overview. Motivation/Context Framework: Dynamic Capacity Contracting (DCC) Scheme: Edge-to-Edge Pricing (EEP)

maisie-nicholson
Download Presentation

Distributed-Dynamic Capacity Contracting: A congestion pricing framework for Diff-Serv

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. Distributed-Dynamic Capacity Contracting: A congestion pricing framework for Diff-Serv Murat Yuksel and Shivkumar Kalyanaraman Rensselaer Polytechnic Institute, Troy, NY.

  2. Overview • Motivation/Context • Framework: Dynamic Capacity Contracting (DCC) • Scheme: Edge-to-Edge Pricing (EEP) • Distributed-DCC • Simulation Experiments • Summary IEEE MMNS 2002

  3. Motivation/Context • Multimedia (MM) applications introduce extensive traffic loads. • Hence, better ways of managing network resources are needed for provision of sufficient QoS for MM applications. • For this purpose, congestion pricing is one of the methods among many others. • Two major implemetation problems: • Timely feedback about price • Congestion information about the network IEEE MMNS 2002

  4. DCC Framework IEEE MMNS 2002

  5. 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: IEEE MMNS 2002

  6. 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 IEEE MMNS 2002

  7. DCC Framework (cont’d) IEEE MMNS 2002

  8. 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 IEEE MMNS 2002

  9. 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. IEEE MMNS 2002

  10. 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) IEEE MMNS 2002

  11. Distributed-DCC (cont’d) IEEE MMNS 2002

  12. Distributed-DCC (cont’d) IEEE MMNS 2002

  13. Distributed-DCC (cont’d) IEEE MMNS 2002

  14. 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.: IEEE MMNS 2002

  15. Distributed-DCC (cont’d) • Fairness Tuner: • Punish the flows causing more cost! • Punishment function: • A particular version by using from Flow Cost Analyzer: • Max-min fairness, when • Proportional fairness, when IEEE MMNS 2002

  16. Distributed-DCC (cont’d) IEEE MMNS 2002

  17. 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 IEEE MMNS 2002

  18. Distributed-DCC (cont’d) • An example Capacity Allocator: • Edge-to-edge Topology-Independent Capacity Allocation (ETICA). • Define for flow : • Define as congested, if . IEEE MMNS 2002

  19. 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. IEEE MMNS 2002

  20. Simulation Experiments • We want to illustrate: • Steady-state properties of Distributed-DCC: queues, rate allocation • Distributed-DCC’s fairness properties • Performance of the capacity allocation in terms of adaptiveness. IEEE MMNS 2002

  21. Simulation Experiments (cont’d) IEEE MMNS 2002

  22. 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. IEEE MMNS 2002

  23. Simulation Experiments (cont’d) • Single-bottleneck experiment: • 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. IEEE MMNS 2002

  24. Simulation Experiments (cont’d) IEEE MMNS 2002

  25. Simulation Experiments (cont’d) IEEE MMNS 2002

  26. Simulation Experiments (cont’d) IEEE MMNS 2002

  27. Simulation Experiments (cont’d) • 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. IEEE MMNS 2002

  28. Simulation Experiments (cont’d) IEEE MMNS 2002

  29. Simulation Experiments (cont’d) IEEE MMNS 2002

  30. 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. IEEE MMNS 2002

  31. Simulation Experiments (cont’d) IEEE MMNS 2002

  32. Simulation Experiments (cont’d) IEEE MMNS 2002

  33. Summary • Deployability of congestion pricing is a problem. • A new congestion pricing framework, Distributed-DCC: • Middle-ground between Smart Market and Expected Capacity. • Deployable on a diff-serv domain. • A range of fairness capabilities. IEEE MMNS 2002

More Related