Quality of Service, and the Condition It Needs to Do Anything

The conditionThe condition everybody skips

A router forwards data packets as fast as the outgoing interface allows. If packets arrive slower than the available bandwidth, every packet leaves immediately and there is no queue. Nothing is waiting, so there is nothing to prioritize, and any QoS policy configured on that interface has no work to do.

QoS becomes real the moment arrivals exceed what the interface can send. Then a queue forms, and the question of which packet leaves next is a question with an answer.

Without quality of service the answer is first in, first out, and a large file transfer will happily fill the queue with its own data packets while a voice call waits behind them, adding latency to exactly the real time application that cannot absorb it.

That is the whole value proposition, and it explains the two most common disappointments. QoS on a gigabit LAN that never fills does nothing, correctly.

And quality of service cannot help when the link is simply too small, because prioritizing traffic on a saturated network means choosing what to drop, and if every application is critical the answer is more bandwidth rather than better rules.

The useful framing is that QoS decides how a network fails rather than whether it does.

What it measuresThe network performance parameters QoS manages

Quality of service is measured with four parameters, and every QoS mechanism exists to control one of them for the applications that are sensitive to it.

• Bandwidth is the capacity of the link, the amount of data it can carry per second. QoS divides it among traffic classes and cannot add to it.
• Latency, or delay, is the time a packet takes to cross the network from sender to receiver. Time spent waiting in a queue is the part QoS controls.
• Jitter is the variation in that delay from one packet to the next. Real time applications such as voice and video play data out at a fixed rate, so uneven arrival is heard as choppy audio.
• Packet loss happens when a queue is full and the router drops the packets that do not fit. TCP resends lost data, and a voice call cannot wait for a resend.

Business critical applications and real time services suffer first when these numbers slip, which is why QoS policies are written around applications and their traffic rather than around users.

QoS modelsThree QoS models: best effort, IntServ and DiffServ

Networks deliver quality of service under one of three models.

Best effort is the default and means no QoS at all. Every packet gets the same treatment and nothing is guaranteed. Most of the internet runs this way.

Integrated Services (IntServ) reserves network resources for each traffic flow before any data is sent. Applications signal what they need with RSVP, the Resource Reservation Protocol defined in RFC 2205, and every router on the path keeps state per flow. It gives hard guarantees and it does not scale, so it is rare outside specialized networks.

Differentiated Services (DiffServ), defined in RFC 2475, is what almost every business network uses. Packets are sorted into a small number of classes and marked, and each router treats a class the same way, hop by hop, with no reservation and no per flow state. Everything below about marking, DSCP values and queuing describes DiffServ.

Marking and queuingQoS marking and QoS queuing are two different jobs

This is where most configurations go wrong, and the distinction is simple once stated.

QoS marking writes a value into the packet that says what traffic class it belongs to. On IP that value is DSCP, six bits in the header field that used to be Type of Service.

Marking is cheap, it is done as close to the source as possible, and by itself it changes nothing at all. A marked packet on an uncongested link is an ordinary packet with a number in it.

QoS queuing is the part that acts. When a network interface is congested, the queuing discipline reads the marking and decides the order packets leave and which get dropped. Packet prioritization is the plain name for this step.

Priority queuing sends one class first, always. Weighted fair queuing gives each class a share. Shaping delays traffic to a rate below the physical line speed, which is how you create a queue you control instead of one your provider controls.

Marking without queuing is the most common QoS deployment in the world and it accomplishes nothing. The markings are correct, the reports look right, and no interface anywhere is treating one packet differently from another.

Traffic shaping and traffic policing

Both enforce a rate limit on a class of network traffic, and they differ in what happens to the excess. Traffic policing drops or re-marks packets above the rate at once. Traffic shaping buffers them and sends them a moment later, which smooths bursts at the cost of some added delay.

Policing suits the cap on a priority queue, so that voice cannot starve other services. Traffic shaping suits WAN egress, where the physical interface is faster than the rate you bought from the provider.

QoS trust

QoS trust is the third piece. A network switch or router decides whether to believe the DSCP value a packet arrives with. Trusting everything means any workstation can mark its own traffic as voice, which people do accidentally and applications do deliberately.

The usual policy is to trust markings from phones and known devices, and to rewrite everything from a user port to best effort.

ApplicationsWhat different applications actually need

QoS classes exist because applications tolerate different things, and the tolerances are not a matter of which applications are critical to the business. They are a matter of physics on the network.

Read the last column against the second. The applications that need protection use almost no network resources, and the applications that move the most data need no protection at all. That asymmetry is what makes quality of service work: guarding voice costs the network almost nothing, because there is almost nothing of it.

It also explains the classic complaint. A backup starting at nine in the morning does not break calls because backups are important, it breaks them because backup software is designed to use every bit of bandwidth available and has no reason not to.

The classesThe classes worth using

RFC 4594 recommends how service classes map to DSCP values, which it calls codepoints. The full list is long and most networks need five or six of these QoS classes.

Two things about that table are worth stating plainly.

The number of classes should be small. Every class is a queue with a share of the network interface, and dividing a link into ten classes means each one is guarding a slice of bandwidth too thin to matter. Three or four classes plus best effort covers almost every real network.

