Understanding QoS: Why It Matters in Networking

Have you ever wondered why some applications on your network run smoothly while others lag or buffer endlessly? That’s where QoS, or Quality of Service, comes in. QoS is all about managing network traffic so that the most important applications get the performance they need. Whether it’s a video call, online gaming, or streaming a movie, QoS helps make sure the right traffic gets priority.

In this blog, we’ll break down what QoS is, why it’s important, and how it actually works in simple terms. By the end, you’ll have a clearer picture of how networks handle different types of traffic and why QoS plays such a big role in making our online experience better.

---

From Traditional Phones to IP Phones

Before diving into IP Phones, let’s take a quick look at how traditional telephones worked. Old phone systems relied on POTS (Plain Old Telephone Service), which used analog signals to carry voice. These calls traveled over the PSTN (Public Switched Telephone Network), a huge global system of circuit-switched lines. When you made a call, a dedicated path was set up between you and the other person until the call ended.

It worked well for decades, but it wasn’t very efficient. Every call required its own dedicated line, and adding more users meant building more physical infrastructure.

Now, enter IP Phones. Instead of using analog signals, IP Phones convert your voice into digital packets and send them over a data network the same one that handles your internet traffic. This approach is called VoIP (Voice over IP). It’s cheaper, more flexible, and doesn’t require a separate telephone network like PSTN.

Most IP Phones have three internal switch ports:

1. Port for the phone itself – this connects the phone to the network, just like a computer would.

2. Port for the PC – many IP Phones let you plug your computer into the phone, so both the phone and PC share the same network cable.

3. Port for power (PoE or adapter) – IP Phones can receive power through the network cable (Power over Ethernet), or by using a regular power adapter.

This design makes IP Phones easy to integrate into an existing network. You don’t need separate wiring for phones and computers. The phone acts like a small switch, passing data through while still giving priority to voice traffic.

---

How Voice and Data Traffic Are Separated

When an IP Phone and a PC share the same cable, the switch needs a way to tell their traffic apart. This is where VLANs and tagging come in.

• Voice Traffic (Tagged): The IP Phone marks its traffic with a special tag that identifies it as part of the Voice VLAN. Because of this tag, the switch knows those packets belong to the voice network.

• Data Traffic (Untagged): The PC, on the other hand, usually sends traffic without any tag. The switch then treats this traffic as part of the Data VLAN, which is the default VLAN on that port.

So even though both devices share the same physical cable, their traffic stays logically separated. The phone’s packets are tagged and prioritized, while the PC’s packets remain untagged and handled normally.

Why do it this way?

1. QoS Priority: Tagged voice traffic can be recognized and given higher priority over untagged data traffic.

2. Efficiency: You don’t need extra cabling for phones and computers. They just share the same port while still staying in separate VLANs.

3. Clarity: The switch always knows which traffic is voice and which is data, making it easier to apply policies and troubleshoot issues.

In short, the phone tags its own traffic for the Voice VLAN, while the PC stays untagged and goes to the Data VLAN. The switch keeps them apart and ensures calls don’t get disrupted by someone’s heavy internet usage.

---

Voice VLAN Configuration

Now that we know why voice and data traffic need to be separated, let’s look at how a switch is actually configured for an IP Phone and PC setup.

Imagine you have a switch port where both an IP Phone and a PC are connected. The goal is to put the PC in the Data VLAN and the IP Phone in the Voice VLAN. Here’s how it’s usually done on a Cisco switch:

Switch(config)# interface fa0/1
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# switchport voice vlan 20

Breaking it down:

• switchport mode access → sets the port as an access port (not trunk).

• switchport access vlan 10 → puts the PC (untagged traffic) in VLAN 10, the Data VLAN.

• switchport voice vlan 20 → tells the switch that tagged traffic from the IP Phone belongs to VLAN 20, the Voice VLAN.

With this setup:

• Any traffic from the PC is untagged and goes straight into VLAN 10.

• Any traffic from the IP Phone is tagged and automatically placed into VLAN 20.

The switch now knows how to separate and prioritize traffic. From here, QoS policies can be applied to ensure voice packets always get better treatment than normal data packets.

---

Power over Ethernet (PoE)

Now that we’ve covered how voice and data traffic are separated with VLANs, there’s another important piece that makes IP Phones practical in a network: Power over Ethernet (PoE).

Unlike traditional phones that simply plugged into a wall jack for both connection and power, IP Phones need electricity to run their digital hardware. You could use a power adapter for each phone, but imagine an office with hundreds of phones. That would mean a lot of cables, outlets, and clutter.

