The goal of Quality of Service (QoS) is to provide preferential treatment to certain subsets of data, enabling that data to traverse the traditionally best-effort Internet or intranet with higher quality transmission.
By using QoS you can:
- Specify or request bandwidth requirements particular to their application, such as latency requirements for streaming audio.
- Give applications their required bandwidth — provided bandwidth availability exist.
- Control network device resources based on user policy and/or application usage.
- Reserve portions of a given bandwidth for applications or users that require such availability for core business activities.
- Shape and smooth the traffic that clients submit to the network, thereby avoiding the overburdening of switches and routers suffered with traditional burst transmissions.
QoS History in Windows
Windows 2000 introduced the Generic QOS (GQOS) application programming interface (API) as a framework for QOS. The GQOS API provided access to QOS mechanisms that were available as part of the networking stack. Windows 2000 also provided tools, such as Subnet Bandwidth Manager (SBM) and QOS policy control.
In Windows XP, the focus was on prioritization and traffic shaping mechanisms. Although GQOS continued to be the application interface for accessing prioritized QOS, the reservation mechanisms had been removed. The kernel component that implemented prioritization and traffic shaping was the QOS Packet Scheduler, called the Traffic Control (TC) API. The TC API provided control of QOS mechanisms (such as prioritization and shaping) at the host level rather than at the application level, but it required administrative privileges to be invoked. The QOS mechanisms provided in Windows XP supported enterprise QOS needs for wired networks. In Windows XP Service Pack 2 (SP2), the GQOS mechanisms allowed the application to set Layer 3 priorities only. Applications that set Layer 2 priorities for their traffic had to implement an independent service with administrative privileges to set Layer 2 priorities using TC APIs.
In Windows Vista, two features were introduced: Quality Windows Audio Video Experience (qWAVE) and policy-based QOS. qWAVE is designed to estimate the network bandwidth, intelligently mark the application packets (with proper DSCP values), and interact with the application in the event of network congestion or bandwidth fluctuations (informing the application to take appropriate actions). Policy-based QOS allows IT administrators to apply QOS to applications (which do not need to have native support for QOS), computers, and users in their enterprise network.
In Windows 7, enhancements were made to allow policies to be created based on the URL of an HTTP server (rather than just on an application name), source and/or destination IP addresses, source and/or destination ports, and protocol).
Using PowerShell to manage QoS
With the following cmdlets you can manage your QoS.
Get-NetQosPolicy Retrieves network Quality of Service (QoS) policies. New-NetQosPolicy Creates a new network QoS policy. Set-NetQosPolicy Updates the QoS policy settings. Remove-NetQosPolicy Removes a network Quality of Service (QoS) policy.
Lets get started:
As usual step 1 is to know from where you are starting. So we are going to check if some NetQosPolicy is already defined. Open PowerShell with administrative priviledges.
The Get-NetQosPolicy cmdlet allows you to retrieve Quality of Service (QoS) policies from a computer.
QoS policies can originate from many sources, such as from the administrator of a local computer, from a domain controller, or from applications that use the QoS Windows Management Instrumentation (WMI) APIs. Therefore, the QoS policies are stored in different locations. If the location as provided by the PolicyStore parameter is not specified, then this cmdlet retrieves all the policies stored on the local computer (localhost).
ActiveStore is a special location. If ActiveStore is specified as the location, the user will see all the effective QoS policies, regardless of where the QoS policies are stored.
This command gets a list of QoS policies currently effective on the computer:
Get-NetQosPolicy -PolicyStore "ActiveStore"
This command gets all of the properties of a specific QoS policy.
Get-NetQosPolicy -Name "YOUR POLICY HERE" | Format-List -Property *
The New-NetQosPolicy cmdlet creates a new network Quality of Service (QoS) policy. A QoS policy consists of two main parts: match conditions also known as filters, and actions. If the PolicyStore parameter is not specified, then the new policy is added to local computer (localhost). If a policy is stored in ActiveStore, then the policy will not persist after reboot.
This command creates a QoS policy named FTP that matches an application path at ftp.exe and throttles the traffic at 1,000,000 bits per second.
New-NetQosPolicy -Name "FTP" -AppPathNameMatchCondition "ftp.exe" -ThrottleRateActionBitsPerSecond 1MB -PolicyStore ActiveStore
This command creates a QoS policy named SMB Policy that classifies SMB traffic and tags it with 802.1p priority value of 1. The SMB parameter is a built-in filter
New-NetQosPolicy -Name "SMB Policy" -SMB -PriorityValue8021Action 1
This command creates a QoS policy named Backup that matches traffic sent to 10.1.1.176/28 subnet and tags it with DSCP value of 40. This policy is effective only on traffic sent on a domain-joined network adapter.
New-NetQosPolicy -Name "Backup" -IPDstPrefixMatchCondition "192.168.1.170/28" -NetworkProfile Domain -DSCPAction 40
You can also use a single IP as a IPDstPrefixMatchCondition and the NetworkProfile can be: Domain, Public, Private, or All.
The Set-NetQosPolicy cmdlet modifies an existing Quality of Service (QoS) policy. You need to specify the existing name to change values in this policy.
This command updates the QoS policy named SMB Policy so that it only applies to traffic that is outgoing from a domain-joined network adapter.
Set-NetQosPolicy -Name "SMB Policy" -NetworkProfile Domain
The Remove-NetQosPolicy cmdlet removes the network Quality of Service (QoS) policies. All the policies, in a policy store, are removed unless a specific policy is named.
This example removes a policy named as Backup.
Remove-NetQosPolicy -Name "Backup"
This example removes all the policies from the ActiveStore.
Remove-NetQosPolicy -PolicyStore ActiveStore
With this information you can get into shape… 😉
Differentiated Services and DSCP
Diffserv (Differentiated Services) is a protocol that defines traffic prioritization at Layer 3 of the OSI model. Layer 3 network devices, such as routers, that support this protocol use Diffserv markings to identify the forwarding treatment, or per-hop behavior (PHB), that marked traffic is to receive. Diffserv markings for a packet are placed in the IP header.
RFC 2475 defines the architecture for Diffserv. RFC 2474 defines the bits in the Diffserv field.
RFC 2474 redefines the IPv4 TOS octet as 6 bits for the Diffserv value, also known as Diffserv code point or DSCP, followed by 2 unused bits.
DSCP values are backward-compatible with IP precedence values, which means that legacy routers that support only IP precedence can interpret DSCP values. Valid values are 0-63.
Common values sorted from low to high are: 0,8,16,24,32,40,48,56
IEEE 802.1p Priority Levels
IEEE 802.1p defines a 3-bit field called the Priority Code Point (PCP) within an IEEE 802.1Q tag. The PCP value defines 8 priority levels, with 7 the highest priority and 1 the lowest priority. The priority level of 0 is the default. Each priority level defines a class of service that identifies separate traffic classes of transmitted packets.
Specifies the location of the policy that is stored. The acceptable values for this parameter are: