Summary

  • IPv4 first carried advisory precedence and service preferences. DiffServ later used a six-bit codepoint to select a per-hop behavior, while classification, metering, policing, shaping and re-marking remained concentrated at policy boundaries.
  • A DSCP is neither a reservation nor a passport. AF and EF acquire practical meaning only through local resources and agreements; a receiving domain may accept, translate, reset or reject a mark it is not obliged to honor.

The packet reached a constitutional border

Imagine a voice packet leaving a company network marked for Expedited Forwarding. Inside that network, the mark selects a short queue backed by an allocated service rate. At the provider edge, the same six bits are visible. Nothing in them proves that the sender bought the service, stayed within its traffic profile or is entitled to consume the provider's scarce low-delay capacity.

The ingress router therefore does more than read. It classifies the packet, checks the traffic against policy, and may preserve, replace or erase the mark. A packet that was privileged a metre earlier can become best effort on the next link without violating the architecture.

That boundary is the central invention of Differentiated Services. The codepoint travels; authority over the queue does not.

The first octet expressed a wish

The history began with the IPv4 header. RFC 791, published in September 1981, defined an eight-bit Type of Service field. Three bits described precedence. Other bits expressed preferences for low delay, high throughput and high reliability. The field was meant to guide the treatment and path of a datagram across networks with very different capabilities.

Even the original text restrained the apparent hierarchy. Network Control precedence was for use inside a network, and its actual use and control were left to that network. If a network cared about access to privileged designations, it had to police them itself. A mark was not self-authenticating merely because the sender could set it.

The abstraction was attractive: let the application say what kind of service it wanted without knowing every underlying technology. Its weakness was equally fundamental. A preference could not manufacture a different path, spare bandwidth or a willing operator.

In 1992, RFC 1349 stated the limit bluntly. TOS was strictly advisory and unsuitable for requesting guarantees. Some networks would ignore it because there was no better route to choose. The field also could not express a quantity such as a required number of megabytes per second. The header could describe a direction of preference; it could not bind resources.

DiffServ made the limitation into an architecture

By the late 1990s, the Internet needed differentiation that did not force every core router to retain state for every application flow or customer. RFC 2474 and RFC 2475, both published in December 1998, supplied the DiffServ answer.

The six most significant bits of the former IPv4 TOS octet, and of the IPv6 Traffic Class octet, became the Differentiated Services field. A value encoded there is a Differentiated Services Codepoint, or DSCP. The two remaining bits later belonged to Explicit Congestion Notification; they are not extra DiffServ authority.

A DSCP selects a per-hop behavior, or PHB, at a node. The distinction between the value and the behavior is crucial. Several codepoints may lead to the same PHB. Some values may have purely local meaning. The behavior itself is an externally observable forwarding treatment applied to an aggregate of packets at one node—something implemented through queue scheduling, buffer allocation and drop policy.

It is not an end-to-end service. It is a building block from which a network may construct one.

Complexity moved to the edge so the core could stay small

DiffServ's scaling bargain placed rich decisions at network boundaries. An ingress node can inspect multiple fields, meter a stream against a profile, mark or re-mark packets, shape their timing and police excess traffic by dropping it. Interior nodes can then operate on aggregates rather than remembering each microflow.

The architecture calls a contiguous region with a common provisioning policy and PHB definitions a DS domain. That term marks an administrative fact as much as a topology. Inside the domain, nodes are expected to interpret acceptable codepoints consistently enough to deliver the configured behavior. At the boundary, the domain decides which outside statements enter that trusted context.

This is why a packet header could remain compact. The six bits did not need to contain the customer identity, contract, traffic profile, queue rate and sanctions for excess. Those facts lived in classifiers, configuration and agreements held by the parties responsible for the resources.

Assured Forwarding did not standardize assurance itself

RFC 2597 defined the Assured Forwarding PHB group in 1999. AF provides four classes, each with three drop-precedence levels. Within a class, packets marked with greater drop precedence should face a higher probability of loss during congestion, while packets in the same microflow must not be reordered merely because their drop precedences differ.

The familiar labels can look like a global service menu. They are not. The document does not prescribe how much bandwidth or buffer each AF class receives relative to another. Actual assurance depends on the resources a provider allocates, the current load and the packet's drop precedence. A DS-compliant node is not even required to implement AF.

