A while back I wrote about the fundamentals of networking Quality of Service (QoS) including 802.1p and DSCP. Gabe recently wrote about WMM. With Vista soon to hit the market, it's time for us to talk about the new and old QoS APIs. Let's start with the old ones.

The idea of networking Quality of Service in Windows has been around for a long time. If you look at the APIs in Windows 2000 and Windows XP, you'll find at least 3 APIs for QoS. We reviewed each of them and decided to deprecate them. What this means is that, some time in the future, each of these APIs will be removed from Windows. Until they're removed though, backwards compatibility remains important. Therefore, although all of these APIs have been changed to some extent in Vista, we made sure to NOT break any dependencies applications might have on header files, libraries or DLLs. Here's what we did:

1. IP_TOS
   When I wrote about DSCP, I mentioned that the RFC which defined Type Of Service (TOS) in IP, RFC 1349, is now obsolete. Back in XP we had disabled the Winsock IP_TOS option. If you used this socket option, the call would succeed but be ignored silently. You could re-enable it through a registry value. In Vista, this registry mechanism has been removed: Winsock IP_TOS option is no longer available.  The call will always be ignored silently. Why silently? Because otherwise we would have had to return an error. This would have broken legacy applications. To get DSCP marking, you should use the QOS2 API.
2. Generic Quality of Service (GQoS)
   The feedback we received from developers was GQoS, with token bucket semantics, is too hard to use - especially if you are not certain what the network traffic characteristics of your application look like. If you were using this API, we encourage you to switch to the new, much simpler, QOS2 API which you can find in QOS2.h. In the meantime, the old QOS.h header file has been updated with a warning.
3. Traffic Control (TC)
   If you've ever looked at the TC API, you might have noticed two things:
   1. It uses filters to identify outgoing traffic of interest. Compare this to the GQoS or QOS2 APIs which are built around sockets. When a packet travels down the networking stack, the QoS subsystem knows immediately whether or not the packet is part of a flow since each flow is affiliated to a specific socket. When TC is used, every packet needs to first be classified. This adds needless CPU overhead to many networking scenarios.
   2. You need to be an admin to use the TC API. As you've probably heard, Vista has a new security model for user accounts. Should your application really have to run under administrative credentials to shape its outgoing traffic? 

Overall, with QOS2 and Policy-based QoS, the TC API is no longer the right API to program to for your scenarios. Again, to maintain backwards compatibility, we kept this API in Vista. However, every one of its functions has been marked deprecated in the header file. If need be, with some work you can still compile against this API, and of course, the DLL will remain to ensure application compatibility.

Deprecating an API and its technology is never an easy decision. When we reviewed why and how people were using these APIs, we found that the new QOS2 API could always be used instead much more easily. If the new API doesn't meet your needs, please email us a description of your scenario and what you'd like this new platform API to do.

- Mathias Jourdain