As noted earlier in this paper, Microsoft will also support the Resource Reservation Protocol (RSVP) for IP, allowing software developers to "reserve" bandwidth on the Internet.
RSVP, if completely implemented, is intended to provide QoS over any media, even if the media itself provides none. But RSVP allows only a much less granular, more generic QoS guarantee. The present definition of RSVP includes a number of stations, all connected to a switch that handles local traffic, which in turn is connected to a router, which provides WAN access. The RSVP definition is concerned primarily with the router, which means that when one router wants to talk to another, RSVP can request a certain quantity of bandwidth. But the Internet allows connections over various types of routers, most of which don't support RSVP.
Additionally, RSVP doesn't yet apply to the station or the switch, meaning that an Ethernet card doesn't know anything about quality of service, or limiting packet release to assure that it doesn't go over its allocation. These things have to be done in software via packet schedulers. There is no plan or infrastructure for putting RSVP on the switch. With ATM, every component in the line is ATM-based, so it can provide absolute guarantees.
RSVP also doesn't provide a mechanism for tracking and billing for quality of service, which is a major concern for carriers. Tracking and billing are easily done using ATM.
As noted, RSVP does not address all the needs of QoS, but RSVP and related protocols are significant. Microsoft will continue to support efforts related to enabling real-time multimedia applications to run on IP or other types of networks. For many customers, this measure of QoS will be sufficient. For other customers, ATM will be required.