The Cable Guy - March 2006

  • Article

Policy-based QoS Architecture in Windows Server 2008 and Windows Vista

TechNet's The Cable Guy

By The Cable Guy

Policy-based Quality of Service (QoS) in Microsoft® Windows Server 2008 and Windows Vista allows you to configure QoS profiles that specify how to mark or throttle outbound traffic. Policy-based QoS settings are distributed using Group Policy. The architecture of Policy-based QoS takes advantage of the Next-Generation TCP/IP stack, the Windows® Filtering Platform, and a new Network Device Interface Specification (NDIS) 6.0 lightweight filter driver.

Introduction to Policy-based QoS

Policy-based QoS in Windows Server 2008 and Windows Vista allows you to offer better end-user experiences, control bandwidth costs, or negotiate finer service levels with bandwidth providers or business departments. You can centrally manage the network bandwidth of computers running Windows Server 2008 or Windows Vista, regardless of the application and across an entire Active Directory® directory service infrastructure. Because the traffic management is occurring below the application layer, existing applications do not need to be modified for Policy-based QoS traffic management.

Policy-based QoS settings in Windows Server 2008 and Windows Vista allows you to prioritize or manage the sending rate for outgoing network traffic based on the following conditions:

  • Sending application

  • Source or destination Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) addresses or address prefixes

  • Protocol (Transmission Control Protocol [TCP], User Datagram Protocol [UDP], or both)

  • Source or destination ports (TCP or UDP)

QoS policies are applied to a user login session or a computer as part of a Group Policy object (GPO) that is linked to an Active Directory container such as a domain, site, or organizational unit (OU). As part of Group Policy, QoS policies leverage your existing Active Directory management infrastructure.

Policy-based QoS allows you to:

  • Define the priority of traffic You can configure a QoS policy to mark outbound network traffic with a specific Differentiated Services Code Point (DSCP) value, as defined in RFC 2474. The DSCP value is stored in the Type of Service (TOS) field in the IPv4 header or the Traffic Class field in the IPv6 header. Most modern enterprise routers support DSCP traffic differentiation, but it is typically disabled by default. DSCP-capable routers read the DSCP value and place a packet being forwarded into a specific queue. For example, you can configure your routers to place forwarded packets into high-priority, best effort, or lower than best effort queues based on DSCP values that you define. By configuring queues and DSCP values, DSCP-marked traffic can have differentiated levels of service. For example, mission-critical network traffic gets forwarding preference and is not delayed by other lower-priority bulk data traffic.

  • Manage the use of bandwidth You can configure a QoS policy with a throttle rate for outbound traffic. With throttling, the QoS components limit the aggregate outgoing network traffic that matches the QoS policy settings to a specified rate.

Both DSCP marking and throttling can be used together to manage traffic effectively.

Architecture of Policy-based QoS

The following figure shows the architecture of Policy-based QoS.

Architecture of Policy-based QoS

