Policy-based Quality of Service (QoS)

As traffic increases on a network, it becomes increasingly important for IT departments to balance network performance with the cost of service. However, network traffic is not easily prioritized and managed. Mission-critical and latency-sensitive applications must compete for bandwidth against lower priority traffic. At the same time, some users and computers with specific network performance requirements might require differentiated service levels.

Such challenges of providing cost-effective, predictable network performance levels often first appear over wide area network (WAN) connections or with latency-sensitive applications, like voice over IP (VoIP) and video. However, the end-goal of providing predictable network service levels applies to any network environment (for example, an enterprises’ local area network), and to more than VoIP applications, such as your company's custom line-of-business applications.

For computers running Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008, and Windows Vista, you can use Policy-based Quality of Service (QoS) to manage traffic to offer better user experiences, control bandwidth costs, or more finely negotiate service levels with bandwidth providers or business departments. Policy-based QoS provides network control based on applications, users, and computers. Applications do not need to be written for specific application programming interfaces (APIs), providing you with the ability to use QoS with existing applications. Additionally, Policy-based QoS takes advantage of your existing management infrastructure, because Policy-based QoS is built into Group Policy.

You can specify QoS policies that define priority through a Differentiated Services Code Point (DSCP) value. The DSCP applies a value (0–63) within the Type of Service (TOS) field in an IPv4 packet's header and within the Traffic Class field in IPv6. This DSCP value provides classification at the Internet Protocol (IP) level, which routers can use to decide queuing behavior. You can also limit an application's outbound network traffic by specifying a throttle rate.

For example, you can configure routers to place packets with specific DSCP values into one of three queues: high-priority, best-effort, or lower-than-best effort. Therefore, mission-critical network traffic, which is in the high-priority queue, gets preference before other traffic. The QoS policy that defines throttling limits the rate of outbound network traffic. For example, an IT department might implement a service level agreement that specifies that a file server can never provide downloads beyond a specific rate to manage WAN costs.

You can also use Policy-based QoS to apply DSCP values and throttle rates for outbound network traffic to the following:

Sending application and directory path

Source and destination IP addresses, including support for address prefixes

Specific groups of users or computers (through deployment in Group Policy)

By using these controls, you can specify a QoS policy with a DSCP value of 46 for a VoIP application, enabling routers to place those packets in a low-latency queue, or you can use a QoS policy to throttle a set of servers' outbound traffic to 512 kilobytes per second (KBps) when sending from TCP port 443. Or, as in the expanded example in the next section, QoS policy can be applied to a particular application that has special bandwidth requirements.

With Policy-based QoS, IT administrators can configure and enforce QoS policies that cannot be configured on routers and switches.

Level of detail: It is difficult to create user-level QoS policies on routers or switches, especially if the user’s computer is either configured by using dynamic IP address assignment or if the computer is not connected to fixed switch or router ports, as is frequently the case with portable computers. In contrast, Policy-based QoS makes it easier to configure a user-level QoS policy on a domain controller and propagate it to the user’s computer, regardless of where or how the computer connects to the network. For example, you can configure a user-level QoS policy that will apply to a computer, no matter where the user logs on: for example, in either a main office or in a branch office. Similarly, the same user level QoS policy will apply no matter how the user connects to the network: for example, by either the wired Ethernet network or by Wi-Fi.

Security: If your IT department encrypts users’ traffic from end to end by using Internet Protocol security (IPsec), you cannot classify the traffic on routers based on any information above the IP layer in the packet (for example, a TCP port). However, by using Policy-based QoS, you can classify packets at the end device to indicate the priority of the packets in the IP header before the IP payloads are encrypted and the packets sent out.

Performance: Some QoS functions, such as throttling, are better performed when they are closer to the source. Policy-based QoS moves such QoS functions to where they can be closest to the source.

Manageability: Policy-based QoS enhances the network manageability in two ways:

First, because it is based on Group Policy, you can use Policy-based QoS to configure and manage a set of user/computer QoS policies whenever necessary, and on one central domain-controller computer.

Second, Policy-based QoS facilitates user/computer configuration by providing a mechanism to specify policies by URL, as opposed to specifying policies based on the IP addresses of each of the servers where QoS policies need to be applied.

For example, assume your network has a cluster of servers that share a common URL. By using Policy-based QoS, you need only to create one policy based on that common URL, as opposed to creating one policy for each server in the cluster, with each policy based on the IP address of each server.

