Upload
zena
View
36
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Architectures for Congestion-Sensitive Pricing of Network Services. Thesis Defense by Murat Yuksel CS Department, RPI July 3 rd , 2002. Overview. Motivation Scope Studied Items Framework: Dynamic Capacity Contracting (DCC) Scheme: Edge-to-Edge Pricing (EEP) Distributed-DCC - PowerPoint PPT Presentation
Citation preview
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
Architectures for Congestion-Sensitive Pricing of Network Services3
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
Architectures for Congestion-Sensitive Pricing of Network Services4
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
Architectures for Congestion-Sensitive Pricing of Network Services5
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
Architectures for Congestion-Sensitive Pricing of Network Services6
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 ˆ
Architectures for Congestion-Sensitive Pricing of Network Services7
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
Architectures for Congestion-Sensitive Pricing of Network Services8
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
Architectures for Congestion-Sensitive Pricing of Network Services9
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
Architectures for Congestion-Sensitive Pricing of Network Services10
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
Architectures for Congestion-Sensitive Pricing of Network Services11
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
Architectures for Congestion-Sensitive Pricing of Network Services12
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 )(
Architectures for Congestion-Sensitive Pricing of Network Services13
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
Architectures for Congestion-Sensitive Pricing of Network Services14
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)
Architectures for Congestion-Sensitive Pricing of Network Services15
Distributed-DCC (cont’d)Distributed-DCC Framework
.
.
.
.
.
.
Egress1
Ingress1
Egressn
Egress2
Ingressn
Ingress2
LPS
Customers
Architectures for Congestion-Sensitive Pricing of Network Services16
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
Architectures for Congestion-Sensitive Pricing of Network Services17
Distributed-DCC (cont’d)
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
Architectures for Congestion-Sensitive Pricing of Network Services18
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
Architectures for Congestion-Sensitive Pricing of Network Services19
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
Architectures for Congestion-Sensitive Pricing of Network Services20
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
Architectures for Congestion-Sensitive Pricing of Network Services21
Distributed-DCC (cont’d)
+
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)
Architectures for Congestion-Sensitive Pricing of Network Services22
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
Architectures for Congestion-Sensitive Pricing of Network Services23
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
Architectures for Congestion-Sensitive Pricing of Network Services24
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 for Congestion-Sensitive Pricing of Network Services25
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 for Congestion-Sensitive Pricing of Network Services26
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
Architectures for Congestion-Sensitive Pricing of Network Services27
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.
Architectures for Congestion-Sensitive Pricing of Network Services28
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_
Architectures for Congestion-Sensitive Pricing of Network Services29
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 /
Architectures for Congestion-Sensitive Pricing of Network Services30
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.
Architectures for Congestion-Sensitive Pricing of Network Services31
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.
Architectures for Congestion-Sensitive Pricing of Network Services32
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
Architectures for Congestion-Sensitive Pricing of Network Services33
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.
Architectures for Congestion-Sensitive Pricing of Network Services34
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.
Architectures for Congestion-Sensitive Pricing of Network Services35
Simulation Experiments (cont’d)
PFCC
Architectures for Congestion-Sensitive Pricing of Network Services36
Simulation Experiments (cont’d)
PFCC
Architectures for Congestion-Sensitive Pricing of Network Services37
Simulation Experiments (cont’d)
PFCC
Architectures for Congestion-Sensitive Pricing of Network Services38
Simulation Experiments (cont’d)
POCC
Architectures for Congestion-Sensitive Pricing of Network Services39
Simulation Experiments (cont’d)
POCC
Architectures for Congestion-Sensitive Pricing of Network Services40
Simulation Experiments (cont’d)
POCC
Architectures for Congestion-Sensitive Pricing of Network Services41
Simulation Experiments (cont’d)
POCC
Architectures for Congestion-Sensitive Pricing of Network Services42
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.
Architectures for Congestion-Sensitive Pricing of Network Services43
Simulation Experiments (cont’d)
Architectures for Congestion-Sensitive Pricing of Network Services44
Simulation Experiments (cont’d)
Architectures for Congestion-Sensitive Pricing of Network Services45
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.
Architectures for Congestion-Sensitive Pricing of Network Services46
Simulation Experiments (cont’d)
Architectures for Congestion-Sensitive Pricing of Network Services47
Simulation Experiments (cont’d)
Architectures for Congestion-Sensitive Pricing of Network Services48
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 Services49
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 user’s 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.