architectures for congestion-sensitive pricing of network services

Architectures for Congestion-Sensitive

Pricing of Network Services

Thesis Defense byMurat Yuksel

CS Department, RPIJuly 3rd, 2002

Architectures for Congestion-Sensitive Pricing of Network Services2

Overview Motivation Scope Studied Items Framework: Dynamic Capacity Contracting

(DCC) Scheme: Edge-to-Edge Pricing (EEP) Distributed-DCC Architectures: PFCC, POCC Simulation Experiments Summary


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


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


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) 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 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 “pricing scheme” at the ingress, e.g. EEP, Price Discovery

Vmax is a parameter to be set by soft admission control

),,( max TVpfContract vvp

TmaxV

vp

maxV


DCC Framework (cont’d)

User'straffic

p iji

3

j

User

c ij

kl

12

uv

4 m

DCC

User'straffic

User

kl

uv

4 m

p i

p j

p 3

p 2p 1

i

3

j

12

Low's


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


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.

ijijij cbp /ˆijbijc

ijc

ijb

ijc

ijp

ijp


Optimality of EEP System problem:

subject to

Logarithmic utility function: Single-bottleneck case:

Multi-bottleneck case:

f

ffU )(max

llFff c

)(

)log()( xwxu ii

c

wp Ff f

)( )(

)(

lFf fLk k

lFf f

l c

wp


Optimality of EEP (cont’d) Elasticity

Demand-price elasticity:

Utility-bandwidth elasticity:

For a surplus-maximizing user:

.1 where,1

1

.1,0 where,1

1

})({max xpxux

dp

pdX

pX

p

pdp

pXpdX )(

)(/

)(/)(

dx

xdu

xu

x )(

)(

appX )(

bxxu )(


Optimality of EEP (cont’d) 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.

10 where

,)(

xwxu ii

|/1|||

c

wp Ff f

|/1|

)( )(

)(

||

lFf fLk k

lFf f

l c

wp

10 1


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)


Distributed-DCC (cont’d)Distributed-DCC Framework

.

.

.

.

.

.

Egress1

Ingress1

Egressn

Egress2

Ingressn

Ingress2

LPS

Customers


Distributed-DCC (cont’d)

CurrentRates of

CustomerFlows

measuredhere at

Ingress i

ContractParameters

(price,maximum

volume,length) toCustomers

in

i

i

b

b

b

ˆ

.

.

ˆ

ˆ

2

1

BudgetEstimationsof Flows to

Egresses

TotalEstimatedNetwork

Capacity andAllowed Flow

Capacitiesfrom LPS

Ingress i

T

V

pij

max

in

i

i

c

c

c

C

.

.2

1

PricingScheme

(e.g. EEP)

BudgetEstimator

in

i

i

x

x

x

.

.2

1



CongestionIndications

EstimatedFlow

Capacities to LPS

nj

j

j

b

b

b

ˆ

.

.

ˆ

ˆ

2

1

BudgetEstimations of Flows

fromIngresses

CurrentOutput

Rates ofFlows

measuredhere at

Egress j

Egress j

Congestion-Based

CapacityEstimator

FairnessTuner

nj

j

j

c

c

c

ˆ

ˆ

ˆ

.

.1

1

nj

j

j

b

b

b

.

.

2

1UpdatedBudget

Estimation of

Flows toLPS

CongestionDetector

nj

j

j

.

.

2

1

ArrivingTraffic

atEgress j

Flow CostAnalyzer

(e.g. ARBE)ijr

Congestion

Indicationsabout

flows toLPS


Distributed-DCC (cont’d) 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.:

ijc

ijc

ij

ijc

indication congestion no ,ˆ)1(ˆ

indication congestion ,)(ˆ

ctctc

ij

ij

ij


Distributed-DCC (cont’d) Flow Cost Analyzer: ARBE

Flow’s 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”

otherwise ,ˆ)1(

)(ˆ)1( ),(ˆ)(

rtr

trtrtrtr

ij

ijijij

ij


Distributed-DCC (cont’d) Fairness Tuner:

Punish the flows causing more cost! Punishment function:

A particular version by using from ARBE:

Max-min fairness, when Proportional fairness, when

),,ˆ( parametersbfb ijij ijr

)(

ˆ),,,ˆ(

minminmin rrr

brrbfb

ij

ijijijij

01



+

nnnn

n

n

ccc

ccc

ccc

ˆ..ˆˆ

....

ˆ..ˆˆ

ˆ..ˆˆ

21

22221

11211EstimatedFlow

Capacitiesreceived

fromEgresses

UpdatedBudget

Estimations of Flows

receivedfrom

Egresses

TotalEstimatedNetworkCapacity

andAllowed

FlowCapacitiesbeing sent to

Ingresses

CongestionIndications

about flowsreceived from

Egresses

Logical Pricing Server (LPS)

nnnn

n

n

bbb

bbb

bbb

..

....

..

..

21

22221

11211

nnnn

n

n

ccc

ccc

ccc

C

..

....

..

..

21

22221

11211

CapacityAllocator

(e.g. ETICA)


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

ijc ijb

ijc


Distributed-DCC (cont’d) An example Capacity Allocator:

Edge-to-edge Topology-Independent Capacity Allocation (ETICA).

Define for flow :

Define as congested, if .

ijK ijf

)1(in congestion no ,1)1(

)1(in congestion ,)(

ttK

tktK

ijij

ijf 0ijK

. . .1-p

p

p

p

p

1-p p1-p1-p1-p

kk-120 1


Distributed-DCC (cont’d) An example Capacity Allocator: (cont’d)

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.

ijf

otherwise ),(ˆ

0)( ,)(

tc

tKB

Cb

tc

ij

ijc

cij

ij


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


Architectures: PFCC, POCC (cont’d)

diff-serv boundary Bottleneck

ProviderStation 0

ProviderStation 1

Customers

Customers

Smaller queuebuilds at interiorbottleneck0

1

Large queuesbuild at edges

POCCSmooth prices

diff-serv boundary Bottleneck

ProviderStation 0

ProviderStation 1

Customers

Customers 1

0

Large queue buildsat interior bottleneck

Inte

rmed

iary

Inte

rmed

iary

PFCCFluctuatingprices

Smoothprices


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 < n LPSs.


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 Riviera’s parameters as:

Ccijij /ijf

ijijij

ijijij

ijijij

threshthresh

threshthresh

min_min_

max_max_


Distributed-DCC: 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 /


Distributed-DCC: PFCC vs. POCC

Distributed-DCC: PFCC Distributed-DCC: POCC

LPS must operate at small time-scales.

LPS may operate at large time-scales.

LPS must be scaled because of its operational time-scale.

It is not necessary to scale LPS.

Framework can achieve a range of fairness in rate allocation.

Fairness is limited and depends on the underlying congestion control mechanism.

Bottleneck queues at network core are large.

Bottleneck queues at network core are small.

Does not need to manage edge queues.

Need to manage edge queues.


Simulation Experiments We want to illustrate:

Steady-state properties of PFCC and POCC: queues, rate allocation

PFCC’s fairness properties Performance of PFCC’s capacity allocator

ETICA in terms of adaptiveness. For PFCC, Distributed-DCC’s PFCC

version. For POCC, Distributed-DCC over

Riviera.


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

15Mb

15Mb 10Mb

15Mb

A

3

0

1

15Mb 010Mb D10Mb

15Mb

15Mb

15Mb

15Mb

1 2

CB

32

flow 3

flow 0

flow 1 flow 2

Multi-Bottleneck


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


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



PFCC



POCC


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


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


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.

architectures for congestion-sensitive pricing of network services

Documents

onlyenables congestion

pricing scheme

pricing intervals

edge congestion

congestion control

edge pricing eep scheme

network congestionfairness

dcc frameworkarchitectures