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
 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
Edge
Router Edge
Router

Edge
Router
Network Core
Customer Edge
(Accessed only by contracts)
s Strategy

Edge
Router
Edge
Router

Edge
Router

Stations of the provider

implement pricing strategies
for the short-term contracts
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: ˆ
bij  xij pij
DCC Framework (cont’d)
 The provider offers short-term contracts:
Contract  f ( pv , Vmax , T )
 pv is price per unit volume
V Vmax
max is maximum volume user can contract for

T T is contract length
 Ppvv is formulated by a “pricing scheme” at the
ingress, e.g. Price Discovery [Arora’02]
 Vmax
V max is a parameter to be set by soft

admission control
 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
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  ij  cij / C be the fraction of capacity that
must be given to f ij .
 Set Riviera’s parameters as:

 ij   ij ij
max_ threshij  max_ threshij ij
min_ threshij  min_ threshij ij
POCC (cont’d)
 Edge queues:
 Subtract necessary capacity from cij in order
to drain the edge queue headed on f ij .

cij  cij  Qij / T

 Alternatively (or simultaneously), mark packets
at the edge when the edge queue exceeds a
threshold. This will indirectly reduce the
estimated capacity cij .
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)
0 Single-Bottleneck 0
flow 0
15Mb flow 1 15Mb

1 15Mb A 10Mb B 15Mb 1

flow 2
15Mb 15Mb

2 2

 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.
Simulation Experiments (cont’d)

Pricing w/o edge-to-edge

congestion control POCC
Simulation Experiments (cont’d)

Pricing w/o edge-to-edge

congestion control POCC
Simulation Experiments (cont’d)

POCC
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
Questions, Ideas?

 THANK YOU!