Understanding Application Needs

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.
Understanding Application Needs
639
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 20.1 shows e-mail packets traversing a network, comprising 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.

Quality of service (QoS)
is a largely new concept to bring into
the world of LANs. Traditional Ethernet networks have been constructed
on base protocols that allow for best efforts delivery and
little else. Legacy switched networks—if you will pardon the term—have been designed and built
using the same principles. After all, Ethernet suffers from collisions, broadcasts are LAN-wide
random events, and frame sizes are unpredictable. All of this pretty much guarantees that quality
of service will also have some random aspects, doesn’t it?
Well, maybe not. Over the last few years, considerable effort has been applied to the development
of techniques designed to provide the Internet Protocol (IP) with some added bells and whistles.
Many of these are associated with providing quality of service beyond the traditional best efforts
capabilities of IP in order to make the Internet a better place for the transport of time-sensitive traffic
such as voice, video, and multimedia applications.
Once these developments started to bear fruit, much of the effort shifted away from IP
toward the edges of the networks. The idea is that if we can somehow create QoS-based
switched networks in the campus, then it might be possible to create end-to-end QoS provision
from LAN to LAN across the Internet.
This chapter deals primarily with the QoS options currently available on Cisco switches. We
will have to start, however, with some detail about the QoS options in IP, so we can see how
they may also be employed in multilayer switched networks and how the layer 3 and layer 2
QoS options map together at the campus edge.
The last section of this chapter, “Redundancy in Switched Networks,” looks at redundancy in
several of its implementations, including router redundancy and server redundancy. Although these
techniques may not normally be considered QoS protocol, they do nonetheless add to the general
availability of network services. The chapter ends with a brief discussion of one of the more interesting
technologies to emerge from the new-look Ethernet—transparent Ethernet.