Download - M3I price reaction
![Page 1: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/1.jpg)
M3I price reaction
Bob Briscoe
31 May 2000
![Page 2: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/2.jpg)
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
![Page 3: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/3.jpg)
control granularity
• fixed pipe per customer (diffserv)• fixed pipe per flow, but can adapt (intserv)• congestion charge reaction middleware• congestion charge reaction by appdecreasing prediction requirement
• what is the Internet denying by only supports predictable apps?
![Page 4: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/4.jpg)
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
![Page 5: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/5.jpg)
separation of concerns
Iq
Pq
Ip IpIp
QoS control
QoS control policy
Iq
Ip
legend
data packet
QoS signalling
I invocation of network service
![Page 6: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/6.jpg)
richness of QoS control policyoutput
• output options:– set of QoS parameters (RSVP service class), Iq
– packets, Ip, conforming to Iq
• polymorphic– function depends on the type of input
Iq
IqIq0 Iq
Ip IpIp
Iq
Pq
Ip IpIp
QoS control
QoS control policy
![Page 7: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/7.jpg)
richness of QoS control policyinput
• input options (dumbest first):prescriptive
declare QoS & degrade pro rata to fit budget• Iq & budget
optimise against utility• vector of utility functions scaled by budget• vector of currently offered pricing
task oriented• dbase of assoc’s betw. QoS policies, tasks & users• continue with
declarative
Iq
Pr
Iq
Pq
Ip IpIp
QoS control
QoS control policy
![Page 8: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/8.jpg)
QoS mapping
• QoS conceptions• user
• application
• network
• utility: user land
• edge QoS control: application land
• network QoS control: network land
![Page 9: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/9.jpg)
QoS mappinguser QoS dimensions
• ???
![Page 10: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/10.jpg)
QoS mappingapplication 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
![Page 11: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/11.jpg)
network QoS dimensionse.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
![Page 12: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/12.jpg)
inside QoS control policyU/$
Q1
p1Q1U1(Q1) U/$
Q2
p2Q2
U2(Q2)
Q = [Q1, Q2, Q3, Q4, Q5]U=iUi ?
for any one task, may find one QoS dimension dominates
...
U/$
Q2
p3Q3
U3(Q3)
![Page 13: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/13.jpg)
setting QoS control policy
U/$
Q1
U1(Q1)user-app-task
context
add
![Page 14: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/14.jpg)
derive demand curve
price, p
poptimal rate, x*
x*
![Page 15: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/15.jpg)
conjectured effect of wealth on utility
$
Q1
U1(Q1)
wealth1
wealth2 << wealth1
• motivation: re-usable per-task rate control policies• conjecture: wealth affects utility more strongly than QoS
sensitivity• QoS sensitivity = marginal utility wrt Q
the arrows map between pointsof similar QoS sensitivity
![Page 16: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/16.jpg)
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?
![Page 17: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/17.jpg)
sanity checksecurity-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
![Page 18: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/18.jpg)
types of reactionsndr sndr proxy rcvr proxy rcvr
preserve delay buffer buffer buffer
delay mark f/b mark f/b mark
re-xmt drop f/b nack f/b nack
less - drop suppress nack suppress nack
recode mark f/b mark f/b mark
recode f/b nack f/b nack f/b nack
- - f/b drop layer f/b drop layer• explicitly instruct sender what to do• sender adapts to thinner pipe through f/b
• which reaction depends on relative strengths in vector– but declarative isn’t enough (need some prescription)
![Page 19: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/19.jpg)
legendservice operation
network
meter
rate control
charge advice
aggregator
service creationtariff
policyP
![Page 20: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/20.jpg)
duration charged intserv
sender receiver
Pq
Pq
data
PATH
RESV
Pq
![Page 21: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/21.jpg)
‘abc’ charged intserv
sender receiver
Pq
Pq
data
PATH
RESV
Pq
$=aT + bV +c
![Page 22: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/22.jpg)
congestion chargingsender (‘s GSP) receiver (‘s GSP)
congestion f/b
dataPq
Pq
CE
CE = congestion experiencedGSP = guaranteed stream provider (Kelly’s ‘gateway’)
![Page 23: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/23.jpg)
congestion charging
sender (‘s GSP) receiver (‘s GSP)
congestion f/b
data
Pq
CE
CE = congestion experiencedGSP = guaranteed stream provider (Kelly’s ‘gateway’)
Pq
![Page 24: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/24.jpg)
ratecontrol
directory
Cbuyingagent
Pr
Pr
PAPAPA
Pr
price reaction in context
budget
application
C
?
![Page 25: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/25.jpg)
application involvement
• application options:• delegate control for non-functional comms
– giving context
• control everything itself
• buying agent shouldn’t take control of QoS unsolicited
![Page 26: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/26.jpg)
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
![Page 27: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/27.jpg)
the meta-object design pattern
Inherit
Application
Reflection classchangeMeta( )
Someapplication class
Access to original objects
Access toreflective objects
Meta ObjectmetaBefore( )metaAfter( )
Java.net.Socket
QoteS
refl_Socket
Meta calls
![Page 28: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/28.jpg)
OO
CAc
AMc
CAp
end-customer network provider
serviceprovision
Enterprise Enterprise policy agentpolicy agent
Offer directory
Price setting & reaction
App or M/w
Service
Charging & Charging & acc’tingacc’ting
QoS ctrl
Metering
Sp
Pp
Qc
Pc
Qp
edge-centric use case
McMp
EpEc
2
45
7
3
10 10
6
12 12
13 15
8
1
9
11
14
16
17
![Page 29: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/29.jpg)
OO
AMc
CAp
end-customer network provider
serviceprovision
Enterprise Enterprise policy agentpolicy agent
Offer directory
Price setting & reaction
App or M/w
Service
Charging & Charging & acc’tingacc’ting
QoS ctrl
Metering
Sp
Pp
Qc
Pc
Qp
edge control use case
Mp
EpEc
2
45
7
3
10
6
12
13 15
8
1
9
11
14 16
![Page 30: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/30.jpg)
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?
![Page 31: M3I price reaction](https://reader036.vdocuments.net/reader036/viewer/2022081519/56813b47550346895da42ace/html5/thumbnails/31.jpg)
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