At the edge, a provider may shape AF traffic, discard it, change its drop precedence or move it to another class. The result is predictable only when marking and traffic profiles match the domain's provisioning. The number on the packet does not create the allocation it names.

Expedited Forwarding stopped at one node

The name Expedited Forwarding seems even more like a promise. RFC 3246, which replaced the first EF specification in 2002, carefully narrows it. A node claiming EF must supply service at or above a configured rate and can quantify behavior under bounded operating conditions. But the RFC defines one node. The behavior of a collection of nodes lies outside its scope, and a DiffServ-compliant node need not implement EF at all.

Low delay across a path therefore requires every relevant node to be provisioned and the offered traffic to stay within the conditions that keep queues short. One honest EF implementation cannot compel the next router, repair an overloaded domain or convert a missing commercial agreement into capacity.

This is not a failure of standardization. It is a truthful division between a testable forwarding primitive and a service assembled across multiple control surfaces.

The contract could not fit in the codepoint

RFC 2475 used the terms Service Level Agreement and Traffic Conditioning Agreement for the arrangements that connected service claims to boundary rules. RFC 3260 later clarified why the protocol could not own those words completely: an agreement may include pricing, availability and other commercial matters beyond DiffServ. It introduced Service Level Specification and Traffic Conditioning Specification for the narrower technical parameters.

That vocabulary records a constitutional limit. The IETF could standardize the field, PHB requirements and how a compliant node behaved. It could not standardize which customer had purchased which service, how two carriers settled obligations or how much capacity an operator installed.

An ingress receiving an unacceptable codepoint may discard the packet or change it to an acceptable value. Traffic from a domain with no enhanced-service agreement may be reset to Default. After boundary conditioning, an unrecognized mapping normally receives Default behavior rather than arbitrary privilege. The receiving network remains the principal for its buffers and schedulers.

A mark that anyone can set needs a gate

DSCP is not an authentication field. Software at an endpoint can set high-preference values, and an adversary can alter an unauthenticated outer header. The DiffServ RFCs therefore treat theft of service as an architectural threat. If forged privileged traffic consumes the resources reserved for enhanced classes, the theft becomes denial of service.

Boundary conditioning is the primary defense. The edge determines whether the mark is appropriate for the traffic and policy, while interior nodes rely on the cleaned aggregate. Tunnel endpoints face the same obligation when a protected inner header emerges into a new policy domain. Cryptographic integrity may establish where a mark came from; it still does not prove that the next operator promised to honor it.

The security model reinforces the larger lesson: a claim placed in a shared header is evidence to evaluate, not authority to obey.

New links kept exposing the translation problem

Later operational guidance did not turn DSCP into a universal language. RFC 7657 observed in 2015 that an endpoint cannot know which PHB a class-selector codepoint selects in a particular network, much less across an entire path. Even CS1, commonly associated with lower-effort service, may receive Default or better treatment, be re-marked or be dropped where that service is absent.

RFC 8325 showed the same limit where IP meets Wi-Fi. DiffServ DSCP and IEEE 802.11 User Priority are different classification spaces. An access point may translate between them, and a value with no corresponding service may become Default. The boundary has to interpret; copying bits is not enough.

Thin coordination survived because local control survived

DiffServ's durable idea was not that six bits could govern the Internet. It was that six bits could coordinate running systems without pretending to contain the whole bargain. Standards supplied a shared vocabulary and testable node behaviors. Operators supplied resources, admission rules and maps. Customers and neighboring domains supplied profiles and agreements. Boundary devices made those layers meet.

The architecture became scalable by refusing to turn a mark into a portable claim on somebody else's capacity. It kept the common layer small and made stronger service conditional on visible, local acts. A packet could ask. A configured node could answer. No header field could appoint itself sovereign over the next network.

Sources and limits

The chronology and original TOS semantics come from RFC 791 and RFC 1349. The DS field and architecture come from RFC 2474 and RFC 2475; AF and EF from RFC 2597 and RFC 3246; later clarification and deployment boundaries from RFC 3260, RFC 7657 and RFC 8325. These standards do not reveal any current operator's queue configuration, customer entitlement, commercial agreement, deployment share or measured end-to-end performance.