What Is QoS? Quality of Service for Voice and Video

Real-time media has an unusual profile: small packets, sent at a constant rate, with a hard deadline. A single voice call is roughly eighty to ninety kilobits per second once IP, UDP and RTP headers are counted — trivial next to any modern link — but every packet has to arrive within a narrow window or it is useless, because there is nothing to play. ITU-T Recommendation G.114 sets the reference point: keep one-way delay below about 150 milliseconds and interactivity is essentially transparent to users, while delays beyond 400 milliseconds are considered unacceptable for general planning. Jitter, the variation in that delay, matters as much as the average, because a receiver's buffer can only absorb so much before it either adds delay or drops the late packet.

Bulk traffic is the opposite in every respect. A file transfer, a backup or an operating-system update wants throughput and does not care whether an individual packet takes ten milliseconds or two hundred; the transport will simply retransmit anything lost and keep going. Left to a single first-in-first-out queue, those two profiles compete on equal terms, and the bulk transfer wins by volume — it fills the queue, and the voice packets that arrive behind it inherit the entire queueing delay.

Congestion points are rarely where people expect. The obvious one is a wide-area circuit that is slower than the local network, and it is a genuine one. The less obvious ones are speed transitions inside the building: a ten-gigabit server port sending to a one-gigabit access port produces microbursts that overflow a switch's egress buffer in microseconds, invisible to any utilization graph averaged over a minute, and entirely capable of degrading a call. Uplink oversubscription in a wiring closet does the same. Any point where a faster interface feeds a slower one is a place where a queue forms.

Two marking schemes are in general use, at different layers. The first is the Priority Code Point, commonly called 802.1p, which is a three-bit field inside the 802.1Q VLAN tag — eight values, zero to seven. Because it lives in the VLAN tag, it only exists on a tagged frame and disappears the moment the tag is stripped, which means it is useful within a switched layer-2 domain and does not survive a routed hop. Nothing about the field defines what the eight values mean; that is a local convention, although voice conventionally lands on five and network control traffic higher.

The second is DSCP, the Differentiated Services Code Point, a six-bit field in the IP header defined by RFC 2474 and part of the DiffServ architecture in RFC 2475. Because it is in the IP header it survives routed hops end to end, which makes it the marking that matters for anything crossing more than one network. Its values map to per-hop behaviours: Expedited Forwarding, defined in RFC 3246 and carried as DSCP 46, is the low-latency treatment intended for voice media; the Assured Forwarding classes from RFC 2597 give several tiers with different drop preferences and are commonly used for interactive video and business applications; Class Selector values preserve compatibility with the older three-bit precedence field; and zero is default best-effort.

Deciding which application gets which value is not something to invent locally. RFC 4594 is the configuration guideline for exactly this — it defines a set of service classes and recommends a code point for each, placing telephony on Expedited Forwarding, real-time interactive and multimedia conferencing on Assured Forwarding classes, call signalling on a Class Selector value, and bulk data below best-effort. Following a published scheme means the markings mean the same thing to a service provider, a conferencing platform and the next engineer, which is worth more than a bespoke map. The critical caveat: a marking is a request, not an instruction. Every hop must be configured to honour it, and markings crossing an external boundary are typically re-written or ignored unless the service contract says otherwise.

Any device can set any value in its own packets. A workstation can mark a backup client as Expedited Forwarding, and on a network that accepts markings from access ports it will be forwarded ahead of the phone calls. This is not a hypothetical attack so much as an ordinary accident: software sets code points on its own initiative all the time, and some of it is optimistic. A QoS design that has not decided where it stops trusting endpoint markings is a design that has effectively given every application priority, which is the same as giving none of them priority.

The rule is to establish a trust boundary as close to the edge as possible. Access ports carrying general endpoints are untrusted, and the switch re-writes incoming markings to default. Uplinks between infrastructure you administer are trusted, because the marking was set or verified by a device under your control. Where a device genuinely needs to mark its own traffic — an IP phone is the standard case — the switch can extend trust conditionally: trust the phone's markings only while a phone is actually detected on the port, and untrust the PC daisy-chained behind it. The result is that priority is granted by the network's policy rather than by the endpoint's opinion.

For traffic that cannot be trusted to mark itself and cannot be ignored, the alternative is classification at the boundary: the switch or router identifies the traffic itself, by access list, by port, by VLAN, or by application recognition, and applies the correct marking on ingress. That is more configuration and it is the only honest option for legacy applications and for anything a user could tamper with. It is also where a voice VLAN earns its place — putting phones on their own VLAN gives the switch a simple, reliable classifier for traffic that must be prioritized, alongside the segmentation and power arrangements it already provides.

