Skip to content
Log in Sign up My account

4.1 QoS Strategy from Business Requirements

Blueprint 4.1: QoS strategies based on business requirements (DiffServ, IntServ)

  • Turn business applications into traffic classes with measurable targets
  • Choose between the 4-class, 8-class and 12-class models
  • Compare the DiffServ and IntServ architectures and know where a hybrid fits
  • Decide where the trust boundary sits and who is allowed to mark

ENSLD asks you to design QoS, not to type it. The question usually starts with a list of applications and a business statement ("the CEO's video calls must be clear, the backup must not hurt anything") and asks which strategy or marking scheme satisfies it. The mechanics of MQC and policy reading are in ENCOR QoS. This page covers the thinking that comes before any policy is written.

Start with the business, not the queue

QoS does not create bandwidth. It decides who suffers when there is not enough. A sound strategy follows the same sequence every time:

  1. Inventory the applications and decide which ones the business cares about. Use NetFlow, NBAR2 or Catalyst Center application visibility, not guesses.
  2. Group them into classes by what the traffic needs from the network (delay, jitter, loss, bandwidth), not by who owns the application.
  3. Assign a marking and a per-hop treatment to each class.
  4. Place the policy at the trust boundary, then at every point where congestion can occur.
  5. Measure and adjust. A QoS design is never finished on day one.

Applications are rarely equal, and most enterprises have one or two that are business critical, a handful that are important, and a long tail that is not. The common mistake is to promote too many applications into the "important" classes until nothing is protected.

What each traffic type needs

These are the widely used Cisco design targets. Treat them as guidelines for choosing a class, not as a contract.

Traffic Delay (one way) Jitter Loss Bandwidth behaviour
Voice (bearer) 150 ms or less 30 ms or less 1% or less Constant, small packets
Interactive video 150 ms or less 30 ms or less 0.1 to 1% Bursty, variable
Streaming video 4 to 5 seconds Not critical (buffered) 5% or less Elastic
Call signalling Not critical, but a lost packet delays a call Low Low Light
Transactional data Application dependent Not critical Low (TCP retransmits) Elastic
Bulk data Not critical Not critical Tolerates loss Elastic, greedy

Voice is the easy design driver. A G.711 call uses about 80 kbps per call at Layer 3 with 20 ms packetisation and about 24 kbps for G.729, before Layer 2 overhead. Sizing the priority queue is therefore a matter of counting simultaneous calls, which a call admission control policy limits.

Class models: 4, 8 or 12 classes

The number of classes is a trade-off between precision and operational cost. Cisco's design guides publish three reference models based on the same RFC 4594 service classes.

4-class model 8-class model 12-class model (RFC 4594 based)
Real-time (EF) Voice (EF) Telephony (EF)
Signalling and critical data Interactive video (AF41) Real-time interactive (CS4)
Transactional data Streaming video (AF31) Multimedia conferencing (AF4x)
Best effort and scavenger Network control (CS6) Broadcast video (CS5)
Signalling (CS3) Multimedia streaming (AF3x)
Transactional data (AF21) Network control (CS6)
Best effort (0) Signalling (CS3)
Scavenger (CS1) Operations, administration, management (CS2)
Transactional data (AF2x)
Bulk data (AF1x)
Scavenger (CS1)
Default (0)

Choose the smallest model that separates the traffic the business cares about. A small branch with voice and a few cloud applications is well served by four or five classes. A campus carrying broadcast video, telepresence and a managed operations network justifies the 12-class model. Whatever you choose, use the same model end to end, because every extra class is another place where markings can be misread.

graph LR
  A["Applications"] --> B["Requirements:<br/>delay, jitter, loss, rate"]
  B --> C["Classes and markings"]
  C --> D["Per-hop behaviours:<br/>priority, bandwidth, drop"]
  D --> E["Policy at each<br/>congestion point"]

DiffServ versus IntServ

The blueprint names both architectures explicitly. They solve the same problem at opposite ends of the scale.

DiffServ (RFC 2474, RFC 2475) IntServ (RFC 1633, RSVP RFC 2205)
Model Coarse classes, per-hop behaviour Per-flow reservation
Signalling None. Marking in the packet header RSVP, hop by hop, before traffic starts
State in the network Per class, small and static Per flow, on every router in the path
Scalability High Low in the core, because state grows with flows
Guarantee Statistical. Depends on provisioning Explicit, for admitted flows
Admission control No, unless added separately Yes, built in
Typical use Almost every enterprise Small, high value flows where a hard guarantee matters

DiffServ uses the six DSCP bits of the IP header to select a per-hop behaviour (PHB). EF gives low loss, delay and jitter, AF gives a minimum share with drop precedence, and CS keeps compatibility with IP Precedence. Every router makes the decision independently, which is why consistent configuration matters so much.

IntServ has two service types: guaranteed service (a firm delay bound) and controlled-load (service like an uncongested network). RSVP reserves bandwidth along the path and each router must keep soft state for each flow and refresh it. That cost is why IntServ never became a general Internet or enterprise architecture.

The hybrid answer. In modern designs you rarely pick one. DiffServ does the forwarding treatment, and a small amount of RSVP or an equivalent call admission control mechanism protects the priority queue from being oversubscribed. The classic example is a voice platform that uses RSVP to refuse a call when the WAN priority queue has no room, rather than letting the new call damage the existing ones. If a question says "classes are enough but we must stop the 31st call degrading the first 30," the answer is admission control layered on DiffServ, not more bandwidth in the queue.

Exam trap

