| Platform SDK: Quality of Service |
The RSVP service and TC communicate in order to work together to provide overall QOS for a given sending flow. When an application requests QOS using the RSVP SP, the RSVP SP responds by initiating RSVP signaling and invoking kernel traffic control from local TC components (using the traffic control Interface). As such, traffic control and RSVP signaling are initiated concurrently upon flow setup.
In this transitional period (presuming QOS_OBJECT_SD_MODE has not been specifically set) the reservation has not been established, and therefore traffic control is configured to transmit traffic associated with the flow's specification, as follows:
Note The above default configuration can be overridden by supplying the QOS_OBJECT_SD_MODE object in the ProviderSpecific buffer.
In this transitional period, all packets conforming to the flowspec for BEST_EFFORT and CONTROLLED LOAD are sent immediately with the appropriate traffic control marking, and nonconforming packets are sent immediately with their host and network priority demoted. Transmission settings for any given flow are aligned with the allowed sending rate specified by the system (which is in turn determined by settings in the appropriate FLOWSPEC).
Sending applications can determine what the allowed sending rate is by querying the Allowed_Rate using SIO_CHK_QOS. More information about using SIO_CHK_QOS is provided in Using SIO_CHK_QOS.
Once PATH messages arrive at the receiving host (or hosts; for simplicity, ongoing references will be singular), the host may request QOS provisioning for the flow in the form of RESV messages sent back toward the sender. When the RSVP SP on the receiver receives the RESV message, it communicates with traffic control to enable traffic control to update its transmission information, and if appropriate, to modify the BEST_EFFORT flow according to the reservation indicated in the RESV message.
Note that it is possible to invoke traffic control without RSVP signaling, and to programmatically modify traffic control's treatment of a flow. RSVP signaling can be suppressed on a given flow if the SERVICE_NO_QOS_SIGNALING service type is specified, and traffic control can be suppressed on a given flow if the SERVICE_NO_TRAFFIC_CONTROL service type is specified. Additional control over the suppressing of RSVP signaling and traffic control can be achieved through the use of registry entries. For more information on controlling QOS through the use of registry entries, consult the Windows 2000 Resource Kit, available from Microsoft Press.