ARPANET short blocking feature
Letting ARPANET hosts escape long blocking timeouts.
Malis, A.G., "ARPANET short blocking feature", RFC 852, DOI 10.17487/RFC0852, April 1983, <https://www.rfc-editor.org/info/rfc852>.
@misc{rfc852,
series = {Request for Comments},
number = 852,
howpublished = {RFC 852},
publisher = {RFC Editor},
doi = {10.17487/RFC0852},
url = {https://www.rfc-editor.org/info/rfc852},
author = {A.G. Malis},
title = {{ARPANET short blocking feature}},
pagetotal = 13,
year = 1983,
month = apr,
} RFC text
Request for Comments: 852
The ARPANET Short Blocking Feature
RFC 852
Andrew G. Malis
ARPANET Mail: malis@bbn-unix
Bolt Beranek and Newman Inc.
50 Moulton St.
Cambridge, MA 02238
April 1983
This RFC specifies the ARPANET Short Blocking Feature, which will
allow ARPANET hosts to optionally shorten the IMP's host blocking
timer. This Feature is a replacement of the ARPANET non-blocking
host interface, which was never implemented, and will be
available to hosts using either the 1822 or 1822L Host Access
Protocol. The RFC is also being presented as a solicitation of
comments on the Short Blocking Feature, especially from host
network software implementers and maintainers.
RFC 852
1 INTRODUCTION
This RFC specifies the ARPANET Short Blocking Feature, which will
allow a host to shorten the amount of time that it may be blocked
by its IMP after it presents a message to the network (currently,
the IMP can block further input from a host for up to fifteen
seconds).
The Feature is an addition to the ARPANET 1822 and 1822L Host
Access Protocols, and replaces the non-blocking host interface
described in section 3.7 of BBN Report 1822 [1], which was never
implemented. This Feature will be available to hosts on C/30
IMPs only. This will not present a problem on the ARPANET, which
only has C/30 IMPs, but hosts on non-C/30 IMPs in networks that
mix C/30 and non-C/30 IMPs will not be able to use the Short
Blocking Feature.
The RFC's terminology is consistent with that used in Report
1822, and any new terms will be defined when they are first used.
Familiarity with Report 1822 (section 3 in particular) is
assumed.
This RFC was once part of RFC 802, which is now obsolete and has
been replaced by the combination of this RFC and RFC 851, The
ARPANET 1822L Host Access Protocol [2]. The Short Blocking
Feature will be available to all hosts on C/30 IMPs, no matter
RFC 852
which (1822 or 1822L) host access protocol they are using to
communicate with the IMP.
RFC 852
2 THE ARPANET SHORT BLOCKING FEATURE
The Short Blocking Feature of the 1822 and 1822L protocols allows
a host to present messages to the IMP without causing the IMP to
not accept further messages from the host for long amounts of
time (up to fifteen seconds). It is a replacement for the non-
blocking host interface described in section 3.7 of Report 1822,
and that description should be ignored.
2.1 Host Blocking
Usually, when a source host submits a message to an IMP, the IMP
immediately processes that message and sends it on its way to its
destination host. Sometimes, however, the IMP is not able to
process the message immediately. Processing a message requires a
significant number of resources, and when the network is heavily
loaded, there can sometimes be a long delay before the necessary
resources become available. In such cases, the IMP must make a
decision as to what to do while it is attempting to gather the
resources.
One possibility is for the IMP to stop accepting messages from
the source host until it has gathered the resources needed to
process the message just submitted. This strategy is known as
blocking the host, and is basically the strategy that has been
RFC 852
used in the ARPANET up to the present. When a host submits a
message to an IMP, all further transmissions from that host to
that IMP are blocked until the message can be processed.
It is important to note, however, that not all messages require
the same set of resources in order to be processed by the IMP.
The particular set of resources needed will depend on the message
type, the message length, and the destination host of the
message. Therefore, although it might take a long time to gather
the resources needed to process a particular message, it might
take only a short time to gather the resources needed to process
some other message. This fact exposes a significant disadvantage
in the strategy of blocking the host. A host which is blocked
may have many other messages to submit which, if only they could
be submitted, could be processed immediately. It is "unfair" for
the IMP to refuse to accept these messages until it has gathered
the resources for some other, unrelated message. Why should
messages for which the IMP has plenty of resources be delayed for
an arbitrarily long amount of time just because the IMP lacks the
resources needed for some other message?
A simple way to alleviate the problem would be to place a limit
on the amount of time during which a host can be blocked. This
amount of time should be long enough so that, in most
circumstances, the IMP will be able to gather the resources
RFC 852
needed to process the message within the given time period. If,
however, the resources cannot be gathered in this period of time,
the IMP will flush the message, sending a reply to the source
host indicating that the message was rejected and specifying the
reason that it could not be processed. However, the resource
gathering process would continue. The intention is that the host
resubmit the message in a short time, when, hopefully, the
resource gathering process has concluded successfully. In the
meantime, the host can submit other messages, which may be
processed sooner. This strategy does not eliminate the
phenomenon of host blocking, but only limits the time during
which a host is blocked. This shorter time limit will always be
less than or equal to two seconds.
Note, however, that there is a disadvantage to having short
blocking times. Let us assume that the IMP accepts a message if
it has all the resources needed to process it. The ARPANET
provides a sequential delivery service, whereby messages with the
same priority, source host, and destination host are delivered to
the destination host in the same order as they are accepted from
the source host. With short blocking times, however, the order
in which the IMP accepts messages from the source host need not
be the same as the order in which the source host originally
submitted the messages. Since the two data streams (one in each
RFC 852
direction) between the host and the IMP are not synchronized, the
host may not receive the reply to a rejected message before it
submits subsequent messages for the same destination host. If a
subsequent message is accepted, the order of acceptance differs
from the order of original submission, and the ARPANET will not
provide the same type of sequential delivery that it has in the
past. If sequential delivery by the subnet is a strict
requirement, the Short Blocking Feature should not be used. For
messages without this requirement, however, the Short Blocking
Feature can be used.
Up to now, type 0 (Regular) messages have only had sub-types
available to request the standard blocking timeout, fifteen
seconds. The Short Blocking Feature makes available new sub-
types that allow the host to request messages to be short
blocking, i.e. only cause the host to be blocked for two seconds
at most if the message cannot be immediately processed.
Type 0 messages now have the following subtypes:
0: Standard: This subtype instructs the IMP to use its full
message and error control facilities. The host may be
blocked up to fifteen seconds during the message submission.
1: Standard, Short Blocking: The IMP attempts to use the same
facilities as for subtype 0, but will block the host for a
RFC 852
maximum of two seconds.
3: Uncontrolled Packet: The IMP performs no message-control
functions, and the packet is not guaranteed to be delivered.
The host may be blocked up to fifteen seconds during the
packet submission, although any such blockage is unlikely.
4: Uncontrolled, Short Blocking: The IMP treats the packet
similarly to subtype 3, but will only block the host for a
maximum of two seconds. Again, actual blockage is unlikely.
2.2 Reasons for Host Blockage
There are a number of reasons why a message could cause a long
blockage in the IMP, which would result in the rejection of a
short (or even non-short) blocking message. The IMP signals this
rejection of a message by using the Incomplete Transmission (Type
9) message, using the sub-type field to indicate why the message
was rejected. The already-existing sub-types for the type 9
message are:
0: The destination host did not accept the message quickly
enough.
1: The message was too long.
RFC 852
2: The host took more than fifteen seconds to transmit the
message to the IMP. This time is measured from the last bit
of the leader through the last bit of the message.
3: The message was lost in the network due to IMP or circuit
failures.
4: The IMP could not accept the entire message within fifteen
seconds because of unavailable resources. This sub-type is
only used in response to non-short blocking messages. If a
short blocking message timed out, it will be responded to
with one of sub-types 6-10.
5: Source IMP I/O failure occurred during receipt of this
message.
The new sub-types that apply to the Short Blocking Feature are:
6: Connection set-up delay: Although the IMP presents a simple
message-at-a-time interface to the host, it provides an
internal connection-oriented (virtual circuit) service,
except in the case of uncontrolled packets. Two messages are
considered to be on the same connection if they have the same
source host (i.e., they are submitted to the same IMP over
the same host interface), the same priority, and the same
destination host name or address. The subnet maintains
RFC 852
internal connection set-up and tear-down procedures.
Connections are set up as needed, and are torn down only
after a period of inactivity. Occasionally, network
congestion or resource shortage will cause a lengthy delay in
connection set-up. During this period, no messages for that
connection can be accepted, but other messages can be
accepted.
7: End-to-end flow control: For every message that a host
submits to an IMP (except uncontrolled packets) the IMP
eventually returns a reply to the host indicating the
disposition of the message. Between the time that the
message is submitted and the time the host receives the
reply, the message is said to be outstanding. The ARPANET
allows only eight outstanding messages on any given
connection. If there are eight outstanding messages on a
given connection, and a ninth is submitted, it cannot the
accepted. If a message is refused because its connection is
blocked due to flow control, messages on other connections
can still be accepted.
End-to-end flow control is the most common cause of host
blocking in the ARPANET at present.
RFC 852
8: Destination IMP buffer space shortage: If the host submits a
message of more than 1008 bits (exclusive of the 96-bit
leader), buffer space at the destination IMP must be reserved
before the message can be accepted. Buffer space at the
destination IMP is always reserved on a per-connection basis.
If the destination IMP is heavily loaded, there may be a
lengthy wait for the buffer space; this is another common
cause of blocking in the present ARPANET. Messages are
rejected for this reason based on their length and
connection; messages of 1008 or fewer bits or messages for
other connections may still be acceptable.
9: Congestion control: A message may be refused for reasons of
congestion control if the path via the intermediate IMPs and
lines to the destination IMP is too heavily loaded to handle
additional traffic. Messages to other destinations may be
acceptable, however.
10: Local resource shortage: Occasionally, the source IMP itself
is short of buffer space, table entries, or some other
resource that it needs to accept a message. Unlike the other
reasons for message rejection, this resource shortage will
affect all messages equally, except for uncontrolled packets.
The message's size or connection is not relevant.
RFC 852
The Short Blocking Feature is available to all hosts on C/30
IMPs, whether they are using the 1822 or 1822L protocol, through
the use of Type 0, sub-type 1 and 4 messages. A host using these
sub-types should be prepared to correctly handle the Type 9
(Incomplete Transmission) messages from the IMP.
RFC 852
3 REFERENCES
[1] Specifications for the Interconnection of a Host and an IMP,
BBN Report 1822, December 1981 Revision.
[2] A. Malis, The ARPANET 1822L Host Access Protocol, Request
for Comments 851, April 1983.
AI ELI5
On this page
§1The Blocking Problem on ARPANET
The ARPANET uses Interface Message Processors (IMPs) to handle communication between hosts. When a host submits a message to its IMP, the IMP must allocate resources (buffers, routing tables, connection state) before transmitting it. If these resources are not available, the IMP blocks the host—stops accepting further messages from that host—until resources are freed.
In the original design, blocking could last up to 15 seconds. This creates a fairness problem: a host may have multiple messages queued, some of which require few resources and could be processed immediately, but all are delayed because the IMP is blocked waiting for resources for a single heavy message.
The Short Blocking Feature replaces the never-implemented non-blocking interface with a practical option for shorter timeouts, available on C/30 IMPs using either 1822 or 1822L host access protocols.
An IMP is like a post office sorting machine. When one package needs special handling, the whole machine stops until that's done. Short Blocking lets you say: 'If you can't sort this package in 2 seconds, put it aside and handle the next one.'
§2Message Subtypes for Blocking Control
Type 0 (Regular) messages now have four subtypes, differing in blocking behavior and error handling:
Subtype 0 (Standard) instructs the IMP to use its full message and error control facilities, with blocking lasting up to 15 seconds.
Subtype 1 (Standard, Short Blocking) requests the same facilities as subtype 0 but limits blocking to a maximum of 2 seconds. If the message cannot be processed within that time, the IMP sends a Type 9 (Incomplete Transmission) rejection.
Subtype 3 (Uncontrolled Packet) disables message control and delivery guarantees, blocking for up to 15 seconds though actual blockage is unlikely.
Subtype 4 (Uncontrolled, Short Blocking) combines uncontrolled transmission with a 2-second maximum blocking time.
Hosts using short blocking subtypes must be prepared to handle Type 9 rejection messages and resubmit messages that time out.
You can tell the post office machine: 'Quick mode, standard service, 2 seconds or reject it' or 'Quick mode, no guarantee, 2 seconds or skip it.' This gives hosts more control.
- 0Standard — Full control, 15-second block timeout.
- 1Standard, Short Blocking — Full control, 2-second block timeout.
- 3Uncontrolled Packet — No guarantees, 15-second timeout (unlikely to block).
- 4Uncontrolled, Short Blocking — No guarantees, 2-second timeout.
§3Why Messages Get Rejected
When a message is rejected, the IMP returns a Type 9 (Incomplete Transmission) message with a subtype code indicating the reason. Subtypes 0–5 apply to all messages. For short blocking messages specifically, subtypes 6–10 describe why the 2-second timeout was exceeded.
Connection set-up delay (subtype 6) occurs when the IMP needs to establish or reuse a virtual circuit connection to the destination, causing a delay. Other messages for different destinations can still be accepted.
End-to-end flow control (subtype 7) is the most common cause: the ARPANET limits each connection to eight outstanding messages. If all eight slots are full, a ninth message is rejected; however, messages to other destinations can proceed.
Destination IMP buffer shortage (subtype 8) happens when the destination IMP has insufficient buffer space for messages over 1008 bits. Smaller messages or messages to other connections may still be accepted.
Congestion control (subtype 9) rejects a message when the path to the destination is overloaded, but messages to other destinations may be acceptable.
Local resource shortage (subtype 10) indicates the source IMP itself lacks buffers or tables to accept any message.
The rejection codes tell the host why it failed: connection setup taking too long, the recipient is slow, the destination is full, the path is crowded, or the source is out of resources. Each suggests a different fix.
§4Sequential Delivery Tradeoff
Short blocking introduces a subtle but important limitation: the order in which messages are accepted by the IMP may not match the order in which the host submitted them. This occurs because messages that time out are rejected while other messages submitted later may be accepted immediately.
The ARPANET normally provides sequential delivery—messages with the same priority, source, and destination are delivered in submission order. When a host uses short blocking, this guarantee breaks down: if message A is rejected and message B (submitted after A) is accepted, the receiving host may see B before A.
This tradeoff is acceptable for applications that do not require ordered delivery but unacceptable for those that do. The RFC advises that applications requiring sequential delivery should not use short blocking.
Because rejected messages go back to the queue and submitted messages jump ahead, they can arrive out of order. It's like cutting in line and then going to the back—things get out of sequence.
- Submit Message A (short blocking)
- Submit Message B (short blocking)
- Reject A (timeout on connection setup)2 seconds elapsed, resources unavailable
- Forward BB had all needed resources