Transcript M3I charge reaction

M3I price reaction
Bob Briscoe
31 May 2000
motivation
• current QoS solutions favour apps that can:
– predict where & what traffic they will send/rcv
• unpredictable apps need
– either over-capacity (without overbooking)
– or tighter app control (closer to app), leading to:
• less overhead to adapt policy
• less coupled to routing
• more open to commercial innovation
• BUT... feedback delay
control granularity
•
•
•
•
fixed pipe per customer (diffserv)
fixed pipe per flow, but can adapt (intserv)
congestion charge reaction middleware
congestion charge reaction by app
decreasing prediction requirement
• what is the Internet denying by only
supports predictable apps?
approach
• project (top down)
•
•
•
•
general solution must have extreme flexibility
consider form of general solution (architecture)
consider appropriate approximations
prototype specific solution(s) within that framework
• presentation (bottom up)
• start with core function: price reaction
• then put in architectural context
separation of concerns
QoS control policy
Ip
Ip
Iq
Pq
Ip
QoS control
legend
I
invocation of network service
Ip
data packet
Iq
QoS signalling
richness of QoS control policy
output
QoS control policy
Ip Ip
• output options:
Iq
Pq
Ip
QoS control
– set of QoS parameters (RSVP service class), Iq
Iq0
Iq
Iq
Ip
Iq
Ip
– packets, Ip, conforming to Iq
Ip
• polymorphic
– function depends on the type of input
richness of QoS control policy
input
QoS control policy
• input options (dumbest first):
prescriptive
Ip Ip
Iq
Pq
Ip
QoS control
declare QoS & degrade pro rata to fit budget
• Iq & budget
Pr
optimise against utility
• vector of utility functions scaled by budget
• vector of currently offered pricing
Iq
task oriented
• dbase of assoc’s betw. QoS policies, tasks & users
• continue with 
declarative
QoS mapping
• QoS conceptions
• user
• application
• network
• utility: user land
• edge QoS control: application land
• network QoS control: network land
QoS mapping
user QoS dimensions
• ???
QoS mapping
application QoS dimensions
• bandwidth, x
– burstiness, dx/dt
• responsiveness, r = 1/latency
– jitter, dr/dt
• delivery probability, d = 1 - (drop prob)
• availability etc: out of scope
network QoS dimensions
e.g. RSVP service class
• guaranteed service/controlled load
• flowspec
– parameters for a token bucket
•
•
•
•
•
token rate
max token size
max burst size
max token rate
etc
inside QoS control policy
U/$
U1(Q1)
p1Q1
U/$
U/$
p2Q2
Q1
U2(Q2)
p3Q3
Q2
U3(Q3)
Q2
...
Q = [Q1, Q2, Q3, Q4, Q5]
U=iUi
?
for any one task, may find one QoS dimension dominates
setting QoS control policy
add 
user-app-task
context
U1(Q1)
U/$
Q1
derive demand curve
price, p
x*
optimal rate, x*
p
conjectured effect of wealth on utility
wealth1
$
wealth2 << wealth1
U1(Q1)
the arrows map between points
of similar QoS sensitivity
Q1
• motivation: re-usable per-task rate control policies
• conjecture: wealth affects utility more strongly
than QoS sensitivity
• QoS sensitivity = marginal utility wrt Q
approximations - summary
• conjectures:
•
•
•
•
one QoS dimension dominates most applications?
use identical utility functions for related tasks?
3 or 4 parameters can approximate a utility curve?
wealth/budget scales utility vertically?
sanity check
security-efficiency compromise
• more expressive QoS control policy has to
include buying policy
• customer can’t trust provider to execute
buying policy
– to audit seems to require complete duplication
of the function
– may have implications for guaranteed service
provider function
types of reaction
sndr sndr proxy
rcvr proxy
preserve
delay buffer
buffer
delay mark
f/b mark
re-xmt drop
f/b nack
less
drop
suppress nack
recode mark
f/b mark
recode f/b nack
f/b nack
f/b drop layer
• explicitly instruct sender what to do
• sender adapts to thinner pipe through f/b
rcvr
buffer
f/b mark
f/b nack
suppress nack
f/b mark
f/b nack
f/b drop layer
• which reaction depends on relative strengths in vector
– but declarative isn’t enough (need some prescription)
legend
service operation
service creation
network
meter
rate control
charge advice
aggregator
tariff
P
policy
duration charged intserv
Pq
PATH
Pq
RESV
Pq
data
sender
receiver
‘abc’ charged intserv
$=aT + bV +c
Pq
PATH
Pq
RESV
Pq
data
sender
receiver
congestion charging
sender (‘s GSP)
receiver (‘s GSP)
Pq
congestion f/b
Pq
CE
data
CE = congestion experienced
GSP = guaranteed stream provider (Kelly’s ‘gateway’)
congestion charging
Pq
sender (‘s GSP)
receiver (‘s GSP)
Pq
congestion f/b
CE
data
CE = congestion experienced
GSP = guaranteed stream provider (Kelly’s ‘gateway’)
price reaction in context
budget
?
PA
PA
PA
buying
agent
C
Pr
Pr
C
application
directory
Pr
rate
control
application involvement
• application options:
• delegate control for non-functional comms
– giving context
• control everything itself
• buying agent shouldn’t take control of QoS
unsolicited
user involvement
• user can:
• give agent control over any stream’s QoS
– giving context
• user must:
• monitor feedback on cost of functional comms
• adapt demand accordingly, through application
controls
the meta-object design pattern
refl_Socket
Reflection class
changeMeta( )
Access to
reflective objects
Application
Access to original objects
Meta calls
QoteS
Meta Object
metaBefore( )
metaAfter( )
Inherit
Some
application class
Java.net.Socket
edge-centric use case
end-customer
Enterprise
policy agent
Offer
directory
Price setting
& reaction
3
Ec
6
Metering
7
5
8
Ep
OO
4
16
AMc
Pc
9
Service
QoS ctrl
1
2
14
App or M/w
Charging &
acc’ting
network provider
11
Qc
10
Pp
10
15
13
CAc
17
Sp
CAp
12
12
Mc
Mp
Qp
edge control use case
end-customer
Enterprise
policy agent
Offer
directory
Price setting
& reaction
3
7
Ec
6
5
8
Pc
9
Service
QoS ctrl
Metering
Ep
OO
4
14
AMc
11
Qc
1
2
16
Pp
10
App or M/w
Charging &
acc’ting
network provider
13
15
Sp
CAp
12
Mp
Qp
price reaction conclusions I
•
•
•
•
separate policy from QoS control
ultimately, QoS control must be polymorphic
QoS mapping important
QoS control policy approximations
• a few parameters (can then be communicated)?
• budget dependency?
• many tasks to few policies?
• QoS control policy implies type of reaction?
price reaction conclusions II
• difficult to do price reaction generically
• limited application hooks
• only simple tariffs allow price reaction
• multi-part tariffs require charge reaction
• allowing for competition is possible but complex on
host
• but relying on provider for charge advice inefficient