Sending QOS-Enabled Data

As a sender on a QOS-enabled connection, the events differ somewhat from the receiver's collection of available actions. Where senders initiate connections and request certain QOS-specific parameters, receivers respond to such requests (note that network devices between the receiver and sender also react to receiver requests, and may reject requests before they ever reach the sender).

As a sender on a QOS-enabled connection, a host may initiate some or all of the following actions:

• Sending hosts must inform the RSVP SP of QOS-specific parameters in order to enable the RSVP SP to interact with other QOS components on the sending host's behalf. QOS-specific parameters are provided to the RSVP SP through the SendingFlowspec member of the QOS structure, which itself is a parameter of the WSAConnect function, the WSAAccept function's ConditionFunc placeholder, and the WSAJoinLeaf function. The SendingFlowspec member can also be provided through the use of the SIO_SET_QOS IOCTL opcode.
• The QOS-specific members (SendingFlowspec) are based on the application's knowledge of the data transmission characteristics appropriate for the application. For example, bandwidth requirements for database queries of a mission-critical application may be different than bandwidth requirements for low-quality audio broadcasts. Latency boundaries may also be different for those types of applications (note that latency boundaries are only available with Guaranteed Service). Therefore, the application is best equipped to provide appropriate QOS-specific transmission parameters, perhaps through the use of a QOS template.
• Senders may use the WSAGetQosByName function to enumerate, and then retrieve preinstalled QOS templates that include QOS-specific parameters with appropriate transmission characteristics based on the type of application. For example, there may be a template called RADIOBCAST associated with a QOS structure that automatically applies the most appropriate QOS settings for radio broadcast senders. It is the application's responsibility to ensure that its traffic remains within the bounds of FLOWSPEC members obtained using WSAGetQosByName; traffic that exceeds those parameters will be treated as nonconforming, and may result in degradation of quality.
• Senders may configure additional traffic control parameters by including objects in the ProviderSpecific buffer, such as handling nonconforming packets through setting of the SD_MODE.
• The sender may monitor RSVP SP events to maintain the QOS-enabled connection, such as the arrival of RESV messages. Often, the sender will want to monitor status information and error codes provided with FD_QOS events. For example, the sender may choose to stop transmission when the FD_QOS event WSA_QOS_NO_RECEIVER occurs, indicating that there are no QOS-enabled receivers for the transmission.
• The sending application may want to use the Windows Sockets 2 SIO_GET_QOS IOCTL opcode to look up QOS-specific parameters associated with the arrival of a RESV message.
• The sending application may want to use the Windows Sockets 2 SIO_CHK_QOS IOCTL opcode to query parameters that provide information about the QOS connection such as allowed sending rate, line rate, and others.