Understanding Application Needs

Understanding the needs of different applications is the key to developing an understanding of the many factors contributing to the selection of the most appropriate QoS options. Obviously, there are an enormous number of applications in use, but we can use some basic categories to define their needs and expectations in general terms.

One method is to define applications using some sort of classification, and then apply QoS based on specific classes. I have selected three applications to illustrate this principle- e-mail, World Wide Web traffic, and voice over Ethernet-each of which possesses different characteristics.

E-mail

A number of different e-mail packages exist on the market today, and all have idiosyncrasies of some sort. Nonetheless, the basic method of operation (from the perspective of the bottom layers of the OSI model) is very similar in all cases.

E-mail uses a store-and-forward transfer mechanism, gaining its reliability from the TCP protocol. Data is formatted by the application and by TCP and IP into a reliable sequence of datagrams (packets) that are individually transmitted to the server or e-mail client. Little in the way of QoS needs to be applied to e-mail, largely because the users and the application both agree that this is not an instantaneous protocol.

Figure 9.1 shows e-mail packets traversing a network. As you can see, Figure 9.1 shows an e-mail message traveling from host Terry to host Stephanie. The message is fragmented into packets that are sent across the intervening internetwork, and then are reassembled at the destination by the application. Because e-mail is designed from the top down to be a store-and-forward (rather than real-time) application, greater emphasis was placed on guaranteed delivery than on delay, and so each packet will be of the maximum size permitted by the media.

Figure 9.1: E-mail application fragments

Obviously, if the delay in packet delivery was so large that users complained and the system became unusable, then something would have to be done, but this would generally be a low priority.

WWW Traffic

All WWW traffic starts from somewhere. Assuming that you are connecting to the Web from a LAN, that's the first place where problems can affect the connection and the upload or download speed.

This is just a small part of the story, however. The weakest link in a chain always sets the strength for the whole chain, and the same is true of networks. So as far as transfer speed is concerned, we need to spend most of our time working on the narrowest bandwidth (generally the lowest speed). And that is unlikely to be the switched Ethernet LAN.

After all, your LAN is probably running 100BaseT, switched, possibly with duplex links to important machines. The connection to the Internet is probably through the company firewall (a packet-filtering engine introducing its own delay), and the Internet speed itself available to your PC is probably be a fraction of an E1 or T1 at best!

Tip 

Obviously, if the service runs too slowly to be of use, and if you can identify the switched Ethernet LAN that you are connected to as the choke point, then you need to do something about it. But for the moment, let's leave the problems with WWW to the WAN guys.

What is important to us is that the size of each WWW packet may be different. Even though we tend to equate being connected to a website as having a single flow, that is rarely true. The construction of modern sites and the surfing behavior of Internet users means that TCP sessions are being opened and closed all the time, and the download of different format content ensures that the service is very patchy (see Figure 9.2).

Figure 9.2: HTTP application fragments

Voice over Ethernet

Now, at last. Something that we can really get our teeth into! Voice traffic is very unusual, in that it presents an entirely different set of demands to an Ethernet LAN. We are all used to the usual pressures from applications, namely bandwidth and delay, but jitter is a new problem for us. In short, jitter is the variation in the delay experienced by successive packets in a flow.

Voice is a streaming protocol. As the analog signal is encoded and broken down into packets, each packet is transmitted across the network as a unique entity, and the whole is reassembled into a stream at the receiving end. Obviously, humans don't speak in packets, and we take pauses and breaks at random moments, uttering words when we need to. If the packets received at the end of the link are delayed too long, or if the delay is too variable for the decoder, then the voice stream cannot be properly reconstructed.

There is a name for this transmission type: isochronous. Derived from the Greek words for 'equal' and 'time,' it describes processes that require timing to be coordinated. In other words, isochronous traffic requires that data flow continuously and at a steady rate in close timing with the ability of the display mechanism to receive and display the image data. Figure 9.3 demonstrates how jitter can affect the output of the playback buffers.

Figure 9.3: Voice playback buffers

As you can see, the possibility exists for the playback buffer to be empty, full, or half-full. If the buffer is half-full, then a smoothly created output audio signal will result in good quality voice reception.

If the buffer is empty, then no audio signal output can be created; this is not a problem if the reason for the empty buffer is a genuine lack of transmitted data. But if the buffer is full, then there may be a problem. First, any new arriving packets will be dropped, and time is insufficient for them to be retransmitted, so they are lost forever. This, however, may not be the largest problem, because if the reason for the buffer alternating between full and empty is a variability in the arrival rate of voice-encapsulated data packets, then the output stream will be of poor quality.

Jitter is probably of greater significance than simple delay in voice networks, because (up to a certain limit) delay just means that the receiver has to wait a short time for the words. But jitter results in poor quality voice reception that may be unacceptable to the listener. Figure 9.4 illustrates a general design model for multimedia traffic, showing how voice will be integrated into the IP infrastructure. Obviously, we are focusing on the campus network, but you can see clearly that as IP datagrams carry voice into the IP cloud, inconsistencies start to appear in the delivery process.

Figure 9.4: Voice design model