In this scenario, an IT department adds QoS to provide better network performance for a key set of users and the mission-critical applications users depend on, but also needs to minimize the WAN link costs. The IT department decides to prioritize specific applications by using DSCP values to classify network traffic, and to configure its routers to provide preferential treatment for higher priority traffic. Later, they might consider using this classification to negotiate service levels for the leased WAN links.

In addition to DSCP values, the QoS policies can specify a throttle rate. Throttling limits all outbound traffic that matched the QoS policy to a specific send rate.

The first mission-critical application to use Policy-based QoS is a company-wide enterprise resource planning (ERP) application. The ERP application is hosted on several computers running Windows Server 2012 in the data center, which are part of an organization unit (OU) for computers. While many groups within the company access the ERP application, the finance group requires differentiated performance, because the finance group depends on this application when dealing with customers. The client-side component for the ERP application is installed on computers running Windows 8, Windows 7, and Windows Vista.

The following example illustrates the clients and servers in a prioritization scenario. The subsequent section titled "Configuring Policy-based QoS" walks through the wizard steps for creating QoS policies. In this example, the IT administrator selects the Group Policy Object (GPO) on which the QoS policy will be deployed. Through the QoS policy wizard, the IT administrator creates a QoS policy for the group of servers called "Server LOB policy" that specifies a high-priority DSCP value of 44 for all applications, any IP address, TCP and UDP, and port number. The QoS policy is applied only to the line-of-business (LOB) servers by linking the GPO to the OU that contains only these servers, via the Group Policy Management Console (GPMC) tool. This initial server LOB policy applies the high-priority DSCP value whenever the computer sends network traffic. This QoS policy can later be edited (in the Group Policy Object Editor tool) to include the ERP application's port numbers, which limits the policy to apply only when the specified port number is used.

To ensure that the finance group can support their customers, a QoS policy needs to classify these users' traffic as higher priority. However, the policy should not apply when members of the finance group use applications other than the ERP application. Thus, the IT department defines a second QoS policy called "Client LOB policy" in the Group Policy Object Editor tool that applies a DSCP value of 60 when the finance user group runs the ERP application.

A separate backup application is running on all computers. To ensure the backup application's traffic does not use all available network resources, a backup data policy is created. This backup policy specifies a DSCP value of 1 based on the executable name for this backup application, backup.exe. A third GPO is created and deployed for all client computers in the domain. Whenever the backup application sends data, the low-priority DSCP value is applied, even if it originates from computers in the finance department.

Note that traffic without a QoS policy sends with a DSCP value of 0.

The following table summarizes the QoS policies for this scenario.

Policy name

DSCP value

Throttle rate

Applied to organization units

Description

[No policy]

0

None

[No deployment]

Best effort (default) treatment for unclassified traffic.

Backup data

1

None

All clients

Applies a low-priority DSCP value for this bulk data.

Server LOB

44

None

Computer OU for ERP servers

Applies high-priority DSCP for ERP server traffic

Client LOB

60

None

Finance user group

Applies high-priority DSCP for ERP client traffic

Note

DSCP values are represented in decimal form.

With QoS policies defined and applied by using Group Policy, outbound network traffic receives the policy-specified DSCP value. Routers then provide differential treatment based on these DSCP values by using queuing. For this IT department, the routers are configured with four queues: high-priority, middle-priority, best-effort, and low-priority.

When traffic arrives at the router with DSCP values from "Server LOB policy" and "Client LOB policy," the data is placed into high-priority queues. Traffic with a DSCP value of 0 receives a best-effort level of service. Packets with a DSCP value of 1 (from the backup application) receive low-priority treatment.

To prioritize a line-of-business application, complete the following tasks:

Create and link a Group Policy Object (GPO) with a QoS policy.

Configure the routers to differentially treat a line-of-business application (by using queuing) based on the selected DSCP values. The procedures of this task will vary depending upon the type of routers you have.

Many enterprise applications are developed for and hosted on Internet Information Services (IIS) web servers. Typically, the application is accessed from browsers on client computers. For these deployments, IT departments can benefit from prioritizing the network traffic that is associated with web-based applications. In Windows Server 2012, Windows 8, Windows 7, and Windows Server 2008 R2, Policy-based QoS provides a new feature, known as URL-based Policies, that enables administrators to place HTTP responses—to applications that are built on top of HTTP—subject to QoS control.

