How QoS Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How QoS Works

In this section

• Traffic Control Overview

• Windows Server 2003 QoS Architecture

• QoS Protocols

• QoS Interfaces

• QoS Example

• QoS for Slow Links

• Related Information

The recent rapid growth in the number of bandwidth-intensive and time-sensitive applications, such as IP telephony, video conferencing, and other multimedia applications, often puts a strain on networks and keeps network administrators busy balancing capacity and performance. Windows Server 2003 Quality of Service (QoS) is a group of components that can differentiate traffic flows so that higher-priority traffic receives preferential treatment. Network administrators can use QoS to efficiently manage their resources and to ensure that high-priority applications receive preferential treatment without adversely affecting the performance of more typical network traffic. Various network technologies support QoS, but the focus of this document is on QoS for IP-based networks.

Implementing QoS involves combining a set of technologies defined by the Internet Engineering Task Force (IETF) and the Institute of Electrical and Electronic Engineers (IEEE). These technologies are designed to alleviate the problems caused by shared network resources and finite bandwidth. Although the concept of QoS encompasses a variety of standards and mechanisms, QoS for Windows Server 2003 IP-based networks is centered on traffic control, which includes mechanisms for prioritization and traffic shaping (the smoothing of traffic bursts).

QoS can be used in any network environment in which bandwidth, latency, jitter, and data loss must be controlled for mission-critical software, such as Enterprise Resource Planning (ERP) applications, or for latency-sensitive software, such as video conferencing, IP telephony, or other multimedia applications. QoS also can be used to improve the throughput of traffic that crosses a slow link, such as a dial-up connection.

All the network elements along the path that prioritized traffic takes must support QoS. Such network elements include the sending and receiving hosts, Layer 2 (Data Link layer) network devices (bridges and switches), and Layer 3 (Network layer) network devices (routers), including routers used for wide area network (WAN) links. If a network device along this path does not support QoS, the traffic flow receives the standard first-come, first-served treatment on that network segment.

This section describes how traffic control in Windows Server 2003 works. It covers the following:

• Overview of traffic prioritization and shaping.

• Description of Windows Server 2003 traffic control components.

• Description of the protocols used for Layer 2 and Layer 3 packet marking.

• Overview of the application programming interfaces (APIs) that invoke QoS mechanisms.

• Example of how prioritized traffic traverses a network.

• Description of QoS support for slow links.

Traffic Control Overview

Applications generate traffic at varying rates and typically require the network to carry traffic at the rate it is generated. Some applications are more tolerant than others of delays, variation in transmission rate, and data loss. Based on characteristics such as these, network traffic can fall into one of the following two types:

Elastic traffic

Elastic traffic adapts easily to changing network conditions. Delivery of elastic traffic is slow when bandwidth is limited and faster when bandwidth is abundant. Elastic traffic is usually generated by transaction-oriented applications, such as bulk data transfers.

Real-time traffic

Real-time traffic is limited in its ability to adapt to changing network conditions and delays can significantly reduce intelligibility and usefulness. Real-time traffic is generated primarily by real-time applications, such as video conferencing, that require dedicated bandwidth.

These two types of traffic have different delivery requirements. Traffic control provides the means for differentiating these types of traffic so that their delivery requirements can be met.

Traffic Control Mechanisms

Traffic control is a collection of mechanisms that segregate traffic into the appropriate service types and regulate its delivery to the network. Traffic control involves classifying, shaping, scheduling, and marking traffic.

Classifying Traffic

Duringclassification, packets are separated into distinct data flows and then directed to the appropriate queue on the forwarding interface. Queues are based on service type. The algorithm that services a queue determines the rate at which traffic is forwarded from the queue.

Traffic control in Windows Server 2003 supports the following service types:

Best effort

Best-effort is the standard service level in many IP-based networks. It is a connectionless model of delivery that provides no guarantees for reliability, delay, or other performance characteristics.

Controlled load

