[ih] BBN C-series computers

[Paul Ruizendaal]

I'm trying to get a better understanding of the BBN C30, C70 and C60 machines. Google seems to yield little relevant info for them.

>From brief references in other documents my understanding is that these were microprogrammable machines with 10-bit bytes and 20-bit addresses. Maybe they were all the same machine in different configurations.

I think the C30 was used to replace the 316/516 as IMP's from 1980 onwards. The C70 seems to have been a "Unix machine", perhaps targeted at a role as gateway (router). The C60 seems to have been a general purpose version for the broader market.

Any further info about these machines welcome.

[Bernie Cosell]

On 21 Oct 2017 at 13:54, Paul Ruizendaal wrote:

> I'm trying to get a better understanding of the BBN C30, C70 and C60
> machines. Google seems to yield little relevant info for them.
>
> >From brief references in other documents my understanding is that these
> were microprogrammable machines with 10-bit bytes and 20-bit addresses.
> Maybe they were all the same machine in different configurations.

They were, indeed, machines with 10-bit bytes and 20-bit addresses. BBN
designed and built a microprogrammable board precisely to put the IMP
code on -- Honeywell was discontinuing the H316. I'm not sure of the
details about how they ported the IMP code, but I think they were able to
use the same source code. That became the C30.

A separate project was to replace the [expensive] PDP 11/70s [I think]
with an MBB [microprogrammable building block] based Unix system. The
original plan was for it to have a lifetime of a year or two,
anticipating that better/cheaper unix platforms would be available. We
worked with the original Unix C-code. We designed an 'instruction set'
for the MBB. Carl Howe wrote the microcode to implement it. I modified
a C compiler [running on a 36-bit PDP-10] to produce "MBB microcode" and
Al Nemeth worked to make it run.

