Terminating QOS

Terminating QOS

In the previous section, you learned how to invoke QOS on a socket. Next, we'll examine the termination of QOS guarantees. Each of the following events causes a termination of RSVP and TC processing for a socket.

  • Closing a socket via the closesocket function

  • Shutting down a socket via the shutdown function

  • Calling WSAConnect with a null peer address

  • Calling WSAIoctl and SIO_SET_QOS with the SERVICETYPE_ NOTRAFFIC or the SERVICETYPE_BESTEFFORT service type

Except for the second item in the list, these events are self-explanatory. Remember that the shutdown function can signal the cessation of either sending or receiving data, which will result in the termination of the flow of data for only that direction. In other words, if shutdown is called with SD_SEND, QOS will still be in effect for data being received.

Provider-Specific Objects

The provider-specific objects covered in this section are passed as part of the ProviderSpecific field of the QOS structure. Either they return QOS information to your application via the FD_QOS event or you can pass them along with the other QOS parameters to a WSAIoctl call with the SIO_SET_QOS option to refine QOS's behavior.

Every provider-specific object contains a QOS_OBJECT_HDR structure as its first member. This structure identifies the type of provider-specific object. This is necessary because these provider objects are most commonly returned within the QOS structure after a call to SIO_GET_QOS. By using the QOS_ OBJECT_HDR, your application can identify each object and decode its significance. The object header is defined as

typedef struct   {     ULONG   ObjectType;     ULONG   ObjectLength;  } QOS_OBJECT_HDR, *LPQOS_OBJECT_HDR;

ObjectType identifies the type of preset provider-specific object, while ObjectLength tells how long the entire object is, including the object header and the provider-specific object. An object type can be one of the flags listed in Table 10-3.

Table 10-3 Object Types

Provider Object

Object Structure

QOS_OBJECT_SD_MODE

QOS_SD_MODE

QOS_OBJECT_SHAPING_RATE

QOS_SHAPING_RATE

QOS_OBJECT_DESTADDR

QOS_DESTADDR

RSVP_OBJECT_STATUS_INFO

RSVP_STATUS_INFO

RSVP_OBJECT_RESERVE_INFO

RSVP_RESERVE_INFO

RSVP_OBJECT_ADSPEC

RSVP_ADSPEC

RSVP_OBJECT_POLICY_INFO

RSVP_POLICY_INFO

QOS_OBJECT_END_OF_LIST

None. No more objects.

QOS Shape Discard Mode

This QOS object defines how the Packet Shaper element of TC processes the data of a given flow. This property most often comes into play when dealing with flows that do not conform to the parameters given in FLOWSPEC. That is, if an application is sending data at a rate faster than what is specified in the TokenRate field of the sending FLOWSPEC, it is considered nonconforming. This object defines how the local system handles this occurrence. The QOS_SD_MODE structure is defined as

typedef struct _QOS_SD_MODE  {     QOS_OBJECT_HDR   ObjectHdr;     ULONG            ShapeDiscardMode; } QOS_SD_MODE, *LPQOS_SD_MODE;

The ShapeDiscardMode field can be one of the values specified in Table 10-4.

Table 10-4 QOS Shape DiscardMode Flags

Flag

Description

TC_NONCONF_BORROW

The flow receives the resources remaining after all higher-priority flows have been serviced. Flows of this type are not subjected to either the Shaper or the Sequencer. If a value for TokenRate is specified, packets can be nonconforming and will be demoted to less than best-effort priority.

TC_NONCONF_BORROW_PLUS

Similar to TC_NONCONF_BORROW, however, packets will not be marked as nonconforming in the Shaper.

TC_NONCONF_SHAPE

A value for TokenRate must be specified. Nonconforming packets will be retained in the Packet Shaper until they become conforming.

TC_NONCONF_DISCARD

A value for TokenRate must be specified. Nonconforming packets will be discarded.

