Index Journeys
RFC 209 UNKNOWN INFRASTRUCTURE · OPERATIONS

Host/IMP interface documentation

BBN explains why hosts should follow the documented IMP interface.

On rfc-editor.org ↗
PUBLISHED
August 1971
AUTHORS
B. Cosell
STREAM
Legacy
IMP VERSION
2500
STARTUP DELAY
About 30 seconds
DOI
10.17487/RFC0209

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
Network Working Group                                          B. Cosell
Request for Comments: 209                        Bolt Beranek and Newman
NIC: 7187                                                 13 August 1971


                     HOST/IMP Interface Documentation

   On 25 June 1971 we put a new version of the IMP system, Version 2500,
   up in the network.  Among other changes, the new system corrected the
   problem of Hosts receiving spurious "Destination Dead" [Type 7]
   messages.  The correction involved making the IMP refuse to accept
   any messages from its Host for about 30 seconds after the Host
   indicated its intention to come alive.  This delay has caused trouble
   to a number of NCPs because they had imposed an upper limit on the
   time an IMP may take to accept a message, and when that time was
   exceeded the IMP was declared inoperative and the NCP shut itself
   down, leaving the site personnel annoyed and perplexed.

   We're sorry to have caused so much trouble, but we thought that the
   new version modified no advertised property of the system.  To
   prevent misunderstandings of this type in the future, the IMP/Host
   interface should be well documented, well understood and invariant.
   The only way to set up and maintain such an interface is to presume
   that BBN Report No. 1822 is complete and correct.  We understand that
   it is neither, but operating on the basis of this assumption is the
   best way to force 1822 to improve.  In our view, the Hosts should
   proceed under the constraint that anything not specifically
   guaranteed by 1822 does not exist and should not be used.  If there
   are problems using this approach, please don't "code around" the
   problem or treat your IMP as a "black box" and extrapolate its
   characteristics from a series of experiments.  Instead, send your
   comments and problems to the NCC at BBN, and we will fix the IMP
   system, or 1822, whichever is necessary.

   We are, at the moment, working n an update to 1822.  It will reflect
   the deletion of the "cease" mechanism [as per RFC #107].

   We are also considering augmenting the IMP/Host protocol with a
   mechanism to allow a Host to detect a change in the "version" of the
   IMP system, and to provide the Hosts with status information as to
   who is alive in the net.


         [ This RFC was put into machine readable form for entry ]
             [ into the online RFC archives by Ryan Kato 6/01]

ISO Plain Language

On this page
PROBLEMA new IMP version introduced a startup delay that caused some NCPs to treat the IMP as failed and shut down.
MECHANISMBBN urges hosts to rely only on behavior guaranteed by BBN Report 1822 and report problems instead of relying on undocumented behavior.
INTERFACE GUIDANCEBBN was preparing an update to Report 1822 and considering interface features for version detection and host status.

§1The Startup Delay Problem

IMP system version 2500 corrected a problem that caused hosts to receive spurious Destination Dead messages. The correction made the IMP refuse host messages for about 30 seconds after the host indicated it was coming alive.

Some NCPs had shorter limits for how long an IMP could take to accept a message. When the delay exceeded those limits, the NCP declared the IMP inoperative and shut itself down.

A change intended to stop false failure messages caused some host programs to time out. They shut down before the IMP's new waiting period ended.

§2Use the Documented Interface

BBN said the change did not alter an advertised system property, but acknowledged the trouble it caused. To prevent similar misunderstandings, it argued that the IMP/Host interface should be documented, understood and stable.

BBN asked hosts to assume that features not specifically guaranteed by BBN Report 1822 do not exist. It advised sites to report problems to BBN rather than work around them or infer behavior from experiments.

Hosts should rely on behavior that the interface document promises. If a problem occurs, BBN asks sites to report it instead of depending on undocumented behavior.

§3Planned Documentation and Features

BBN was working on an update to Report 1822 to reflect removal of the cease mechanism described in RFC 107. It was also considering a way for hosts to detect an IMP system version and receive information about which hosts were alive.

BBN planned to update the interface report. It was also considering ways for hosts to learn the IMP version and network host status.