Browse Prior Art Database

Two Proposed Changes to the IMP-Host Protocol (RFC0394)

IP.com Disclosure Number: IPCOM000003570D
Original Publication Date: 1972-Sep-27
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J.M. McQuillan: AUTHOR

Abstract

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).

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 51% of the total text.

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.

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