Quality of Service (QoS)

Quality of Service (QoS) provides differential treatment to network traffic, ensuring critical applications receive adequate bandwidth, low delay, minimal jitter, and acceptable packet loss despite network congestion. Understanding QoS principles, metrics, and necessity is essential for CCNA certification and supporting modern converged networks carrying voice, video, and data simultaneously. QoS doesn't create additional bandwidth but intelligently manages existing capacity, prioritizing business-critical and latency-sensitive traffic over less important traffic during congestion. The fundamental need for QoS arises from limited bandwidth and competing application requirements. Network links have finite capacity—a 100 Mbps connection cannot carry 150 Mbps simultaneously. Without QoS, networks use FIFO (First In First Out) queuing treating all packets equally. During congestion, tail drop occurs where arriving packets simply drop when queues fill, affecting all traffic types equally. This is problematic because applications have vastly different network requirements: real-time VoIP requires low delay but tolerates some loss, streaming video needs consistent bandwidth, interactive applications require low latency, bulk data transfers can tolerate delays but need high throughput, and background tasks should use spare capacity without impacting other traffic. QoS enables policies matching network treatment to application needs. Traffic classification identifies different traffic types based on business importance and technical requirements. Voice traffic (VoIP, IP phones) is most sensitive—conversations require one-way delay under 150 ms (preferably under 100 ms) for acceptable quality. Jitter (delay variation) must remain below 30 ms, and packet loss should be under 1%. Voice uses relatively little bandwidth (64-128 Kbps per call) but is extremely delay-sensitive. Even 200 ms delay creates noticeable conversation gaps. Video traffic (conferencing, streaming) requires consistent bandwidth and moderate delay tolerance. Video conferencing needs low delay like voice (under 150 ms) for interactive conversations. One-way video streaming tolerates higher delay but needs consistent throughput avoiding buffering. Packet loss causes visible artifacts. Mission-critical data applications (ERP, CRM, databases, transactions) directly support business operations and should receive priority over recreational traffic. Interactive data (SSH, remote desktop, web browsing) benefits from low latency providing responsive user experience. Best-effort data (email, file transfer, general internet) can tolerate delay and operates on available bandwidth. Scavenger traffic (peer-to-peer, streaming media, personal applications) should receive minimal resources to prevent impacting business traffic. QoS metrics measure network performance. Bandwidth represents transmission capacity (bits per second). Delay (latency) measures time for packets to traverse the network—cumulative of propagation delay (physical distance at light speed), transmission delay (placing bits on medium), processing delay (routing decisions, switching), and queuing delay (waiting in queues—the component QoS most impacts). Jitter measures delay variation—important for real-time protocols as variable delay complicates playout buffer management. High jitter causes choppy voice/video. Packet loss occurs when congestion fills buffers and arriving packets drop. Voice tolerates 1% loss, video around 1-2%, while data requires retransmission of lost packets. Critically, QoS does not create bandwidth—it allocates existing bandwidth according to policies. Over-subscribed networks require either upgrading capacity or accepting that QoS merely prioritizes which traffic suffers degradation during congestion. Proper capacity planning ensures most periods operate below congestion, with QoS handling temporary spikes. QoS is most effective at network edges where bandwidth is most constrained (WAN links, internet connections) and less critical in high-speed core networks rarely experiencing congestion. QoS implementation follows a workflow: classify traffic (identify types), mark packets (tag with priority), queue packets (separate into classes), and shape/police traffic (control rates). Understanding QoS fundamentals enables implementing policies supporting converged network requirements and maintaining application performance during congestion.

