frastructure. However, this is much more important to the enterprise than to the average consumer. While enterprises are likely to indeed be willing to pay to have their traffic between ISP-connected sites routed at a certain priority, consumers are more likely to be willing to pay for simple enhanced services (such as higher bandwidth for a higher monthly fee) rather than individual QoS controls. And for the ISPs, there's little economic incen- tive to offer individual QoS because it is much too expensive to manage. There are really two types of metrics that we loosely refer to as QoS: class of service (CoS) and true QoS. CoS is a prioritization scheme-like having a plati- num credit card versus a gold card versus a regular card. With CoS, you can priori- tize streams and thereby facilitate better performance. QoS, however, deals with very strict traffic measurements, where you can specify the latencies end to end, the jitter or variable latencies in the receipt of the packets, the tolerable cell loss, and the mechanism for allocating the bandwidth continuously or on a bursty basis. QoS is much more stringent than CoS, and what we are currently using in the Internet is really more like CoS than QoS. Techniques such as DiffServ allow us to prioritize the traffic streams, but they really do not allow us to control the traffic measurements. That is why, as discussed in Chapter 10, we tend to still rely on ATM within the core: ATM allows the strict control of traffic measurements, and it therefore enables us to improve perfor- mance, quality, reliability, and security. Efforts are under way to develop equivalent QoS mechanisms for IP networks, such as MPLS, which is increasingly deployed and available (also discussed in Chapter 10), but we are still a couple years away from clearly defining the best mechanism, especially because we need to consider the marriage of IP and optical technologies. In the meantime, we are redesigning the Internet core, moving away from what was a connectionless router environ- ment that o