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, [email protected]
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
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.
Traditional Pricing Schemes Proposed
congestion pricing schemes have used network interior, which is hard to implement
Kelly’s, Low’s, Varian’s, etc.
DCC Framework
Stations of the providerimplement pricing strategiesfor the short-term contracts
Customers
Network Core(Accessed only by contracts)
EdgeRouter
EdgeRouter
EdgeRouter
EdgeRouter
EdgeRouter
EdgeRouter
EdgeStrategy
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:ijijij pxb ˆ
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
),,( max TVpfContract vvp
TmaxV
vp
maxV
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
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
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.
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:
Ccijij /ijf
ijijij
ijijij
ijijij
threshthresh
threshthresh
min_min_
max_max_
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 .
ijc
ijfijc
TQcc ijijij /
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.
Simulation Experiments (cont’d)
15Mb
15Mb
10Mb
0
1
15Mb
15Mb 1
2
flow 2
15Mb
0
15Mb
2
A B
flow 1flow 0
Single-Bottleneck
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.
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
Top Related