.gif) uality of Service (QoS) is an industry-wide movement whose purpose is to use network resources more efficiently by differentiating between subsets of traffic data. QoS functionality is obtained by cooperation among applications, end hosts (PCs, servers, and so on), switches, routers, and wide area network (WAN) links through which data must pass. QoS features are ubiquitous in today's Internet and corporate networks. Microsoft® Windows® 2000 extends the QoS reach even further and provides comprehensive support for QoS.
The Winsock 2 API is a common API used for network applications. Several Winsock functions have QoS parameters and, therefore, can be used to invoke QoS services from the operating system. These commands comprise a subset of the Winsock 2 API, known as the Generic QoS (GQoS) API. Existing Winsock applications need only to implement minor changes to enable GQoS. The QoS components of Windows 2000 integrate the medley of QoS mechanisms such as RSVP, DiffServ, 802.1p, IntServ, and so on. Through the single and unified GQoS API, ISVs can integrate several QoS benefits easily into their products.
This article will discuss the development process for adding GQoS support to your Winsock-based applications. Although the GQoS semantics are quite straightforward, you should be familiar with the basic QoS mechanisms and Windows 2000 QoS components and have expertise in developing Winsock applications. If you haven't yet done so, please study the white papers and other resources referenced in the links at the beginning of this article before reading ahead.
GQoS Benefits
GQoS allows a Winsock app to inform the network of its traffic requirements. How those requirements are met depends on policies established by network administrators. This means entitled users or apps can receive preferential treatment for their net traffic.
Because networks can often be saturated, QoS is extremely important to mission-critical applications such as Enterprise Resource Planning (ERP) applications and multimedia apps. The traffic profile of ERP applications cannot be quantitatively defined, but priority delivery with minimal packet loss are very important to these kinds of applications. Supplying an application identity through GQoS can allow ERP applications to receive qualitative QoS support from the network. Multimedia applications such as IP telephony and audio/video streaming applications have stringent requirements for bandwidth and latency. Such applications can utilize GQoS to request quantitative QoS support and to reserve network resources to meet their traffic profile.
Enabling GQoS
While QoS involves extensive interactions with networking devices, infrastructure software, network administrations, network policies, end hosts, and the applications running on the end hosts, the goals for Winsock programmers who are going to GQoS-enable their applications can be narrowly defined as follows:
- Add or modify Winsock calls at appropriate places with appropriate GQoS parameters to trigger Resource Reservation Protocol (RSVP) signaling. More sophisticated GQoS programs need to process FD_QOS event notifications as the result of RSVP messages.
- Once you have RSVP signaling working for your quantitative applications (applications that know their network traffic needs), you need to tune the application's sending profile, such as its buffers and sending rate, to conform to the parameters specified in the sending FLOWSPEC structure. Windows 2000 will then mark the conformant packets according to the requested service level.
- For qualitative applications (those that don't know their traffic requirements, but for which data delivery is very important), provide an application ID policy element in the ProviderSpecific field of the QualityOfService (QOS) structure. (Note that the QualityOfService structure has a typedef of QOS and will be referred to as QOS, not to be confused with the previously defined QoS or GQoS.) The network will return a proper DCLASS object (DSCP marking) or TCLASS object (802.1p marking, which requires NIC driver support) based on the application's ID policy element to allow Windows 2000 to mark the packets accordingly.
First Step
The first step in QoS-enabling your application is to make sure your application requests at least Winsock version 2.0 in its WSAStartup call. Then create QoS-capable sockets from the RSVP service provider (RSVPSP) by enumerating the available protocols using WSAEnumProtocols.
When you find a protocol that supports QoS, call WSASocket, passing a pointer to the WSAPROTOCOL_INFO structure with the XP1_QOS_SUPPORTED flag. Also be sure to set the WSA_FLAG_OVERLAPPED flag so that the socket is created in overlapped mode. In Windows 2000 all QoS sockets are required to be overlapped. (In "Whistler," code name for the next version of Windows, this flag is needed only if you are going to use overlapped operations.) The code in Figure 1 shows how to do this.
Now that you have created the QoS socket, the next step is to understand how to use the QOS and FLOWSPEC structures to specify the traffic requirements for your application.
Specifying Traffic Requirements in the QOS Structure
An application can specify the QoS parameters that define the needs for its sending and receiving traffic in the SendingFlowspec and ReceivingFlowspec structures within the QOS structure:
typedef struct _QualityOfService
{
FLOWSPEC SendingFlowspec; /* flow spec for data sending */
FLOWSPEC ReceivingFlowspec; /* flow spec for data receiving */
WSABUF ProviderSpecific; /* provider-specific stuff */
} QOS;
The WSABUF contains a pointer to a ProviderSpecific buffer that can be used by the application to supply additional QOS control objects to RSVPSP.
The FLOWSPEC structure, which contains the token bucket parameters and a service type specification, is defined as:
typedef struct _flowspec
{
int32 TokenRate; /* In Bytes/sec */
int32 TokenBucketSize; /* In Bytes */
int32 PeakBandwidth; /* In Bytes/sec */
int32 Latency; /* In microseconds */
int32 DelayVariation; /* In microseconds */
SERVICETYPE ServiceType; /* Service Type */
int32 MaxSduSize; /* In Bytes */
int32 MinimumPolicedSize; /* In Bytes */
} FLOWSPEC;
The traffic profile is specified according to the token bucket model, and is supplied through the FLOWSPEC structure. In the token bucket model, the token bucket size is the maximum bytes of data that can accumulate in the token bucket. TokenRate is the average rate data arrives from the sending application. Peak bandwidth is the rate at which data is emptied from the token bucket.
If the bucket contains sufficient credit, the application data is sent and the number of credits in the bucket is reduced by the size of the data sent out. If sufficient credits are not available, the application data will be deemed nonconformant and could be discarded or it could be demoted based on the SD_MODE in the QoS Packet Scheduler (QoS PS).
In variable-rate applications, the TokenRate is typically the average byte rate over long periods of time. In constant-rate applications, the TokenRate is equal to the PeakBandwidth. PeakBandwidth must always be greater than or equal to TokenRate. I'll discuss TokenRate in more detail in the section "Effects of TokenRate" later in this article.
The ServiceType field used in the FLOWSPEC structure indicates the application's requirement for network service quality. Common service types include SERVICETYPE_GUARANTEED, SERVICETYPE_CONTROLLEDLOAD, and SERVICETYPE_QUALITATIVE.
The guaranteed service promises to carry a certain traffic volume with a quantifiable bounded latency. The controlled load service agrees to carry a certain traffic volume to a service level that approximates what could be achieved when the network is lightly loaded. The qualitative service indicates that the application requires better than BESTEFFORT transmission, but cannot quantify its transmission requirements.
Applications that use the SERVICETYPE_QUALITATIVE service type should supply an application ID policy element. The application ID policy element enables policy servers on the network to identify the application and assign an appropriate QOS to the application request by returning a DCLASS object.
The MaxSduSize field of the FLOWSPEC structure specifies the maximum size of any data packet in this flow. Any application data packets of a size smaller than MinimumPolicedSize are treated as if they are of MinimumPolicedSize by the token bucket model. The MinimumPolicedSize field is used by the RSVPSP to adjust the real token rate to compensate for the layer-3 protocol overhead. The protocol overhead for UDP is 28 bytes, and for TCP, 40 bytes. The actual token rate signaled in an RSVP message is calculated using the following formula:
Actual_Token_Rate = (1 + Protocol_Overhead / MinimumPolicedSize) *
TokenRate
In order to achieve a realistic and effective token rate, applications are expected to set the MinimumPolicedSize equal to their average packet size. Setting a smaller value in the MinimumPolicedSize will cause more local resources to be allocated to the flow and can also lead to admission control failures.
The QOS structure can be submitted to GQoS through one of the following calls:
- WSAConnect for TCP or connected UDP clients
- WSAAccept with a conditional function for TCP servers. WSAIoctl(SIO_SET_QOS) must be called in the conditional function or after WSAAccept has returned
- WSAIoctl(SIO_SET_QOS)
- WSAJoinLeaf for multicast clients
Triggering RSVP Signaling
RSVP is a layer-3 IP protocol (protocol number 46) that provides a signaled QoS mechanism. A sending host sends a PATH message as soon as the application makes a GQoS request with the sending FLOWSPEC structure and the RSVPSP has obtained flow classification information (such as source IP address and port, and destination IP address and port) from other Winsock calls.
If the PATH message is not blocked or rejected, it eventually arrives at the receiver. If the receiving application is interested in the traffic offered by the sender, it makes the GQoS API call with a receiving FLOWSPEC structure and the receiving host responds with an RESV message. The RESV message is sent toward the sender following the reverse path of the PATH message. The resource reservation is made on the network and the sending host only when a receiver shows interest in the data by sending the RESV message.
If an application sends and receives traffic, the sending traffic and receiving traffic are considered two separate flows and the RSVP signaling message exchange for establishing reservation has to take place in both directions. In the case of multicast traffic flows, RESV messages from multiple receivers are merged whenever possible, making RSVP suitable for QoS with multicast traffic as well. The merged RESV message contains a FLOWSPEC derived from the arriving RESV messages in such a way as to satisfy all receivers' needs.
I have talked about submitting the QOS structure to GQoS in the previous section. To trigger RSVP signaling, the RSVPSP also needs to obtain the classification information for the flow (the local IP and port and the remote IP and port) through other Winsock calls. This information can be obtained in the following ways:
- For TCP and connected UDP clients to emit a PATH message, the flow classification information is implicitly provided via a connect call.
- For unconnected UDP clients to emit a PATH message, the sending application needs to issue a bind to provide the local port to the RSVPSP, and then attach a QOS_DESTADDR object to the ProviderSpecific field of the QOS structure to specify the remote IP and port to RSVPSP. I will discuss the QOS_DESTADDR object in detail later in this article.
- For receivers, the only requirement for returning the RESV message upon receiving the PATH message is that RSVPSP must get the QOS structure (with the receiving FLOWSPEC) because the arriving PATH message carries the classification information.
RSVP messages carry the following information:
- Classification information such as IP addresses, ports numbers, and protocol
- Quantitative parameters describing the traffic profile (data rate, and so on)
- Service type of the reservation being requested (ControlledLoad, Guaranteed, or Qualitative)
- Policy information (identifying the user requesting resources for the traffic and the app generating it)
Figure 2 summarizes the information required by RSVP to begin the transmission of PATH messages.
On the receiving end, when a PATH message is received, the RSVP creates an RSVP session and associates a PATH state with it. The RSVP will also create a session (in the absence of PATH messages) when QOS is indicated on any receive socket. (However, in this case, the PATH state is not associated with the session until a corresponding PATH message is received.)
The RSVP will send RESV messages when it determines that a PATH state exists for a session that matches a socket for which a receive QOS is indicated. As a result, the transmission of RESV messages may be triggered either by the receipt of a PATH message (which matches the session associated with a preexisting socket), or by the creation of a receive socket (which matches the session associated with preexisting PATH state). The information in Figure 3 is required to begin the transmission of RESV messages.
If RSVP signaling fails to reserve resources, the RSVP will keep sending RSVP messages as if the failure has not occurred and will only stop sending when the reservation is no longer required (for example, when the socket is closed or QOS is reset). Apps don't need to reissue SIO_SET_QOS on a reservation failure unless they want to request a different QoS requirement with the network.
To allow for user-based QoS policy control, the RSVPSP automatically inserts a Kerberos ticket in the user identity policy element into both PATH and RESV messages. A Kerberos-capable Policy Decision Point (PDP), such as a server running Windows 2000 that is also running the Admission Control Service (ACS) can apply admission control policy based on user identity. The Kerberos ticket can also be cracked by third-party policy servers with Kerberos clients. To allow for application identity-based policy control, an application can also provide an application identity policy element through the ProviderSpecific buffer in the FLOWSPEC structure, as demonstrated in the sample in the Qualitative directory in the download available from the link at the top of this article.
Occasionally, applications can receive RSVP error messages or even no messages at all. As the PATH message traverses the network, it will be processed at all RSVP-aware devices in the network along the data path. RSVP-aware devices could allow the PATH message to be forwarded, or they could reject the message by stopping its progress and returning a PATH-ERR message to the sender.
Certain RSVP-unaware devices (such as firewalls) may be configured to block RSVP messages without participating in the RSVP protocol at all. In this case, the PATH message would simply be dropped without generating any error messages.
If the PATH message is not blocked or rejected, it eventually arrives at the receiver. If the receiving application is interested in the traffic offered by the sender, it makes the GQoS API call and the receiving host responds with an RESV message.
The RESV message is sent toward the sender following the reverse path of the PATH message. As the RESV traverses the network, it will be processed at all RSVP-aware devices in the network through which the PATH message traversed. These devices may allow the RESV message to be forwarded, or they may alternatively reject it by blocking its progress and returning an RESV-ERR message back toward the receiver. In any case, the RESV message will return to the sender unless specific network policies deny the reservation or there is a lack of resources in intermediate devices.
Through RSVP signaling, the GQoS API has made applications network-aware and has also made networks application- and user-aware. To find out if RSVP signaling takes place, you need to use Netmon (which ships as part of Microsoft Systems Management Server and the Windows 2000 Resource Kit) to capture the traffic and verify the exchange of RSVP messages. For more RSVP troubleshooting information, please consult the book Network Quality of Service and Windows Operating Systems by Yoram Bernet (New Riders, 2000).
The Right QOS Structure for Your App
You know that the application traffic profile is described in the QOS structure. You also know the Winsock calls for submitting the QOS structure to RSVPSP and how they are mapped to RSVP parameters. So now the question is what kind of QOS structure should be used in your application?
The QOS structure is the only structure in GQoS in which the application's QoS requirement is specified. The initial SendingFlowspec and ReceivingFlowspec values in the structure should be carefully chosen based on a prior knowledge of application traffic characteristics, performance requirements, and user preferences. The receiver can adjust the ReceivingFlowspec value later based on the SENDER_TSPEC and ADSPEC from the received PATH messages in another WSAIoctl(SIO_SET_QOS) call. But in a majority of cases, the receiver can just specify the default (QOS_NOT_SPECIFIED) for everything in the FLOWSPEC structure other than ServiceType.
The RSVPSP has provided several predefined QOS structure templates for popular multimedia codecs such as G711, H263CIF, and so on. (See https://msdn.microsoft.com/library/psdk/gqos/gqosbasicops_47ub.htm for a full list of templates.) WSAGetQOSByName can be used to retrieve a predefined QOS structure based on the template name. The ProviderSpecific.len field in the QOS structure has to be set to 0 before the WSAGetQOSByName call in order for it to work. For your easy reference, the predefined templates are shown in Figure 4.
For qualitative applications, all fields in the SendingFlowspec and ReceivingFlowspec can default to QOS_NOT_SPECIFIED except the ServiceType field, which has to specify SERVICETYPE_QUALITATIVE. The MaxSduSize can be specified by the sending application if it knows the size; otherwise, the media Maximum Transmission Unit (MTU) size will be used for the MaxSduSize.
If there is traffic in only one direction, then only the ServiceType field in the FLOWSPEC structure for that direction needs to be specified with SERVICETYPE_NOTRAFFIC.
Making Your App RSVP-savvy
Most Winsock applications can add basic GQoS support by simply replacing the open socket call with one that returns a QoS-capable socket, placing WSAIoctl(SIO_SET_QOS) at the appropriate place or providing a QoS parameter in WSAConnect and WSAAccept. Adding minimal GQoS support to applications is easy, but making apps truly RSVP-savvy can be challenging.
QoS status is provided through FD_QOS events. Applications can use WSAAsyncSelect or WSAEventSelect to register for FD_QOS events to get notifications from the RSVPSP as the result of the arrival of RSVP messages. When an FD_QOS notification arrives, apps can call WSAIoctl (SIO_GET_QOS) to find out the details of the notification, which is returned via the QOS structure.
Another method for getting FD_QOS notifications is to issue an overlapped WSAIoctl(SIO_GET_QOS), and detect FD_QOS notifications using any of the overlapped I/O completion semantics such as event waits, APC completion functions, or I/O completion ports. Besides being triggered by the arrival of RSVP messages, other ways to trigger FD_QOS notifications include time-outs, internal QoS errors such as an invalid FLOWSPEC or traffic control errors.
Similar to other FD_XXX notifications, SIO_GET_QOS should only be issued once per FD_QOS notification. Figure 5 lists the mapping of the FD_QOS status codes with the RSVP messages and specifies whether it is received at the sender or at the receiver. Please consult the winsock2.h header file for a description of each WSA_QOS status code.
The status code WSA_QOS_GENERIC_ERROR is a catch-all error and is used when any of these situations occur:
- An error occurs that doesn't fall into any of the other categories
- An unrecognized error is found in a RSVP error message
- A system call error has occurred
RSVP messages are refreshed periodically to maintain the state of the flow in network devices. An FD_QOS notification will be triggered for the first PATH message and the first RESV message. Unless the QoS parameters change in the RSVP messages, no further FD_QOS notifications are delivered for the same type of RSVP messages.
The RSVP status info object, RSVP_STATUS_INFO, is used to return RSVP-specific error and status information. The structure is defined as:
typedef struct _RSVP_STATUS_INFO {
QOS_OBJECT_HDR ObjectHdr; /* Object Hdr */
ULONG StatusCode; /* Error or Status Information
/* see Winsock2.h */
ULONG ExtendedStatus1;/* Provider-specific status
/* extension */
ULONG ExtendedStatus2;/* Provider-specific status
/* extension */
} RSVP_STATUS_INFO, *LPRSVP_STATUS_INFO;
Figure 6 lists the semantics of the FD_QOS notifications. The buffer provided in these calls should be long enough to hold a QOS structure and the RSVP_STATUS_INFO object as the information returned in an FD_QOS event always contains a QOS structure and an RSVP_STATUS_INFO object. The Knowledge Base article Q246689 demonstrates the proper technique of calling WSAIoctl(SIO_GET_QOS) (https://support.microsoft.com/default.aspx?scid=kb;EN-US;q246689).
Traffic Policing and Marking
As a result of the RSVP signaling, the RSVP invokes traffic control (TC) on the flow. Figure 7 illustrates TC invocation with RSVP signaling. After a PATH message is initially sent and before an RESV message is received, the traffic is transmitted using a best-effort flow. Once the network approves the reservation after the sender has received an RESV message, RSVP invokes the traffic control API to either modify the existing flow from best-effort to control-service or guaranteed-service flow based on the RESV message.
.gif)
Figure 7 TC Invocation with RSVP Signaling
Next, the QoS Packet Scheduler (QoS PS) performs traffic policing on the sending traffic against the SendingFlowspec, does Diffserv code point (DSCP) and/or 8021.p marking on the conformant traffic according to its service type and its DCLASS object, and then submits the packets to the NIC driver to be sent on the wire. The QoS PS implements the Windows 2000 QoS traffic control elements, such as packet scheduling and marking.
Please note that the QoS PS is not installed by default on Windows 2000. You must add it from the property dialog box for your network card. On "Whistler", the QoS PS will be installed by default on the Professional and Personal versions, and must be manually added on the Server version.
The QoS PS supports the following SD modes.
Borrow mode Allows traffic on the flow to borrow resources from other flows that are temporarily idle (at the expense of being marked nonconforming and demoted in priority).
Shape mode Delays packets submitted for transmission until they conform to a specified traffic profile (specified in the FLOWSPEC structure).
Discard mode Discards packets that do not conform to a specified traffic control descriptor.
Figure 8 shows the default mapping from the requested service type to an SD mode and packet marking.
The DSCP (defined in RFC 2474) mark is the first 6-bit value in the DS field of the IP header spanning the fields formerly known as the IP precedence fields and the type-of-service (TOS) fields (RFC 791). The last two bits in the DS field are used for other purposes. For example, Windows 2000, by default, enters the binary value 10100000 in the DS field for a packet receiving guaranteed service. The DSCP value of this packet is a hex value 0x28H (masking out the last two bits), which corresponds to the decimal value 5 in the IP Precedence field (bits 0 through 2 in the DS field). Note that Netmon version 2 parser still displays the field as IP Type of Service field.
Testing Network Topology
Various network configurations are possible for testing GQoS applications:
- The sender machine and the receiver machine are on the same shared segment (same Ethernet subnet). No router/switch hardware is needed and no ACS is present on the subnet. This is the most basic test configuration.
- Same as the previous entry, but with an ACS on the subnet running as the Designated Subnet Bandwidth Manager (DSBM). RSVP signaling messages will be sent via the DSBM.
- The sender machine and the receiver machine are on a different subnet, with an RSVP-aware router in between. There is no ACS/DSBM on the two subnets. This configuration tests interoperability with a router vendor's RSVP implementation.
- Same as the previous entry, but with an ACS on the two subnets and an SBM-capable router between the two subnets. Alternatively, if the router supports it, you may configure the router as a DSBM, and in such topology, there is no need for ACSs.
- Same as the previous two entries, but with RSVP and SBM-enabled switches in both subnets. In this topology the switch can also be configured as the DSBM. This further tests interoperability for RSVP and DSBM mechanisms with the switch and the router vendor's RSVP implementation.
In the previous tests it is advisable to use 802.1p-capable NICs if your network hardware (your switch/router) supports it. Doing this will enable testing of layer-2 prioritization.
As you can see, adding GQoS support to a Winsock app is quite simple to do compared with your original efforts to develop your application. In fact, the Microsoft QoS team has worked with an ISV who added GQoS support to a major ERP software in one week, including testing. Given that many networks are becoming saturated with the traffic of bandwidth-hungry applications, now is the best time to GQoS-enable your Winsock applications.
The following sections cover more advanced GQoS topics to help you fine-tune your application's QoS parameters. Finally, I will discuss the GQoS support in Windows 98, Windows 98 SE, and Windows Millennium Edition (Me).
Effects of TokenRate
The TokenRate is the rate at which credits are added to the token bucket. As such, the token rate will limit the sustained rate at which data can be submitted by the application without the submitted packets being deemed as nonconforming. Ideally, the TokenRate is set equal to the sustained data rate generated by the application.
If the TokenRate is significantly higher than what is deemed necessary for the application, it may allow the application to consume more of the network resources than required. It may also allow the traffic submitted to the network to be more bursty (occurring in more irregular bursts of transmission) than intended.
If the TokenRate is significantly lower than that generated by the application, a large proportion of packets will be marked nonconforming. Figure 9 lists the effects of a TokenRate that is too low.
In considering the effects of the TokenRate and TokenBucketSize parameters in the following paragraphs, assume that the PeakBandwidth parameter is set to its default value of infinity.
TokenBucketSize Relative to App Buffer Size
The relative sizes of the buffers submitted by applications and the TokenBucketSize has a profound effect on the profile with which a flow's traffic is submitted to the network. Since the entire application buffer is submitted to the PS at the same instant, any data in excess of the TokenBucketSize will be deemed nonconforming. If application buffers are occasionally slightly larger than the TokenBucketSize, this may not be a problem. However, if the application buffer size is consistently greater than the TokenBucketSize, most of the application's data will be deemed nonconforming. The effects are shown in Figure 10.
The converse case is also worth considering; namely, when the application buffer size is smaller than the TokenBucketSize. In this case, so long as the sustained rate at which the application submits data is less or equal to the TokenRate over a period equal to TokenBucketSize/TokenRate, all packets generated from the submitted data will be deemed conforming.
The burstiness with which an application is able to submit packets to the network can be controlled by reducing the TokenBucketSize or by controlling the PeakBandwidth of the flow. If the TokenBucketSize is reduced, then the period over which the sustained rate of data is submitted by the application must not exceed the TokenRate. Reducing the TokenBucketSize is an effective way to limit the burstiness of data submitted to the network. However, this approach tends to protect the network at the expense of the app.
Effect of the PeakBandwidth Parameter
Until now, I have largely ignored the effect of the PeakBandwidth parameter. I have assumed that it has been equal to infinity (its default value). An alternate approach to reducing the burstiness of traffic submitted to the network is to set the PeakBandwidth to a finite value. The effect of the PeakBandwidth parameter varies depending on the Shape Mode.
If the SD is set to Discard Mode, then the PeakBandwidth can act as the input to the token bucket, discarding any bursts that exceed the PeakBandwidth.
If the SD Mode is Borrow Mode, then some fraction of submitted data will be considered nonconforming, but it will not be treated as harshly as it would be in Discard Mode. In Borrow Mode, a finite PeakBandwidth will typically cause a proportion of submitted data to be reduced to best effort in the QoS PS.
The primary benefit of configuring the PeakBandwidth to a finite value can be realized in Shape Mode. In this case, the effect of the PeakBandwidth setting is in limiting the rate at which the QoS PS transmits individual packets to the network.
Note that in Shape Mode, the PeakBandwidth interacts with the pipe's MTU size in the following manner: the PeakBandwidth limits the maximum rate at which packets may be burst onto the network. If the TokenBucketSize is equal to the pipe's MTU size and the application buffers are bigger than the pipe's MTU size, then the TokenRate will limit the rate at which packets may be burst onto the network. Therefore, in this particular case, PeakBandwidth will have no effect on the flow's behavior.
RSVPSP Provider-specific Objects
The ProviderSpecific field in the QOS structure can be used to provide or retrieve QoS parameters that cannot be supplied via the FLOWSPEC structure. The ProviderSpecific.len property is the length of a provider-specific object. ProviderSpecific.buf is the actual pointer to the provider-specific object. Figure 11 lists some commonly used provider-specific object types.
Figure 12 shows a code fragment that sets a QOS_DESTADOR object in a QOS structure. Figure 13 shows code on the receiver side that sets an RSVP_RESERVE_INFO object in a QOS structure to request an RESV_CONFIRM message from the sender.
Some of the reservation styles require the receiver to specify the sender's address as filters to select senders. By default, unicast TCP receivers and connected UDP receivers use fixed filter style. Multicast receivers and unconnected UDP receivers use wildcard filter styles in which there is no need to specify the sender's address. The RSVP_RESERVE_INFO object can be used to overwrite the default reservation style. UDP and multicast receivers can use a fixed style filter to specify multiple senders and different ReceivingFlowspec information for each of the senders, or a shared explicit style filter to share a ReceivingFlowspec among multiple specified senders.
The RSVP_RESERVE_INFO object is also used by either senders or receivers to supply policy elements through its PolicyElementList field. The RSVP_POLICY_INFO object (with the type RSVP_OBJECT_POLICY_INFO) contains a list of RSVP_POLICY structures. The RSVP_POLICY structure defines the policy element that is tagged with RSVP messages.
Note that some older versions of the Platform SDK documentation incorrectly list the PolicyElementList field as type LPRSVP_POLICY. The correct type for the field is LPRSVP_POLICY_INFO as defined in qossp.h. (See https://msdn.microsoft.com/library/psdk/gqos/gqosobj_8ju7.htm for more details.)
Windows 2000 RSVPSP automatically attaches the user ID policy element (containing the Kerberos key) with the RSVP messages so that Policy Decision Point and Policy Enforcement Point (PDP/PEP) can make policy decisions based on user identities. To provide application identities to PEP/PDP, applications need to provide an application ID policy element so that PDP/PEP can return a DCLASS object and/or a TCLASS object based on the application ID to allow proper marking at the sending host. Please see the sample in the Qualitative directory in the Samples folder of the code download for details on using the RSVP_RESERVE_INFO object to supply application ID policy elements to RSVPSP.
To help you diagnose the errors from GQoS calls, there's a list of error conditions in the download for this article. This list should only be treated as a guide, as the details could change if the RSVPSP implementation is changed.
GQoS in Windows 98, Windows 98 SE, and Windows Me
I have purposely delayed the discussion of the QoS support in Windows 98, Windows 98 SE, and Windows Me until now so that you have a good knowledge of GQoS and the general QoS mechanisms to fully understand the implications of the missing QoS features from Windows 2000 on these platforms.
GQoS support is implemented in Windows 98, Windows 98 SE, and Windows Me through a built-in RSVPSP. GQoS applications on these platforms can invoke RSVP signaling through the RSVPSP. However these platforms do not provide QoS kernel traffic control mechanisms, and therefore cannot shape, schedule, and mark packets. In addition, they don't provide DSBM client functionality and don't support submission or retrieval of application-specific policy objects (RSVP_RESERVE_INFO with RSVP_POLICY_INFO objects).
Without GQoS, Winsock applications don't interact with the network. The most significant benefit of GQoS-enabling an application is that the application can inform the network of its traffic requirement and adapt to the network conditions and policies through RSVP signaling. For this reason alone, ISVs are strongly advised to add GQoS support to their applications even if these applications are not targeted to Windows 2000. With this understanding, here are the implications of the QoS limitations on Windows 98, Windows 98 SE, and Windows Me:
- Due to lack of Kerberos support in these platforms, the RSVPSP does not add a user identity policy element (with a Kerberos ticket). This means the flow will only get an unauthenticated user policy from ACS.
- Unlike applications running on Windows 2000, which shape and schedules traffic based on the SendingFlowspec, GQoS applications on these platforms can send at a rate greater than its SendingFlowspec due to the lack of kernel traffic control in these platforms.
- Due to the lack of the DSBM client functionality, GQoS applications on these platforms may overcommit resources in a shared subnet.
- Flows are not marked and are always treated as best effort in the DiffServ network, but IntServ-aware network devices will provide the negotiated QoS treatment.
Therefore, GQoS applications on Windows 98, Windows 98 SE, and Windows Me can interact and adapt with the network, but their traffic flows are treated as though they are generated by untrusted users and, therefore, are subject to best-effort-only treatment in the DiffServ network.
For a complete list of QoS features in Windows 2000 not available on these platforms, please consult the Windows 98 QoS Notes in the MSDN® Platform SDK documentation.
Additional Resources
The ZIP file available for download with this article provides valuable tools, samples, and a guide to GQoS error conditions. These items are not supported by Microsoft product support services. Please read the disclaimer.txt before use.
For background information see: "A short overview of QoS Mechanisms and their Interoperation", "The Microsoft QoS Components", and an in-depth discussion of the above topics including pointers to references and standards documents at https://www.microsoft.com/windows2000/library/howitworks/communications/trafficmgmt/qosover.asp.
|