From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc410.txt | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 doc/rfc/rfc410.txt (limited to 'doc/rfc/rfc410.txt') diff --git a/doc/rfc/rfc410.txt b/doc/rfc/rfc410.txt new file mode 100644 index 0000000..0a993f8 --- /dev/null +++ b/doc/rfc/rfc410.txt @@ -0,0 +1,112 @@ + + + + + + +Network Working Group John M. McQuillan +Request for Comments #410 Bolt Beranek and Newman +NIC #12402 10 November 1972 +Categories: B-1 + + + Removal of the 30-Second Delay When Hosts Come Up + ------------------------------------------------- + + + The IMP currently delays accepting input from a Host for 30 +seconds after the Host has come up. This delay serves to allow +the fact that the Host is up to propagate through the network. +The fundamental problem is that a Host must not be permitted +to communicate with a second Host until the second Host +(actually its IMP) has been made aware that the first Host is +up. Otherwise, one Host may come up and send a "hello" +message to another Host, whose reply is discarded by the IMP +because it is for a dead destination. + + All this reasoning is based on a dead destination de- +tection mechanism at the source IMP. The 30-second delay is +based on the worst-case propagation delay for routing information +in the network, so that every potential source IMP can update +its host up/down table. There are several drawbacks to this +scheme: + + 1. Hosts should not 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 timeout period of 30 seconds is really a + function of network topology and we would like to + be able to change it when necessary as the network + expands. + + We propose to eliminate the 30-second delay altogether. +The IMP subnetwork will detect messages for a dead Host at the +destination IMP instead of at the source IMP. There is no delay + + + + + + + + + + [Page 1] + +involved for an IMP to sense when its own Hosts come up, so +that it can always make the correct decision about whether to +give a message to one of its Hosts or to return a destination +dead message to the source Host. Under this new scheme, when- +ever the IMP's ready line is up it is ready to accept input +from its Hosts without delay. Several comments on this change +should be noted: + + 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 will not ad- +versely 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. + + + [ 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 ] + + + + + + + + + + + + + [Page 2] + -- cgit v1.2.3