Summary

  • RFC 1046 proposed a limited low-delay queue whose admitted datagrams could meet a per-node waiting bound; overflow was discarded, and the class's link share was limited so prompt traffic could not exclude every other class.
  • Under contention, several Type-of-Service requests were alternatives, not cumulative rights. A packet could receive one queue treatment, while fallback could improve admission at the price of reordering, variable one-way delay and a different reliability bargain.

The counterintuitive object in RFC 1046 is not the Type-of-Service bit. It is the empty buffer slot. A node could promise less waiting only if it refused to let the low-delay queue grow. Once all of the permitted slots were occupied, the next marked datagram was not owed more memory. It was discarded.

Published in February 1988 by W. Prue and J. Postel, the memo called itself an idea paper. It explored what an IP link might do with the service indications already carried in the IPv4 header. It did not report a universal deployment, settle the percentages or define an Internet-wide service contract. Its value lies in making the costs of a desirable label unusually visible.

The header named a trade before a router implemented it

RFC 791 gave IPv4 an eight-bit Type of Service octet. Three bits expressed precedence. Others indicated preferences for low delay, high throughput and high reliability. The specification described the main choice as a three-way trade-off: improving one property could worsen another, and unusually no more than two of the three should be requested.

The field was an abstract statement. A gateway still needed an algorithm, queues, buffer limits and transmission opportunities before the statement changed the fate of a packet. RFC 1046 began with that gap. It observed that nothing yet said what to do with the parameters, then assumed the condition in which the answer mattered: demand exceeded present capability. If significant queues did not form, special queueing was superfluous.

That condition prevents a common historical mistake. Service differentiation is not created by a label alone. It becomes consequential when several packets compete for finite buffer and link time, and a node has to decide which cost each class will bear.

Less waiting required less room

RFC 1046 wanted a low-delay-only datagram to traverse a node promptly even under load. It named the target Maximum Guaranteed Delay, or MGD, per node, conditional on the datagram successfully traversing the Internet. The condition is essential. The proposal bounded the waiting of an admitted packet; it did not promise that every marked packet would be admitted or delivered.

The arithmetic was direct. If N was the size of the low-delay queue, P the fraction of link resources allocated to the class and R the link rate in datagrams per second, then:

Max Delay = N / (P × R)

Holding the target fixed meant that a slower link or a smaller allocation required a smaller queue. A high-propagation-delay link could reduce the available queue budget still further. The proposed guarantee therefore lived in configuration and physical conditions: queue depth, service share and link rate. The packet header contained none of those numbers.

The memo initially recommended servicing the low-delay queue at a lower rate than the other classes so it could not consume excessive resources. The queue remained small enough to protect waiting time. When arrivals exceeded the limit, the node discarded the excess. Source Quench was considered too slow for such a small queue and was not to be used for this class in the basic design.

This is the bargain hidden by the attractive word “fast.” The low-delay class did not get every scarce resource. It traded away throughput and congestion reliability so the packets that fit could wait less.

Reliability bought a longer wait

The high-reliability queue inverted the choice. It was longer than normal, sent Source Quench earlier and delayed discard until the queue was full. More buffering raised the chance that a packet would survive transient congestion, but it also raised potential waiting time. The memo warned that this could address unreliability caused by congestion only. A noisy link or a need for forward error correction belonged to a different mechanism.

High throughput used the largest service rate in the example and a larger queue, accepting more average delay at the node. The suggestion to keep bursts together was explicitly tentative because it assumed facts about upper-layer protocols that a queue might not know.

The three queues did not label packets as good, better and best. They assigned different failure modes. Low delay risked early loss. High reliability tolerated waiting. High throughput consumed transmission opportunities and accepted a larger buffer. “Better” had no meaning until the application chose which harm it could bear.

Three requests did not make three entitlements

The most important rule appears before the queue details: when resources were contested, a request for several service classes was an OR request, not an AND request. Low delay and high throughput could both be obtained only when there was no contention.

Later in the memo, the implementation consequence becomes concrete. Only one class queue could serve a datagram at a time. The proposed selection order was low delay, then high throughput, then high reliability. If a low-delay/high-reliability packet found the low-delay queue full, the node could place it in the reliability queue. That fallback gave it another chance to enter the system, but it changed the treatment.

For a block of packets, different queue choices could reorder the data and make one-way transmission times more variable. A receiver looking only at the original bits could not reconstruct which queue accepted each datagram, how long it waited or which packets were discarded. The request travelled end to end; the decision was local and per occurrence.

Priority was allowed to cut in, but not forever

The three service preferences sat beside eight precedence levels. RFC 1046 proposed that a higher-priority arrival move ahead of lower-priority datagrams within the chosen class queue. Yet it also tried to prevent indefinite starvation. Every time a waiting datagram was overtaken, its local “frustration” value rose until it could no longer be preempted by the same newcomers.

The adjustment was local to the node and disappeared at the next hop. It did not change the packet's advertised priority. A high-priority arrival also could not eject an older packet from a full queue; the newest arrival, priority or not, was discarded.

This second scheduling dimension disturbed the simple MGD story. In the memo's example, a low-delay packet without matching high priority might experience between one and 28 times the delay calculated without priority queueing. A system that reports only “low delay requested” therefore omits the competing state that determined whether the bound remained meaningful.

The proposal left its constitutional questions open

RFC 1046 offered illustrative shares—17 percent low delay, 50 percent high throughput and 33 percent high reliability—and a proportional “chit” mechanism to keep classes near their allocations. It did not sanctify those numbers. Its issues section asks who should choose class percentages, what MGD should be promised, how attractive classes and high priorities should be limited, whether routing complexity was acceptable and what simulation would reveal.

Instrumentation was part of the answer. The node should count which service was actually used when a packet requested several and adjust allocations when observed loss and use diverged. An administrator, not the bit, would have to interpret an imbalance and change policy.

The memo's historical honesty survives in that unfinished work. Queueing is not merely a mathematical mapping from three bits. It allocates loss, waiting and capacity among users. Someone must own the parameters, observe the consequences and remain able to reverse a poor choice.

Later standards narrowed the historical claim

RFC 1349 later said the TOS mechanism was strictly advisory and unsuitable for requesting service guarantees. A minimize-delay value asked the network to prefer the lowest-delay path available; it did not promise a delay the user would consider low. In 1998, RFC 2474 and RFC 2475 replaced the old TOS interpretation with the DS field and separated a codepoint, a per-hop behavior, a service, traffic conditioning and the mechanism that implemented the behavior.

Those later documents do not prove that RFC 1046 was deployed or that DiffServ inherited its exact queues. They make the distinction more explicit: a portable mark is not the same object as a local forwarding mechanism or a provisioned service.

The Source Quench references also need a firm date boundary. RFC 1016 described the contemporary idea that a host would slow after congestion feedback. RFC 6633 later required hosts not to send Source Quench, transports to ignore it and the RFC 1016 approach not to be implemented. RFC 1046 records a 1988 design space; it is not current Source Quench guidance.

Sources and limits of evidence

RFC 791 supplies the original TOS field and trade-off. RFC 1046 supplies the idea-paper status, MGD model, queue formula, class rules, OR semantics, priority treatment and unresolved questions. RFC 1016 and RFC 6633 bound the historical Source Quench context. RFC 1349 supplies the later advisory limit. RFC 2474 and RFC 2475 establish the later DS-field architecture.

The sources do not show that a particular network implemented the algorithm, what queue depths or percentages an operator used, whether any packet received its requested class, or what present DSCP markings mean in a specific domain. A mark is evidence of a request. Queue admission, scheduling, discard, delivery and application outcome remain separate facts.