Controlled load data flows are treated similarly to best-effort data flows in unloaded (uncongested) conditions. This means that a very high percentage of transmitted packets will be delivered successfully to the receiving end node and a very high percentage of packets will not exceed the minimum delay in delivery. Controlled load service provides high quality delivery without guaranteeing minimum latency. For more information about controlled load service types, see the IETF-defined Request for Comment (RFC) 2211 in the IETF RFC Database.

Guaranteed service

Guaranteed service provides high-quality delivery with guaranteed minimum latency. The impact of guaranteed traffic on the network is heavy, so guaranteed service is typically used only for traffic that does not adapt easily to change. For more information about guaranteed service types, see RFC 2212 in the IETF RFC Database.

Network control

Network control, the highest service level, is designed for network management traffic.

Qualitative service

Qualitative service is designed for applications that require prioritized traffic handling but cannot quantify their QoS traffic requirements. These applications typically send traffic that is intermittent or burst-like in nature. For this service type, the network determines how the data flow is treated.

Shaping and Scheduling Traffic

During traffic shaping, the bursts in traffic are smoothed over time to create an even data flow. Traffic can be shaped only when it is transmitted, not when it is received.

During scheduling, a QoS component, the QoS Packet Scheduler, negotiates simultaneous requests for network access and determines which queue receives priority.

Marking Traffic

Markingmeans specifying a priority level in a packet header. Marking can be performed at Layer 2 of the Open Systems Interconnection (OSI) model (in a tag appended to the media access control [MAC] header) by using 802.1p priorities or at Layer 3 (in the IP header) by using Differentiated Services (Diffserv) priorities, as described later in this document. The priority level maps to the service type a packet is to receive from network devices.

Invoking Traffic Control

In Windows 2000, applications use the Generic QoS (GQoS) API to apply QoS parameters to traffic generated by the application. Applications that use the GQoS API are said to be QoS-aware. In Windows Server 2003, applications can still call the GQoS API to prioritize traffic, but resource reservation is no longer supported.

A lower-level API, the Traffic Control (TC) API, provides prioritization and traffic shaping support at the host level rather than at the application level. Network administrators can use traffic management tools that call the TC API to apply QoS parameters on behalf of an application that is not QoS-aware.

Windows Server 2003 QoS Architecture

Traffic control in Windows Server 2003 consists of the TC API, the Generic Packet Classifier (GPC), and the QoS Packet Scheduler. The following diagram illustrates how the traffic control components fit together in Windows Server 2003.

Traffic Control Architecture

In this diagram, the host computer is running a non-QoS-aware application that is generating traffic. The network administrator uses a traffic management program that calls the TC API to apply QoS parameters to the traffic. Traffic control on the sending host classifies, schedules, and marks the packets to accommodate the QoS service type specified by the traffic management program.

The Generic Packet Classifier classifies packets by service type; the QoS Packet Scheduler schedules the packets, marks them with the appropriate priority, and then sends the prioritized traffic to the network media.

Traffic Control API

Traffic control uses standardized QoS parameters to segment packets into sequences and to regulate the sequences. The Traffic Control (TC) API (Traffic.dll) applies the QoS parameters to the appropriate packets. Developers and network administrators use the TC API to specify the traffic that is to receive preferential treatment, the traffic that is to be treated alike, and the QoS parameters that define the preferential treatment. Traffic control uses the following specifications to define traffic:

• A flowspec, which is the list of QoS parameters such as service type and token rate (the permitted transmission rate of packets) that applies to a sequence of packets. A flowspec defines the preferential treatment.

• A flow, which is the sequence of packets that is subject to a flowspec. All of the packets in a flow receive the same treatment.

• A filterspec, which is the list of attributes, including source IP address, destination IP address, and port number, that classifies packets into a single flow.

Using the filterspec and flowspec, traffic control filters packets into the appropriate flow and applies the appropriate QoS parameters to the flow. QoS-aware devices, such as switches and routers, use the filterspec to determine how to handle packets.

Generic Packet Classifier

The Generic Packet Classifier (Msgpc.sys) classifies packets generated by an application so that the packets can subsequently be prioritized for sending across the network.

