After XP, when we reviewed the scenarios for QoS in Windows, we considered the following 4 big categories:
Scenarios #1 and #2 are perfect for the policy based QoS technology that Gabe wrote about previously. Through it, you can effect QoS on applications' traffic without their knowledge. You can even override the QoS characteristics that an application has requested through a QoS API.
The QOS2 API was aimed at scenarios #3 and #4.
An adaptive flow:
Scenario #3 happens a lot with unstable networks - think about your wireless network. Let's say you're watching TV at home over your wireless network. Suddenly some interference lowers the quality of the wireless connection. There's literally less bandwidth available than before. Maybe there's not even enough left for you to watch TV anymore. Which would you prefer: stop watching TV or watch TV with a lesser video quality? I know I'd rather have a smooth lesser-quality video than a jerky one.
We call this an adaptive experience. The technology in the QOS2 api that evaluates network conditions is named qWave. qWave is a combination of various network probing schemes designed for home networks. You read this right: it probes your home network. With these lightweight probes, at an application's request, qWave estimates the maximum bandwidth and the available bandwidth on a given network path. It can also detect when there's congestion and more... The application then uses this information (exposed via the QOS2 API) to adapt the content and give the user the best quality possible given the ever changing available network ressources.
Probing isn't always feasible though. Here are some reasons why probing to a specific destination might not be supported or interesting:
A non-adaptive flow:
If your flow of traffic won't adapt to the network, you have a non-adaptive experience. This is scenario #4. It might be the case you're sending traffic to the Internet, it might be that you simply want to limit the throughput of your traffic, or it might be that you just want to prioritize/deprioritize your traffic vs. everyone else's per WMM. Historically, you would solve this with the GQoS API in XP. However, we found most developers didn't like this API. It had a convoluted syntax. Mostly, it used a token bucket model which, although great in its ability to characterize the flow of traffic, is very hard to define correctly.
Next time we'll see how these two different scenarios are handled in the QOS2 API.
- Mathias Jourdain
P.S.: As I wrote previously, GQoS has been marked for deprecation and will be removed in a subsequent release of Windows; developers should migrate to QOS2.