Share via

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.

Comments

  • Anonymous
    July 09, 2006
    So, in Vista the OS no longer does any classification? It does only probing on L2+ layers and the classification got "offloaded" to the lower (hardware) transport layers?

  • Anonymous
    July 09, 2006
    Actually, Vista provides a full, comprehensive platform for classification called WFP (Windows Filtering Platform). Please review the WFP post category on this blog. Qos2 APIs take a socket handle as input, and as such, the QoS subsystem knows all the classification information necessary to match outgoing packets for the flow (src/dst IP address, src/dst port, and protocol). The hardware (or NIC driver) is not responsible in any way for classification.
    That said, the OS does both classification and probing to estimate bandwidth real-time. If you are a little more specific with your question, I'd be happy to answer.
    - Gabe

  • Anonymous
    July 12, 2006
    Over the past few months we've been receiving feedback from partners on the new QOS2 API I just...

  • Anonymous
    July 12, 2006
    Over the past few months we've been receiving feedback from partners on the new QOS2 API I just...

  • Anonymous
    August 02, 2006
    Thank you Gabe, I'll need to look at the WFP and QOS2 API again...
    From the first look I've gathered (wrongly?) that you implemented  two different solutions:
    Pacer is for business class managed clients, and it does classification, as previosly TC did. qWave and QOS2 is for unmanaged / self managed networks, and it lets the apps mark their traffic with priority. Then, some other layer can (optionally) shape traffic based on the flow characteristics - but there is no classification such as by port, ip protocol and so on. correct?

  • Anonymous
    August 02, 2006
    The comment has been removed

  • Anonymous
    October 31, 2006
    There has been a lot of buzz about the recent fall update for the Xbox 360; however, an important new

  • Anonymous
    January 22, 2008
    This is all very well but what if you write network stress testing applications and you just want to vary the diffserv byte in the ip header.  Too much stuff to learn to do a simple thing!  Is there no registry setting like XP to allow direct setting of the byte?