Three QoS models exist providing different approaches to quality assurance, each with distinct characteristics, scalability, and use cases. Understanding model differences is essential for CCNA certification and selecting appropriate QoS strategies for network requirements. The industry has largely standardized on DiffServ for scalability and flexibility, though understanding all models provides context for QoS evolution and specialized scenarios. Best Effort represents the absence of QoS—all traffic receives identical treatment using FIFO (First In First Out) queuing. Packets process in arrival order without priority. During congestion, the last packets arriving drop when queues fill (tail drop). Best Effort is simple requiring no configuration, has no overhead, and works adequately for homogeneous traffic types. However, it fails for converged networks with mixed traffic—VoIP calls suffer same delays and drops as file transfers, real-time applications degrade during congestion, and important traffic receives no preferential treatment. Best Effort suits networks with: single traffic type, consistent underutilization (no congestion), or no critical applications. Modern converged networks require more sophisticated approaches. Integrated Services (IntServ) provides per-flow resource reservation using RSVP (Resource Reservation Protocol). Applications signal the network requesting specific bandwidth, delay, and loss characteristics for individual flows (identified by source/destination IP and ports). Routers along the path either accept reservations (if resources available) or reject them (if insufficient capacity). Accepted flows receive guaranteed resources end-to-end. IntServ provides absolute QoS guarantees, supports per-flow granularity, and enforces admission control preventing over-subscription. However, IntServ has critical scalability limitations: maintaining per-flow state on routers doesn't scale to internet backbones with millions of concurrent flows, RSVP signaling creates overhead, not all applications support RSVP, and requires end-to-end implementation (partial deployment ineffective). IntServ suits specialized environments: laboratory networks, private voice networks with predictable flows, or high-value applications requiring guarantees. It never achieved widespread internet deployment due to scalability issues. Differentiated Services (DiffServ) provides class-based QoS operating at aggregate traffic levels rather than individual flows. DiffServ is the industry-standard QoS model used in enterprise and service provider networks. It classifies packets into traffic classes, marks them with DSCP values indicating class, and provides differentiated treatment per class rather than per flow. DiffServ scales to any network size (backbone routers maintain class state, not flow state), requires no signaling overhead (markings in packet headers), allows incremental deployment (benefits at each hop), and provides flexibility in defining classes and policies. DiffServ implementation follows a multi-step process: Classification identifies traffic based on various criteria: ACLs matching source/destination IP addresses and port numbers, NBAR (Network-Based Application Recognition) using deep packet inspection identifying applications despite dynamic ports, source/destination addresses or subnets, DSCP values (trusting existing markings), or CoS values from Layer 2 headers. Marking tags packets with priority indicators enabling downstream devices to identify traffic classes without re-classification. Layer 2 CoS uses 3 bits in 802.1Q/802.1p headers (values 0-7, only on VLAN tagged frames). Layer 3 DSCP uses 6 bits in IP header's Differentiated Services field (values 0-63, works across Layer 3 boundaries). Marking typically occurs at network edges (access layer switches, remote site routers) where traffic originates—core devices trust markings avoiding processing overhead. Trust boundaries define where markings are trusted versus re-marked—trust internal devices but re-mark at internet edge. Queuing provides differentiated forwarding based on markings. Multiple queues separate traffic classes, with scheduling algorithms determining service order and allocation. Policing and shaping control traffic rates preventing specific classes from consuming excessive resources. Policing drops or remarks excess traffic, while shaping buffers excess traffic smoothing bursts. DiffServ PHB (Per-Hop Behavior) defines standard treatments: Default (BE, DSCP 0) for best-effort traffic, Expedited Forwarding (EF, DSCP 46) for voice with strict low-latency/low-loss priority, Assured Forwarding (AF, multiple DSCP values) for differentiated classes with drop precedence, and Class Selector (CS, backward compatible with IP Precedence). Understanding QoS models enables selecting and implementing appropriate service strategies for network requirements.

