QoS in Modern Networks: SD-WAN, Cloud, and Application-Aware Steering

QoS in modern networks looks different from the MPLS-WAN-with-LLQ patterns that dominated the 2000s and 2010s. Cloud-direct connectivity, SD-WAN application-aware steering, SaaS-everything traffic, and best-effort internet transport between branches and the cloud all shift where QoS lives, what it can enforce, and what it cannot. The protocol mechanics (DSCP, LLQ, MQC) still apply; their context has changed.

This article walks through how QoS works in SD-WAN, how it interacts with cloud on-ramps, what changes when transport is the public internet, the new app-aware policy patterns, and the realities of QoS-end-to-end when half the path is somebody else's network. If you are designing a modern WAN or SASE deployment, or trying to figure out why your DSCP markings stop being honored at the cloud edge, this is the reference.

What Changed Versus the MPLS Era

The big conceptual shift: QoS used to be about marking once and trusting the carrier to honor markings end-to-end. Modern QoS is about marking once for what you control, and accepting that your markings end at the boundary of someone else's network.

QoS in SD-WAN

SD-WAN platforms implement application-aware QoS that combines traditional queueing with per-application path steering. The mechanism:

1. Application identification at the edge. The SD-WAN WAN Edge does deep packet inspection (NBAR2 in Cisco Catalyst SD-WAN, app signatures in other vendors) to identify Office 365, Salesforce, Zoom, Teams, etc.
2. Per-application policy. "Voice prefers MPLS or lowest-jitter broadband." "Salesforce goes direct internet break-out." "Bulk backup goes to whichever transport has spare capacity."
3. Per-tunnel SLA monitoring. Edges send keep-alive probes through every tunnel to measure latency, jitter, and loss. Path selection updates dynamically as conditions change.
4. Local queueing. On each WAN egress, traditional LLQ + CBWFQ still applies. The application-aware steering picks which tunnel; the per-tunnel queueing decides packet order within that tunnel.

So SD-WAN QoS is two-layer: application-aware path selection (which transport) plus per-tunnel queueing (what order within that transport). The traditional QoS toolset is still there; it just runs at a different scale.

Cisco Catalyst SD-WAN expresses this via centralized data policy:

! Conceptual policy expression in vManage
Match: application Office365
Action:
  preferred-color biz-internet
  fallback mpls
  sla-class voice-class

Match: application VoIP
Action:
  preferred-color mpls
  fallback biz-internet
  sla-class voice-class
  marking dscp ef

The vSmart compiles this into per-WAN-Edge state and pushes via OMP. See the SD-WAN cluster pillar and Cisco Catalyst SD-WAN architecture article for the underlying control plane.

QoS Over Internet Transport

Internet ISPs do not honor your DSCP markings. The IETF's IPv4 specification requires intermediate routers to preserve DSCP, but in practice:

• Most ISPs zero out DSCP at their network edge to prevent customers from gaming inter-AS QoS
• Some ISPs preserve DSCP within their network but do not act on it
• Public peering points strip DSCP routinely
• Cloud providers (AWS, Azure, GCP) do not honor DSCP inside their networks

Practical implication: your DSCP marking matters only at endpoints under your control. Your SD-WAN edge sees DSCP, applies queueing, and sends the packet over the internet. The next hop where DSCP matters again is the receiving SD-WAN edge.

What still works over internet:

• Edge marking and queueing. Local prioritization of traffic leaving your edge.
• SD-WAN path conditioning. Forward Error Correction (FEC), packet ordering, jitter buffers compensate for variable internet quality.
• Per-tunnel SLA-based steering. If one path's jitter spikes, voice automatically moves to a better path.
• Local jitter buffers at endpoints. The receiving softphone or video client absorbs jitter.

What does not work:

• End-to-end DSCP honoring
• Carrier-grade SLA on packet loss for VoIP
• Predictable latency over multi-AS internet paths

QoS at Cloud On-Ramps

Cloud on-ramps (AWS Cloud WAN, Azure Virtual WAN, Google Cloud Network Connectivity Center, AWS Direct Connect, Azure ExpressRoute) provide private connectivity from your network to the cloud provider's network. Inside the cloud provider's network, your DSCP is generally not honored (the provider does not own per-packet QoS for tenant traffic at the public-cloud scale).

What you can control at the cloud on-ramp:

• QoS at the SD-WAN edge facing the on-ramp. Your standard LLQ + CBWFQ on egress to the cloud.
• Bandwidth allocation per cloud (in multi-cloud). Reserve more bandwidth for the cloud carrying your latency-sensitive workloads.
• Path preference. Use AWS Direct Connect for production workloads; use IPsec VPN over internet for less critical traffic.

What you cannot control:

