Summary

  • RFC 791 divided the Type of Service octet into precedence and separate delay, throughput and reliability indications; RFC 1349 later made service type a single four-bit choice and added monetary cost.
  • RFC 2474 replaced that structure with a six-bit DSCP selecting per-hop behavior, while RFC 3168 assigned the remaining two bits to explicit congestion notification.

An IPv4 implementation written from RFC 791 and one written two decades later could examine the same octet and see different structures. The field remained in the same place in the header. Its interpretation moved from a compact statement of importance and desired qualities to two mechanisms with different owners: differentiated forwarding treatment and congestion signaling.

This was not mere renaming. Later specifications openly acknowledged incompatibility, reserved compatibility codepoints where useful, and moved policy toward administrative boundaries. The octet became a case study in how a deployed wire format can evolve without becoming physically larger.

When quality was a set of switches

RFC 791 called the field Type of Service. Its first three bits carried Precedence, from Routine through several higher designations including network-control traffic. Three more bits independently requested low delay, high throughput and high reliability. The final two bits were reserved for future use.

The specification framed those middle choices as a tradeoff. Better performance in one dimension might worsen another or increase service cost in some sense. Except in unusual cases, it advised setting no more than two of the three indications. The packet was not commanding a universal treatment. It was describing desired abstract qualities that a particular network could map onto services it actually provided.

That distinction mattered because networks did not share one queueing system or one economic model. A low-delay request could influence path or service selection where such choices existed, but the bit itself could not manufacture capacity. Precedence likewise described importance without making every administrative domain honor the same privilege.

From bit combinations to one requested type

RFC 1349 revisited the octet in 1992 after years of conflicting definitions. It fixed the service portion at four bits and, contrary to RFC 791, treated it as a single enumerated value rather than independent switches. The recognized choices requested minimum delay, maximum throughput, maximum reliability, minimum monetary cost, or normal service.

The change prevented arbitrary combinations from acquiring accidental meaning. A sender selected one requested tradeoff; combining values with a logical OR was no longer a valid way to ask for several qualities. The cost value also made explicit a dimension that RFC 791 had discussed only as a possible consequence of better service.

RFC 1349 still kept the request modest. It sought a fixed-size field so new service types could be deployed, and said hosts and routers should handle an unfamiliar type correctly without needing to understand its semantics. The signal described a preference. It did not guarantee that the path would deliver the requested property.

The field became a behavior selector

By 1998, RFC 2474 replaced the TOS definition with the Differentiated Services field. Six bits became an unstructured Differentiated Services Codepoint, or DSCP. A compliant node matches the entire six-bit value and uses it to select a per-hop behavior implemented on that node. The mapping must be configurable.

The change replaced a small vocabulary of named end-to-end aspirations with a larger selector for forwarding treatment. A codepoint could identify a behavior, but an operator still controlled the local mapping and traffic conditioning. Nodes could rewrite the DS field at administrative boundaries. Service-level relationships between domains governed translations that the base field could not express by itself.

RFC 2474 did not pretend the new layout was identical to RFC 791. It called the structures incompatible. Limited backward compatibility came through Class Selector codepoints whose leading patterns corresponded to historical IP Precedence values and whose per-hop behaviors had minimum ordering requirements. This preserved useful deployed expectations without forcing the entire old semantic model onto the new one.

The result was compatibility by constrained reinterpretation. The wire location survived; selected historical patterns received a bridge; arbitrary assumptions about the rest did not.

Two unused bits found another owner

RFC 2474 labeled the final two bits Currently Unused for differentiated-services processing and required them to be ignored when choosing a per-hop behavior. RFC 3168 then used those positions as a separate two-bit Explicit Congestion Notification field.

Its four codepoints are Not-ECT, ECT(0), ECT(1), and Congestion Experienced (CE). A sender uses ECT(0) or ECT(1) only when the transport endpoints can participate. Under incipient congestion, an active queue management mechanism can set CE instead of dropping that capable packet. The receiver and transport sender then carry the response back into congestion control.

ECN therefore did not turn two spare bits into extra priority. It created a feedback channel with different semantics and different participants from DSCP. The upper six bits help a node select treatment. The lower two can record congestion for a capable transport. A router may still drop at a full queue, and traffic that is not ECN-capable does not gain a promise of marking instead of loss.

Stable position, unstable assumptions

The history is valuable precisely because the octet stayed visible while its meaning changed. An implementation that assumed every old bit retained its 1981 semantics could misread a later packet. A domain that treated every DSCP as a universal global rank could mistake a configurable selector for an entitlement. A device that erased CE could break an end-to-end congestion signal even while forwarding the packet.

The cited RFCs do not measure how consistently markings survived operational paths, tunnels, remarking policies or middleboxes. They do not establish that a specific codepoint buys a fixed latency, throughput, reliability or monetary price. Those outcomes depend on implemented behaviors, agreements and current path conditions.

What the sources do show is an architectural method. The IETF reused a scarce fixed location by documenting incompatible change, reserving bridges for deployed practice, assigning interpretation to administrative domains, and separating the congestion field from the behavior selector. The octet endured because its physical stability was not confused with semantic immutability.

Sources