Classification and marking form the foundation of QoS implementation, identifying traffic types and tagging packets enabling downstream devices to provide differentiated treatment. Understanding classification methods, marking types, trust boundaries, and best practices is essential for CCNA certification and implementing effective QoS policies. Proper classification and consistent marking throughout networks ensure traffic receives appropriate priority regardless of path. Classification methods identify traffic using various packet characteristics. Access Control Lists (ACLs) provide granular classification matching packets by source and destination IP addresses, source and destination port numbers, and protocol types. ACLs enable very specific policies like prioritizing SIP traffic (VoIP signaling, UDP 5060) or specific application servers. However, ACLs require manual configuration for each application and struggle with applications using dynamic ports. NBAR (Network-Based Application Recognition) performs deep packet inspection identifying applications by signatures and behavioral analysis, recognizing applications despite dynamic port usage, identifying encrypted traffic through statistical analysis, and automatically updating signatures. NBAR significantly simplifies classification for complex modern applications like video conferencing using multiple dynamic ports. Source/destination-based classification uses IP addresses or subnets—useful when specific sites or servers host certain traffic types (all traffic from call manager subnet is voice). Existing markings can be trusted when devices have already classified and marked traffic upstream, avoiding reclassification overhead in core networks. Marking embeds priority information in packet headers enabling downstream devices to identify traffic classes without reclassifying. Two primary marking locations exist based on OSI layer. Layer 2 CoS (Class of Service) uses 3 bits in the 802.1Q VLAN tag header's priority field (PCP - Priority Code Point). CoS provides 8 priority levels (0-7, where 7 is highest). CoS 0 is best-effort default, CoS 5 typically voice traffic, CoS 3 typically business-critical data, and CoS 1 typically scavenger/background. CoS limitations include operation only on trunk links (requires VLAN tagging), lost when crossing Layer 3 boundaries (routers don't forward Ethernet headers), and having just 8 values limiting granularity. CoS suits Layer 2 QoS on switches within campus networks. Layer 3 DSCP (Differentiated Services Code Point) uses 6 bits in the IP header's Differentiated Services field (formerly Type of Service). DSCP provides 64 possible values (0-63) enabling fine-grained classification. DSCP persists across Layer 3 boundaries traveling end-to-end, works across routed networks and WANs, and is the preferred marking for enterprise networks. Common DSCP values follow industry standards: EF (Expedited Forwarding, DSCP 46, binary 101110) for voice—highest priority, strict low-latency treatment. AF (Assured Forwarding) classes provide differentiated classes with drop precedence: AF41 (DSCP 34) high priority data, AF31 (DSCP 26) medium priority, AF21 (DSCP 18) low priority. Each AF class has three drop precedence levels (low, medium, high drop probability during congestion). CS (Class Selector) values (CS0-CS7) provide backward compatibility with IP Precedence. Default/Best-Effort (DSCP 0) represents unmarked traffic. Using standard DSCP values ensures interoperability between vendors and with service provider QoS policies. Trust boundaries define network locations where markings are trusted versus overwritten. The fundamental principle: mark at the network edge, trust within the network core. Marking at the edge means access layer switches or remote site routers classify traffic as close to the source as possible, minimizing core device processing. Some deployments trust markings from IP phones with authentication (Cisco phones mark voice DSCP 46, signaling DSCP 24) but re-mark PC traffic. Untrusted boundaries include connections to: internet (re-mark all ingress traffic according to SLAs), guest networks, and user devices (users might mark all traffic highest priority). Core devices trust markings avoiding reclassification overhead on high-speed interfaces. Consistent trust policies prevent marking manipulation and ensure fair resource allocation. Marking best practices include: mark as close to source as possible, use standard DSCP values for interoperability, limit high-priority classes to necessary traffic (voice, critical applications), police user-facing ports preventing priority manipulation, document classification policies, test and monitor to ensure proper marking, and coordinate with service providers for WAN circuits. Understanding classification and marking enables implementing foundational QoS policies that downstream queuing and shaping mechanisms leverage for differentiated treatment.

