The basic Quality of Service (QOS) mechanism in Windows Sockets 2 descends from the flow specification as described in RFC 1363, dated September 1992. Following is a brief overview of this concept:
Flow specifications describe a set of characteristics about a proposed, unidirectional flow through the network. An application can associate a pair of flow specifications with a socket (one for each direction) at the time a connection request is made using WSAConnect, or at other times using WSAIoctl with the SIO_SET_QOS/SIO_SET_GROUP_QOS command. Flow specifications indicate parametrically what level of service is required and provide a feedback mechanism for applications to use in adapting to network conditions.
This is the usage model for QOS in Windows Sockets 2: An application can establish its QOS requirements at any time with WSAIoctl or coincident with the connect operation with WSAConnect. For connection-oriented transports, it is often most convenient for an application to use the WSAConnect function because any QOS values supplied at connect time supersede those supplied earlier with the WSAIoctl function. If the WSAConnect function completes successfully, the application knows that its QOS request has been honored by the network. The application is then free to use the socket for data exchange. If the connect operation fails because of limited resources, an appropriate error indication is given. At this point, the application can scale down its service request and try again, or it can give up.
Transport providers update the associated flowspec structures after every connection attempt (successful or otherwise) in order to indicate, as well as possible, the existing network conditions. (Updating with the Default Values will indicate that information about the current network conditions is not available.) This update from the service provider about current network conditions is especially useful when the application's QOS request consists entirely of the default (unspecified) values, which any service provider should be able to meet.
Applications expect to use this information about current network conditions to guide their use of the network, including any subsequent QOS requests. However, the information provided by the transport in the updated flowspec structure is only an indication. It might be little more than a rough estimate that only applies to the first hop and not to the complete, end-to-end connection. The application must take appropriate precautions in interpreting this information.
Connectionless sockets can also use the WSAConnect function to establish a specified QOS level to a single designated peer. Otherwise, connectionless sockets use the WSAIoctl function to stipulate the initial QOS request, and any subsequent QOS renegotiations.
Even after a flow is established, conditions in the network can change or one of the communicating parties might invoke a QOS renegotiation that results in a reduction (or increase) in the available service level. A notification mechanism is included that utilizes the usual Windows Sockets notification techniques (FD_QOS and FD_GROUP_QOS events) to indicate to the application that QOS levels have changed.
A service provider generates FD_QOS/FD_GROUP_QOS notifications when the current level of service supported is significantly different (especially in the negative direction) from what was last reported as a basic guideline. The application should use the WSAIoctl function with SIO_GET_QOS and/or SIO_GET_GROUP_QOS to retrieve the corresponding flowspec structure and examine them in order to discover what aspect of the service level has changed. The QOS structures will be updated where appropriate. regardless of whether FD_QOS/FD_GROUP_QOS is registered and generated.
If the updated level of service is not acceptable, the application can adjust itself to accommodate it, attempt to renegotiate QOS, or close the socket. If a renegotiation is attempted, a successful return from the WSAIoctl function indicates that the revised QOS request was accepted., Otherwise, an appropriate error will be indicated.
The flow specifications proposed for Windows Sockets 2 divide QOS characteristics into the following general areas: