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 appdecreasing 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

Iq

Pq

Ip IpIp

QoS control

QoS control policy

Iq

Ip

legend

data packet

QoS signalling

I invocation of network service

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

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

QoS mapping

• QoS conceptions• user

• application

• network

• utility: user land

• edge QoS control: application land

• network QoS control: network land

QoS mappinguser QoS dimensions

• ???

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

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

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)

setting QoS control policy

U/$

Q1

U1(Q1)user-app-task

context

add

derive demand curve

price, p

poptimal rate, x*

x*

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

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

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)

legendservice operation

network

meter

rate control

charge advice

aggregator

service creationtariff

policyP

duration charged intserv

sender receiver

Pq

Pq

data

PATH

RESV

Pq

‘abc’ charged intserv

sender receiver

Pq

Pq

data

PATH

RESV

Pq

$=aT + bV +c

congestion chargingsender (‘s GSP) receiver (‘s GSP)

congestion f/b

dataPq

Pq

CE

CE = congestion experiencedGSP = guaranteed stream provider (Kelly’s ‘gateway’)

congestion charging

sender (‘s GSP) receiver (‘s GSP)

congestion f/b

data

Pq

CE

CE = congestion experiencedGSP = guaranteed stream provider (Kelly’s ‘gateway’)

Pq

ratecontrol

directory

Cbuyingagent

Pr

Pr

PAPAPA

Pr

price reaction in context

budget

application

C

?

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

Inherit

Application

Reflection classchangeMeta( )

Someapplication class

Access to original objects

Access toreflective objects

Meta ObjectmetaBefore( )metaAfter( )

Java.net.Socket

QoteS

refl_Socket

Meta calls

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

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

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