There was never an assembler for the MBB-Unix [which became the C70 when
we got it working] -- "C" was the only "assembly" code for the system.
That freed us to make the MBB instruction set quite irregular [with
different field sizes, different subroutine calls [depending on the
number of arguments] and other efficiency hacks like that. We got it
going surprisingly quickly and Al kept studying the resulting code and
making suggestions. Carl would implement them, I'd hack them into the
compiler, rebuild the system, download into the MBB, and check again.

One I remember was that Al noticed that some large percentage of the
subroutine calls in the kernel were either zero argument or one-argument
calls. So we implemented a second subroutine call instruction that
always pushed the AC onto the stack and called the subroutine [in one MBB
cycle] -- similarly there were two 'return' instuctions, one normal and
one popped a single arg off the stack as it returned. The compiler
figured all this out and did the right thing [using the 'long' or 'quick'
subr call instruction]

Another involved accessing structures. Al checked the size of structures
in the kernel and found the predominant "maximum" size, and Carl made
room in an MBB instruction for a constant of that size, and I had the
compiler figure out whether it could do an 'indirect and index' into a
struct in a single instruction (when it could) and the usual struct
reference code otherwise.

I remember when we decided that the C70 was stable and solid enough that
it could run its own compiler [now running on a 20-bit machine]. After
some hacking, we got the on-PDP10 compiler and the on-MBB compiler to
produce identical results, and we cut the cord: running entirely on the
[now] C70 itself. The result of all of this [Al's optimizing, Carl's
clever microcode and a smart compiler] was that the C70 was *very* fast.
Much faster than the 11/70. As a result, it survived for many years past
its expect lifetime [and was good enough that BBNCC was selling it as
cost-effective Unix product]

/Bernie\

--
Bernie Cosell Fantasy Farm Fibers
mailto:***@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--

[Dave Walden]

Paul,

See http://walden-family.com/bbn/bbn-print2.pdf and search repeatedly
for "C/30" for some not-too-deep information on the C series of machines.

See http://walden-family.com/impcode/imp-code.pdf and read the section
found by searching for "MBB" for a bit for a high level timeline of how
the H516/316 IMP code transitioned to the C/30, etc., and evolved there.

See M.F. Kraley et al., “Design of a User-Microprogrammable Building
Block,” Proc. 13th Ann. Microprogramming Workshop, Colorado Springs,
1980, pp. 106–114, for more about the hardware base on which the C/30
etc. were built.

Some of the people exBBN people on this list might have worked on those
machines.  If you are working on a research paper, I can put you in
touch with people not on this list who worked on these systems.

Dave


On 10/21/2017 7:54 AM, Paul Ruizendaal wrote:
> I'm trying to get a better understanding of the BBN C30, C70 and C60 machines. Google seems to yield little relevant info for them.
>
> >From brief references in other documents my understanding is that these were microprogrammable machines with 10-bit bytes and 20-bit addresses. Maybe they were all the same machine in different configurations.
>
> I think the C30 was used to replace the 316/516 as IMP's from 1980 onwards. The C70 seems to have been a "Unix machine", perhaps targeted at a role as gateway (router). The C60 seems to have been a general purpose version for the broader market.
>
> Any further info about these machines welcome.
>
>
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>

--
12 Linden Road, East Sandwich, 02537
landline=508-888-7655; cell=774-205-3202
website=walden-family.com

[Paul Ruizendaal]

Many thanks all for that C30/60/70 background! It lets a few more puzzle pieces fall into place.

By the way, I found this Computer World advert for the C60 from December 1981:
https://books.google.nl/books?id=87IzRZnd_UYC&pg=RA1-PA63&lpg=RA1-PA63&dq=c/60+bolt+beranek+introducing&source=bl&ots=k9-3aJZiCL&sig=pwEkQyHF6spDLmPJppvmFe8mA80&hl=nl&sa=X&ved=0ahUKEwiOurum1ofXAhUMDMAKHat7C1EQ6AEILTAB#v=onepage&q=c%2F60%20bolt%20beranek%20introducing&f=false

My interest in these machines is merely retro hobby and was triggered again by some comments in the Gurwitz TCP/IP code. Apparently the code was written to target both the VAX and the C70, perhaps as an aid in finding unintended machine dependencies quickly (having different word sizes and being little vs. big endian helps with that sort of thing).

Sections for the C70 are "#ifdef MBB” and now I finally know what that MBB acronym means. I suppose the “Design of a User-Microprogrammable Building Block” paper will explain more (have not read it yet).


Bernie, a few follow-up questions on the C70 and its C/Unix environment if I may:

- Can you confirm that the C/70 indeed ran the TCP/IP stack?

- The advert says the C/60 was running V7 Unix, I assume this was true of the C/70 as well? Before now, I did not realise that the TCP/IP stack integrated with V7 as well.

- Would you at this remove still remember the main features of the C/70 MMU? This detail is relevant to me as it has a connection to the evolution of network buffer management in Unix, and also to the organisation of network code in the kernel.

- How should I understand "There was never an assembler for the MBB-Unix”? If I read your notes correctly the compiler did not generate microcode, but instructions on a traditional instruction set architecture level. In that context, wouldn’t the last phase of the (native) compiler be an assembler of sorts? Wouldn’t you need some sort of assembler to write libraries for system calls, signal handling, making longjmp's, etc.?

[Bernie Cosell]

> - Can you confirm that the C/70 indeed ran the TCP/IP stack?

I don't know. I expect it did

> - The advert says the C/60 was running V7 Unix, I assume this was true
> of the C/70 as well? Before now, I did not realise that the TCP/IP stack
> integrated with V7 as well.

That was the version of unix we had the sources for. There was no
floating point! After we got the system up and running I left the
project. I understand the next thing to be done was to add 'float' to
the compiler -- but this was all done locally on the C/70.

> - Would you at this remove still remember the main features of the C/70
> MMU? This detail is relevant to me as it has a connection to the
> evolution of network buffer management in Unix, and also to the
> organisation of network code in the kernel.

I have no idea -- Probably someone like Carl Howe would know that. I had
little to do with the kernel or the machinery.

> - How should I understand "There was never an assembler for the
> MBB-Unix”? If I read your notes correctly the compiler did not
> generate microcode, but instructions on a traditional instruction set
> architecture level.

Mostly it generated binary! There was a sort of 'traditional'
instruction set but it wasn't available outside the compiler. As I
mentioned, it was very irregular and wasn't designed to be "user
friendly" [or even "user comprehensible"]

> .. In that context, wouldn’t the last phase of the
> (native) compiler be an assembler of sorts? Wouldn’t you need some
> sort of assembler to write libraries for system calls, signal handling,
> making longjmp's, etc.?

Not really -- I don't remember how we managed that, but there was no
direct "assembly" code. In fact, the "instruction set" changed from time
to time as we hacked new things in. I expect some BBN report documented
the actual final MMB machinery but it wasn't publicized and other than
making a binary, basically, by hand there wasn't any way to code for the
machine other than in 'C'.

I don't remember how we handled user processes, memory handling, system
calls, etc. Dave: did we ever do a BBN report on the insides of the
C/70? I don't remember doing one.

/Bernie\

--
Bernie Cosell Fantasy Farm Fibers
mailto:***@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--

[Dave Walden]

There are about 5 reports in the BBN/BBNCC reports list that have "C/70"
in their title. This are about operations, specialized applications of
the C/70, and one about "Gastronomie of Power Consumption".  None of the
titles indicate anything bout detailed design.


On 10/23/2017 6:42 PM, Paul Ruizendaal wrote:
> Many thanks all for that C30/60/70 background! It lets a few more puzzle pieces fall into place.
>
> By the way, I found this Computer World advert for the C60 from December 1981:
> https://books.google.nl/books?id=87IzRZnd_UYC&pg=RA1-PA63&lpg=RA1-PA63&dq=c/60+bolt+beranek+introducing&source=bl&ots=k9-3aJZiCL&sig=pwEkQyHF6spDLmPJppvmFe8mA80&hl=nl&sa=X&ved=0ahUKEwiOurum1ofXAhUMDMAKHat7C1EQ6AEILTAB#v=onepage&q=c%2F60%20bolt%20beranek%20introducing&f=false
>
> My interest in these machines is merely retro hobby and was triggered again by some comments in the Gurwitz TCP/IP code. Apparently the code was written to target both the VAX and the C70, perhaps as an aid in finding unintended machine dependencies quickly (having different word sizes and being little vs. big endian helps with that sort of thing).
>
> Sections for the C70 are "#ifdef MBB” and now I finally know what that MBB acronym means. I suppose the “Design of a User-Microprogrammable Building Block” paper will explain more (have not read it yet).
>
>
> Bernie, a few follow-up questions on the C70 and its C/Unix environment if I may:
>
> - Can you confirm that the C/70 indeed ran the TCP/IP stack?
>
> - The advert says the C/60 was running V7 Unix, I assume this was true of the C/70 as well? Before now, I did not realise that the TCP/IP stack integrated with V7 as well.
>
> - Would you at this remove still remember the main features of the C/70 MMU? This detail is relevant to me as it has a connection to the evolution of network buffer management in Unix, and also to the organisation of network code in the kernel.
>
> - How should I understand "There was never an assembler for the MBB-Unix”? If I read your notes correctly the compiler did not generate microcode, but instructions on a traditional instruction set architecture level. In that context, wouldn’t the last phase of the (native) compiler be an assembler of sorts? Wouldn’t you need some sort of assembler to write libraries for system calls, signal handling, making longjmp's, etc.?
>
>
>
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.

--
12 Linden Road, East Sandwich, 02537
landline=508-888-7655; cell=774-205-3202
website=walden-family.com

[Vint Cerf]

The BBN guys will have to respond but I recall contracting with them for an
X.25 network for MCI Mail in 1983. Originally I think the CXX's emulated
the BBN 1822 interface as a substitute for IMPs that used the Honeywell
DDP-X16 processors. Their commecial offerings used X.25 which was a popular
standard during the late 1970s and was widely used until the early 2000s (I
shut down MCI's X.25 services around 2003) and might still be used in
banking/financial transactions system if they haven't all been moved over
to TCP/IP by now.

On Sat, Oct 21, 2017 at 7:54 AM, Paul Ruizendaal <***@planet.nl> wrote:

>
> I'm trying to get a better understanding of the BBN C30, C70 and C60
> machines. Google seems to yield little relevant info for them.
>
> >From brief references in other documents my understanding is that these
> were microprogrammable machines with 10-bit bytes and 20-bit addresses.
> Maybe they were all the same machine in different configurations.
>
> I think the C30 was used to replace the 316/516 as IMP's from 1980
> onwards. The C70 seems to have been a "Unix machine", perhaps targeted at a
> role as gateway (router). The C60 seems to have been a general purpose
> version for the broader market.
>
> Any further info about these machines welcome.
>
>
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>



--
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190

[Miles Fidelman]

Obviously the C-series machines found their niche as network devices. 
But I remember being told that they were originally designed
specifically with optimizations to run c language code. Perhaps somebody
older than I can verify that (or not).

Miles Fidelman


On 10/21/17 7:54 AM, Paul Ruizendaal wrote:
> I'm trying to get a better understanding of the BBN C30, C70 and C60 machines. Google seems to yield little relevant info for them.
>
> >From brief references in other documents my understanding is that these were microprogrammable machines with 10-bit bytes and 20-bit addresses. Maybe they were all the same machine in different configurations.
>
> I think the C30 was used to replace the 316/516 as IMP's from 1980 onwards. The C70 seems to have been a "Unix machine", perhaps targeted at a role as gateway (router). The C60 seems to have been a general purpose version for the broader market.
>
> Any further info about these machines welcome.
>
>
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

[Dave Walden]

On 10/21/2017 9:58 AM, Miles Fidelman wrote:
> Obviously the C-series machines found their niche as network devices.
> But I remember being told that they were originally designed
> specifically with optimizations to run c language code. Perhaps somebody
> older than I can verify that (or not).

Here is my memory.

1. Mike Kraley, Randy Rettberg, etc., developed the MBB (micro-coded
building block).

2. BBN started the BBN Computer Corporation to be a computer company
with the MBB as the base of its systems.  One market was as a
replacement computer to run the 316 IMP code in BBN's (separate) network
business.  Another use was to try to be a commercial Unix computer
manufacturer which would run Unix particularly well because it was
micro-coded (as Bernie described in his message) to execute C directly.

3. Being in the Unix computer business didn't go particularly well, but
there was increasing demand for C/30-IMP-based networks.

4. BBN networking business was folded into the computer business and the
combination was renamed BBN Communications Corporation. The C/70 has a
natural market there as a non-IMP component in network applications.

5. The C/70 also had other applications within BBN's various R&D
applications; search for "C/70" at walden-family.com/bbn/bbn-print2.pdf

[Bob Hinden]

Dave,

> On Oct 21, 2017, at 7:56 AM, Dave Walden <***@gmail.com> wrote:
>
> On 10/21/2017 9:58 AM, Miles Fidelman wrote:
>> Obviously the C-series machines found their niche as network devices.
>> But I remember being told that they were originally designed
>> specifically with optimizations to run c language code. Perhaps somebody
>> older than I can verify that (or not).
>
> Here is my memory.
>
> 1. Mike Kraley, Randy Rettberg, etc., developed the MBB (micro-coded
> building block).
>
> 2. BBN started the BBN Computer Corporation to be a computer company
> with the MBB as the base of its systems. One market was as a
> replacement computer to run the 316 IMP code in BBN's (separate) network
> business. Another use was to try to be a commercial Unix computer
> manufacturer which would run Unix particularly well because it was
> micro-coded (as Bernie described in his message) to execute C directly.
>
> 3. Being in the Unix computer business didn't go particularly well, but
> there was increasing demand for C/30-IMP-based networks.
>
> 4. BBN networking business was folded into the computer business and the
> combination was renamed BBN Communications Corporation. The C/70 has a
> natural market there as a non-IMP component in network applications.
>
> 5. The C/70 also had other applications within BBN's various R&D
> applications; search for "C/70" at walden-family.com/bbn/bbn-print2.pdf

This matches my memory as well.

The C/70 was, as Bernie Cosell noted in his email, a big improvement over running Unix on the DEC PDP 11/70. Unfortunately, DEC came out with the VAX shortly after the C/70 was completed which reduced the market opportunity for the C/70 significantly.

Bob

[Alex McKenzie]

I believe the original question was about the C/30, C/60, and C/70.  Answers so far have not addressed the C/60.  I believe that was the "catalog number" for a C/70 equipped with the suite of Network Management software developed by BBN.  But my memory is fuzzy.
Cheers,Alex McKenzie

[John Levine]

In article <CA5F73E9-DD4E-4A68-8477-***@gmail.com> you write:
>> 2. BBN started the BBN Computer Corporation to be a computer company
>> with the MBB as the base of its systems. One market was as a
>> replacement computer to run the 316 IMP code in BBN's (separate) network
>> business.

It is my recollection that the C30 was a microcoded reimplementation of
the 516. The IMP code was so dense that it was easier to reimplement
the hardware than the software.

>The C/70 was, as Bernie Cosell noted in his email, a big improvement over running Unix on the DEC PDP 11/70. Unfortunately, DEC came out with the VAX shortly
>after the C/70 was completed which reduced the market opportunity for the C/70 significantly.

I ran into someone I think at a Usenix meeting who groused that
porting existing Unix code to the C70 was difficult because everyone
unreasonably assumed that bytes were 8 bits.

While it was certainly nice that the C70 let you run bigger individual
programs than the -11, it was about a decade too late for a computer
that didn't have eight bit bytes.

R's,
John

[Andrew G. Malis]

The C/30, indeed, started life by faithfully emulating the Honeywell
316/516 instruction set and hardware model so that we were able to run the
existing IMP code with minimal changes. However, once we got that working,
we then started taking advantage of the microprgramability of the hardware
to move significant portions of the code into microcode. We had a great set
of tools for profiling the code execution to see where we could get the
greatest bang for the buck by moving heavily executed code into microcode
(especially in the packet forwarding code path), and we also microcoded
some atomic operations like queue and stack management. I wrote some amount
of microcode myself, including the driver for the tape drive to be able to
remotely download new versions of the code onto tape, and reload the C/30s
from the tape drive.

One of the major differences between the C/30 and C/60 and C/70 was that
the C/30 didn’t have any disk drives, just a tape drive.

The C/70 was a general purpose UNIX machine. The C/60 was a cost-optimzed
version of the C/70 used to operate a C/30-based network, and it came with
the necessary network management software.

Cheers,
Andy


On Sat, Oct 21, 2017 at 1:28 PM, John Levine <***@iecc.com> wrote:

> In article <CA5F73E9-DD4E-4A68-8477-***@gmail.com> you write:
> >> 2. BBN started the BBN Computer Corporation to be a computer company
> >> with the MBB as the base of its systems. One market was as a
> >> replacement computer to run the 316 IMP code in BBN's (separate) network
> >> business.
>
> It is my recollection that the C30 was a microcoded reimplementation of
> the 516. The IMP code was so dense that it was easier to reimplement
> the hardware than the software.
>
> >The C/70 was, as Bernie Cosell noted in his email, a big improvement over
> running Unix on the DEC PDP 11/70. Unfortunately, DEC came out with the
> VAX shortly
> >after the C/70 was completed which reduced the market opportunity for the
> C/70 significantly.
>
> I ran into someone I think at a Usenix meeting who groused that
> porting existing Unix code to the C70 was difficult because everyone
> unreasonably assumed that bytes were 8 bits.
>
> While it was certainly nice that the C70 let you run bigger individual
> programs than the -11, it was about a decade too late for a computer
> that didn't have eight bit bytes.
>
> R's,
> John
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>

[David Walden]

I was not close to the C/70 project so I don't know.
We can find the right person to answer questions with a question to the ex-BBN list. In the meantime, I will look in the list of BBN reports.


On October 23, 2017, at 9:17 PM, Bernie Cosell <***@fantasyfarm.com> wrote:

> - Can you confirm that the C/70 indeed ran the TCP/IP stack?

I don't know. I expect it did

> - The advert says the C/60 was running V7 Unix, I assume this was true
> of the C/70 as well? Before now, I did not realise that the TCP/IP stack
> integrated with V7 as well.

That was the version of unix we had the sources for. There was no
floating point! After we got the system up and running I left the
project. I understand the next thing to be done was to add 'float' to
the compiler -- but this was all done locally on the C/70.

> - Would you at this remove still remember the main features of the C/70
> MMU? This detail is relevant to me as it has a connection to the
> evolution of network buffer management in Unix, and also to the
> organisation of network code in the kernel.

I have no idea -- Probably someone like Carl Howe would know that. I had
little to do with the kernel or the machinery.

> - How should I understand "There was never an assembler for the
> MBB-Unix”? If I read your notes correctly the compiler did not
> generate microcode, but instructions on a traditional instruction set
> architecture level.

Mostly it generated binary! There was a sort of 'traditional'
instruction set but it wasn't available outside the compiler. As I
mentioned, it was very irregular and wasn't designed to be "user
friendly" [or even "user comprehensible"]

> .. In that context, wouldn’t the last phase of the
> (native) compiler be an assembler of sorts? Wouldn’t you need some
> sort of assembler to write libraries for system calls, signal handling,
> making longjmp's, etc.?

Not really -- I don't remember how we managed that, but there was no
direct "assembly" code. In fact, the "instruction set" changed from time
to time as we hacked new things in. I expect some BBN report documented
the actual final MMB machinery but it wasn't publicized and other than
making a binary, basically, by hand there wasn't any way to code for the
machine other than in 'C'.

I don't remember how we handled user processes, memory handling, system
calls, etc. Dave: did we ever do a BBN report on the insides of the
C/70? I don't remember doing one.

/Bernie\

--
Bernie Cosell Fantasy Farm Fibers
mailto:***@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--




_______
internet-history mailing list
internet-***@postel.org
http://mailman.postel.org/mailman/listinfo/internet-history
Contact list-***@postel.org for assistance.

[James J Dempsey]

I used the C/70 as a user -- I was not involved in C-Machine development.
However, I feel I can answer some of these questions, so I'll give it a go.
I read internet-history in digest mode; it's highly possible someone more
authoritative than me will have already answered these questions.

David Walden <***@gmail.com> wrote:

> I was not close to the C/70 project so I don't know.
> We can find the right person to answer questions with a question to the ex-BBN list. In the meantime, I will look in the list of BBN reports.
>
> On October 23, 2017, at 9:17 PM, Bernie Cosell <***@fantasyfarm.com> wrote:
>
> > - Can you confirm that the C/70 indeed ran the TCP/IP stack?
>
> I don't know. I expect it did

The C/70 (as well as the C/60) definitely did have a TCP/IP stack. One of
the first uses of the C/70 was to build and run the NU Network Monitoring
system. When I arrived at BBN in the Summer of 1981, we were already on
track to transition ARPANET to TCP/IP, which as we know eventually happened
on 1 Jan 1983.

It was important that NU be able to monitor the ARPANET at that point
because the TENEX-based U program (which previously monitored and controlled
ARPANET) could not handle TCP. My memory is that some people thought NU was
not up to the task by this point, but it was certainly moot since many
aspects of the U program would not work after the transition.

> > - The advert says the C/60 was running V7 Unix, I assume this was true
> > of the C/70 as well? Before now, I did not realise that the TCP/IP stack
> > integrated with V7 as well.
>
> That was the version of unix we had the sources for.

Yes - I understand that this was a financial issue. BBN had a V7 source
license. If we wanted a newer UNIX license (System III was announced in
1981), the price for a source license was very expensive.

And really, most developers didn't want System III at that time anyway.
What we really wanted was BSD and the BSD license gave us access to those
sources as well. As a result, BBN-UNIX (as it was called) had many BSDisms
and looked (in many, but not all ways) a lot like BSD. Certainly, the csh
shell was there, though I'm pretty certain the TCP stack was BBN's, not BSDs.

I still have a button from a conference or show that says "I <heart>
BBN-UNIX, supported by BBN Computer". I was told that the big deal was that
BBN actually had commercial support for UNIX which was rare or non-existent
for a computer manufacturer at the time.

You can see that button (and some others) here:
http://serenity.jjd.com/Images/bbn-buttons.jpg

> > - Would you at this remove still remember the main features of the C/70
> > MMU? This detail is relevant to me as it has a connection to the
> > evolution of network buffer management in Unix, and also to the
> > organisation of network code in the kernel.
>
> I have no idea -- Probably someone like Carl Howe would know that. I had
> little to do with the kernel or the machinery.

The final nail in the coffin of the C-series machines as competitive UNIX
computers was the fact that there was no virtual memory. I believe the max
RAM a C/70 could have was 2-megabytes. That was substantially more than the
PDP-11s we had available, but really not competive with the DEC VAX series.

The VAX didn't exist at the time the MBB was first designed, but it was
available by the time the C/70 with BBN-UNIX was first sold.

We probably had about 10-15 developers assigned to a C/70 development
machine and it wasn't too bad until you used certain "memory hungry"
applications. At the time most BBN developers used the in-house screen
editor called Pen, but I preferred Gosling Emacs. Launching Gosling emacs
on a multi-user C/70 took literally minutes. As a result, I'd start it in
the morning and leave it running all day. I'm not sure BBN-UNIX originally
had job-control, but it soon did. Plus, you could use the BBN BitGraph
terminal's clever window manager (author Dave Mankins) to have one window
running emacs and others for shells.

Several C-Machine anecdotes:

The typical mass storage in a C/70 was a winchester-type hard disk of some
sort, about 14" in diameter. I believe the canonical capacity at first was
80-megabytes and you could put two of them in the rack with the computer.
They were in drawers underneath the CPU. The problem was that if you pulled
out both drawers at the same time, the machine would tip over on top of you.
One of the solutions for this was an ECO that was named something on the
order of "ECO-PB" because it consisted of two lead bricks you would place in
the base of the rack to re-balance it to avoid tipping!

For the most part the C/70 and the C/60 were identical, but the C/60 had a
slower clock. If you had bought a C/60, you could subsequently buy a "C/70
upgrade" which consisted of a BBN support person coming to your site and
merely either cutting the right wire or replacing the clock chip. (I can't
remember which.)

Early in my career (and early in the life of BBN-UNIX) I was writing some
shell script and while I was debugging it, the machine crashed. This was
tedious because it took something like 15-20 minutes to reboot. Once it was
up, I continued my debugging where I left off and the machine crashed
again. While it was coming up, I speculated whether my shell script could
be crashing the machine. Of course, when it was up I had to test this
theory by running the script a third time, causing the machine to crash
again. I was previously skeptical that a shell script could crash a
machine! Let me tell you, the other developers on that machine weren't
happy with me that day.

The NU system for monitoring the ARPANET (and the ARPANET itself) eventually
got large enough that the C/70 started running low on memory causing it to
be very slow. I had been advocating porting the entire NU system to a VAX
running BSD to get more address space. This fell mostly on deaf ears
because BBN made good money selling C/70 systems for managing our clients'
packet networks. Eventually someone (Jim Herman? John Sax?) came to me and
asked me to estimate how much effort it would take to port NU to BSD. He
and I talked about it for half an hour or so and I came up with a number.
(Please remember this was quite early in my career!) Whoever it was said
"Good. Thank you. Eric Rosen told me to come and ask you for your estimate
and then multiply the answer by ten."

--Jim Dempsey--

[Paul Ruizendaal]

> On 24 Oct 2017, at 20:52, James J Dempsey <***@jjd.com> wrote:
>
> The C/70 (as well as the C/60) definitely did have a TCP/IP stack. One of
> the first uses of the C/70 was to build and run the NU Network Monitoring
> system. When I arrived at BBN in the Summer of 1981, we were already on
> track to transition ARPANET to TCP/IP, which as we know eventually happened
> on 1 Jan 1983.
>
> It was important that NU be able to monitor the ARPANET at that point
> because the TENEX-based U program (which previously monitored and controlled
> ARPANET) could not handle TCP. My memory is that some people thought NU was
> not up to the task by this point, but it was certainly moot since many
> aspects of the U program would not work after the transition.

Thanks for confirming that. Would you recall if the C/70 used the sockets API
or the earlier arpanet API? (I would suspect the latter).

If the former, it would be the only back port of sockets to V7 that I’m
aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).

> The final nail in the coffin of the C-series machines as competitive UNIX
> computers was the fact that there was no virtual memory. I believe the max
> RAM a C/70 could have was 2-megabytes. That was substantially more than the
> PDP-11s we had available, but really not competive with the DEC VAX series.

Yes: the C/60 ad also says maximum 2 MB of real memory.

With 20 bit addresses and byte addressing, logical address space is 1 MB. That
suggests that the C/70 must have had some sort of address translation (and
probably some sort of memory protection as well).

[James J Dempsey]

Paul Ruizendaal <***@planet.nl> wrote:

> > On 24 Oct 2017, at 20:52, James J Dempsey <***@jjd.com> wrote:
> >
> > The C/70 (as well as the C/60) definitely did have a TCP/IP stack. One of
> > the first uses of the C/70 was to build and run the NU Network Monitoring
> > system. When I arrived at BBN in the Summer of 1981, we were already on
> > track to transition ARPANET to TCP/IP, which as we know eventually happened
> > on 1 Jan 1983.
>
> Thanks for confirming that. Would you recall if the C/70 used the sockets API
> or the earlier arpanet API? (I would suspect the latter).
>
> If the former, it would be the only back port of sockets to V7 that I?m
> aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).

If you check out RFC 801 (written Nov 1981), Rob Gurwitz (who wrote BBN's
UNIX TCP implementation) says of "BBN C70 UNIX":

The C/70 processor is a BBN-designed system with a native
instruction set oriented toward executing the C language. It
supports UNIX Version 7 and provides for user processes with a
20-bit address space. The TCP/IP implementation for the C/70 was
ported from the BBN VAX TCP/IP, and shares all of its features.

This version of TCP/IP is running experimentally at BBN, but is
still under development. Performance tuning is underway, to make
it more compatible with the C/70's memory management system.

In the same RFC, Rob writes of the BBN VAX UNIX TCP implementation:

