Service Differentiation: Congestion Pricing, Brokers and Bandwidth Futures

In most Networks or Systems, users compete for a set of limited resources. Resources might be point-to-point bandwidth, buffer space, memory, CPU cycles etc. and users can be humans, applications or processes. Connection-oriented Telecoms services use either reservation, where resources are booked in advanced or Admission Control — think of telephony or ATM for example. Packet-based services and Operating Systems rely mainly on either priority schemes, for instance using simple priority queues, or flow-control feedback mechanisms such as TCP. The current Internet uses flow-control with an admit-all policy that relies on secondary measures, such as users’ willingness to tolerate current service, to throttle excess load. Within the IETF, IntServ is attempting to define connection-oriented admission control schemes whilst DiffServ is based on connectionless ideas, attempting to use priorities and complex queuing disciplines to provide QoS classes. But if we step outside the Computer Science or Telecommunication mindset, we see the same problem occurring in other areas, but solved using resource pricing as a fundamental ingredient. For example, think of resources as airline seats, units of (electrical) power or economic wealth. Prices or taxes are used to control the load, or to maximise the return by offering differential services at different prices — think for instance of power companies who use price incentives and penalties, or airlines. We claim not only that it is impossible to separate service differentiation from pricing, but also that some use of resource pricing is the only sensible way to proceed. The first point is clear: if there are two qualities which both cost the same, any rational person will chose the higher quality! As an example, most current DiffServ proposals are interesting but fundamentally flawed, caused by attempting to define technologies independently of economics or implementation. They attempt to define local priority schemes and scheduling policies, whereas an application/user is interested in end-to-end performance. Also, the cost and complexity of scheduling policies is not addressed. Even if the hardware cost is not significant, there are real management overheads. A salutary example is provided by the ABR service of ATM: this only really makes sense if ABR operates from end-system to end-system, which now looks highly unlikely. Moreover, despite being more complex to implement, it would have to be charged at a cheaper tariff than say a CBR service operating at the MCR, despite using the same bandwidth. (Otherwise a smart user with delay insensitive traffic could just use CBR and overflow excess traffic to a best-effort traffic class that has be to an order of magnitude cheaper). The Explicit Congestion Notification (ECN) [ ] proposal within DiffServ looks attractive, and we believe can be extended to give as much diversity as is required. Our contribution is to break away from shackles of mandatory TCP-like behaviour inherent in the current ECN RFC. We can even incorporate call admission control at the flow or micro-flow level, an anathema to the current DiffServ!