When an application or traffic management program invokes QoS, the Generic Packet Classifier on the sending host determines the service type (defined by the flowspec) to which each individual packet belongs and maps each packet to a queue (flow) based on the service type. After packets are assigned to a queue, the QoS Packet Scheduler can manage the queue in accordance with the QoS parameters specified in the flowspec.

Note

• In Windows Server 2003, unlike Windows 2000, the GQoS API directly calls the Generic Packet Classifier. In Windows 2000, the GQoS API calls the QoS RSVP Service Provider, which is not supported in Windows Server 2003.

QoS Packet Scheduler

The QoS Packet Scheduler (Psched.sys) is a kernel-level component that marks and schedules packets that the Generic Packet Classifier has assigned into queues. The QoS Packet Scheduler enforces QoS parameters for a given flow to achieve traffic shaping.

The QoS Packet Scheduler retrieves packets from the queues and marks them with a priority and rate of flow. The rate of flow is used to pace the transmission of packets to the network, thus mitigating the inherent “send it all right now” nature of IP transmissions. The priority is used to determine the order in which packets are submitted to the network during periods of congestion, thus spreading bursts of traffic over time and creating a more uniform traffic flow.

Using the priority and rate of flow, the QoS Packet Scheduler determines the delivery schedule for each queue and negotiates competition between any queued packets that simultaneously request access to the network.

To ensure preferential treatment throughout the network, packets must be marked so that network devices along the path can detect the priority and handle the packets appropriately. Packets are marked with an 802.1p priority for prioritization by Layer 2 devices and with a Diffserv priority for prioritization by Layer 3 devices. The QoS Packet Scheduler provides 802.1p marking. TCP/IP provides Diffserv marking.

The QoS Packet Scheduler is not automatically installed with Windows Server 2003. You install this component on any host on which you want to perform traffic marking or shaping. Use Network Connections to display the properties for the connection where you want to install the QoS Packet Scheduler; install the QoS Packet Scheduler as a new service.

Note

• To use the QoS Packet Scheduler for 802.1p (Layer 2) marking, the network adapter must support 802.1p. On the Advanced tab for the properties of the network adapter (available through Network Connections or Device Manager), you must select the option to enable 802.1p support.

QoS Protocols

Windows Server 2003 supports both 802.1p (Layer 2) and Diffserv (Layer 3) priority marking. Network devices that support these protocols use the markings to provide end-to-end preferential treatment.

802.1p

The IEEE 802.1p signaling standard defines traffic prioritization at Layer 2 of the OSI model. Layer 2 network devices, such as switches, that adhere to this standard can group incoming packets into separate traffic classes.

The 802.1p standard is used to prioritize packets as they traverse a network segment (subnet). When a subnet becomes congested, causing a Layer 2 network device to drop packets, the packets marked for higher priority receive preferential treatment and are serviced before packets with lower priorities.

The 802.1p priority markings for a packet are appended to the MAC header. In Windows Server 2003, the QoS Packet Scheduler performs 802.1p marking.

On Ethernet networks, 802.1p priority markings are carried in Virtual Local Area Network (VLAN) tags. The IEEE 802.1q standard defines VLANs and VLAN tags. This standard specifies a 3-bit field for priority in the VLAN tag, but it does not define the values for the field. The 802.1p standard defines the values for the priority field. This standard defines eight priority classes (0 - 7). Network administrators can determine the actual mappings, but the standard makes general recommendations.

The VLAN tag is placed inside the Ethernet header, between the source address and either the Length field (for an IEEE 802.3 frame) or the EtherType field (for an Ethernet II frame) in the MAC header. The 802.1p marking determines the service level that a packet receives when it crosses an 802.1p-enabled network segment.

The following diagram illustrates the location of an 802.1p priority within a VLAN tag.

Structure of a VLAN Tag

Layer 2 priority values are defined by Group Policy. Windows Server 2003 provides a default priority value for each service type on a host. Sophisticated switches, however, might direct hosts or routers to use different mappings. The QoS Packet Scheduler in Windows Server 2003 uses the default priority values listed in the following table.

