Using WSAIoctl(SIO_SET_QOS) During RSVP Sessions

The use of WSAIoctl(SIO_SET_QOS) is often unnecessary; the use of connection-oriented Windows Sockets function calls (such as the WSAConnect function) is generally sufficient for providing the RSVP SP (and therefore RSVP) with requisite QOS parameters.

One exception is when a UDP application receives from multiple senders, in which case the WSAIoctl(SIO_SET_QOS) function/opcode pair must be used to specify QOS parameters to avoid limiting the socket to receive traffic from a single sender (as the use of a connection-oriented function call such as WSAConnect would do). This is a limitation of Windows Sockets 2.

Another exception is when a UDP transmit uses the sendto function to transmit data to one or more receivers through an unconnected socket (Microsoft® NetMeeting™ version 2.1 is an example of such an application). In this circumstance, the sending application must do the following in order to invoke QOS provisioning:

• Supply the RSVP SP with one or more appropriate SendingFlowspec(s) by issuing one or more SIO_SET_QOS IOCTLs.
• Provide the RSVP SP with the destination address by issuing a QOS_OBJECT_DESTADDR object in the ProviderSpecific buffer.

The WSAIoctl(SIO_SET_QOS) function/opcode pair is also useful for modifying QOS parameters subsequent to the establishment of the connection with a connection-oriented function call. This functionality also enables an application to separate the specification of QOS parameters from the determination of local and peer addresses implicit in making a connection-oriented function call.