[ih] Recently restored and a small ARPANET was run using simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol])
Jack Haverty
jack at 3kitty.org
Mon Sep 7 11:00:19 PDT 2020
Hi Barbara,
Packet Radio artifacts of any kind were elusive (at least in 2013 when
we searched), except for a few conference papers. Specifically, we were
looking for things like QTRs or other project reports that SRI
presumably submitted to ARPA, analogous to the BBN QTRs. We found a
lot of the BBN reports online at DTIC, but little from SRI. I'm not
sure, but the BBN QTRs may have been found by the search engine because
I had the BBN/ARPA contract numbers involved, but I didn't know the
appropriate contract numbers for the SRI (or any other) contracts.
Not much detail about Fuzzballs, or Port Expanders, or other such boxes
that were prolific in the early days of the Internet. Google wasn't
much help, but that may be from lack of knowledge in how to best use the
search mechanisms.
IMHO, there wasn't as much collaboration between the ARPANET and Packet
Radio as there was with the Internet/Gateway work at BBN.
BBN had internal structure that to some extent influenced the
"technology transfer" between projects. In particular there were two
"divisions", Div4 and Div6, that both did similar computer and network
research. Div6 was where the ARPANET project began and evolved to an
operational service over the ten years preceding the Internet, so there
was a lot of operational experience and war wounds there. Div4 was
where the Packet Radio work was done, along with lots of other things,
such as TENEX. Both were very competent, but had different experiences.
Although the technical staffs of the two divisions got along pretty
well, pragmatic details limited collaboration. We were physically
located in separate buildings, so hallway encounters and casual
interactions were less likely. Interesting "teaching events" that
occurred in the ARPANET propagated quickly through Div6 where the NOC
was literally just down the hallway, less so to Div4. Cross-charging
(charging your time to the other Division's project) was possible but
discouraged.
The "Gateway Project" began in Div4, where Ginny Strazisar implemented
the first gateway; I don't know if that was a separate
project/contract, or just a part of the Packet Radio contract at the
time. Some few years later, as it became desirable for the Internet to
stabilize and become an operational service, ARPA moved the gateway work
from Div4 to Div6, folding it into the "Internet Project" contract that
was my responsibility at the time (it included various TCP
implementations, SATNET, WBNET, Remote Site Maintenance, etc.).
That was the point where we started injecting "ARPANET DNA" into the
Internet/gateways, blatantly adopting ARPANET techniques as the most
obvious (to us in Div6) way to get the Internet to be as managed as the
ARPANET.
I know little about the internal mechanisms of the Packet Radio
environment. But it did not move to Div6 (which became BBN
Communications Corp at some point) at least during my involvement
(roughly 1978-1990).
So I suspect that the Packet Radio system did not reuse much of the IMP
ideas/techniques, especially the ones that were rather mundane and not
well documented or publicized (such as the "reload from neighbor"
idea). The Packet Radio QTRs, if they survive, would probably answer
that question.
I've often wondered, from a historical perspective now, to what extent
things like internal corporate structure and organizational decisions
influenced the design and implementation of the Internet.
/Jack
On 9/6/20 11:44 PM, Barbara Denny via Internet-history wrote:
> Because of BBN's involvement, I am thinking Packet Radio might have reused many of the same ideas as the IMPs for loading new software from another node. Do you know this was not the case? I never needed to look at that part of the code.
> I remember using XNET for examination of the Packet Radio station. Given your recent email it sounds like you looked for old Packet Radio station software and couldn't find it. Is this correct?
> I don't think Rockwell released their Packet Radio software in the late 70s/early 80s. I would have to contact Rockwell if I thought bugs required a change to a packet radio, versus the Packet Radio station, when I worked at BBN. I know several years later SRI did get some of their code because I implemented one of the new routing algorithms ( I am pretty sure it was called threshold distance vector routing if anyone is interested). BTW, I think the software may have only been tested in a simulator due to delays in the delivery of the LPR (Low Cost Packet Radio). This was during the SURAN program.
> The first demo of Packet Radio and ARPANET in 1976 involved submitting the status report. Don Nielson would probably remember if that was done through anything like email. Below is a link to an article that discusses this event. The text from the article mentions email but more importantly it has a link to a podcast with Don. I didn't know this podcast existed so I still need to listen to it. I can see why you might think the report submission may have been done by using a telnet connection to a SRI host that had email.
> https://hightechforum.org/happy-birthday-internet-richard-bennett-talks-with-don-nielson/
> barbara
> On Sunday, September 6, 2020, 12:39:38 PM PDT, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
>
> Hi Geoff - thanks for that bit of history and kudos!
>
> I think there's an Internet connection in your experience. I'm not sure
> what, legally, "wireless email" means. But I suspect that email was
> being sent and received, wirelessly, well before even 1982, if only to
> and from the SRI Packet Radio van that could occasionally be seen then
> roaming around the Bay Area.
>
> Of course, technically, that probably involved a Telnet connection,
> wirelessly, to some PDP-10 running an email program. But, legally, it
> might meet the court accepted definition of "wireless email". I
> learned from the lawyers that much of litigation involves arguing about
> the meaning of words and phrases.
>
> So, perhaps someone could have looked for mouldering Packet Radio (aka
> PR) hardware and software, and demonstrated wireless email circa 1978
> over one or more PRNETs.
>
> Sadly, although I was pretty sure that interesting "prior art" would be
> found in the PR environment, we had little success 7 years ago while
> trying to find anything that might show exactly how PR equipment
> "downloaded instructions".
>
> There's remarkably little readily discoverable material about lots of
> the computer and network systems of the 70s/80s, especially internal
> details of operation, tools, procedures, etc. Plenty of stuff on
> Routing, but little on other mechanisms, or other types of networks of
> that era, at least that the lawyers and I could find. IMHO, that's a
> huge gap even in Internet History, since the Internet did not evolve in
> a vacuum, was itself composed of more than the ARPANET, and was
> surrounded by competitors (remember multiprotocol routers).
>
> /Jack
>
> On 9/6/20 11:58 AM, the keyboard of geoff goodfellow wrote:
>> Jack, you're a Most Eloquent purveyor of history and that WHY explain
>> is exactly what yours truly was hoping for... Thank You for the
>> elucidation! :D
>>
>> along the lines vis-a-vis:
>>
>> So, that's a bit about the "Why", for history to ponder. The
>> experience got me wondering about the "patent history" of The
>> Internet. Clearly there was a lot of innovation in those days.
>> My recollection is that very little was patented, even if only to
>> make sure no one else could. Maybe someone will document the
>> patent-related aspects of Internet History someday.
>>
>> please excuse/pardon this immodesty: yours truly had a kinda similar
>> "lawyered" experience with respect to WHO was the purported
>> "inventor"/originator of wireless email in a patent litigation case
>> and the "challenge" of finding/presenting any extant legally
>> submissive "artifactual proof" to that effect -- for which John
>> Markoff at the New York Times wrote about in this 2006 article:
>>
>> In Silicon Valley, a Man Without a Patent
>> https://www.nytimes.com/2006/04/16/business/technology/in-silicon-valley-a-man-without-a-patent.html
>>
>> for which some links of "proof" exist -- for some stuff mentioned in
>> the above NYT article -- on my website https://iconia.com/ under
>> "wireless email" (in case any historians are duly interested)...
>>
>> geoff
>>
>> On Sun, Sep 6, 2020 at 8:24 AM Jack Haverty <jack at 3kitty.org
>> <mailto:jack at 3kitty.org>> wrote:
>>
>> Geoff,
>>
>> Dave's IEEE paper does an excellent job of the
>> Who/What/When/Where. He's right that it was about 7 years ago.
>> Time flies... but I guess it's still "recent" when viewed as part
>> of Internet History.
>>
>> For the curious, I can add a bit more about the Why.
>>
>> Sometime in 2013, I got an email out of the blue from Charlie
>> Neuhauser, someone I didn't recognize or remember at all, asking
>> if I was the "Jack Haverty" who authored IEN 158 - documenting the
>> XNET protocol in 1980. Figuring that the statute of limitations
>> must have expired after 30+ years, I cautiously said yes. Over
>> the next few days, he hooked me up with the lawyers who were
>> involved in a patent dispute - one that had been going on for
>> several decades by then. In fact, the patent involved had been
>> issued, ran its 17 year lifetime, and expired, but there was still
>> litigation in process about whether or not the patent was valid,
>> and 17 years of violations were alleged cause for compensation in
>> the many millions. For the next few years I was involved in the
>> battles, working with the lawyers scattered all over the country.
>> I never met any of them. All our work was done by email and
>> telephone. No Zoom then or we probably would have used it.
>>
>> The core issue in the patent battle concerned "downloading
>> instructions", mechanisms such as would be involved in patching or
>> issuing new software releases to remote equipment. XNET seemed
>> to them to possibly have something to do with that, hence the
>> interest. The goal was to find hard evidence that such procedures
>> were being done by 1980, which would prove that prior art
>> existed. Hard evidence literally means "hard" - opinions help,
>> but physical equipment and running code is much more impressive in
>> a courtroom.
>>
>> They hadn't found any XNET artifacts, and I couldn't point them to
>> any surviving implementations. But I pointed out that my XNET
>> document simply captured the technology that we "stole" from the
>> ARPANET IMP experience, and that the IMPs routinely "downloaded
>> code" from their neighbors and the NOC all during the life of the
>> ARPANET.
>>
>> Since the IMPs had existed since the early 70s, that really
>> sparked their interest, and a search (worldwide) ensued to find
>> old IMPs, in the hope that just maybe one of them still had the
>> IMP software in its magnetic-core memory. A few IMPs were
>> located, but none were functional. The one in the museum at UCLA
>> seemed promising, but the owners were reluctant to even hook it up
>> to power after sitting idle for so many years, expecting it might
>> go up in smoke.
>>
>> Then I learned from the BBN alumni mailing list that an ancient
>> IMP listing had been found in a basement. The story from that
>> point is pretty well described in Dave's paper.
>>
>> Personally, it was an interesting experience. I worked
>> extensively with one lawyer in San Diego. I taught him how
>> computers and networks actually work; he taught me a lot about the
>> legal system regarding patents. IMHO, they are equally
>> convoluted and complex when viewed from the other's perspective.
>>
>> I also learned a lot about the IMP code, which I had never even
>> looked at while I was at BBN. One task I took on was to
>> exhaustively analyze the parts of the IMP code that implemented
>> the "download new instructions" functionality, writing up an
>> instruction-by-instruction description of how the code
>> accomplished that by interacting with a neighboring IMP. It was
>> a very clever design, and extremely tight code, even including
>> self-modifying instructions. Not easy to figure out (or explain
>> in language amenable to a non-technical judge or jury). So there
>> was great interest in being able to demonstrate the code in action
>> using real software from the 70s and hardware simulators.
>> Tangible evidence is much better than even expert opinions.
>>
>> The whole legal project came to a sudden end just a few months
>> prior to the first court date. I was looking forward to going
>> to Delaware (legal action was filed in Federal court in Delaware),
>> and finally meeting some of the people. But the parties settled
>> suddenly, the case was dropped, and AFAIK the patent question was
>> never resolved.
>>
>> So, that's a bit about the "Why", for history to ponder. The
>> experience got me wondering about the "patent history" of The
>> Internet. Clearly there was a lot of innovation in those days.
>> My recollection is that very little was patented, even if only to
>> make sure no one else could. Maybe someone will document the
>> patent-related aspects of Internet History someday.
>>
>> /Jack Haverty
>>
>>
>>
>> On 9/6/20 12:34 AM, the keyboard of geoff goodfellow wrote:
>>> jack, you've raised my curiosity with respect to:
>>>
>>> ... There
>>> *is* ARPANET IMP software which was recently restored and a small
>>> ARPANET was run using simulated IMP hardware.
>>>
>>> Who/What/When/Where/Why?
>>>
>>> geoff
>>>
>>> On Sat, Sep 5, 2020 at 8:40 PM Jack Haverty via Internet-history
>>> <internet-history at elists.isoc.org
>>> <mailto:internet-history at elists.isoc.org>> wrote:
>>>
>>> Lukasz,
>>>
>>> I think that the earliest implementations of TTL called it
>>> "Time", but
>>> I'm not aware that anyone actually used time per se in
>>> gateways, at
>>> least in the early days (1977-1982 or so).
>>>
>>> TCP implementations didn't do anything with TTL other than
>>> set it on
>>> outgoing datagrams, and at least in my implementation (TCP
>>> for Unix), it
>>> was just set to some arbitrary value. Until we had some data
>>> from
>>> experimentation it was hard to evaluate ideas about what
>>> routers, hosts,
>>> et al should actually do. The early TCPs did use time in
>>> handling
>>> retransmission timers, and there was work a bit later to
>>> incorporate
>>> time more powerfully into TCP behavior, e.g., Van Jacobson's
>>> work.
>>>
>>> The early gateways, IIRC, used the terminology "time", but in
>>> practice
>>> used just hop counts, since time measurements were difficult to
>>> implement. The exception to that may be Dave Mills'
>>> Fuzzballs, since
>>> Dave was the implementor most interested in time and making
>>> precise
>>> measurements of network behavior. I *think* Dave may have
>>> used time
>>> values and delay-based routing amongst his "fuzzies".
>>>
>>> The BBN doc you're seeking might have been one of many that
>>> discussed
>>> the ARPANET internal mechanisms, e.g., ones with titles like
>>> "Routing
>>> Algorithm Improvements". The ARPANET internal mechanisms did
>>> use time.
>>> It was fairly simple in the IMPs, since the delay introduced
>>> by the
>>> synchronous communications lines could be easily predicted,
>>> and the
>>> other major component of delay was the time spent in queues,
>>> which could
>>> be measured fairly easily.
>>>
>>> I even found one BBN ARPANET Project QTR from circa 1975 that
>>> discussed
>>> the merits of the new-fangled TCP proposal that some
>>> professor had
>>> published -- and seemed to conclude it couldn't possibly work.
>>>
>>> My involvement in implementations of TCPs and gateways lasted
>>> through
>>> about mid-1983, so I don't know much of the detail of subsequent
>>> implementations. For the various BBN gateway/router
>>> equipment, Bob
>>> Hinden would probably be a good source. The other major
>>> early player
>>> was MIT and spinoffs (Proteon), which perhaps Noel Chiappa will
>>> remember. There's also at least one paper on the Fuzzballs
>>> which may
>>> have some details.
>>>
>>> One thing I'd advise being careful of is the various
>>> "specifications" in
>>> RFCs. Much of the wording in those was intentionally
>>> non-prescriptive
>>> (use of "should" or "may" instead of "must"), to provide as much
>>> latitude as possible for experimentation with new ideas,
>>> especially
>>> within an AS. The Internet was an Experiment.
>>>
>>> Also, there was no consistent enforcement mechanism to assure
>>> that
>>> implementations actually even conformed to the "must"
>>> elements. So
>>> Reality could be very different from Specification.
>>>
>>> I don't know of any gateway implementations that have
>>> survived. There
>>> *is* ARPANET IMP software which was recently restored and a small
>>> ARPANET was run using simulated IMP hardware. I still have
>>> a ~1979
>>> listing of the TCP I wrote for Unix, but haven't scanned it
>>> into digital
>>> form yet.
>>>
>>> Jack
>>>
>>> On 9/5/20 7:38 PM, Łukasz Bromirski wrote:
>>> > Jack,
>>> >
>>> > I was reading a lot of old BBN PDFs thanks to all good souls on
>>> > this list that post nice URLs from time to time.
>>> >
>>> > I remember reading in at least one of them, that apparently
>>> first
>>> > TCP/IP implementations were indeed using TTL as literally
>>> “time”,
>>> > not hop count. I believe there somewhere there between PDP docs
>>> > and ARPANET docs I’ve read something to the effect “and
>>> from this
>>> > time we changed from measuring time to simply count routing
>>> hops”.
>>> > Of course, right now google-fu is failing me.
>>> >
>>> > Quoting RFC 1009 that was already brought up, there’s quite
>>> > direct “definition” of the field:
>>> >
>>> > "4.8. Time-To-Live
>>> >
>>> > The Time-to-Live (TTL) field of the IP header is defined
>>> to be a
>>> > timer limiting the lifetime of a datagram in the
>>> Internet. It is
>>> > an 8-bit field and the units are seconds. This would
>>> imply that
>>> > for a maximum TTL of 255 a datagram would time-out after
>>> about 4
>>> > and a quarter minutes. Another aspect of the definition
>>> requires
>>> > each gateway (or other module) that handles a datagram to
>>> > decrement the TTL by at least one, even if the elapsed
>>> time was
>>> > much less than a second. Since this is very often the
>>> case, the
>>> > TTL effectively becomes a hop count limit on how far a
>>> datagram
>>> > can propagate through the Internet."
>>> >
>>> > Were there any implementations that survived somewhere and
>>> actually
>>> > did exactly that - counted actual time/processing delay,
>>> not hops?
>>> > And if it took 2s to process packet, did they really
>>> decrement TTL
>>> > by two?
>>> >
>>> > Thanks for any pointers,
>>>
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> <mailto:Internet-history at elists.isoc.org>
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>
>>>
>>>
>>> --
>>> Geoff.Goodfellow at iconia.com <mailto:Geoff.Goodfellow at iconia.com>
>>> living as The Truth is True
>>>
>>>
>>>
>>
>>
>> --
>> Geoff.Goodfellow at iconia.com <mailto:Geoff.Goodfellow at iconia.com>
>> living as The Truth is True
>>
>>
>>
More information about the Internet-history
mailing list