Congestion Pricing Overlaid on Edge-to-Edge Congestion Control

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!