You might wonder why you would want to use the TC_NONCONF_ DISCARD mode when it might result in dropping data before it even gets sent on the wire. One such use is in sending audio or video data. In most cases, the FLOWSPEC structure is set up to reflect sending a packet whose size is equal to one frame of video or a small segment of audio. If for some reason the packet does not conform, is it better for an application to wait until it does conform (as is the case with TC_NONCONF_SHAPE), or should the application drop the packet altogether and move on to the next one? For time-critical data such as video, it is often better to drop the frame and move on.

QOS Destination Address

The QOS_DESTADDR structure is used to specify the destination address for a connectionless sending socket without using a WSAConnect call. No RSVP PATH or RESV messages will be sent until the destination address of a connectionless socket is known. The destination address can be set with the SIO_SET_QOS ioctl command. The structure is defined as

typedef struct _QOS_DESTADDR  {     QOS_OBJECT_HDR         ObjectHdr;      const struct sockaddr *SocketAddress;     ULONG                  SocketAddressLength; } QOS_DESTADDR, *LPQOS_DESTADDR;

The SocketAddress field references the SOCKADDR structure that defines the endpoint's address for the given protocol. SocketAddressLength is simply the size of the SOCKADDR structure.

RSVP Status Info

The RSVP status info object is used to return RSVP-specific error and status information. The structure is defined as

typedef struct _RSVP_STATUS_INFO {     QOS_OBJECT_HDR ObjectHdr;     ULONG            StatusCode;     ULONG            ExtendedStatus1;     ULONG            ExtendedStatus2; } RSVP_STATUS_INFO, *LPRSVP_STATUS_INFO;

The StatusCode field is the RSVP message returned. The possible codes are described in Table 10-5. The other two fields, ExtendedStatus1 and ExtendedStatus2, are reserved for provider-specific information.

Table 10-5 RSVP Status Info Codes

Flag

Meaning

WSA_QOS_RECEIVERS

At least one RESV message has arrived.

WSA_QOS_SENDERS

At least one PATH message has arrived.

WSA_QOS_NO_RECEIVERS

There are no receivers.

WSA_QOS_NO_SENDERS

There are no senders.

WSA_QOS_REQUEST_CONFIRMED

The reserve has been confirmed.

WSA_QOS_ADMISSION_FAILURE

Request failed due to lack of resources.

WSA_QOS_POLICY_FAILURE

Request rejected for administrative reasons or bad credentials.

WSA_QOS_BAD_STYLE

Unknown or conflicting style.

WSA_QOS_BAD_OBJECT

There is a problem with some part of the RSVP_FILTERSPEC structure or with the provider-specific buffer in general. (This object will be discussed shortly.)

WSA_QOS_TRAFFIC_CTRL_ERROR

There is a problem with some part of the FLOWSPEC structure.

WSA_QOS_GENERIC_ERROR

General error.

ERROR_IO_PENDING

Overlapped operation is canceled.

Typically, an application receives an FD_QOS event and calls SIO_ GET_QOS to obtain a QOS structure containing an RSVP_STATUS_INFO object when an RSVP message is received. For example, for a QOS-enabled UDP-based receiver, an FD_QOS event containing a WSA_QOS_SENDERS message is generated to indicate that someone has requested the QOS service to send data to the receiver.

RSVP Reserve Info

The RSVP reserve info object is used for storing RSVP-specific information for fine-tuning interactions via the Winsock 2 QOS APIs and the provider-specific buffer. An RSVP_RESERVE_INFO object overrides the default reservation style and is used by a QOS receiver. The object is defined as

typedef struct _RSVP_RESERVE_INFO  {     QOS_OBJECT_HDR      ObjectHdr;     ULONG               Style;     ULONG               ConfirmRequest;     LPRSVP_POLICY_INFO  PolicyElementList;     ULONG               NumFlowDesc;     LPFLOWDESCRIPTOR    FlowDescList; } RSVP_RESERVE_INFO, *LPRSVP_RESERVE_INFO;

The Style field specifies the filter type that should be applied to this receiver. Table 10-6 lists the filter types available and the default filter types that different types of receivers use.

Table 10-6 Default Filter Styles

