Congestion Pricing Overlaid on EdgetoEdge Congestion Control Murat

Outline n Literature development : n n n congestion-sensitive pricing DCC -- an edge-to-edge

Congestion-Sensitive Pricing n n n Increase the price when congestion, decrease when no congestion.

Traditional Pricing Schemes n n Proposed congestion pricing schemes have used network interior, which

DCC Framework (cont’d) n n Users negotiate with the provider at ingress points The

DCC Framework (cont’d) n The provider offers short-term contracts: n n n is price

DCC Framework (cont’d) n n No per-packet accounting Updates to edges only Enables congestion

POCC (cont’d) n Problems: n n Parameter mapping – need to map parameters of

An Example Edge-to-Edge Congestion Control Scheme: Riviera n n n n Accumulation-based congestion control

POCC (cont’d) n Solutions when Riviera is the underlying edge-to-edge congestion control scheme: n

POCC (cont’d) n Edge queues: n n Subtract necessary capacity from to drain the

Simulation Experiments n n n Average packet size is 1000 bytes. Propagation delay is

Simulation Experiments (cont’d) n n n 3 user flows with budgets 30, 20 and

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

Summary n n Control of congestion requires small timescale price updates Users want less

Slides: 20

Download presentation

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 n Literature development : n n n congestion-sensitive pricing DCC -- an edge-to-edge pricing framework Pricing Over Congestion Control (POCC) Edge-to-edge congestion control Simulation experiments Summary

Congestion-Sensitive Pricing n n n Increase the price when congestion, decrease when no congestion. A way of controlling user’s traffic demand hence, a way of controlling network congestion Better resource (bandwidth) allocation Fairness Problems: n n 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.

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

DCC Framework

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

DCC Framework (cont’d) n The provider offers short-term contracts: n n n 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

DCC Framework (cont’d) n n 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

POCC

POCC (cont’d) n Problems: n n 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

An Example Edge-to-Edge Congestion Control Scheme: Riviera n n n n 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: n n 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.

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

POCC (cont’d) n Edge queues: n n Subtract necessary capacity from to drain the edge queue headed on . in order Alternatively (or simultaneously), mark packets at the edge when the edge queue exceeds a threshold. This will indirectly reduce the estimated capacity.

Simulation Experiments n n n Average packet size is 1000 bytes. Propagation delay is 5 ms 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.

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

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

Simulation Experiments (cont’d) POCC

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

Questions, Ideas? n THANK YOU!