a) All messages held for the Host are discarded.

b) The source Host for each discarded messages is sent

a type 9, subtype 0 message (Incomplete Transmission - Destination Host Tardy).

c) The IMP ready line is dropped and raised again.

d) The Host is sent 3 type 4 messages (NOP).

e) The Host is sent a type 10 message (IMP-Host Interface

Reset).

     We propose that in addition the IMP declare the Host dead to the
network.  Upon receipt of the next bit from the Host, the IMP will
declare the Host alive and begin the 30-second delay while the
information that the Host is now alive is propagated throughout the
network.
     This change is an attempt to alleviate some problems that are
caused by Hosts whose ready lines are up when they are not able to
accept bits from the IMP. Several Hosts fall into this category.
There are some Hosts whose ready lines are wired to be on all the
time.  It is annoying, in terminal use and in running survey programs,
to have to wait for 30 seconds to find out that a Host is not
responding.  Other Hosts sometimes go into "break- point mode" for
system debugging for several minutes at a time.  The NCP software is
not running, and messages accumulate in the network and are thrown
away.  It seems preferable to declare such Hosts to be dead until they
send a message* to the IMP, and then any source Host attempting to
communicate can be notified at once that the destination Host is dead.

2) Timing out Host-to-IMP messages in 15 seconds

---------------------------------------------

     When the IMP receives a message from a Host, it must acquire
several internal resources in order to process the message.  It must
assign it a message number, make an entry in an internal table, and so
on.  If any of these IMP resources is not available, the IMP simply
waits until it does become available.  It cannot take any more
messages from the Host, and so the interface is stopped.  This
condition is usually momentary, but under unusual circumstances the
IMP may not be able to process a message it has begun to accept for
many seconds.  This situation creates an especially difficult problem
for Hosts with half-duplex interfaces.  If the IMP takes 30 seconds to
process a message, then the IMP-to- Host timeout outlined in 1) takes
effect, and the Host loses all messages sent to it in the last 30
seconds.  (It should be noted that the half-duplex interface may be
the cause of a deadly embrace, e.g. the reason that the IMP cannot
acquire the necessary resources to process a given message may be that
the Host in question has several messages on its queue and they are
tying up storage, message

__________________
*Thus a Host should send its IMP at least two NOPs (or other
 messages) whenever it receives a type 10 message from its IMP.

numbers, or table slots. The Host must accept these messages before any more messages can be introduced into the network.) Even for Hosts with full-duplex interfaces, occurrences of this situation might interfere with other useful communication.

     We propose to notify the Host when the IMP cannot continue to
process a message that it has begun to accept.  The IMP will try to
process the message for 15 seconds, and then will send the Host a type
9, subtype 4 message (bits 30,31,32 = 100) which will be defined as
Incomplete Transmission - Resources Unavailable.  In such a case, the
IMP has not been able to send any part of the message into the
network.  The IMP will take in the remainder of the message; at that
point a Host with a half-duplex interface should begin to accept
messages from the IMP, while a Host with a full-duplex interface might
attempt to transmit some other message.  The Host may attempt to
retransmit the incomplete message if that is desirable.

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                      1/97 ]