Summary

  • RFC 852, written by Andrew G. Malis in April 1983, specified an optional Short Blocking Feature for ARPANET hosts attached to C/30 IMPs. A message that could hold the entire host's input for up to fifteen seconds could instead be refused within at most two seconds, with a Type 9 Incomplete Transmission reason. The host could then try again and offer other work.
  • The shorter wait changed the queue's contract. A later message might be accepted before the host learned that an earlier one was rejected. The ARPANET's same-priority, same-source, same-destination ordering followed acceptance order, so software that required submission order had to avoid this mode or manage the consequence.

Imagine a clerk with one window and a difficult form. The clerk needs a document from a distant office, so he closes the entire counter. A second visitor arrives with a form that could be handled immediately. She waits anyway. That was the host-level grievance in RFC 852. An ARPANET Interface Message Processor, or IMP, could be gathering resources for one message while the source computer had other messages ready. Under the existing blocking practice, the IMP stopped accepting every further message from that host until it could process the first. The pause could last fifteen seconds. Different messages needed different resources according to type, length and destination; the counter treated them as one problem.

The paper's proposed answer was modest and sharp: give the computer an optional shorter wait. If the IMP could not process a short-blocking message promptly, it could reject that message within two seconds, send the host a Type 9 Incomplete Transmission reply explaining why, and continue its resource-gathering work. Meanwhile the host could offer other messages. The rejected one could be resubmitted later. That is a different kind of success from making the first message magically disappear into the network. The clerk opens the counter again; the visitor holding the hard form must come back.

Malis gave the choice visible protocol handles. A regular Type 0 message with subtype 0 retained the full facilities and could block up to fifteen seconds. Subtype 1 asked for the same facilities with the two-second cap. There were also uncontrolled-packet subtypes: subtype 3 with the older blocking limit and subtype 4 with the shorter one. Those packets had no delivery guarantee. A host choosing the new subtype had to be ready to handle a Type 9 reply rather than mistake its own submission for the IMP's acceptance. The specification covered C/30 IMPs with either the 1822 or 1822L host-access protocol.

Its earlier, supposedly non-blocking predecessor in Report 1822 had never been implemented; RFC 852 asked implementers for comments on a different design.

The error reply was a small map of where the line had jammed. New Type 9 subtypes separated connection setup delay, end-to-end flow control, lack of destination IMP buffer space, congestion along the path, and shortage of a local IMP resource. Those causes did not have the same blast radius. A delayed connection to one destination could leave other connections free. A source IMP short of its own buffers or table entries could hold up nearly everything except uncontrolled packets. “The network is busy” was too blunt a diagnosis for an operator deciding what to retry next.

One case gives the office-counter image a literal queue length. The ARPANET allowed eight outstanding messages on a connection: messages submitted for which the IMP had yet to return a disposition. Offer a ninth on that same connection and flow control could refuse it. Another case concerned size. A message longer than 1,008 bits, excluding its 96-bit leader, needed buffer space reserved at the destination IMP. A shortage there could delay that large message while a shorter one or a message for another connection was acceptable.

The feature let the host discover a narrower refusal and keep useful work moving, as long as its software listened to the reason returned.

The bill arrived in ordering. ARPANET sequential delivery referred to messages with the same priority, source and destination in the order the IMP accepted them. The host's outgoing stream and the IMP's replies were asynchronous. The host might submit a later message before it received the first one's rejection, and the IMP might accept the later one. If the host then retried the first, its original submission order would no longer match the acceptance order on which the network's delivery promise rested. Malis stated the choice directly: when subnet sequential delivery was a strict requirement, the short-blocking option was the wrong one. Saving waiting time could move sequence control from the network queue into host software.

That tradeoff is the heart of this 1983 proposal. An IMP should not shut every door because one destination or buffer is awkward. Yet a faster “no” creates work: recognize the reason, decide when to retry, and decide whether another message may pass first. RFC 852 drew a two-second limit around the clerk's patience and handed the host a numbered receipt. The counter reopened. The paperwork moved to the computer that had chosen the quicker line.