The architecture of Policy-based QoS consists of the following components:

  • Group Policy Client Service A Windows service that manages user and computer configuration Group Policy settings.

  • Group Policy engine A component of the Group Policy Client Service that retrieves user and computer configuration Group Policy settings from Active Directory upon startup and periodically checks for changes (by default, every 90 minutes). If changes are detected, the Group Policy engine retrieves the new Group Policy settings. The Group Policy engine processes the incoming GPOs and informs the QoS Client Side Extension when the QoS policies are updated.

  • QoS Client Side Extension A component of the Group Policy Client Service that waits for an indication from the Group Policy engine that the QoS policies have changed and informs the QoS Inspection Module.

  • Next-Generation TCP/IP Stack The redesigned TCP/IP stack for Windows Server 2008 and Windows Vista that includes integrated support for IPv4 and IPv6 and supports the new Windows Filtering Platform. For more information, see Next Generation TCP/IP Stack in Windows Vista and Windows Server 2008, the September 2005 The Cable Guy article.

  • QoS Inspection Module A component within the Next-Generation TCP/IP stack that waits for indications of QoS policy changes from the QoS Client Side Extension, retrieves the QoS policy settings, and interacts with the Transport Layer and Pacer.sys to internally mark traffic that matches the QoS policies.

  • NDIS 6.0 A standard interface between kernel-mode network drivers and the operating system in Windows Server 2008 and Windows Vista. NDIS 6.0 supports new lightweight filters, which is a simplified driver model for NDIS intermediate drivers and miniport drivers that provides better performance.

  • QoS Network Provider Interface (NPI) An interface for kernel-mode drivers to interact with Pacer.sys.

  • Pacer.sys A new NDIS 6.0 lightweight filter driver that controls packet scheduling for Policy-based QoS and for the traffic of applications that use the Generic QoS (GQoS) and Traffic Control (TC) APIs. Pacer.sys replaces Psched.sys in Windows Server 2003 and Windows XP. Pacer.sys is installed with the QoS Packet Scheduler component from the properties of a network connection or adapter.

How Policy-based QoS Works

When starting up or obtaining updated user or computer configuration Group Policy settings for QoS, the following process occurs:

  1. The Group Policy engine retrieves the user or computer configuration Group Policy settings from Active Directory.

  2. The Group Policy engine informs the QoS Client-Side Extension that there were changes in QoS policies.

  3. The QoS Client-Side Extension sends a QoS policy event notification to the QoS Inspection Module.

  4. The QoS Inspection Module retrieves the user or computer QoS policies and stores them.

When a new Transport Layer endpoint (TCP connection or UDP traffic) is created, the following process occurs:

  1. The Transport Layer component of the Next Generation TCP/IP stack informs the QoS Inspection Module.

  2. The QoS Inspection Module compares the parameters of the Transport Layer endpoint to the stored QoS policies.

  3. If a match is found, the QoS Inspection Module contacts Pacer.sys to create a flow, a data structure containing the DSCP value and the traffic throttling settings of the matching QoS policy. If there are multiple QoS policies that match the parameters of the Transport Layer endpoint, the most specific QoS policy is used.

  4. Pacer.sys stores the flow and returns a flow number corresponding to the flow to the QoS Inspection Module.

  5. The QoS Inspection Module returns the flow number to the Transport Layer.

  6. The Transport Layer stores the flow number with the Transport Layer endpoint.

When a packet corresponding to a Transport Layer endpoint marked with a flow number is sent, the following process occurs:

  1. The Transport Layer internally marks the packet with the flow number.

  2. The Network Layer queries Pacer.sys for the DSCP value corresponding to the flow number of the packet.

  3. Pacer.sys returns the DSCP value to the Network Layer.

  4. The Network Layer changes the IPv4 TOS field or IPv6 Traffic Class field to the DSCP value specified by Pacer.sys and, for IPv4 packets, calculates the final IPv4 header checksum.

  5. The Network Layer hands the packet to the Framing Layer.

  6. Because the packet has been marked with a flow number, the Framing Layer hands the packet to Pacer.sys through NDIS 6.0.

  7. Pacer.sys uses the flow number of the packet to determine if the packet needs to be throttled, and if so, schedules the packet for sending.

  8. Pacer.sys hands the packet either immediately (if there is no traffic throttling) or as scheduled (if there is traffic throttling) to NDIS 6.0 for transmission over the appropriate network adapter.

The design of the components of Policy-based QoS has the following advantages:

  • The inspection of traffic to determine whether a QoS policy applies is done per-Transport Layer endpoint, rather than per-packet.

  • There is no performance impact for traffic that does not match a QoS policy.

  • Applications do not need to be modified to take advantage of DSCP-based differentiated service or traffic throttling.

  • QoS policies can apply to traffic protected with Internet Protocol security (IPsec).

For More Information

For more information about this topic, consult the following resources:

For a list of all The Cable Guy articles, click here.