This is where PoE comes in. With PoE, the same Ethernet cable that carries data can also deliver power to the device. That means your IP Phone only needs a single cable for both network connection and power, making installation much simpler and cleaner.

Switches that support PoE can detect if a connected device (like an IP Phone, access point, or even a camera) needs power. If it does, the switch provides just the right amount of power through the cable. If the device doesn’t need it, the switch won’t send power.

---

PSE (Power Sourcing Equipment)

The PSE is the device that provides power. In most networks, this is your switch. A PoE-capable switch can detect when a device needs power and then send it through the Ethernet cable. Some PoE setups can also use a midspan injector, which sits between a non-PoE switch and the device, adding power to the line.

---

PD (Powered Device)

The PD is the device that receives power from the network cable. In our case, the IP Phone is a powered device. But PoE isn’t limited to phones. You’ll also find wireless access points, IP cameras, and even some small IoT devices working as PDs.

---

How It Works

When a PD is plugged in, the PSE doesn’t just blast power right away. Instead, it first checks if the device actually supports PoE. If it does, the PSE negotiates how much power is needed and then starts supplying it. This prevents damage and ensures each device gets only the amount it requires.

PoE Standards (Simplified)

• IEEE 802.3af (PoE): Up to 15.4 watts of power per port.

• IEEE 802.3at (PoE+): Up to 30 watts per port, for hungrier devices like video phones or access points.

• IEEE 802.3bt (PoE++): Can go much higher, up to 60–90 watts, powering things like LED lighting or even laptops.

With these standards, network admins can support different types of devices without needing extra power cables everywhere.

---

Power Policing

Since PoE lets switches supply power to devices, there needs to be a way to control and monitor how much power each device uses. That’s where power policing comes in.

Power policing is a feature that checks the power consumption of a connected device (like an IP Phone or access point) and makes sure it doesn’t draw more than it’s allowed. If the device tries to pull too much power, the switch can take action like shutting down the port or just sending a warning depending on how you configure it.

This is useful because:

• It prevents faulty or misconfigured devices from overloading the switch.

• It helps manage power budgets, especially when you have many PoE devices connected.

• It adds an extra layer of safety and control in the network.

Configuring Power Policing (Cisco Example)

Switch(config)# interface fa0/1
Switch(config-if)# power inline police

With this command, the switch monitors the device’s power usage. If the device exceeds its allocated power limit, the switch will take action (by default, it shuts down the port and logs an error).

You can also configure what happens when a violation occurs. For example:

Switch(config)# interface fa0/1
Switch(config-if)# power inline police action err-disable

• err-disable → shuts the port down if the device draws too much power.

• Some switches also support log or trap, which just record the event without shutting down the port.

This ensures that devices like IP Phones only use the power they are supposed to, keeping the network stable and safe.

---

Verifying Power Policing

After enabling power policing on a port, you can use the show power inline police command to see if any violations have occurred.

Example:

Switch# show power inline police

Interface  Admin Police Oper Police Violations
---------  ------------ ----------- ----------
Fa0/1      on           on          0
Fa0/2      on           on          2
Fa0/3      off          off         0
Fa0/4      on           on          0

Breaking it down:

• Admin Police – shows if power policing is configured (on or off).

• Oper Police – shows if it’s currently active on the port.

• Violations – the number of times a connected device has tried to draw more power than allowed.

In this example:

• Port Fa0/1 has policing enabled and no violations.

• Port Fa0/2 has had 2 violations meaning the device connected there attempted to draw more power than it should.

• Port Fa0/3 doesn’t have power policing configured.

This command is handy for troubleshooting and making sure your PoE devices are staying within their limits.

---

Power Inline Police Action

When you enable power policing, you can also decide what the switch should do if a device tries to draw more power than it’s allowed. This is controlled by the power inline police action command.

The main options are:

1. err-disable (default)

   • If the device violates the power limit, the switch shuts down the port.

   • The port will stay disabled until you manually re-enable it or use an automatic recovery feature (errdisable recovery).

   • This is the strictest action and is often used when you want to protect the switch from misbehaving devices.

2. log

   • The switch doesn’t shut the port down.

   • Instead, it just records the violation in the log.

   • Useful if you only want visibility of power issues but don’t want to cut off the device.

3. trap

   • Similar to log, but it sends an SNMP trap to your monitoring system.

   • Handy if you’re using a network management tool to keep track of power usage.

Example Configurations

Switch(config)# interface fa0/1
Switch(config-if)# power inline police
Switch(config-if)# power inline police action err-disable

or

Switch(config)# interface fa0/1
Switch(config-if)# power inline police
Switch(config-if)# power inline police action log

