1 / 20

Congestion Pricing Overlaid on Edge-to-Edge Congestion Control

Congestion Pricing Overlaid on Edge-to-Edge Congestion Control. Murat Yuksel, Shivkumar Kalyanaraman and Anuj Goel Rensselaer Polytechnic Institute, Troy, NY {yuksem, shivkuma} @ecse.rpi.edu, goela@rpi.edu. Outline. Literature development : congestion-sensitive pricing

rhoda
Download Presentation

Congestion Pricing Overlaid on Edge-to-Edge Congestion Control

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. Congestion Pricing Overlaid on Edge-to-Edge Congestion Control Murat Yuksel, Shivkumar Kalyanaraman and Anuj Goel Rensselaer Polytechnic Institute, Troy, NY {yuksem, shivkuma} @ecse.rpi.edu, goela@rpi.edu

  2. Outline • Literature development : • congestion-sensitive pricing • DCC -- an edge-to-edge pricing framework • Pricing Over Congestion Control (POCC) • Edge-to-edge congestion control • Simulation experiments • Summary

  3. Congestion-Sensitive Pricing • Increase the price when congestion, decrease when no congestion. • A way of controlling user’s traffic demand and hence, a way of controlling network congestion • Better resource (bandwidth) allocation • Fairness • Problems: • Users don’t like price fluctuations! • Each price change must be fed back to the user before it could be applied, i.e. hard to implement in a wide area network.

  4. Traditional Pricing Schemes • Proposed congestion pricing schemes have used network interior, which is hard to implement • Kelly’s, Low’s, Varian’s, etc.

  5. DCC Framework

  6. DCC Framework (cont’d) • 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:

  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 a “pricing scheme” at the ingress, e.g. Price Discovery [Arora’02] • Vmax is a parameter to be set by soft admission control

  8. DCC Framework (cont’d) • No per-packet accounting • Updates to edges only • Enables congestion pricing by edge-to-edge congestion detection techniques • Deployable on diff-serv architecture of the Internet

  9. POCC

  10. POCC (cont’d) • Problems: • Parameter mapping – need to map parameters of the overlay pricing protocol with the parameters of the underlying edge-to-edge congestion control scheme • Edge queues – need to manage the edge queues so that they are bounded

  11. An Example Edge-to-Edge Congestion Control Scheme: Riviera • Accumulation-based congestion control mechanism • At the egress nodes, estimates edge-to-edge flow’s accumulation a by monitoring packet delay • If a < min_thresh, the edge-to-edge flow is not congested. • If a > max_thresh, the edge-to-edge flow is congested. • Egress informs ingress about the congestion state, along with an average output rate of the flow. • Ingress applies an AIMD-like algorithm with increase parameter  and decrease parameter to set sending rate. • More is available at: • D. Harrison, S. Kalyanaraman and S. Ramakrishnan, “Overlay bandwidth services: Basic framework and edge-to-edge closed-loop building block”, Poster in SIGCOMM 2001. • Y. Xia, D. Harrison, S. Kalyanaraman, “An Accumulation-based Congestion Control Model”, ICC 2003, NGI 8, Tuesday 15:30.

  12. POCC (cont’d) • Solutions when Riviera is the underlying edge-to-edge congestion control scheme: • Parameter mapping: • Let be the fraction of capacity that must be given to . • Set Riviera’s parameters as:

  13. 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 .

  14. Simulation Experiments • Average packet size is 1000bytes. • Propagation delay is 5ms an all links. • The buffer sizes are assumed to be infinite, no drops are allowed. • User utility is concave: u(x) = b log(x) • Users have a budget b and maximize their surplus by sending at a rate b/p.

  15. Simulation Experiments (cont’d) • 3 user flows with budgets 30, 20 and 10 $/Mb respectively for flows 0, 1, 2. • Total simulation time is 15,000s. • At every 5,000s, one of the user flows gets active, starting from flow 0 up to 2.

  16. Simulation Experiments (cont’d) Pricing w/o edge-to-edge congestion control POCC

  17. Simulation Experiments (cont’d) Pricing w/o edge-to-edge congestion control POCC

  18. Simulation Experiments (cont’d) POCC

  19. Summary • Control of congestion requires small time-scale price updates • Users want less frequent price updates • POCC overlays large time-scale pricing on top of small time-scale congestion control • Problems: • Parameter mapping • Edge queues • Solutions are proposed

  20. Questions, Ideas? • THANK YOU!

More Related