Queuing mechanisms determine packet forwarding order and resource allocation during congestion, directly impacting application performance and user experience. Understanding queuing algorithms, scheduling methods, and configuration is essential for CCNA certification and implementing effective QoS. The queuing algorithm selected must match traffic requirements—voice needs strict priority, while data needs fair sharing with guaranteed minimums. Modern implementations combine multiple techniques addressing diverse application needs. FIFO (First In First Out) represents the simplest queuing—single queue processing packets in arrival order. The first packet arriving is the first transmitted. During congestion, arriving packets drop when queues fill (tail drop). FIFO provides no preferential treatment regardless of traffic importance, has no configuration overhead, minimal processing requirements, and acceptable performance when congestion is rare. However, FIFO fails for converged networks as delay-sensitive traffic waits behind bulk transfers, all traffic suffers equal drops during congestion, and no protection for critical applications. FIFO is default on high-speed interfaces (>2Mbps traditionally) assumed to rarely congest, but inappropriate for WAN links or anywhere QoS is needed. Priority Queuing (PQ) implements multiple queues (typically four: high, medium, normal, low) with strict priority scheduling. The scheduler always services high-priority queue first, only servicing medium when high is empty, then normal, then low. PQ guarantees high-priority traffic (voice) always transmits first with minimal delay. However, PQ can starve lower queues—heavy high-priority traffic prevents lower queues from ever transmitting. Complete starvation is possible if high-priority traffic continuously arrives. Legacy PQ suits simple scenarios with limited voice traffic (guaranteed to be less than link capacity) and understanding that lower priority traffic may starve. Modern implementations use Low Latency Queuing instead. Round Robin provides fairness by servicing queues in rotation—each queue gets equal turns. Weighted Round Robin (WRR) assigns weights determining how frequently queues service. Queue with weight 2 gets serviced twice as often as queue with weight 1. WRR prevents starvation (all queues eventually service) and provides proportional bandwidth allocation. However, WRR can't provide strict priority for delay-sensitive traffic—voice might wait through other queue cycles introducing unacceptable delay. Weighted Fair Queuing (WFQ) automatically creates per-flow queues and provides fair bandwidth sharing with preference for small packets (typically interactive traffic). WFQ identifies flows (unique source/destination IP and ports), creates separate queue for each flow, and schedules packets so lower-bandwidth flows get proportionally better service. WFQ works automatically without classification/marking, provides fairness preventing aggressive flows from dominating, and favors interactive traffic over bulk transfers (as interactive has smaller packets). However, WFQ doesn't scale to hundreds of flows (state maintenance overhead), can't provide guaranteed bandwidth to specific applications, and automatic behavior may not match business priorities. Class-Based Weighted Fair Queuing (CBWFQ) combines class-based classification with WFQ's fair queuing. CBWFQ creates queues for user-defined traffic classes (not automatic per-flow), guarantees minimum bandwidth percentage for each class, and uses WFQ within classes. CBWFQ configuration defines class maps (traffic matching), policy maps (bandwidth allocation), and applies policies to interfaces. For example: voice class guaranteed 25% bandwidth, business-critical guaranteed 40%, default gets 30%, scavenger gets 5%. CBWFQ ensures all classes receive minimums while allowing borrowing excess capacity, prevents starvation, and matches business priorities. However, CBWFQ queues don't provide strict priority—voice might wait behind other class packets if arriving simultaneously. Low Latency Queuing (LLQ) combines priority queuing with CBWFQ, providing ideal balance for converged networks. LLQ creates strict priority queue (typically for voice) served first with policing preventing starvation, plus CBWFQ classes for remaining traffic. Voice gets strict low-latency priority, data classes get guaranteed minimum bandwidths with fair sharing, and policing limits priority queue preventing starvation. LLQ is the recommended queuing for most enterprise deployments supporting voice. Configuration example: priority queue for voice (30% maximum), CBWFQ classes for business-critical (40%), default (25%), scavenger (5%). The priority queue serves first, but policing drops voice exceeding 30%, preventing voice traffic from consuming all bandwidth and starving data. Remaining bandwidth fairly shares among CBWFQ classes. Queuing best practices include: use LLQ for networks with voice/video, limit priority queue to needed capacity (30-33% maximum for voice), guarantee bandwidth for critical data classes, leave bandwidth for default class, use scavenger class for undesirable traffic, and configure queuing on all congestion points (typically WAN interfaces). Understanding queuing mechanisms enables selecting and implementing appropriate scheduling providing application-appropriate service.

