Quality of Service is a scheduling decision, not a capacity one. When two packets contend for the same outbound interface, the policy decides which goes first. When nothing is contending, it does nothing whatsoever. Cisco states this without hedging in its own support documentation, and it is the most useful sentence in the subject, because most disappointed QoS deployments expected priority to substitute for bandwidth. Everything practical follows from it, including the uncomfortable fact that a marking set on your own switch may not survive the trip to the far end.
Provision first, queue second
Cisco’s VoIP design documentation opens on a precondition rather than a technique: ‘Before you consider applying any of the QoS features discussed in this document, you must first provision sufficient network bandwidth to support real-time voice traffic.’ Only then does the same document allow that ‘After you provision sufficient bandwidth for voice traffic, you can take further steps to guarantee that voice packets have a certain percentage of the total bandwidth and get priority.’
The reason is stated more bluntly elsewhere in Cisco’s support library: ‘Bandwidth guarantees are only an issue when an interface is congested.’ A policy map on an interface that never fills is inert.
There is a trap on the other side of that fact. Cisco describes what happens to a priority class under load: packets that match are policed to the configured rate and any excess is discarded, while an uncongested interface simply lets the class exceed its configured bandwidth. Marking more traffic as high priority therefore does not accelerate it. At the moment it matters, over-marked traffic is dropped rather than delayed. Microsoft adds the buyer’s version: bigger connections are the least complex fix but often cost-prohibitive, and QoS ‘enables you to manage the resources you have instead of adding bandwidth.’
Three marking schemes, living at three different layers
Prioritization is not one mechanism but at least three, at different layers, and one packet can carry marks from several at once.
The wireless one deserves a caveat, because it is where expectations break. WMM does not provide guaranteed throughput: contention parameters improve a station’s odds of reaching the medium sooner, and they do not add spectrum. Cisco’s argument for configuring it anyway concerns the default, since without QoS all traffic has the same priority and the same chance of being delivered at any given time.
- DSCP, at layer 3, is the IETF’s differentiated services field. RFC 4594 is the standards-track configuration guidance for service classes.
- IEEE 802.1p priority sits at layer 2, carried in the 802.1Q VLAN tag as the Priority Code Point, with eight levels numbered 0 to 7.
- Wi-Fi Multimedia, certified by the Wi-Fi Alliance and based on IEEE 802.11e, defines four access categories: voice (AC_VO), video (AC_VI), best effort (AC_BE) and background (AC_BK), using Enhanced Distributed Channel Access in place of the older distributed coordination function.
- Cisco maps those wireless categories to layer 3 values as 46 (EF) for voice, 34 (AF41) for video and 0 (BE) for best effort, which is how wired and wireless policy stay aligned.
Teams and Zoom mark video differently, and both are documented
Two vendors publish recommended markings, and they do not agree. Microsoft’s Teams guidance pairs port ranges with DSCP values: audio on 50,000 to 50,019 marked 46 (EF), video on 50,020 to 50,039 marked 34 (AF41), screen sharing on 50,040 to 50,059 marked 18 (AF21), and signaling on 50,070 to 50,089 marked 40 (CS5), which it notes is not configurable. Zoom recommends a four-class model instead: audio at EF, DSCP 46; video and screen sharing together at CS5, DSCP 40; signaling and control at CS3, DSCP 24.
Neither is wrong. The scheme is an administrative choice made once per domain, then enforced everywhere. Microsoft is explicit about doing it partially: ‘For QoS to be effective, you must apply consistent QoS settings throughout your organization. Any part of the path that fails to support your QoS priorities can degrade the quality of calls, video, and screen sharing.’ It adds that the DSCP value needs to be present at both ends of a call.
Zoom, meanwhile, says its clients often cope without any of this: the applications carry proprietary, adaptive features that optimize audio and video in real time, allowing a consistent experience with or without a DSCP marking strategy. Its case for tagging is narrower, that packets should be tagged so real-time audio and video are prioritized during times of network congestion. That is Cisco’s condition, reached from another direction.
Bleaching: where your tags stop meaning anything
The IETF’s working document on DSCP considerations describes the mechanism that defeats most first attempts. The DiffServ field can be re-marked at DiffServ domain boundaries, and a DSCP can be re-marked at the ingress of a domain. A specific form of that, which the draft calls bleaching, occurs when the field is re-assigned to the default treatment, CS0, hexadecimal 00. A re-marked packet that travels on then receives whatever treatment each further domain’s operator specifies.
Zoom states the practical version: DSCP tags may not be recognized by other internal network components, and tags can be stripped when traversing the internet. Marking is enforceable as far as your administrative authority reaches: the LAN, the campus, the WAN and a provider network held under contract. Beyond that it is a request nobody agreed to honor.
The trust boundary inside your own network deserves equal skepticism. Cisco’s Catalyst 9000 documentation notes that DSCP is trusted by default for all incoming packets, so an endpoint marking its own bulk transfer as EF will be believed unless the access edge polices it.
When the real fault is buffer depth, not class order
A large share of the latency people attribute to missing QoS is bufferbloat on the access link. RFC 8290, published in January 2018 by Toke Hoeiland-Joergensen, Paul McKenney, Dave Taht, Jim Gettys and Eric Dumazet, states the problem directly: excessive buffers in the network lead to poor end-to-end latencies for interactive applications. It specifies FQ-CoDel, which mixes packets from multiple flows to reduce head-of-line blocking from bursty traffic, isolates low-rate traffic such as DNS, web and videoconferencing, and keeps queue lengths short.
One bulk upload filling an oversized buffer on a branch router will ruin a call however carefully it is marked, because the delay accumulates in a queue the marking never reaches. Flow queueing at the real bottleneck fixes that. Classification does not.
An order of work the evidence supports
The sequence below follows from the sources rather than from habit, and the first two steps are the ones usually skipped.
- Set measurable targets first. Cisco, restating ITU-T Recommendation G.114, uses less than 150 milliseconds of one-way end-to-end delay for voice and packet loss far below 1 percent, and notes jitter buffers are usually only effective on delay variations under 100 milliseconds.
- Size the link for the load. Cisco puts a single G.711 call at 80 kbps, 64 kbps of payload plus 16 kbps of header. Multiply by concurrent calls.
- Choose one marking scheme per administrative domain and apply the same values to endpoints, switches, routers and WAN edges. Partial application is the failure Microsoft warns about.
- Set a trust boundary at the access edge and police what endpoints mark, since the switch believes them by default.
- Fix the bottleneck queue with active queue management before adding classes.
- Verify at the far end whether the marking arrived, and assume it did not on any internet path until a capture says otherwise.
Sources: Microsoft Learn · Zoom · Cisco Systems · Cisco Systems technical support library · IETF · RFC Editor