And the expedited forwarding class, EF, is a strict priority queue in most implementations. Traffic in it goes first, always, which is correct for voice because voice is low volume and delay sensitive.

It is also why putting any high bandwidth application into EF is destructive: a class that always goes first and never runs out of packets starves every other service on the link.

Where it worksWhere QoS works, and where it cannot

QoS acts at the bottleneck, and the bottleneck is almost never inside your LAN.

WAN egress is where it works. The interface from your router to the internet or to an MPLS circuit is the narrow point in the network, it is where network congestion happens regularly, and you control it. This is where a policy earns its keep, and it is usually the only place one is needed.

Inbound is the case people misunderstand. Traffic arriving from the internet was already queued by your provider, on their interface, before it reached you. By the time a packet is on your side the congestion has already happened.

You can shape your own inbound by dropping packets to slow senders down, which works for TCP because it responds to loss, and does nothing for UDP applications such as video streams.

Across a provider network, markings are advisory at best. Most internet transit rewrites DSCP to zero at the edge, because honoring somebody else's markings would let every customer mark everything as priority.

An MPLS or managed WAN service can carry your markings, and whether it does is a contract term to check rather than assume. If it is not in the service description, assume the field is bleached.

Wireless QoS is its own subject. Wi-Fi uses WMM with four access categories rather than DSCP, and the mapping between them is a place where markings quietly get lost on a wireless network. A voice packet correctly marked EF on the wire can arrive as best effort over the air if the access point is not configured to map it.

How organizations implement QoS, in order

A QoS rollout is network management work more than configuration work, and the steps are the same on every platform.

1. Measure network performance first: utilization per second on the WAN interface, plus latency, jitter and packet loss for the applications people complain about. 2. List the specific applications and services that are sensitive to delay, and leave everything else in best effort. 3.

Mark that traffic as close to the source as possible, and set the trust boundary at the access switch. 4. Apply queuing and traffic shaping at the congested interface, with a policer on the priority class. 5. Monitor the per class counters, and revisit the policy when applications or data volumes change.

PitfallsWhere QoS deployments go wrong on real networks

Configuring it where there is no congestion. A policy on a network interface with spare bandwidth is a policy that has never run. It will run for the first time during an incident, which is a bad time to discover a mistake in it.

QoS marking without a queuing policy. Covered above and worth repeating, because it is the most common state of a real network: correct markings, and no network interface acting on them.

Trusting markings from user ports. One workstation marking its backup traffic as EF can starve every phone on the site, and nothing in the monitoring will point at it.

Putting bulk traffic in the priority queue. EF is strict priority in most implementations. Anything high volume in there is not prioritized, it is a denial of service against every other class.

Using quality of service to avoid buying bandwidth. It buys time and it does not create capacity or network resources. A link that is congested for six hours a day needs more bandwidth, and QoS only changes which users complain.

Ignoring what happens at the far end. A policy on your egress does nothing about the return traffic, and both directions need attention if the application is interactive. This is the same asymmetry that makes latency and packet loss behave differently in each direction.

Assuming markings survive. Check what actually arrives. A capture at both ends of a circuit answers in minutes what a design document will assert for years.

Checking itHow to check whether QoS is doing anything

Three checks, in order, and the first one settles most network performance complaints.

Is the interface ever congested? Look at utilization in your network monitoring or bandwidth management tool at the granularity of seconds rather than the five minute average, because a link that averages 40 percent of its bandwidth can be full for two seconds at a time, and two seconds is an audible gap in a call. Five minute averages hide exactly the events QoS exists for.

Are the queues being used? Every platform can show per class packet and drop counters on a network interface. A class with zero packets is a class nothing is being marked into. A class with drops during the complaint window is the policy working, or the policy being wrong, and the counters distinguish them.

Do the QoS markings survive the network path? Capture at the sending side and at the receiving side and compare the DSCP field on the same traffic flow.

If it arrives as zero, everything downstream of the bleaching point is treating it as best effort no matter what the local configuration says. A packet capture is the only honest answer here.

ComparisonQoS, more bandwidth, SD-WAN, or nothing

The second row is the one worth reading twice. QoS is not a performance improvement to a working network, it is insurance for critical applications on a failing one, and the cost of that insurance is that somebody has to maintain a policy that is invisible until the day it runs.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Protocols TCP vs UDP Why shaping inbound traffic slows a TCP sender down and does nothing at all to a UDP stream. Open this next10 min

• Infrastructure · 11 min MPLS Explained The kind of managed circuit that can carry your markings across a provider, unlike ordinary transit.
• Diagnostics · 11 min Packet Loss vs Latency, and Why They Feel the Same to Users What congestion actually does to an application, and why the two symptoms need different fixes.
• Network fundamentals · 9 min Application Service, the Three Things People Mean by It A traffic-shaping neighbour of the delivery-and-security functions here.
• Wireless · 9 min 5GHz Channels, and Why Most of Them Come With Conditions The spectrum side of the same capacity question.
• Network operations · 10 min Bandwidth Management, the Four Levers and When to Pull Each The quality-of-service detail this page treats as one lever of four.
• Network services · 9 min NTP Stratum, How Far a Server Is From the Clock A neighboring network service concept in the same silo.
• Network operations · 9 min NetFlow, the Record of Every Conversation on the Network The traffic classes NetFlow helps you see before you shape them.