DiffServ (Differentiated Services) is a networking architecture that prioritizes certain types of internet traffic over others. Instead of treating every packet equally, DiffServ lets network equipment sort packets into classes, like voice calls, video streams, or file downloads, and handle each class differently. A voice call gets fast, consistent delivery while a bulk file transfer waits its turn.
The system works by stamping each packet with a small code in its header that tells every router along the path how to treat it. This approach is the dominant method for delivering Quality of Service (QoS) on modern IP networks, used in everything from enterprise offices to internet service provider backbones.
Why DiffServ Exists
The original internet was designed as a best-effort network. Every packet got the same treatment, and if the network was congested, packets were dropped more or less at random. That’s fine for email or web browsing, but it’s a problem for real-time traffic like phone calls or video conferences, where even small delays or dropped packets cause noticeable quality issues.
An earlier approach called Integrated Services (IntServ) tried to solve this by reserving bandwidth for each individual data flow. A VoIP call, for example, would reserve its own dedicated path through the network. The problem was scalability: every router along the path had to track the state of every individual flow passing through it. On a busy backbone router handling millions of simultaneous flows, that overhead became unmanageable. Periodic refresh messages to maintain all that state information added even more traffic to the network.
DiffServ takes the opposite approach. Rather than tracking individual flows, it groups traffic into a handful of broad classes and applies simple, consistent rules to each class. Edge routers at the boundary of the network do the heavy lifting of classifying and marking packets. Core routers in the middle only need to look at a 6-bit code on each packet and apply the matching forwarding behavior. No per-flow tracking, no signaling between routers, no complex state to maintain. This “push complexity to the edge” design is what makes DiffServ scale to the largest networks.
How Packets Get Marked
Every IP packet has a small field in its header reserved for DiffServ. In IPv4, this is the old Type of Service (TOS) byte, repurposed. In IPv6, it’s the Traffic Class byte. Either way, six bits of that byte form the Differentiated Services Code Point, or DSCP. Those six bits can represent 64 distinct values, each one telling routers what level of service the packet should receive. The remaining two bits are reserved for a separate congestion notification feature.
The DSCP marking is typically applied at the edge of a network. When traffic enters a DiffServ-aware domain, an edge router classifies each packet based on rules set by the network administrator. These rules might look at the source address, destination port, protocol type, or other header fields. Once classified, the router stamps the appropriate DSCP value into the packet header. From that point on, every router in the network core simply reads the DSCP and applies the corresponding forwarding behavior without needing to inspect the packet further.
At the network boundary, routers also perform traffic conditioning. This includes metering (checking whether traffic stays within agreed-upon limits), shaping (buffering excess traffic to smooth it out), and policing (dropping or re-marking traffic that exceeds its allowance). These functions enforce the rules of service level agreements and prevent any single customer or application from consuming more than its share.
Per-Hop Behaviors
The DSCP value on a packet maps to a specific “per-hop behavior,” or PHB, which defines how each router along the path handles that packet. Four main behaviors cover the vast majority of real-world deployments.
Default Forwarding (DF) is plain best-effort delivery, the same treatment the internet has always provided. Packets with a DSCP of zero (also called CS0) get this treatment. Any traffic that hasn’t been explicitly classified ends up here.
Class Selector (CS) values provide backward compatibility with the older IP Precedence system. There are eight classes, CS0 through CS7, using only the first three bits of the DSCP field. Non-DiffServ routers that still use IP Precedence can read these bits and apply roughly equivalent treatment. Higher class numbers generally receive better forwarding priority.
Expedited Forwarding (EF) is the premium tier. It provides low loss, low delay, low jitter, and guaranteed bandwidth. Routers treat EF traffic with the highest priority, using dedicated queuing to ensure minimal delay. To prevent EF traffic from starving everything else during congestion, routers police it: any EF traffic exceeding its allocated rate gets dropped rather than allowed to crowd out other classes. EF carries a DSCP decimal value of 46 and is the standard marking for voice traffic.
Assured Forwarding (AF) is more nuanced. It defines four separate classes (AF1 through AF4), each guaranteed a minimum amount of bandwidth. Within each class, packets are further divided into three drop probability levels. During congestion, the router drops high-probability packets first, then medium, then low. This lets network operators protect important traffic within a class while still allowing less critical traffic to use spare capacity. The AF class number itself doesn’t imply priority: AF4 doesn’t automatically get better treatment than AF1.
Common DSCP Assignments
Industry guidelines from the IETF recommend specific DSCP markings for common traffic types. These aren’t mandatory, but most enterprise and service provider networks follow them closely.
- Voice (VoIP): EF (DSCP 46). The gold standard for real-time audio.
- Video conferencing (adaptive): AF41, AF42, AF43 (DSCP 34, 36, 38). Used for video that can adjust its bitrate based on network conditions.
- Video conferencing (fixed-rate) and interactive gaming: CS4 (DSCP 32). For video that can’t adapt and needs steady bandwidth.
- Broadcast video and live events: CS3 (DSCP 24).
- Streaming media: AF31, AF32, AF33 (DSCP 26, 28, 30). On-demand audio and video.
- Transactional data (client/server): AF21, AF22, AF23 (DSCP 18, 20, 22). Database queries, web applications, point-of-sale systems.
- Bulk data transfers: AF11, AF12, AF13 (DSCP 10, 12, 14). Backups, file transfers, email.
- Network control traffic: CS6 (DSCP 48). Routing protocols and network management.
- Low-priority or scavenger traffic: CS1 (DSCP 8). Background downloads, software updates.
Where DiffServ Works Well
DiffServ is most effective within a single administrative domain, meaning a network controlled by one organization. Inside a corporate network or a single ISP’s infrastructure, the administrator configures every router to honor the same DSCP markings and apply consistent forwarding behaviors. Voice calls get priority end to end, bulk transfers yield during congestion, and the network runs smoothly.
Enterprise networks are the most common deployment. An office network might mark VoIP phones with EF, video conferencing with AF41, and general web browsing as best effort. When congestion hits the WAN link connecting two offices, voice quality stays crisp while file downloads slow down instead.
Cross-Network Limitations
DiffServ runs into challenges when traffic crosses between different organizations’ networks. Each network operator sets its own policies, and there’s no universal requirement to honor another network’s DSCP markings. An ISP might re-mark or reset DSCP values on traffic entering its network, effectively stripping away the QoS treatment the sender intended.
For DiffServ to work across multiple networks, the organizations involved need service level agreements that specify how each traffic class will be treated at the boundaries between their domains. In practice, this works well between an enterprise and its ISP, or between peering ISPs that have negotiated such agreements. But across the open internet, where traffic may cross half a dozen networks with no coordinated QoS policies, DiffServ markings often don’t survive the journey intact.
This is why DiffServ is primarily a tool for managed networks rather than a general internet-wide QoS mechanism. It excels at prioritizing traffic within the networks you control or have agreements with, but it can’t guarantee end-to-end treatment across arbitrary internet paths.