Scenarios and technologies of QOS2

  • Article

After XP, when we reviewed the scenarios for QoS in Windows, we considered the following 4 big categories:

  1. I'm a network administrator who wants to control how the traffic from the computers on my domain will be marked with priority (DSCP).
  2. I want to apply shaping or marking to an application that doesn't know about QoS. I don't want to (or cannot) modify and recompile my application.
  3. I want my user's experience to adapt to changes in the network. If there's not enough bandwidth available, I want to know this so my application can change the content. I'm willing to modify and recompile my application.
  4. My application can't adapt its content to the changes in the network bandwidth. However, I still want marking or shaping.

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:

  1. By design we will not allow you to probe to an offlink (cross subnet) destination. For example, you can't probe to a destination if the traffic needs to go through a router. The networking hardware on the Internet is too different from those found in your home. 
  2. The probe packets must be able to go throuh in each direction. qWave can either use UDP/TCP probes or LLTD probes.
    1. The UDP/TCP traffic is on port 2177 (as assigned by the IANA) which, in Vista, the firewall will block by default (destination won't be able to receive the probe packets)
    2. LLTD is a new layer 2 protocol that is used for mapping networks and is part of the Windows Rally technologies. If your machine is joined to a domain or a public network, it'll be disabled by default (qWAVE won't be able to send probe packets).
  3. What if the destination is not a Vista PC? It wouldn't have the components to receive this qWave probe traffic.
    • You can download the LLTD porting kit from the Windows Rally website to implement it on your device.
  4. Finally, maybe you, as an application developer, don't care to know about network conditions, but rather only marking packets for priority and/or shaping?

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.