or

Switch(config)# interface fa0/1
Switch(config-if)# power inline police
Switch(config-if)# power inline police action trap

This gives you control over how strict the switch should be when handling devices that exceed their power allocation.

---

Quality of Service (QoS)

So far, we’ve talked about how IP Phones connect to the network using VLANs and PoE. But even with those set up, there’s still one big challenge: making sure voice traffic always sounds clear, especially when the network gets busy.

This is where Quality of Service (QoS) comes in. QoS is a set of techniques that manage network resources so that important traffic like voice and video gets priority over less time-sensitive data, such as file downloads or web browsing.

To understand QoS, it helps to first know the four main factors that affect voice quality:

1. Bandwidth

   • Bandwidth is the amount of data that can be transmitted over a network link in a given time.

   • Think of it like the width of a road: the wider the road, the more cars (packets) can pass through at once.

   • For voice, you don’t need a lot of bandwidth per call, but you do need consistent availability.

2. Delay (Latency)

   • Delay is the time it takes for a packet to travel from the source to the destination.

   • For voice, delay should be low otherwise conversations feel unnatural, like talking over a slow satellite link.

3. Jitter

   • Jitter is the variation in delay between packets.

   • If one packet arrives in 30 ms and the next in 60 ms, you’ll notice voice “choppiness” or gaps.

4. Loss

   • Packet loss happens when some packets never arrive.

   • For data traffic, lost packets can be resent, but for voice, lost packets usually mean missing words or broken audio.

---

Standards (Recommended by ITU-T)

To ensure good voice quality, the ITU-T (International Telecommunication Union – Telecommunication Standardization Sector) has set guidelines:

• Bandwidth: A single voice call typically needs about 30–100 kbps.

• Delay (Latency): Should be less than 150 ms one way for acceptable quality.

• Jitter: Should be kept below 30 ms.

• Loss: Should not exceed 1% of packets.

If the network can meet these standards, calls usually sound clear and natural. If not, you’ll start noticing poor audio, echoes, or dropped calls.

---

QoS and Queuing

When a network link gets congested, packets can’t all be sent at once. They need to wait their turn. This is where queuing comes in. Think of it like lines at a grocery store: customers (packets) wait in different lines, and how quickly they get served depends on the type of line they’re in.

In networking, queuing decides:

• Which packets get sent first.

• How much bandwidth each type of traffic receives.

• What happens if the queue is full.

Since voice traffic is sensitive to delay and jitter, QoS queuing ensures that voice packets go to the “express lane”, while less critical traffic like file downloads waits a little longer.

---

Types of Queuing

1. FIFO (First In, First Out)

   • The simplest method. Packets are sent in the order they arrive.

   • Fair, but not good for voice because all traffic is treated equally.

2. PQ (Priority Queuing)

   • Creates different priority levels. Voice packets go to the highest priority queue, so they always get sent first.

   • Works well for voice but can starve lower-priority traffic if overused.

3. CQ (Custom Queuing)

   • Lets you divide bandwidth among traffic types. Each queue gets a slice of bandwidth.

   • More control, but still limited for real-time traffic.

4. WFQ (Weighted Fair Queuing)

   • Automatically shares bandwidth based on traffic “weights.”

   • Good balance, but may not always guarantee strict voice quality.

5. LLQ (Low Latency Queuing)

   • The most common for voice. It combines PQ and WFQ.

   • Voice traffic goes into a strict priority queue (always served first), while other traffic still gets fair treatment.

   • Prevents starvation and ensures clear voice quality.

In short, queuing is about managing the line. QoS makes sure voice traffic doesn’t wait behind big data transfers. It goes to the front of the line to keep conversations smooth.

---

When Queues Fill Up

Even with queuing, there’s a limit to how many packets a buffer (queue) can hold. Once it’s full, the switch or router has to decide what to do with new incoming packets. That’s where drop mechanisms come in.

---

Tail Drop

• What it is: The simplest drop mechanism. When the queue is full, any new packets that arrive are dropped automatically—like a bouncer saying “sorry, we’re full” and not letting anyone in.

• Problem: It’s simple, but it can cause issues with TCP traffic.

---

TCP Global Synchronization

• What it is: A side effect of tail drop.

• When multiple TCP connections see packet loss at the same time (because the queue got full), they all reduce their sending rate together. Then, after a while, they all increase their rate again.

• This creates a “sawtooth” pattern: sudden drops in throughput followed by sudden bursts, instead of a smooth flow.

• End result: the network link isn’t used efficiently—it alternates between being underused and congested.