• QoS inside AWS, Azure, or GCP
• How the cloud routes traffic between regions
• Latency to specific services (CloudFront, Azure Front Door, etc.)

Application-Aware Policy: From DSCP Values to Application Names

The legacy QoS expression was DSCP-centric: "AF41 traffic gets 30 percent bandwidth." The modern expression is application-centric: "Microsoft Teams traffic gets the best path."

The translation:

The application-aware approach is more robust against the SaaS reality: an HTTPS connection to Office 365 looks identical to one to YouTube at the port level. NBAR2 identifies the service via DNS, certificate fields, and traffic patterns. AVC (Application Visibility and Control) extends this with reporting.

The legacy mechanics still apply underneath. Once an application is identified, the marking, queueing, and shaping are the same MQC patterns as before. NBAR2 is a more sophisticated classifier feeding the same MQC engine.

Wireless QoS in the Modern Era

Wireless QoS uses 802.11e WMM with four access categories (Voice, Video, Best Effort, Background). The Catalyst 9800 maps DSCP from incoming wired traffic into WMM access categories on the air, and CoS-marked frames from wireless clients into DSCP for upstream forwarding.

Modern wireless QoS additions:

• Auto QoS. One command (auto qos voip or equivalent on the C9800) configures the standard wireless QoS templates without hand-rolling MQC.
• AVC integration. NBAR2 runs on the WLC; identifies applications; applies marking and steering.
• Wi-Fi 6 (802.11ax) features. OFDMA improves QoS-like behavior at the radio layer (fairness across many simultaneous users); WMM still provides the application-class priority.
• Wi-Fi 7 (802.11be) Multi-Link Operation. A client can use multiple radios simultaneously; the AP can use the cleanest band for high-priority traffic.

For the wireless-specific configuration, see C9800 QoS Configuration: Auto QoS, DSCP Mapping, and Wireless Profiles.

End-to-End QoS in the Real World

The honest picture of "end-to-end QoS" in 2026:

The pragmatic engineering question: where in this chain do you have control, and what can you do at those points to maximize user experience? The answer for most modern networks is "the SD-WAN edge plus the local LAN," with everything in between treated as best-effort that you compensate for via SD-WAN path selection.

Modern QoS Design Patterns

Three patterns dominate 2026 designs:

1. SD-WAN with App-Aware Steering. The dominant pattern. Identify applications at the SD-WAN edge; mark with standardized DSCP; steer over multiple transports based on real-time SLA measurements. Local LLQ on each tunnel; SD-WAN handles the inter-tunnel decision.

2. SaaS-Direct with Local QoS. SaaS traffic exits the local SD-WAN edge directly to the internet (no backhaul). Local QoS prioritizes voice and video on the way out; the rest is best-effort over the internet. SASE handles the security inspection on the way out.

3. Cloud-On-Ramp with Per-Cloud Bandwidth. Multiple cloud providers; each gets its own on-ramp tunnel; per-cloud bandwidth allocation in the SD-WAN policy. Voice and video to specific clouds get prioritized; bulk transfer to other clouds gets the leftovers.

All three rely on SD-WAN as the policy enforcement point. The traditional MQC machinery still runs underneath; the policy expression is application-centric.

Anti-Patterns in Modern QoS

• Assuming DSCP is honored end-to-end. It is not. Plan for marking to disappear at every administrative boundary outside your control.
• Backhauling SaaS traffic. Sending Office 365 traffic to HQ for inspection then out to the internet adds latency for no benefit. Use SD-WAN direct break-out plus SASE inspection.
• Forgetting that internet is best-effort. Voice over public internet works most of the time; SD-WAN path conditioning (FEC, packet ordering, jitter buffers) helps; carrier-grade SLAs do not exist over consumer broadband.
• Over-engineering policy with too many classes. 12-class IETF models work in theory; in practice, 4-6 classes (voice, video, business, default, scavenger) are easier to operate and just as effective.
• Ignoring application identification accuracy. NBAR2 misidentifies some traffic. Audit periodically; tune signatures; do not assume the classifier is always right.

Summary

Modern QoS is application-aware steering at the SD-WAN edge plus local queueing on each tunnel, with the understanding that DSCP markings end at every administrative boundary outside your control. The traditional QoS toolset (MQC, LLQ, CBWFQ, DSCP) still runs underneath; the policy expression is more application-centric and the path selection layer is dynamic.

If you are designing modern QoS, focus on the SD-WAN edge as the policy enforcement point, accept that internet transport is best-effort, and rely on path conditioning + jitter buffers to compensate. Bookmark this article alongside the QoS cluster pillar, the SD-WAN cluster pillar, and the per-feature articles on DSCP, MQC, queueing, and voice/video QoS for the full design picture.