[ih] Internet-history Digest, Vol 12, Issue 36
John Shoch
j at shoch.com
Mon Sep 7 16:16:10 PDT 2020
Well, I'm not sure of the time frame for that comment on Packet Radio
Network performance, but we had a better experience.
At the 6th Data Comm. Symposium in the fall of 1979 [over 40 years ago] we
reported 12-20 Kbps, internetwork end-to-end:
https://dl.acm.org/doi/10.1145/800092.802993
--With support from Vint and SRI we used the PRNet as a transit network,
part of our PUP internet deployment.
--Running our regular test programs we got 12-15 Kbps through 3 networks
(reliable byte streams, Alto-Ethernet-PUP Gateway-PRNet-PUP
Gateway-Ethernet-Alto).
--I presume that included network-specific fragmentation and reassembly
required for the PRNet, which had a smaller native packet size than a PUP
packet.
--We apparently tweaked some PRNet parameters and got the throughput up to
20 Kbps.
--That link ran in parallel with our 9.2 Kbps phone line, at the time.
--We did have to sort out a few issues -- "...it is worth noting that the
Ethernet and the Radionet are systems whose overall performance differs by
at least two decimal orders of magnitude -- a range which will continue to
challenge the design of good flow control and congestion control
procedures."
It was a fun time; kudos to SRI and everyone else....
John Shoch
Date: Mon, 7 Sep 2020 16:30:15 -0600
From: Craig Partridge <craig at tereschau.net>
To: Craig Partridge via Internet-history
<internet-history at elists.isoc.org>
Subject: Re: [ih] Recently restored and a small ARPANET was run using
simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol])
Message-ID:
<CAHQj4Cc8TQVy_Z8CYHV_+eHocQb2YjvagVSQAPHe0ewxqZV82A at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Two quick followups to Jack's note.
Dave Mills wrote a retrospective on the Fuzzball in 1988 in SIGCOMM '88. (
https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf).
When I knew the Packet Radio work, it was supervised by Jil Westcott (Div
4) and there was a rack of PRs in a computer room in 10 Moulton right by
the bridge. Data rates, even over a few feet, were painfully slow and the
late Charlie Lynn was the lead programmer. I have a vague recollection
(perhaps wrong) of Charlie commenting that the links were so bad, that
getting even minimal information between the devices was a challenge.
Craig
On Mon, Sep 7, 2020 at 3:30 PM <internet-history-request at elists.isoc.org>
wrote:
> Send Internet-history mailing list submissions to
> internet-history at elists.isoc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://elists.isoc.org/mailman/listinfo/internet-history
> or, via email, send a message with subject or body 'help' to
> internet-history-request at elists.isoc.org
>
> You can reach the person managing the list at
> internet-history-owner at elists.isoc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Internet-history digest..."
>
>
> Today's Topics:
>
> 1. Re: inter IMP hackery [was Recently restored and a small
> ARPANET was run using simulated IMP hardware, ] (Alex McKenzie)
> 2. Re: inter IMP hackery [was Recently restored and a small
> ARPANET was run using simulated IMP hardware, ] (Alex McKenzie)
> 3. Re: Recently restored and a small ARPANET was run using
> simulated IMP hardware. (was: TTL [was Exterior Gateway
> Protocol]) (Craig Partridge)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 7 Sep 2020 20:26:00 +0000 (UTC)
> From: Alex McKenzie <amckenzie3 at yahoo.com>
> To: Internet-history <internet-history at elists.isoc.org>
> Subject: Re: [ih] inter IMP hackery [was Recently restored and a small
> ARPANET was run using simulated IMP hardware, ]
> Message-ID: <1085132283.1107108.1599510360228 at mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> Geoff,
> As far as I can recall, the only actual use of the mag tape TIPs was to
> transfer data from one to another.? However, I believe they implemented a
> (undoubtedly small) subset of FTP so in theory they could have exchanged
> data with other Hosts.? I know no details of their actual use (if any).? I
> don't know what bandwidth they achieved although the ARPAnet design would
> not have allowed them to exceed the bandwidth of a single IMP-IMP phone
> circuit, and those were almost all 50kbs.? If there were any measurements
> of performance in the field it would have been by GWC and/or ASL, not the
> NOC or NMC.? I think it is fair to say the mag tape TIP was an experiment
> that didn't catch on.
>
> Cheers,Alex
>
> On Monday, September 7, 2020, 2:06:27 PM EDT, the keyboard of geoff
> goodfellow <geoff at iconia.com> wrote:
>
> thanks for the clarification on the MTIPs Alex... was always curious as
> to the MTIPs, as they seemed "unique"/"forgotten" in the history of the
> ARPANET and never seemed to get much if any?prominence (and now
> understandably?given that there were only two of them).
> the MTIPs had come to yours truly's attention in that in the Tenex host
> table file, <System>Host-Name/Descriptor-File.txt as well as IIRC in the
> NIC's (SRI-ARC) <Netinfo>Hosts.txt there was a descriptor field of what
> type?(i.e. functionality) a given host provided: User, Server, TIP or MTIP.
> one remaining question of the MTIPs: did they only transfer data between
> them exclusively over the ARPANET, MTIP to MTIP only, -OR- were they used
> to transfer/send data from a mag tape on an MTIP to some socket & receiving
> process on a "server" host?
> if the later, the next curious/pesky question would be: what was the
> protocol (and corresponding socket #) used to effectuate said data
> transference??geoff
> On Mon, Sep 7, 2020 at 6:30 AM Alex McKenzie via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> ?Geoff,
> Now that I've refreshed my memory, I can say that the 2 mag tape TIPs were
> installed at Global Weather Central, Offett AFB, NE, and Atmospheric
> Sciences Lab, Army Electronics R&D Command, White Sands Missile Range, NM.?
> As I said in my previous message, the motivation was to allow the two
> organizations? to experiment with using the ARPAnet to replace whatever
> method they were using to exchange large amounts of data.? I cannot
> remember the dates associated with this test, nor can I recall if it was
> deemed a success.
> Sorry for the previous mis-information,Alex
>
> ? ? On Monday, September 7, 2020, 11:01:20 AM EDT, Alex McKenzie via
> Internet-history <internet-history at elists.isoc.org> wrote:?
>
> ? Geoff,
> There were two mag tape TIPs, at Tinker and McClellan Air Force Bases.?
> The motivation was to allow the Air Force to experiment with using the
> ARPAnet to replace whatever method they were using to exchange large
> amounts of data.? I think the test was successful and Tinker and McClellan
> then decided to attach Hosts to the TIPs to continue operational use of the
> net to do their data exchanges.? Steve Crocker was involved in helping the
> Air Force people design the Host software to use the ARPAnet, which led to
> an amusing story which Steve has recounted several times (it crashed the
> network, and one of the BBN people decided it was deliberate).? As I recall
> the test was run in the summer of 1972 and shortly after that the mag tape
> hardware and software stopped being supported by BBN.
> Cheers,Alex
>
> ? ? On Sunday, September 6, 2020, 9:05:33 PM EDT, the keyboard of geoff
> goodfellow via Internet-history <internet-history at elists.isoc.org>
> wrote:?
>
> ?Dave (or Bernie), can you provide any elucidation on the ARPANET MTIPs
> (the
> TIPs that had a magnetic tape unit attached to them)?
>
> yours truly kinda recalls there were perhaps two of them... one being at
> GWC?
>
> why were they created and to whom did they send their data?
>
> geoff
>
> On Sun, Sep 6, 2020 at 2:50 PM dave walden via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > I can describe the genesis.? The IMP code was originally for one host
> > computer and several inter-IMP modems (that was what our contract
> > specified), and I coded the IMP/Host and Host/IMP code for that in
> > parallel with Bernie coding the DDT, etc. Then some host site wanted a
> > second host on its IMP -- I think maybe UCLA for its IBM 360.? ARPA
> > called us and asked if the IMP could handle more than one Host.? Our
> > hardware guys said the Honeywell computer could support (if I remember
> > correctly) up to seven interfaces which could be up to four Host
> > interfaces or up to four inter-IMP modem interfaces.? We looked at the
> > IMP/Host and Host/IMP code and it seemed fairly easy to make it
> > reentrant, so we told ARPANET "yes".? Once the IMP would know how to
> > handle multiple Hosts and given there was a bit in the header words
> > between IMPs and Host to say "real" Host or "fake" Host, the
> > possibilities were fairly clear.? I implemented the reentrant IMP-host
> > and host-IMP code, and Bernie changed the routines he had written or was
> > writing:
> > - TTY in/out
> > - DDT in/out
> > - parameter change packets into the IMP and trace packets out of the IMP
> > - into the IMP to be discarded and statistics packets out of the IMP
> > For the regular reports from IMPs to the Network Monitoring Center, a
> > bit of code in the IMP could send packets to a real host; I don't
> > remember which of the fake Hosts they looked like they were coming from
> > -- stats maybe.
> >
> > On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote:
> > > 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:
> > >
> > >
> > --
> > 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
> ?
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
> --
> 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
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 7 Sep 2020 20:44:40 +0000 (UTC)
> From: Alex McKenzie <amckenzie3 at yahoo.com>
> To: Internet-history <internet-history at elists.isoc.org>
> Subject: Re: [ih] inter IMP hackery [was Recently restored and a small
> ARPANET was run using simulated IMP hardware, ]
> Message-ID: <473718283.4103758.1599511480307 at mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> Geoff,
> The NOC in the early 1970s was interested in the up/down status of IMPs,
> lines, and eventually Hosts, diagnosing IMP failures, and coordinating IMP
> software releases. The NOC also published network? traffic statistics to
> ARPA and via the RFC series to the NWG.? The NMC was interested in
> measuring the internal performance of the network under both real and
> artificial load, looking at things like queue lengths, packet lifetimes,
> maximum achievable throughputs, end-to-end delays, and so on.? In some
> sense they were responsible for telling ARPA whether the network BBN
> delivered met the specs of the RFQ.? They were also interested in comparing
> the actually performance to the predictions of queuing theory.? They made
> extensive use of traffic generation tools and statistics reporting tools
> built into the IMPs by BBN as "fake hosts", and collected? and analyzed the
> data on their Sigma-7.? Their experiments were often disruptive of network
> performance as seen by other Hosts, and therefore the
> ir experiment times were scheduled and controlled by the NOC.? This led
> to a certain degree of tension between the personnel at the NOC and the
> NMC, but nothing that couldn't be handled.? I believe the first publication
> of the NMC's work was a paper by Gerald Cole (one of Kleinrock's students)
> titled "Performance Measurements on the ARPA Computer Network" in the
> Proceedings of the ACM second symposium on Problems in the optimizations of
> data communications systems January 1971.
> Hope this helps,Alex
>
>
>
>
>
> On Monday, September 7, 2020, 2:55:50 PM EDT, the keyboard of geoff
> goodfellow via Internet-history <internet-history at elists.isoc.org>
> wrote:
>
> would be curious to know WHAT did UCLA-NMC measure and HOW did it measure
> it?
>
> i.e. was there a "precursor" to some kind of SNMP capability that allowed
> UCLA-NMC to peer inside IMPs or hosts?
>
> or were their processes on (all?) the ARPANET hosts at the time that
> collected data from their respective OS's that the UCLA-NMC machine would
> then periodically poll to get the data, kind of like the Tenex RSSER job
> processes did with respect to sharing load avg. data among themselves?
>
> [btw, believe that unless Leonard Kleinrock <lk at cs.ucla.edu> is
> on/subscriber to the IH list, any reply sent to IH would be black holed, as
> the IH list is most likely configured (Joe can confirm) to only allow
> submissions to it from its "subscribers"... ERGO, if Len does reply, even
> if cc'ng the list, you'd need to then manually fwd it to the list for
> everyone else to see.]
>
> geoff
>
>
> On Mon, Sep 7, 2020 at 8:36 AM Steve Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > I don't think the NMC measured anything at the host level, but I could be
> > wrong.? Vint and Len copied explicitly.
> >
> > Steve
> >
> >
> > On Mon, Sep 7, 2020 at 2:30 PM Jack Haverty via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> > > On 9/7/20 11:15 AM, Steve Crocker via Internet-history wrote:
> > > > It would be interesting to know the
> > > > transfer rate between MTIPs.
> > > This is the kind of thing that I'd expect the ARPANET NMC (Network
> > > Measurement Center at UCLA, as opposed to NOC - Network Operations
> > > Center at BBN) might have been measuring.? I don't remember ever seeing
> > > any results or raw data from Measurements, and don't know much about
> > > that part of the History.? Were results published somewhere and did
> > > such reports survive?
> > > /Jack
> > >
> > > --
> > > Internet-history mailing list
> > > Internet-history at elists.isoc.org
> > > https://elists.isoc.org/mailman/listinfo/internet-history
> > >
> > --
> > 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
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 7 Sep 2020 16:30:15 -0600
> From: Craig Partridge <craig at tereschau.net>
> To: Craig Partridge via Internet-history
> <internet-history at elists.isoc.org>
> Subject: Re: [ih] Recently restored and a small ARPANET was run using
> simulated IMP hardware. (was: TTL [was Exterior Gateway Protocol])
> Message-ID:
> <
> CAHQj4Cc8TQVy_Z8CYHV_+eHocQb2YjvagVSQAPHe0ewxqZV82A at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Two quick followups to Jack's note.
>
> Dave Mills wrote a retrospective on the Fuzzball in 1988 in SIGCOMM '88. (
> https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf).
>
> When I knew the Packet Radio work, it was supervised by Jil Westcott (Div
> 4) and there was a rack of PRs in a computer room in 10 Moulton right by
> the bridge. Data rates, even over a few feet, were painfully slow and the
> late Charlie Lynn was the lead programmer. I have a vague recollection
> (perhaps wrong) of Charlie commenting that the links were so bad, that
> getting even minimal information between the devices was a challenge.
>
> Craig
>
>
>
> On Mon, Sep 7, 2020 at 12:00 PM Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > 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
> > >>
> > >>
> > >>
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
>
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>
> ------------------------------
>
> End of Internet-history Digest, Vol 12, Issue 36
> ************************************************
>
More information about the Internet-history
mailing list