The theme of any approach to prioritization of traffic is that if congestion occurs, a logical decision of what to drop or delay is superior to a random one. Figure 1 provided emprical confirmation of this claim using a recent packet trace from an entrance point into the NSFNET backbone. Our scheme does not require a central standard-setting; the IP precedence field is already a standard, albeit a non-enforced and essentially unutilized one. It also does not require central enforcement. As long as there is no resource contention, there is no need to prioritize traffic. The only question is that as congestion occurs, who gets hurt and how much.
An important characteristic of our proposal is its decentralized nature. Players, whether network users, clients, or service providers can participate in the scheme, via implementation of their portion, or not, as they choose. Players can also choose whether to impose incentives to lower level customers. Incentives can be of many different kinds; quotas are only one alternative. Some networks could decide to bill by priority, rather than set quotas. Each decision is between the provider and its customers.
Other approaches favor classifying traffic by more abstract definitions, such as local funding agencies or specific applications being used. As the Internet matures to a market driven environment based on varieties of funding sources and billing arrangements, as well as multitudes of varying requirements for millions of users and thousands of applications, we believe that qualifying traffic priorities according to applications and users will not scale to a global environment, largely due to the inability to manage and administer such an environment while ensuring global consistency. Decentralized arrangements in client-provider relationships without global impact would likely be easier to implement, operate, and manage. The implementation we suggest here is only one example of a step in the direction we advocate. It is by no means a permanent solution, but gears the community toward the use of multiple service levels, which we view as the essential architectural objective.