Total Traffic Classification
(CBWFQ in a DiffServ Model)
In the previous case study, we saw that we could effectively guarantee a certain
amount of bandwidth to a mission-critical application. But what if there were
many other applications that needed minimum bandwidth guarantees? (We will
address voice, and other truly latency-sensitive types of traffic in just a minute.)
We may need more granular control over how our applications behave under
WFQ. CBWFQ allows us to configure up to 64 distinct classes. However, we
probably would not want to put each application into a separate class. Not only
would we be limited in the amount of bandwidth we could allocate to the class
(the sum of all bandwidth cannot exceed the link speed), but it could also be
confusing having this many classes.
A best-practice approach would be to define just a few of the classes, and
categorize all applications into these classes based on expected bandwidth utilization
and the application’s tolerance of dropped packets.With this approach, applications
would be sharing bandwidth with others within the same class, but a
degree of granularity is added in addition to WFQ that would be adequate for
most networks.
The IP CoS header allows us to enumerate packets into eight levels of IP
precedence, two of them being reserved for network applications, leaving six
levels for user applications.We can map these IP precedence levels directly into
our network classes of service. Using a precious metal analogy, we would have six
classes of service, as shown in Table 8.3.