RFC 271

IMP System Change Notification 🎀

Okay bestie, here's the whole RFC tea ☕ It's RFC 271, written by Bernard Cosell from BBN, dated 3 January 1972, under NIC 7819. It's in category B.1, and it doesn't update or obsolete anything 💅

• Network Working Group: Bernard Cosell, BBN
• RFC #: 271
• NIC: 7819
• Date: 3 January 1972
• Categories: B.1
• Updates: None
• Obsoletes: None

So, we're planning to install a new version of the IMP System, version 2514 🦋 It's getting installed in the field on Thursday, January 13, 1972, between noon and 1 PM EST, and it's gonna need IMP-site personnel at each site to help out 🫶

Version 2513 had two main problems, and they were both about the delay between when a Host comes up and when its IMP will accept the second packet from that Host 😭 First, the delay got stretched to slightly over 40 seconds, and that caused hardware problems for some Hosts. Second, there was an ambiguity that could make the delay run as long as a minute and a quarter 💀 For the first one, the delay is backed off from 40 seconds to 30 seconds, which is what IMP systems did before 2513. For the second one, the ambiguity is totally gone ✨

(Note though, BBN Report No. 1822, on page 23, says the delay may range from 30 to 90 seconds, and future versions may require a longer delay 👀)

Here's the main idea, and it's giving very clear vibes 🌈 A Host can come alive in one of two ways, which match the two ways it can go down.

If the Host went down voluntarily, by sending a "Host going down" to the IMP, then it tells the IMP it's ready to come alive by sending the IMP something. If the Host went down involuntarily, by dropping its ready line, then it says it's coming alive by bringing its ready line back up 🧚

Either way, the IMP refuses to accept more than one packet from the Host for 30 seconds after the Host says it's coming alive. BUT here's the lowkey important part: the Host has to be ready to accept all messages from the Network from the exact instant it says it's coming alive 🚨 This one trips up loads of Hosts during their standard initialization, so it's literally the rule to remember. When you're telling your IMP you're alive, you must be prepared to always take everything from the Network, whether or not the Network is taking anything from you 🫶💖

Version 2514 also has a few other changes, mostly about how the NCC operates 🍓 Since the Timeout is getting shorter for once, and the other changes are minor, there shouldn't be any noticeable transient when the new version rolls out 🌸

*In fact, if the Host doesn't accept messages from its IMP pimmediately, the Host might see the IMP's Ready line go down for 1/4 second at some point during the 30 second waiting period. Here's why 👇

• The IMP periodically places NOPs on the queue for a dead Host as part of checking the IMP/Host interface.
• If a message sits on a Host's queue for 30 seconds without being taken, the IMP drops its Ready line for 1/4 second 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 ready to see the IMP's Ready line dropped during the 30-second delay while coming alive, then no harm is done if messages from the IMP aren't 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 ]