---

RED (Random Early Detection)

• What it is: A smarter way of dropping packets before the queue is completely full.

• Instead of waiting until the buffer overflows, RED randomly drops packets early when the queue starts to get congested.

• This signals TCP flows to slow down gradually, preventing all connections from hitting a wall at the same time.

• Think of it as the bouncer occasionally turning people away early to keep the club from suddenly overflowing.

---

WRED (Weighted Random Early Detection)

• What it is: An improved version of RED.

• With WRED, the decision of which packets to drop is based on their priority markings (like DSCP).

• Low-priority packets are dropped first, while high-priority packets (like voice) are protected as long as possible.

• This makes WRED more intelligent, ensuring important traffic is less affected during congestion.

---

In short:

• Tail Drop = wait until the buffer is full, then drop everything new.

• TCP Global Synchronization = result of many TCP sessions slowing down and speeding up together after tail drop.

• RED = randomly drop early to avoid global synchronization.

• WRED = same as RED but smarter, protecting higher-priority traffic.

---

Classifications and Methods of Classifying Traffic

Now that we’ve covered marking and policing, let’s move on to classification, which is another important part of QoS. Classification is basically the process of identifying and sorting traffic into categories so the network knows how to handle it. Think of it as tagging certain packets and putting them into the right “line” so they can be managed properly.

There are several methods to classify traffic, and here are some of the most common ones you’ll encounter:

1. NBAR (Network-Based Application Recognition)

NBAR is a Cisco feature that allows routers to identify and classify applications even if they’re using dynamic ports. Normally, classification relies on things like port numbers (e.g., HTTP = port 80, HTTPS = port 443), but some applications don’t stick to fixed ports. NBAR solves this by looking deeper into the packet to figure out what application it actually belongs to. This makes it very handy for identifying traffic like Skype, peer-to-peer apps, or even video streams.

2. PCP (Priority Code Point)

PCP is used at Layer 2 in Ethernet frames. It’s a 3-bit field inside the IEEE 802.1Q VLAN tag that indicates the priority level of the frame. Since it has 3 bits, you can have 8 different priority values (0 to 7). Higher values usually mean higher priority. This method is especially useful in LAN environments where VLAN tagging is common.

3. DSCP (Differentiated Services Code Point)

DSCP works at Layer 3 in the IP header. It uses 6 bits to mark packets, which means there are 64 possible values. These values map to different levels of service, like “best effort,” “assured forwarding,” or “expedited forwarding.” DSCP is one of the most widely used methods in modern networks because it gives you fine-grained control over how traffic is handled.

---

Priority Code Point (PCP)

PCP is a 3-bit field in the 802.1Q VLAN tag of Ethernet frames. Since it’s only 3 bits, it allows for 8 different priority levels (0–7). These values are often referred to as Class of Service (CoS) values.

Think of PCP as a way for switches to look at a frame and decide how “important” it is compared to others. Higher PCP values mean higher priority, so traffic gets handled first when congestion happens.

Here’s a simple breakdown of the PCP values:

So, if a switch sees a frame with PCP = 6, it knows that’s voice traffic and should be given priority over, say, a PCP = 0 frame that’s just loading a website.

PCP is most useful in Layer 2 QoS (LAN environments), where it helps ensure that important traffic like voice and video doesn’t get delayed by less time-sensitive traffic like file downloads.

---

IP ToS Byte

In the IPv4 header, there’s an 8-bit field originally called the Type of Service (ToS) byte. It was designed to tell routers how to handle packets in terms of priority and quality. Over time, this field evolved into what we now use for Differentiated Services (DiffServ).

Here’s how the 8 bits of the ToS Byte are structured:

• First 3 bits – IP Precedence (IPP):
  Used in older QoS models. It allowed 8 different priority levels (0–7).

• Next 4 bits – Type of Service flags:
  They were meant to describe how the packet should be treated (e.g., minimize delay, maximize throughput, maximize reliability). These aren’t widely used anymore.

• Last bit – Unused / reserved:
  Not used in the original design.

---

Evolution into DSCP

Because the old ToS field was too limited, it got redefined:

• The first 6 bits are now the DSCP (Differentiated Services Code Point) value.

• The last 2 bits are used for ECN (Explicit Congestion Notification).

So today, when we talk about QoS, it’s usually about DSCP values inside the old ToS byte.

---

In earlier implementations of QoS (before DSCP became widely adopted), the IP header had a Type of Service (ToS) field. The first 3 bits of this field were used as IP Precedence (IPP) values. These values allowed routers to prioritize packets based on their importance.

