- protocol described in BBN Report 1822 and revised in RFC 381. The
-
- first deals with the IMP-to-Host interface and the 30-second timeout
-
- mechanism on each IMP transmission to the Host. The second deals with
-
- the Host-to-IMP interface and proposes a new timeout mechanism. These
-
- changes are independent; in statement and in implementation. We
-
- invite comments on each proposal. If no adverse comments are
-
- received, they will be installed in the network on Tuesday, October 10
-
- (if serious adverse comments are received, action will be delayed
-
- until early November).
-
- 1) Declaring an unresponsive Host as dead to the network
-
-----------------------------------------------------
Currently, a Host is given 30 seconds to accept each packet of a
- regular message and is also given 30 seconds to accept non- regular
-
- messages. If the Host is unresponsive for this period of time, the
-
- IMP takes the following actions:
-
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.
-
[Page 1]
-
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.
[Page 2]
-
- 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 ]
[Page 3]
-