As per Relevance of the word resource, we have this rfc below:
Request for Comments: 852
The ARPANET Short Blocking
RFC 852
Andrew G.
ARPANET Mail: malis@bbn-
Bolt Beranek and Newman Inc
50 Moulton St
Cambridge, MA 02238
April 1983
This RFC specifies the ARPANET Short Blocking Feature, which
allow ARPANET hosts to optionally shorten the IMP's host
timer. This Feature is a replacement of the ARPANET non-
host interface, which was never implemented, and will
available to hosts using either the 1822 or 1822L Host
Protocol. The RFC is also being presented as a solicitation
comments on the Short Blocking Feature, especially from
network software implementers and maintainers
ARPANET Short Blocking Feature April 1983
RFC 852
1
This RFC specifies the ARPANET Short Blocking Feature, which
allow a host to shorten the amount of time that it may be
by its IMP after it presents a message to the network (currently
the IMP can block further input from a host for up to
seconds).
The Feature is an addition to the ARPANET 1822 and 1822L
Access Protocols, and replaces the non-blocking host
described in section 3.7 of BBN Report 1822 [1], which was
implemented. This Feature will be available to hosts on C/30
IMPs only. This will not present a problem on the ARPANET,
only has C/30 IMPs, but hosts on non-C/30 IMPs in networks
mix C/30 and non-C/30 IMPs will not be able to use the
Blocking Feature
The RFC's terminology is consistent with that used in
1822, and any new terms will be defined when they are first used
Familiarity with Report 1822 (section 3 in particular)
assumed
This RFC was once part of RFC 802, which is now obsolete and
been replaced by the combination of this RFC and RFC 851,
ARPANET 1822L Host Access Protocol [2]. The Short
Feature will be available to all hosts on C/30 IMPs, no
- 1 -
ARPANET Short Blocking Feature April 1983
RFC 852
which (1822 or 1822L) host access protocol they are using
communicate with the IMP
- 2 -
ARPANET Short Blocking Feature April 1983
RFC 852
2 THE ARPANET SHORT BLOCKING
The Short Blocking Feature of the 1822 and 1822L protocols
a host to present messages to the IMP without causing the IMP
not accept further messages from the host for long amounts
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
Usually, when a source host submits a message to an IMP, the
immediately processes that message and sends it on its way to
destination host. Sometimes, however, the IMP is not able
process the message immediately. Processing a message requires
significant number of resources, and when the network is
loaded, there can sometimes be a long delay before the
resources become available. In such cases, the IMP must make
decision as to what to do while it is attempting to gather
resources
One possibility is for the IMP to stop accepting messages
the source host until it has gathered the resources needed
process the message just submitted. This strategy is known
blocking the host, and is basically the strategy that has
- 3 -
ARPANET Short Blocking Feature April 1983
RFC 852
used in the ARPANET up to the present. When a host submits
message to an IMP, all further transmissions from that host
that IMP are blocked until the message can be processed
It is important to note, however, that not all messages
the same set of resources in order to be processed by the IMP
The particular set of resources needed will depend on the
type, the message length, and the destination host of
message. Therefore, although it might take a long time to
the resources needed to process a particular message, it
take only a short time to gather the resources needed to
some other message. This fact exposes a significant
in the strategy of blocking the host. A host which is
may have many other messages to submit which, if only they
be submitted, could be processed immediately. It is "unfair"
the IMP to refuse to accept these messages until it has
the resources for some other, unrelated message. Why
messages for which the IMP has plenty of resources be delayed
an arbitrarily long amount of time just because the IMP lacks
resources needed for some other message
A simple way to alleviate the problem would be to place a
on the amount of time during which a host can be blocked.
amount of time should be long enough so that, in
circumstances, the IMP will be able to gather the
- 4 -
ARPANET Short Blocking Feature April 1983
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
host indicating that the message was rejected and specifying
reason that it could not be processed. However, the
gathering process would continue. The intention is that the
resubmit the message in a short time, when, hopefully,
resource gathering process has concluded successfully. In
meantime, the host can submit other messages, which may
processed sooner. This strategy does not eliminate
phenomenon of host blocking, but only limits the time
which a host is blocked. This shorter time limit will always
less than or equal to two seconds
Note, however, that there is a disadvantage to having
blocking times. Let us assume that the IMP accepts a message
it has all the resources needed to process it. The
provides a sequential delivery service, whereby messages with
same priority, source host, and destination host are delivered
the destination host in the same order as they are accepted
the source host. With short blocking times, however, the
in which the IMP accepts messages from the source host need
be the same as the order in which the source host
submitted the messages. Since the two data streams (one in
- 5 -
ARPANET Short Blocking Feature April 1983
RFC 852
direction) between the host and the IMP are not synchronized,
host may not receive the reply to a rejected message before
submits subsequent messages for the same destination host. If
subsequent message is accepted, the order of acceptance
from the order of original submission, and the ARPANET will
provide the same type of sequential delivery that it has in
past. If sequential delivery by the subnet is a
requirement, the Short Blocking Feature should not be used.
messages without this requirement, however, the Short
Feature can be used
Up to now, type 0 (Regular) messages have only had sub-
available to request the standard blocking timeout,
seconds. The Short Blocking Feature makes available new sub
types that allow the host to request messages to be
blocking, i.e. only cause the host to be blocked for two
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
message and error control facilities. The host may
blocked up to fifteen seconds during the message submission
1: Standard, Short Blocking: The IMP attempts to use the
facilities as for subtype 0, but will block the host for
- 6 -
ARPANET Short Blocking Feature April 1983
RFC 852
maximum of two seconds
3: Uncontrolled Packet: The IMP performs no message-
functions, and the packet is not guaranteed to be delivered
The host may be blocked up to fifteen seconds during
packet submission, although any such blockage is unlikely
4: Uncontrolled, Short Blocking: The IMP treats the
similarly to subtype 3, but will only block the host for
maximum of two seconds. Again, actual blockage is unlikely
2.2 Reasons for Host
There are a number of reasons why a message could cause a
blockage in the IMP, which would result in the rejection of
short (or even non-short) blocking message. The IMP signals
rejection of a message by using the Incomplete Transmission (
9) message, using the sub-type field to indicate why the
was rejected. The already-existing sub-types for the type 9
message are
0: The destination host did not accept the message
enough
1: The message was too long
- 7 -
ARPANET Short Blocking Feature April 1983
RFC 852
2: The host took more than fifteen seconds to transmit
message to the IMP. This time is measured from the last
of the leader through the last bit of the message
3: The message was lost in the network due to IMP or
failures
4: The IMP could not accept the entire message within
seconds because of unavailable resources. This sub-type
only used in response to non-short blocking messages. If
short blocking message timed out, it will be responded
with one of sub-types 6-10.
5: Source IMP I/O failure occurred during receipt of
message
The new sub-types that apply to the Short Blocking Feature are
6: Connection set-up delay: Although the IMP presents a
message-at-a-time interface to the host, it provides
internal connection-oriented (virtual circuit) service
except in the case of uncontrolled packets. Two messages
considered to be on the same connection if they have the
source host (i.e., they are submitted to the same IMP
the same host interface), the same priority, and the
destination host name or address. The subnet
- 8 -
ARPANET Short Blocking Feature April 1983
RFC 852
internal connection set-up and tear-down procedures
Connections are set up as needed, and are torn down
after a period of inactivity. Occasionally,
congestion or resource shortage will cause a lengthy delay
connection set-up. During this period, no messages for
connection can be accepted, but other messages can
accepted
7: End-to-end flow control: For every message that a
submits to an IMP (except uncontrolled packets) the
eventually returns a reply to the host indicating
disposition of the message. Between the time that
message is submitted and the time the host receives
reply, the message is said to be outstanding. The
allows only eight outstanding messages on any
connection. If there are eight outstanding messages on
given connection, and a ninth is submitted, it cannot
accepted. If a message is refused because its connection
blocked due to flow control, messages on other
can still be accepted
End-to-end flow control is the most common cause of
blocking in the ARPANET at present
- 9 -
ARPANET Short Blocking Feature April 1983
RFC 852
8: Destination IMP buffer space shortage: If the host submits
message of more than 1008 bits (exclusive of the 96-
leader), buffer space at the destination IMP must be
before the message can be accepted. Buffer space at
destination IMP is always reserved on a per-connection basis
If the destination IMP is heavily loaded, there may be
lengthy wait for the buffer space; this is another
cause of blocking in the present ARPANET. Messages
rejected for this reason based on their length
connection; messages of 1008 or fewer bits or messages
other connections may still be acceptable
9: Congestion control: A message may be refused for reasons
congestion control if the path via the intermediate IMPs
lines to the destination IMP is too heavily loaded to
additional traffic. Messages to other destinations may
acceptable, however
10: Local resource shortage: Occasionally, the source IMP
is short of buffer space, table entries, or some
resource that it needs to accept a message. Unlike the
reasons for message rejection, this resource shortage
affect all messages equally, except for uncontrolled packets
The message's size or connection is not relevant
- 10 -
ARPANET Short Blocking Feature April 1983
RFC 852
The Short Blocking Feature is available to all hosts on C/30
IMPs, whether they are using the 1822 or 1822L protocol,
the use of Type 0, sub-type 1 and 4 messages. A host using
sub-types should be prepared to correctly handle the Type 9
(Incomplete Transmission) messages from the IMP
- 11 -
ARPANET Short Blocking Feature April 1983
RFC 852
3
[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,
for Comments 851, April 1983.
- 12 -
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
