The RFC Archive
 The RFC Archive   RFC 394   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 394

Two Proposed Changes to the IMP-Host Protocol

Last modified on Wednesday, March 5th, 1997

Permanent link to RFC 394
Search GitHub Wiki for RFC 394
Show other RFCs mentioning RFC 394







Network Working Group                    John M. McQuillan
Request for Comments #394                Bolt Beranek and Newman Inc.
NIC 11856                                27 September 1972
Categories:  B.1
Updates:  RFC #381
Obsoletes:

             TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL
---------------------------------------------
     This note describes two changes to the IMP-Host communication
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 top


RFC #394 John M. McQuillan 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 top

RFC #394 John M. Mcquillan 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 top

Two Proposed Changes to the IMP-Host Protocol RFC TOTAL SIZE: 5780 bytes PUBLICATION DATE: Wednesday, March 5th, 1997 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 394: The IETF Trust, Wednesday, March 5th, 1997
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement