[ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ]

[Alex McKenzie]

 Geoff,
Keep in mind that the original ARPA contract for the first 4 nodes did not call for any management or control.  I expect that Larry Roberts expected Len Kleinrock's Network Measurement Center contract to keep an eye on things.  The 4 node network was a "proof of concept" experiment, not a service.  If the proof of concept seemed to be successful there was an option in the BBN contract to expand the network to a total of as many 19 nodes.  The expansion in 1970 to BBN was an indication that Larry decided the experiment was successful and perhaps it was beginning to be time to think of "service".  When I got involved with the network in November 1970 Larry was beginning to put pressure on the Host organizations and the NWG to start using the network for resource sharing experiments, and it began to be clear that for the Hosts to do that BBN needed to shift its focus a bit away from network research and a bit more toward operations.
Keep that background in mind when thinking about the techniques of phone calls and mailed paper tapes used to "manage" the network in 1969-1970.
Cheers,Alex
    On Sunday, September 6, 2020, 8:58:51 PM EDT, the keyboard of geoff goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 Bernie, one thing yours truly has always been curious of is when the
ARPANET was initially being rolled out, viz.:
http://som.csudh.edu/fac/lpress/history/arpamaps/press.jpg :

How were the first four IMPs (UCLA, SRI, UCSB & UTAH) managed/controlled
until the cross country link to IMP #5 to y'all at BBN was installed?
and
What was the length of time the initial 4 ARPANET IMPs "ran" without the
cross country link to IMP #5 in Boston?

geoff

On Sun, Sep 6, 2020 at 1:30 PM Bernie Cosell via Internet-history <
internet-history at elists.isoc.org> wrote:

> Let me add a little bit to Jack's explorations.  There are two things of
> interest we
> put in the IMP code that relates to this.  The first was the DDT/TTY
> machinery
> and other was the "reload from your neighbor" machinery.
>
> I remember that first quite well, since I mostly designed it [we did
> EVERYTHING as a team so we coöperated and sorted stuff out together] and I
> implemented it [so I was really responsible for the complicated machinery
> that
> made this aspect of the IMP work]:
>
> Early on as we were coding the IMP stuff the question arose as to what to
> do
> about the TTY [and how the hell were we to debug the damn thing].  We did
> several things in this regard.  First I wrote a simple DDT [about as
> powerful as
> the test-word switches on our PDP-1 :o)] but it allowed us to poke around
> in the
> dead hulk of the code of a stopped system to see what went wrong and also
> put
> patches in.  I believe it was originally a stand alone - the imp would
> crash or hit a
> diagnostic trap and they we could run the DDT and look at buffers and
> counters
> and pointers and such and generally try to figure out what happened.  When
> the
> IMP was running solidly enough [which actually happened pretty early on in
> its
> development],  I can't remember the genesis of the underlying idea, but
> we
> thought we could route the DDT *over* the net to other IMPs and poke at
> *then*.
> I came up with a scheme that Will [I think] thought was way too
> complicated:
>
>    1) connect the DDT to the IMP as a "fake host",
> &2) connect the TTY to the IMP as another "fake host"
>
> With those now residing *in* the IMP, instead of apart from it we got a
> bunch of
> benefits:
>    1) we could run the DDT *while* the IMP was up doing its thing, and
>    2) we could interrogate a *different* IMPs DDT [simply by pointing the
> TTY to
> the appropriate fake host on the other IMP.
>    3) We could "IM" between machines [simply by pointing the TTY to the
> *TTY*
> on the other machine.
>
> [on (3) that ability was very handy as Ben and Marty were bringing up IMPs
> 1&2.
> They knew, for example, long before any of the host interface and
> machinery was
> working, that the IMP was doing just fine, since they could exchange
> messages
> and *knew* it used the same code that the hosts would be using.  It also
> replaced
> lots of long-distance calls to coördinate what was happening at SRI and
> UCLA]
>
> WE also had the IMPs send "health reports" [via a background process] and
> they
> were hard wired to send to the IMP 5 TTY and so virtually from the outset
> we
> could monitor [and with the DDT tweak] the whole network.  Until the
> PDP-1
> was online it chewed up a fair bit of paper :o)
>
> It was all using the basic IMP packet-handling machinery, so that two IMPs
> could be poking the DDT on a particular IMP and not interfere with one
> another.
> When the PDP-1 came online as the first proto-NCC, the DDT was as happy to
> talk to a real host as one of its fake brethrens and ditto for the "health
> reports"
> that just changed which host they were going to and it all worked.  So
> everything
> was fitting together very nicely and very usefully [despite the
> complicated code]
>
> A conceptually neat part about all this is that the *internals* of the IMP
> were
> host-agnostic.  They didn't care if they were fake or real, they just
> sent the
> packets where there were supposed to go.  and so we could implement
> "satellite"
> activities that used the underlying IMP code to do other useful things
> beyond
> just host-to-host.
>
> Expanding this principle a few years later, we had a H316 that had *two*
> 16k
> banks.  [and I think I've mentioned this before on this list].  We decided
> to
> implement the TIP as, what else?? :o), a host.  But in this case it was a
> pseudo-real-host [as I've mentioned before]  this was done so that the TIP
> code
> could live in the upper memory bank and its "host interface" transferred
> data and
> control across the boundary.  The IMP didn't need to know or care that the
> TIP
> was there.
>
> Phew.  now to the second mechanism: reloading from a neighbor.  Maybe
> dave
> remembers this better than I do but I think that one of the things we did
> as the
> IMP got more solid was removed its "loader" [which could boot the machine
> from paper tape] and replaced with with something that could live in 20
> words
> [which was where the paper tape loader lived: in shadow memory behind the
> registers]  I think that that code was *just* enough of a bootstrap to
> send
> message to a neighboring IMP and the first thing that IMP sent over a
> smarter
> loader that than received a whole memory-full of IMP code from the
> neighbor
> and then started the neighbor up.  I believe we could trigger this
> remotely via
> DDT and so if the IMP was up but just in need of an updated version it
> could
> suck it in from its neighbor.
>
> My opinion is that hacking in this kind of stuff [and piggybacking
> "services" on
> top of the IMP's 'day job' of handing real host data] helped a lot in the
> ARPAnet
> being virtually "operational" [and manageable] from the start.
>
>  /Bernie\
>            Bernie Cosell
>        bernie at fantasyfarm.com
> -- Too many people; too few sheep --
>
>
>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history