Here’s a quick breakdown:

• 3 bits = 8 possible precedence levels (0–7)

• Higher values meant higher priority

• Routers could use these values to decide which packets to forward first, especially during congestion

Common IP Precedence Levels:

• 0 – Routine (default, normal data traffic)

• 1 – Priority

• 2 – Immediate

• 3 – Flash

• 4 – Flash Override

• 5 – Critical

• 6 – Internetwork Control

• 7 – Network Control (highest, usually reserved for routing protocols and control traffic)

In practice, most user data was marked with 0 (Routine), while critical traffic like routing updates could be marked with 6 or 7.

Limitation: IP Precedence only provided 8 levels of priority, which wasn’t flexible enough for modern networks. That’s why DSCP (with 6 bits, giving 64 values) later replaced it.

---

Now that we’ve covered IP Precedence, let’s move on to Differentiated Services Code Point (DSCP), which provides a more flexible and detailed way of classifying and prioritizing traffic. DSCP was introduced in RFC 2474, which redefined the old IP Type of Service (ToS) field to support modern QoS requirements.

What is DSCP?

• DSCP uses 6 bits in the IP header, allowing for 64 different traffic classes (compared to only 8 levels in IP Precedence).

• It enables fine-grained control over how packets are forwarded, making it more suitable for today’s diverse traffic like video, voice, and data.

• With DSCP, routers and switches can apply policies such as queueing, shaping, or dropping based on the assigned value.

---

Standard DSCP Markings

RFC 2474 defines a set of Per-Hop Behaviors (PHBs) that describe how packets with certain DSCP values should be treated across the network. Some common ones are:

• Default Forwarding (DF) – DSCP 0 (best effort traffic, no priority).

• Expedited Forwarding (EF) – DSCP 46 (high priority, often used for VoIP because it needs low delay and jitter).

• Assured Forwarding (AF) – Provides four classes (AF1, AF2, AF3, AF4), each with three drop precedence levels:

  • Example: AF11, AF12, AF13 → all belong to Class 1 but with different likelihoods of being dropped during congestion.

• Class Selector – Backward compatible with IP Precedence (values like DSCP 8, 16, 24, etc.).

This approach allows service providers and enterprises to create QoS policies that prioritize critical applications (like voice and video) while still handling less critical traffic fairly.

---

Quick Recall

• DSCP = Differentiated Services Code Point

• Found in the first 6 bits of the IP ToS byte (the DiffServ field).

• Each DSCP value decides how packets are treated in terms of priority and forwarding.

---

1. Default (Best Effort)

• DSCP Value: 000000

• Formula: All zeros → no special treatment.

• Use: Normal traffic like browsing, email, or any non-urgent app.

2. Class Selector (CSx)

• These come directly from IP Precedence (old system).

• Formula: IP Precedence (3 bits) shifted left by 3 = DSCP.

  • Example: IP Prec 3 (011) → DSCP 011000 = CS3.

• Values: CS0 to CS7.

• Use: Backward compatibility, basic priority levels.

3. Assured Forwarding (AF)

• Designed to give different delivery assurances.

• Formula: AFxy

  • x = Class (1 to 4)

  • y = Drop Precedence (1 = low, 2 = medium, 3 = high)

• Each AF has 3 values per class (higher "y" = higher chance of drop if congestion).

• Example: AF21 = Class 2, Low Drop.

• Use: Business apps, video, or traffic that needs some protection.

4. Expedited Forwarding (EF)

• DSCP Value: 101110 (decimal 46).

• Formula: Special single value.

• Use: Very low latency and jitter, like VoIP, real-time video, voice calls.

5. Other Notes

• RFC 2474 defined DSCP.

• RFC 2597 defined AF classes.

• RFC 3246 defined EF.

In short:

• Best Effort (BE): 000000 → normal traffic

• CSx: legacy precedence values

• AFxy: controlled priority + drop probability

• EF: strict priority (real-time, voice)

---

RFC 4594 – Configuration Guidelines for DiffServ Service Classes

RFC 4594 provides standardized recommendations for how different types of applications should be mapped into DiffServ (DSCP) service classes.
This is meant to help ensure consistent QoS treatment across networks.

---

Common Service Classes and Recommended DSCP Markings

1. Voice Traffic (Telephony, VoIP)

   • Recommended DSCP: EF (Expedited Forwarding, DSCP 46)

   • Why: Voice needs very low latency, low jitter, and low loss. EF guarantees high-priority forwarding with minimal delay.