In this scenario, assume that you manage a set of IIS servers that host training videos for all your organization’s employees. Your objective is to ensure that the traffic from these video servers won’t overwhelm your network, and ensure that video traffic is differentiated from voice and data traffic on the network. The task is similar to the task in Scenario 1. You will design and configure the traffic management settings, such as the DSCP value for the video traffic, and the throttling rate the same as you would for the line-of-business applications. Only when specifying the traffic, instead of providing the application name, you need only to enter the URL to which your HTTP server application will respond: for example, https://hrweb/training.

All the following URLs are valid and can be specified in Policy-based QoS and applied simultaneously to a computer or a user:

http://video

https://training.hr.mycompany.com

http://10.1.10.249:8080/tech

https://*/ebooks

But which one will receive precedence? The rules are simple. URL-based policies are prioritized in a left-to-right reading order. So, from the highest priority to the lowest priority, the URL fields are:

A Quintuple policy is specified by protocol ID, source IP address, source port, destination IP address, and destination port. A Quintuple policy always has a higher precedence than any URL-based policy. If a Quintuple policy is already applied for a user, a new URL-based policy will not cause conflicts on any of that user’s client computers.

Based on the previous line-of-business application example, you can see that QoS for networks is an industry-wide set of standards and mechanisms for ensuring high-quality performance for mission-critical applications. By using QoS mechanisms, network administrators can use existing resources efficiently and ensure the required level of service without reactively expanding or over-provisioning their networks.

In Windows operating systems, Policy-based QoS combines the functionality of standards-based QoS with the manageability of Group Policy. Configuration of this combination makes for easy application of QoS policies to Group Policy Objects. Windows includes a Policy-based QoS Wizard to help you:

As noted in the previous line-of-business application example, you can define the priority of outbound network traffic by using Specify DSCP Value to configure a QoS policy with a specific DSCP value. As described in RFC 2474, DSCP allows values from 0 to 63 to be specified within the TOS field of an IPv4 packet and within the Traffic Class field in IPv6. Network routers use the DSCP value to classify network packets and to queue them appropriately.

Note

By default, Windows traffic has a DSCP value of 0.

The number of queues and their prioritization behavior needs to be designed as part of your organization's QoS strategy. For example, your organization may choose to have five queues: latency-sensitive traffic, control traffic, business-critical traffic, best-effort traffic, and bulk-data-transfer traffic.

Along with DSCP values, throttling is another key control for managing network bandwidth. As mentioned earlier, you can use the Specify Throttle Rate setting to configure a QoS policy with a specific throttle rate for outbound traffic. By using throttling, a QoS policy limits the outgoing network traffic to a specified throttle rate. Both DSCP marking and throttling can be used together to manage traffic effectively.

Note

By default, the Specify Throttle Rate check box is not selected.

To create a QoS policy, edit the settings of a Group Policy Object (GPO) from within the Group Policy Management Console (GPMC) tool. GPMC then opens the Group Policy Object Editor.

QoS policy names must be unique. How policies are applied to servers and end users depends on where the QoS policy is stored in the Group Policy Object Editor:

A QoS policy in Computer Configuration\Windows Settings\Policy-based QoS applies to computers, regardless of the user that is currently logged on. You typically use computer-based QoS policies for server computers.

A QoS policy in User Configuration\Windows Settings\Policy-based QoS applies to users after they have logged on, regardless of which computer they have logged on to.

In Policy name, type a name for the QoS policy. The name must uniquely identify the policy.

Optionally, use Specify DSCP Value to enable DSCP marking, and then configure a DSCP value between 0 and 63.

Optionally, use Specify Throttle Rate to enable traffic throttling and configure the throttle rate. The throttle rate value must be greater than 1 and you can specify units of kilobytes per second (KBps) or megabytes per second (MBps).

In the second page of the Policy-based QoS wizard you can apply the policy to all applications, to a specific application as identified by its executable name, to a path and application name, or to the HTTP server applications that handle requests for a specific URL.

All applications specifies that the traffic management settings on the first page of the Policy-based QoS wizard apply to all applications.

Only applications with this executable name specifies that the traffic management settings on the first page of the Policy-based QoS wizard are for a specific application. The executable file name and must end with the .exe file name extension.

Only HTTP server applications responding to requests for this URL specifies that the traffic management settings on the first page of the Policy-based QoS wizard apply to certain HTTP server applications only.

Optionally, you can enter the application path. To specify an application path, include the path with the application name. The path can include environment variables. For example, %ProgramFiles%\My Application Path\MyApp.exe, or c:\program files\my application path\myapp.exe.

Note

The application path cannot include a path that resolves to a symbolic link.

