RFC 209 UNKNOWN INFRASTRUCTURE · ARPANET

Host/IMP interface documentation

A memo clarifying the host-IMP interface after a software update caused confusion

On rfc-editor.org ↗
PUBLISHED
August 1971
AUTHORS
B. Cosell
STREAM
Legacy
IMP VERSION
2500
DELAY ADDED
About 30 seconds
PROBLEM
Host timeouts exceeded
REFERENCE DOCUMENT
BBN Report No. 1822
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]

AI ELI5

On this page
PROBLEMBBN updated the IMP software to fix a bug, adding a 30-second delay before accepting messages from hosts that just came up. Some host programs had shorter timeout limits and treated this delay as a failure, causing them to shut down.
MECHANISMBBN requested that all hosts treat BBN Report 1822 as the definitive and invariant specification of the host-IMP interface, and not rely on undocumented behavior or experimental extrapolation.
WHY IT MATTERSThis established the principle that the host-IMP interface should be strictly documented and understood by all participants, with BBN working on an updated 1822 report.

§1The Problem

On 25 June 1971, BBN deployed IMP system version 2500 with a correction to prevent hosts from receiving spurious "Destination Dead" messages. The fix added a constraint: the IMP would refuse to accept any messages from a host for about 30 seconds after the host indicated it was coming alive.

This delay caused trouble for host programs using the Network Control Protocol (NCP). Some had imposed upper limits on the acceptable time for an IMP to accept a message. When the new delay exceeded those limits, the programs declared the IMP inoperative and shut themselves down.

A software fix added a waiting period, and some host programs had stricter rules and thought the system was broken.

§2Why This Matters

BBN acknowledged causing confusion but argued the change did not modify any advertised property of the system. To prevent such misunderstandings in the future, the IMP/Host interface needed to be well documented, well understood, and invariant.

BBN proposed that the host-IMP interface should be defined and maintained based on BBN Report No. 1822, treated as complete and correct. Hosts should operate under the assumption that anything not specifically guaranteed by 1822 does not exist and should not be used.

Misunderstandings come from unclear rules. The solution is to follow the written specification exactly.

§3Next Steps

BBN committed to working on an update to 1822 to reflect recent changes, such as the deletion of the "cease" mechanism described in RFC 107. The team also planned to augment the IMP/Host protocol with a mechanism allowing hosts to detect changes in the IMP system version and to provide hosts with status information about which systems in the network were alive.

The rule book would be updated to match the actual system, and new ways would be added for computers to check on each other's status.

§4References