Traffic shaping and policing control traffic rates preventing congestion, enforcing service level agreements, and protecting network resources from oversubscription. While both limit traffic rates, their mechanisms and impacts differ significantly. Understanding shaping versus policing, rate parameters, and configuration is essential for CCNA certification and managing bandwidth allocation. The choice between shaping and policing depends on direction (inbound vs outbound), traffic type, and desired behavior during rate violations. Traffic policing enforces maximum traffic rates by dropping or remarking packets exceeding configured thresholds, implementing a "hard limit" with immediate enforcement. When traffic exceeds the rate, policing instantly drops excess packets or remarks them to lower priority (hoping downstream devices will drop them during congestion). Policing is typically applied inbound to untrusted interfaces protecting network resources from excessive traffic sources. Use cases include enforcing customer bandwidth limits on service provider networks (customer purchasing 50 Mbps gets policed at 50 Mbps), protecting against DoS attacks or misbehaving applications, and enforcing SLA compliance. Policing advantages include no buffering (no delay introduced), simple implementation, and protects resources immediately. Disadvantages include packet drops causing TCP retransmissions and reduced throughput, aggressive to TCP flows which interpret drops as congestion and slow down, and potential application impact as dropped voice/video packets cause quality degradation. Policing suits scenarios where immediate enforcement matters more than occasional drops—untrusted sources, protecting critical resources, or enforcing hard limits. Traffic shaping delays excess traffic buffering packets until conforming to configured rate, creating smooth traffic flow without drops. When traffic exceeds rate, shaping queues excess packets and transmits them when bandwidth becomes available. Shaping is typically applied outbound smoothing bursts before traffic enters potentially congested links. Use cases include matching traffic to downstream bandwidth (shaping 100 Mbps LAN interface to match 50 Mbps WAN circuit), preventing drops from provider policing (shape slightly below provider rate), and smoothing bursty traffic. Shaping advantages include no packet drops (more TCP-friendly than policing), smooth traffic flow beneficial for voice/video, and prevents triggering downstream policing. Disadvantages include added delay from buffering, requires buffer memory, and increased complexity. Shaping suits outbound traffic on interfaces feeding slower downstream links, traffic types sensitive to drops (voice, video), and TCP traffic benefiting from smooth delivery. Rate parameters control both shaping and policing behavior. CIR (Committed Information Rate) specifies guaranteed average rate in bps—traffic at or below CIR should never drop (subject to conforming burst). Bc (Committed Burst) defines burst size in bytes permitted above CIR over short intervals. Networks permit brief bursts exceeding average rates—Bc specifies how much. Bc combines with CIR determining evaluation interval: Tc (time interval) = Bc / CIR. For example, CIR 50 Mbps with Bc 10,000 bytes means evaluation every 10,000 bytes / 50 Mbps = 1.6 ms. During each interval, 10,000 bytes can transmit. Be (Excess Burst, optional) defines additional burst traffic above Committed Burst that may transmit if network has capacity. Traffic within CIR always forwards, traffic within CIR+Bc forwards during bursts, and traffic exceeding CIR+Bc drops (policing) or queues (shaping). Generic Traffic Shaping (GTS) applies shaping at interface level controlling total interface output rate. Configuration specifies CIR and Bc. GTS shapes all traffic uniformly without class differentiation. Use when entire interface should limit to specific rate. Class-Based Shaping applies shaping per class enabling different rates for different traffic types. For example: voice class shaped to 10 Mbps, data to 40 Mbps. Requires class-maps defining traffic and policy-maps specifying shaping rates. Hierarchical shaping implements parent and child policies—parent shapes total interface rate, children shape individual classes within that total. Class-Based Policing applies policing per class. Configuration similar to shaping but uses "police" keyword instead of "shape." Can specify actions for exceeding traffic: drop, transmit (pass anyway), or set-dscp-transmit (remark to lower priority). Verification uses 'show policy-map interface [name]' displaying applied policies, configured rates, conforming traffic (within limits), exceeding traffic (drops/delays), and buffer statistics. Monitoring identifies whether shaping/policing thresholds are appropriate or need adjustment. Best practices include: shape outbound, police inbound; shape slightly below (98%) downstream rate avoiding provider policing; police untrusted sources protecting resources; use shaping for TCP traffic; coordinate shaping/policing rates with service provider SLAs; and monitor conformance adjusting as traffic patterns change. Understanding traffic shaping and policing enables implementing effective rate control protecting network resources while maintaining application performance.