Are the QoS API's in Winsock useful?

Question

Quality of Service (QoS) was designed to manage bandwidth usage, which implicitly assumes that applications compete for that (limited) resource. Is that really, ever a concern for ANY applications these days?

It also assumes that the QoS protocols and Internet Protocol options are implemented on both client and server ends, and recognized and honored on each network element in between (e.g., all switches, routers, proxies, and NATs). Is that ever true on anything other than, maybe, between two hosts on the same subnet, or on a highly-managed enterprise network?

And finally, has anyone ever used the QoS APIs AND identified an actual benefit? In other words, did it ever "save the day", and avert a problem that would surely have happened otherwise?

thanks, bob

Answer 1

Clearly, the answer is no, the Winsock QoS API's are not useful. It is not that QoS itself is useless, just that socket-level QoS need not be set by application developers.

Some devices, like SIP-based phones, set the ToS bits (Differentiated Services Code Points) in the Internet Protocol headers in outgoing packets, to provide class-based QoS to aggregates of traffic. Most often, however, traffic classification is done by routers, which set the DSCP after classifying by (layer 3, TCP or UDP) port number, among other things. Hence, QoS is mostly the concern of network managers, not application developers.

For more information on where Differentiated Services are appropriate, see IETF RFC 4594 "Guidelines for DiffServ Service Classes".

Answer 2

Skype for Business marks its two different classes of traffic with two different DSCP values:

• Audio: EF (Expedited Forwarding, DSCP 46)
• Video: AF41 (Assuring Forwarding, DSCP 34)

And, at one point, both Steam and Blizzard marked their bulk download traffic with a DSCP.

It's a useful thing that nobody does because nobody honors it, and nobody honors it because nobody does it. The only way to combat that is education.

Also note that by default after Windows 2000 you cannot manually set the IP_TOS header value unless you're an administrator. Allowing non-admin programs to set their own QoS would violate QoS policies.

On Windows 2000-based, Windows XP-based, or Windows Server 2003-based host devices, the Generic Quality of Service (GQOS) implementation determines the DSCP marking. A Winsock GQOS program triggers the RSVP service provider to submit policy and resource checks to determine the policy control and the availability of resources along a network data path. If the intended resource usage is approved, the QOS Packet Scheduler service marks the DSCP prioritization in the IP packet headers. The IP_TOS option with the setsockopt function would bypass Windows 2000, Windows XP, or Windows Server 2003 QOS policy control, and thus is disabled by default on these versions of Windows.

Microsoft recommends that you implement GQOS in your Winsock programs to take advantage of the Windows 2000, Windows XP, and Windows Server 2003 GQOS capabilities.

That's why the Generic QoS api was created; request a QoS and you will get it if approved.