IntServ is not "better DiffServ". It gives a hard guarantee at the price of per-flow state on every hop. When a scenario involves thousands of flows or a large WAN, the scalable answer is DiffServ. When it says "reject a call rather than degrade existing calls," look for admission control or RSVP.

The trust boundary and who may mark

Marks are only useful if they can be trusted. Decide where the network starts believing them.

Placement Behaviour Use when
Trust at the end device Accept the host's markings Controlled endpoints only, such as managed servers
Conditional trust at the access port Trust DSCP or CoS only when CDP or LLDP identifies a phone Standard campus design
Trust at the distribution or edge Reclassify everything on entry Untrusted access, guest or contractor ports
No trust, re-mark in the access layer Classify with ACLs or NBAR2 and write fresh markings PCs, BYOD, anything an end user controls

A user who can mark their own traffic as EF can take priority away from real voice, so untrusted ports should classify by application or reset the marking to default. Placing the boundary as close to the source as possible keeps unwanted marks off the rest of the network and spreads the classification work across many access switches rather than concentrating it on one distribution or WAN router.

At a service provider handoff the boundary moves again. The provider will sell a small number of classes (often three to six) and will police traffic that arrives with a marking it did not sell. The enterprise therefore remarks at the WAN edge to the provider's scheme and remarks back on the way in. A request for 12 end-to-end classes over a provider that supports four means the design must map several enterprise classes into each provider class and accept the loss of separation inside them.

Tunnels and encryption

Classification needs to see the field it is matching. When traffic enters a GRE or IPsec tunnel the original DSCP is copied to the outer IP header by default, so the underlay still sees the marking. But an egress policy on the physical interface of an encrypted tunnel cannot see inner ports or the original ACL match, because the payload is encrypted. qos pre-classify makes the router classify on the clear-text header before encryption. In a design review, "the markings are right but the WAN policy is not matching" is often a tunnel, an encryption or a provider remark problem rather than a policy bug.

interface Tunnel10
 tunnel source GigabitEthernet0/0/0
 tunnel destination 192.0.2.10
 qos pre-classify                     ! classify on inner header before the tunnel encapsulates

Design exercise

Scenario. A retailer has 120 branches, each with a 20 Mbps Internet link and a 10 Mbps MPLS link from a provider that offers three classes (real-time, business, best effort). Branch traffic is IP phones (G.711), point-of-sale transactions to a data centre, inventory updates that run overnight, and staff web browsing. Head office wants video conferencing to be added later. The WAN team is small.

Requirements.

  • POS transactions must complete quickly during the working day.
  • Calls must be clear.
  • Overnight inventory sync must not slow POS traffic if it runs late.
  • The design must be operable by a small team.

Constraints.

  • Provider supports only three classes.
  • Branch access switches are Catalyst 9000.

Which strategy would you propose?

Model answer

Use an 8-class enterprise model inside the campus and branch, mapped to the provider's three classes at the WAN edge.

  • Classify and mark at the branch access switches. Trust DSCP from Cisco phones through conditional trust, and re-mark everything from PCs by application with NBAR2. POS is marked AF21 (transactional), inventory sync AF11 (bulk), browsing default or CS1 for non-business sites.
  • At the WAN edge, map EF and CS3 to the provider's real-time class, AF21, AF31 and AF41 to the business class, and AF11, CS1 and default to best effort. Because video arrives later, the AF41 mapping is reserved now and needs no redesign.
  • Apply a hierarchical shaper to the 10 Mbps MPLS circuit with the child queuing policy underneath it. Without the shaper, a 1 Gbps router port never congests and the queuing never acts.
  • Size the priority queue by call count. Ten simultaneous G.711 calls need about 800 kbps at Layer 3, so a priority class of 10 percent holds that with margin. Anything more risks starving the business class.

Rejected alternatives.

  • 12-class model. The provider collapses it to three classes anyway, and the added precision costs a small team operational effort for no WAN benefit.
  • IntServ/RSVP on every branch. Per-flow state on 120 branches for traffic that DiffServ already serves adds complexity without solving the stated problem.
  • Trusting all markings from the access ports. A PC or a compromised device could mark traffic EF and take the priority queue from phones.
  • More bandwidth only. Cheaper per month than a redesign, but the overnight sync would still compete with POS whenever it ran late.

Quick check

A design needs a firm guarantee that a new video call is refused if the WAN cannot carry it, but the network has thousands of other flows. What is the right architecture?

DiffServ for per-hop treatment of all traffic, plus an admission control mechanism (such as RSVP for the video flows only) at the edge. Full IntServ everywhere does not scale.

Why do you re-mark traffic at the WAN edge when using a provider with fewer classes than the enterprise?

The provider polices or re-marks anything outside the classes it sold, so the enterprise maps its classes to the provider's markings on the way out and maps them back on the way in.

An access port connects a PC behind an IP phone. What trust setting is the best practice?

Conditional trust (CDP or LLDP identifies the phone) so the phone's markings are trusted, while the PC's markings are not.

References

  • Cisco Enterprise QoS Solution Reference Network Design Guide (search "Enterprise QoS SRND" on cisco.com)
  • Modular QoS CLI Configuration Guide, Cisco IOS XE (search on cisco.com)
  • RFC 2475 (DiffServ architecture), RFC 4594 (configuration guidelines for DiffServ service classes), RFC 2205 (RSVP), RFC 1633 (IntServ), all at rfc-editor.org
  • Cisco Live On-Demand Library: search "QoS design" and "campus QoS"