Summary

  • RFC 795 mapped the original IP Type of Service fields—precedence, delay, throughput and reliability—onto the service choices of AUTODIN II, ARPANET, PRNET and SATNET. Each network offered a different set of controls.
  • The tables exposed sharp edges: PRNET had no priority indication, ARPANET had only one priority bit, some requested DTR combinations collapsed to the same service, and 111 was an error in two listed mappings.

Imagine ordering a fast, reliable, first-class ride with one eight-bit form. The clerk passes it to four transport companies. One has a priority stamp, one has a single priority switch, one has no priority counter at all, and the fourth offers 48 combinations of knobs. Jon Postel's September 1981 RFC 795 is that awkward order desk in four pages. The IP header could express a preference. Crossing into a particular network required someone to translate it into a service that network actually knew how to provide.

The form was IP's original Type of Service byte. Three bits described precedence, followed by one each for low delay, high throughput and high reliability; the last two were reserved. The precedence scale ran from routine up through priority, immediate and flash to network control. It was a compact vocabulary for asking. Postel's point arrived in the next sentence: the individual networks had very different service choices. The rest of the memo was a set of actual mappings rather than a sermon about universal quality.

AUTODIN II divided its choices between traffic acceptance categories and application types. The former mapped reasonably directly to IP precedence. The latter supplied combinations of delay, throughput and reliability: I/A favored delay, B1 throughput, B2 throughput plus reliability, and Q/R the ordinary setting. A reverse table made the mismatch plain. More than one IP DTR pattern led to Q/R or I/A, while 111 ended in “error.” The packet's three wishes did not force a fifth item onto the local menu.

ARPANET was more austere. It had one priority bit, which Postel could map to the high-order bit of IP precedence. Other distinctions involved regular Type 0 versus uncontrolled Type 3 messages and single-packet versus multipacket messages. Type 3 multipacket was disallowed. Several DTR values mapped to the same regular multipacket form; 100 and 110 selected a Type 3 single packet; 101 chose a regular single packet; 111 was again an error. In a tidy universal story, each new bit buys a new service. On this network, several combinations bought the same ticket.

PRNET made the priority question even plainer. The network offered no priority indication. Its choices were station versus point-to-point routing and acknowledgment versus no acknowledgment. Postel's mapping let delay steer the route type and reliability steer the acknowledgment choice. Throughput could change in the IP request without changing the resulting PRNET pair in his table. A sender could write “important” in the IP precedence field; there was no matching priority lever on that network.

SATNET had the opposite sort of complication. It also lacked a priority indication, yet it offered block or stream service, four delay categories, two holding-time strategies and three reliability levels. Multiply them and the result is 48 possible local combinations. A short IP DTR request could not describe each of those switches separately. A gateway would need a rule for choosing among them; the memo recorded the breadth of local options rather than pretending one byte mapped neatly to every one.

Postel's tables are entertaining because they refuse to flatter the header. They show exact places where a request collapses, encounters an error, or meets a capability with no corresponding bit. The Internet's common vocabulary made unlike networks speak to one another. It did not make their equipment identical. In 1981, that distinction fitted on four pages of menus, and the smallest print was where the engineering lived.