Receiving QOS-Enabled Data

An application can begin receiving data from its QOS-enabled sender before the QOS-enabled reservation is established. The result of receiving data before the QOS reservation is established is that data is transmitted over the network without QOS guarantees (as it would be in a non-QOS network). Once the QOS-enabled reservation is established, the receiver can receive data that conforms to the established QOS-parameters for the reservation.

Inherent in the occurrence of events (such as the establishment of the QOS-enabled connection) is the need for an application to query for events. The RSVP SP provides mechanisms that enable event notification. These mechanisms differ depending on whether the application is receiving or sending data.

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

• As implied in the section Providing the RSVP SP with QOS-specific parameters, a receiver must provide QOS-specific parameters to the RSVP SP. These parameters are provided in the ReceivingFlowSpec parameter of the QOS structure, which is provided through the use of the WSAConnect function, the WSAJoinLeaf function, the WSAAccept callback function, or through the Windows Sockets 2 SIO_SET_QOS IOCTL opcode.
• To streamline the establishment of existing, common settings for the QOS structure, an application can use the WSAGetQosByName function to enumerate, and then retrieve an existing QOS template, and apply the values in that template (in the form of a QOS structure) to the QOS structure in the Windows Sockets function call. See the section QOS Templates for more information on QOS templates.
• The application may then send data. Data sent per the constraints of the established QOS-specific parameters is considered conforming data. Data that falls outside those parameters, or nonconforming data, is handled differently based on the QOS_OBJECT_SD_MODE setting, which is particular to traffic control. Options for nonconforming data include relegating it to a best-effort transmission to discarding nonconforming packets.
• The application may want to track RSVP SP events in order to monitor the QOS-enabled connection status. For example, the application uses the status information and error codes provided with FD_QOS events. Other RSVP SP events that an application may want to monitor include using an RSVP_RESERVE_INFO object to request arrival confirmation of a RESV message.
• When the application receives notification of certain events, it may want to take appropriate action to modify its QOS settings or parameters. For example, if an application is notified of the arrival of a PATH message, it must use the Windows Sockets 2 SIO_GET_QOS IOCTL opcode to retrieve pertinent QOS information, such as the sender's Tspec and the path's Adspec. Information provided in the PATH message may be used by the application to modify its initial QOS-specific parameters to match the sender's Tspec. For more information on Tspec and Adspec, see the section RSVP SP and RSVP).