skip to content

What became of the IPv4 header's Type of Service byte, and what do its DSCP and ECN fields carry today?

level: middleimportance: should knowfreq 20%

answer

  1. the header's second byte
  2. six bits plus two bits
  3. a selector, not a guarantee
  4. a mark instead of a drop
  5. precedence survives as xxx000

basics

~20 s

RFC 2474 superseded the IPv4 Type of Service byte with a 6-bit DSCP that selects a per-hop forwarding behaviour, and RFC 3168 made the last 2 bits the ECN field, where a congested router can mark CE instead of dropping.

solid answer

~50 s

RFC 791 split the header's second byte into a 3-bit Precedence and delay, throughput and reliability bits, and later RFCs reshuffled the rest; little of it was used consistently. RFC 2474 superseded those definitions: the first six bits are the `DSCP`, one of 64 codepoints that a differentiated-services router maps to a per-hop behaviour. `000000` is the Default PHB, and the Class Selector codepoints `xxx000` keep IP Precedence's ordering. RFC 3168 gave the last two bits to `ECN`: `00` Not-ECT, `10` ECT(0), `01` ECT(1), `11` CE. The sender sets ECT when its transport understands ECN; a router whose queue management would drop such a packet early may set CE instead; the receiver's transport reports it and the sender slows as if a packet had been lost. Both fields can change in flight — DSCP re-marked at a boundary, ECN set to CE — and each change means a header checksum update.

go deeper

for a junior

Recall that the IPv4 header's second byte is now DSCP, which asks for a forwarding treatment, plus ECN, which lets routers flag congestion.

for a middle

Give the 6-plus-2 split, the four ECN codepoints and who sets each, and why the Class Selector codepoints exist for IP Precedence compatibility.

for a senior

Treat both fields as mutable and untrusted: expect re-marking at domain edges, check whether a path clears ECN bits, and remember every change forces a checksum update.

for a principal

Argue where to trust, re-mark or ignore incoming DSCP at a boundary, and what deploying ECN end to end requires of every device that touches the byte.

## The byte's history The second byte of the IPv4 header has been redefined more often than any other. RFC 3168's history section traces it: | Specification | Layout of the byte | |---|---| | RFC 791 (1981) | 3-bit Precedence, Delay, Throughput, Reliability bits, 2 reserved bits | | RFC 1122 (1989) | Precedence plus a 5-bit TOS field | | RFC 1349 (1992) | Precedence, a 4-bit TOS field, one must-be-zero bit | | RFC 2474 (1998) | 6-bit DSCP plus 2 currently unused bits | | RFC 3168 (2001) | 6-bit DSCP plus the 2-bit ECN field | RFC 2474 states that the DS field is "intended to supersede the existing definitions of the IPv4 TOS octet", and it obsoleted RFC 1349. RFC 3168 then records that the DS field covers only the first six bits, and assigns the last two to ECN. Interview shorthand: **"the old ToS byte is now DSCP (6 bits) plus ECN (2 bits)"**. The same split applies to IPv6's Traffic Class octet. ## DSCP: a selector, not a promise The **Differentiated Services Codepoint** picks the **per-hop behaviour** (PHB) a packet receives at each node that implements differentiated services: - Six bits give **64 codepoints**. - The mapping from codepoint to behaviour **MUST be configurable** in a DS-compliant node; the codepoint is a label the network interprets, not a guaranteed service. - `000000` is the recommended codepoint for the **Default PHB** — ordinary best-effort forwarding. - The eight **Class Selector** codepoints `xxx000` sit where IP Precedence used to be. RFC 2474 requires them to map to behaviours that preserve precedence ordering, and requires `11x000` to get better treatment than `000000`, protecting the historical use of precedence 6 and 7 for routing traffic. - A network may **re-mark** the field at an administrative boundary when its neighbour uses different codepoints for the same behaviour. Which codepoints a network uses and how its queues treat them is quality-of-service design; the header's part is only where the six bits sit and that routers may read and rewrite them. ## ECN: the four codepoints | Bits | Name | Meaning | |---|---|---| | `00` | Not-ECT | the transport does not use ECN | | `10` | ECT(0) | ECN-capable transport | | `01` | ECT(1) | ECN-capable transport | | `11` | CE | congestion experienced | RFC 3168 notes that its predecessor, RFC 2481, had used the same two bits as separate ECT and CE flags; the codepoint form replaced that. ## Who writes and who reads ECN 1. **The sender** sets ECT(0) or ECT(1) when both ends' transport has agreed to use ECN; otherwise it sends Not-ECT. 2. **A router** whose active queue management decides to signal incipient congestion first checks whether the packet carries an ECT codepoint. If it does, the router **MAY set CE instead of dropping**. A Not-ECT packet is dropped exactly as it would be without ECN, and a full queue still drops everything. 3. **The receiver's IP layer** passes the CE mark up; the transport reports it back to the sender. 4. **The sender** responds as if a packet had been lost — RFC 3168 requires the congestion response to a single CE to be essentially the same as to a single drop. The gain is that the signal arrives without losing the packet, so there is no retransmission delay. ## Reading the byte in a capture A capture shows the byte as one hex value. Shift right by two to get the DSCP; keep the low two bits for ECN: | Byte | Binary | DSCP | ECN | |---|---|---|---| | `0x00` | `000000 00` | 0, Default PHB | Not-ECT | | `0x02` | `000000 10` | 0, Default PHB | ECT(0) | | `0x03` | `000000 11` | 0, Default PHB | CE | | `0x20` | `001000 00` | 8, Class Selector for precedence 1 | Not-ECT | A packet that left as `0x02` and arrives as `0x03` was marked by a congested router on the way; one that arrives as `0x00` crossed a device that cleared the ECN bits. ## What follows for the header - **Both fields change in flight.** A DSCP re-mark or a CE mark rewrites header bits, so the router must update the header checksum. - **Old interpretations linger.** RFC 3168 warns that, because of the byte's unstable history, ECN cannot be guaranteed compatible with every older use of those two bits; a device that clears or rewrites them breaks ECN silently. - **DSCP is a request, not a credential.** Any sender can write any codepoint, which is why networks re-mark at their edges rather than trusting what arrives.

  • Why does RFC 2474 treat the IPv4 Class Selector codepoints xxx000 as a special case?
    For compatibility with IP Precedence. Those eight codepoints occupy the old 3-bit precedence positions followed by zeros, and RFC 2474 requires them to map to behaviours that keep precedence ordering, with `11x000` treated better than `000000` so routing traffic marked precedence 6 or 7 keeps its priority. Networks built around precedence keep working.
  • An IPv4 router's queue management wants to signal congestion with a Not-ECT packet; can it set CE?
    No. RFC 3168 has the router check for an ECT codepoint first and mark CE only on ECT packets instead of dropping them. A Not-ECT packet comes from a transport that would ignore CE, so the router drops it exactly as it would without ECN — the drop is the only signal that sender understands.

saying these in an interview costs you the question

  • Type of Service is still read as delay, throughput and reliability bits.
  • DSCP guarantees bandwidth or latency on every network the packet crosses.
  • ECN uses a single bit that routers set on congestion.
  • Routers set CE on any packet when their queue starts to fill.
  • Re-marking DSCP leaves the header checksum valid because DSCP is outside it.