Which Goals, and What Assumptions? Douglas S. Reeves N. C. State University Workshop on Pricing and QoS ENTS September 23, 1999 A sign of maturity in an area is agreement about goals, and to some extent about reasonable assumptions. The area of pricing and QoS has not reached that point yet. The result is some confusion, lack of impact, and slowed progress.

Which Goal? vs.? and? Fair allocation Maximum utility + maximum revenue For the most paper, research papers address one or the other of these goals, but not both. Fairness appeals to networking types, utility+revenue to business people and economists. Both aspects appeal to users. These goals should not be contradictory, but more work needs to be done to unify them. The result will bring two communities together.

What Does "Fair" Mean? Pareto efficient Max-min Proportional fair Utility fair There is some lack of agreement on what the right form of fairness should be. More work needs to be done on what the practical differences between these forms of fairness are. for real networks.

Price Uniformity Should everybody face the same price? Prof. Odlyzko’s presentation does a brilliant job of explaining why price discrimination is both common and desirable. Examples of possible price discrimination include varying price with QoS, varying price with amount of resource, and varying price with length of usage.

Time Scale vs. Congestion control (reactive, distributed) Network optimization (static, centralized) Much work fails to address clearly this all-important issue. A dynamic method is suitable for quickly-changing conditions, and will almost certainly have to be distributed and iterative. Static methods are suitable for long time scales and can afford to do a more centralized optimization. It is my opinion that no single method of pricing will be suitable across all time scales. And description of a new method should address what time scale it is appropriate for!

Price Variation vs. Price simplicity and predictability Fixed prices Flexibility and efficiency Cheap prices vs. Everyone would like fixed prices, but no price is fixed forever, so the issue here is on what time scale a price may vary. If a single user is guaranteed that his/her price will not vary for the duration of usage, then either a) all usage starts and stops at the same time, or b) prices never change for anybody, or c) different users experience different prices. None of these is very attractive! The choices given to users will likely be fixed but expensive prices, or variable but cheap prices. It’s unlikely all users will make the same choice. User preferences about price variation can easily be interpreted as risk preferences, with removal of price variation as a form of “insurance” against risk, etc. There is quite a bit of experience / machinery that can be drawn upon in this domain.

What Do We Know? Desirability of knowing traffic parameters, utility, indifference Need to know Difficulty of knowing/expressing traffic parameters, utility, indifference Unwillingness to tell vs. It is questionable whether users can or will provide accurate information about themselves and their intended usage. The ability to infer user preferences is a major assumption which needs to be validated in practice.

Elasticity Does elastic mean non-guaranteed? What is the real elasticity / utility? “Elastic” traffic is similar to the concept of scalable QoS. I don’t know what it means to have guaranteed QoS for elastic traffic! Unless the elasticity is only used during admission control, and thereafter is no longer exploited.

QoS Classes How many classes are enough? Is QoS continuous or discreet? Having many choices can lead to economic efficiency, but can also be confusing and hard to implement. (Again, Prof. Odlydzko’s presentation does an admirable job of the trend toward flat rate pricing). With discreet QoS classes, utility or QoS curves are no longer continuous, differentiable and convex, which may be a problem for most of the proposed techniques.

Practicalities vs. Precision of control Resources cost more Efficiency + low overhead accounting + billing costs more Hierarchical or aggregated pricing vs. An issue generally avoided is whether the gains of efficiently allocating resources are sufficient recompense for the expenses of accounting and billing that pricing requires. As the price of resources goes down, this question gains importance. An approach (besides flat rate pricing) is to price aggregate usage, or do pricing on a coarser time scale. It’s a pragmatic issue that will probably be decided by service providers more than anyone else.

Resources vs. Resource provisioning Need for access Time scale of capacity expansion Resource allocation Quality and cost of access Time scale of traffic changes vs. In most places, the telephone system has been designed so that a denial of service is a rare event. It’s a great solution but increases costs. A difference with the telephone system is that it is trivial to generate large resource demands from a single end point, so the potential for abuse when resources are not charged is much greater. Provisioning is clearly a long time scale fix, not a solution to short time scale congestion, unless service providers develop a very flexible market for short time scale resource provisioning; pricing among service providers, rather than users!

What's Important? vs. Pricing of resources Which resources? Pricing of QoS Which QoS? vs. It may be difficult to determine the relationship between resource amount and perception of QoS, and certainly there’s little data available for applications other than voice. There is considerable disagreement in the pricing literature as to which resources and which QoS parameters are the important ones to measure and control.

Protection vs. Protecting the network resources Protecting the pricing mechanism A frequent justification for pricing is to protect the network from abuse. If that is the goal, then we need to pay careful attention to whether the pricing mechanism itself is robust and protected from attack. If it’s not, we have just substituted one vulnerability for another, i.e., rather than steal the goods, one could just steal the cash and then buy the goods.