Default Priority Values for Service Types

1 This service type is applied to packets that do not conform to the flowspec.

These default values can be modified by applying a Computer Configuration Group Policy setting for the host at Administrative Templates\Network\QoS Packet Scheduler\Layer-2 priority value. These Group Policy settings create corresponding registry subkeys and values at HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Psched\UserPriorityMapping.

Implementing 802.1p marking on a host requires the following:

• The network adapter and device driver support 802.1p.

• The option to enable 802.1p support is selected.

• The service types are enabled with Group Policy.

• For a customized priority value, the default priority value has been changed with a Group Policy setting.

Differentiated Services

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. In Windows Server 2003, TCP/IP performs Diffserv marking.

RFC 2475 defines the architecture for Diffserv. RFC 2474 defines the bits in the Diffserv field. The Type of Service (TOS) field in Internet Protocol version 4 (IPv4) headers and the Traffic Class field in Internet Protocol version 6 (IPv6) headers are redefined for Diffserv values.

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. The following figure illustrates how Diffserv redefines the TOS field.

Diffserv Redefinition of TOS Field

The first 3 bits of the TOS field were formerly used for IP precedence, which indicated the importance of a packet. DSCP values are backward-compatible with IP precedence values, which means that legacy routers that support only IP precedence can interpret DSCP values.

As with Layer 2 prioritization, DSCP values are defined by Group Policy. Windows Server 2003 provides a default DSCP value for each service type on a host, but some Layer 3 network devices can direct hosts to use different values. Windows Server 2003 uses the default DSCP values listed in the following table.

Default DSCP Values for Service Types for Conforming Packets

Packets that do not conform to the flowspec have a default priority of 0.

These defaults can be modified by applying a Computer Configuration Group Policy setting for the host at Administrative Templates\Network\QoS Packet Scheduler\. The DSCP value of conforming packets subcategory supports settings for packets that conform to the flowspec. These Group Policy settings create corresponding registry subkeys and values at HKLM\Software\Policies\Microsoft\Windows\Psched\DiffservByteMappingConforming. The DSCP value of non-conforming packets subcategory supports settings for packets that do not conform to the flowspec. These Group Policy settings create corresponding registry subkeys and values at HKLM\Software\Policies\Microsoft\Windows\Psched\DiffservByteMappingNonConforming.

Diffserv differs from 802.1p prioritization in that Layer 3 devices can aggregate flows. Routers, therefore, need to distinguish a comparatively small number of aggregated flows instead of the thousands or millions of individual flows that compose them, and can provide better service to the packets that have higher priority.

QoS Interfaces

Windows Server 2003 provides two application programming interfaces (APIs) for assigning QoS parameters to traffic. Application developers use the GQoS API to apply QoS parameters at the application level. Network administrators use traffic management tools that call the TC API to apply QoS parameters at the host level.

Generic QoS API

In Windows 2000, the GQoS API was the foundation for QoS. It provided access to several QoS mechanisms, including resource reservation mechanisms and traffic control mechanisms. In Windows XP and Windows Server 2003, the GQoS API still provides access to traffic control mechanisms, but it no longer supports resource reservation. Existing calls to invoke resource reservations are still supported, but they are treated differently: a traffic flow is immediately created locally without a reservation request and the traffic from the application is marked and scheduled as though a reservation had been requested successfully.

GQoS is part of Windows Sockets 2.0 (Winsock2). Most applications use the GQoS API to invoke the QoS capabilities in Windows. For more information about the GQoS API, see “QoS API” on MSDN.

Traffic Control API

The TC API provides access to traffic control mechanisms that regulate network traffic on the local host. These components regulate traffic within the kernel of the local host and, through prioritization and scheduling, across the network.

QoS-aware applications (those that call the GQoS API) invoke the TC API indirectly. Network administrators can use traffic management programs to invoke this API directly on behalf of applications that are not QoS-aware. A lower-level API than the GQoS API, the TC API requires administrative privileges.

