QoS functionality in routers. It is
important to understand the characteristics of the applications
that need protection. Some applications tend to be sensitive to
latency or packet loss, while others are considered
"aggressive" because they are bursty or consume a lot
of bandwidth. If the application is bursty, determine if there
is a constant burst or a small burst. Is the packet size of the
application large or small? Is the application TCP or UDP
based? The table “Understanding the Characteristics of
Applications” provides some-high level guidelines .
Content 3.2 Implementing Cisco IOS QoS
3.2.6 Step 2: Define Traffic Classes After
identifying and measuring network traffic, use business
requirements to perform the second step: define the traffic
classes. A class is a group of network flows that share similar
characteristics. For example, an ISP might define classes to
represent the different service levels offered to customers. An
enterprise might define service level agreements (SLAs) that
give different levels of service to various applications.
Because of its stringent QoS requirements, voice traffic is
usually in a class by itself. Cisco has developed specific QoS
mechanisms, such as LLQ, to ensure that voice always receives
priority treatment over all other traffic. After you define the
applications with the most critical requirements, the remaining
traffic classes are defined using business requirements.
Example: Define Traffic Classes
A typical enterprise
might define the following five traffic classes as shown in
Figure based on department requirements or based on the
preponderance of a particular application in the network
traffic: - Voice: Absolute priority for VoIP
traffic.
- Mission-critical: Small set of
locally defined critical business applications. For example, a
mission-critical application might be an order-entry database
that needs to run 24 hours a day.
-
Transactional: Database access, transaction services,
interactive traffic, and preferred data services. Depending on
the importance of the database application to the enterprise,
you might give the database a large amount of bandwidth and a
high priority. For example, your payroll department performs
critical or sensitive work. Their importance to the
organization determines the priority and amount of bandwidth
you would give their network traffic.
- Best
effort: Popular applications such as e-mail and FTP could
each constitute a class. Your QoS policy might guarantee
employees using these applications a smaller amount of
bandwidth and a lower priority then other applications.
Incoming HTTP queries to your company's external website might
be a class that gets a moderate amount of bandwidth and runs at
low priority.
- Scavenger: The unspecified
traffic is considered as less than best effort. Scavenger
applications, such as BitTorrent and other point-to-point
applications, are served by this class.
Content 3.2 Implementing Cisco IOS QoS
3.2.7 Step 3: Define QoS Policy In the third step,
define a QoS policy for each traffic class as shown in Figure .
A QoS policy typically defines the following: - Discrete
groups of network traffic (classes of service [CoS]).
- Metrics for regulating the amount of network traffic for
each class. These metrics govern the traffic-measuring process
(metering).
- Actions to be applied to a packet flow
(per-hop behavior [PHB]).
- Any statistics gathering
required for a CoS (for example, traffic that is generated by a
customer or particular application).
When packets
pass to your network, QoS evaluates the packet headers. The QoS
policy determines the action that QoS takes. Defining a QoS
policy involves one or more of the following activities:
- Setting a minimum bandwidth guarantee
- Setting a
maximum bandwidth limit
- Assigning priorities to each
class
- Using QoS technologies, such as advanced
queuing, to manage congestion
Example: Define QoS
Policies
As an example, consider a network that has a
finite amount of bandwidth available. Using the traffic
classes, previously defined QoS policies can be mandated based
on the following priorities (with Priority 5 being the highest
and Priority 1 being the lowest): - Priority
5—Voice: Use LLQ to give voice priority always. Minimum
bandwidth of 1 Mbps.
- Priority
4—Mission-critical: Use CBWFQ to prioritize critical-class
traffic flows. Minimum bandwidth of 1 Mbps.
-
Priority 3—Transactional: Use CBWFQ to prioritize
transactional traffic flows. Minimum bandwidth of 1 Mbps.
- Priority 2—Best-effort: Use CBWFQ to prioritize
best-effort traffic flows that are below mission-critical and
voice. Maximum bandwidth of 500 kbps.
- Priority
1—Scavenger (less-than-best-effort): Use WRED to drop these
packets whenever the network has a tendency toward congestion.
Maximum bandwidth of 100 kbps.
Content
3.3 Selecting an Appropriate QoS
Policy Model 3.3.1 Three QoS Models The
following are three models for implementing QoS in a network as
illustrated in Figure : - Best-effort model: The
best-effort model does not use QoS. If it is not important when
or how packets arrive, the best-effort model is appropriate.
Figure summarizes the best-effort model.
- Integrated
services (IntServ): IntServ can provide very high QoS to IP
packets. Essentially, IntServ defines a signaling process for
applications to signal to the network that they require special
QoS for a period and that bandwidth should be reserved. With
IntServ, packet delivery is guaranteed. However, the use of
IntServ can severely limit the scalability of a network. Figure
is a simple illustration of the IntServ model.
- Differentiated services (DiffServ): DiffServ
provides the greatest scalability and flexibility in
implementing QoS in a network. Network devices recognize
traffic classes and provide different levels of QoS to
different traffic classes. Figure is a simple illustration of
the DiffServ model.
Content
3.3 Selecting an Appropriate QoS
Policy Model 3.3.2 Best-Effort Model The
basic design of the Internet provides for best-effort packet
delivery and provides no guarantees. This approach is still
predominant on the Internet today and remains appropriate for
most purposes. The best-effort model treats all network packets
in the same way, so an emergency voice message is treated the
same way a digital photograph attached to an e-mail is treated.
Without QoS, the network cannot tell the difference between
packets and, as a result, cannot treat packets preferentially.
These points are summarized in Figure . When you mail a letter
using standard postal mail, you are using a best-effort model.
Your letter is treated exactly the same as every other letter.
With the best-effort model, the letter may never arrive, and,
unless you have a separate notification arrangement with the
letter recipient, you may never know that the letter did not
arrive. Figure summarizes the benefits and drawbacks of best
effort model as follows: - Benefits:
- The
model has nearly unlimited scalability. The only way to reach
scalability limits is to reach bandwidth limits, in which case
all traffic is equally affected.
- You do not need to
employ special QoS mechanisms to use the best-effort model.
Best-effort is the easiest and quickest model to deploy.
- Drawbacks:
- There are no
guarantees of delivery. Packets will arrive whenever they can
and in any order possible, if they arrive at all.
- No
packets have preferential treatment. Critical data is treated
the same as casual e-mail is treated.
Content 3.3 Selecting an
Appropriate QoS Policy Model 3.3.3 IntServ