After every connection attempt (successful or otherwise) transport providers update the associated flow spec structures in order to indicate, as well as possible, the existing network conditions. (Note that it is legal to update with the default values defined below to indicate that information about the current network conditions is not available.) This update from the service provider about current network conditions is especially useful for the case where the client's QOS request consisted entirely of the default (i.e. unspecified) values, which any service provider should be able to agree to. Clients expect to be able to use this information about current network conditions to guide their use of the network, including any subsequent QOS requests. Note however, that information provided by the transport service provider in the updated flow spec structure is only a hint and may be little more than a rough estimate that only applies to the first hop as opposed to the complete end-to-end connection.
Even after a flow is established, conditions in the network may change or one of the communicating parties may invoke a QOS renegotiation which results in a reduction (or increase) in the available service level. A notification mechanism is included which utilizes the usual Windows Sockets notification techniques for network events (FD_QOS and FD_GROUP_QOS events) to allow the service provider to indicate to the client that QOS levels have changed. The basic guideline for a service provider to generate FD_QOS/FD_GROUP_QOS notifications is when the current level of service supported is significantly different (especially, in the negative direction) from what was last reported. The client should use WSPIoctl with SIO_GET_QOS and/or SIO_GET_GROUP_QOS to retrieve the corresponding FLOWSPEC structures and examine them in order to discover what aspect of the service level has changed. Note that the QUALITYOFSERVICE structures should be updated as appropriate regardless of whether FD_QOS/FD_GROUP_QOS is registered and generated. If the updated level of service is not acceptable, the client may adjust itself to accommodate it, attempt to renegotiate QOS, or close the socket. If a renegotiation is attempted, a successful return from the WSPIoctl function indicates that the revised QOS request was accepted, otherwise an appropriate error will be indicated.