Filter Style

Default Users

Fixed filter

Unicast receivers; connected UDP receivers

Wildcard

Multicast receivers; unconnected UDP receivers

Shared explicit

None

Each filter style will be discussed in greater detail shortly. If the ConfirmRequest field is nonzero, notification will be sent once the RESV request has been received for receiving applications. NumPolicyElement is related to the PolicyElementList field. PolicyElementList is a list of RSVP_POLICY objects that we define a little bit later in this chapter. Let's take a look at the different filter styles and the characteristics of each.

RSVP_DEFAULT_STYLE

This flag tells the QOS service provider to use the default style. Table 10-6 lists the default styles for the different possible receivers. Unicast receivers use fixed filter, whereas wildcard is for multicast receivers. UDP receivers that call WSAConnect also use fixed filter.

RSVP_FIXED_FILTER_STYLE

Normally, this style establishes a single flow with QOS guarantees between the receiver and a single source. This is the case for a unicast receiver and connected UDP receivers: NumFlowDesc is set to 1, and FlowDescList contains the sender's address. However, it is also possible to set up a multiple fixed filter style that allows a receiver to reserve mutually exclusive flows from multiple, explicitly identified sources. For example, if your receiver intends to receive data from three senders and needs guaranteed bandwidth of 20 Kbps for each, use the multiple fixed filter style. In this example, NumFlowDesc is set to 3, while FlowDescList contains three addresses, one for each FLOWSPEC. It is also possible to assign varying levels of QOS to each sender; they do not all have to be equal. Note that unicast receivers and connected UDP receivers cannot use multiple fixed filters. Figure 10-1 shows the relationship between FLOWDESCRIPTOR and RSVP_FILTERSPEC structures.

Figure 10-1 Multiple fixed filter style

RSVP_WILDCARD_STYLE

Multicast receivers and unconnected UDP receivers use the wildcard style. To use this style for TCP connections or for connected UDP receivers, set NumFlowDesc to 0 and FlowDescList to NULL. This is the default filter style for unconnected UDP receivers and multicast applications because the sender's address is unknown.

RSVP_SHARED_EXPLICIT_STYLE

This style is somewhat similar to multiple fixed filter style except that network resources are shared among all senders instead of being allocated for each sender. In this case, NumFlowDesc is 1 and FlowDescList contains the list of sender addresses. Figure 10-2 illustrates this style.

Figure 10-2 Shared explicit style

We've introduced the last two fields, NumFlowDesc and FlowDescList, in our discussion of RSVP styles. How you use these two fields depends on the style. NumFlowDesc defines the number of FLOWDESCRIPTOR objects in the FlowDescList field. This structure is defined as

typedef struct _FLOWDESCRIPTOR  {     FLOWSPEC             FlowSpec;     ULONG                NumFilters;     LPRSVP_FILTERSPEC    FilterList; } FLOWDESCRIPTOR, *LPFLOWDESCRIPTOR;

This object is used to define the types of filters per FLOWSPEC given by FlowSpec. Again, the NumFilters field contains the number of RSVP_FILTERSPEC objects present in the FilterList array. The RSVP_FILTERSPEC object is defined as

typedef struct _RSVP_FILTERSPEC {     FilterType   Type;     union {         RSVP_FILTERSPEC_V4      FilterSpecV4;         RSVP_FILTERSPEC_V6      FilterSpecV6;         RSVP_FILTERSPEC_V6_FLOW FilterSpecV6Flow;         RSVP_FILTERSPEC_V4_GPI  FilterSpecV4Gpi;         RSVP_FILTERSPEC_V6_GPI  FilterSpecV6Gpi;     }; } RSVP_FILTERSPEC, *LPRSVP_FILTERSPEC;

The first field, Type, is a simple enumeration of the following values:

typedef enum {         FILTERSPECV4 = 1,         FILTERSPECV6,         FILTERSPECV6_FLOW,         FILTERSPECV4_GPI,         FILTERSPECV6_GPI,         FILTERSPEC_END } FilterType;

