108Chapter 2: QoS Tools and Architectures

•Flow-based tools provide a great amount of granularity, because each flow can be treated differently.

•The granularity may create scaling problems when the number of flows becomes large.

GOCS Class-Based QoS

Most QoS tools do not need to differentiate between each flow. In the Figure 2-10, for instance, flows to web Server1 were identified. Most network engineers would want to treat those collective web flows the exact same way with their QoS tools. Therefore, most QoS tools tend to operate on the idea of a category, or class, of flows and packets. Consider Figure 2-11, for example, which has thousands of flows, all of which are classified into four types of traffic.

Figure 2-11 GOCS Approach to QoS with Classes

201

301

Class-based QoS tools do not have to identify each flow. However, they do need to identify packets based on something in the packet header—such as TCP destination port 80 for web traffic—and consider that traffic to be in one category or class for QoS treatment. Once again,

The Good-Old Common Sense QoS Model 109

the reasons and rationale behind deciding what traffic gets what QoS treatment changes from network to network, but the basic process works the same, but per class rather than per flow:

Unlike flow-based QoS tools, class-based QoS tools typically require the engineer to specify exactly what must be seen in the packet header to classify a packet. If this network currently has 4 flows to the web server, or 400, or 4000, if the classification criteria just states “all TCP port 80 traffic,” no additional configuration is required as the network scales. Both flow-based and class-based tools need to examine every packet to classify the packet into the appropriate flow or class. Because class-based tools typically only need a small number of classifications, however, the tool can reasonably be configured to specify the types of traffic that get added to each class.

Class-based QoS tools can use more complex rules to classify packets than do flow-based tools. For instance, a class-based tool can examine subsets of the IP addresses (matching a subnet, for example), the incoming interface, the URL for web traffic, and anything that an IP ACL can match. For flow-based tools, the router always look at five fields, all in the IP header—Source and Destination Address, Source and Destination Port, and the Protocol Type field (which identifies the transport layer protocol). In short, classification options for class-based tools tend to be much more varied and functional, but they require more configuration work to take advantage of the different options.

Flow-based and class-based QoS tools both have a useful place in a QoS strategy for a network. Most QoS tools tend to be based on general classes, as opposed to looking at each individual flow.

Classification and Marking at the Edge

Class-based tools have advantages and disadvantages as well. The engineer can exercise great control over the packets placed into the classes or categories used in a network. Because a small number of categories are used, in most cases fewer than 10, the configuration scales. For instance, you build a network and choose four categories for packets. As the network grows, you can keep using the same four categories, and even with growing numbers of packets and routers, the number of classes can remain the same.

However, the same explicit classification configuration details can be the cause of two particular types of problems. For instance, suppose that you have 500 sites, with at least one router and several switches at each site. At each site, you want to classify packets into the same four categories. You need to use six different IOS QoS tools—which is not an unreasonable choice,

The Good-Old Common Sense QoS Model 111

Figure 2-12 GOCS Design: Mark Packets near the Edge of the Network

Server 1

201

301

Marked with QoS=1: Lots of Flows to Server1 Web Server

Marked with QoS=2: Lots of Flows to Server1 FTP Server

Marked with QoS=3: Lots of VoIP Payload Flows

Marked with QoS=4: Lots of VoIP Signaling Traffic

It is possible to plan QoS classes for an enterprise network. However, planning classes for all networks in the Internet is a bit more challenging! For instance, although everyone may agree that VoIP and video may need different treatment than data over the Internet needs, they probably do not agree about differentiation between different types of data traffic. Also a company paying a premium to a service provider may expect better service—translated, better QoS treat- ment—so the classification may be based on the source IP addresses, and may be different for different ISPs.

Therefore, although the political and business challenges of Internet-scale QoS may be difficult, cases will still exist where QoS can be implemented over the Internet. Consider Figure 2-13, which shows two companies, each connected to two different ISPs.

112 Chapter 2: QoS Tools and Architectures

Figure 2-13 QoS Between Different Companies over the Internet

Two key QoS issues exist in this case. First, the parties must agree to the different classifications of packets. In this example, all four networks agree to the need for four classes. (Agreement will not always occur!) For instance, McCoy Enterprises may want a different class for customer web traffic versus supplier web traffic. Even if all companies want these same general categories, it is difficult to effectively match the correct traffic for all companies connected to the Internet, because every company has different customers and suppliers. Therefore, QoS across the Internet may well end up using general categories—categories such as voice, video, voice/video signaling, important data, and not-so-important data.

Even with general categories agreed upon, not every network chooses to mark the IP packets with the same value to denote the same class. Figure 2-13 shows just such a case, where ISP1 and ISP2 agree to the values to use when marking packets, but McCoy Ordinance and Hatfield Gunsmiths, two long-time competitors, do not agree on what marked values to use.

Three commonsense QoS design choices help overcome common Internet QoS issues:

•If neighboring autonomous systems do not agree about what traffic should be in each class, each autonomous system should reclassify ingress traffic based on more complex matching of packets based on the large variety of packet header fields.

•If neighboring autonomous systems do agree about the classes, but not the marked values, each autonomous system should reclassify ingress traffic based on simple matching of packets based on the previously marked fields in the IP header, as shown in Figure 2-13.