104 Chapter 2: QoS Tools and Architectures

The Good-Old Common Sense QoS Model

Most people already have some idea of what would be useful, and not so useful, regarding implementing QoS in a network. If you have been reading this book from the beginning of Chapter 1, you already know about the how QoS tools affect bandwidth, delay, jitter, and loss. You also know some of the traffic characteristics of voice, video, and data flows. You have seen the basics of how each general category of QoS tool works (Chapter 1), and you have at least seen a list of QoS tools in IOS (within this chapter).

With that in mind, you can mostly ignore DiffServ and IntServ and succeed at deploying QoS. Of course, you need to know more about each specific QoS tool, and you need to know how to configure the tools. You need to follow some good QoS design principles as well. However, you do not have to understand a lot about the DiffServ and IntServ models of QoS to succeed with QoS deployments.

However, most readers will find information about DiffServ and IntServ important for at least two reasons. First, the information is on the Cisco QoS exams! The other reasons is that the two formal models for QoS, DiffServ and IntServ, formalize and describe good QoS design models. You can deploy QoS without considering the concepts behind DiffServ and IntServ, but you will be better prepared for deploying QoS if you take the time to understand each model.

For those who are relatively new to QoS, before covering the depth and details in the upcoming chapters, you should consider some basic terms, concepts, and strategies for applying QoS in a network. This book summarizes these common strategies into what I call the “Good-Old Commonsense” (GOCS) QoS model, which summarizes what most people think of as just plain common sense about how to apply QoS. If you understand the GOCS model, you will already

The Good-Old Common Sense QoS Model 105

understand more than half of the concepts behind DiffServ, without letting the vast amount of terminology get in the way.

GOCS Flow-Based QoS

A flow consists of all the packets about which the following are true:

•All packets use the same transport layer protocol (for instance, UDP or TCP).

•All packets have the same source IP address.

•All packets have the same source port number.

•All packets have the same destination IP address.

•All packets have the same destination port number.

The slightly different, but just as exact definition, is that a flow consists of the packets between two IP sockets. For instance, a web browser on a PC, connecting to a server, creates a flow. (Actually, in the case of HTTP, it may create multiple TCP connections, which would actually be multiple flows.) Regardless, consider Figure 2-9. In this network, one flow exists from Hannah to Server1’s web server.

Figure 2-9 GOCS Approach to QoS for a Single Flow

Single Flow: Hannah’s Browser to Server1 Web Server

-Classify into Flows

-Apply Other QoS Tools, per Flow

-Performed at Each Router

Server 1

301

The Good-Old Common Sense QoS Model 107

This figure shows four flows. Even though Vinnie sends all packets for both flows to Server1, they are in two different flows, because each of the two browser windows would open separate TCP connections, with different source TCP port numbers. (Note: HTTP 1.1 could cause multiple connections to be opened; FTP uses a control and data connection, which would result in two flows.) However, assume that only four flows exist at this point.

How does the GOCS model with flow-based tools change with multiple flows? Well, not much. Each flow must be identified, based on its unique source/destination address/port values. The QoS actions at each router may be different for each flow—for instance, maybe FTP just gets leftover bandwidth, or maybe Hannah gets better treatment for her web flow than does Vinnie. The reasons and rationale behind deciding what traffic gets what QoS treatment will change from network to network, but the basic process works the same:

Flow-based QoS tools provide some advantages and some disadvantages. Because each separate flow is identified, the QoS tools can literally provide different levels of service to every flow. A single queue could be used for each flow, for instance, giving each a different reserved bandwidth. With a large number of flows, however, the overhead associated with keeping state information about each flow can be a lot of work. Imagine a router with 1000, or even 10,000, concurrent flows, which would not be surprising in the Internet—and then imagine the overhead in trying to perform queuing with 1000 or 10,000 queues! So, flow-based QoS tools provide a great deal of granularity, but they do not scale as well as some other QoS tools that do not consider flows (particularly with very large networks or the Internet).

Engineers gain another advantage and disadvantage when configuring flow-based QoS tools. Suppose that your job is to explicitly configure the routers in Figure 2-10 as to which source and destination IP addresses and ports to use to find each flow. And instead of 4 flows, there are 1000 concurrent flows. Over the course of a day, there may be hundreds of thousands of flows. Your job is to find the details that make each flow unique and configure it! Well, that would be rather ridiculous, a lot of work, and mostly impractical. Therefore, flow-based tools typically require no configuration to match and classify packets into a flow. However, some configuration control is lost.

The following list summarizes the key points about flow-based QoS tools:

•Flow-based QoS tools automatically recognize flows based on the source and destination IP address and port numbers, and the transport layer protocol.

•Flow-based tools automatically identify flows, because it would be impractical to configure parameters statically to match the large number of dynamically created flows in a network.