[ih] Internet-history Digest, Vol 12, Issue 36

Barbara Denny b_a_denny at yahoo.com
Mon Sep 7 19:43:24 PDT 2020


  I believe a packet radio sent data at either 400 or 100 Kbps depending on the link quality.   

barbara 
    On Monday, September 7, 2020, 04:16:40 PM PDT, John Shoch via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 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
> ************************************************
>
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  


More information about the Internet-history mailing list