Summary

  • RFC 1363 proposed a flow specification for applications such as multimedia conferencing. It described a caller's traffic and sensitivities, but made the delay preference advisory instead of treating one number as a universal maximum.
  • A service request covered one direction. The network could accept or refuse a requested guarantee, and a path with an Ethernet last hop might work well without being able to promise that it would never saturate.

A video call between the United States and Japan might feel fortunate to arrive in 100 milliseconds. The same delay for two people in one city could feel like a poor bargain. Craig Partridge made that comparison in RFC 1363, an Informational proposal from September 1992. It was an awkward fact for anyone who wanted to fill a box marked “maximum delay” and ask the Internet to sign underneath.

Partridge was writing for distributed applications that wanted more than ordinary delivery: multimedia conferences, visualization and other work whose usefulness could change with bandwidth, delay or lost packets. A host might ask the internetwork for resources before sending data, during setup or while traffic was already moving. The memo did not choose that negotiation machinery. It designed the data structure the host would bring to the conversation. Getting the request right mattered because a precise-looking number could disguise a promise that no path could make.

The proposed Minimum Delay Noticed field carried a deliberately narrower meaning. It told the network when further reductions would stop helping the application. It was not a maximum acceptable end-to-end delay. Distance made an absolute ceiling hard to choose; the network might not know the geography, and mobile endpoints made it harder. Partridge also rejected the claim that conversation simply stopped after about 100 milliseconds. A call with several seconds of delay could still be worth making when the other choice was no call at all. The number had to describe a preference, not legislate every caller's patience.

The request began with a bill of materials for the traffic itself: a sustainable token-bucket rate, a peak transmission rate and an approximate burst size. Those numbers let a routing system compare a proposed flow with a candidate path. The memo's own example rejects sending more than 10 megabits per second through a 1.5-megabit T1 link. No choice of reassuring words in a delay field could make that capacity fit.

A call also had a receiving end. Packets sent at regular intervals could emerge from queues at irregular intervals, so a receiver needed buffer space to restore the rhythm. RFC 1363 tied permissible delay variation to that buffer budget; its worked model related the required buffer to the full spread in packet delay multiplied by the transmission rate. Loss had separate dimensions: total losses over an interval and consecutive losses. Counting losses alone would miss the damage caused when several packets vanished together. The specification put those questions beside bandwidth rather than hiding them under a single “fast” label.

Then came the question that made a service claim expensive. The Quality of Guarantee field distinguished a mere hint, an imperfect guarantee, predicted service and a firm guarantee. Partridge pointed to IETF conferencing experiments in which an Ethernet last hop could perform acceptably. That same shared segment could saturate during a flow's lifetime. The network could offer a useful path with an island of uncertainty; it could not sell that path as a guarantee at every hop. Predicted service was a different bargain: cooperating routers and links might let performance dip modestly under load. An imperfect guarantee could fail outright at its noncooperating segment. The two labels told the application different things about the risk it was accepting.

For a firm request, the expected answer was yes or no. Partridge preferred asking for the minimum acceptable service and letting the network accept or refuse. He resisted an elaborate setup conversation in which a host demanded perfection and haggled down through possible routes. That would turn the beginning of a call into a potentially lengthy search. A refusal could still return a modified flow specification as a hint about what the network might support; it was not a standing offer.

The memo proposed a language for asking, not an Internet-wide reservation system. It left the setup mechanism open and described candidate approaches, including hop-by-hop establishment or a route server. Its decisive insight sat at the boundary between an application's desire and an operator's claim. “One hundred milliseconds” sounded like a contract only after someone specified the endpoints, traffic shape, receiver tolerance and every hop that had to honor it. RFC 1363 made the caller show its work and the network name the promise it could actually carry.

Sources: RFC 1363, A Proposed Flow Specification; RFC Editor record for RFC 1363.