The third part of our proposal involves an opportunity for network service providers to set soft quotas on the total volume of traffic by specific IP Precedence levels. Between peer networks, quotas will have to be negotiated through settlements, which although violating the spirit of the ``no settlements'' policy of some interconnections (e.g., the CIX), will be necessary to control and limit the import of congestion from a correspondent network. In the more prevalent non-peer case, each client of an NSP may receive from the service provider(s) from whom it buys service a quota on the weighted sum of the priority values in its packets per unit time. We suggest a formula such as:
where 
is the total quota used by the customer;
is the number of packets sent with priority 
during the metered period; and 
is a parameter
greater than 1; we suggest 
.
Alternatively, a bandwidth-limited system may set
the quota in terms of transmitted bytes,
or perhaps a weighted average of bytes and packets.
Note that we do not sum over = 0,1, or 7.
In this scheme one can send both priority 0 and priority 1
traffic freely since they have no effect on the value of .
Only network management software will send
priority 7 traffic; others using that priority
would incur penalty by a special mechanism.
One fear is that users will simply set all their traffic to the highest priority. The purpose of the quota is to set loose incentives, monitored after the fact. If a customer exceeds its quota, the local network service provider assesses an after-the-fact penalty, such as an increase in connection charge for the next month; a more careful monitoring of traffic from that client; or if the abuse persists a threat to terminate services to the customer. The NSPs will specify the quota in the contracts with their users (and in contracts between the NSP and its neighbors and backbones). If a customer finds that it is exceeding its quota regularly, it has three choices: negotiate a higher quota, put and enforce quotas on its subordinate units, or pay the penalties assessed on it.
Each service provider decides what original quota to allocate to each
customer, with obvious heuristics such as assigning them in proportion to
pipe capacity that attaches the customer, or in proportion to total
packets sent the previous year.
Customers could also
pre-purchase a higher quota.
We propose that quotas be handled in a decentralized way, with
measurement and enforcement only at gateways between networks, and only as
desired. For example, suppose that backbone 
gives a quota to NSP 
.
can ignore the quota until its traffic (whether original customers or
through gateways) begins to approach the quota. This recurses all the way
down to end users. End users then have a direct or indirect incentive to
limit their use of high priority packets. Each level
chooses its own method of enforcing the quotas
for the next lower level. Thus for a long
time Internet will have a variety of coexisting
quota systems. For some
systems, peer pressure and informal mechanisms (such as publicizing a list
of offenders) may be the most cost-effective means of enforcement.
Metering, when used, has several simplifying characteristics:
Note that we do not tie this scheme directly to billing or pricing. Over time we imagine tying multiple service qualities to more direct monetary incentives for compliance with the otherwise voluntary standard, such as a ``pay per priority'' scheme. Again, each individual service provider has this choice, and different systems may coexist even in a single network.
We illustrate with an example. A university may receive a bulk quota from the regional network to which it attaches. The campus network operations center may reallocate the overall quota to faculty, students, and staff, or to different departments, according to established criteria at that campus. Some universities may use a very egalitarian system, while others may tie the quotas to overhead payments or academic rank. Tracking quota usage by individuals would be too expensive, but various proxies and limiting mechanisms are possible if desired. For example the network operations center may impose control, or at least guidelines, on standard software used (e.g., a special version of NCSA telnet). The NOC can set filters according to user ID, or even in principle take the extreme step of automatically reducing packet precedence levels before the packet enters the regional network.