Last week, I covered one of the distinct advantages of Windows 2000 -- its support for new network cards that are able to function autonomously and thus decrease CPU and bus utilization. But the keys to Windows 2000 network performance amount to more than network card and bus efficiency. While getting data in and out of a server is important, you should also consider several other factors when striving to improve the overall performance of networks running Windows 2000 Server editions.
These factors include, for example, the time-sensitivity of your network traffic, appropriate compression methods, and transmission prioritization. Quality of service (QoS), which Windows 2000 supports to some extent, encompasses all these factors and more.
Consider that there are two types of data: the kind that needs no special timing and the kind that's time-sensitive. When you load an application or data into a client or server, you won't often care about how fast it actually gets there so long as it's a reasonably short amount of time. But there are several classes of applications for which the timing of data arrival is especially important.
Generally, applications that must convert data from analog to digital formats are bound to preserve the timing associated with the method that was used to digitize the analog data. To ensure correct reassembly, these applications record the timing values of an analog stream during its conversion to digital. Sampling occurs at specific intervals of speed, to correlate the resulting digital stream to the original analog signal. Transmission flow rates must also be kept within specified bounds so that receiving devices can then reassemble the analog signal correctly on playback.
In other words, while nonanalog media just simply arrive, the timing requirements of voice, video, and multimedia fall outside the methods employed by normal get-there-when-you-can delivery mechanisms, and must be delivered within a time domain. Such data is termed isochronous, which means "timed separately."
Different isochronous data streams have different sampling, linking, and compression requirements. As an example, voice streams can be sampled satisfactorily at a low analog-to-digital data rate and can use one of two linking methods, either half duplex (one channel sent one direction at a time) or full duplex (two channels established bidirectionally).
Compression and latency
Codecs (short for compressor/decompressors) are used for voice and many other types of analog media, because raw, uncompressed data can require enormous transfer rates.
Codecs squeeze streams down by removing quiet time and interjecting predictability tokens that represent long events of the same data -- a byte for a long pause as an example. There are two types of compression, lossy and nonlossy. The less lossy a codec, the more faithfully it can decompress data back to its original form with no errors. Most codecs are lossy, although the amount of loss is usually undetectable to human ears and eyes. The payoff is smaller transmission and associated file sizes, and fewer network latency-induced problems.
One of the Holy Grails of compression is the ultimate nonlossy codec, and algorithm-heads have a field day when they obtain even a fraction of a percentage-point increase in compression without losing data. Nonlossy compression is "expensive" because compression rates are typically low. Compression ratios, which define codec efficiency, can range from 2:1 to as high as 20:1, with higher levels resulting in increased data degradation.
In my next column, I'll talk more about how compression works and how you can have a direct bearing on a codec's results simply by choosing specific compression policies.
When good video goes bad
All isochronous media has a breaking point at which quality degrades or timing problems become objectionable.
Take digitized voice, which, like any other isochronous media, is sensitive to latency. Network-delay-induced gaps in conversations can cause objectionable pauses in a conversation. Because only a very short amount of conversation time can be buffered before gaps result, network congestion can affect the quality of conversation.
Early Internet telephony generated occasionally humorous results, when IP packets would become highly buffered, or duplicate packets would be sent -- creating what some called the M-M-Max H-H-Headroom effect, after the digitally stuttering TV character. Today, streaming media, such as Internet radio broadcasts, can suffer the same fate. The good news is that there are ways to control the problem without deploying enormous amounts of available bandwidth in an effort to provide guaranteed noncongested data pipelines.
Video data rate requirements are far greater than those for voice, but ever more efficient codecs, coupled with reduced raster sizes, limited color spectra, and other techniques make digitized video usable even at dialup connection speeds. Bidirectional video is trickier because, like voice conversations, videoconferencing isn't very tolerant of buffering or latencies in network communications.
By definition, isochronous media streams must be as uninterrupted as possible. The term quality of service (abbreviated QoS and pronounced "kwoss") is used to describe the action of differentiating the flow and congestion tolerance requirements of data streams. Isochronous voice conversations, for example, usually require higher quality of service than other apps -- if the value of quality is important to an organization.
Few companies actually look at their data streams to discern what types of benefits are available to enhance streamed media quality; most organizations haven't looked at how to improve voice over IP (VoIP) and videoconferencing, because they still separate the resources used for data networking from those used for communications networking. That's going to change much more rapidly over the next few years, because networking infrastructure is becoming ever more intimately tied to other organizational communications infrastructure.
Considering the data flows
Defining data-type service levels is important. One of the first acts that many organizations perform in this area is to find out how to prioritize business-related network use over less "important" types of networking data-flow relationships. Preventing activities such as user Web surfing, email, and other applications from dominating available bandwidth has become important for large and small organizations.
Prioritizing one type of network activity over another is actually a rather huge hurdle for many IT departments, because it puts IT staff in the difficult position of having to prioritize business communications.
Bandwidth provisioning vs. QoS
Bandwidth provisioning is a technique used to prioritize applications by protocol type. There are several products in the marketplace that can identify specific types of traffic, such as email, Web surfing, and even application-specific traffic such as Lotus Notes.
It's short work to then put ceilings on traffic by protocol type. Generally, this is accomplished by brute force methods that limit by application type the amount of data that can be transported through critical junction points such as bridgehead servers, junctions near firewalls, and so on. Limitation clamps can be imposed on applications such as email, push services, Web browsing, or other applications considered "low priority" in business situations. The remaining available bandwidth is then used for business applications and associated data.
The Windows 2000 link
Unlike predecessor versions of Windows Server editions, Windows 2000 supports virtually every type of QoS protocol method. While this is quite an advance for Windows server users -- there's been reasonably good QoS support in prior versions of Windows, but nothing like the spread in the current edition -- it's only a first step.
Of the differing types of QoS available in Windows 2000, some are useful, others esoteric, and some may never be used in the real world. What are they? What are they good for? Are they realistic? How do I use them? Do I want to use them yet? What about bandwidth management?
I answer these questions and more after I get back from the Networld+Interop exhibition in Las Vegas.