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 IqIq PqPq IpIp IpIp IpIp QoS control QoS control policy IqIq IpIp legend data packet QoS signalling I invocation of network service

richness of QoS control policy output output options: –set of QoS parameters (RSVP service class), I q –packets, I p, conforming to I q polymorphic –function depends on the type of input IqIq IqIq I q0 IqIq IpIp IpIp IpIp IqIq PqPq IpIp IpIp IpIp QoS control QoS control policy

richness of QoS control policy input input options (dumbest first): prescriptive  declare QoS & degrade pro rata to fit budget I q & 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 IqIq PrPr IqIq PqPq IpIp IpIp 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 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/$ Q1Q1 p1Q1p1Q1 U 1 (Q 1 ) U/$ Q2Q2 p2Q2p2Q2 U 2 (Q 2 ) Q = [Q 1, Q 2, Q 3, Q 4, Q 5 ] U=  i U i ? for any one task, may find one QoS dimension dominates... U/$ Q2Q2 p3Q3p3Q3 U 3 (Q 3 )

setting QoS control policy U/$ Q1Q1 U 1 (Q 1 ) user-app-task context add 

derive demand curve price, p p optimal rate, x * x*x*

conjectured effect of wealth on utility $ Q1Q1 U 1 (Q 1 ) wealth 1 wealth 2 << wealth 1 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 points of 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 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 sndrsndr proxyrcvr proxyrcvr preservedelaybufferbufferbuffer delaymarkf/b markf/b mark re-xmtdropf/b nackf/b nack less-dropsuppress nacksuppress nack recodemarkf/b markf/b mark recodef/b nackf/b nackf/b nack --f/b drop layerf/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)

legend SC session characteris’n P policy $ charge record C context information (hard state) message state & interface R resource M mgmt = any of Q query OA offer acceptance O offer AA address allocation QA QoS policy association A association = any of IqIq QoS signalling IpIp data packet I service invocation = either of

legend service operation network classifier meter rate control charge advice distributor aggregator settlement service creation pricing tariff directory utilities correlator transform

legend service operation network meter rate control charge advice aggregator service creation tariff policy P

duration charged intserv senderreceiver PqPq PqPq data PATH RESV PqPq

‘abc’ charged intserv senderreceiver PqPq PqPq data PATH RESV PqPq $=aT + bV +c

congestion charging sender (‘s GSP)receiver (‘s GSP) congestion f/b data PqPq PqPq CE CE = congestion experienced GSP = guaranteed stream provider (Kelly’s ‘gateway’)

congestion charging sender (‘s GSP)receiver (‘s GSP) congestion f/b data PqPq CE CE = congestion experienced GSP = guaranteed stream provider (Kelly’s ‘gateway’) PqPq

rate control directory C buying agent PrPr PrPr PA PrPr 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 class changeMeta( ) Some application class Access to original objects Access to reflective objects Meta Object metaBefore( ) metaAfter( ) Java.net.Socket QoteS refl_Socket Meta calls

O O CA c AM c CA p end-customernetwork provider service provision Enterprise policy agent Offer directory Price setting & reaction App or M/w Service Charging & acc’ting QoS ctrl Metering SpSp PpPp QcQc PcPc QpQp edge-centric use case McMc MpMp EpEp EcEc

O O AM c CA p end-customernetwork provider service provision Enterprise policy agent Offer directory Price setting & reaction App or M/w Service Charging & acc’ting QoS ctrl Metering SpSp PpPp QcQc PcPc QpQp edge control use case MpMp EpEp EcEc

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