2. Interactive Video (e.g., video conferencing)

   • Recommended DSCP: AF41, AF42, AF43 (Assured Forwarding Class 4)

   • Why: Video conferencing is delay-sensitive but a bit more tolerant than voice. The AF4x range provides priority while allowing some drop precedence if congestion occurs.

3. Streaming Video (e.g., YouTube, IPTV)

   • Recommended DSCP: AF31, AF32, AF33 (Assured Forwarding Class 3)

   • Why: Streaming video is less sensitive to delay but needs throughput. AF3x ensures delivery with some tolerance for buffering.

4. High-Priority Data (e.g., transactional, critical business apps)

   • Recommended DSCP: AF21, AF22, AF23 (Assured Forwarding Class 2)

   • Why: These applications are important but not as sensitive as real-time media. AF2x provides better reliability compared to best effort.

5. Best Effort Traffic (Default)

   • Recommended DSCP: DF (Default Forwarding, DSCP 0)

   • Why: All traffic without explicit QoS marking falls here. It’s treated fairly but with no guarantees.

6. Background (Scavenger, low-priority data like backups or bulk transfers)

   • Recommended DSCP: CS1 (Class Selector 1, DSCP 8)

   • Why: Background apps can wait. CS1 is designed to get only leftover bandwidth.

---

Formula for AF Classes

AF (Assured Forwarding) uses a formula:
DSCP = 8 × Class + Drop Precedence

• Class ranges: AF1, AF2, AF3, AF4

• Drop precedence: 1 (low), 2 (medium), 3 (high)

Example:

• AF21 = 8×2 + 1 = 17

• AF22 = 8×2 + 2 = 18

• AF23 = 8×2 + 3 = 19

---

Key Points to Remember

• EF (46): Best for real-time voice.

• AF4x: Use for video conferencing.

• AF3x: Use for streaming video.

• AF2x: For critical data.

• DF (0): Default traffic.

• CS1 (8): Background, low-priority traffic.

---

Trust Boundaries

In QoS (Quality of Service), a trust boundary is the point in the network where you decide whether to trust or not trust the markings (like DSCP or CoS) that are already on the packets coming in.

Here’s the idea:

• Some devices, like IP phones, mark their traffic with DSCP values (for example, EF for voice).

• Other devices, like PCs or user applications, might try to mark their own packets with high-priority values even if they don’t deserve it. This could abuse the network by giving normal traffic the same priority as real-time traffic.

So, network engineers define trust boundaries to control where markings are accepted and where they are overwritten.

Key Points

1. Trusted devices:

   • IP phones, routers, and switches that you control.

   • Their QoS markings are usually honored.

2. Untrusted devices:

   • End-user PCs, laptops, servers, or unmanaged devices.

   • Their QoS markings are typically reset (re-marked to best effort or another value) at the access switch.

3. Typical placement:

   • The trust boundary is usually set at the access switch port connected to a trusted device (like an IP phone).

   • Traffic beyond that boundary is assumed to be marked correctly and forwarded according to QoS policies.

Why it matters

Prevents misuse of QoS by untrusted users.

• Ensures fairness in the network.

• Keeps priority treatment only for the traffic that truly needs it (voice, video, critical apps).

Example:

• You connect a Cisco IP phone and a PC to the same switch.

• The switch trusts the phone’s DSCP markings but does not trust the PC.

• The switch may re-mark PC traffic to Best Effort (DF), while keeping the phone’s voice traffic as EF.

---

What is Queuing (Congestion Management)?

When too much traffic arrives at an interface (router, switch, firewall) and the output link cannot send all packets immediately, the extra packets must wait in a queue. Congestion management decides which packets wait, in what order, and who gets priority.

The main goal is to avoid dropping important traffic (like voice or video) when congestion happens.

---

Common Queuing Strategies

1. FIFO (First In, First Out)

• Default method in many devices.

• Packets are forwarded in the order they arrive.

• No differentiation; if the queue is full, packets are dropped.

• Best for: simple networks, low traffic.

2. PQ (Priority Queuing)

• Creates multiple queues (High, Medium, Normal, Low).

• High-priority traffic always gets sent first.

• Can cause starvation of lower queues if high-priority traffic is constant.

• Best for: ensuring critical traffic (like voice) is never delayed.

3. WFQ (Weighted Fair Queuing)

• Dynamically separates flows into queues.

• Gives each flow a fair share of bandwidth.

• More intelligent than FIFO or PQ, but can be CPU-intensive on older devices.

• Best for: mixed environments with many applications.

4. CBWFQ (Class-Based Weighted Fair Queuing)

• You define classes of traffic using ACLs or QoS policies.

• Each class gets a configured share of bandwidth.