Marking decides nothing on its own; queues do the work. A switch port has a small number of hardware egress queues, typically four or eight, and the QoS configuration maps code points into them. One queue is normally configured as strict priority — it is serviced before all others, every time, which is what delivers the low latency Expedited Forwarding promises. That queue is always paired with a policer, because a strict-priority queue with no ceiling will starve everything else the moment it is oversubscribed, which turns a voice problem into a total outage. The remaining queues are serviced by a weighted scheme that shares the leftover capacity in proportions you set.

Drop behaviour is the second lever. Tail drop simply discards whatever arrives at a full queue, which tends to make many TCP flows back off simultaneously and then ramp up together. Weighted random early detection drops a few packets probabilistically before the queue is full, and preferentially from classes marked as more drop-eligible, which signals senders to slow down earlier and keeps the queue shorter — meaning lower delay for everything sharing it. Real-time traffic in a priority queue is not subject to this; it is policed instead, because a dropped voice packet is a defect rather than a signal.

Policing and shaping are the two ways to enforce a rate, and they are not interchangeable. A policer measures and immediately drops or re-marks anything over the limit; it adds no delay and no buffering, and it belongs at an ingress trust boundary or as the ceiling on a priority queue. A shaper buffers excess traffic and releases it at the configured rate, smoothing bursts at the cost of some delay, and it belongs where a fast interface feeds a slower path — the classic case being a gigabit handoff to a circuit provisioned at a fraction of that speed. Without a shaper on that handoff, the provider's equipment does the dropping, and it will not honour your priorities when it does.

On Wi-Fi the constraint is not a queue on a wire but access to a shared radio channel, so the mechanism is different. Wi-Fi Multimedia, which implements the prioritization part of IEEE 802.11e, defines four access categories — voice, video, best effort and background — and gives higher categories shorter waiting intervals and smaller contention windows before they may transmit. The effect is statistical rather than absolute: high-priority frames get more chances to seize the medium, not a guarantee of going first. Wi-Fi Alliance certification has required this since 802.11n, so any business-class access point supports it.

The join between the wired and wireless schemes is where deployments quietly lose their markings. A DSCP value in the IP header has to be mapped to one of the four wireless categories on the way out, and back to a DSCP value on the way in, and the historical default mappings were not consistent between vendors or with the DiffServ recommendations. RFC 8325 exists specifically to define a sensible mapping between DiffServ code points and 802.11 user priorities, and following it — on the access points, the controller and the wired ports they connect to — is what keeps a marked call marked from the handset to the far end.

Two wireless realities limit what prioritization can achieve. Airtime is shared, so a single distant client negotiating a low data rate consumes a disproportionate share of the channel and degrades everyone on it, which is an airtime-fairness and radio-design problem rather than a QoS one. And prioritization only orders the traffic that a given access point is handling; it does nothing about co-channel interference from a neighbouring access point or building. Wireless call quality problems are more often fixed by channel planning, access-point placement and minimum-data-rate settings than by a queueing change.

Keep the number of classes small. Hardware typically offers four or eight egress queues, and a design with twelve classes will be collapsed into those queues anyway, usually in ways the designer did not intend. Three to five classes covers nearly every organization: real-time media, call signalling, a business-critical or interactive class, best-effort, and optionally a scavenger class below best-effort for backups and updates. That last one is frequently the highest-value single change, because demoting bulk traffic below everything else solves most contention without needing to promote anything.

QoS is end to end or it is nothing, and the weakest hop decides the outcome. An unmanaged switch anywhere in the path cannot classify, mark or queue, so it forwards everything with equal urgency and discards your design at that point. A wide-area provider will apply its own class model, so mark to match what the contract specifies rather than to an internal scheme the provider will overwrite. And a link that is congested all day is a capacity problem: QoS decides who suffers during contention, and if contention is the normal state, the answer is more bandwidth, a second circuit, or moving the workload.

Finally, measure and write it down. Capture one-way delay, jitter and loss per class before the change and after it, from the places users actually sit, so the effect is a number rather than an impression. Record the class definitions, the code points, the trust boundaries and the queue mappings in a document that a future engineer can read, because an undocumented QoS configuration is one that nobody will dare to modify and everybody will eventually work around. When specifying hardware for a site that carries voice or video, confirm the switch supports the number of queues, the classification granularity and the conditional-trust behaviour the design needs — those are managed-switch capabilities, and they vary considerably between tiers within the same product family.