Unlike the GQoS API, the TC API allows traffic from a number of sources (on the same sending host) to be aggregated into a single traffic control flow. For example, all of the traffic to a specific destination IP address can be included in a single flow, regardless of the source port and destination port. The GQoS API, on the other hand, allows only traffic from a single conversation, which is defined by source and destination IP addresses, source and destination ports, and protocol (Transmission Control Protocol [TCP] or User Datagram Protocol [UDP]) to be included in a single flow.

For more information about the TC API, see “Application-Driven QoS Components” on MSDN.

QoS Example

The following diagram illustrates what happens when QoS is invoked for traffic generated by an application. In this diagram, an application running on Client A is generating traffic and sending it to Client B. In this example, the application is not QoS-aware, which means it does not use the GQoS API to specify QoS parameters. Instead, the network administrator uses a traffic management tool to define the QoS parameters for the host.

Invoking QoS on a Host

In this example, the following occurs:

1. Client A on Network A is running an application that is generating traffic. The application is not QoS-aware, so the traffic is destined for best-effort service.

2. The network administrator has used a traffic management tool (Traffic Control Monitor, for example) to define flows (the filterspec) for each interface on Client A and the QoS parameters that apply to each flow (the flowspec) for preferential treatment.

3. As the application generates traffic, the GPC (Generic Packet Classifier) on Client A classifies the traffic into queues by service type.

4. The QoS Packet Scheduler on Client A manages the queues determined by the GPC by providing preferential treatment for higher-priority traffic. The QoS Packet Scheduler takes the following actions:

   • Reduces traffic bursts by smoothing transmission peaks over a period of time (that is, shapes traffic).

   • Schedules packets for transmission.

   • Marks packets for Layer 3 and, if 802.1p is enabled for the network adapter, Layer 2 prioritization, as specified by QoS Packet Scheduler Group Policy.

   • Sends the packets to the network media.

5. When the traffic reaches the Layer 3 router, the router uses the DSCP marking in the IP header to determine how to forward it.

6. When the traffic reaches the Layer 2 switch, the switch uses the 802.1p marking in the MAC header to give the traffic preferential treatment.

QoS for Slow Links

When slow links, such as dial-up modems, are used to connect to the Internet or another remote network, the network can suffer significant performance problems. Windows Server 2003 provides QoS support for these slow links.

QoS for Internet Connection Sharing Clients

Some home or small office networks use Internet Connection Sharing (ICS) to connect to the Internet or to another network. With ICS, multiple computers on a small network can access Internet resources by using the Internet connection of the ICS host computer. In these ICS networks, typically the computers are connected to a relatively fast internal network (for example, 100 megabits per second [Mbps] Ethernet). The connection to the Internet, however, can be a slow link, such as a dial-up connection.

When an ICS client computer (one that uses the shared Internet connection provided by the ICS host computer) is on a fast network and connects to a computer on a different fast network through a slow link connection, a speed mismatch occurs. This speed mismatch can result in a significant transmission delay on ICS networks. In this situation, the TCP receive window on the ICS client computer is set to a large value based on the high speed of the local small network. The TCP receive window specifies the number of bytes remaining in a memory buffer that stores incoming data on a connection. The larger the window size, the more packets a sender can send at one time before waiting for acknowledgements and a newly advertised receive window size.

For a slow link, the ICS client sends the large value of the TCP receive window to the Internet server. When the Internet server responds to the ICS client’s request for data, it starts sending data at a slow rate. If packets are not lost, the Internet server gradually increases the sending rate until it sends almost a full window of packets at a time. This is normal TCP connection behavior.

However, the disparity between the large amount of data that the ICS client reports it can receive and the smaller amount of data that can be accommodated by the slow link can cause data to back up in a potentially large queue at the slow link. Large queues can have a negative effect on the performance of other traffic across the slow link.