• Fair distribution between classes.

• Best for: enterprise networks with known application traffic (voice, video, data).

5. LLQ (Low Latency Queuing)

• Extension of CBWFQ with a strict priority queue for delay-sensitive traffic.

• Voice/video packets go to the priority queue, ensuring minimal delay/jitter.

• Other traffic still gets fair bandwidth through CBWFQ.

• Best for: converged networks (voice, video, and data).

---

Congestion Management Guidelines

According to RFC 4594 (QoS Recommendations):

• Voice (EF) → Strict priority, low latency queue.

• Interactive Video (AF4x) → High-priority class, but not strict priority.

• Streaming Video (AF3x) → Medium-priority, less sensitive to delay.

• High-Priority Data (AF2x) → Ensure reserved bandwidth.

• Best Effort (DF) → Default queue.

• Scavenger Class (CS1) → Very low priority, background tasks.

---

Key Points to Remember

• Voice traffic must have guaranteed low delay → LLQ is the best.

• Fairness is important for data and video → CBWFQ or WFQ works.

• Overusing priority queues can harm the network → only real-time traffic should go there.

• Queuing is activated only when there’s congestion → if the link is underutilized, packets just flow through.

---

Prioritization

Prioritization is the process of determining which types of traffic should be sent first when there is congestion. Since not all traffic is equal (e.g., voice packets are more sensitive to delay than email), prioritization ensures that important or time-sensitive traffic gets preferential treatment.

---

Common Scheduling Methods

Scheduling determines how packets are taken from queues and placed onto the outbound interface when congestion occurs.

1. Weighted Round Robin (WRR)

   • Packets are placed into different queues, each with a weight.

   • Higher-weighted queues send more packets per cycle compared to lower-weighted ones.

   • Ensures all traffic gets serviced but with proportional priority.

   • Suitable for environments where fairness is important but some traffic still needs more bandwidth.

2. Class-Based Weighted Fair Queuing (CBWFQ)

   • Builds on WFQ by allowing the network admin to define classes of traffic using policies (e.g., voice, video, critical apps).

   • Each class gets a guaranteed portion of bandwidth.

   • Flexible, since you can align classes with business needs and allocate resources accordingly.

3. Low Latency Queuing (LLQ)

   • Extension of CBWFQ that adds a strict priority queue.

   • Packets in the priority queue (usually voice) are always sent first, minimizing delay and jitter.

   • To prevent starvation of other traffic, the priority queue is policed or rate-limited.

4. Policing

   • Enforces bandwidth limits by dropping or remarking traffic that exceeds defined thresholds.

   • Common for traffic entering the network from untrusted sources or when controlling excessive usage.

   • Unlike shaping, policing does not buffer traffic; it simply discards excess, which can negatively affect TCP flows.

Together, these methods form the basis of QoS traffic management:

• Prioritize critical flows (voice, video).

• Allocate fair bandwidth to other classes.

• Prevent abuse or congestion by enforcing limits.

---

Alright, now that we’ve gone through prioritization and scheduling methods, let’s transition to Shaping and Policing, two of the most important traffic conditioning tools used in QoS.

Traffic Shaping

Traffic shaping is about delaying excess traffic so that it conforms to a desired traffic rate. Instead of discarding packets, the router buffers them and then sends them later, smoothing out traffic bursts.

• Typically applied on outbound traffic.

• Helps prevent congestion on slower links.

• Uses token bucket algorithms to regulate transmission rates.

• Example: If an interface is set to shape traffic to 2 Mbps, any traffic above that rate is queued and sent gradually so it doesn’t exceed the limit.

---

Traffic Policing

Traffic policing, on the other hand, enforces a rate by dropping or remarking excess packets when the traffic exceeds a specified threshold.

• Can be applied on inbound or outbound traffic.

• If traffic is conforming, it is transmitted. If it exceeds the rate, packets may be:

  • Dropped (hard policing)

  • Remarked to a lower-priority class (so they are still sent but treated as less important)

• Example: If a service provider contract allows 10 Mbps, but the customer sends 12 Mbps, the extra 2 Mbps may be dropped or marked down.

---

Key Difference

• Shaping: Smooths traffic by queuing excess packets.

• Policing: Enforces limits by dropping or remarking excess packets.

---

Shaping and Policing

Traffic Shaping

• Buffers excess traffic and sends it later, smoothing traffic flow.

• Ensures traffic does not exceed a specified rate while reducing packet loss.

• Works best for traffic that can tolerate some delay.

Traffic Policing

• Drops or remarks traffic that exceeds a defined rate.

• Enforces strict bandwidth limits.