The VAX TCP/IP implementation is written in C for Berkeley 4.1BSD
UNIX, and runs in the UNIX kernel. It has been run on VAX 11/780s
and 750s at several sites, and is due to be generally available in
early 1982.

The implementation conforms to the TCP and IP specifications (RFC
791, 793). The implementation supports the new extended internet
address formats, and both GGP and ICMP. It also supports multiple
network access protocols and device drivers. Aside from ARPANET
1822 and the ACC LH/DH-11 driver, experimental drivers have also
been developed for ETHERNET. There are user interfaces for
accessing the IP and local network access layers independent of
the TCP.

Higher level protocol services include user and server TELNET,
MTP, and FTP, implemented as user level programs. There are also
tools available for monitoring and recording network traffic for
debugging purposes.

Continuing development includes performance enhancements. The
implementation is described in IEN-168.

IEN-168 (available here https://www.rfc-editor.org/ien/ien168.txt ) does not
contain the word "socket", so I suspect that that means the BBN-UNIX
implementation of TCP didn't contains the socket interface, initially.

In "Networking Implementation Notes 4.4BSD Edition" (
https://docs.freebsd.org/44doc/smm/18.net/paper.pdf ) Sam Leffler and Bill
Joy acknowledge the BBN TCP/IP implementation:

Many of the ideas related to protocol modularity, memory management, and
network interfaces are based on Rob Gurwitz’s TCP/IP implementation for the
4.1BSD version of UNIX on the VAX [Gurwitz81].

[Gurwitz81] is IEN-168.

Finally, at http://www.xbbn.org/note-12.html there is this description of
sockets and BBN's TCP implementation:

The BBN BSD TCP was the standard TCP for 4BSD and BSD UNIX 4.1. However, in
BSD 4.2, the team at U.C. Berkeley created their own and very different
implementation of TCP/IP (using the now familiar socket interface developed
by Bill Joy and Sam Leffler of Berkeley along with Gurwitz). BBN promptly
revised its TCP implementation to use the socket interface, and for about a
year there was a battle to determine whose networking code would take
precedence. Although the BBN code won some adherents, and was licensed to
several computer vendors, the Berkeley code won the battle.

I hope this clears that up.

--Jim Dempsey--

[Jack Haverty]

The history of TCP implementations was driven by non-technical forces
too. As the saying goes -- "Follow the money."

ARPA paid for the development of most if not all of the very early TCP
implementations: the BBN-TENEX and LSI-11 for the Packet Radio project,
my own PDP-11/40 Unix implementation as part of a Network Security
research program, Sax/Edmond's HP-3000 code, Braden's IBM work at UCLA,
Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax
implementation. Probably more I've forgotten. Wingfield's PDP-11/70
was funded, IIRC, by DCEC, the research arm of DCA - so it represented a
tiny step from the research/ARPA world into the operational side.

ARPA also paid for development of OSes, in particular BSD. As the TCP
implementations were completed, ARPA stopped funding further
TCP-specific work, and, also IIRC, made those baseline implementations
generally available. Berkeley continued BSD with ARPA funds, which
evolved into Sun. Big government contractors (motivated by the
contractual requirement to support TCP) built TCPs as they needed.

Note also that the "await/capac" Unix interface was created by Randy
Rettberg and I to be the minimal functionality, with absolute minimal
kernel code footprint, that we knew was needed to be able to write
network applications - ftp, telnet, etc. The goal was to cram it into
the PDP-11/40, not to make a definitive interface for general Unix use.
So it's not surprising that sockets took over.

Also, someone commented that it would have been possible to do
networking with standard Unix primitives at the time, by having multiple
processes interacting. We actually tried that. More accurately, Ray
Tomlinson (yes the same one) ported a network security application that
had been running on BBN-TENEX into a Unix implementation with a dozen or
so interacting processes. With all of the context switching it was so
slow that it was totally unusable. Plan B was await/capac to make it
possible to use a single Unix process instead.

Hardware vendors built TCPs too, such as the C/70. IIRC, the C/70
development for network management was partially funded by DCA, so that
would have provided support for TCP development too.

Startups popped up to fill gaps. Microsoft was a tad late to the party,
and a slew of small companies created TCPs for DOS/Windows. I recall
circa 1990 we had to deal with testing our software using 30+ different
TCP implementations for Windows that were then in common use.

Historians may find DNA traces of some of those baseline 1980-ish
implementations in the later systems. My gut feeling is that the
choices that were made were not necessarily driven much by technical
evaluations, but more often by pragmatic considerations - availability
of code, or of personnel with relevant experience.

So, when you seek to unravel the history of TCP (and the Internet), I'd
suggest also following the trails of the money, the people, as well as
the software to understand why things happened the way they did. That
won't be easy...

HTH,
/Jack

On 10/25/2017 08:27 AM, James J Dempsey wrote:
> Paul Ruizendaal <***@planet.nl> wrote:
>
>>> On 24 Oct 2017, at 20:52, James J Dempsey <***@jjd.com> wrote:
>>>
>>> The C/70 (as well as the C/60) definitely did have a TCP/IP stack. One of
>>> the first uses of the C/70 was to build and run the NU Network Monitoring
>>> system. When I arrived at BBN in the Summer of 1981, we were already on
>>> track to transition ARPANET to TCP/IP, which as we know eventually happened
>>> on 1 Jan 1983.
>>
>> Thanks for confirming that. Would you recall if the C/70 used the sockets API
>> or the earlier arpanet API? (I would suspect the latter).
>>
>> If the former, it would be the only back port of sockets to V7 that I?m
>> aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).
>
> If you check out RFC 801 (written Nov 1981), Rob Gurwitz (who wrote BBN's
> UNIX TCP implementation) says of "BBN C70 UNIX":
>
> The C/70 processor is a BBN-designed system with a native
> instruction set oriented toward executing the C language. It
> supports UNIX Version 7 and provides for user processes with a
> 20-bit address space. The TCP/IP implementation for the C/70 was
> ported from the BBN VAX TCP/IP, and shares all of its features.
>
> This version of TCP/IP is running experimentally at BBN, but is
> still under development. Performance tuning is underway, to make
> it more compatible with the C/70's memory management system.
>
> In the same RFC, Rob writes of the BBN VAX UNIX TCP implementation:
>
> The VAX TCP/IP implementation is written in C for Berkeley 4.1BSD
> UNIX, and runs in the UNIX kernel. It has been run on VAX 11/780s
> and 750s at several sites, and is due to be generally available in
> early 1982.
>
> The implementation conforms to the TCP and IP specifications (RFC
> 791, 793). The implementation supports the new extended internet
> address formats, and both GGP and ICMP. It also supports multiple
> network access protocols and device drivers. Aside from ARPANET
> 1822 and the ACC LH/DH-11 driver, experimental drivers have also
> been developed for ETHERNET. There are user interfaces for
> accessing the IP and local network access layers independent of
> the TCP.
>
> Higher level protocol services include user and server TELNET,
> MTP, and FTP, implemented as user level programs. There are also
> tools available for monitoring and recording network traffic for
> debugging purposes.
>
> Continuing development includes performance enhancements. The
> implementation is described in IEN-168.
>
> IEN-168 (available here https://www.rfc-editor.org/ien/ien168.txt ) does not
> contain the word "socket", so I suspect that that means the BBN-UNIX
> implementation of TCP didn't contains the socket interface, initially.
>
> In "Networking Implementation Notes 4.4BSD Edition" (
> https://docs.freebsd.org/44doc/smm/18.net/paper.pdf ) Sam Leffler and Bill
> Joy acknowledge the BBN TCP/IP implementation:
>
> Many of the ideas related to protocol modularity, memory management, and
> network interfaces are based on Rob Gurwitz’s TCP/IP implementation for the
> 4.1BSD version of UNIX on the VAX [Gurwitz81].
>
> [Gurwitz81] is IEN-168.
>
> Finally, at http://www.xbbn.org/note-12.html there is this description of
> sockets and BBN's TCP implementation:
>
> The BBN BSD TCP was the standard TCP for 4BSD and BSD UNIX 4.1. However, in
> BSD 4.2, the team at U.C. Berkeley created their own and very different
> implementation of TCP/IP (using the now familiar socket interface developed
> by Bill Joy and Sam Leffler of Berkeley along with Gurwitz). BBN promptly
> revised its TCP implementation to use the socket interface, and for about a
> year there was a battle to determine whose networking code would take
> precedence. Although the BBN code won some adherents, and was licensed to
> several computer vendors, the Berkeley code won the battle.
>
> I hope this clears that up.
>
> --Jim Dempsey--
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>

[Miles Fidelman]

On 10/25/17 2:27 PM, Jack Haverty wrote:

> The history of TCP implementations was driven by non-technical forces
> too. As the saying goes -- "Follow the money."
>
> <snip>
>
> Startups popped up to fill gaps. Microsoft was a tad late to the party,
> and a slew of small companies created TCPs for DOS/Windows. I recall
> circa 1990 we had to deal with testing our software using 30+ different
> TCP implementations for Windows that were then in common use.

Wang was even later.  As I recall, they went from being the Army's
primary computer vendor, to out-the-door, because they kept dragging
their heels on implementing TCP/IP.

Miles

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

[Dave Crocker]

On 10/25/2017 12:11 PM, Miles Fidelman wrote:
> Wang was even later.  As I recall, they went from being the Army's
> primary computer vendor, to out-the-door, because they kept dragging
> their heels on implementing TCP/IP.


While at the unfortunate Wollongong -- circa 1987-1988 -- we had a
really terrible meeting with Wang, trying to sell him our rather nice PC
TCP stack. He was counter-productive even before the meeting started,
and things only got worse from there.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

[Vint Cerf]

FTP Software - TCP/IP for DOS/Windows - went belly up with Microsoft
integrated this into a version of their OS.

IBM, DEC and HP did implementations in the research labs without charge to
DARPA.

v


On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty <***@3kitty.org> wrote:

> The history of TCP implementations was driven by non-technical forces
> too. As the saying goes -- "Follow the money."
>
> ARPA paid for the development of most if not all of the very early TCP
> implementations: the BBN-TENEX and LSI-11 for the Packet Radio project,
> my own PDP-11/40 Unix implementation as part of a Network Security
> research program, Sax/Edmond's HP-3000 code, Braden's IBM work at UCLA,
> Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax
> implementation. Probably more I've forgotten. Wingfield's PDP-11/70
> was funded, IIRC, by DCEC, the research arm of DCA - so it represented a
> tiny step from the research/ARPA world into the operational side.
>
> ARPA also paid for development of OSes, in particular BSD. As the TCP
> implementations were completed, ARPA stopped funding further
> TCP-specific work, and, also IIRC, made those baseline implementations
> generally available. Berkeley continued BSD with ARPA funds, which
> evolved into Sun. Big government contractors (motivated by the
> contractual requirement to support TCP) built TCPs as they needed.
>
> Note also that the "await/capac" Unix interface was created by Randy
> Rettberg and I to be the minimal functionality, with absolute minimal
> kernel code footprint, that we knew was needed to be able to write
> network applications - ftp, telnet, etc. The goal was to cram it into
> the PDP-11/40, not to make a definitive interface for general Unix use.
> So it's not surprising that sockets took over.
>
> Also, someone commented that it would have been possible to do
> networking with standard Unix primitives at the time, by having multiple
> processes interacting. We actually tried that. More accurately, Ray
> Tomlinson (yes the same one) ported a network security application that
> had been running on BBN-TENEX into a Unix implementation with a dozen or
> so interacting processes. With all of the context switching it was so
> slow that it was totally unusable. Plan B was await/capac to make it
> possible to use a single Unix process instead.
>
> Hardware vendors built TCPs too, such as the C/70. IIRC, the C/70
> development for network management was partially funded by DCA, so that
> would have provided support for TCP development too.
>
> Startups popped up to fill gaps. Microsoft was a tad late to the party,
> and a slew of small companies created TCPs for DOS/Windows. I recall
> circa 1990 we had to deal with testing our software using 30+ different
> TCP implementations for Windows that were then in common use.
>
> Historians may find DNA traces of some of those baseline 1980-ish
> implementations in the later systems. My gut feeling is that the
> choices that were made were not necessarily driven much by technical
> evaluations, but more often by pragmatic considerations - availability
> of code, or of personnel with relevant experience.
>
> So, when you seek to unravel the history of TCP (and the Internet), I'd
> suggest also following the trails of the money, the people, as well as
> the software to understand why things happened the way they did. That
> won't be easy...
>
> HTH,
> /Jack
>
> On 10/25/2017 08:27 AM, James J Dempsey wrote:
> > Paul Ruizendaal <***@planet.nl> wrote:
> >
> >>> On 24 Oct 2017, at 20:52, James J Dempsey <***@jjd.com> wrote:
> >>>
> >>> The C/70 (as well as the C/60) definitely did have a TCP/IP stack.
> One of
> >>> the first uses of the C/70 was to build and run the NU Network
> Monitoring
> >>> system. When I arrived at BBN in the Summer of 1981, we were already
> on
> >>> track to transition ARPANET to TCP/IP, which as we know eventually
> happened
> >>> on 1 Jan 1983.
> >>
> >> Thanks for confirming that. Would you recall if the C/70 used the
> sockets API
> >> or the earlier arpanet API? (I would suspect the latter).
> >>
> >> If the former, it would be the only back port of sockets to V7 that I?m
> >> aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).
> >
> > If you check out RFC 801 (written Nov 1981), Rob Gurwitz (who wrote BBN's
> > UNIX TCP implementation) says of "BBN C70 UNIX":
> >
> > The C/70 processor is a BBN-designed system with a native
> > instruction set oriented toward executing the C language. It
> > supports UNIX Version 7 and provides for user processes with a
> > 20-bit address space. The TCP/IP implementation for the C/70 was
> > ported from the BBN VAX TCP/IP, and shares all of its features.
> >
> > This version of TCP/IP is running experimentally at BBN, but is
> > still under development. Performance tuning is underway, to make
> > it more compatible with the C/70's memory management system.
> >
> > In the same RFC, Rob writes of the BBN VAX UNIX TCP implementation:
> >
> > The VAX TCP/IP implementation is written in C for Berkeley 4.1BSD
> > UNIX, and runs in the UNIX kernel. It has been run on VAX 11/780s
> > and 750s at several sites, and is due to be generally available in
> > early 1982.
> >
> > The implementation conforms to the TCP and IP specifications (RFC
> > 791, 793). The implementation supports the new extended internet
> > address formats, and both GGP and ICMP. It also supports multiple
> > network access protocols and device drivers. Aside from ARPANET
> > 1822 and the ACC LH/DH-11 driver, experimental drivers have also
> > been developed for ETHERNET. There are user interfaces for
> > accessing the IP and local network access layers independent of
> > the TCP.
> >
> > Higher level protocol services include user and server TELNET,
> > MTP, and FTP, implemented as user level programs. There are also
> > tools available for monitoring and recording network traffic for
> > debugging purposes.
> >
> > Continuing development includes performance enhancements. The
> > implementation is described in IEN-168.
> >
> > IEN-168 (available here https://www.rfc-editor.org/ien/ien168.txt )
> does not
> > contain the word "socket", so I suspect that that means the BBN-UNIX
> > implementation of TCP didn't contains the socket interface, initially.
> >
> > In "Networking Implementation Notes 4.4BSD Edition" (
> > https://docs.freebsd.org/44doc/smm/18.net/paper.pdf ) Sam Leffler and
> Bill
> > Joy acknowledge the BBN TCP/IP implementation:
> >
> > Many of the ideas related to protocol modularity, memory management,
> and
> > network interfaces are based on Rob Gurwitz’s TCP/IP implementation
> for the
> > 4.1BSD version of UNIX on the VAX [Gurwitz81].
> >
> > [Gurwitz81] is IEN-168.
> >
> > Finally, at http://www.xbbn.org/note-12.html there is this description
> of
> > sockets and BBN's TCP implementation:
> >
> > The BBN BSD TCP was the standard TCP for 4BSD and BSD UNIX 4.1.
> However, in
> > BSD 4.2, the team at U.C. Berkeley created their own and very
> different
> > implementation of TCP/IP (using the now familiar socket interface
> developed
> > by Bill Joy and Sam Leffler of Berkeley along with Gurwitz). BBN
> promptly
> > revised its TCP implementation to use the socket interface, and
> for about a
> > year there was a battle to determine whose networking code would
> take
> > precedence. Although the BBN code won some adherents, and was
> licensed to
> > several computer vendors, the Berkeley code won the battle.
> >
> > I hope this clears that up.
> >
> > --Jim Dempsey--
> >
> > _______
> > internet-history mailing list
> > internet-***@postel.org
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > Contact list-***@postel.org for assistance.
> >
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>



--
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190

[Vint Cerf]

sorry "when" Microsoft not "with" ....duh

v


On Wed, Oct 25, 2017 at 3:27 PM, Vint Cerf <***@google.com> wrote:

> FTP Software - TCP/IP for DOS/Windows - went belly up with Microsoft
> integrated this into a version of their OS.
>
> IBM, DEC and HP did implementations in the research labs without charge to
> DARPA.
>
> v
>
>
> On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty <***@3kitty.org> wrote:
>
>> The history of TCP implementations was driven by non-technical forces
>> too. As the saying goes -- "Follow the money."
>>
>> ARPA paid for the development of most if not all of the very early TCP
>> implementations: the BBN-TENEX and LSI-11 for the Packet Radio project,
>> my own PDP-11/40 Unix implementation as part of a Network Security
>> research program, Sax/Edmond's HP-3000 code, Braden's IBM work at UCLA,
>> Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax
>> implementation. Probably more I've forgotten. Wingfield's PDP-11/70
>> was funded, IIRC, by DCEC, the research arm of DCA - so it represented a
>> tiny step from the research/ARPA world into the operational side.
>>
>> ARPA also paid for development of OSes, in particular BSD. As the TCP
>> implementations were completed, ARPA stopped funding further
>> TCP-specific work, and, also IIRC, made those baseline implementations
>> generally available. Berkeley continued BSD with ARPA funds, which
>> evolved into Sun. Big government contractors (motivated by the
>> contractual requirement to support TCP) built TCPs as they needed.
>>
>> Note also that the "await/capac" Unix interface was created by Randy
>> Rettberg and I to be the minimal functionality, with absolute minimal
>> kernel code footprint, that we knew was needed to be able to write
>> network applications - ftp, telnet, etc. The goal was to cram it into
>> the PDP-11/40, not to make a definitive interface for general Unix use.
>> So it's not surprising that sockets took over.
>>
>> Also, someone commented that it would have been possible to do
>> networking with standard Unix primitives at the time, by having multiple
>> processes interacting. We actually tried that. More accurately, Ray
>> Tomlinson (yes the same one) ported a network security application that
>> had been running on BBN-TENEX into a Unix implementation with a dozen or
>> so interacting processes. With all of the context switching it was so
>> slow that it was totally unusable. Plan B was await/capac to make it
>> possible to use a single Unix process instead.
>>
>> Hardware vendors built TCPs too, such as the C/70. IIRC, the C/70
>> development for network management was partially funded by DCA, so that
>> would have provided support for TCP development too.
>>
>> Startups popped up to fill gaps. Microsoft was a tad late to the party,
>> and a slew of small companies created TCPs for DOS/Windows. I recall
>> circa 1990 we had to deal with testing our software using 30+ different
>> TCP implementations for Windows that were then in common use.
>>
>> Historians may find DNA traces of some of those baseline 1980-ish
>> implementations in the later systems. My gut feeling is that the
>> choices that were made were not necessarily driven much by technical
>> evaluations, but more often by pragmatic considerations - availability
>> of code, or of personnel with relevant experience.
>>
>> So, when you seek to unravel the history of TCP (and the Internet), I'd
>> suggest also following the trails of the money, the people, as well as
>> the software to understand why things happened the way they did. That
>> won't be easy...
>>
>> HTH,
>> /Jack
>>
>> On 10/25/2017 08:27 AM, James J Dempsey wrote:
>> > Paul Ruizendaal <***@planet.nl> wrote:
>> >
>> >>> On 24 Oct 2017, at 20:52, James J Dempsey <***@jjd.com> wrote:
>> >>>
>> >>> The C/70 (as well as the C/60) definitely did have a TCP/IP stack.
>> One of
>> >>> the first uses of the C/70 was to build and run the NU Network
>> Monitoring
>> >>> system. When I arrived at BBN in the Summer of 1981, we were already
>> on
>> >>> track to transition ARPANET to TCP/IP, which as we know eventually
>> happened
>> >>> on 1 Jan 1983.
>> >>
>> >> Thanks for confirming that. Would you recall if the C/70 used the
>> sockets API
>> >> or the earlier arpanet API? (I would suspect the latter).
>> >>
>> >> If the former, it would be the only back port of sockets to V7 that I?m
>> >> aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).
>> >
>> > If you check out RFC 801 (written Nov 1981), Rob Gurwitz (who wrote
>> BBN's
>> > UNIX TCP implementation) says of "BBN C70 UNIX":
>> >
>> > The C/70 processor is a BBN-designed system with a native
>> > instruction set oriented toward executing the C language. It
>> > supports UNIX Version 7 and provides for user processes with a
>> > 20-bit address space. The TCP/IP implementation for the C/70 was
>> > ported from the BBN VAX TCP/IP, and shares all of its features.
>> >
>> > This version of TCP/IP is running experimentally at BBN, but is
>> > still under development. Performance tuning is underway, to make
>> > it more compatible with the C/70's memory management system.
>> >
>> > In the same RFC, Rob writes of the BBN VAX UNIX TCP implementation:
>> >
>> > The VAX TCP/IP implementation is written in C for Berkeley 4.1BSD
>> > UNIX, and runs in the UNIX kernel. It has been run on VAX 11/780s
>> > and 750s at several sites, and is due to be generally available in
>> > early 1982.
>> >
>> > The implementation conforms to the TCP and IP specifications (RFC
>> > 791, 793). The implementation supports the new extended internet
>> > address formats, and both GGP and ICMP. It also supports multiple
>> > network access protocols and device drivers. Aside from ARPANET
>> > 1822 and the ACC LH/DH-11 driver, experimental drivers have also
>> > been developed for ETHERNET. There are user interfaces for
>> > accessing the IP and local network access layers independent of
>> > the TCP.
>> >
>> > Higher level protocol services include user and server TELNET,
>> > MTP, and FTP, implemented as user level programs. There are also
>> > tools available for monitoring and recording network traffic for
>> > debugging purposes.
>> >
>> > Continuing development includes performance enhancements. The
>> > implementation is described in IEN-168.
>> >
>> > IEN-168 (available here https://www.rfc-editor.org/ien/ien168.txt )
>> does not
>> > contain the word "socket", so I suspect that that means the BBN-UNIX
>> > implementation of TCP didn't contains the socket interface, initially.
>> >
>> > In "Networking Implementation Notes 4.4BSD Edition" (
>> > https://docs.freebsd.org/44doc/smm/18.net/paper.pdf ) Sam Leffler and
>> Bill
>> > Joy acknowledge the BBN TCP/IP implementation:
>> >
>> > Many of the ideas related to protocol modularity, memory
>> management, and
>> > network interfaces are based on Rob Gurwitz’s TCP/IP implementation
>> for the
>> > 4.1BSD version of UNIX on the VAX [Gurwitz81].
>> >
>> > [Gurwitz81] is IEN-168.
>> >
>> > Finally, at http://www.xbbn.org/note-12.html there is this description
>> of
>> > sockets and BBN's TCP implementation:
>> >
>> > The BBN BSD TCP was the standard TCP for 4BSD and BSD UNIX 4.1.
>> However, in
>> > BSD 4.2, the team at U.C. Berkeley created their own and very
>> different
>> > implementation of TCP/IP (using the now familiar socket interface
>> developed
>> > by Bill Joy and Sam Leffler of Berkeley along with Gurwitz). BBN
>> promptly
>> > revised its TCP implementation to use the socket interface, and
>> for about a
>> > year there was a battle to determine whose networking code would
>> take
>> > precedence. Although the BBN code won some adherents, and was
>> licensed to
>> > several computer vendors, the Berkeley code won the battle.
>> >
>> > I hope this clears that up.
>> >
>> > --Jim Dempsey--
>> >
>> > _______
>> > internet-history mailing list
>> > internet-***@postel.org
>> > http://mailman.postel.org/mailman/listinfo/internet-history
>> > Contact list-***@postel.org for assistance.
>> >
>> _______
>> internet-history mailing list
>> internet-***@postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-***@postel.org for assistance.
>>
>
>
>
> --
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> Reston, VA 20190
>



--
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190

[Jack Haverty]

I've always been curious about the ways, other than technical committees
as documented in RFCs et al, that Internet history was driven.

E.G., did the DEC/IBM/HP implementations in their respective labs use
any of the code developed by ARPA for their machines? Recruit the
people? Or did they start from the spec? Did the 30+ vendors of
DOS/Windows TCP products spring from the work by Jim Mathis, Dave Mills,
et al?

There was a lot of talk back then about "Technology Transfer" as a
government goal - basically saying that the government didn't want to
fund development forever. Just wondering how that worked out... Did
TCP/IP spread because the availability of free code enabled it? Or
because the people moved from the research to product worlds and brought
the knowledge (and code) with them?

I'm sure some of this happened. Maybe some historian will tackle the
problem of uncovering the various paths and timing that people and code
took over the early decade or so. And how important that was to how
things turned out.

/Jack

On 10/25/2017 12:28 PM, Vint Cerf wrote:
> sorry "when" Microsoft not "with" ....duh
>
> v
>
>
> On Wed, Oct 25, 2017 at 3:27 PM, Vint Cerf <***@google.com
> <mailto:***@google.com>> wrote:
>
> FTP Software - TCP/IP for DOS/Windows - went belly up with Microsoft
> integrated this into a version of their OS.
>
> IBM, DEC and HP did implementations in the research labs without
> charge to DARPA.
>
> v
>
>
> On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty <***@3kitty.org
> <mailto:***@3kitty.org>> wrote:
>
> The history of TCP implementations was driven by non-technical
> forces
> too.  As the saying goes -- "Follow the money."
>
> ARPA paid for the development of most if not all of the very
> early TCP
> implementations: the BBN-TENEX and LSI-11 for the Packet Radio
> project,
> my own PDP-11/40 Unix implementation as part of a Network Security
> research program, Sax/Edmond's HP-3000 code, Braden's IBM work
> at UCLA,
> Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax
> implementation.  Probably more I've forgotten.  Wingfield's
> PDP-11/70
> was funded, IIRC, by DCEC, the research arm of DCA - so it
> represented a
> tiny step from the research/ARPA world into the operational side.
>
> ARPA also paid for development of OSes, in particular BSD.  As
> the TCP
> implementations were completed, ARPA stopped funding further
> TCP-specific work, and, also IIRC, made those baseline
> implementations
> generally available.  Berkeley continued BSD with ARPA funds, which
> evolved into Sun.  Big government contractors (motivated by the
> contractual requirement to support TCP) built TCPs as they needed.
>
> Note also that the "await/capac" Unix interface was created by Randy
> Rettberg and I to be the minimal functionality, with absolute
> minimal
> kernel code footprint, that we knew was needed to be able to write
> network applications - ftp, telnet, etc.  The goal was to cram
> it into
> the PDP-11/40, not to make a definitive interface for general
> Unix use.
> So it's not surprising that sockets took over.
>
> Also, someone commented that it would have been possible to do
> networking with standard Unix primitives at the time, by having
> multiple
> processes interacting.  We actually tried that.  More
> accurately, Ray
> Tomlinson (yes the same one) ported a network security
> application that
> had been running on BBN-TENEX into a Unix implementation with a
> dozen or
> so interacting processes.  With all of the context switching it
> was so
> slow that it was totally unusable.  Plan B was await/capac to
> make it
> possible to use a single Unix process instead.
>
> Hardware vendors built TCPs too, such as the C/70.  IIRC, the C/70
> development for network management was partially funded by DCA,
> so that
> would have provided support for TCP development too.
>
> Startups popped up to fill gaps.  Microsoft was a tad late to
> the party,
> and a slew of small companies created TCPs for DOS/Windows.  I
> recall
> circa 1990 we had to deal with testing our software using 30+
> different
> TCP implementations for Windows that were then in common use.
>
> Historians may find DNA traces of some of those baseline 1980-ish
> implementations in the later systems.  My gut feeling is that the
> choices that were made were not necessarily driven much by technical
> evaluations, but more often by pragmatic considerations -
> availability
> of code, or of personnel with relevant experience.
>
> So, when you seek to unravel the history of TCP (and the
> Internet), I'd
> suggest also following the trails of the money, the people, as
> well as
> the software to understand why things happened the way they
> did.  That
> won't be easy...
>
> HTH,
> /Jack
>
> On 10/25/2017 08:27 AM, James J Dempsey wrote:
> > Paul Ruizendaal <***@planet.nl <mailto:***@planet.nl>> wrote:
> >
> >>> On 24 Oct 2017, at 20:52, James J Dempsey <***@jjd.com
> <mailto:***@jjd.com>> wrote:
> >>>
> >>> The C/70 (as well as the C/60) definitely did have a TCP/IP
> stack.  One of
> >>> the first uses of the C/70 was to build and run the NU
> Network Monitoring
> >>> system.  When I arrived at BBN in the Summer of 1981, we
> were already on
> >>> track to transition ARPANET to TCP/IP, which as we know
> eventually happened
> >>> on 1 Jan 1983.
> >>
> >> Thanks for confirming that. Would you recall if the C/70 used
> the sockets API
> >> or the earlier arpanet API? (I would suspect the latter).
> >>
> >> If the former, it would be the only back port of sockets to
> V7 that I?m
> >> aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).
> >
> > If you check out RFC 801 (written Nov 1981), Rob Gurwitz (who
> wrote BBN's
> > UNIX TCP implementation) says of "BBN C70 UNIX":
> >
> >       The C/70 processor is a BBN-designed system with a native
> >       instruction set oriented toward executing the C
> language.  It
> >       supports UNIX Version 7 and provides for user processes
> with a
> >       20-bit address space.  The TCP/IP implementation for the
> C/70 was
> >       ported from the BBN VAX TCP/IP, and shares all of its
> features.
> >
> >       This version of TCP/IP is running experimentally at BBN,
> but is
> >       still under development.  Performance tuning is
> underway, to make
> >       it more compatible with the C/70's memory management system.
> >
> > In the same RFC, Rob writes of the BBN VAX UNIX TCP
> implementation:
> >
> >       The VAX TCP/IP implementation is written in C for
> Berkeley 4.1BSD
> >       UNIX, and runs in the UNIX kernel.  It has been run on
> VAX 11/780s
> >       and 750s at several sites, and is due to be generally
> available in
> >       early 1982.
> >
> >       The implementation conforms to the TCP and IP
> specifications (RFC
> >       791, 793).  The implementation supports the new extended
> internet
> >       address formats, and both GGP and ICMP.  It also
> supports multiple
> >       network access protocols and device drivers.  Aside from
> ARPANET
> >       1822 and the ACC LH/DH-11 driver, experimental drivers
> have also
> >       been developed for ETHERNET.  There are user interfaces for
> >       accessing the IP and local network access layers
> independent of
> >       the TCP.
> >
> >       Higher level protocol services include user and server
> TELNET,
> >       MTP, and FTP, implemented as user level programs.  There
> are also
> >       tools available for monitoring and recording network
> traffic for
> >       debugging purposes.
> >
> >       Continuing development includes performance
> enhancements.  The
> >       implementation is described in IEN-168.
> >
> > IEN-168 (available here
> https://www.rfc-editor.org/ien/ien168.txt
> <https://www.rfc-editor.org/ien/ien168.txt> ) does not
> > contain the word "socket", so I suspect that that means the
> BBN-UNIX
> > implementation of TCP didn't contains the socket interface,
> initially.
> >
> > In "Networking Implementation Notes 4.4BSD Edition" (
> > https://docs.freebsd.org/44doc/smm/18.net/paper.pdf
> <https://docs.freebsd.org/44doc/smm/18.net/paper.pdf> ) Sam
> Leffler and Bill
> > Joy acknowledge the BBN TCP/IP implementation:
> >
> >     Many of the ideas related to protocol modularity, memory
> management, and
> >     network interfaces are based on Rob Gurwitz’s TCP/IP
> implementation for the
> >     4.1BSD version of UNIX on the VAX [Gurwitz81].
> >
> > [Gurwitz81] is IEN-168.
> >
> > Finally, at http://www.xbbn.org/note-12.html
> <http://www.xbbn.org/note-12.html> there is this description of
> > sockets and BBN's TCP implementation:
> >
> >       The BBN BSD TCP was the standard TCP for 4BSD and BSD
> UNIX 4.1. However, in
> >       BSD 4.2, the team at U.C. Berkeley created their own and
> very different
> >       implementation of TCP/IP (using the now familiar socket
> interface developed
> >       by Bill Joy and Sam Leffler of Berkeley along with
> Gurwitz).  BBN promptly
> >       revised its TCP implementation to use the socket
> interface, and for about a
> >       year there was a battle to determine whose networking
> code would take
> >       precedence.  Although the BBN code won some adherents,
> and was licensed to
> >       several computer vendors, the Berkeley code won the battle.
> >
> > I hope this clears that up.
> >
> > --Jim Dempsey--
> >
> > _______
> > internet-history mailing list
> > internet-***@postel.org <mailto:internet-***@postel.org>
> > http://mailman.postel.org/mailman/listinfo/internet-history
> <http://mailman.postel.org/mailman/listinfo/internet-history>
> > Contact list-***@postel.org <mailto:list-***@postel.org>
> for assistance.
> >
> _______
> internet-history mailing list
> internet-***@postel.org <mailto:internet-***@postel.org>
> http://mailman.postel.org/mailman/listinfo/internet-history
> <http://mailman.postel.org/mailman/listinfo/internet-history>
> Contact list-***@postel.org <mailto:list-***@postel.org> for
> assistance.
>
>
>
>
> --
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> Reston, VA 20190
>
>
>
>
> --
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> Reston, VA 20190

[Vint Cerf]

i think the DEC and HP implementations may have been from scratch (?) while
the IBM Labs version might had had contact with Univ Wisconsin (Larry
Landweber would know) or UCLA (Bob Braden). Landweber was involved in an
IP/X.25 implementation also. The DEC implementation might have had help
from BBN (does anyone on the list recall)?

vint


On Wed, Oct 25, 2017 at 5:52 PM, Jack Haverty <***@3kitty.org> wrote:

> I've always been curious about the ways, other than technical committees
> as documented in RFCs et al, that Internet history was driven.
>
> E.G., did the DEC/IBM/HP implementations in their respective labs use
> any of the code developed by ARPA for their machines? Recruit the
> people? Or did they start from the spec? Did the 30+ vendors of
> DOS/Windows TCP products spring from the work by Jim Mathis, Dave Mills,
> et al?
>
> There was a lot of talk back then about "Technology Transfer" as a
> government goal - basically saying that the government didn't want to
> fund development forever. Just wondering how that worked out... Did
> TCP/IP spread because the availability of free code enabled it? Or
> because the people moved from the research to product worlds and brought
> the knowledge (and code) with them?
>
> I'm sure some of this happened. Maybe some historian will tackle the
> problem of uncovering the various paths and timing that people and code
> took over the early decade or so. And how important that was to how
> things turned out.
>
> /Jack
>
> On 10/25/2017 12:28 PM, Vint Cerf wrote:
> > sorry "when" Microsoft not "with" ....duh
> >
> > v
> >
> >
> > On Wed, Oct 25, 2017 at 3:27 PM, Vint Cerf <***@google.com
> > <mailto:***@google.com>> wrote:
> >
> > FTP Software - TCP/IP for DOS/Windows - went belly up with Microsoft
> > integrated this into a version of their OS.
> >
> > IBM, DEC and HP did implementations in the research labs without
> > charge to DARPA.
> >
> > v
> >
> >
> > On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty <***@3kitty.org
> > <mailto:***@3kitty.org>> wrote:
> >
> > The history of TCP implementations was driven by non-technical
> > forces
> > too. As the saying goes -- "Follow the money."
> >
> > ARPA paid for the development of most if not all of the very
> > early TCP
> > implementations: the BBN-TENEX and LSI-11 for the Packet Radio
> > project,
> > my own PDP-11/40 Unix implementation as part of a Network
> Security
> > research program, Sax/Edmond's HP-3000 code, Braden's IBM work
> > at UCLA,
> > Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax
> > implementation. Probably more I've forgotten. Wingfield's
> > PDP-11/70
> > was funded, IIRC, by DCEC, the research arm of DCA - so it
> > represented a
> > tiny step from the research/ARPA world into the operational side.
> >
> > ARPA also paid for development of OSes, in particular BSD. As
> > the TCP
> > implementations were completed, ARPA stopped funding further
> > TCP-specific work, and, also IIRC, made those baseline
> > implementations
> > generally available. Berkeley continued BSD with ARPA funds,
> which
> > evolved into Sun. Big government contractors (motivated by the
> > contractual requirement to support TCP) built TCPs as they
> needed.
> >
> > Note also that the "await/capac" Unix interface was created by
> Randy
> > Rettberg and I to be the minimal functionality, with absolute
> > minimal
> > kernel code footprint, that we knew was needed to be able to
> write
> > network applications - ftp, telnet, etc. The goal was to cram
> > it into
> > the PDP-11/40, not to make a definitive interface for general
> > Unix use.
> > So it's not surprising that sockets took over.
> >
> > Also, someone commented that it would have been possible to do
> > networking with standard Unix primitives at the time, by having
> > multiple
> > processes interacting. We actually tried that. More
> > accurately, Ray
> > Tomlinson (yes the same one) ported a network security
> > application that
> > had been running on BBN-TENEX into a Unix implementation with a
> > dozen or
> > so interacting processes. With all of the context switching it
> > was so
> > slow that it was totally unusable. Plan B was await/capac to
> > make it
> > possible to use a single Unix process instead.
> >
> > Hardware vendors built TCPs too, such as the C/70. IIRC, the
> C/70
> > development for network management was partially funded by DCA,
> > so that
> > would have provided support for TCP development too.
> >
> > Startups popped up to fill gaps. Microsoft was a tad late to
> > the party,
> > and a slew of small companies created TCPs for DOS/Windows. I
> > recall
> > circa 1990 we had to deal with testing our software using 30+
> > different
> > TCP implementations for Windows that were then in common use.
> >
> > Historians may find DNA traces of some of those baseline 1980-ish
> > implementations in the later systems. My gut feeling is that the
> > choices that were made were not necessarily driven much by
> technical
> > evaluations, but more often by pragmatic considerations -
> > availability
> > of code, or of personnel with relevant experience.
> >
> > So, when you seek to unravel the history of TCP (and the
> > Internet), I'd
> > suggest also following the trails of the money, the people, as
> > well as
> > the software to understand why things happened the way they
> > did. That
> > won't be easy...
> >
> > HTH,
> > /Jack
> >
> > On 10/25/2017 08:27 AM, James J Dempsey wrote:
> > > Paul Ruizendaal <***@planet.nl <mailto:***@planet.nl>> wrote:
> > >
> > >>> On 24 Oct 2017, at 20:52, James J Dempsey <***@jjd.com
> > <mailto:***@jjd.com>> wrote:
> > >>>
> > >>> The C/70 (as well as the C/60) definitely did have a TCP/IP
> > stack. One of
> > >>> the first uses of the C/70 was to build and run the NU
> > Network Monitoring
> > >>> system. When I arrived at BBN in the Summer of 1981, we
> > were already on
> > >>> track to transition ARPANET to TCP/IP, which as we know
> > eventually happened
> > >>> on 1 Jan 1983.
> > >>
> > >> Thanks for confirming that. Would you recall if the C/70 used
> > the sockets API
> > >> or the earlier arpanet API? (I would suspect the latter).
> > >>
> > >> If the former, it would be the only back port of sockets to
> > V7 that I?m
> > >> aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).
> > >
> > > If you check out RFC 801 (written Nov 1981), Rob Gurwitz (who
> > wrote BBN's
> > > UNIX TCP implementation) says of "BBN C70 UNIX":
> > >
> > > The C/70 processor is a BBN-designed system with a native
> > > instruction set oriented toward executing the C
> > language. It
> > > supports UNIX Version 7 and provides for user processes
> > with a
> > > 20-bit address space. The TCP/IP implementation for the
> > C/70 was
> > > ported from the BBN VAX TCP/IP, and shares all of its
> > features.
> > >
> > > This version of TCP/IP is running experimentally at BBN,
> > but is
> > > still under development. Performance tuning is
> > underway, to make
> > > it more compatible with the C/70's memory management
> system.
> > >
> > > In the same RFC, Rob writes of the BBN VAX UNIX TCP
> > implementation:
> > >
> > > The VAX TCP/IP implementation is written in C for
> > Berkeley 4.1BSD
> > > UNIX, and runs in the UNIX kernel. It has been run on
> > VAX 11/780s
> > > and 750s at several sites, and is due to be generally
> > available in
> > > early 1982.
> > >
> > > The implementation conforms to the TCP and IP
> > specifications (RFC
> > > 791, 793). The implementation supports the new extended
> > internet
> > > address formats, and both GGP and ICMP. It also
> > supports multiple
> > > network access protocols and device drivers. Aside from
> > ARPANET
> > > 1822 and the ACC LH/DH-11 driver, experimental drivers
> > have also
> > > been developed for ETHERNET. There are user interfaces
> for
> > > accessing the IP and local network access layers
> > independent of
> > > the TCP.
> > >
> > > Higher level protocol services include user and server
> > TELNET,
> > > MTP, and FTP, implemented as user level programs. There
> > are also
> > > tools available for monitoring and recording network
> > traffic for
> > > debugging purposes.
> > >
> > > Continuing development includes performance
> > enhancements. The
> > > implementation is described in IEN-168.
> > >
> > > IEN-168 (available here
> > https://www.rfc-editor.org/ien/ien168.txt
> > <https://www.rfc-editor.org/ien/ien168.txt> ) does not
> > > contain the word "socket", so I suspect that that means the
> > BBN-UNIX
> > > implementation of TCP didn't contains the socket interface,
> > initially.
> > >
> > > In "Networking Implementation Notes 4.4BSD Edition" (
> > > https://docs.freebsd.org/44doc/smm/18.net/paper.pdf
> > <https://docs.freebsd.org/44doc/smm/18.net/paper.pdf> ) Sam
> > Leffler and Bill
> > > Joy acknowledge the BBN TCP/IP implementation:
> > >
> > > Many of the ideas related to protocol modularity, memory
> > management, and
> > > network interfaces are based on Rob Gurwitz’s TCP/IP
> > implementation for the
> > > 4.1BSD version of UNIX on the VAX [Gurwitz81].
> > >
> > > [Gurwitz81] is IEN-168.
> > >
> > > Finally, at http://www.xbbn.org/note-12.html
> > <http://www.xbbn.org/note-12.html> there is this description of
> > > sockets and BBN's TCP implementation:
> > >
> > > The BBN BSD TCP was the standard TCP for 4BSD and BSD
> > UNIX 4.1. However, in
> > > BSD 4.2, the team at U.C. Berkeley created their own and
> > very different
> > > implementation of TCP/IP (using the now familiar socket
> > interface developed
> > > by Bill Joy and Sam Leffler of Berkeley along with
> > Gurwitz). BBN promptly
> > > revised its TCP implementation to use the socket
> > interface, and for about a
> > > year there was a battle to determine whose networking
> > code would take
> > > precedence. Although the BBN code won some adherents,
> > and was licensed to
> > > several computer vendors, the Berkeley code won the
> battle.
> > >
> > > I hope this clears that up.
> > >
> > > --Jim Dempsey--
> > >
> > > _______
> > > internet-history mailing list
> > > internet-***@postel.org <mailto:internet-history@
> postel.org>
> > > http://mailman.postel.org/mailman/listinfo/internet-history
> > <http://mailman.postel.org/mailman/listinfo/internet-history>
> > > Contact list-***@postel.org <mailto:list-***@postel.org>
> > for assistance.
> > >
> > _______
> > internet-history mailing list
> > internet-***@postel.org <mailto:internet-***@postel.org>
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > <http://mailman.postel.org/mailman/listinfo/internet-history>
> > Contact list-***@postel.org <mailto:list-***@postel.org> for
> > assistance.
> >
> >
> >
> >
> > --
> > New postal address:
> > Google
> > 1875 Explorer Street, 10th Floor
> > Reston, VA 20190
> >
> >
> >
> >
> > --
> > New postal address:
> > Google
> > 1875 Explorer Street, 10th Floor
> > Reston, VA 20190
>



--
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190

[Wayne Hathaway]

For what it's worth, my IBM TSS/360 version at NASA Ames was from scratch and
even in 360 Assembler.&nbsp; Not too many other tools available.&nbsp; I forget what our user
interface looked like, but it was definitely not sockets.&nbsp; I guess it was in keeping with
what TSS/360 did, but that was too many years ago for me to remember.&nbsp; Oh, NASA
actually paid me as a consultant after I had left civil service to upgrade the NCP code
to TCP, a very entertaining exercise. :-)

Wayne Hathaway


On Wed, 25 Oct 2017 18:44:37 -0400, Vint Cerf wrote:
&nbsp;

i think the DEC and HP implementations may have been from scratch (?) while the IBM Labs version might had had contact with Univ Wisconsin (Larry Landweber would know) or UCLA (Bob Braden). Landweber was involved in an IP/X.25 implementation also. The DEC implementation might have had help from BBN (does anyone on the list recall)?
&nbsp;

vint

&nbsp;


&nbsp;
On Wed, Oct 25, 2017 at 5:52 PM, Jack Haverty &lt;***@3kitty.org&gt; wrote:

I've always been curious about the ways, other than technical committees
as documented in RFCs et al, that Internet history was driven.

E.G., did the DEC/IBM/HP implementations in their respective labs use
any of the code developed by ARPA for their machines? Recruit the
people? Or did they start from the spec? Did the 30+ vendors of
DOS/Windows TCP products spring from the work by Jim Mathis, Dave Mills,
et al?

There was a lot of talk back then about "Technology Transfer" as a
government goal - basically saying that the government didn't want to
fund development forever. Just wondering how that worked out... Did
TCP/IP spread because the availability of free code enabled it? Or
because the people moved from the research to product worlds and brought
the knowledge (and code) with them?

I'm sure some of this happened. Maybe some historian will tackle the
problem of uncovering the various paths and timing that people and code
took over the early decade or so. And how important that was to how
things turned out.

/Jack

On 10/25/2017 12:28 PM, Vint Cerf wrote:
&gt; sorry "when" Microsoft not "with" ....duh
&gt;
&gt; v
&gt;
&gt;
&gt; On Wed, Oct 25, 2017 at 3:27 PM, Vint Cerf &lt;***@google.com
&gt; &lt;mailto:***@google.com&gt;&gt; wrote:
&gt;
&gt; FTP Software - TCP/IP for DOS/Windows - went belly up with Microsoft
&gt; integrated this into a version of their OS.
&gt;
&gt; IBM, DEC and HP did implementations in the research labs without
&gt; charge to DARPA.
&gt;
&gt; v
&gt;
&gt;
&gt; On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty &lt;***@3kitty.org
&gt; &lt;mailto:***@3kitty.org&gt;&gt; wrote:
&gt;
&gt; The history of TCP implementations was driven by non-technical
&gt; forces
&gt; too. As the saying goes -- "Follow the money."
&gt;
&gt; ARPA paid for the development of most if not all of the very
&gt; early TCP
&gt; implementations: the BBN-TENEX and LSI-11 for the Packet Radio
&gt; project,
&gt; my own PDP-11/40 Unix implementation as part of a Network Security
&gt; research program, Sax/Edmond's HP-3000 code, Braden's IBM work
&gt; at UCLA,
&gt; Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax
&gt; implementation. Probably more I've forgotten. Wingfield's
&gt; PDP-11/70
&gt; was funded, IIRC, by DCEC, the research arm of DCA - so it
&gt; represented a
&gt; tiny step from the research/ARPA world into the operational side.
&gt;
&gt; ARPA also paid for development of OSes, in particular BSD. As
&gt; the TCP
&gt; implementations were completed, ARPA stopped funding further
&gt; TCP-specific work, and, also IIRC, made those baseline
&gt; implementations
&gt; generally available. Berkeley continued BSD with ARPA funds, which
&gt; evolved into Sun. Big government contractors (motivated by the
&gt; contractual requirement to support TCP) built TCPs as they needed.
&gt;
&gt; Note also that the "await/capac" Unix interface was created by Randy
&gt; Rettberg and I to be the minimal functionality, with absolute
&gt; minimal
&gt; kernel code footprint, that we knew was needed to be able to write
&gt; network applications - ftp, telnet, etc. The goal was to cram
&gt; it into
&gt; the PDP-11/40, not to make a definitive interface for general
&gt; Unix use.
&gt; So it's not surprising that sockets took over.
&gt;
&gt; Also, someone commented that it would have been possible to do
&gt; networking with standard Unix primitives at the time, by having
&gt; multiple
&gt; processes interacting. We actually tried that. More
&gt; accurately, Ray
&gt; Tomlinson (yes the same one) ported a network security
&gt; application that
&gt; had been running on BBN-TENEX into a Unix implementation with a
&gt; dozen or
&gt; so interacting processes. With all of the context switching it
&gt; was so
&gt; slow that it was totally unusable. Plan B was await/capac to
&gt; make it
&gt; possible to use a single Unix process instead.
&gt;
&gt; Hardware vendors built TCPs too, such as the C/70. IIRC, the C/70
&gt; development for network management was partially funded by DCA,
&gt; so that
&gt; would have provided support for TCP development too.
&gt;
&gt; Startups popped up to fill gaps. Microsoft was a tad late to
&gt; the party,
&gt; and a slew of small companies created TCPs for DOS/Windows. I
&gt; recall
&gt; circa 1990 we had to deal with testing our software using 30+
&gt; different
&gt; TCP implementations for Windows that were then in common use.
&gt;
&gt; Historians may find DNA traces of some of those baseline 1980-ish
&gt; implementations in the later systems. My gut feeling is that the
&gt; choices that were made were not necessarily driven much by technical
&gt; evaluations, but more often by pragmatic considerations -
&gt; availability
&gt; of code, or of personnel with relevant experience.
&gt;
&gt; So, when you seek to unravel the history of TCP (and the
&gt; Internet), I'd
&gt; suggest also following the trails of the money, the people, as
&gt; well as
&gt; the software to understand why things happened the way they
&gt; did. That
&gt; won't be easy...
&gt;
&gt; HTH,
&gt; /Jack
&gt;
&gt; On 10/25/2017 08:27 AM, James J Dempsey wrote:
&gt; &gt; Paul Ruizendaal &lt;***@planet.nl &lt;mailto:***@planet.nl&gt;&gt; wrote:
&gt; &gt;
&gt; &gt;&gt;&gt; On 24 Oct 2017, at 20:52, James J Dempsey &lt;***@jjd.com
&gt; &lt;mailto:***@jjd.com&gt;&gt; wrote:
&gt; &gt;&gt;&gt;
&gt; &gt;&gt;&gt; The C/70 (as well as the C/60) definitely did have a TCP/IP
&gt; stack. One of
&gt; &gt;&gt;&gt; the first uses of the C/70 was to build and run the NU
&gt; Network Monitoring
&gt; &gt;&gt;&gt; system. When I arrived at BBN in the Summer of 1981, we
&gt; were already on
&gt; &gt;&gt;&gt; track to transition ARPANET to TCP/IP, which as we know
&gt; eventually happened
&gt; &gt;&gt;&gt; on 1 Jan 1983.
&gt; &gt;&gt;
&gt; &gt;&gt; Thanks for confirming that. Would you recall if the C/70 used
&gt; the sockets API
&gt; &gt;&gt; or the earlier arpanet API? (I would suspect the latter).
&gt; &gt;&gt;
&gt; &gt;&gt; If the former, it would be the only back port of sockets to
&gt; V7 that I?m
&gt; &gt;&gt; aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).
&gt; &gt;
&gt; &gt; If you check out RFC 801 (written Nov 1981), Rob Gurwitz (who
&gt; wrote BBN's
&gt; &gt; UNIX TCP implementation) says of "BBN C70 UNIX":
&gt; &gt;
&gt; &gt; The C/70 processor is a BBN-designed system with a native
&gt; &gt; instruction set oriented toward executing the C
&gt; language. It
&gt; &gt; supports UNIX Version 7 and provides for user processes
&gt; with a
&gt; &gt; 20-bit address space. The TCP/IP implementation for the
&gt; C/70 was
&gt; &gt; ported from the BBN VAX TCP/IP, and shares all of its
&gt; features.
&gt; &gt;
&gt; &gt; This version of TCP/IP is running experimentally at BBN,
&gt; but is
&gt; &gt; still under development. Performance tuning is
&gt; underway, to make
&gt; &gt; it more compatible with the C/70's memory management system.
&gt; &gt;
&gt; &gt; In the same RFC, Rob writes of the BBN VAX UNIX TCP
&gt; implementation:
&gt; &gt;
&gt; &gt; The VAX TCP/IP implementation is written in C for
&gt; Berkeley 4.1BSD
&gt; &gt; UNIX, and runs in the UNIX kernel. It has been run on
&gt; VAX 11/780s
&gt; &gt; and 750s at several sites, and is due to be generally
&gt; available in
&gt; &gt; early 1982.
&gt; &gt;
&gt; &gt; The implementation conforms to the TCP and IP
&gt; specifications (RFC
&gt; &gt; 791, 793). The implementation supports the new extended
&gt; internet
&gt; &gt; address formats, and both GGP and ICMP. It also
&gt; supports multiple
&gt; &gt; network access protocols and device drivers. Aside from
&gt; ARPANET
&gt; &gt; 1822 and the ACC LH/DH-11 driver, experimental drivers
&gt; have also
&gt; &gt; been developed for ETHERNET. There are user interfaces for
&gt; &gt; accessing the IP and local network access layers
&gt; independent of
&gt; &gt; the TCP.
&gt; &gt;
&gt; &gt; Higher level protocol services include user and server
&gt; TELNET,
&gt; &gt; MTP, and FTP, implemented as user level programs. There
&gt; are also
&gt; &gt; tools available for monitoring and recording network
&gt; traffic for
&gt; &gt; debugging purposes.
&gt; &gt;
&gt; &gt; Continuing development includes performance
&gt; enhancements. The
&gt; &gt; implementation is described in IEN-168.
&gt; &gt;
&gt; &gt; IEN-168 (available here
&gt; https://www.rfc-editor.org/ien/ien168.txt
&gt; &lt;https://www.rfc-editor.org/ien/ien168.txt&gt; ) does not
&gt; &gt; contain the word "socket", so I suspect that that means the
&gt; BBN-UNIX
&gt; &gt; implementation of TCP didn't contains the socket interface,
&gt; initially.
&gt; &gt;
&gt; &gt; In "Networking Implementation Notes 4.4BSD Edition" (
&gt; &gt; https://docs.freebsd.org/44doc/smm/18.net/paper.pdf
&gt; &lt;https://docs.freebsd.org/44doc/smm/18.net/paper.pdf&gt; ) Sam
&gt; Leffler and Bill
&gt; &gt; Joy acknowledge the BBN TCP/IP implementation:
&gt; &gt;
&gt; &gt; Many of the ideas related to protocol modularity, memory
&gt; management, and
&gt; &gt; network interfaces are based on Rob Gurwitz’s TCP/IP
&gt; implementation for the
&gt; &gt; 4.1BSD version of UNIX on the VAX [Gurwitz81].
&gt; &gt;
&gt; &gt; [Gurwitz81] is IEN-168.
&gt; &gt;
&gt; &gt; Finally, at http://www.xbbn.org/note-12.html
&gt; &lt;http://www.xbbn.org/note-12.html&gt; there is this description of
&gt; &gt; sockets and BBN's TCP implementation:
&gt; &gt;
&gt; &gt; The BBN BSD TCP was the standard TCP for 4BSD and BSD
&gt; UNIX 4.1. However, in
&gt; &gt; BSD 4.2, the team at U.C. Berkeley created their own and
&gt; very different
&gt; &gt; implementation of TCP/IP (using the now familiar socket
&gt; interface developed
&gt; &gt; by Bill Joy and Sam Leffler of Berkeley along with
&gt; Gurwitz). BBN promptly
&gt; &gt; revised its TCP implementation to use the socket
&gt; interface, and for about a
&gt; &gt; year there was a battle to determine whose networking
&gt; code would take
&gt; &gt; precedence. Although the BBN code won some adherents,
&gt; and was licensed to
&gt; &gt; several computer vendors, the Berkeley code won the battle.
&gt; &gt;
&gt; &gt; I hope this clears that up.
&gt; &gt;
&gt; &gt; --Jim Dempsey--
&gt; &gt;
&gt; &gt; _______
&gt; &gt; internet-history mailing list
&gt; &gt; internet-***@postel.org &lt;mailto:internet-***@postel.org&gt;
&gt; &gt; http://mailman.postel.org/mailman/listinfo/internet-history
&gt; &lt;http://mailman.postel.org/mailman/listinfo/internet-history&gt;
&gt; &gt; Contact list-***@postel.org &lt;mailto:list-***@postel.org&gt;
&gt; for assistance.
&gt; &gt;
&gt; _______
&gt; internet-history mailing list
&gt; internet-***@postel.org &lt;mailto:internet-***@postel.org&gt;
&gt; http://mailman.postel.org/mailman/listinfo/internet-history
&gt; &lt;http://mailman.postel.org/mailman/listinfo/internet-history&gt;
&gt; Contact list-***@postel.org &lt;mailto:list-***@postel.org&gt; for
&gt; assistance.
&gt;
&gt;
&gt;
&gt;
&gt; --
&gt; New postal address:
&gt; Google
&gt; 1875 Explorer Street, 10th Floor
&gt; Reston, VA 20190
&gt;
&gt;
&gt;
&gt;
&gt; --
&gt; New postal address:
&gt; Google
&gt; 1875 Explorer Street, 10th Floor
&gt; Reston, VA 20190

&nbsp;

&nbsp;
--


New postal address:
Google
1875 Explorer Street, 10th Floor

Reston, VA 20190

[Brian E Carpenter]

On 26/10/2017 11:44, Vint Cerf wrote:
> i think the DEC

If you mean the Ultrix code, that seems to have been derived from 4.2BSD.
Released June 1984 according to Wikipedia.

On VAX/VMS we had to use the Wollongong third-party product for a long time.
That was allegedly based on BSD code in some way, I don't recall the details.

On PDP/11s there seems to have been a bit of everything.

> and HP implementations may have been from scratch (?) while
> the IBM Labs version might had had contact with Univ Wisconsin (Larry
> Landweber would know) or UCLA (Bob Braden).

It was a complicated story on the mainframes. WISCNET was indeed the way
in for VM/CMS users (as early as 1985), and IBM apparently sold it as
a product. But that wasn't the whole story. There's a brief discussion in
Olivier Martin's book:
http://www.ictconsulting.ch/reports/European-Research-Internet-History.pdf
I don't know the early story for MVS users.

AIX was released in 1986 "based on UNIX System V... also incorporated source
code from 4.2 and 4.3 BSD".

Then there were numerous false starts in IBM over TCP/IP, because of
frantic internal attempts to defeat it as an enemy of SNA, and equally
frantic attempts to support it as the clear winner. This didn't end
until Lou Gerstner took over as CEO, put Irving Wladawsky-Berger in
charge of the Internet Division, and IBM incidentally hired me away
from CERN. But then I spent ten years running errands between the
development teams for each IBM operating system trying to make their
TCP/IP stacks feature-compatible. (And failing, of course.)

Brian

> Landweber was involved in an
> IP/X.25 implementation also. The DEC implementation might have had help
> from BBN (does anyone on the list recall)?
>
> vint
>
>
> On Wed, Oct 25, 2017 at 5:52 PM, Jack Haverty <***@3kitty.org> wrote:
>
>> I've always been curious about the ways, other than technical committees
>> as documented in RFCs et al, that Internet history was driven.
>>
>> E.G., did the DEC/IBM/HP implementations in their respective labs use
>> any of the code developed by ARPA for their machines? Recruit the
>> people? Or did they start from the spec? Did the 30+ vendors of
>> DOS/Windows TCP products spring from the work by Jim Mathis, Dave Mills,
>> et al?
>>
>> There was a lot of talk back then about "Technology Transfer" as a
>> government goal - basically saying that the government didn't want to
>> fund development forever. Just wondering how that worked out... Did
>> TCP/IP spread because the availability of free code enabled it? Or
>> because the people moved from the research to product worlds and brought
>> the knowledge (and code) with them?
>>
>> I'm sure some of this happened. Maybe some historian will tackle the
>> problem of uncovering the various paths and timing that people and code
>> took over the early decade or so. And how important that was to how
>> things turned out.
>>
>> /Jack
>>
>> On 10/25/2017 12:28 PM, Vint Cerf wrote:
>>> sorry "when" Microsoft not "with" ....duh
>>>
>>> v
>>>
>>>
>>> On Wed, Oct 25, 2017 at 3:27 PM, Vint Cerf <***@google.com
>>> <mailto:***@google.com>> wrote:
>>>
>>> FTP Software - TCP/IP for DOS/Windows - went belly up with Microsoft
>>> integrated this into a version of their OS.
>>>
>>> IBM, DEC and HP did implementations in the research labs without
>>> charge to DARPA.
>>>
>>> v
>>>
>>>
>>> On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty <***@3kitty.org
>>> <mailto:***@3kitty.org>> wrote:
>>>
>>> The history of TCP implementations was driven by non-technical
>>> forces
>>> too. As the saying goes -- "Follow the money."
>>>
>>> ARPA paid for the development of most if not all of the very
>>> early TCP
>>> implementations: the BBN-TENEX and LSI-11 for the Packet Radio
>>> project,
>>> my own PDP-11/40 Unix implementation as part of a Network
>> Security
>>> research program, Sax/Edmond's HP-3000 code, Braden's IBM work
>>> at UCLA,
>>> Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax
>>> implementation. Probably more I've forgotten. Wingfield's
>>> PDP-11/70
>>> was funded, IIRC, by DCEC, the research arm of DCA - so it
>>> represented a
>>> tiny step from the research/ARPA world into the operational side.
>>>
>>> ARPA also paid for development of OSes, in particular BSD. As
>>> the TCP
>>> implementations were completed, ARPA stopped funding further
>>> TCP-specific work, and, also IIRC, made those baseline
>>> implementations
>>> generally available. Berkeley continued BSD with ARPA funds,
>> which
>>> evolved into Sun. Big government contractors (motivated by the
>>> contractual requirement to support TCP) built TCPs as they
>> needed.
>>>
>>> Note also that the "await/capac" Unix interface was created by
>> Randy
>>> Rettberg and I to be the minimal functionality, with absolute
>>> minimal
>>> kernel code footprint, that we knew was needed to be able to
>> write
>>> network applications - ftp, telnet, etc. The goal was to cram
>>> it into
>>> the PDP-11/40, not to make a definitive interface for general
>>> Unix use.
>>> So it's not surprising that sockets took over.
>>>
>>> Also, someone commented that it would have been possible to do
>>> networking with standard Unix primitives at the time, by having
>>> multiple
>>> processes interacting. We actually tried that. More
>>> accurately, Ray
>>> Tomlinson (yes the same one) ported a network security
>>> application that
>>> had been running on BBN-TENEX into a Unix implementation with a
>>> dozen or
>>> so interacting processes. With all of the context switching it
>>> was so
>>> slow that it was totally unusable. Plan B was await/capac to
>>> make it
>>> possible to use a single Unix process instead.
>>>
>>> Hardware vendors built TCPs too, such as the C/70. IIRC, the
>> C/70
>>> development for network management was partially funded by DCA,
>>> so that
>>> would have provided support for TCP development too.
>>>
>>> Startups popped up to fill gaps. Microsoft was a tad late to
>>> the party,
>>> and a slew of small companies created TCPs for DOS/Windows. I
>>> recall
>>> circa 1990 we had to deal with testing our software using 30+
>>> different
>>> TCP implementations for Windows that were then in common use.
>>>
>>> Historians may find DNA traces of some of those baseline 1980-ish
>>> implementations in the later systems. My gut feeling is that the
>>> choices that were made were not necessarily driven much by
>> technical
>>> evaluations, but more often by pragmatic considerations -
>>> availability
>>> of code, or of personnel with relevant experience.
>>>
>>> So, when you seek to unravel the history of TCP (and the
>>> Internet), I'd
>>> suggest also following the trails of the money, the people, as
>>> well as
>>> the software to understand why things happened the way they
>>> did. That
>>> won't be easy...
>>>
>>> HTH,
>>> /Jack
>>>
>>> On 10/25/2017 08:27 AM, James J Dempsey wrote:
>>> > Paul Ruizendaal <***@planet.nl <mailto:***@planet.nl>> wrote:
>>> >
>>> >>> On 24 Oct 2017, at 20:52, James J Dempsey <***@jjd.com
>>> <mailto:***@jjd.com>> wrote:
>>> >>>
>>> >>> The C/70 (as well as the C/60) definitely did have a TCP/IP
>>> stack. One of
>>> >>> the first uses of the C/70 was to build and run the NU
>>> Network Monitoring
>>> >>> system. When I arrived at BBN in the Summer of 1981, we
>>> were already on
>>> >>> track to transition ARPANET to TCP/IP, which as we know
>>> eventually happened
>>> >>> on 1 Jan 1983.
>>> >>
>>> >> Thanks for confirming that. Would you recall if the C/70 used
>>> the sockets API
>>> >> or the earlier arpanet API? (I would suspect the latter).
>>> >>
>>> >> If the former, it would be the only back port of sockets to
>>> V7 that I?m
>>> >> aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).
>>> >
>>> > If you check out RFC 801 (written Nov 1981), Rob Gurwitz (who
>>> wrote BBN's
>>> > UNIX TCP implementation) says of "BBN C70 UNIX":
>>> >
>>> > The C/70 processor is a BBN-designed system with a native
>>> > instruction set oriented toward executing the C
>>> language. It
>>> > supports UNIX Version 7 and provides for user processes
>>> with a
>>> > 20-bit address space. The TCP/IP implementation for the
>>> C/70 was
>>> > ported from the BBN VAX TCP/IP, and shares all of its
>>> features.
>>> >
>>> > This version of TCP/IP is running experimentally at BBN,
>>> but is
>>> > still under development. Performance tuning is
>>> underway, to make
>>> > it more compatible with the C/70's memory management
>> system.
>>> >
>>> > In the same RFC, Rob writes of the BBN VAX UNIX TCP
>>> implementation:
>>> >
>>> > The VAX TCP/IP implementation is written in C for
>>> Berkeley 4.1BSD
>>> > UNIX, and runs in the UNIX kernel. It has been run on
>>> VAX 11/780s
>>> > and 750s at several sites, and is due to be generally
>>> available in
>>> > early 1982.
>>> >
>>> > The implementation conforms to the TCP and IP
>>> specifications (RFC
>>> > 791, 793). The implementation supports the new extended
>>> internet
>>> > address formats, and both GGP and ICMP. It also
>>> supports multiple
>>> > network access protocols and device drivers. Aside from
>>> ARPANET
>>> > 1822 and the ACC LH/DH-11 driver, experimental drivers
>>> have also
>>> > been developed for ETHERNET. There are user interfaces
>> for
>>> > accessing the IP and local network access layers
>>> independent of
>>> > the TCP.
>>> >
>>> > Higher level protocol services include user and server
>>> TELNET,
>>> > MTP, and FTP, implemented as user level programs. There
>>> are also
>>> > tools available for monitoring and recording network
>>> traffic for
>>> > debugging purposes.
>>> >
>>> > Continuing development includes performance
>>> enhancements. The
>>> > implementation is described in IEN-168.
>>> >
>>> > IEN-168 (available here
>>> https://www.rfc-editor.org/ien/ien168.txt
>>> <https://www.rfc-editor.org/ien/ien168.txt> ) does not
>>> > contain the word "socket", so I suspect that that means the
>>> BBN-UNIX
>>> > implementation of TCP didn't contains the socket interface,
>>> initially.
>>> >
>>> > In "Networking Implementation Notes 4.4BSD Edition" (
>>> > https://docs.freebsd.org/44doc/smm/18.net/paper.pdf
>>> <https://docs.freebsd.org/44doc/smm/18.net/paper.pdf> ) Sam
>>> Leffler and Bill
>>> > Joy acknowledge the BBN TCP/IP implementation:
>>> >
>>> > Many of the ideas related to protocol modularity, memory
>>> management, and
>>> > network interfaces are based on Rob Gurwitz’s TCP/IP
>>> implementation for the
>>> > 4.1BSD version of UNIX on the VAX [Gurwitz81].
>>> >
>>> > [Gurwitz81] is IEN-168.
>>> >
>>> > Finally, at http://www.xbbn.org/note-12.html
>>> <http://www.xbbn.org/note-12.html> there is this description of
>>> > sockets and BBN's TCP implementation:
>>> >
>>> > The BBN BSD TCP was the standard TCP for 4BSD and BSD
>>> UNIX 4.1. However, in
>>> > BSD 4.2, the team at U.C. Berkeley created their own and
>>> very different
>>> > implementation of TCP/IP (using the now familiar socket
>>> interface developed
>>> > by Bill Joy and Sam Leffler of Berkeley along with
>>> Gurwitz). BBN promptly
>>> > revised its TCP implementation to use the socket
>>> interface, and for about a
>>> > year there was a battle to determine whose networking
>>> code would take
>>> > precedence. Although the BBN code won some adherents,
>>> and was licensed to
>>> > several computer vendors, the Berkeley code won the
>> battle.
>>> >
>>> > I hope this clears that up.
>>> >
>>> > --Jim Dempsey--

[Dave Crocker]

On 10/25/2017 6:18 PM, Brian E Carpenter wrote:
> On VAX/VMS we had to use the Wollongong third-party product for a long time.
> That was allegedly based on BSD code in some way, I don't recall the details.


I should have the fine-grained details of the answer to that, but I am
embarrassed to admit I don't, though part of me thinks that's more from
poor memory than from never having known.

Here's what I /think/ the answer is:

Yes, the code was a BSD base, probably 4.1, but really I don't recall.

Wollongong had a virtualization layer that ran on top of VMS and
emulated a BSD interface that the TCP code ran on. I'll let the reader
take a wild guess what non-US university they got this code base from...

At the time I left, there was a new releaswe of VMS coming that killed
this emulation environment. They did the revisions, to make it work but
I don't know the details of how.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

[Paul Vixie]

Dave Crocker wrote:
> ...
>
> Here's what I /think/ the answer is:
>
> Yes, the code was a BSD base, probably 4.1, but really I don't recall.
>
> ...

"Congratulations, you're not running Eunice(tm)!"

(that was from the RN autoconfiguration script of that era.)

--
P Vixie

[Alan Maitland]

HP had a proprietary DS/3000 (Distributed Systems) networking solution
(announced around Spring 1977), allowing their HP3000 Business Systems
and HP1000 real time systems to network together. Still remember going
to the HP sales office in NJ in 1979 as a customer to watch the
introduction via satellite by John Young (then HP's President) demoing
the solution between the Palo Alto and Santa Clara HP Sales offices.

That got replaced with NS/3000 in 1986 (or thereabouts) which was
compliant with basic TCP/IP standards of that time. Also recall getting
introduced to and trained on TCP/IP that year, then as an HP SE in the
South Bay Area.

Using NS/3000, HP was able to have its commercial business systems
coexist on a standards based network to interact with PC clients and
other compliant vendor systems. The cities of Sunnyvale and Palo Alto
implemented such networks using "ThickLAN" (thick ethernet cabling
10Mb/s), "ThinLan" (thin eithernet cabling 10Mb/s) and "StarLAN"
(Twisted Pair initially at 1Mb/s, later upgraded to 10Mb/s and rebranded
"StarLAN 10") hardware and the NS/3000 solution with HP OfficeShare for PCs.

Seems a lifetime ago.

Alan


On 10/25/2017 4:44 PM, Vint Cerf wrote:
> i think the DEC and HP implementations may have been from scratch (?)
> while the IBM Labs version might had had contact with Univ Wisconsin
> (Larry Landweber would know) or UCLA (Bob Braden). Landweber was
> involved in an IP/X.25 implementation also. The DEC implementation might
> have had help from BBN (does anyone on the list recall)?
>
> vint
>
>
> On Wed, Oct 25, 2017 at 5:52 PM, Jack Haverty <***@3kitty.org
> <mailto:***@3kitty.org>> wrote:
>
> I've always been curious about the ways, other than technical committees
> as documented in RFCs et al, that Internet history was driven.
>
> E.G., did the DEC/IBM/HP implementations in their respective labs use
> any of the code developed by ARPA for their machines?  Recruit the
> people?  Or did they start from the spec?  Did the 30+ vendors of
> DOS/Windows TCP products spring from the work by Jim Mathis, Dave Mills,
> et al?
>
> There was a lot of talk back then about "Technology Transfer" as a
> government goal - basically saying that the government didn't want to
> fund development forever.  Just wondering how that worked out...  Did
> TCP/IP spread because the availability of free code enabled it?   Or
> because the people moved from the research to product worlds and brought
> the knowledge (and code) with them?
>
> I'm sure some of this happened.  Maybe some historian will tackle the
> problem of uncovering the various paths and timing that people and code
> took over the early decade or so.   And how important that was to how
> things turned out.
>
> /Jack
>
> On 10/25/2017 12:28 PM, Vint Cerf wrote:
> > sorry "when" Microsoft not "with" ....duh
> >
> > v
> >
> >
> > On Wed, Oct 25, 2017 at 3:27 PM, Vint Cerf <***@google.com
> <mailto:***@google.com>
> > <mailto:***@google.com <mailto:***@google.com>>> wrote:
> >
> >     FTP Software - TCP/IP for DOS/Windows - went belly up with
> Microsoft
> >     integrated this into a version of their OS.
> >
> >     IBM, DEC and HP did implementations in the research labs without
> >     charge to DARPA.
> >
> >     v
> >
> >
> >     On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty
> <***@3kitty.org <mailto:***@3kitty.org>
> >     <mailto:***@3kitty.org <mailto:***@3kitty.org>>> wrote:
> >
> >         The history of TCP implementations was driven by
> non-technical
> >         forces
> >         too.  As the saying goes -- "Follow the money."
> >
> >         ARPA paid for the development of most if not all of the very
> >         early TCP
> >         implementations: the BBN-TENEX and LSI-11 for the Packet
> Radio
> >         project,
> >         my own PDP-11/40 Unix implementation as part of a Network
> Security
> >         research program, Sax/Edmond's HP-3000 code, Braden's IBM
> work
> >         at UCLA,
> >         Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax
> >         implementation.  Probably more I've forgotten.  Wingfield's
> >         PDP-11/70
> >         was funded, IIRC, by DCEC, the research arm of DCA - so it
> >         represented a
> >         tiny step from the research/ARPA world into the
> operational side.
> >
> >         ARPA also paid for development of OSes, in particular
> BSD.  As
> >         the TCP
> >         implementations were completed, ARPA stopped funding further
> >         TCP-specific work, and, also IIRC, made those baseline
> >         implementations
> >         generally available.  Berkeley continued BSD with ARPA
> funds, which
> >         evolved into Sun.  Big government contractors (motivated
> by the
> >         contractual requirement to support TCP) built TCPs as
> they needed.
> >
> >         Note also that the "await/capac" Unix interface was
> created by Randy
> >         Rettberg and I to be the minimal functionality, with absolute
> >         minimal
> >         kernel code footprint, that we knew was needed to be able
> to write
> >         network applications - ftp, telnet, etc.  The goal was to
> cram
> >         it into
> >         the PDP-11/40, not to make a definitive interface for general
> >         Unix use.
> >         So it's not surprising that sockets took over.
> >
> >         Also, someone commented that it would have been possible
> to do
> >         networking with standard Unix primitives at the time, by
> having
> >         multiple
> >         processes interacting.  We actually tried that.  More
> >         accurately, Ray
> >         Tomlinson (yes the same one) ported a network security
> >         application that
> >         had been running on BBN-TENEX into a Unix implementation
> with a
> >         dozen or
> >         so interacting processes.  With all of the context
> switching it
> >         was so
> >         slow that it was totally unusable.  Plan B was await/capac to
> >         make it
> >         possible to use a single Unix process instead.
> >
> >         Hardware vendors built TCPs too, such as the C/70.  IIRC,
> the C/70
> >         development for network management was partially funded
> by DCA,
> >         so that
> >         would have provided support for TCP development too.
> >
> >         Startups popped up to fill gaps.  Microsoft was a tad late to
> >         the party,
> >         and a slew of small companies created TCPs for
> DOS/Windows.  I
> >         recall
> >         circa 1990 we had to deal with testing our software using 30+
> >         different
> >         TCP implementations for Windows that were then in common use.
> >
> >         Historians may find DNA traces of some of those baseline
> 1980-ish
> >         implementations in the later systems.  My gut feeling is
> that the
> >         choices that were made were not necessarily driven much
> by technical
> >         evaluations, but more often by pragmatic considerations -
> >         availability
> >         of code, or of personnel with relevant experience.
> >
> >         So, when you seek to unravel the history of TCP (and the
> >         Internet), I'd
> >         suggest also following the trails of the money, the
> people, as
> >         well as
> >         the software to understand why things happened the way they
> >         did.  That
> >         won't be easy...
> >
> >         HTH,
> >         /Jack
> >
> >         On 10/25/2017 08:27 AM, James J Dempsey wrote:
> >         > Paul Ruizendaal <***@planet.nl <mailto:***@planet.nl>
> <mailto:***@planet.nl <mailto:***@planet.nl>>> wrote:
> >         >
> >         >>> On 24 Oct 2017, at 20:52, James J Dempsey
> <***@jjd.com <mailto:***@jjd.com>
> >         <mailto:***@jjd.com <mailto:***@jjd.com>>> wrote:
> >         >>>
> >         >>> The C/70 (as well as the C/60) definitely did have a
> TCP/IP
> >         stack.  One of
> >         >>> the first uses of the C/70 was to build and run the NU
> >         Network Monitoring
> >         >>> system.  When I arrived at BBN in the Summer of 1981, we
> >         were already on
> >         >>> track to transition ARPANET to TCP/IP, which as we know
> >         eventually happened
> >         >>> on 1 Jan 1983.
> >         >>
> >         >> Thanks for confirming that. Would you recall if the
> C/70 used
> >         the sockets API
> >         >> or the earlier arpanet API? (I would suspect the latter).
> >         >>
> >         >> If the former, it would be the only back port of
> sockets to
> >         V7 that I?m
> >         >> aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).
> >         >
> >         > If you check out RFC 801 (written Nov 1981), Rob
> Gurwitz (who
> >         wrote BBN's
> >         > UNIX TCP implementation) says of "BBN C70 UNIX":
> >         >
> >         >       The C/70 processor is a BBN-designed system with
> a native
> >         >       instruction set oriented toward executing the C
> >         language.  It
> >         >       supports UNIX Version 7 and provides for user
> processes
> >         with a
> >         >       20-bit address space.  The TCP/IP implementation
> for the
> >         C/70 was
> >         >       ported from the BBN VAX TCP/IP, and shares all of its
> >         features.
> >         >
> >         >       This version of TCP/IP is running experimentally
> at BBN,
> >         but is
> >         >       still under development.  Performance tuning is
> >         underway, to make
> >         >       it more compatible with the C/70's memory
> management system.
> >         >
> >         > In the same RFC, Rob writes of the BBN VAX UNIX TCP
> >         implementation:
> >         >
> >         >       The VAX TCP/IP implementation is written in C for
> >         Berkeley 4.1BSD
> >         >       UNIX, and runs in the UNIX kernel.  It has been
> run on
> >         VAX 11/780s
> >         >       and 750s at several sites, and is due to be generally
> >         available in
> >         >       early 1982.
> >         >
> >         >       The implementation conforms to the TCP and IP
> >         specifications (RFC
> >         >       791, 793).  The implementation supports the new
> extended
> >         internet
> >         >       address formats, and both GGP and ICMP.  It also
> >         supports multiple
> >         >       network access protocols and device drivers.
> Aside from
> >         ARPANET
> >         >       1822 and the ACC LH/DH-11 driver, experimental
> drivers
> >         have also
> >         >       been developed for ETHERNET.  There are user
> interfaces for
> >         >       accessing the IP and local network access layers
> >         independent of
> >         >       the TCP.
> >         >
> >         >       Higher level protocol services include user and
> server
> >         TELNET,
> >         >       MTP, and FTP, implemented as user level
> programs.  There
> >         are also
> >         >       tools available for monitoring and recording network
> >         traffic for
> >         >       debugging purposes.
> >         >
> >         >       Continuing development includes performance
> >         enhancements.  The
> >         >       implementation is described in IEN-168.
> >         >
> >         > IEN-168 (available here
> > https://www.rfc-editor.org/ien/ien168.txt
> <https://www.rfc-editor.org/ien/ien168.txt>
> >         <https://www.rfc-editor.org/ien/ien168.txt
> <https://www.rfc-editor.org/ien/ien168.txt>> ) does not
> >         > contain the word "socket", so I suspect that that means the
> >         BBN-UNIX
> >         > implementation of TCP didn't contains the socket interface,
> >         initially.
> >         >
> >         > In "Networking Implementation Notes 4.4BSD Edition" (
> >         > https://docs.freebsd.org/44doc/smm/18.net/paper.pdf
> <https://docs.freebsd.org/44doc/smm/18.net/paper.pdf>
> >         <https://docs.freebsd.org/44doc/smm/18.net/paper.pdf
> <https://docs.freebsd.org/44doc/smm/18.net/paper.pdf>> ) Sam
> >         Leffler and Bill
> >         > Joy acknowledge the BBN TCP/IP implementation:
> >         >
> >         >     Many of the ideas related to protocol modularity,
> memory
> >         management, and
> >         >     network interfaces are based on Rob Gurwitz’s TCP/IP
> >         implementation for the
> >         >     4.1BSD version of UNIX on the VAX [Gurwitz81].
> >         >
> >         > [Gurwitz81] is IEN-168.
> >         >
> >         > Finally, at http://www.xbbn.org/note-12.html
> <http://www.xbbn.org/note-12.html>
> >         <http://www.xbbn.org/note-12.html
> <http://www.xbbn.org/note-12.html>> there is this description of
> >         > sockets and BBN's TCP implementation:
> >         >
> >         >       The BBN BSD TCP was the standard TCP for 4BSD and BSD
> >         UNIX 4.1. However, in
> >         >       BSD 4.2, the team at U.C. Berkeley created their
> own and
> >         very different
> >         >       implementation of TCP/IP (using the now familiar
> socket
> >         interface developed
> >         >       by Bill Joy and Sam Leffler of Berkeley along with
> >         Gurwitz).  BBN promptly
> >         >       revised its TCP implementation to use the socket
> >         interface, and for about a
> >         >       year there was a battle to determine whose networking
> >         code would take
> >         >       precedence.  Although the BBN code won some
> adherents,
> >         and was licensed to
> >         >       several computer vendors, the Berkeley code won
> the battle.
> >         >
> >         > I hope this clears that up.
> >         >
> >         > --Jim Dempsey--
> >         >
> >         > _______
> >         > internet-history mailing list
> >         > internet-***@postel.org
> <mailto:internet-***@postel.org>
> <mailto:internet-***@postel.org
> <mailto:internet-***@postel.org>>
> >         >
> http://mailman.postel.org/mailman/listinfo/internet-history
> <http://mailman.postel.org/mailman/listinfo/internet-history>
> >
>  <http://mailman.postel.org/mailman/listinfo/internet-history
> <http://mailman.postel.org/mailman/listinfo/internet-history>>
> >         > Contact list-***@postel.org
> <mailto:list-***@postel.org> <mailto:list-***@postel.org
> <mailto:list-***@postel.org>>
> >         for assistance.
> >         >
> >         _______
> >         internet-history mailing list
> > internet-***@postel.org <mailto:internet-***@postel.org>
> <mailto:internet-***@postel.org
> <mailto:internet-***@postel.org>>
> > http://mailman.postel.org/mailman/listinfo/internet-history
> <http://mailman.postel.org/mailman/listinfo/internet-history>
> >
>  <http://mailman.postel.org/mailman/listinfo/internet-history
> <http://mailman.postel.org/mailman/listinfo/internet-history>>
> >         Contact list-***@postel.org
> <mailto:list-***@postel.org> <mailto:list-***@postel.org
> <mailto:list-***@postel.org>> for
> >         assistance.
> >
> >
> >
> >
> >     --
> >     New postal address:
> >     Google
> >     1875 Explorer Street, 10th Floor
> >     Reston, VA 20190
> >
> >
> >
> >
> > --
> > New postal address:
> > Google
> > 1875 Explorer Street, 10th Floor
> > Reston, VA 20190
>
>
>
>
> --
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> Reston, VA 20190
>
>
> _______
> internet-history mailing list
> internet-***@postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-***@postel.org for assistance.
>

[Craig Partridge]

On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty <***@3kitty.org> wrote:

> The history of TCP implementations was driven by non-technical forces
> too. As the saying goes -- "Follow the money."
>
> ARPA paid for the development of most if not all of the very early TCP
> implementations: the BBN-TENEX and LSI-11 for the Packet Radio project,
> my own PDP-11/40 Unix implementation as part of a Network Security
> research program, Sax/Edmond's HP-3000 code, Braden's IBM work at UCLA,
> Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax
> implementation. Probably more I've forgotten. Wingfield's PDP-11/70
> was funded, IIRC, by DCEC, the research arm of DCA - so it represented a
> tiny step from the research/ARPA world into the operational side.
>
> ARPA also paid for development of OSes, in particular BSD. As the TCP
> implementations were completed, ARPA stopped funding further
> TCP-specific work
>
>
While I generally agree with Jack's note, I have one correction. ARPA did
not stop funding further TCP-specific work at the end of this list. ARPA
continued the BBN TCP project (originally Jack's project, then managed by
Rob Gurwitz, then handed to me) until either 1989 or 1991-2. Most of the
work
was with the TCP/IP code but not specifically on TCP but other enhancements
such as IP multicast.

Thanks!

Craig

--
*****
Craig Partridge's email account for professional society activities and
mailing lists.
For Raytheon business, please email: craig. <***@bbn.com>
***@raytheon.com

[Paul Ruizendaal]

This is the internet history list, not the computer architecture history list, so I’d like to close this thread with a brief summary of on and off list responses.


The MBB processor:

The MBB processor is documented in this paper (available from the ACM library, unfortunately behind a paywall):
M. F. Kraley, R. D. Rettberg, P. Herman, R. D. Bressler, and A. Lake, “Design of a User-Microprogrammable Building Block” in Proceedings of the 13th Annual Microprogramming Workshop, IEEE, New York, 1980.
It is an interesting read and I can certainly recommend it; it also discusses some aspects of the C/30 and C/70 configurations.

The MBB processor seems to have been word (not byte) addressable, with 20 bit addresses and data paths. It is highly reminiscent of the Alto, with I/O device controllers partially implemented in microcode. It is also somewhat reminiscent of the TI990 and the later Sparc in that it had 1024 registers with a visible window of 16 registers. It is unique in that the processor had two optional daughter boards to customise the system: (i) a board to assist with macro-instruction decoding, (ii) an MMU board.

The C/30 version seems to have had a macro-instruction daughter board, but with addresses going straight through. When used as an IMP, some 30% of microcycles seem to have gone on I/O processing and the remaining 70% on executing H316 code.

The C/70 version had both daughter boards. The MMU board divided the 1MW address space into 128 pages of 4KW, and had protection & dirty bits per page. It could hold page tables for up to 8 tasks. 128 pages by 4KW is only 19 bits, perhaps the MMU board used 1 bit to simulate byte accesses. Apparently, there was also a ‘switch’ version of the C/70, without the MMU board and running a minimal OS (but using the “C” microcode & board).

The C/70 seems to have implemented a load/store type architecture with 40 basic instructions, each offering one of 19 addressing modes in an orthogonal setup. The 19 addressing modes were designed around typical C data access operations. Next to that there were 44 specialised instructions.

Procedure calls were very fast, as specialised instructions existed to switch to a new register bank as part of the call, with spilling to main memory upon deep recursion. Apparently it was possible for C code to ‘call' into microcode, and this may be how system calls were done.

According to the paper mentioned above, it is all documented in detail in the "MBB Microprogrammer's Handbook" BBN Report No. 4268, Feb. 1980. Unfortunately, this document does not seem to be available on the DTIC website.


BBN-UNIX for the C/70:

This was a port of the V7 based Unix that BBN had running on the PDP11, with various BSD-type extensions. It had the Gurwitz TCP/IP stack integrated, and accessible via the Gurwitz API (which was compatible with the earlier NCP Unix API). I would guess that some of the earlier IPC features (Haverty’s await() and capac() calls, shared memory areas) were also available.

I’m highly intrigued by this, as some of my own experiments in the past year have been along similar lines (but on 16 bit hardware).