RFC 410

Removal of the 30-Second Delay When Hosts Come Up ✨

okay bestie, let's start with the title block 💖 This is RFC #410 (NIC #12402) from the Network Working Group, written by John M. McQuillan at Bolt Beranek and Newman and dated 10 November 1972. It's filed under category B-1, and it doesn't list anything it obsoletes or updates 🎀

So right now the IMP waits 30 seconds after a Host comes up before it accepts any input from that Host 🕰️ That wait exists so the news that the Host is up has time to spread through the network 🌐 The real problem is that a Host can't talk to a second Host until that second Host (well, its IMP) knows the first one is up. Otherwise, a Host can boot up, send a "hello" to another Host, and get its reply tossed by the IMP because it's for a dead destination 💀

All of this reasoning depends on dead destination detection happening at the source IMP. The 30-second wait is based on the worst-case propagation delay for routing information in the network, so every potential source IMP can update its host up/down table. It's giving a lot of drawbacks, though 🙈

1. Hosts shouldn't have to wait the worst-case time of 30 seconds to send to Hosts at their IMP or nearby in the network.
2. The operation of half-duplex interfaces is made even more complicated because of the startup delay.
3. The 30-second timeout is really a function of network topology, and we'd like to be able to change it when necessary as the network expands.

Here's the plan 👑 We get rid of the 30-second delay altogether. The IMP subnetwork will detect messages for a dead Host at the destination IMP instead of the source IMP. There's no delay for an IMP to sense when its own Hosts come up, so it can always make the correct call: hand the message to one of its Hosts, or send a destination dead message back to the source Host. Under this new scheme, whenever the IMP's ready line is up, it's ready to accept input from its Hosts without any delay ✨ A few comments on this change are worth noting:

1. No change to Host software should be necessitated by this change. The Host may attempt to send a message to the IMP as soon as it brings its ready line up, or it may delay for a long time. In either case, the IMP will take the message. As before, as soon as the Host has brought up its ready line, it must accept messages from the IMP.
2. The Hosts may wish to remove any delays they have programmed into their startup routines, since such delays are no longer necessary 🧚
3. Destination dead messages will be returned as before, with two differences. There will be more delay between the receipt of the message at the IMP and the return of the dead destination message, because it must travel through the network. For the same reason, if many messages are sent to dead Hosts, the dead destination messages may come back out of order 🌈

The Host personnel responsible for the IMP software at each site should check that this proposed change won't adversely affect them 🫶 If no adverse comments are received, this change will go into effect on Tuesday morning, December 12 at the regular IMP software release time. Periodt 💅

[ 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 ]