• Often used by service providers to enforce customer contracts.

Key difference: Shaping delays traffic, policing drops it.

---

QoS Configuration with Class Maps and DSCP Matching

Cisco IOS uses a Modular QoS Command-Line Interface (MQC). The main building blocks are:

1. Class-map: Defines traffic classes.

2. Policy-map: Defines actions for each class.

3. Service-policy: Applies the policy to an interface.

Step 1: Define a class map

We match traffic based on DSCP (Differentiated Services Code Point).

class-map match-any VOICE
 match dscp ef

• class-map creates a traffic class named VOICE.

• match-any means traffic only needs to match one condition.

• match dscp ef matches packets marked with DSCP value EF (Expedited Forwarding, DSCP 46), which is typically used for voice.

Step 2: Define a policy map

Here we specify actions such as prioritization or bandwidth allocation.

policy-map QOS_POLICY
 class VOICE
  priority percent 30
 class class-default
  fair-queue

• policy-map creates a QoS policy.

• priority percent 30 reserves 30% of the interface bandwidth for voice traffic and places it in a Low Latency Queue (LLQ).

• class-default applies to all other traffic. fair-queue ensures fairness across different flows.

Step 3: Apply the policy to an interface

interface GigabitEthernet0/0
 service-policy output QOS_POLICY

• The service policy is applied outbound on the interface.

• Traffic exiting this interface will now be classified and prioritized.

---

Example Explained

If a voice call packet marked DSCP EF comes in:

• It matches the VOICE class.

• It gets priority treatment, with up to 30% of the link dedicated to it.

• If the link is congested, voice still gets priority while other traffic is queued fairly.

If traffic does not match VOICE:

• It falls into the default class, where fair-queue prevents single flows from dominating.

---

Summary of QoS

Quality of Service (QoS) ensures that network resources are managed efficiently, especially when there is congestion. It classifies and prioritizes traffic so critical applications, like voice and video, get the bandwidth and low delay they need.

• IP Precedence & DSCP: Methods for marking packets so they can be prioritized.

• Trust Boundaries: Define where markings are trusted (often at the network edge).

• Congestion Management: Techniques like queuing ensure fair handling of traffic when bandwidth is limited.

• Prioritization Methods:

  • Weighted Round Robin (WRR): Balances queues with weighted fairness.

  • CBWFQ (Class-Based Weighted Fair Queuing): Assigns bandwidth guarantees to classes.

  • LLQ (Low Latency Queuing): Gives strict priority for delay-sensitive traffic like voice.

• Policing and Shaping:

  • Policing drops or marks traffic that exceeds a rate.

  • Shaping buffers excess traffic and sends it later, smoothing traffic flows.

• Configuration Basics:

  • class-map: Defines traffic classes (e.g., match dscp).

  • policy-map: Defines actions like priority, bandwidth, policing, or shaping.

  • service-policy: Applies QoS to interfaces.

Example Recap:
We built a QoS policy that prioritized voice (EF traffic) with LLQ, allocated bandwidth for video, and limited best-effort traffic using class-map, policy-map, and service-policy commands.

---

QoS Configuration Commands

1. Define a class map (to match traffic)

class-map match-any VOICE
 match dscp ef

2. Define a policy map (to apply actions to matched traffic)

policy-map QOS-POLICY
 class VOICE
  priority 150
 class class-default
  fair-queue

3. Apply the policy to an interface

interface GigabitEthernet0/0
 service-policy output QOS-POLICY

---

Important Keywords

• class-map – groups traffic based on criteria like DSCP or ACLs.

• match dscp – matches traffic with a specific DSCP value.

• policy-map – defines QoS actions (queueing, policing, shaping).

• priority – gives strict priority (used in LLQ).

• fair-queue – enables CBWFQ for default traffic.

• service-policy – attaches the QoS policy to an interface (inbound or outbound).

That closes the QoS topic, with theory, examples, and command references all covered.

---

Wrap-Up

And that’s a solid overview of QoS! We covered the key scheduling methods like Weighted Round Robin, CBWFQ, and LLQ, then moved into shaping and policing to control traffic behavior. On top of that, we looked at how to classify traffic with class maps and match criteria like DSCP values, and we even went through an example of configuring QoS step by step.

QoS can feel like a heavy topic at first, but once you see how these tools work together, it starts to click. Think of it as giving your network some rules and discipline, so the right traffic always gets through when it matters most.

Networking isn’t just about connecting devices, it’s about making sure the connection works well, even under pressure. So keep practicing, stay curious, and let QoS be another tool in your growing network engineer toolkit.