To avoid such problems caused by slow links, the ICS host computer automatically sets the TCP receive window for communications across the slow link to a size that accommodates the slow link, thus overriding the ICS client computer’s default TCP receive window size. The smaller window size does not adversely affect traffic performance because it is the same size as the window that the receiving computer would use if it were connected directly to the slow link. The QoS Packet Scheduler on the ICS host computer makes this window adjustment on behalf of the ICS client computers.

QoS for Modems

Many home computers still connect to the Internet through slow, dial-up modem links with connection speeds less than 56 kilobits per second (Kbps). In spite of the speed limitation, users sometimes run several programs that access the Internet concurrently. For example, they might be browsing the Internet, downloading files, receiving e-mail, joining a chat session, or running streaming audio or video. Most programs that support these activities use TCP and open their own connections.

If the QoS Packet Scheduler is not installed on the computer, the first program that uses the slow link initially has exclusive use of the link. Exclusive use allows the program’s connection to reach a steady state, which can result in the transfer of a full TCP receive window of data. When the next program starts to transfer data, its connection is subject to the TCP slow-start algorithm that limits how much unacknowledged data can be in transit. Because data is already in transit on the first connection, the second connection takes much longer to reach a steady state and the transfer rate is slower than for the first connection.

To resolve these issues, the QoS Packet Scheduler in Windows XP and Windows Server 2003 uses a Deficit Round Robin (DRR) queue-servicing scheme for slow links. The DRR scheme allocates queues and assigns data flows to each queue. The queues are serviced in a round-robin fashion, which improves responsiveness and performance for all network communications.

The DRR scheme was available in Windows 2000 and is used automatically in Windows XP and Windows Server 2003 when the operating system detects a slow link.

Integrated Services over Slow Links

Special mechanisms are provided to perform traffic shaping on slow links, such as 28.8-kilobytes per second (KBps) modem links. On such links, large packets can occupy the link long enough to delay small audio packets that must be sent on the same link. This can cause problems with audio quality. To avoid this problem, traffic control fragments large packets at the link layer, sending only one fragment at a time. Latency-sensitive audio packets can then be inserted in between the larger packet’s fragments, thus reducing audio latency and improving audio quality.

Integrated Services over Slow Links (ISSLOW) is a queuing mechanism that is used to optimize slow (low-capacity) network interfaces by reducing latency. In particular, it is designed for interfaces that forward traffic to modem links, ISDN bearer (B) channels, and sub-T1 links.

A typical packet occupies a modem link for up to half a second. Other packets queued behind it can experience significant delays. Packets that are long enough in length to exceed the maximum tolerable delay for their QoS flow are fragmented before transmission through the link, so that high-priority packets can be inserted between the fragments of the larger packet, and meet the required QoS parameters for speedy transmission. The following figure illustrates a Point-to-Point Protocol (PPP) link using ISSLOW.

PPP Link with ISSLOW

For example, a PPP link is carrying best-effort traffic in addition to guaranteed service level flow “A.” The PPP link capacity is 100 KBps and the average latency is 100 milliseconds. The best-effort traffic is consuming the majority of the bandwidth on the link, which is starving flow “A” of the resources it requires to provide guaranteed service levels. In this example, flow “A” cannot tolerate a delay of more than 145 milliseconds. As the best-effort traffic fills the queue, packets from flow “A” arrive. The first best-effort packet (10 kilobits) is fragmented into 2-kilobit packets. The 8-kilobit packet from flow “A” is fragmented into 2-kilobit packets as well, and the flow “A” fragments are inserted between the best-effort fragments in order to meet the required latency guarantees of flow “A”.

Related Information

The following resources contain additional information that is relevant to this section.

• ATM Technical Reference

• Quality of Service on MSDN

For more information about QoS and Traffic Control, see the following RFCs in the IETF RFC Database.

• RFC 2211, “Specification of the Controlled-Load Network Element Service.”

• RFC 2212, “Specification of Guaranteed Quality of Service.”

• RFC 2474, “Definition of the Differentiated Services Field.”

• RFC 2475, “An Architecture for Differentiated Service.”