This enumeration specifies the object present in the union. Each of these filter specs is defined as follows:

typedef struct _RSVP_FILTERSPEC_V4 {     IN_ADDR_IPV4    Address;     USHORT          Unused;     USHORT          Port; } RSVP_FILTERSPEC_V4, *LPRSVP_FILTERSPEC_V4; typedef struct _RSVP_FILTERSPEC_V6 {     IN_ADDR_IPV6    Address;     USHORT          UnUsed;     USHORT          Port; } RSVP_FILTERSPEC_V6, *LPRSVP_FILTERSPEC_V6; typedef struct _RSVP_FILTERSPEC_V6_FLOW {     IN_ADDR_IPV6    Address;     UCHAR           UnUsed;     UCHAR           FlowLabel[3]; } RSVP_FILTERSPEC_V6_FLOW, *LPRSVP_FILTERSPEC_V6_FLOW; typedef struct _RSVP_FILTERSPEC_V4_GPI {     IN_ADDR_IPV4    Address;     ULONG           GeneralPortId; } RSVP_FILTERSPEC_V4_GPI, *LPRSVP_FILTERSPEC_V4_GPI; typedef struct _RSVP_FILTERSPEC_V6_GPI {     IN_ADDR_IPV6    Address;     ULONG           GeneralPortId; } RSVP_FILTERSPEC_V6_GPI, *LPRSVP_FILTERSPEC_V6_GPI;

RSVP Adspec

The RSVP_ADSPEC object defines the information carried in the RSVP Adspec. This RSVP object typically indicates which service types are available (controlled load or guaranteed), whether a non-RSVP hop has been encountered by the PATH message, and the minimum MTU along the path. The structure is defined as

typedef struct _RSVP_ADSPEC   {     QOS_OBJECT_HDR     ObjectHdr;     AD_GENERAL_PARAMS  GeneralParams;                           ULONG              NumberOfServices;      CONTROL_SERVICE    Services[1];  } RSVP_ADSPEC, *LPRSVP_ADSPEC;

The first field of interest is GeneralParams, which is a structure of type AD_GENERAL_PARAMS. This structure is exactly as it sounds—it defines some general characterization parameters. The definition of this object is

typedef struct _AD_GENERAL_PARAMS {     ULONG       IntServAwareHopCount;     ULONG       PathBandwidthEstimate;     ULONG       MinimumLatency;     ULONG       PathMTU;     ULONG       Flags; } AD_GENERAL_PARAMS, *LPAD_GENERAL_PARAMS;

The IntServAwareHopCount is the number of hops that conform to Integrated Services (IntServ) requirements. PathBandwidthEstimate is the minimum bandwidth available from sender to receiver. MinimumLatency is the sum of minimum latencies, in microseconds, of the packet forwarding processes in the routers. PathMTU is the maximum transmission unit—end-to-end—that will not incur any fragmentation. The Flags field is not used anymore.

RSVP Policy Info

The last provider object we'll take a look at is the RSVP policy info. This object is rather nebulous—it contains any number of policy elements from RSVP that are not defined. The structure is defined as

typedef struct _RSVP_POLICY_INFO  {     QOS_OBJECT_HDR     ObjectHdr;     ULONG              NumPolicyElement;      RSVP_POLICY        PolicyElement[1];  } RSVP_POLICY_INFO, *LPRSVP_POLICY_INFO;

The NumPolicyElement field gives the number of RSVP_POLICY structures present in the PolicyElement array. This structure is defined as

typedef struct _RSVP_POLICY {     USHORT  Len;     USHORT  Type;     UCHAR   Info[4]; } RSVP_POLICY, *LPRSVP_POLICY;

The RSVP_POLICY structure is data transported by RSVP on behalf of the policy component and is not particularly relevant to our needs.



Network Programming for Microsoft Windows
Network Programming for Microsoft Windows (Microsoft Professional Series)
ISBN: 0735605602
EAN: 2147483647
Year: 2001
Pages: 172
Authors: Anthony Jones

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net