QoS is new; buying bandwidth to solve application communications problems is old. Fatter pipes are brute force; QoS is intelligent flow-control assertion.
The problem with making QoS work in Windows-2000-based networks has historically been a problem with QoS in general: It's seen as complex and application-driven. Applications that need QoS-multimedia apps have historically been a low priority in business situations, and simply unusable in consumers' slow-speed, dial-up environments.
Faster technology doesn't equal faster QoS adoption
Now, the advent of faster modems, broadband deployments, and other market drivers has dramatically increased demand for multimedia applications. To paraphrase Mark Knopfler of Dire Straits: I want my MTV -- and what's its URL?
QoS, though, is often vexed by the perceived complexity of deploying support for it. Organizations ignore it unless serious business-application throughput is being hampered by some other service. "If it ain't broke, don't fix it!" is the hue and cry.
Another demotivator is fear. Many network designers think both types of QoS -- qualitative and quantitative -- are tough to implement, and that the benefits of QoS are obscure and difficult to sell to management. This is actually an avoidance problem: QoS can be easily justified with the right information, and surprisingly, most of the foundational components are already in your OS to support it. The key is that applications must ask for QoS, and the delivery chain must support these requests.
Review of quantitative QoS
Quantitative QoS applications -- think multimedia and isochronicity protocols -- are host-to-host, and therefore stream-oriented. Relationships are generally built between a desktop user and a multimedia source; in Internet Telephony/VoIP, two relationships are established, one in each direction.
Whatever the relationship -- unicast or multicast (see "Understanding QoS for timing-sensitive applications") -- all the routers along a delivery chain must be able to support the desired type of QoS. Any router that doesn't is a potential entrance point for the latency and resulting jitter that breaks the time-domain needs of applications, which may cause the multimedia reproduction to suffer. Voice apps will have gaps spiked into them. Videos will freeze and catch up, like a dying VCR. Keep within the time-domain boundary, and the results will be acceptable.
Windows routing and changing times
A Windows 2000 (or NT) server doesn't participate in quantitative QoS unless it is configured as an interloper or intermediary -- e.g., a router or gateway between a desktop and the multimedia source -- or it is the source of a conversation, as in multicasting via Windows Media, Real, or another unicast/multicast media disseminator.
NT/2000 servers don't act as routers within LAN communications fabrics as much as they used to. Instead, NT/2000 servers that are near-edge devices may play new roles in the wider QoS chain of delivery. In the late 1980s and early-to-mid-1990s, high router costs led to the use of servers as routers and gateways in LANs. As the cost of Ethernet switches fell, followed by a drop in the price of hardware-based routers, the need to deploy servers as routers or gateway devices also tapered off. Putting "everything" into a server was increasingly viewed as unwise, unless the device was the primary resource for a small office or branch.
Routing functionality was pulled from servers in part because it created routing inefficiency, which could drag down server performance. Buses inside servers, for example, could be bottlenecks in network routing. Worse, routing placed aperiodic loads on servers, causing wiggy server performance. Nonetheless, branch-office servers and other small systems are still used to support routing, as well as to house firewalls, gateways, and other communications-plumbing application functions that aren't as sensitive to routing impact. Such servers can also become serviceable participants in QoS support. I'll tell you how below.
Unlike quantitative methods, qualitative QoS support is managed by policy, not rigid time-domain needs: you select, through bandwidth management, which protocols get priority access to available transmission resources. There are two ways to support qualitative requirements, both of which I'll discuss in upcoming installments. One is anchored in Active Directory links that enable applications (or users with applications). The other is provided through a third-party infrastructure that serves as bandwidth throttles and/or bandwidth admission controls.
Resource Reservation Protocol (RSVP)RSVP is application-based -- applications on Windows clients initiate it through WinSock. A workstation called a receiver sets up relationships between itself and all the devices (usually routers) along the network connection path to the host (called a sender). RSVP sends messages to the connecting components to find how much latency there is between, and even among, these devices. A reservation request is then set up to allocate bandwidth "space" along the route that the data will travel. Subsequent RSVP relationships can be built with the same host by other workstations.
RSVP, a signaling protocol, can also ride inside other protocols, as I describe below.
DiffServDifferentiated Services (DiffServ) is a method that's used to mark packets as needing priority; unlike RSVP, DiffServ does not use time-domain cognizance. Routers between two communicating hosts can respect the need for priority, and many made after 1997 do. Examples of DiffServ markings are "Assured Service" and "Preferred Service."
It's possible to link RSVP relationships and allow them to "ride" DiffServ-enabled paths: essentially a merger of the two protocols. RSVP is initiated by a receiver, as described above, and its packets are then boosted by the marking behavior of DiffServ. DiffServ can give aggregated priority to RSVP relationships that are built -- without knowledge of the application -- as a function of a router-to-router relationship.
IEEE 802.1p (now a part of IEEE 802.1D)Another marking protocol supported by Windows 2000, 802.1p is a virtual LAN protocol. 802.1p allows for prioritization of packets in switched-network (usually Ethernet) fabrics; it's also supported in most routers. Because switches were intended to be raw packet-forwarding devices, initial switch implementations did not prioritize packets for forwarding -- 802.1p does. Such marking doesn't allow devices in the delivery chain to have a respect for time domains (as RSVP does). Instead, it's the first boost given to data through switched fabrics.
There are applications considerations that enable QoS, and there are policies that can be used with Windows 2000 that can have a direct bearing on how QoS is used. I'll tell you how and why in my next column, which will begin a series called "Networking by Policy."