Many organizations view Quality of Service (QoS) management as an afterthought -- an issue to be dealt with only when the need arises. That's a shame because Windows 2000, far more than any previous version of Windows, is able to respond to the needs of applications that require QoS.
Proactively implementing Windows 2000's new QoS features can improve the performance of both isochronous (timing-sensitive) and non-isochronous applications. The trick is understanding how to use the available tools.
In "Multimedia vs. your network," I provided an overview of QoS concepts. This week I'll discuss the structure and needs of isochronous applications in more detail.
The Winsock connection
In Windows 2000, QoS is enabled by a combination of kernel resources triggered by applications requesting QoS services. That occurs through the Windows Sockets API (also known as Winsock).
It's worth remembering that QoS protocols, being part of the underlying infrastructure, are transparent to users. A strange quality of QoS is that users don't know when they're benefitting from it -- they just know their apps work. And maybe it's better that way, since an application's priority implies a privileged status that could become the crux of arguments.
Quantitative (timing-based) routing
Through Winsock, applications can manage several different protocols and relationships that have a bearing on QoS. Applications can either directly manipulate streams of data -- a process that requires timing -- or use policies. I'll cover policies in detail in my next and final QoS installment.
A quick review of quantitative concepts tells us that isochronous applications (e.g. voice and video) live within a defined time domain, whereas most data applications do not. While non-isochronous applications need qualitative delivery, isochronous applications require quantitative delivery. If apps that must function within a time domain are interrupted, playback at the receiver may have glitches. Think again of voice- and video-data streams, which although compressed with codecs, are notoriously susceptible to corruption. Such applications require quantitative, or statistically successful, packet control because dropped packets and induced delays can demonstrably corrupt a multimedia stream at the receiver.
In addition to problems caused by latency and data loss, isochronous streams can be affected by distortion (rarer these days) and codec-specific peculiarities. Those peculiarities can amount to distortions -- strange video raster updates, which appear as morphing or partial updates, and other frustration-inducing reproduction quality problems.
Unicasting and multicasting
Now let's consider the two types of relationships possible between the sender and receiver of isochronous data: unicasting and multicasting.
Unicasting is one-on-one, host-to-host communications. Two simultaneous unicasts -- one in each direction -- constitute a bidirectional conversation using full-duplex communications. Two bidirectional unicasts that share a single channel and communicate in only one direction at a time are engaged in half-duplex communications.
Half-duplex operation is similar to CB radio communication, in which one must indicate that they're finished talking and the channel is now available for the other user. In early Internet telephony, half-duplex was normal. Now, fortunately, full-duplex is the norm. (Of course, this also means that two points must be controlled simultaneously per instance of IP telephony.)
Multicasting is similar to broadcasting: a single source, or several sources chained together and supplying the same data for redundancy, sends data to requesters. Internet Radio and Broadcast.Com (via Windows Media Player, RealAudio, etc.) are examples of multicasters, in that they allow people to receive streams as multicast recipients.
I've yet to see multicasting used for bidirectional video conferencing, but it'll happen someday. Current video conferencing between two parties is made up of two unicasts. If three or more parties participate in a video conference or a voice conference call, a matrix of unicast relationships is created among the participants.
Qualitative (policy-based) routing
Qualitative QoS applications, generally non-isochronous in nature, aren't usually sensitive to latency, although they may be sensitive to dropped packets. Instead, such applications receive priority for other reasons. Consider that Oracle SQL*Net or SAP transactions may, for business reasons, receive priority over Web surfing, email, or push traffic. The QoS needs of isochronous applications, established by policy, are often handled through bandwidth and admittance controls.
You could buy enormous amounts of bandwidth in order to prevent jitter and latency. However, there are several other ways to allow isochronous streams to get through huge and unpredictable secure-side network traffic patterns, as well as through the Internet.
One of the first sources of multicasting support was the Multicast Backbone, or MBone. The MBone was a set of Class-D IP addresses designed to shorten paths between participants. As the Internet grew, several applications were built to take advantage of MBone routing, but use of the MBone was largely confined to university users; few corporations or consumers took advantage of it. The MBone still works, but is now overshadowed by more deterministic mechanisms.
The RSVP end-to-end protocol model
One of the first end-to-end protocol models was the ReSerVation Protocol (RSVP). RSVP is a host-to-host protocol initiated by an application residing on the receiver. RSVP queries routers and network fabric between hosts, setting up priorities in these intermediary devices based upon their capabilities. RSVP also identifies user, type and level of QoS needed, and which network resources will be impacted by a conversation. The result is a system that provides topology-aware admission control. (See Microsoft's treatise on QoS.)
RSVP has a number of benefits, as well as a few problems. One benefit is that apps can assert some control over intermediary devices in the delivery chain by establishing policies on them. There is a risk of misuse, though, in the form of rogue apps that assert bogus requests for QoS.
Also, RSVP is only effective if the devices in the delivery chain support it. A device that doesn't support RSVP won't necessarily hurt RSVP-based conversations. Instead, it will constitute an area where there's no control -- and therefore a point where objectionable latencies can screw up isochronous data flows.
RSVP isn't a cure-all. Even if all the devices in a delivery chain correctly identify streams, it's still possible they lack the bandwidth to handle the traffic. For instance, if 200 users attempt to use an IP Telephony app that uses RSVP QoS on a 256-kbps DSL line, there'll be about 190 unhappy campers. The DSL line simply can't deliver the prioritized bandwidth allocation to support that many users. The pipes can't be overstuffed with data.
RSVP, like other QoS protocols, sets up and tears down relationships with the devices it uses in the data delivery chain. That means it's possible to support two hundred VoIP users, but not all at the same time -- only the maximum allocation available can be used. Therein lies a trunk busy signal that an application should recognize if it's written correctly.
Windows 2000 supports several other initiatives that assist QoS in aiding applications, some of which are in conjunction with the RSVP protocol set. I'll cover these, along with how Windows-2000 policy controls work, in Part III of this series.