Paul Schnackenburg03 October 2006, 2:22 AM
Network Quality of Service is one of Longhorn's big selling points: Microsoft has integrated it at the network level, so software no longer needs to be aware of it. This will make life much easier for network admins struggling to keep time critical traffic like VoIP flowing smoothly over large networks.
Microsoft is paying close attention to VoIP on corporate networks, with Longhorn and Vista integrating Quality of Service (QoS) at the network level.
Applications no longer need to be written to support QoS, handing back full control to network administrators.
VoIP and video streaming are two applications crying out for easier and more effective QoS. Behind the scenes, though, QoS can also be used to control WAN traffic, ensuring bulk data transfers (backup/replication) don't interrupt other critical business applications.
Many home users are already familiar with QoS: if you have a newish modem/router or router, it probably already supports it. Mainly, this is used to attempt to ensure VoIP calls aren't affected by other network traffic like BitTorrent.
However, applying the same principles successfully within a large corporate network is difficult -- many components have to work together, including routers, switches, operating systems and -- most importantly -- individual applications.
The approach in Vista and Longhorn server takes the application out of the equation and make it easier for network administrators to control traffic. Specifically QoS can be applied based on:
- Sending application
- Source or destination IP v4 or v6 addresses
- Protocol, TCP or UDP
- Source or destination ports (TCP or UDP)
How to set it up
The magic is all done through Group Policy, which gives very granular control for which computers or users should be affected by the policy. To prioritise traffic you setup one or more QoS policies that tags outbound traffic with a specific Differentiated Services Code Point (DSCP) value (see RFC 2474).
This value is then read by routers so they can decide which queue to put the traffic in. More importantly a throttle rate can be applied as well as a DSCP, this allows you to set a specific rate in Kbps for particular traffic.
Policy can be set both for users so that particular QoS settings apply no matter which computer that user logs on to or per computer in which case the same QoS policies apply no matter who is logged on.
The DSCP can be set between 0 and 63 with a higher number receiving higher priority. Zero is assigned to all non-QoS traffic and it is delivered on a best effort basis. When planning QoS policies leave gaps in-between the values in case other applications need to be added later.
The process is quite simple, here we’re creating a new QoS policy in the Group Policy editor. The wizard allows us to set DSCP value and optionally a throttle rate.
A specific application can be detailed and source and destination IP addresses defined.
Finally specific ports can also be set for complete control. There are a couple of generic QoS settings that can be configured including whether to ignore or respect application DSCP (that is when an application is actually written to support QoS).
General incoming TCP throughput can also be controlled here.
This then sets up a list of policies arranged in priority order. That’s all there’s to it, as long as your routers support traffic prioritisation (based on DSCP), which most should, you’re home and hosed.
