Architectures for CongestionSensitive Pricing of Network Services

1
Architectures for Congestion-Sensitive Pricing of
Network Services

• Thesis Defense by
• Murat Yuksel
• CS Department, RPI
• July 3rd, 2002

2
Overview

• Motivation
• Scope
• Studied Items
• Framework Dynamic Capacity Contracting (DCC)
• Scheme Edge-to-Edge Pricing (EEP)
• Distributed-DCC
• Architectures PFCC, POCC
• Simulation Experiments
• Summary

3
Motivation

• Need for new economic models and tools in the
  Internet
• More flexible pricing architectures
• Building blocks with a range of pricing
  capabilities
• Adaptive pricing
• A way of controlling user demand and network
  congestion
• Fairness TCP vs. UDP, cost differences

4
Studied Items

• Smart Market ? Ch. 3
• Dynamic Capacity Contracting (DCC) framework ?
  Ch. 4
• Edge-to-Edge Pricing (EEP) scheme ? Ch. 4
• Pricing intervals vs. congestion control by
  pricing? ? Ch. 5
• Two architectures PFCC, POCC
• Distributed-DCC PFCC ? Ch. 6
• Fairness issues ? Ch. 6
• Distributed-DCC POCC ? Ch. 7
• Optimization analysis of EEP ? Ch. 8
• Optimization analysis of Distributed-DCC ? Ch. 9

• Smart Market ? Ch. 3
• Dynamic Capacity Contracting (DCC) framework ?
  Ch. 4
• Edge-to-Edge Pricing (EEP) scheme ? Ch. 4
• Pricing intervals vs. congestion control by
  pricing? ? Ch. 5
• Two architectures PFCC, POCC
• Distributed-DCC PFCC ? Ch. 6
• Fairness issues ? Ch. 6
• Distributed-DCC POCC ? Ch. 7
• Optimization analysis of EEP ? Ch. 8
• Optimization analysis of Distributed-DCC ? Ch. 9

5
DCC Framework
6
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

7
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

8
DCC Framework (contd)
9
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

10
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.

11
Optimality of EEP

• System problem
• subject to
• Logarithmic utility function
• Single-bottleneck case
• Multi-bottleneck case

12
Optimality of EEP (contd)

• Elasticity
• Demand-price elasticity
• Utility-bandwidth elasticity
• For a surplus-maximizing user

13
Optimality of EEP (contd)

• Non-Logarithmic utility function
• Since , .
• Single-bottleneck case
• Multi-bottleneck case
• Simply estimate and calculate prices
  accordingly..
• Be more conservative in capacity, if more
  elasticity.

14
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)

15
Distributed-DCC (contd)
16
Distributed-DCC (contd)
17
Distributed-DCC (contd)
18
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.

19
Distributed-DCC (contd)

• Flow Cost Analyzer ARBE
• Flows cost of traversed bottlenecks, links,
  or amount of queueing delay
• Algorithm for Routing-sensitive Bottleneck-count
  Estimation (ARBE)
• Assume same severity for bottlenecks
• Assume increment instead of marking

20
Distributed-DCC (contd)

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

21
Distributed-DCC (contd)
22
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

23
Distributed-DCC (contd)

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

24
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.

25
Architectures PFCC, POCC

• Level of congestion control reduces sharply as
  pricing interval increases, i.e. almost no
  contribution to congestion control after 40RTT
• Highly variant Internet traffic makes it more
  difficult
• Two possible tracks to follow
• Pricing for Congestion Control (PFCC) congestion
  pricing behind intermediaries
• Pricing over Congestion Control (POCC) overlay
  pricing over an underlying edge-to-edge
  congestion control mechanism

26
Architectures PFCC, POCC (contd)
27
Distributed-DCC PFCC

• Users need to employ intermediaries.
• LPS must operate at very small time-scale.
• So, scalability becomes an issue for
• LPS
• of flows
• There are n(n-1) flows for a diff-serv domain
  with n edge routers.
• LPS can be scaled in two ways
• Fully distributed LPS LPS on each edge router,
  i.e. n LPSs.
• Partially distributed LPS local LPSs for a group
  of edge routers, i.e. k lt n LPSs.

28
Distributed-DCC POCC

• Problems
• Parameter mapping
• Edge queues
• Solutions for Distributed-DCC over Riviera
  Harrison et al.
• Parameter mapping
• Let be the fraction of
  capacity that must be given to .
• Set Rivieras parameters as

29
Distributed-DCC POCC (contd)

• 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 .

30
Distributed-DCC PFCC vs. POCC
31
Simulation Experiments

• We want to illustrate
• Steady-state properties of PFCC and POCC queues,
  rate allocation
• PFCCs fairness properties
• Performance of PFCCs capacity allocator ETICA in
  terms of adaptiveness.
• For PFCC, Distributed-DCCs PFCC version.
• For POCC, Distributed-DCC over Riviera.

32
Simulation Experiments (contd)
33
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.

34
Simulation Experiments (contd)

• Single-bottleneck experiments
• 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.
• For POCC, edge queues mark when exceeding 200
  packets.

35
Simulation Experiments (contd)

• PFCC

36
Simulation Experiments (contd)

• PFCC

37
Simulation Experiments (contd)

• PFCC

38
Simulation Experiments (contd)

• POCC

39
Simulation Experiments (contd)

• POCC

40
Simulation Experiments (contd)

• POCC

41
Simulation Experiments (contd)

• POCC

42
Simulation Experiments (contd)

• Simulate PFCC only, since Riviera does not
  support weighted allocation for multi-bottleneck
  topologies.
• 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.

43
Simulation Experiments (contd)
44
Simulation Experiments (contd)
45
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.

46
Simulation Experiments (contd)
47
Simulation Experiments (contd)
48
Summary

• Need for new economic models.
• Deployability of adaptive pricing is a problem.
• A new adaptive pricing framework,
  Distributed-DCC
• Middle-ground between Smart Market and Expected
  Capacity.
• Deployable on a diff-serv domain.
• A range of fairness capabilities.
• Two possible architectures to solve time-scale
  issues PFCC, POCC.

49
Candidacy Issues

• Prof. Sikdar commented on simulation settings in
  Ch. 3.
• Re-designed and re-ran the experiments.
• Prof. Szymanski suggested to explore new research
  dimensions on more economics by considering
  different parameters such as users elasticity.
• Available in Ch. 8.
• Prof. Ravichandran suggested to experiment
  Distributed-DCC with more simulations.
• Available in Ch. 9.
• Prof. Szymanski commented on simplistic modeling
  of network behavior used in Ch. 5.
• Relaxed some of the assumptions and developed a
  second model.