The URL must conform to RFC 1738 (http://tools.ietf.org/html/rfc1738), that is, in the form of “http[s]://<hostname>:<port>/<url-path>”. You can use a wildcard, ‘*’, for <hostname> and/or <port>, e.g. http://training.*/, https://*.*, but the wildcard cannot denote a substring of <hostname> or <port>.

In other words, neither http://my*site/ nor https://*training*/ is valid. Optionally, you can check Include subdirectories and files to perform matching on all subdirectories and files following a URL. For example, if this option is checked and the URL is “http://training”, Policy-based QoS will consider requests for “http://training/video” a good match.

In the third page of the Policy-based QoS wizard you can specify IP address conditions for the QoS policy, including the following:

All source IPv4 or IPv6 addresses or specific source IPv4 or IPv6 addresses

All destination IPv4 or IPv6 addresses or specific destination IPv4 or IPv6 addresses

If you select Only for the following source IP address or Only for the following destination IP address, you must type one of the following:

An IPv4 address, such as 192.168.1.1

An IPv4 address prefix using network prefix length notation, such as 192.168.1.0/24

An IPv6 address, such as 3ffe:ffff::1

An IPv6 address prefix, such as 3ffe:ffff::/48

If you select both Only for the following source IP address and Only for the following destination IP address, both addresses or address prefixes must be either IPv4- or IPv6-based.

If you specified the URL for HTTP server applications in the previous wizard page, you’ll notice that the source IP address for the QoS policy on this wizard page is grayed out. That’s because the source IP address is the HTTP server address and it is not configurable here. On the other hand, you can still customize the policy by specifying the destination IP address. This makes it possible for you to create different policies for different clients by using the same HTTP server applications.

In Select the protocol this QoS policy applies to, select TCP, UDP, or TCP and UDP.

In Specify the source port number, select From any source port or From this source port number.

If you selected From this source port number, type a port number between 1 and 65535.

Optionally, you can specify a port range, in the format of "Low:High," where Low and High represent the lower bounds and upper bounds of the port range, inclusively. Low and High each must be a number between 1 and 65535. No space is allowed between the colon (:) character and the numbers.

In Specify the destination port number, select To any destination port or To this destination port number.

If you selected To this destination port number in the previous step, type a port number between 1 and 65535.

To complete the creation of the new QoS policy, click Finish on the Protocols and Ports page of the Policy-based QoS wizard. When completed, the new QoS policy is listed in the details pane of the Group Policy Object Editor.

To apply the QoS policy settings to users or computers, link the GPO in which the QoS policies are located to an Active Directory Domain Services container, such as a domain, a site, or an organizational unit (OU).

After you have applied a number of QoS policies across your organization, it may be useful or necessary to periodically review how the policies are applied. A summary of the QoS policies for a specific user or computer can be viewed by using GPMC reporting.

In GPMC, right-click the Group Policy Results node, and then select the menu option for Group Policy Results Wizard.

After Group Policy results are generated, click the Settings tab. On the Settings tab, the QoS policies can be found under the "Computer Configuration\Windows Settings\Policy-based QoS" and "User Configuration\Windows Settings\Policy-based QoS" nodes.

On the Settings tab, the QoS policies are listed by their QoS policy names with their DSCP value, throttle rate, policy conditions, and winning GPO listed in the same row..

The Group Policy results view uniquely identifies the winning GPO. When multiple GPOs have QoS policies with the same QoS policy name, the GPO with the highest GPO precedence is applied. This is the winning GPO. Conflicting QoS policies (identified by policy name) that are attached to a lower priority GPO are not applied. Note the GPO priorities define which QoS policies are deployed in the site, domain, or OU, as appropriate. After deployment, at a user or computer level, the QoS Policy Precedence Rules determine which traffic is allowed and blocked.

The QoS policy's DSCP value, throttle rate, and policy conditions are also visible in Group Policy Object Editor (GPOE)

With Policy-based QoS, the goal is to manage traffic on an enterprise's network. In mobile scenarios, users might be sending traffic on or off the enterprise network. Because QoS policies are not relevant while away from the enterprise's network, QoS policies are enabled only on network interfaces that are connected to the enterprise for Windows 8, Windows 7, or Windows Vista.

For example, a user might connect her portable computer to her enterprise's network via virtual private network (VPN) from a coffee shop. For VPN, the physical network interface (such as wireless) will not have QoS policies applied. However, the VPN interface will have QoS policies applied because it connects to the enterprise. If the user later enters another enterprise's network that does not have an AD DS trust relationship, QoS policies will not be enabled.

Note that these mobile scenarios do not apply to server workloads. For example, a server with multiple network adapters might sit on the edge of an enterprise's network. The IT department might choose to have QoS policies throttle traffic that egresses the enterprise; however, this network adapter that sends this egress traffic does not necessarily connect back to the enterprise network. For this reason, QoS policies are always enabled on all network interfaces of a computer running Windows Server 2012.

Note

Selective enablement only applies to QoS policies and not to the Advanced QoS settings discussed next in this document.

Advanced QoS settings provide additional controls for IT administrators to manage computer network consumption and DSCP markings. Advanced QoS settings apply only at the computer level, whereas QoS policies can be applied at both the computer and user levels.

DSCP Marking Override restricts the ability of applications to specify—or "mark"—DSCP values other than those specified in QoS policies. By specifying that applications are allowed to set DSCP values, applications can set non-zero DSCP values. By specifying Ignore, applications that use QoS APIs will have their DSCP values set to zero, and only QoS policies can set DSCP values. By default, computers running Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows Server 2008, and Windows Vista and allow applications to specify DSCP values; applications and devices that do not use the QoS APIs are not overridden.

The Wi-Fi Alliance has established a certification for Wireless Multimedia (WMM) that defines four access categories (WMM_AC) for prioritizing network traffic transmitted on a Wi-Fi wireless network. The access categories include (in order of highest-to-lowest priority): voice, video, best effort, and background; respectively abbreviated as VO, VI, BE, and BK. The WMM specification defines which DSCP values correspond with each of the four access categories:

DSCP Value

WMM Access Category

48-63

Voice (VO)

32-47

Video (VI)

24-31, 0-7

Best effort (BE)

8-23

Background (BK)

In Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows Server 2008, and Windows Vista QoS policies can be created that use these DSCP values to ensure that portable computers with Wi-Fi Certified™ for WMM wireless adapters receive prioritized handling when associated with Wi-Fi Certified for WMM access points.

Similar to GPO's priorities, QoS policies have precedence rules to resolve conflicts when multiple QoS policies apply to a specific set of traffic. For outbound TCP or UDP traffic, only one QoS policy can be applied at a time, which means that QoS policies do not have a cumulative effect, such as where throttle rates would be summed.

In general, the QoS policy with the most matching conditions wins. When multiple QoS policies apply, the rules fall into three categories: user-level versus computer-level; application versus the network quintuple; and among the network quintuple.

This rule greatly facilitates network administrators’ management of QoS GPOs, particularly for user group–based policies. For example, if the network admin wants to define a QoS policy for a user group, they can just create and distribute a GPO to that group. They don’t have to worry about which computers those users are logged on to and whether those computers will have conflicting QoS policies defined, because, if a conflict exists, the user-level policy always takes precedence.

Note

A user-level QoS policy is only applicable to traffic that is generated by that user. Other users of a specific computer, and the computer itself, will not be subject to any QoS policies that are defined for that user.

Application specificity and taking precedence over network quintuple

When multiple QoS policies match the specific traffic, the more specific policy is applied. Among policies that identify applications, a policy that includes the sending application's file path is considered more specific than another policy that only identifies the application name (no path). If multiple policies with applications still apply, the precedence rules use the network quintuple to find the best match.

Alternatively, multiple QoS policies might apply to the same traffic by specifying non-overlapping conditions. Between the conditions of applications and the network quintuple, the policy that specifies the application is considered more specific and is applied. For example, policy_A only specifies an application name (app.exe), and policy_B specifies the destination IP address 192.168.1.0/24. When these QoS policies conflict (app.exe sends traffic to an IP address within the range of 192.168.4.0/24), policy_A gets applied.

However, QoS policies might have an equal number of conditions. For example, several policies may each specify only one (but not the same) piece of the network quintuple. Among the network quintuple, the following order is from higher to lower precedence:

Source IP address

Destination IP address

Source port

Destination port

Protocol (TCP or UDP)

Within a specific condition, such as IP address, a more specific IP address is treated with higher precedence; for example, an IP address 192.168.4.1 is more specific than 192.168.4.0/24.

Note

Generally your QoS policies should be designed as specifically as possible to simplify your organization's understanding of which policies are in effect.

If multiple policies apply, the more specific QoS policy takes precedence. For example, a policy that states a host address (192.168.4.12) gets applied instead of a network address (192.168.0.0/16). If a computer-level and user-level policy have the same specificity, the user-level QoS policy is applied instead of the computer-level QoS policy.