Distributed-Dynamic Capacity Contracting: A congestion pricing framework for Diff-Serv

1
Distributed-Dynamic Capacity Contracting A
congestion pricing framework for Diff-Serv

• Murat Yuksel and Shivkumar Kalyanaraman
• Rensselaer Polytechnic Institute, Troy, NY.

2
Overview

• Motivation/Context
• Framework Dynamic Capacity Contracting (DCC)
• Scheme Edge-to-Edge Pricing (EEP)
• Distributed-DCC
• Simulation Experiments
• Summary

3
Motivation/Context

• Multimedia (MM) applications introduce extensive
  traffic loads.
• Hence, better ways of managing network resources
  are needed for provision of sufficient QoS for MM
  applications.
• For this purpose, congestion pricing is one of
  the methods among many others.
• Two major implemetation problems
• Timely feedback about price
• Congestion information about the network

4
DCC Framework
5
DCC Framework (contd)

• Solves implementation issues by
• Short-term contracts, i.e. middle-ground between
  Smart Market and Expected Capacity
• Edge-to-edge coordination for price calculation
• Users negotiate with the provider at ingress
  points
• The provider estimates users incentives by
  observing users traffic at different prices
• A simple way of representing users incentive is
  his/her budget
• Budget estimation

6
DCC Framework (contd)

• 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 pricing scheme at the
  ingress, e.g. EEP, Price Discovery
• Vmax is a parameter to be set by soft admission
  control

7
DCC Framework (contd)
8
DCC Framework (contd)

• Key benefits
• Does not require per-packet accounting
• Requires updates to edges only
• enables congestion pricing by edge-to-edge
  congestion detection techniques
• deployable on diff-serv architecture of the
  Internet

9
Edge-to-Edge Pricing (EEP)

• At Ingress i, given and
• Balancing supply (edge-to-edge capacity) and
  demand (budget for route ij)
• If is congestion-based (i.e. decreases when
  congestion, increases when no congestion), then
  becomes a congestion-sensitive price.
• formulation above is optimal for maximization
  of total user utility.

10
Distributed-DCC

• DCC distributed contracting, i.e. flexibility
  of advertising local prices
• Defines ways of maintaining stability and
  fairness of the overall system
• Operates on a per-edge-to-edge flow basis
• Major components
• Ingresses
• Egresses
• Logical Pricing Server (LPS)

11
Distributed-DCC (contd)
12
Distributed-DCC (contd)
13
Distributed-DCC (contd)
14
Distributed-DCC (contd)

• Congestion-Based Capacity Estimator
• Estimates available capacity for each flow
  fij exiting at Egress j
• To calculate it uses
• Congestion indications from Congestion Detector
• Actual output rates of flows
• Increase when fij generates congestion
  indications, decrease when it does not, e.g.

15
Distributed-DCC (contd)

• Fairness Tuner
• Punish the flows causing more cost!
• Punishment function
• A particular version by using from Flow Cost
  Analyzer
• Max-min fairness, when
• Proportional fairness, when

16
Distributed-DCC (contd)
17
Distributed-DCC (contd)

• Capacity Allocator
• Receives congestion indications, and
• Calculates allowed capacities for each flow
• Hard to do w/o knowledge of interior topology
• In general,
• Flows should share capacity of the same
  bottleneck in proportion to their budgets
• Flows traversing multiple bottlenecks should be
  punished accordingly

18
Distributed-DCC (contd)

• An example Capacity Allocator
• Edge-to-edge Topology-Independent Capacity
  Allocation (ETICA).
• Define for flow
• Define as congested, if .

19
Distributed-DCC (contd)

• An example Capacity Allocator (contd)
• Allowed capacity for flow
• Intuition If a group of flows are congested,
  then it is more probable that they are traversing
  the same bottleneck.
• Assumes no knowledge about interior topology.

20
Simulation Experiments

• We want to illustrate
• Steady-state properties of Distributed-DCC
  queues, rate allocation
• Distributed-DCCs fairness properties
• Performance of the capacity allocation in terms
  of adaptiveness.

21
Simulation Experiments (contd)
22
Simulation Experiments (contd)

• Propagation delay is 5ms on each link
• Packet size 1000B
• Users generate UDP traffic
• Interior nodes mark when their local queue
  exceeds 30 packets.
• User with a budget b maximizes its surplus by
  sending at a rate b/p.
• For each contracting period, users budgets are
  randomized with truncated-Normal.
• Contracting 4s, observation 0.8s, LPS 0.16s.
• k is 25, i.e. a flow stays in congested states
  for 25 LPS intervals, or one contract period.

23
Simulation Experiments (contd)

• Single-bottleneck experiment
• 3 user flows
• Flow budgets 30, 20, 10 respectively for flows 0,
  1, 2.
• Simulation time 15,000s.
• Flows get active at every 5,000s.

24
Simulation Experiments (contd)
25
Simulation Experiments (contd)
26
Simulation Experiments (contd)
27
Simulation Experiments (contd)

• Multi-bottleneck experiment 1
• 10 user flows with equal budgets of 10 units.
• Simulation time 10,000s.
• Flows get active at every 1,000s.
• All the other parameters are the same as in the
  PFCC experiment on single-bottleneck topology.
• ? is varied between 0 and 2.5.

28
Simulation Experiments (contd)
29
Simulation Experiments (contd)
30
Simulation Experiments (contd)

• Multi-bottleneck experiment 2
• 4 user flows
• Simulation time 30,000s.
• Increase capacity of node D from 10Mb/s to
  15Mb/s.
• All flows get active at the starts of simulation.
• Initially all flows have equal budget of 10
  units. Flow 1 temporarily increases its to 20
  units between times 10,000 and 20,000.
• ? is 0.

31
Simulation Experiments (contd)
32
Simulation Experiments (contd)
33
Summary

• Deployability of congestion pricing is a problem.
• A new congestion pricing framework,
  Distributed-DCC
• Middle-ground between Smart Market and Expected
  Capacity.
• Deployable on a diff-serv domain.
• A range of fairness capabilities.