We are planning to install a new version of the IMP System,
- version 2514. The new version is scheduled for field installation
-
- Thursday, January 13, 1972 between noon and 1 PM EST, and will require
-
- the assistance of IMP-site personnel at each site.
-
There were two principal problems with version 2513, both related
- to the delay inserted between the time when a Host comes up and the
-
- time when its IMP will accept the second packet from the Host. The
-
- first was that the delay was lengthened to slightly over 40 seconds,
-
- which caused hardware difficulties for some Hosts. The second was
-
- that there was an ambiguity that could make the delay run as long as a
-
- minute and a quarter. On the first point, the delay has been backed
-
- off from 40 seconds to 30 seconds, as it was for IMP systems prior to
-
- 2513. On the second point, the ambiguity has been entirely removed.
-
- (Note, however, that BBN Report No. 1822, on page 23, specifies that
-
- the delay may range from 30 to 90 seconds, and that future versions
-
- may require a longer delay.)
-
In summary, a Host may come alive in one of two ways, corres-
- ponding to the two ways in which the Host can go down. If the Host
-
- went down voluntarily (by sending a "Host going down" to the IMP), the
-
- Host indicates his intention to come alive by sending the IMP
-
- something. If the Host went down involuntarily (by dropping his ready
-
- line), the Host indicates his intention to come alive by bringing his
-
- ready line back up. In either case
-
[Page 1]
-
- 30 seconds after the Host has indicated his intention to come alive.
-
- Notice, however, that the Host must be prepared to accept all messages
-
- from the Network from the instant that he indicates his intention to
-
- come alive.* This particular point seems to have given many Hosts
-
- difficulty in running through their standard initialization
-
- procedures. Don't forget this simple and universal rule, that when
-
- you are telling your IMP that you are alive, you must be prepared to
-
- always take every- thing from the Network whether or not the Network
-
- is taking any- thing from you.
-
Version 2514 will also incorporate a few other changes, mainly
- related to the operation of the NCC. Since the Timeout is, for a
-
- change, being made shorter, and the other modifications are minor,
-
- there should be no appreciable transient with the coming of the new
-
- version.
-
- _______________
-
- *In fact, if the Host does not accept messages from his IMP
-
- pimmediately then the Host may see the IMP's Ready line go down
-
- for 1/4 second sometime during the 30 second waiting period.
-
- This is due to the following set of circumstances:
-
* The IMP periodically places NOPs on the queue for a
dead Host as part of the process of checking the IMP/Host
interface.
* If a message remains on a Host's queue for 30 seconds
without being taken, the IMP drops its Ready line for
1/4 second in order to clear the interface (see RFC #270).
* The timeout periods for the Host queue and the delay
when the Host comes alive are _not_ synchronized.
- If the Host is prepared to see the IMP's Ready line dropped
-
- during the 30-second delay while coming alive, then no harm
-
- will be done if messages from the IMP are not accepted immediately.
-
- BC/jm
-
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 12/96 ]
[Page 2]
-