From joly at punkcast.com  Sun Oct  1 11:19:52 2017
From: joly at punkcast.com (Joly MacFie)
Date: Sun, 1 Oct 2017 14:19:52 -0400
Subject: [ih] EMISARI
Message-ID: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>

?Listening to PBS yesterday, there was an interveiew about the history of
FEMA, and they mentioned EMISARI as being the Ur of chat software. I had
heard of PLATO and EIES, but never EMISARI.

I googled and found 1) a related story in Wired -
https://www.wired.com/story/the-secret-history-of-fema/ and 2) this book
excerpt http://bit.ly/2fIe8Qw

Questions: Packet-based? Relied on a central server? Any further insights?

?It would seem Murray Turoff deserves wider recognition.
?https://en.wikipedia.org/wiki/Murray_Turoff


-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171001/89f1db43/attachment.htm>

From us.m.h at ieee.org  Sun Oct  1 13:32:31 2017
From: us.m.h at ieee.org (Marc Handelman)
Date: Sun, 01 Oct 2017 13:32:31 -0700
Subject: [ih] EMISARI
In-Reply-To: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>
References: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>
Message-ID: <0A439EE9-CEB7-4B07-8120-655DA5028A3C@ieee.org>

Joly,

 

EMISARI was ?mainframe based (corroborated here: https://www.livinginternet.com/r/ri_emisari.htm ).

 

Marc Handelman

us.m.h at ieee.org

 

From: <internet-history-bounces at postel.org> on behalf of Joly MacFie <joly at punkcast.com>
Reply-To: <joly at punkcast.com>
Date: Sunday, October 1, 2017 at 11:38
To: "internet-history at postel.org" <internet-history at postel.org>
Subject: [ih] EMISARI

 


?Listening to PBS yesterday, there was an interveiew about the history of FEMA, and they mentioned EMISARI as being the Ur of chat software. I had heard of PLATO and EIES, but never EMISARI.

 

I googled and found 1) a related story in Wired - https://www.wired.com/story/the-secret-history-of-fema/ and 2) this book excerpt http://bit.ly/2fIe8Qw

 

Questions: Packet-based? Relied on a central server? Any further insights?

 

?It would seem Murray Turoff deserves wider recognition.

?https://en.wikipedia.org/wiki/Murray_Turoff

 

 

-- 

---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171001/5dabd684/attachment.htm>

From jack at 3kitty.org  Sun Oct  1 13:51:27 2017
From: jack at 3kitty.org (Jack Haverty)
Date: Sun, 1 Oct 2017 13:51:27 -0700
Subject: [ih] EMISARI
In-Reply-To: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>
References: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>
Message-ID: <8c4a4c30-9171-33cd-5780-8cec1439ba49@3kitty.org>

I've also never heard "EMISARI".  However, if done in 1971, I suspect it
was a "central server" implementation.  All the users would have been on
terminals (aka "dumb terminals") connected to the same computer.

By the 1971 timeframe, "mail" was present on a variety of computers.
For example, several of these are captured in the materials from the
ICCC '72 conference in Washington.  In some systems at least, you could
hold a "conference call" of sorts by simply mailing to the list of
others in the group.  We did this at MIT for such earth-shaking
utterances as "Anybody interested in lunch?".  There was also a
mechanism for "linking" two terminals together, so two people could
easily have a conversation.  All was on the same timeshared computer, or
perhaps a few same-manufacturer computers interconnected by phone lines.
 The notion of "server" came later with the ARPANET.

Even before 1971, people communicated using a computer.  I recall having
conversations with the system operator at an IBM installation in New
York, circa 1969, while I was logged in to that system over a phone line
from Cambridge.  That's for example how we users found out that the
system was going down for some reason.  Even before that, it was common
to send messages to the human operator even when submitting card decks
for batch runs - messages such as "Please mount tape xxxyyy for this job".

Professor Licklider did a lot early on in this area.  E.g., he
orchestrated the creation of Project MAC at MIT in the early 60s.  Among
other things, MAC stood for Man And Computer.  We did a lot of work on
"Messaging" in the early 70s, which you'd now recognize as email.

It would be interesting to see a comprehensive history of man/computer
communications.  Packet-switching did not enable such usage; its
motivation was to improve efficiency of use of expensive telephone
lines.   After packet-switching appeared, the economics then enabled
large-scale usage.

IMHO,
/Jack


On 10/01/2017 11:19 AM, Joly MacFie wrote:
> 
> ?Listening to PBS yesterday, there was an interveiew about the history
> of FEMA, and they mentioned EMISARI as being the Ur of chat software. I
> had heard of PLATO and EIES, but never EMISARI.
> 
> I googled and found 1) a related story in Wired
> -?https://www.wired.com/story/the-secret-history-of-fema/ and 2) this
> book excerpt?http://bit.ly/2fIe8Qw
> 
> Questions: Packet-based? Relied on a central server? Any further insights?
> 
> ?It would seem Murray Turoff deserves wider recognition.
> ?https://en.wikipedia.org/wiki/Murray_Turoff
> 
> 
> -- 
> ---------------------------------------------------------------
> Joly MacFie? 218 565 9365 Skype:punkcast
> --------------------------------------------------------------
> -
> 
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


From alan at clegg.com  Sun Oct  1 13:54:24 2017
From: alan at clegg.com (Alan Clegg)
Date: Sun, 1 Oct 2017 16:54:24 -0400
Subject: [ih] EMISARI
In-Reply-To: <0A439EE9-CEB7-4B07-8120-655DA5028A3C@ieee.org>
References: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>
	<0A439EE9-CEB7-4B07-8120-655DA5028A3C@ieee.org>
Message-ID: <d7771f0f-86ac-333c-37b8-ea750c53be49@clegg.com>

Interesting article... and interesting "IRC History" that doesn't even
mention RELAY on BITNET.  *sigh*

On 10/1/17 4:32 PM, Marc Handelman wrote:
> Joly,
> 
> ?
> 
> EMISARI was ?mainframe based (corroborated here:
> https://www.livinginternet.com/r/ri_emisari.htm ).
> 
> ?
> 
> Marc Handelman
> 
> us.m.h at ieee.org
> 
> ?
> 
> *From: *<internet-history-bounces at postel.org> on behalf of Joly MacFie
> <joly at punkcast.com>
> *Reply-To: *<joly at punkcast.com>
> *Date: *Sunday, October 1, 2017 at 11:38
> *To: *"internet-history at postel.org" <internet-history at postel.org>
> *Subject: *[ih] EMISARI
> 
> ?
> 
> 
> ?Listening to PBS yesterday, there was an interveiew about the history
> of FEMA, and they mentioned EMISARI as being the Ur of chat software. I
> had heard of PLATO and EIES, but never EMISARI.
> 
> ?
> 
> I googled and found 1) a related story in Wired
> -?https://www.wired.com/story/the-secret-history-of-fema/ and 2) this
> book excerpt?http://bit.ly/2fIe8Qw
> 
> ?
> 
> Questions: Packet-based? Relied on a central server? Any further insights?
> 
> ?
> 
> ?It would seem Murray Turoff deserves wider recognition.
> 
> ?https://en.wikipedia.org/wiki/Murray_Turoff
> 
> ?
> 
> ?
> 
> -- 
> 
> ---------------------------------------------------------------
> Joly MacFie? 218 565 9365 Skype:punkcast
> --------------------------------------------------------------
> -
> 
> _______ internet-history mailing list internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history Contact
> list-owner at postel.org for assistance.
> 
> 
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171001/269c50b3/attachment.asc>

From us.m.h at ieee.org  Sun Oct  1 14:56:16 2017
From: us.m.h at ieee.org (Marc Handelman)
Date: Sun, 01 Oct 2017 14:56:16 -0700
Subject: [ih] EMISARI
In-Reply-To: <d7771f0f-86ac-333c-37b8-ea750c53be49@clegg.com>
References: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>
	<0A439EE9-CEB7-4B07-8120-655DA5028A3C@ieee.org>
	<d7771f0f-86ac-333c-37b8-ea750c53be49@clegg.com>
Message-ID: <A1E2F6A4-2F45-40D6-8464-97330EC11319@ieee.org>

Yes, I thought the lack of a reference to RELAY on BITNET, was both odd and disappointing...



On 10/1/17, 14:18, "Alan Clegg" <internet-history-bounces at postel.org on behalf of alan at clegg.com> wrote thusly:

    Interesting article... and interesting "IRC History" that doesn't even
    mention RELAY on BITNET.  *sigh*
    
    On 10/1/17 4:32 PM, Marc Handelman wrote:
    > Joly,
    > 
    >  
    > 
    > EMISARI was  mainframe based (corroborated here:
    > https://www.livinginternet.com/r/ri_emisari.htm ).
    > 
    >  
    > 
    > Marc Handelman
    > 
    > us.m.h at ieee.org
    > 
    >  
    > 
    > *From: *<internet-history-bounces at postel.org> on behalf of Joly MacFie
    > <joly at punkcast.com>
    > *Reply-To: *<joly at punkcast.com>
    > *Date: *Sunday, October 1, 2017 at 11:38
    > *To: *"internet-history at postel.org" <internet-history at postel.org>
    > *Subject: *[ih] EMISARI
    > 
    >  
    > 
    > 
    > ?Listening to PBS yesterday, there was an interveiew about the history
    > of FEMA, and they mentioned EMISARI as being the Ur of chat software. I
    > had heard of PLATO and EIES, but never EMISARI.
    > 
    >  
    > 
    > I googled and found 1) a related story in Wired
    > - https://www.wired.com/story/the-secret-history-of-fema/ and 2) this
    > book excerpt http://bit.ly/2fIe8Qw
    > 
    >  
    > 
    > Questions: Packet-based? Relied on a central server? Any further insights?
    > 
    >  
    > 
    > ?It would seem Murray Turoff deserves wider recognition.
    > 
    > ?https://en.wikipedia.org/wiki/Murray_Turoff
    > 
    >  
    > 
    >  
    > 
    > -- 
    > 
    > ---------------------------------------------------------------
    > Joly MacFie  218 565 9365 Skype:punkcast
    > --------------------------------------------------------------
    > -
    > 
    > _______ internet-history mailing list internet-history at postel.org
    > http://mailman.postel.org/mailman/listinfo/internet-history Contact
    > list-owner at postel.org for assistance.
    > 
    > 
    > 
    > _______
    > internet-history mailing list
    > internet-history at postel.org
    > http://mailman.postel.org/mailman/listinfo/internet-history
    > Contact list-owner at postel.org for assistance.
    > 
    
    _______
    internet-history mailing list
    internet-history at postel.org
    http://mailman.postel.org/mailman/listinfo/internet-history
    Contact list-owner at postel.org for assistance.
    





From us.m.h at ieee.org  Sun Oct  1 15:10:14 2017
From: us.m.h at ieee.org (Marc Handelman)
Date: Sun, 01 Oct 2017 15:10:14 -0700
Subject: [ih] EMISARI
In-Reply-To: <9F9FA488-6BB8-479D-8AB5-8FDB1034B782@ieee.org>
References: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>
	<0A439EE9-CEB7-4B07-8120-655DA5028A3C@ieee.org>
	<d7771f0f-86ac-333c-37b8-ea750c53be49@clegg.com>
	<9F9FA488-6BB8-479D-8AB5-8FDB1034B782@ieee.org>
Message-ID: <4BFBE7F0-395D-4632-BF34-7709E7FC2635@ieee.org>

...and then there?s Jeff Kell, the main force behind RELAY over BITNET: http://web.inter.nl.net/users/fred/relay/relhis.html




On 10/1/17, 14:56, "Marc Handelman" <us.m.h at ieee.org> wrote thusly:

    Yes, I thought the lack of a reference to RELAY on BITNET, was both odd and disappointing...
    
    
    
    On 10/1/17, 14:18, "Alan Clegg" <internet-history-bounces at postel.org on behalf of alan at clegg.com> wrote thusly:
    
        Interesting article... and interesting "IRC History" that doesn't even
        mention RELAY on BITNET.  *sigh*
        
        On 10/1/17 4:32 PM, Marc Handelman wrote:
        > Joly,
        > 
        >  
        > 
        > EMISARI was  mainframe based (corroborated here:
        > https://www.livinginternet.com/r/ri_emisari.htm ).
        > 
        >  
        > 
        > Marc Handelman
        > 
        > us.m.h at ieee.org
        > 
        >  
        > 
        > *From: *<internet-history-bounces at postel.org> on behalf of Joly MacFie
        > <joly at punkcast.com>
        > *Reply-To: *<joly at punkcast.com>
        > *Date: *Sunday, October 1, 2017 at 11:38
        > *To: *"internet-history at postel.org" <internet-history at postel.org>
        > *Subject: *[ih] EMISARI
        > 
        >  
        > 
        > 
        > ?Listening to PBS yesterday, there was an interveiew about the history
        > of FEMA, and they mentioned EMISARI as being the Ur of chat software. I
        > had heard of PLATO and EIES, but never EMISARI.
        > 
        >  
        > 
        > I googled and found 1) a related story in Wired
        > - https://www.wired.com/story/the-secret-history-of-fema/ and 2) this
        > book excerpt http://bit.ly/2fIe8Qw
        > 
        >  
        > 
        > Questions: Packet-based? Relied on a central server? Any further insights?
        > 
        >  
        > 
        > ?It would seem Murray Turoff deserves wider recognition.
        > 
        > ?https://en.wikipedia.org/wiki/Murray_Turoff
        > 
        >  
        > 
        >  
        > 
        > -- 
        > 
        > ---------------------------------------------------------------
        > Joly MacFie  218 565 9365 Skype:punkcast
        > --------------------------------------------------------------
        > -
        > 
        > _______ internet-history mailing list internet-history at postel.org
        > http://mailman.postel.org/mailman/listinfo/internet-history Contact
        > list-owner at postel.org for assistance.
        > 
        > 
        > 
        > _______
        > internet-history mailing list
        > internet-history at postel.org
        > http://mailman.postel.org/mailman/listinfo/internet-history
        > Contact list-owner at postel.org for assistance.
        > 
        
        _______
        internet-history mailing list
        internet-history at postel.org
        http://mailman.postel.org/mailman/listinfo/internet-history
        Contact list-owner at postel.org for assistance.
        
    





From Guillaume.Latzko-Toth at com.ulaval.ca  Sun Oct  1 15:12:19 2017
From: Guillaume.Latzko-Toth at com.ulaval.ca (Guillaume Latzko-Toth)
Date: Sun, 1 Oct 2017 22:12:19 +0000
Subject: [ih] EMISARI
In-Reply-To: <d7771f0f-86ac-333c-37b8-ea750c53be49@clegg.com>
References: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>
	<0A439EE9-CEB7-4B07-8120-655DA5028A3C@ieee.org>
	<d7771f0f-86ac-333c-37b8-ea750c53be49@clegg.com>
Message-ID: <EA873FAC-1A4A-4FDA-9343-6E9B34EA119A@com.ulaval.ca>

If you are interested in the history of online chat programs, protocols, and systems (including EMISARI, Relay, CompuServe, IRC...), you might enjoy reading the attached paper I published in 2010 in a special issue of the Bulletin of Science, Technology and Society. The paper benefited from archived contributions to this list so I think it's fair enough to share it here :) I have also published papers on IRC history (particularly EFnet and Undernet), and I have another paper under review which includes a case study of BITNET Relay. Email me if you are interested in them. Suggestions, corrections, and testimonies are much welcome as I am working with a colleague on a new paper on chat history and possibly a book.

Guillaume Latzko-Toth
Universit? Laval, Quebec City

Le 01/10/2017 17:17, ? internet-history-bounces at postel.org au nom de Alan Clegg ? <internet-history-bounces at postel.org au nom de alan at clegg.com> a ?crit :

    Interesting article... and interesting "IRC History" that doesn't even
    mention RELAY on BITNET.  *sigh*
    
    On 10/1/17 4:32 PM, Marc Handelman wrote:
    > Joly,
    > 
    >  
    > 
    > EMISARI was  mainframe based (corroborated here:
    > https://www.livinginternet.com/r/ri_emisari.htm ).
    > 
    >  
    > 
    > Marc Handelman
    > 
    > us.m.h at ieee.org
    > 
    >  
    > 
    > *From: *<internet-history-bounces at postel.org> on behalf of Joly MacFie
    > <joly at punkcast.com>
    > *Reply-To: *<joly at punkcast.com>
    > *Date: *Sunday, October 1, 2017 at 11:38
    > *To: *"internet-history at postel.org" <internet-history at postel.org>
    > *Subject: *[ih] EMISARI
    > 
    >  
    > 
    > 
    > ?Listening to PBS yesterday, there was an interveiew about the history
    > of FEMA, and they mentioned EMISARI as being the Ur of chat software. I
    > had heard of PLATO and EIES, but never EMISARI.
    > 
    >  
    > 
    > I googled and found 1) a related story in Wired
    > - https://www.wired.com/story/the-secret-history-of-fema/ and 2) this
    > book excerpt http://bit.ly/2fIe8Qw
    > 
    >  
    > 
    > Questions: Packet-based? Relied on a central server? Any further insights?
    > 
    >  
    > 
    > ?It would seem Murray Turoff deserves wider recognition.
    > 
    > ?https://en.wikipedia.org/wiki/Murray_Turoff
    > 
    >  
    > 
    >  
    > 
    > -- 
    > 
    > ---------------------------------------------------------------
    > Joly MacFie  218 565 9365 Skype:punkcast
    > --------------------------------------------------------------
    > -
    > 
    > _______ internet-history mailing list internet-history at postel.org
    > http://mailman.postel.org/mailman/listinfo/internet-history Contact
    > list-owner at postel.org for assistance.
    > 
    > 
    > 
    > _______
    > internet-history mailing list
    > internet-history at postel.org
    > http://mailman.postel.org/mailman/listinfo/internet-history
    > Contact list-owner at postel.org for assistance.
    > 
    
    

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Latzko-Toth (2010) Metaphors of Synchrony.pdf
Type: application/pdf
Size: 217476 bytes
Desc: Latzko-Toth (2010) Metaphors of Synchrony.pdf
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171001/e75817c1/attachment.pdf>

From jeanjour at comcast.net  Sun Oct  1 17:23:21 2017
From: jeanjour at comcast.net (John Day)
Date: Sun, 1 Oct 2017 20:23:21 -0400
Subject: [ih] EMISARI
In-Reply-To: <EA873FAC-1A4A-4FDA-9343-6E9B34EA119A@com.ulaval.ca>
References: <CAM9VJk3YKVpiggOP_HEpzaSdmJZL09xRjirrkreWPDbv46hjtQ@mail.gmail.com>
	<0A439EE9-CEB7-4B07-8120-655DA5028A3C@ieee.org>
	<d7771f0f-86ac-333c-37b8-ea750c53be49@clegg.com>
	<EA873FAC-1A4A-4FDA-9343-6E9B34EA119A@com.ulaval.ca>
Message-ID: <2A4B43B5-330E-46BF-8E84-37363C092FD4@comcast.net>

Then you need to go back to Jim Calvin?s teleconferencing programs on Tenex in 1971-2. I still have transcriptions of the conversations we had, some at designing new versions of the code we were using.

Take care,
John

> On Oct 1, 2017, at 18:12, Guillaume Latzko-Toth <Guillaume.Latzko-Toth at com.ulaval.ca> wrote:
> 
> If you are interested in the history of online chat programs, protocols, and systems (including EMISARI, Relay, CompuServe, IRC...), you might enjoy reading the attached paper I published in 2010 in a special issue of the Bulletin of Science, Technology and Society. The paper benefited from archived contributions to this list so I think it's fair enough to share it here :) I have also published papers on IRC history (particularly EFnet and Undernet), and I have another paper under review which includes a case study of BITNET Relay. Email me if you are interested in them. Suggestions, corrections, and testimonies are much welcome as I am working with a colleague on a new paper on chat history and possibly a book.
> 
> Guillaume Latzko-Toth
> Universit? Laval, Quebec City
> 
> Le 01/10/2017 17:17, ? internet-history-bounces at postel.org au nom de Alan Clegg ? <internet-history-bounces at postel.org au nom de alan at clegg.com> a ?crit :
> 
>    Interesting article... and interesting "IRC History" that doesn't even
>    mention RELAY on BITNET.  *sigh*
> 
>    On 10/1/17 4:32 PM, Marc Handelman wrote:
>> Joly,
>> 
>> 
>> 
>> EMISARI was  mainframe based (corroborated here:
>> https://www.livinginternet.com/r/ri_emisari.htm ).
>> 
>> 
>> 
>> Marc Handelman
>> 
>> us.m.h at ieee.org
>> 
>> 
>> 
>> *From: *<internet-history-bounces at postel.org> on behalf of Joly MacFie
>> <joly at punkcast.com>
>> *Reply-To: *<joly at punkcast.com>
>> *Date: *Sunday, October 1, 2017 at 11:38
>> *To: *"internet-history at postel.org" <internet-history at postel.org>
>> *Subject: *[ih] EMISARI
>> 
>> 
>> 
>> 
>> ?Listening to PBS yesterday, there was an interveiew about the history
>> of FEMA, and they mentioned EMISARI as being the Ur of chat software. I
>> had heard of PLATO and EIES, but never EMISARI.
>> 
>> 
>> 
>> I googled and found 1) a related story in Wired
>> - https://www.wired.com/story/the-secret-history-of-fema/ and 2) this
>> book excerpt http://bit.ly/2fIe8Qw
>> 
>> 
>> 
>> Questions: Packet-based? Relied on a central server? Any further insights?
>> 
>> 
>> 
>> ?It would seem Murray Turoff deserves wider recognition.
>> 
>> ?https://en.wikipedia.org/wiki/Murray_Turoff
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 
>> ---------------------------------------------------------------
>> Joly MacFie  218 565 9365 Skype:punkcast
>> --------------------------------------------------------------
>> -
>> 
>> _______ internet-history mailing list internet-history at postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history Contact
>> list-owner at postel.org for assistance.
>> 
>> 
>> 
>> _______
>> internet-history mailing list
>> internet-history at postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-owner at postel.org for assistance.
>> 
> 
> 
> 
> <Latzko-Toth (2010) Metaphors of Synchrony.pdf>_______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.




From joly at punkcast.com  Thu Oct  5 20:11:09 2017
From: joly at punkcast.com (Joly MacFie)
Date: Thu, 5 Oct 2017 23:11:09 -0400
Subject: [ih] Columbus Dispatch story on Compuserve
Message-ID: <CAM9VJk3qoz3yyvkC-WdXwATXreLuJ9BKkyNdLcdqjF97WFacjw@mail.gmail.com>

http://www.dispatch.com/news/20171001/now-shadow-of-its-former-self-compuserve-blazed-trails-online

??The big watershed event was when the internet was released from being a
government-funded thing to being a piece of public infrastructure,? Lambert
said. ?The most expensive asset we had ? the network ? all of sudden that
network was ubiquitous and cheap. That was really the beginning of the end.?

CompuServe attempted to deal with the threat of internet rivals by erecting
a home page and then by introducing an online service for novice users,
dubbed Wow! But after Wow! flopped after only eight months, it was clear
that the company had been resting on its laurels for too long.?

-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171005/0dd317af/attachment.htm>

From jtk at depaul.edu  Fri Oct  6 05:42:52 2017
From: jtk at depaul.edu (John Kristoff)
Date: Fri, 6 Oct 2017 07:42:52 -0500
Subject: [ih] RFC 1918 addresses
Message-ID: <20171006074252.545543f0@p50.localdomain>

Elsewhere someone asked why the prefixes defined in RFC 1918 (10/8,
172.12/12, 192.168/16) were the codified private prefixes.  Does anyone
know the definitive reason, if there was one, why these prefixes were
selected over or instead of any other?

Thank you,

John


From craig at tereschau.net  Fri Oct  6 05:59:31 2017
From: craig at tereschau.net (Craig Partridge)
Date: Fri, 6 Oct 2017 08:59:31 -0400
Subject: [ih] RFC 1918 addresses
In-Reply-To: <20171006074252.545543f0@p50.localdomain>
References: <20171006074252.545543f0@p50.localdomain>
Message-ID: <CAHQj4CfxzpRH5KaTHt7635zngkm6GwfGh5qZketsifuWjusrLw@mail.gmail.com>

As I recall, 10/8 was because it was the only prefix still around of that
size (having until recently been the ARPANET's IP network number).  I
suspect similar reasons drove the other two, but don't know as I wasn't
close to this process.

Craig

On Fri, Oct 6, 2017 at 8:42 AM, John Kristoff <jtk at depaul.edu> wrote:

> Elsewhere someone asked why the prefixes defined in RFC 1918 (10/8,
> 172.12/12, 192.168/16) were the codified private prefixes.  Does anyone
> know the definitive reason, if there was one, why these prefixes were
> selected over or instead of any other?
>
> Thank you,
>
> John
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>



-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.
For Raytheon business, please email: craig. <craig at bbn.com>
partridge at raytheon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171006/7bce9493/attachment.htm>

From jnc at mercury.lcs.mit.edu  Fri Oct  6 06:37:07 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  6 Oct 2017 09:37:07 -0400 (EDT)
Subject: [ih] RFC 1918 addresses
Message-ID: <20171006133707.6406518C08E@mercury.lcs.mit.edu>

    > From: Craig Partridge

    > As I recall, 10/8 was because it was the only prefix still around of
    > that size (having until recently been the ARPANET's IP network number).

I'm not sure about that - I think there were still A's around at the time
(although being hoarded).

But it was definitely picked because it _had_ been the ARPANet's number. There
was a lot of concern that even though the ARPANet was, by then, gone, various
ARPANet addresses were hard-wired into code, hither, thither and yon, and it
was felt that making net 10 addresses be 'local' would kill two birds with one
stone.

    > I suspect similar reasons drove the other two

Wasn't the C address something Sun had used? Or did it become common through
Sun after it was made the C address?

Probably a good place to look is in the later 'Assigned Numbers' RFCs, and see
if they had any use prior to asssignment to this.

    >> the prefixes defined in RFC 1918 ... 172.12/12, 192.168/16)

?? I had this bit set that they were an A, a B (/16) and a C (/24)? Or maybe
it was a block of B's and C's, resulting in the /12 and /16?

   Noel


From sob at sobco.com  Fri Oct  6 06:50:44 2017
From: sob at sobco.com (Scott O. Bradner)
Date: Fri, 6 Oct 2017 09:50:44 -0400
Subject: [ih] RFC 1918 addresses
In-Reply-To: <CAHQj4CfxzpRH5KaTHt7635zngkm6GwfGh5qZketsifuWjusrLw@mail.gmail.com>
References: <20171006074252.545543f0@p50.localdomain>
	<CAHQj4CfxzpRH5KaTHt7635zngkm6GwfGh5qZketsifuWjusrLw@mail.gmail.com>
Message-ID: <C06CBBE5-76DA-48FA-8AC9-46D6B4621E0C@sobco.com>

as an IPng AD I was ?in the loop? - 

10 was chosen not directly because it was the ARPANET assignment but
because a LOT of software had coded-in use of net 10 (because it was the ARPANET assignment)

Yakov suggested net 10 and Jon agreed (is what I recall)

Scott



> On Oct 6, 2017, at 8:59 AM, Craig Partridge <craig at tereschau.net> wrote:
> 
> As I recall, 10/8 was because it was the only prefix still around of that size (having until recently been the ARPANET's IP network number).  I suspect similar reasons drove the other two, but don't know as I wasn't close to this process.
> 
> Craig
> 
> On Fri, Oct 6, 2017 at 8:42 AM, John Kristoff <jtk at depaul.edu> wrote:
> Elsewhere someone asked why the prefixes defined in RFC 1918 (10/8,
> 172.12/12, 192.168/16) were the codified private prefixes.  Does anyone
> know the definitive reason, if there was one, why these prefixes were
> selected over or instead of any other?
> 
> Thank you,
> 
> John
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 
> 
> 
> -- 
> *****
> Craig Partridge's email account for professional society activities and mailing lists.
> For Raytheon business, please email: craig.partridge at raytheon.com
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.




From agmalis at gmail.com  Fri Oct  6 07:30:43 2017
From: agmalis at gmail.com (Andrew G. Malis)
Date: Fri, 6 Oct 2017 10:30:43 -0400
Subject: [ih] RFC 1918 addresses
In-Reply-To: <C06CBBE5-76DA-48FA-8AC9-46D6B4621E0C@sobco.com>
References: <20171006074252.545543f0@p50.localdomain>
	<CAHQj4CfxzpRH5KaTHt7635zngkm6GwfGh5qZketsifuWjusrLw@mail.gmail.com>
	<C06CBBE5-76DA-48FA-8AC9-46D6B4621E0C@sobco.com>
Message-ID: <CAA=duU1imPtHsZdjNjmFehXtEkN_wSNZvkxOQbLZ0DqD=i3uqA@mail.gmail.com>

My recollection agrees with Scott. As I recall, the other two ranges were
chosen because they were, at that time, in unallocated space and thus free
for allocation for this purpose.

Cheers,
Andy


On Fri, Oct 6, 2017 at 9:50 AM, Scott O. Bradner <sob at sobco.com> wrote:

> as an IPng AD I was ?in the loop? -
>
> 10 was chosen not directly because it was the ARPANET assignment but
> because a LOT of software had coded-in use of net 10 (because it was the
> ARPANET assignment)
>
> Yakov suggested net 10 and Jon agreed (is what I recall)
>
> Scott
>
>
>
> > On Oct 6, 2017, at 8:59 AM, Craig Partridge <craig at tereschau.net> wrote:
> >
> > As I recall, 10/8 was because it was the only prefix still around of
> that size (having until recently been the ARPANET's IP network number).  I
> suspect similar reasons drove the other two, but don't know as I wasn't
> close to this process.
> >
> > Craig
> >
> > On Fri, Oct 6, 2017 at 8:42 AM, John Kristoff <jtk at depaul.edu> wrote:
> > Elsewhere someone asked why the prefixes defined in RFC 1918 (10/8,
> > 172.12/12, 192.168/16) were the codified private prefixes.  Does anyone
> > know the definitive reason, if there was one, why these prefixes were
> > selected over or instead of any other?
> >
> > Thank you,
> >
> > John
> > _______
> > internet-history mailing list
> > internet-history at postel.org
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > Contact list-owner at postel.org for assistance.
> >
> >
> >
> > --
> > *****
> > Craig Partridge's email account for professional society activities and
> mailing lists.
> > For Raytheon business, please email: craig.partridge at raytheon.com
> > _______
> > internet-history mailing list
> > internet-history at postel.org
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > Contact list-owner at postel.org for assistance.
>
>
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171006/2ad5ec47/attachment.htm>

From johnl at iecc.com  Fri Oct  6 18:43:10 2017
From: johnl at iecc.com (John Levine)
Date: 7 Oct 2017 01:43:10 -0000
Subject: [ih] RFC 1918 addresses
In-Reply-To: <20171006133707.6406518C08E@mercury.lcs.mit.edu>
Message-ID: <20171007014310.5987.qmail@ary.lan>

In article <20171006133707.6406518C08E at mercury.lcs.mit.edu> you write:
>Probably a good place to look is in the later 'Assigned Numbers' RFCs, and see
>if they had any use prior to asssignment to this.

A quick grep finds the first mention of 172.12 and 192.168 in RFC
1597.  Nothing before that.

R's,
John


From joly at punkcast.com  Sat Oct 14 18:16:38 2017
From: joly at punkcast.com (Joly MacFie)
Date: Sat, 14 Oct 2017 21:16:38 -0400
Subject: [ih] Help identifying 1985 NIC
Message-ID: <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg@mail.gmail.com>

I am just doing some remedial work on the captions to the 2017 Internet
Hall of Fame Ceremony.

At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
global IP addresses from ?? sounds like ASI NIC?

Can someone clarify?

Thanks

joly

-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171014/1a8fe162/attachment.htm>

From brian.e.carpenter at gmail.com  Sat Oct 14 19:29:29 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Sun, 15 Oct 2017 15:29:29 +1300
Subject: [ih] Help identifying 1985 NIC
In-Reply-To: <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg@mail.gmail.com>
References: <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg@mail.gmail.com>
Message-ID: <131bf887-d777-939a-d2c0-92d6c1b37e79@gmail.com>

Presumably, ISI NIC. That's what there was in 1985.

Presumably, recorded in https://tools.ietf.org/html/rfc960
or https://tools.ietf.org/html/rfc990
The CERN class Bs, which I expected to find in the 1985 list,
only appeared in 1986. I didn't find JUNET in either list.

After RFC990, IP address assignments were no longer recorded
in the Assigned Numbers RFCs.

Regards
   Brian Carpenter



On 15/10/2017 14:16, Joly MacFie wrote:
> I am just doing some remedial work on the captions to the 2017 Internet
> Hall of Fame Ceremony.
> 
> At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
> global IP addresses from ?? sounds like ASI NIC?
> 
> Can someone clarify?
> 
> Thanks
> 
> joly
> 
> 
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


From joly at punkcast.com  Sun Oct 15 12:51:45 2017
From: joly at punkcast.com (Joly MacFie)
Date: Sun, 15 Oct 2017 15:51:45 -0400
Subject: [ih] Help identifying 1985 NIC
In-Reply-To: <131bf887-d777-939a-d2c0-92d6c1b37e79@gmail.com>
References: <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg@mail.gmail.com>
	<131bf887-d777-939a-d2c0-92d6c1b37e79@gmail.com>
Message-ID: <CAM9VJk2Mkj6w+DgF5Dd4AeSHf=p3bBjMRH3K8GL0r2_-tXmkOQ@mail.gmail.com>

Thank you!



On Sat, Oct 14, 2017 at 10:29 PM, Brian E Carpenter <
brian.e.carpenter at gmail.com> wrote:

> Presumably, ISI NIC. That's what there was in 1985.
>
> Presumably, recorded in https://tools.ietf.org/html/rfc960
> or https://tools.ietf.org/html/rfc990
> The CERN class Bs, which I expected to find in the 1985 list,
> only appeared in 1986. I didn't find JUNET in either list.
>
> After RFC990, IP address assignments were no longer recorded
> in the Assigned Numbers RFCs.
>
> Regards
>    Brian Carpenter
>
>
>
> On 15/10/2017 14:16, Joly MacFie wrote:
> > I am just doing some remedial work on the captions to the 2017 Internet
> > Hall of Fame Ceremony.
> >
> > At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
> > global IP addresses from ?? sounds like ASI NIC?
> >
> > Can someone clarify?
> >
> > Thanks
> >
> > joly
> >
> >
> >
> > _______
> > internet-history mailing list
> > internet-history at postel.org
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > Contact list-owner at postel.org for assistance.
> >
>



-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171015/042ffaba/attachment.htm>

From casner at acm.org  Sun Oct 15 18:53:23 2017
From: casner at acm.org (Stephen Casner)
Date: Sun, 15 Oct 2017 18:53:23 -0700 (PDT)
Subject: [ih] Help identifying 1985 NIC
In-Reply-To: <131bf887-d777-939a-d2c0-92d6c1b37e79@gmail.com>
References: <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg@mail.gmail.com>
	<131bf887-d777-939a-d2c0-92d6c1b37e79@gmail.com>
Message-ID: <alpine.OSX.2.21.1710151850130.83552@auge.attlocal.net>

I don't remember the activities at ISI ever having been referred to as
a Network Information Center, though.  When did the SRI NIC end?

                                                        -- Steve

On Sun, 15 Oct 2017, Brian E Carpenter wrote:

> Presumably, ISI NIC. That's what there was in 1985.
>
> Presumably, recorded in https://tools.ietf.org/html/rfc960
> or https://tools.ietf.org/html/rfc990
> The CERN class Bs, which I expected to find in the 1985 list,
> only appeared in 1986. I didn't find JUNET in either list.
>
> After RFC990, IP address assignments were no longer recorded
> in the Assigned Numbers RFCs.
>
> Regards
>    Brian Carpenter
>
>
>
> On 15/10/2017 14:16, Joly MacFie wrote:
> > I am just doing some remedial work on the captions to the 2017 Internet
> > Hall of Fame Ceremony.
> >
> > At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
> > global IP addresses from ?? sounds like ASI NIC?
> >
> > Can someone clarify?
> >
> > Thanks
> >
> > joly


From brian.e.carpenter at gmail.com  Sun Oct 15 20:25:02 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Mon, 16 Oct 2017 16:25:02 +1300
Subject: [ih] Help identifying 1985 NIC
In-Reply-To: <alpine.OSX.2.21.1710151850130.83552@auge.attlocal.net>
References: <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg@mail.gmail.com>
	<131bf887-d777-939a-d2c0-92d6c1b37e79@gmail.com>
	<alpine.OSX.2.21.1710151850130.83552@auge.attlocal.net>
Message-ID: <b760365d-33a5-c257-33a8-40ad7707bdd4@gmail.com>

On 16/10/2017 14:53, Stephen Casner wrote:
> I don't remember the activities at ISI ever having been referred to as
> a Network Information Center, though.  

True enough, but I don't see how 'SRI' could be misheard as 'ASI'.
Possibly it was a slip of the tongue. I haven't watched the video.

> When did the SRI NIC end?

October 1, 1991 according to Wikipedia.

   Brian

> 
>                                                         -- Steve
> 
> On Sun, 15 Oct 2017, Brian E Carpenter wrote:
> 
>> Presumably, ISI NIC. That's what there was in 1985.
>>
>> Presumably, recorded in https://tools.ietf.org/html/rfc960
>> or https://tools.ietf.org/html/rfc990
>> The CERN class Bs, which I expected to find in the 1985 list,
>> only appeared in 1986. I didn't find JUNET in either list.
>>
>> After RFC990, IP address assignments were no longer recorded
>> in the Assigned Numbers RFCs.
>>
>> Regards
>>    Brian Carpenter
>>
>>
>>
>> On 15/10/2017 14:16, Joly MacFie wrote:
>>> I am just doing some remedial work on the captions to the 2017 Internet
>>> Hall of Fame Ceremony.
>>>
>>> At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
>>> global IP addresses from ?? sounds like ASI NIC?
>>>
>>> Can someone clarify?
>>>
>>> Thanks
>>>
>>> joly
> 


From bob.hinden at gmail.com  Mon Oct 16 08:48:14 2017
From: bob.hinden at gmail.com (Bob Hinden)
Date: Mon, 16 Oct 2017 08:48:14 -0700
Subject: [ih] Help identifying 1985 NIC
In-Reply-To: <b760365d-33a5-c257-33a8-40ad7707bdd4@gmail.com>
References: <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg@mail.gmail.com>
	<131bf887-d777-939a-d2c0-92d6c1b37e79@gmail.com>
	<alpine.OSX.2.21.1710151850130.83552@auge.attlocal.net>
	<b760365d-33a5-c257-33a8-40ad7707bdd4@gmail.com>
Message-ID: <0FACA1DA-4743-4A6C-9F1C-6B398B9AA512@gmail.com>

Joly,

> On Oct 15, 2017, at 8:25 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
> 
> On 16/10/2017 14:53, Stephen Casner wrote:
>> I don't remember the activities at ISI ever having been referred to as
>> a Network Information Center, though.
> 
> True enough, but I don't see how 'SRI' could be misheard as 'ASI'.
> Possibly it was a slip of the tongue. I haven't watched the video.

I listened to the video, and to me it?s fairly clear he said SRI NIC.  To find out for sure, suggest you contact Shigeki Goto directly.

Bob



> 
>> When did the SRI NIC end?
> 
> October 1, 1991 according to Wikipedia.
> 
>   Brian
> 
>> 
>>                                                        -- Steve
>> 
>> On Sun, 15 Oct 2017, Brian E Carpenter wrote:
>> 
>>> Presumably, ISI NIC. That's what there was in 1985.
>>> 
>>> Presumably, recorded in https://tools.ietf.org/html/rfc960
>>> or https://tools.ietf.org/html/rfc990
>>> The CERN class Bs, which I expected to find in the 1985 list,
>>> only appeared in 1986. I didn't find JUNET in either list.
>>> 
>>> After RFC990, IP address assignments were no longer recorded
>>> in the Assigned Numbers RFCs.
>>> 
>>> Regards
>>>   Brian Carpenter
>>> 
>>> 
>>> 
>>> On 15/10/2017 14:16, Joly MacFie wrote:
>>>> I am just doing some remedial work on the captions to the 2017 Internet
>>>> Hall of Fame Ceremony.
>>>> 
>>>> At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
>>>> global IP addresses from ?? sounds like ASI NIC?
>>>> 
>>>> Can someone clarify?
>>>> 
>>>> Thanks
>>>> 
>>>> joly
>> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171016/df59eea8/attachment.asc>

From joly at punkcast.com  Mon Oct 16 08:57:58 2017
From: joly at punkcast.com (Joly MacFie)
Date: Mon, 16 Oct 2017 11:57:58 -0400
Subject: [ih] Help identifying 1985 NIC
In-Reply-To: <0FACA1DA-4743-4A6C-9F1C-6B398B9AA512@gmail.com>
References: <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg@mail.gmail.com>
	<131bf887-d777-939a-d2c0-92d6c1b37e79@gmail.com>
	<alpine.OSX.2.21.1710151850130.83552@auge.attlocal.net>
	<b760365d-33a5-c257-33a8-40ad7707bdd4@gmail.com>
	<0FACA1DA-4743-4A6C-9F1C-6B398B9AA512@gmail.com>
Message-ID: <CAM9VJk1rTRz-n_zF1xfdNbrZxj0dPAf-qJ+YMn4Mryy74=Bb2A@mail.gmail.com>

Yes I think I'll have to do that. There are a couple of names I couldn't
quite get too.

j

On Mon, Oct 16, 2017 at 11:48 AM, Bob Hinden <bob.hinden at gmail.com> wrote:

> Joly,
>
> > On Oct 15, 2017, at 8:25 PM, Brian E Carpenter <
> brian.e.carpenter at gmail.com> wrote:
> >
> > On 16/10/2017 14:53, Stephen Casner wrote:
> >> I don't remember the activities at ISI ever having been referred to as
> >> a Network Information Center, though.
> >
> > True enough, but I don't see how 'SRI' could be misheard as 'ASI'.
> > Possibly it was a slip of the tongue. I haven't watched the video.
>
> I listened to the video, and to me it?s fairly clear he said SRI NIC.  To
> find out for sure, suggest you contact Shigeki Goto directly.
>
> Bob
>
>
>
> >
> >> When did the SRI NIC end?
> >
> > October 1, 1991 according to Wikipedia.
> >
> >   Brian
> >
> >>
> >>                                                        -- Steve
> >>
> >> On Sun, 15 Oct 2017, Brian E Carpenter wrote:
> >>
> >>> Presumably, ISI NIC. That's what there was in 1985.
> >>>
> >>> Presumably, recorded in https://tools.ietf.org/html/rfc960
> >>> or https://tools.ietf.org/html/rfc990
> >>> The CERN class Bs, which I expected to find in the 1985 list,
> >>> only appeared in 1986. I didn't find JUNET in either list.
> >>>
> >>> After RFC990, IP address assignments were no longer recorded
> >>> in the Assigned Numbers RFCs.
> >>>
> >>> Regards
> >>>   Brian Carpenter
> >>>
> >>>
> >>>
> >>> On 15/10/2017 14:16, Joly MacFie wrote:
> >>>> I am just doing some remedial work on the captions to the 2017
> Internet
> >>>> Hall of Fame Ceremony.
> >>>>
> >>>> At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
> >>>> global IP addresses from ?? sounds like ASI NIC?
> >>>>
> >>>> Can someone clarify?
> >>>>
> >>>> Thanks
> >>>>
> >>>> joly
> >>
> > _______
> > internet-history mailing list
> > internet-history at postel.org
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > Contact list-owner at postel.org for assistance.
>
>


-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171016/7c00d34b/attachment.htm>

From crossd at gmail.com  Mon Oct 16 09:16:06 2017
From: crossd at gmail.com (Dan Cross)
Date: Mon, 16 Oct 2017 12:16:06 -0400
Subject: [ih] Help identifying 1985 NIC
In-Reply-To: <0FACA1DA-4743-4A6C-9F1C-6B398B9AA512@gmail.com>
References: <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg@mail.gmail.com>
	<131bf887-d777-939a-d2c0-92d6c1b37e79@gmail.com>
	<alpine.OSX.2.21.1710151850130.83552@auge.attlocal.net>
	<b760365d-33a5-c257-33a8-40ad7707bdd4@gmail.com>
	<0FACA1DA-4743-4A6C-9F1C-6B398B9AA512@gmail.com>
Message-ID: <CAEoi9W5js=DV_0VxnnK3Y3RHpYC6p45gBjESs90v6RbyuyPPTg@mail.gmail.com>

On Mon, Oct 16, 2017 at 11:48 AM, Bob Hinden <bob.hinden at gmail.com> wrote:
> Joly,
>
>> On Oct 15, 2017, at 8:25 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
>>
>> On 16/10/2017 14:53, Stephen Casner wrote:
>>> I don't remember the activities at ISI ever having been referred to as
>>> a Network Information Center, though.
>>
>> True enough, but I don't see how 'SRI' could be misheard as 'ASI'.
>> Possibly it was a slip of the tongue. I haven't watched the video.
>
> I listened to the video, and to me it?s fairly clear he said SRI NIC.  To find out for sure, suggest you contact Shigeki Goto directly.

I concur. He very clearly said "SRI NIC".

        - Dan C.



From b_a_denny at yahoo.com  Mon Oct 16 23:23:42 2017
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Tue, 17 Oct 2017 06:23:42 +0000 (UTC)
Subject: [ih] Help Identifying 1985 NIC
In-Reply-To: <mailman.1.1508168937.11276.internet-history@postel.org>
References: <mailman.1.1508168937.11276.internet-history@postel.org>
Message-ID: <2046140260.329902.1508221422861@mail.yahoo.com>

I haven't watched the video but I would think it would be the SRI NIC.? The date from Wikipedia when the contract ended sounds about right.? JJ Garcia-Luna-Aceves at UC Santa Cruz could tell you.? He was heavily involved with the last proposal effort for the NIC? at SRI.? Even though he was at SRI in 1985,? I am pretty sure JJ hadn't moved to the NIC yet.? I think Jake Feinler was still running things.? Ole Jacobsen could also probably fill you about the 1985 time period.? I am pretty sure he was part of the NIC during that time period.

barbara

      From: "internet-history-request at postel.org" <internet-history-request at postel.org>
 To: internet-history at postel.org 
 Sent: Monday, October 16, 2017 9:20 AM
 Subject: internet-history Digest, Vol 116, Issue 4
   
Send internet-history mailing list submissions to
??? internet-history at postel.org

To subscribe or unsubscribe via the World Wide Web, visit
??? http://mailman.postel.org/mailman/listinfo/internet-history
or, via email, send a message with subject or body 'help' to
??? internet-history-request at postel.org

You can reach the person managing the list at
??? internet-history-owner at postel.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of internet-history digest..."


Today's Topics:

? 1. Re: RFC 1918 addresses (John Levine)
? 2. Help identifying 1985 NIC (Joly MacFie)
? 3. Re: Help identifying 1985 NIC (Brian E Carpenter)
? 4. Re: Help identifying 1985 NIC (Joly MacFie)
? 5. Re: Help identifying 1985 NIC (Stephen Casner)
? 6. Re: Help identifying 1985 NIC (Brian E Carpenter)
? 7. Re: Help identifying 1985 NIC (Bob Hinden)


----------------------------------------------------------------------

Message: 1
Date: 7 Oct 2017 01:43:10 -0000
From: "John Levine" <johnl at iecc.com>
Subject: Re: [ih] RFC 1918 addresses
To: internet-history at postel.org
Cc: jnc at mercury.lcs.mit.edu
Message-ID: <20171007014310.5987.qmail at ary.lan>
Content-Type: text/plain; charset=utf-8

In article <20171006133707.6406518C08E at mercury.lcs.mit.edu> you write:
>Probably a good place to look is in the later 'Assigned Numbers' RFCs, and see
>if they had any use prior to asssignment to this.

A quick grep finds the first mention of 172.12 and 192.168 in RFC
1597.? Nothing before that.

R's,
John


------------------------------

Message: 2
Date: Sat, 14 Oct 2017 21:16:38 -0400
From: Joly MacFie <joly at punkcast.com>
Subject: [ih] Help identifying 1985 NIC
To: "internet-history at postel.org" <internet-history at postel.org>
Message-ID:
??? <CAM9VJk0SGzGu20S_17aJBPXpsdZwu3eV3enT8BnaO6r4BORnzg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I am just doing some remedial work on the captions to the 2017 Internet
Hall of Fame Ceremony.

At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
global IP addresses from ?? sounds like ASI NIC?

Can someone clarify?

Thanks

joly

-- 
---------------------------------------------------------------
Joly MacFie? 218 565 9365 Skype:punkcast
--------------------------------------------------------------
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/internet-history/attachments/20171014/1a8fe162/attachment-0001.html

------------------------------

Message: 3
Date: Sun, 15 Oct 2017 15:29:29 +1300
From: Brian E Carpenter <brian.e.carpenter at gmail.com>
Subject: Re: [ih] Help identifying 1985 NIC
To: joly at punkcast.com,??? "internet-history at postel.org"
??? <internet-history at postel.org>
Message-ID: <131bf887-d777-939a-d2c0-92d6c1b37e79 at gmail.com>
Content-Type: text/plain; charset=utf-8

Presumably, ISI NIC. That's what there was in 1985.

Presumably, recorded in https://tools.ietf.org/html/rfc960
or https://tools.ietf.org/html/rfc990
The CERN class Bs, which I expected to find in the 1985 list,
only appeared in 1986. I didn't find JUNET in either list.

After RFC990, IP address assignments were no longer recorded
in the Assigned Numbers RFCs.

Regards
? Brian Carpenter



On 15/10/2017 14:16, Joly MacFie wrote:
> I am just doing some remedial work on the captions to the 2017 Internet
> Hall of Fame Ceremony.
> 
> At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
> global IP addresses from ?? sounds like ASI NIC?
> 
> Can someone clarify?
> 
> Thanks
> 
> joly
> 
> 
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


------------------------------

Message: 4
Date: Sun, 15 Oct 2017 15:51:45 -0400
From: Joly MacFie <joly at punkcast.com>
Subject: Re: [ih] Help identifying 1985 NIC
To: Brian E Carpenter <brian.e.carpenter at gmail.com>
Cc: "internet-history at postel.org" <internet-history at postel.org>
Message-ID:
??? <CAM9VJk2Mkj6w+DgF5Dd4AeSHf=p3bBjMRH3K8GL0r2_-tXmkOQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thank you!



On Sat, Oct 14, 2017 at 10:29 PM, Brian E Carpenter <
brian.e.carpenter at gmail.com> wrote:

> Presumably, ISI NIC. That's what there was in 1985.
>
> Presumably, recorded in https://tools.ietf.org/html/rfc960
> or https://tools.ietf.org/html/rfc990
> The CERN class Bs, which I expected to find in the 1985 list,
> only appeared in 1986. I didn't find JUNET in either list.
>
> After RFC990, IP address assignments were no longer recorded
> in the Assigned Numbers RFCs.
>
> Regards
>? ? Brian Carpenter
>
>
>
> On 15/10/2017 14:16, Joly MacFie wrote:
> > I am just doing some remedial work on the captions to the 2017 Internet
> > Hall of Fame Ceremony.
> >
> > At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
> > global IP addresses from ?? sounds like ASI NIC?
> >
> > Can someone clarify?
> >
> > Thanks
> >
> > joly
> >
> >
> >
> > _______
> > internet-history mailing list
> > internet-history at postel.org
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > Contact list-owner at postel.org for assistance.
> >
>



-- 
---------------------------------------------------------------
Joly MacFie? 218 565 9365 Skype:punkcast
--------------------------------------------------------------
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/internet-history/attachments/20171015/042ffaba/attachment-0001.html

------------------------------

Message: 5
Date: Sun, 15 Oct 2017 18:53:23 -0700 (PDT)
From: Stephen Casner <casner at acm.org>
Subject: Re: [ih] Help identifying 1985 NIC
To: Brian E Carpenter <brian.e.carpenter at gmail.com>
Cc: "internet-history at postel.org" <internet-history at postel.org>
Message-ID: <alpine.OSX.2.21.1710151850130.83552 at auge.attlocal.net>
Content-Type: text/plain; charset=US-ASCII

I don't remember the activities at ISI ever having been referred to as
a Network Information Center, though.? When did the SRI NIC end?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- Steve

On Sun, 15 Oct 2017, Brian E Carpenter wrote:

> Presumably, ISI NIC. That's what there was in 1985.
>
> Presumably, recorded in https://tools.ietf.org/html/rfc960
> or https://tools.ietf.org/html/rfc990
> The CERN class Bs, which I expected to find in the 1985 list,
> only appeared in 1986. I didn't find JUNET in either list.
>
> After RFC990, IP address assignments were no longer recorded
> in the Assigned Numbers RFCs.
>
> Regards
>? ? Brian Carpenter
>
>
>
> On 15/10/2017 14:16, Joly MacFie wrote:
> > I am just doing some remedial work on the captions to the 2017 Internet
> > Hall of Fame Ceremony.
> >
> > At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
> > global IP addresses from ?? sounds like ASI NIC?
> >
> > Can someone clarify?
> >
> > Thanks
> >
> > joly


------------------------------

Message: 6
Date: Mon, 16 Oct 2017 16:25:02 +1300
From: Brian E Carpenter <brian.e.carpenter at gmail.com>
Subject: Re: [ih] Help identifying 1985 NIC
To: Stephen Casner <casner at acm.org>
Cc: "internet-history at postel.org" <internet-history at postel.org>
Message-ID: <b760365d-33a5-c257-33a8-40ad7707bdd4 at gmail.com>
Content-Type: text/plain; charset=utf-8

On 16/10/2017 14:53, Stephen Casner wrote:
> I don't remember the activities at ISI ever having been referred to as
> a Network Information Center, though.? 

True enough, but I don't see how 'SRI' could be misheard as 'ASI'.
Possibly it was a slip of the tongue. I haven't watched the video.

> When did the SRI NIC end?

October 1, 1991 according to Wikipedia.

? Brian

> 
>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- Steve
> 
> On Sun, 15 Oct 2017, Brian E Carpenter wrote:
> 
>> Presumably, ISI NIC. That's what there was in 1985.
>>
>> Presumably, recorded in https://tools.ietf.org/html/rfc960
>> or https://tools.ietf.org/html/rfc990
>> The CERN class Bs, which I expected to find in the 1985 list,
>> only appeared in 1986. I didn't find JUNET in either list.
>>
>> After RFC990, IP address assignments were no longer recorded
>> in the Assigned Numbers RFCs.
>>
>> Regards
>>? ? Brian Carpenter
>>
>>
>>
>> On 15/10/2017 14:16, Joly MacFie wrote:
>>> I am just doing some remedial work on the captions to the 2017 Internet
>>> Hall of Fame Ceremony.
>>>
>>> At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
>>> global IP addresses from ?? sounds like ASI NIC?
>>>
>>> Can someone clarify?
>>>
>>> Thanks
>>>
>>> joly
> 


------------------------------

Message: 7
Date: Mon, 16 Oct 2017 08:48:14 -0700
From: Bob Hinden <bob.hinden at gmail.com>
Subject: Re: [ih] Help identifying 1985 NIC
To: Joly MacFie <joly at punkcast.com>
Cc: "internet-history at postel.org" <internet-history at postel.org>,
??? Stephen Casner <casner at acm.org>
Message-ID: <0FACA1DA-4743-4A6C-9F1C-6B398B9AA512 at gmail.com>
Content-Type: text/plain; charset="utf-8"

Joly,

> On Oct 15, 2017, at 8:25 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
> 
> On 16/10/2017 14:53, Stephen Casner wrote:
>> I don't remember the activities at ISI ever having been referred to as
>> a Network Information Center, though.
> 
> True enough, but I don't see how 'SRI' could be misheard as 'ASI'.
> Possibly it was a slip of the tongue. I haven't watched the video.

I listened to the video, and to me it?s fairly clear he said SRI NIC.? To find out for sure, suggest you contact Shigeki Goto directly.

Bob



> 
>> When did the SRI NIC end?
> 
> October 1, 1991 according to Wikipedia.
> 
>? Brian
> 
>> 
>>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- Steve
>> 
>> On Sun, 15 Oct 2017, Brian E Carpenter wrote:
>> 
>>> Presumably, ISI NIC. That's what there was in 1985.
>>> 
>>> Presumably, recorded in https://tools.ietf.org/html/rfc960
>>> or https://tools.ietf.org/html/rfc990
>>> The CERN class Bs, which I expected to find in the 1985 list,
>>> only appeared in 1986. I didn't find JUNET in either list.
>>> 
>>> After RFC990, IP address assignments were no longer recorded
>>> in the Assigned Numbers RFCs.
>>> 
>>> Regards
>>>? Brian Carpenter
>>> 
>>> 
>>> 
>>> On 15/10/2017 14:16, Joly MacFie wrote:
>>>> I am just doing some remedial work on the captions to the 2017 Internet
>>>> Hall of Fame Ceremony.
>>>> 
>>>> At https://youtu.be/U0AQ9lYgFRU?t=3264  Shigeki Goto says he obtained
>>>> global IP addresses from ?? sounds like ASI NIC?
>>>> 
>>>> Can someone clarify?
>>>> 
>>>> Thanks
>>>> 
>>>> joly
>> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP
Url : http://mailman.postel.org/pipermail/internet-history/attachments/20171016/df59eea8/signature.bin

------------------------------

_______________________________________________
internet-history mailing list
internet-history at postel.org
http://mailman.postel.org/mailman/listinfo/internet-history
Contact list-owner at postel.org for assistance.


End of internet-history Digest, Vol 116, Issue 4
************************************************


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171017/d2c1e117/attachment.htm>

From brian.e.carpenter at gmail.com  Fri Oct 20 14:29:53 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Sat, 21 Oct 2017 10:29:53 +1300
Subject: [ih] Origin of the loopback interface
Message-ID: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>

Hi,

Over on ipv6 at ietf.org we're discussing the issue of how to assign an address to a node without assigning it to a specific physical or tunnel interface. This is a minor gap in the IPv6 addressing architecture spec, but it creates a terminology issue in various other places.

The thread started with the following message, and has got surprisingly long:
https://mailarchive.ietf.org/arch/msg/ipv6/U0QzAWpZTypF8gyZZ8HPfXZLOPM

So the question came up of when and where the term 'loopback interface' arose. Does anybody here have an answer for that?

Regards
   Brian Carpenter




From tte at cs.fau.de  Fri Oct 20 14:53:26 2017
From: tte at cs.fau.de (Toerless Eckert)
Date: Fri, 20 Oct 2017 23:53:26 +0200
Subject: [ih] NIC.DDN.MIL registrations ?
Message-ID: <20171020215326.GP20090@faui40p.informatik.uni-erlangen.de>

Are there any archives of the historic NIC.DDN.MIL registrations, especially the handles ?

Thanks
    Toerless


From vint at google.com  Fri Oct 20 17:08:50 2017
From: vint at google.com (Vint Cerf)
Date: Fri, 20 Oct 2017 20:08:50 -0400
Subject: [ih] Origin of the loopback interface
In-Reply-To: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
Message-ID: <CAHxHggdCw8iBzYkAfHtg_uh8fu36y5yXsai9yBuSjCkKR6DV1Q@mail.gmail.com>

i have this hazy feeling it might have originated in the port expander
adventure but it might simply have been a way to test TCP/IP locally
without actually leaving the computer.

v


On Fri, Oct 20, 2017 at 5:29 PM, Brian E Carpenter <
brian.e.carpenter at gmail.com> wrote:

> Hi,
>
> Over on ipv6 at ietf.org we're discussing the issue of how to assign an
> address to a node without assigning it to a specific physical or tunnel
> interface. This is a minor gap in the IPv6 addressing architecture spec,
> but it creates a terminology issue in various other places.
>
> The thread started with the following message, and has got surprisingly
> long:
> https://mailarchive.ietf.org/arch/msg/ipv6/U0QzAWpZTypF8gyZZ8HPfXZLOPM
>
> So the question came up of when and where the term 'loopback interface'
> arose. Does anybody here have an answer for that?
>
> Regards
>    Brian Carpenter
>
>
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>



-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171020/771b1723/attachment.htm>

From reed at reedmedia.net  Fri Oct 20 17:12:59 2017
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Fri, 20 Oct 2017 19:12:59 -0500 (CDT)
Subject: [ih] Origin of the loopback interface
In-Reply-To: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
Message-ID: <alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>

On Sat, 21 Oct 2017, Brian E Carpenter wrote:

> So the question came up of when and where the term 'loopback 
> interface' arose. Does anybody here have an answer for that?

In my BSD history research, the earliest reference (for BSD) I have is:

BBN had successful tests with establishing connections and transmitting
data between processes using the loopback 
mode.\cite{{bressler-bbn-198102}

% http://www.dtic.mil/dtic/tr/fulltext/u2/a096114.pdf
% R. D. Bressler
% for nov 1, 1980 to jan 31, 1981
% date stamped March 9, 1981
@BOOK{bressler-bbn-198102,
 editor = "Robert D. Bressler",
 title = "{Combined Quarterly Technical Report No. 20}",
 publisher = "Bolt, Beranek, and Newman Inc.",
 address = "Cambridge, Mass.",
 year = 1981,
 month = feb
}

Document page 82, PDF page 89
Now looking at it again  I see that term used multiple times. I now
see earlier references for loopback for IMP and 1822 interfaces and in 
early BBN reports but this is not about the "internet" interface as far 
as I can tell.

The ARPANET Interface Message Processor (IMP) Port Expander (PE)
Technical Report 1080-140-1
November, 1980
http://www.dtic.mil/dtic/tr/fulltext/u2/a155753.pdf
recreated at 
http://www.warthman.com/images/SRI%20ARPANET-IMP.book.pdf
talks about loopback mode.
(Also at same time it is mentioned in BBN Report No. 4526.)

The oldest Unix code reference I find is University of Illinois 'Network 
Unix' ncpk/drivers/net_ill.h
/* defines for accessing bits in the imp interface */
...
#define imloop          0000400 /* loop back */

but I don't see anything using it. I don't know date of that but the 
system was from 1974-1975 and the file stamp is May 17  1979. This code 
is not about internet loopback though.

As for the earliest Unix "internet" style loopback interface I find 
4.1c.1 BSD's /sys/netinet/if_loop.c. Maybe from Joy or Eric Cooper (even 
if Joy committed it).

D 4.1 81/11/29 22:18:03 wnj 1 0 00059/00000/00000
MRs:
COMMENTS:
date and time created 81/11/29 22:18:03 by wnj

4.1     /*      if_loop.c       4.1     81/11/29        */
4.1     
4.1     /*
4.1      * Loopback interface driver for protocol testing and timing.

This was after the initial BBN code being added to CSRG's SCCS and I 
don't see reference to it earlier in that code so I assume was not in 
the BBN deliverables. I think the BBN reference in regards to the VAX 
UNIX is using a loopback mode not in the Unix networking implementation 
itself, so may be the earliest implementation of internet driver for 
loopback interface. (It was originally hardcoded to be on 254 network, 
but on Dec 22, 1981 changed to be 127 (hardcoded). In March 1982, 
converted to use sockets and AF_INET. In May 1983, changed from 
127.0.0.0 (broadcast) to 127.0.0.1. The hardcoded address was removed in 
March 1985. This is the same code that ended up in the "greatest 
software ever written" :)

Jeremy C. Reed

echo Fybjyl jevgvat zl OFQ uvfgbel obbx. Cyrnfr xrrc nfxvat zr. | \
 tr "OQCFnortuvxyzabcefgjl" "BDPSabeghiklmnoprstwy"


From jack at 3kitty.org  Fri Oct 20 20:44:52 2017
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 20 Oct 2017 20:44:52 -0700
Subject: [ih] Origin of the loopback interface
In-Reply-To: <alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
Message-ID: <6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>

IIRC, loopback was a term used in modems at least as early as the late
60s.  Maybe before.  When a line was put "in loopback" all the data
going out onto the line was reflected directly back to the sender.

Looping was used as a primary operations tool in the ARPANET.  By
"looping a line" the NOC operator could determine what was likely to
have failed - the modem at either end, the line itself (backhoe attack),
or the interface card in the IMPs at either end of the line.    The IMPs
could trigger the "looping" capability of the modems to cause loops to
be established at the various points.  That was important to determine
whose Field Service to call to get a failure fixed.

When we implemented TCPs at BBN for various hardware choices, we
unabashedly adopted ideas and techniques from the ARPANET operational
experience.  So the notion of having a means to "loop" the network
interface was a natural feature to include.  The TCP spec itself didn't
contain such "fault isolation" tools, so things like ICMP echo were
defined to add such functionality in ICMP.

I wrote the first TCP (version 2) for Unix circa 1977-8 on a PDP-11/40.
It did not have a "loopback interface".  There simply wasn't room in
kernel memory for such niceties.  That Unix implementation was based on
Jim Mathis' earlier implementation for the LSI-11 and used in the Packet
Radio project.  It didn't have a loopback facility either.

Shortly thereafter, several other Unix TCP implementations were done: a
PDP-11/70 version (Wingfield/Nemeth) under DCEC sponsorship, an HP-3000
implementation (Sax/Edmond) under ARPA sponsorship, and a Vax
implementation (Gurwitz) under ARPA sponsorship.   Getting an
implementation to talk to itself by cobbling together some way to get
packets reflected back was a common early step in the test/debug of a
TCP implementation.

One of those Unix implementations may have introduced loopback
functionality.  I can't remember...  There is a lot of historical detail
at The Unix History Society (tuhs.org), including ancient listings,
which may be a good place to look.

So, the specific term "loopback interface" probably depends on the
context.  It may have been first used in Unix, but the concept of
"looping an interface" was much older.  It existed in modems, and in the
ARPANET, and in the Internet, and was used primarily for debugging and
fault isolation during operations.  When something works, you just keep
using it.....

I probably wrote that BBN QTR (or more accurately, badgered people into
writing their sections and then put it all together).  Bob (Bressler)
was officially the PI on the contracts, but he assigned all of the
Internet-related projects to me.  Eventually we changed the name so I
was author of later QTRs.  So if there's any other questions about BBN's
Internet work in that timeframe I might be able to answer.

HTH,
/Jack Haverty

On 10/20/2017 05:12 PM, Jeremy C. Reed wrote:
> On Sat, 21 Oct 2017, Brian E Carpenter wrote:
> 
>> So the question came up of when and where the term 'loopback 
>> interface' arose. Does anybody here have an answer for that?
> 
> In my BSD history research, the earliest reference (for BSD) I have is:
> 
> BBN had successful tests with establishing connections and transmitting
> data between processes using the loopback 
> mode.\cite{{bressler-bbn-198102}
> 
> % http://www.dtic.mil/dtic/tr/fulltext/u2/a096114.pdf
> % R. D. Bressler
> % for nov 1, 1980 to jan 31, 1981
> % date stamped March 9, 1981
> @BOOK{bressler-bbn-198102,
>  editor = "Robert D. Bressler",
>  title = "{Combined Quarterly Technical Report No. 20}",
>  publisher = "Bolt, Beranek, and Newman Inc.",
>  address = "Cambridge, Mass.",
>  year = 1981,
>  month = feb
> }
> 
> Document page 82, PDF page 89
> Now looking at it again  I see that term used multiple times. I now
> see earlier references for loopback for IMP and 1822 interfaces and in 
> early BBN reports but this is not about the "internet" interface as far 
> as I can tell.
> 
> The ARPANET Interface Message Processor (IMP) Port Expander (PE)
> Technical Report 1080-140-1
> November, 1980
> http://www.dtic.mil/dtic/tr/fulltext/u2/a155753.pdf
> recreated at 
> http://www.warthman.com/images/SRI%20ARPANET-IMP.book.pdf
> talks about loopback mode.
> (Also at same time it is mentioned in BBN Report No. 4526.)
> 
> The oldest Unix code reference I find is University of Illinois 'Network 
> Unix' ncpk/drivers/net_ill.h
> /* defines for accessing bits in the imp interface */
> ...
> #define imloop          0000400 /* loop back */
> 
> but I don't see anything using it. I don't know date of that but the 
> system was from 1974-1975 and the file stamp is May 17  1979. This code 
> is not about internet loopback though.
> 
> As for the earliest Unix "internet" style loopback interface I find 
> 4.1c.1 BSD's /sys/netinet/if_loop.c. Maybe from Joy or Eric Cooper (even 
> if Joy committed it).
> 
> D 4.1 81/11/29 22:18:03 wnj 1 0 00059/00000/00000
> MRs:
> COMMENTS:
> date and time created 81/11/29 22:18:03 by wnj
> 
> 4.1     /*      if_loop.c       4.1     81/11/29        */
> 4.1     
> 4.1     /*
> 4.1      * Loopback interface driver for protocol testing and timing.
> 
> This was after the initial BBN code being added to CSRG's SCCS and I 
> don't see reference to it earlier in that code so I assume was not in 
> the BBN deliverables. I think the BBN reference in regards to the VAX 
> UNIX is using a loopback mode not in the Unix networking implementation 
> itself, so may be the earliest implementation of internet driver for 
> loopback interface. (It was originally hardcoded to be on 254 network, 
> but on Dec 22, 1981 changed to be 127 (hardcoded). In March 1982, 
> converted to use sockets and AF_INET. In May 1983, changed from 
> 127.0.0.0 (broadcast) to 127.0.0.1. The hardcoded address was removed in 
> March 1985. This is the same code that ended up in the "greatest 
> software ever written" :)
> 
> Jeremy C. Reed
> 
> echo Fybjyl jevgvat zl OFQ uvfgbel obbx. Cyrnfr xrrc nfxvat zr. | \
>  tr "OQCFnortuvxyzabcefgjl" "BDPSabeghiklmnoprstwy"
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


From brian.e.carpenter at gmail.com  Fri Oct 20 20:59:26 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Sat, 21 Oct 2017 16:59:26 +1300
Subject: [ih] Free to a good home...
Message-ID: <27a1e33e-43af-8c3f-d19e-c7c704547e5f@gmail.com>

I need to clear some shelf space, so I'd be happy to send the following
ephemera to a new home, if anybody here is interested or can suggest
a suitable archive. I'd much prefer that to the recycling bin.
In chronological order:

J. Howlett, Report of the National Committee on Computer Networks, Department of Industry, London, October 1978.

J.H. Rutledge, OSI And SNA: A Perspective, IBM Washington Systems Center, Technical Bulletin GG22-9225, April 1981.

B.J. Nelson, Remote Procedure Call, Xerox PARC CSL-81-9, May 1981 (Bruce Nelson's Ph.D. dissertation at CMU, as republished by PARC).

Anonymous, Internet Transport Protocols, Xerox System Integration Standard XSIS 028112, December 1981 (XNS, not TCP/IP).

Anonymous, The Ethernet: A Local Area Network Data Link Layer and Physical Layer Specifications, Version 2, Digital Equipment Corporation, Intel, Xerox, AA-K759B-TK, November 1982 ("DIX Ethernet", before it went to IEEE).

P. Gladman (editor), Packet Switch Stream: A Basic Guide and Directory, British Telecom, August 1983 (commercial X.25 service).

Anonymous, Digital's Networks: An Architecture with a Future, Digital Equipment Corporation, 1984.

D. Oran (editor), Highlights from 25 years of the Computer Communication Review, CCR Volume 25 Number 1, January 1995.

Regards
   Brian Carpenter




From pnr at planet.nl  Sat Oct 21 02:18:19 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 21 Oct 2017 11:18:19 +0200
Subject: [ih] Origin of the loopback interface
In-Reply-To: <alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
Message-ID: <EF51B106-081F-4D40-A9B9-D6BE74D88489@planet.nl>


In documents about TCP/IP stacks from the 1978-1981 era there are often comments like "speed with local looping xx and speed looping through IMP xx". As Jack has pointed out, looping at various steps seems to have been standard practice at the time. I'm re-implementing some old stacks on vintage hardware and can confirm from first hand experience that a loopback interface is a convenient debugging setup.

Next, I can elaborate from the 1981 Gurwitz sources: it does not contain a loopback interface (device) as such, but the standard IMP device driver has #ifdef'ed code to operate either in normal mode or in loopback mode. The device driver configuration is still a simple hardcoded setup at this stage, with a comment saying that it is due to be reworked into a configurable setup.

The commit from Nov 1981 quoted below is very early in the 4.1+ networking development cycle, well before the release of 4.1a. As far as I can tell it is the first occurrence of a dedicated loopback device in the history of Arpa/Inet networking on Unix.


On 21 Oct 2017, at 2:12 , Jeremy C. Reed wrote:

> On Sat, 21 Oct 2017, Brian E Carpenter wrote:
> 
>> So the question came up of when and where the term 'loopback 
>> interface' arose. Does anybody here have an answer for that?
> 
> In my BSD history research, the earliest reference (for BSD) I have is:
> 
> BBN had successful tests with establishing connections and transmitting
> data between processes using the loopback 
> mode.\cite{{bressler-bbn-198102}
> 
> % http://www.dtic.mil/dtic/tr/fulltext/u2/a096114.pdf
> % R. D. Bressler
> % for nov 1, 1980 to jan 31, 1981
> % date stamped March 9, 1981
> @BOOK{bressler-bbn-198102,
> editor = "Robert D. Bressler",
> title = "{Combined Quarterly Technical Report No. 20}",
> publisher = "Bolt, Beranek, and Newman Inc.",
> address = "Cambridge, Mass.",
> year = 1981,
> month = feb
> }
> 
> Document page 82, PDF page 89
> Now looking at it again  I see that term used multiple times. I now
> see earlier references for loopback for IMP and 1822 interfaces and in 
> early BBN reports but this is not about the "internet" interface as far 
> as I can tell.
> 
> The ARPANET Interface Message Processor (IMP) Port Expander (PE)
> Technical Report 1080-140-1
> November, 1980
> http://www.dtic.mil/dtic/tr/fulltext/u2/a155753.pdf
> recreated at 
> http://www.warthman.com/images/SRI%20ARPANET-IMP.book.pdf
> talks about loopback mode.
> (Also at same time it is mentioned in BBN Report No. 4526.)
> 
> The oldest Unix code reference I find is University of Illinois 'Network 
> Unix' ncpk/drivers/net_ill.h
> /* defines for accessing bits in the imp interface */
> ...
> #define imloop          0000400 /* loop back */
> 
> but I don't see anything using it. I don't know date of that but the 
> system was from 1974-1975 and the file stamp is May 17  1979. This code 
> is not about internet loopback though.
> 
> As for the earliest Unix "internet" style loopback interface I find 
> 4.1c.1 BSD's /sys/netinet/if_loop.c. Maybe from Joy or Eric Cooper (even 
> if Joy committed it).
> 
> D 4.1 81/11/29 22:18:03 wnj 1 0 00059/00000/00000
> MRs:
> COMMENTS:
> date and time created 81/11/29 22:18:03 by wnj
> 
> 4.1     /*      if_loop.c       4.1     81/11/29        */
> 4.1     
> 4.1     /*
> 4.1      * Loopback interface driver for protocol testing and timing.
> 
> This was after the initial BBN code being added to CSRG's SCCS and I 
> don't see reference to it earlier in that code so I assume was not in 
> the BBN deliverables. I think the BBN reference in regards to the VAX 
> UNIX is using a loopback mode not in the Unix networking implementation 
> itself, so may be the earliest implementation of internet driver for 
> loopback interface. (It was originally hardcoded to be on 254 network, 
> but on Dec 22, 1981 changed to be 127 (hardcoded). In March 1982, 
> converted to use sockets and AF_INET. In May 1983, changed from 
> 127.0.0.0 (broadcast) to 127.0.0.1. The hardcoded address was removed in 
> March 1985. This is the same code that ended up in the "greatest 
> software ever written" :)
> 
> Jeremy C. Reed
> 
> echo Fybjyl jevgvat zl OFQ uvfgbel obbx. Cyrnfr xrrc nfxvat zr. | \
> tr "OQCFnortuvxyzabcefgjl" "BDPSabeghiklmnoprstwy"
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.




From pnr at planet.nl  Sat Oct 21 04:54:23 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 21 Oct 2017 13:54:23 +0200
Subject: [ih] BBN C-series computers
Message-ID: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>


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.





From dave.walden.family at gmail.com  Sat Oct 21 05:09:45 2017
From: dave.walden.family at gmail.com (Dave Walden)
Date: Sat, 21 Oct 2017 08:09:45 -0400
Subject: [ih] Origin of the loopback interface
In-Reply-To: <6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
Message-ID: <8130e620-b67f-c57a-a7aa-652497d31afb@gmail.com>

Search for "loop test" at 
http://www.dtic.mil/dtic/tr/fulltext/u2/686811.pdf , an early (the 
earliest?) BBN ARPANET IMP development report to ARPA.

Bob Kahn was our modem expert and knew what the (Bell 303?) modem could 
do.? See
 ?? http://www.walden-family.com/impcode/bbn-report-1877.pdf
and search for "loop test".?? While this is a 1973 revision of the 
report, I believe this description was in the original version of the 
report in 1969. My further memory is that such testing could be done 
remotely under software control.

On 10/20/2017 11:44 PM, Jack Haverty wrote:
> IIRC, loopback was a term used in modems at least as early as the late
> 60s.  Maybe before.  When a line was put "in loopback" all the data
> going out onto the line was reflected directly back to the sender.
>
> Looping was used as a primary operations tool in the ARPANET.  By
> "looping a line" the NOC operator could determine what was likely to
> have failed - the modem at either end, the line itself (backhoe attack),
> or the interface card in the IMPs at either end of the line.    The IMPs
> could trigger the "looping" capability of the modems to cause loops to
> be established at the various points.  That was important to determine
> whose Field Service to call to get a failure fixed.
>



From bernie at fantasyfarm.com  Sat Oct 21 05:41:33 2017
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Sat, 21 Oct 2017 08:41:33 -0400
Subject: [ih] Origin of the loopback interface
In-Reply-To: <8130e620-b67f-c57a-a7aa-652497d31afb@gmail.com>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>,
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>,
	<8130e620-b67f-c57a-a7aa-652497d31afb@gmail.com>
Message-ID: <59EB407D.14119.2E3CA797@bernie.fantasyfarm.com>

On 21 Oct 2017 at 8:09, Dave Walden wrote:

> Bob Kahn was our modem expert and knew what the (Bell 303?) modem could
> do.? See
>  ?? http://www.walden-family.com/impcode/bbn-report-1877.pdf
> and search for "loop test".?? While this is a 1973 revision of the 
> report, I believe this description was in the original version of the 
> report in 1969. My further memory is that such testing could be done 
> remotely under software control.

My memory, too.  On the a line test, the IMP would loop its interface, 
loop its modem, and remotely loop the far-end modem back at it.  This 
allowed it to figure out if a line outage was either the modem crapping 
out, the line being broken, or the remote IMP being down.

/Bernie\
-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       






From bernie at fantasyfarm.com  Sat Oct 21 05:58:55 2017
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Sat, 21 Oct 2017 08:58:55 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
Message-ID: <59EB448F.20767.2E4C8AD4@bernie.fantasyfarm.com>

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:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       





From vint at google.com  Sat Oct 21 06:02:38 2017
From: vint at google.com (Vint Cerf)
Date: Sat, 21 Oct 2017 09:02:38 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
Message-ID: <CAHxHggd6uc0ay0tq1yFj1n+BBmkMwcmTj6Pw0OjmjTr0si_4Ug@mail.gmail.com>

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 <pnr at 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-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>



-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171021/6aca79ac/attachment.htm>

From dave.walden.family at gmail.com  Sat Oct 21 06:11:54 2017
From: dave.walden.family at gmail.com (Dave Walden)
Date: Sat, 21 Oct 2017 09:11:54 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
Message-ID: <6700759c-dc9d-5d5f-3fb8-1178ab5d5ff8@gmail.com>

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-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>

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



From mfidelman at meetinghouse.net  Sat Oct 21 06:54:12 2017
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Sat, 21 Oct 2017 09:54:12 -0400
Subject: [ih] Origin of the loopback interface
In-Reply-To: <6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
Message-ID: <38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>

On 10/20/17 11:44 PM, Jack Haverty wrote:

> IIRC, loopback was a term used in modems at least as early as the late
> 60s.  Maybe before.  When a line was put "in loopback" all the data
> going out onto the line was reflected directly back to the sender.
>
> ....
>
> So, the specific term "loopback interface" probably depends on the
> context.  It may have been first used in Unix, but the concept of
> "looping an interface" was much older.  It existed in modems, and in the
> ARPANET, and in the Internet, and was used primarily for debugging and
> fault isolation during operations.  When something works, you just keep
> using it.....
>
>
The term "loopback" goes all the way back to early electrical circuits - 
bridging two wires with a cliplead, at various points, to test connectivity.

Miles Fidelman

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



From mfidelman at meetinghouse.net  Sat Oct 21 06:58:26 2017
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Sat, 21 Oct 2017 09:58:26 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
Message-ID: <a6fb6ced-fb17-0b3a-536c-b1243ac14b23@meetinghouse.net>

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-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.

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



From dave.walden.family at gmail.com  Sat Oct 21 07:56:46 2017
From: dave.walden.family at gmail.com (Dave Walden)
Date: Sat, 21 Oct 2017 10:56:46 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <a6fb6ced-fb17-0b3a-536c-b1243ac14b23@meetinghouse.net>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
	<a6fb6ced-fb17-0b3a-536c-b1243ac14b23@meetinghouse.net>
Message-ID: <d35583f3-8989-875d-2bd2-3b62b281b18f@gmail.com>

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




From bob.hinden at gmail.com  Sat Oct 21 08:36:00 2017
From: bob.hinden at gmail.com (Bob Hinden)
Date: Sat, 21 Oct 2017 08:36:00 -0700
Subject: [ih] BBN C-series computers
In-Reply-To: <d35583f3-8989-875d-2bd2-3b62b281b18f@gmail.com>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
	<a6fb6ced-fb17-0b3a-536c-b1243ac14b23@meetinghouse.net>
	<d35583f3-8989-875d-2bd2-3b62b281b18f@gmail.com>
Message-ID: <CA5F73E9-DD4E-4A68-8477-8296669EA955@gmail.com>

Dave,

> On Oct 21, 2017, at 7:56 AM, Dave Walden <dave.walden.family at 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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171021/8769df25/attachment.asc>

From amckenzie3 at yahoo.com  Sat Oct 21 09:36:36 2017
From: amckenzie3 at yahoo.com (Alex McKenzie)
Date: Sat, 21 Oct 2017 16:36:36 +0000 (UTC)
Subject: [ih] BBN C-series computers
In-Reply-To: <CA5F73E9-DD4E-4A68-8477-8296669EA955@gmail.com>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
	<a6fb6ced-fb17-0b3a-536c-b1243ac14b23@meetinghouse.net>
	<d35583f3-8989-875d-2bd2-3b62b281b18f@gmail.com>
	<CA5F73E9-DD4E-4A68-8477-8296669EA955@gmail.com>
Message-ID: <1916259050.1643878.1508603796729@mail.yahoo.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171021/279e5c1b/attachment.htm>

From johnl at iecc.com  Sat Oct 21 10:28:10 2017
From: johnl at iecc.com (John Levine)
Date: 21 Oct 2017 17:28:10 -0000
Subject: [ih] BBN C-series computers
In-Reply-To: <CA5F73E9-DD4E-4A68-8477-8296669EA955@gmail.com>
Message-ID: <20171021172810.90891.qmail@ary.lan>

In article <CA5F73E9-DD4E-4A68-8477-8296669EA955 at 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


From jack at 3kitty.org  Sat Oct 21 12:17:41 2017
From: jack at 3kitty.org (Jack Haverty)
Date: Sat, 21 Oct 2017 12:17:41 -0700
Subject: [ih] ARPA request for artifacts
Message-ID: <d5206168-9485-e0da-e958-ef31c616a64e@3kitty.org>

I haven't seen this posted here, but it seems like internet-history is
an obvious target audience.   The Internet is arguably one of ARPAs most
successful, enduring and visible creations.

ARPA is right now asking for submissions of "artifacts" of
ARPA-sponsored work, for use in an exhibition celebrating their 60th
anniversary in 2018.

The ARPA request is at:

https://www.fbo.gov/index?s=opportunity&mode=form&id=ba1d11de552f68e166b8395a9389f7fc&tab=core&_cview=0

There's a very short deadline for submissions (early November).   Sorry
about that, I just saw this announcement myself.

I may submit my binder with a listing of my original TCP code, the first
implementation for Unix; it seems like it might be an interesting artifact.

Surely some of us have interesting artifacts.

Surely some of us are interesting artifacts...

/Jack



From brian.e.carpenter at gmail.com  Sat Oct 21 12:36:32 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Sun, 22 Oct 2017 08:36:32 +1300
Subject: [ih] Origin of the loopback interface
In-Reply-To: <38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
Message-ID: <90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>

On 22/10/2017 02:54, Miles Fidelman wrote:
> On 10/20/17 11:44 PM, Jack Haverty wrote:
> 
>> IIRC, loopback was a term used in modems at least as early as the late
>> 60s.  Maybe before.  When a line was put "in loopback" all the data
>> going out onto the line was reflected directly back to the sender.
>>
>> ....
>>
>> So, the specific term "loopback interface" probably depends on the
>> context.  It may have been first used in Unix, but the concept of
>> "looping an interface" was much older.  It existed in modems, and in the
>> ARPANET, and in the Internet, and was used primarily for debugging and
>> fault isolation during operations.  When something works, you just keep
>> using it.....
>>
>>
> The term "loopback" goes all the way back to early electrical circuits - 
> bridging two wires with a cliplead, at various points, to test connectivity.

For sure. I would expect that it was standard practice in the days of
teleprinters and telegraphs, probably back into the 19th century. For the
notion of the loopback interface as a TCP/IP software construct, it seems
that BSD in 1981 is the origin.

We could have another little chat about the loopback address in IP. I reached
the conclusion last night that it was never really necessary. All the TCP/IP
stacks that I know will happily send a message to any of their own assigned
addresses, without putting it on the wire. So having a dedicated address for
loopback tests seems useless today.

Thanks for all the feedback.

    Brian
 


From jack at 3kitty.org  Sat Oct 21 13:29:45 2017
From: jack at 3kitty.org (Jack Haverty)
Date: Sat, 21 Oct 2017 13:29:45 -0700
Subject: [ih] Origin of the loopback interface
In-Reply-To: <90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
Message-ID: <a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>

Hi Brian,

When we were designing those initial capabilities into TCP/IP
implementations, we were thinking not only of how everything would be
used in everyday operation, but also how you would deal with problems -
when things were not working as expected.

Especially in those early days, IIRC things were more often not working
than working...  So tools, techniques, hooks, etc., for "fault
isolation" were introduced.  The early Internet was explicitly
considered an "experiment", so lots of functions were needed to control
and monitor that experiment.

Loopback functionality is an example.  So are other things, especially
in ICMP, e.g., Ping, Source Routing, timestamping, etc.  The IP
"options" in particular was a means for hopefully adding new tools no
one had thought of yet.

Still-popular tools like Traceroute were possible because of the hooks
we put in place.  For example, IP addressing was specifically set up to
provide each physical interface with an address.  So a gateway/router,
for example, had a separate IP address for each wire attached to it.
That made it possible to use Ping, source-routing, etc., to "loop back"
at many different points and determine exactly where a problem was
occurring.

The downside of that architectural choice of IP address per physical
port was one of the items in the list of "things to work on" - namely
"Multi-homed hosts".  Our conclusion at the time (circa 1978) was that
the advantages of having fault analysis tools exceeded the disadvantages
of not dealing well with IP nodes that had multiple physical ports -
something to be fixed "next year" as IPV4 phased into the next version.
Didn't quite happen that way...

So, I'd advise caution in concluding that some features are not needed
now, and were never really necessary.  I'd advise the IPV6 crew to think
about not only how things should work when they work, but also how to
deal with the situation when they don't.

/Jack


On 10/21/2017 12:36 PM, Brian E Carpenter wrote:
> On 22/10/2017 02:54, Miles Fidelman wrote:
>> On 10/20/17 11:44 PM, Jack Haverty wrote:
>>
>>> IIRC, loopback was a term used in modems at least as early as the late
>>> 60s.  Maybe before.  When a line was put "in loopback" all the data
>>> going out onto the line was reflected directly back to the sender.
>>>
>>> ....
>>>
>>> So, the specific term "loopback interface" probably depends on the
>>> context.  It may have been first used in Unix, but the concept of
>>> "looping an interface" was much older.  It existed in modems, and in the
>>> ARPANET, and in the Internet, and was used primarily for debugging and
>>> fault isolation during operations.  When something works, you just keep
>>> using it.....
>>>
>>>
>> The term "loopback" goes all the way back to early electrical circuits - 
>> bridging two wires with a cliplead, at various points, to test connectivity.
> 
> For sure. I would expect that it was standard practice in the days of
> teleprinters and telegraphs, probably back into the 19th century. For the
> notion of the loopback interface as a TCP/IP software construct, it seems
> that BSD in 1981 is the origin.
> 
> We could have another little chat about the loopback address in IP. I reached
> the conclusion last night that it was never really necessary. All the TCP/IP
> stacks that I know will happily send a message to any of their own assigned
> addresses, without putting it on the wire. So having a dedicated address for
> loopback tests seems useless today.
> 
> Thanks for all the feedback.
> 
>     Brian
>  
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


From vint at google.com  Sat Oct 21 13:54:57 2017
From: vint at google.com (Vint Cerf)
Date: Sat, 21 Oct 2017 16:54:57 -0400
Subject: [ih] Origin of the loopback interface
In-Reply-To: <a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
Message-ID: <CAHxHggep4kHrqxOJNAjOpNUmQNbpaWO+3UhQoKR33OaES+RAGA@mail.gmail.com>

+1
v


On Sat, Oct 21, 2017 at 4:29 PM, Jack Haverty <jack at 3kitty.org> wrote:

> Hi Brian,
>
> When we were designing those initial capabilities into TCP/IP
> implementations, we were thinking not only of how everything would be
> used in everyday operation, but also how you would deal with problems -
> when things were not working as expected.
>
> Especially in those early days, IIRC things were more often not working
> than working...  So tools, techniques, hooks, etc., for "fault
> isolation" were introduced.  The early Internet was explicitly
> considered an "experiment", so lots of functions were needed to control
> and monitor that experiment.
>
> Loopback functionality is an example.  So are other things, especially
> in ICMP, e.g., Ping, Source Routing, timestamping, etc.  The IP
> "options" in particular was a means for hopefully adding new tools no
> one had thought of yet.
>
> Still-popular tools like Traceroute were possible because of the hooks
> we put in place.  For example, IP addressing was specifically set up to
> provide each physical interface with an address.  So a gateway/router,
> for example, had a separate IP address for each wire attached to it.
> That made it possible to use Ping, source-routing, etc., to "loop back"
> at many different points and determine exactly where a problem was
> occurring.
>
> The downside of that architectural choice of IP address per physical
> port was one of the items in the list of "things to work on" - namely
> "Multi-homed hosts".  Our conclusion at the time (circa 1978) was that
> the advantages of having fault analysis tools exceeded the disadvantages
> of not dealing well with IP nodes that had multiple physical ports -
> something to be fixed "next year" as IPV4 phased into the next version.
> Didn't quite happen that way...
>
> So, I'd advise caution in concluding that some features are not needed
> now, and were never really necessary.  I'd advise the IPV6 crew to think
> about not only how things should work when they work, but also how to
> deal with the situation when they don't.
>
> /Jack
>
>
> On 10/21/2017 12:36 PM, Brian E Carpenter wrote:
> > On 22/10/2017 02:54, Miles Fidelman wrote:
> >> On 10/20/17 11:44 PM, Jack Haverty wrote:
> >>
> >>> IIRC, loopback was a term used in modems at least as early as the late
> >>> 60s.  Maybe before.  When a line was put "in loopback" all the data
> >>> going out onto the line was reflected directly back to the sender.
> >>>
> >>> ....
> >>>
> >>> So, the specific term "loopback interface" probably depends on the
> >>> context.  It may have been first used in Unix, but the concept of
> >>> "looping an interface" was much older.  It existed in modems, and in
> the
> >>> ARPANET, and in the Internet, and was used primarily for debugging and
> >>> fault isolation during operations.  When something works, you just keep
> >>> using it.....
> >>>
> >>>
> >> The term "loopback" goes all the way back to early electrical circuits -
> >> bridging two wires with a cliplead, at various points, to test
> connectivity.
> >
> > For sure. I would expect that it was standard practice in the days of
> > teleprinters and telegraphs, probably back into the 19th century. For the
> > notion of the loopback interface as a TCP/IP software construct, it seems
> > that BSD in 1981 is the origin.
> >
> > We could have another little chat about the loopback address in IP. I
> reached
> > the conclusion last night that it was never really necessary. All the
> TCP/IP
> > stacks that I know will happily send a message to any of their own
> assigned
> > addresses, without putting it on the wire. So having a dedicated address
> for
> > loopback tests seems useless today.
> >
> > Thanks for all the feedback.
> >
> >     Brian
> >
> > _______
> > internet-history mailing list
> > internet-history at postel.org
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > Contact list-owner at postel.org for assistance.
> >
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>



-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171021/26c792fc/attachment.htm>

From johnl at iecc.com  Sat Oct 21 14:44:31 2017
From: johnl at iecc.com (John Levine)
Date: 21 Oct 2017 21:44:31 -0000
Subject: [ih] Origin of the loopback interface
In-Reply-To: <a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
Message-ID: <20171021214431.91678.qmail@ary.lan>

A little greppage finds that class A network 127 is marked as Reserved
in RFCs 790. 820, 870, 900, 923, 943, and 960.  It is Loopback in RFCs
990, 997, and later ones.

The word loopback appears in other contexts in earlier RFCs but the
first application to IP I can find is in RFC 990 in 1986.

R's,
John


From brian.e.carpenter at gmail.com  Sat Oct 21 15:51:45 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Sun, 22 Oct 2017 11:51:45 +1300
Subject: [ih] Origin of the loopback interface
In-Reply-To: <a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
Message-ID: <3f4edf78-c146-e72f-d126-843ca93c3d52@gmail.com>

> So, I'd advise caution in concluding that some features are not needed
> now, and were never really necessary.  I'd advise the IPV6 crew to think
> about not only how things should work when they work, but also how to
> deal with the situation when they don't.

Absolutely, as a general principle.

Thanks very much,
   Brian Carpenter

On 22/10/2017 09:29, Jack Haverty wrote:
> Hi Brian,
> 
> When we were designing those initial capabilities into TCP/IP
> implementations, we were thinking not only of how everything would be
> used in everyday operation, but also how you would deal with problems -
> when things were not working as expected.
> 
> Especially in those early days, IIRC things were more often not working
> than working...  So tools, techniques, hooks, etc., for "fault
> isolation" were introduced.  The early Internet was explicitly
> considered an "experiment", so lots of functions were needed to control
> and monitor that experiment.
> 
> Loopback functionality is an example.  So are other things, especially
> in ICMP, e.g., Ping, Source Routing, timestamping, etc.  The IP
> "options" in particular was a means for hopefully adding new tools no
> one had thought of yet.
> 
> Still-popular tools like Traceroute were possible because of the hooks
> we put in place.  For example, IP addressing was specifically set up to
> provide each physical interface with an address.  So a gateway/router,
> for example, had a separate IP address for each wire attached to it.
> That made it possible to use Ping, source-routing, etc., to "loop back"
> at many different points and determine exactly where a problem was
> occurring.
> 
> The downside of that architectural choice of IP address per physical
> port was one of the items in the list of "things to work on" - namely
> "Multi-homed hosts".  Our conclusion at the time (circa 1978) was that
> the advantages of having fault analysis tools exceeded the disadvantages
> of not dealing well with IP nodes that had multiple physical ports -
> something to be fixed "next year" as IPV4 phased into the next version.
> Didn't quite happen that way...
> 
> So, I'd advise caution in concluding that some features are not needed
> now, and were never really necessary.  I'd advise the IPV6 crew to think
> about not only how things should work when they work, but also how to
> deal with the situation when they don't.
> 
> /Jack
> 
> 
> On 10/21/2017 12:36 PM, Brian E Carpenter wrote:
>> On 22/10/2017 02:54, Miles Fidelman wrote:
>>> On 10/20/17 11:44 PM, Jack Haverty wrote:
>>>
>>>> IIRC, loopback was a term used in modems at least as early as the late
>>>> 60s.  Maybe before.  When a line was put "in loopback" all the data
>>>> going out onto the line was reflected directly back to the sender.
>>>>
>>>> ....
>>>>
>>>> So, the specific term "loopback interface" probably depends on the
>>>> context.  It may have been first used in Unix, but the concept of
>>>> "looping an interface" was much older.  It existed in modems, and in the
>>>> ARPANET, and in the Internet, and was used primarily for debugging and
>>>> fault isolation during operations.  When something works, you just keep
>>>> using it.....
>>>>
>>>>
>>> The term "loopback" goes all the way back to early electrical circuits - 
>>> bridging two wires with a cliplead, at various points, to test connectivity.
>>
>> For sure. I would expect that it was standard practice in the days of
>> teleprinters and telegraphs, probably back into the 19th century. For the
>> notion of the loopback interface as a TCP/IP software construct, it seems
>> that BSD in 1981 is the origin.
>>
>> We could have another little chat about the loopback address in IP. I reached
>> the conclusion last night that it was never really necessary. All the TCP/IP
>> stacks that I know will happily send a message to any of their own assigned
>> addresses, without putting it on the wire. So having a dedicated address for
>> loopback tests seems useless today.
>>
>> Thanks for all the feedback.
>>
>>     Brian
>>  
>> _______
>> internet-history mailing list
>> internet-history at postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-owner at postel.org for assistance.
>>
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> .
> 


From paul at redbarn.org  Sun Oct 22 03:19:50 2017
From: paul at redbarn.org (Paul Vixie)
Date: Sun, 22 Oct 2017 03:19:50 -0700
Subject: [ih] Origin of the loopback interface
In-Reply-To: <a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
Message-ID: <59EC70C6.2020809@redbarn.org>



Brian Carpenter wrote:
>>  We could have another little chat about the loopback address in IP. I reached
>>  the conclusion last night that it was never really necessary. All the TCP/IP
>>  stacks that I know will happily send a message to any of their own assigned
>>  addresses, without putting it on the wire. So having a dedicated address for
>>  loopback tests seems useless today.

it's nowhere near useless. i use a some virtual machines that aren't on 
any network except their loopback. grateful am i that i can use IP 
sockets to talk to my own services in that case, rather than having to 
teach all my tooling, and the operating system's tools, to use UNIX 
domain sockets.

even when i have interfaces, they change their addresses, either due to 
DHCP, or mobility, or migration. grateful am i, again, that most(*) of 
my tools don't have to be able to reconnect their sockets when this 
happens. i realize that INADDR_ANY was crafted to solve that problem, 
but modern systems run different servers on the same port number, using 
interface address to disambiguate.

multihoming is one of the great unsolved problems in internetworking. we 
do it properly on routers -- there, the loopback has the router's "real" 
ip address -- but only because the router is on-path and can inject its 
loopback address (which usually is not subnetted) into the topology.

(*) name, file, and time servers have to know what interface they were 
contacted on, and answer from that interface, so they have to 
periodically rescan the interface list -- but nothing else does.

-- 
P Vixie



From johnl at iecc.com  Sun Oct 22 08:49:12 2017
From: johnl at iecc.com (John Levine)
Date: 22 Oct 2017 15:49:12 -0000
Subject: [ih] Origin of the loopback interface
In-Reply-To: <59EC70C6.2020809@redbarn.org>
Message-ID: <20171022154912.1254.qmail@ary.lan>

In article <59EC70C6.2020809 at redbarn.org> you write:
>Brian Carpenter wrote:
>>>  So having a dedicated address for
>>>  loopback tests seems useless today.
>
>it's nowhere near useless. i use a some virtual machines that aren't on 
>any network except their loopback. grateful am i that i can use IP 
>sockets to talk to my own services ...

Even on machines that do have physical interfaces, puting a service
on a loopback address lets me be sure it's only available to other
processes on the same machine without having to screw around with
packet filters.  The usual example is a DNS cache.

It seems to me that having a single loopback address rather than at
least a /64 is one of the more inexplicable misfeatures of IPv6.

R's,
John


From jeanjour at comcast.net  Sun Oct 22 10:46:46 2017
From: jeanjour at comcast.net (John Day)
Date: Sun, 22 Oct 2017 13:46:46 -0400
Subject: [ih] Origin of the loopback interface
In-Reply-To: <59EC70C6.2020809@redbarn.org>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
	<59EC70C6.2020809@redbarn.org>
Message-ID: <68FF96C0-8319-4976-8AD9-B4420332737E@comcast.net>

The problem was solved 50 years ago. It is just that the Internet doesn?t like the solution.


> 
> multihoming is one of the great unsolved problems in internetworking. we 
> do it properly on routers -- there, the loopback has the router's "real" 
> ip address -- but only because the router is on-path and can inject its 
> loopback address (which usually is not subnetted) into the topology.
> 
> (*) name, file, and time servers have to know what interface they were 
> contacted on, and answer from that interface, so they have to 
> periodically rescan the interface list -- but nothing else does.
> 
> -- 
> P Vixie
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.




From cloos at jhcloos.com  Sun Oct 22 11:26:25 2017
From: cloos at jhcloos.com (James Cloos)
Date: Sun, 22 Oct 2017 14:26:25 -0400
Subject: [ih] Origin of the loopback interface
In-Reply-To: <20171022154912.1254.qmail@ary.lan> (John Levine's message of "22
	Oct 2017 15:49:12 -0000")
References: <20171022154912.1254.qmail@ary.lan>
Message-ID: <m3o9oz3upa.fsf@carbon.jhcloos.org>

>>>>> "JL" == John Levine <johnl at iecc.com> writes:

JL> It seems to me that having a single loopback address rather than at
JL> least a /64 is one of the more inexplicable misfeatures of IPv6.

I always disliked that, too.  But we *can* use ::7f00:0000/104.

The only downside(?) is that assigning one address therein does not
automatically make the rest of the /104 work.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From brian.e.carpenter at gmail.com  Sun Oct 22 12:22:55 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Mon, 23 Oct 2017 08:22:55 +1300
Subject: [ih] Origin of the loopback interface
In-Reply-To: <59EC70C6.2020809@redbarn.org>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
	<59EC70C6.2020809@redbarn.org>
Message-ID: <5c586b3f-a741-67aa-f5ce-14520bfa92b6@gmail.com>

On 22/10/2017 23:19, Paul Vixie wrote:
> 
> 
> Brian Carpenter wrote:
>>>  We could have another little chat about the loopback address in IP. I reached
>>>  the conclusion last night that it was never really necessary. All the TCP/IP
>>>  stacks that I know will happily send a message to any of their own assigned
>>>  addresses, without putting it on the wire. So having a dedicated address for
>>>  loopback tests seems useless today.
> 
> it's nowhere near useless. 

I take your point. But parse my sentence: "for loopback *tests*". What you're
saying is that having an address that belongs to your own (virtual) machine
is beneficial for actual use, not just for tests. I agree with that.
It was the fact that it's conventionally assigned to a specific virtual
interface that caught my attention.

> i use a some virtual machines that aren't on 
> any network except their loopback. grateful am i that i can use IP 
> sockets to talk to my own services in that case, rather than having to 
> teach all my tooling, and the operating system's tools, to use UNIX 
> domain sockets.
> 
> even when i have interfaces, they change their addresses, either due to 
> DHCP, or mobility, or migration. grateful am i, again, that most(*) of 
> my tools don't have to be able to reconnect their sockets when this 
> happens. i realize that INADDR_ANY was crafted to solve that problem, 
> but modern systems run different servers on the same port number, using 
> interface address to disambiguate.
> 
> multihoming is one of the great unsolved problems in internetworking. we 
> do it properly on routers -- there, the loopback has the router's "real" 
> ip address -- but only because the router is on-path and can inject its 
> loopback address (which usually is not subnetted) into the topology.
> 
> (*) name, file, and time servers have to know what interface they were 
> contacted on, and answer from that interface, so they have to 
> periodically rescan the interface list -- but nothing else does.

Actually the stuff we're developing in ANIMA needs to know exactly
which interfaces it's using too. That's one reason that I got
interested in this topic.

     Brian


From agmalis at gmail.com  Sun Oct 22 19:39:45 2017
From: agmalis at gmail.com (Andrew G. Malis)
Date: Sun, 22 Oct 2017 22:39:45 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <20171021172810.90891.qmail@ary.lan>
References: <CA5F73E9-DD4E-4A68-8477-8296669EA955@gmail.com>
	<20171021172810.90891.qmail@ary.lan>
Message-ID: <CAA=duU3p7tbK70i49J=EPmy8nj70wTASKrxXXxNmU5AfpX5d5w@mail.gmail.com>

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 <johnl at iecc.com> wrote:

> In article <CA5F73E9-DD4E-4A68-8477-8296669EA955 at 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-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171022/700c4127/attachment.htm>

From dot at dotat.at  Mon Oct 23 04:56:12 2017
From: dot at dotat.at (Tony Finch)
Date: Mon, 23 Oct 2017 12:56:12 +0100
Subject: [ih] Origin of the loopback interface
In-Reply-To: <20171022154912.1254.qmail@ary.lan>
References: <20171022154912.1254.qmail@ary.lan>
Message-ID: <alpine.DEB.2.11.1710231252150.22527@grey.csi.cam.ac.uk>

John Levine <johnl at iecc.com> wrote:
>
> Even on machines that do have physical interfaces, puting a service
> on a loopback address lets me be sure it's only available to other
> processes on the same machine without having to screw around with
> packet filters.

That's not entirely true. The "weak endpoint model" followed by most
systems means that they will accept packets to any of their addresses on
any of their interfaces. This opens you up to attacks from malicious
devices on your LAN(s).

Actually, the weak endpoint model is probably less pervasive than it used
to be because some systems have implemented reverse path filtering.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Biscay, Fitzroy: Southwesterly backing southerly 4 or 5, occasionally 6 in
north. Moderate or rough, occasionally very rough in Fitzroy. Occasional rain
and fog patches in north. Moderate or good, occasionally very poor in north.


From touch at strayalpha.com  Mon Oct 23 07:26:28 2017
From: touch at strayalpha.com (Joe Touch)
Date: Mon, 23 Oct 2017 07:26:28 -0700
Subject: [ih] Origin of the loopback interface
In-Reply-To: <alpine.DEB.2.11.1710231252150.22527@grey.csi.cam.ac.uk>
References: <20171022154912.1254.qmail@ary.lan>
	<alpine.DEB.2.11.1710231252150.22527@grey.csi.cam.ac.uk>
Message-ID: <6487360A-DAD6-4057-B6CA-BAD3419FBF06@strayalpha.com>

Loopback should not be a substitute for IPC. At least one additional reason is that packets sent there might not end up where you think (they could be tunneled elsewhere, e.g..).

Joe

> On Oct 23, 2017, at 4:56 AM, Tony Finch <dot at dotat.at> wrote:
> 
> John Levine <johnl at iecc.com> wrote:
>> 
>> Even on machines that do have physical interfaces, puting a service
>> on a loopback address lets me be sure it's only available to other
>> processes on the same machine without having to screw around with
>> packet filters.
> 
> That's not entirely true. The "weak endpoint model" followed by most
> systems means that they will accept packets to any of their addresses on
> any of their interfaces. This opens you up to attacks from malicious
> devices on your LAN(s).
> 
> Actually, the weak endpoint model is probably less pervasive than it used
> to be because some systems have implemented reverse path filtering.
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Biscay, Fitzroy: Southwesterly backing southerly 4 or 5, occasionally 6 in
> north. Moderate or rough, occasionally very rough in Fitzroy. Occasional rain
> and fog patches in north. Moderate or good, occasionally very poor in north.
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.




From tte at cs.fau.de  Mon Oct 23 10:21:00 2017
From: tte at cs.fau.de (Toerless Eckert)
Date: Mon, 23 Oct 2017 19:21:00 +0200
Subject: [ih] Origin of the loopback interface
In-Reply-To: <59EC70C6.2020809@redbarn.org>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
	<59EC70C6.2020809@redbarn.org>
Message-ID: <20171023172100.GR20090@faui40p.informatik.uni-erlangen.de>

On Sun, Oct 22, 2017 at 03:19:50AM -0700, Paul Vixie wrote:
> multihoming is one of the great unsolved problems in internetworking. we 
> do it properly on routers -- there, the loopback has the router's "real" 
> ip address -- but only because the router is on-path and can inject its 
> loopback address (which usually is not subnetted) into the topology.

I am not sure if multihoming is a great unsolved problem in internetworking.
It just seems to be a problem with IPs ideology. As opposed to let's say
CLNS ideology of node addresses.

In the early 90th i had on pretty much every vendors unix system available nodes
with 10 Mbps ethernet and FDDI, and of course the FDDI on each node worked
randomnly 90% of the time (especially in a ring with 10++ vendor NICs). In
the face of NFS, the only way to keep the network running was to let those
MHH participate in the IGP and inject their addresses as host routes.
And when IPv6 came out i was so disappointed that it still did not
acknowledge / describe the notion of node addresses.

Now with IETF ANIMA WG and ACP, we're automation the creation and routing for
node addresses and try to figure out how to use the correct terminology.
"loopback" seems to be the common term used for "internal" interfaces. Not
that there is a real definition of "internal" interfaces either. And of
course there is also no IPv6 architecture description that "loopback" addresses
could have global scope addresses. Thats just a decade old deployment reality
not described by the architecture.

And thats just the tip of the iceberg.

Cheers
    Toerless


From tte at cs.fau.de  Mon Oct 23 10:30:12 2017
From: tte at cs.fau.de (Toerless Eckert)
Date: Mon, 23 Oct 2017 19:30:12 +0200
Subject: [ih] Origin of the loopback interface
Message-ID: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>

Inline

On Mon, Oct 23, 2017 at 12:56:12PM +0100, Tony Finch wrote:
> John Levine <johnl at iecc.com> wrote:
> >
> > Even on machines that do have physical interfaces, puting a service
> > on a loopback address lets me be sure it's only available to other
> > processes on the same machine without having to screw around with
> > packet filters.
>
> That's not entirely true. The "weak endpoint model" followed by most
> systems means that they will accept packets to any of their addresses on
> any of their interfaces. This opens you up to attacks from malicious
> devices on your LAN(s).
>
> Actually, the weak endpoint model is probably less pervasive than it used
> to be because some systems have implemented reverse path filtering.

Any URL explaining why it would be an attack to accept packets
for an address you have on another interface ? I can not see that attack
vector.

AFAIK, the problem with weak endpoint model is only that other
nodes have problems performing correct RPF filtering for packets originated
from weak endpoint model nodes when the available addressing is not correctly
announced into routing. And with no equivalent to ES-IS, this requires
endpoints to have either some IGP or some form of LISP running
(LISP the concept, not the solution by the same name).

On Mon, Oct 23, 2017 at 07:26:28AM -0700, Joe Touch wrote:
> Loopback should not be a substitute for IPC. At least one additional reason is that packets sent there might not end up where you think (they could be tunneled elsewhere, e.g..).
> Joe

Architecturally, there should be no reason for another addressing domain ("IPC")
if IP had a working definition of "node-local addressing". AFAIK, the loopback
addresses are meant to do this, but the RFCs IMHO do not call this out very
clearly. In multicast at least there is a node-local scope (FF01). Can't quite
remember (and to lazy to test now), if in TTL=0 worked to delivery traffic
only node-local at some point.

[ Btw: I could also tunnel any non-IP form of IPC if i have access to the OS. ]

Cheers
    Teorless


From jeanjour at comcast.net  Mon Oct 23 10:52:35 2017
From: jeanjour at comcast.net (John Day)
Date: Mon, 23 Oct 2017 13:52:35 -0400
Subject: [ih] Origin of the loopback interface
In-Reply-To: <20171023172100.GR20090@faui40p.informatik.uni-erlangen.de>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
	<59EC70C6.2020809@redbarn.org>
	<20171023172100.GR20090@faui40p.informatik.uni-erlangen.de>
Message-ID: <B89C4108-9951-469F-A88B-BAB0066809D8@comcast.net>

Toerless,

You are correct.  This problem was solved as soon as it was discovered around 1972 and solved several times.  XNS, CYCLADES and as you point out CLNS all solved it.  It is more a problem, as you say, with IP ideology. 

As you say, it is just the tip of the iceberg.

Take care,
John

> On Oct 23, 2017, at 13:21, Toerless Eckert <tte at cs.fau.de> wrote:
> 
> On Sun, Oct 22, 2017 at 03:19:50AM -0700, Paul Vixie wrote:
>> multihoming is one of the great unsolved problems in internetworking. we 
>> do it properly on routers -- there, the loopback has the router's "real" 
>> ip address -- but only because the router is on-path and can inject its 
>> loopback address (which usually is not subnetted) into the topology.
> 
> I am not sure if multihoming is a great unsolved problem in internetworking.
> It just seems to be a problem with IPs ideology. As opposed to let's say
> CLNS ideology of node addresses.
> 
> In the early 90th i had on pretty much every vendors unix system available nodes
> with 10 Mbps ethernet and FDDI, and of course the FDDI on each node worked
> randomnly 90% of the time (especially in a ring with 10++ vendor NICs). In
> the face of NFS, the only way to keep the network running was to let those
> MHH participate in the IGP and inject their addresses as host routes.
> And when IPv6 came out i was so disappointed that it still did not
> acknowledge / describe the notion of node addresses.
> 
> Now with IETF ANIMA WG and ACP, we're automation the creation and routing for
> node addresses and try to figure out how to use the correct terminology.
> "loopback" seems to be the common term used for "internal" interfaces. Not
> that there is a real definition of "internal" interfaces either. And of
> course there is also no IPv6 architecture description that "loopback" addresses
> could have global scope addresses. Thats just a decade old deployment reality
> not described by the architecture.
> 
> And thats just the tip of the iceberg.
> 
> Cheers
>    Toerless
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.




From touch at strayalpha.com  Mon Oct 23 11:17:52 2017
From: touch at strayalpha.com (Joe Touch)
Date: Mon, 23 Oct 2017 11:17:52 -0700
Subject: [ih] Origin of the loopback interface
In-Reply-To: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>
References: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>
Message-ID: <36223272-DF3B-483B-BEF2-C1F6CCB79B42@strayalpha.com>



> On Oct 23, 2017, at 10:30 AM, Toerless Eckert <tte at cs.fau.de> wrote:
> 
> n Mon, Oct 23, 2017 at 07:26:28AM -0700, Joe Touch wrote:
>> Loopback should not be a substitute for IPC. At least one additional reason is that packets sent there might not end up where you think (they could be tunneled elsewhere, e.g..).
>> Joe
> 
> Architecturally, there should be no reason for another addressing domain ("IPC")
> if IP had a working definition of "node-local addressing". AFAIK, the loopback
> addresses are meant to do this, but the RFCs IMHO do not call this out very
> clearly. In multicast at least there is a node-local scope (FF01). Can't quite
> remember (and to lazy to test now), if in TTL=0 worked to delivery traffic
> only node-local at some point.

You?ve hit the mail on the head. Only routers decrement TTLs. Multihoming works properly only with an internal virtual router inside each host:

J. Touch, T. Faber, ?Dynamic Host Routing for Production Use of Developmental Networks,? in Proc. ICNP ?97, Atlanta, Oct. 1997, pp. 285-292.

But that still doesn?t warrant a strict need for self addressing beyond the addresses already available on other interfaces. 

> 
> [ Btw: I could also tunnel any non-IP form of IPC if i have access to the OS.
> ]

You can but why would you? Ipc should be more efficient and necessary anyway  

Joe

> 
> Cheers
>    Teorless
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171023/9aac2bdf/attachment.htm>

From tte at cs.fau.de  Mon Oct 23 11:47:48 2017
From: tte at cs.fau.de (Toerless Eckert)
Date: Mon, 23 Oct 2017 20:47:48 +0200
Subject: [ih] Origin of the loopback interface
In-Reply-To: <36223272-DF3B-483B-BEF2-C1F6CCB79B42@strayalpha.com>
References: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>
	<36223272-DF3B-483B-BEF2-C1F6CCB79B42@strayalpha.com>
Message-ID: <20171023184748.GT20090@faui40p.informatik.uni-erlangen.de>

On Mon, Oct 23, 2017 at 11:17:52AM -0700, Joe Touch wrote:
> 
> 
> > On Oct 23, 2017, at 10:30 AM, Toerless Eckert <tte at cs.fau.de> wrote:
> > 
> > n Mon, Oct 23, 2017 at 07:26:28AM -0700, Joe Touch wrote:
> >> Loopback should not be a substitute for IPC. At least one additional reason is that packets sent there might not end up where you think (they could be tunneled elsewhere, e.g..).
> > 
> > [ Btw: I could also tunnel any non-IP form of IPC if i have access to the OS.
> > ]
> 
> You can but why would you? Ipc should be more efficient and necessary anyway  

You said that loopback IP traffic would not stay local to a node. You did not
say wether that would be an attack or a feature. I just said i could do the
same thing with any other IPC, eg: security and performance IMHO are
not arguments to decide between IP and other IPC.

I do not see a need for non-IP based IPC. Ultimately, whenever i want highest
performance, i am primarily talking about APIs atypical to classical TCP/IP
stacks (aka: beyond message passing APIs. Like RDMA APIs. Ylu just want to
make sure your API uses IP addressing of entities, and e voila, you can now
provide optimized local and remote implementations in the stacks without apps
having to bother learning two separate mechanisms. E.g.: RoCEv2. If you
want to constrain the scope of communications, you just use the right
addressing.

Cheers
    Toerless

> Joe
> 
> > 
> > Cheers
> >    Teorless

-- 
---
tte at cs.fau.de


From touch at strayalpha.com  Mon Oct 23 12:42:29 2017
From: touch at strayalpha.com (Joe Touch)
Date: Mon, 23 Oct 2017 12:42:29 -0700
Subject: [ih] Origin of the loopback interface
In-Reply-To: <20171023184748.GT20090@faui40p.informatik.uni-erlangen.de>
References: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>
	<36223272-DF3B-483B-BEF2-C1F6CCB79B42@strayalpha.com>
	<20171023184748.GT20090@faui40p.informatik.uni-erlangen.de>
Message-ID: <67C11385-5DF8-4CCD-BBD1-4DA6E9D0BE7E@strayalpha.com>

The fundamental problem is that ip networking doesn?t see far enough into the os to be sufficient as the sole IPC mechanism. There arren?t enough demuxing identifiers. 

It would preclude having a multiprocess stack too. You can?t coordinate components to process Ip using ip. 

The problem with loop back is the assumption of locality, which is false without additional filters. Ipc typicallly defaults to local only until extended, which naps better to expectations.

Jie


> On Oct 23, 2017, at 11:47 AM, Toerless Eckert <tte at cs.fau.de> wrote:
> 
>> On Mon, Oct 23, 2017 at 11:17:52AM -0700, Joe Touch wrote:
>> 
>> 
>>> On Oct 23, 2017, at 10:30 AM, Toerless Eckert <tte at cs.fau.de> wrote:
>>> 
>>> n Mon, Oct 23, 2017 at 07:26:28AM -0700, Joe Touch wrote:
>>>> Loopback should not be a substitute for IPC. At least one additional reason is that packets sent there might not end up where you think (they could be tunneled elsewhere, e.g..).
>>> 
>>> [ Btw: I could also tunnel any non-IP form of IPC if i have access to the OS.
>>> ]
>> 
>> You can but why would you? Ipc should be more efficient and necessary anyway  
> 
> You said that loopback IP traffic would not stay local to a node. You did not
> say wether that would be an attack or a feature. I just said i could do the
> same thing with any other IPC, eg: security and performance IMHO are
> not arguments to decide between IP and other IPC.
> 
> I do not see a need for non-IP based IPC. Ultimately, whenever i want highest
> performance, i am primarily talking about APIs atypical to classical TCP/IP
> stacks (aka: beyond message passing APIs. Like RDMA APIs. Ylu just want to
> make sure your API uses IP addressing of entities, and e voila, you can now
> provide optimized local and remote implementations in the stacks without apps
> having to bother learning two separate mechanisms. E.g.: RoCEv2. If you
> want to constrain the scope of communications, you just use the right
> addressing.
> 
> Cheers
>    Toerless
> 
>> Joe
>> 
>>> 
>>> Cheers
>>>   Teorless
> 
> -- 
> ---
> tte at cs.fau.de




From tte at cs.fau.de  Mon Oct 23 13:02:15 2017
From: tte at cs.fau.de (Toerless Eckert)
Date: Mon, 23 Oct 2017 22:02:15 +0200
Subject: [ih] Origin of the loopback interface
In-Reply-To: <67C11385-5DF8-4CCD-BBD1-4DA6E9D0BE7E@strayalpha.com>
References: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>
	<36223272-DF3B-483B-BEF2-C1F6CCB79B42@strayalpha.com>
	<20171023184748.GT20090@faui40p.informatik.uni-erlangen.de>
	<67C11385-5DF8-4CCD-BBD1-4DA6E9D0BE7E@strayalpha.com>
Message-ID: <20171023200215.GV20090@faui40p.informatik.uni-erlangen.de>

On Mon, Oct 23, 2017 at 12:42:29PM -0700, Joe Touch wrote:
> The fundamental problem is that ip networking doesn???t see far enough into the os to be sufficient as the sole IPC mechanism. There arren???t enough demuxing identifiers. 
> 
> It would preclude having a multiprocess stack too. You can???t coordinate components to process Ip using ip. 

Routing based on ever longer prefixes could IMHO equally be expanded inside of
nodes to create more hierarchy as needed.

> The problem with loop back is the assumption of locality, which is false without additional filters. Ipc typicallly defaults to local only until extended, which naps better to expectations.

I think there is only an assumption of locality on loopback addresses,
not interfaces. Which can be broken of course, but so can locality
expectations of other mechanisms. Unless one would even start to
define the exact behacvior of specific interfaces, yo could never make
an assumption of behavior using some type of interface (across different
implementations).

Toerless

> Jie
> 
> > On Oct 23, 2017, at 11:47 AM, Toerless Eckert <tte at cs.fau.de> wrote:
> > 
> >> On Mon, Oct 23, 2017 at 11:17:52AM -0700, Joe Touch wrote:
> >> 
> >> 
> >>> On Oct 23, 2017, at 10:30 AM, Toerless Eckert <tte at cs.fau.de> wrote:
> >>> 
> >>> n Mon, Oct 23, 2017 at 07:26:28AM -0700, Joe Touch wrote:
> >>>> Loopback should not be a substitute for IPC. At least one additional reason is that packets sent there might not end up where you think (they could be tunneled elsewhere, e.g..).
> >>> 
> >>> [ Btw: I could also tunnel any non-IP form of IPC if i have access to the OS.
> >>> ]
> >> 
> >> You can but why would you? Ipc should be more efficient and necessary anyway  
> > 
> > You said that loopback IP traffic would not stay local to a node. You did not
> > say wether that would be an attack or a feature. I just said i could do the
> > same thing with any other IPC, eg: security and performance IMHO are
> > not arguments to decide between IP and other IPC.
> > 
> > I do not see a need for non-IP based IPC. Ultimately, whenever i want highest
> > performance, i am primarily talking about APIs atypical to classical TCP/IP
> > stacks (aka: beyond message passing APIs. Like RDMA APIs. Ylu just want to
> > make sure your API uses IP addressing of entities, and e voila, you can now
> > provide optimized local and remote implementations in the stacks without apps
> > having to bother learning two separate mechanisms. E.g.: RoCEv2. If you
> > want to constrain the scope of communications, you just use the right
> > addressing.
> > 
> > Cheers
> >    Toerless
> > 
> >> Joe
> >> 
> >>> 
> >>> Cheers
> >>>   Teorless
> > 
> > -- 
> > ---
> > tte at cs.fau.de

-- 
---
tte at cs.fau.de


From paul at redbarn.org  Mon Oct 23 14:20:28 2017
From: paul at redbarn.org (Paul Vixie)
Date: Mon, 23 Oct 2017 14:20:28 -0700
Subject: [ih] Origin of the loopback interface
In-Reply-To: <20171023172100.GR20090@faui40p.informatik.uni-erlangen.de>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
	<59EC70C6.2020809@redbarn.org>
	<20171023172100.GR20090@faui40p.informatik.uni-erlangen.de>
Message-ID: <59EE5D1C.2080202@redbarn.org>

there are two replies here, one to an echo through joe touch.

Toerless Eckert wrote:
> On Sun, Oct 22, 2017 at 03:19:50AM -0700, Paul Vixie wrote:
>> multihoming is one of the great unsolved problems in internetworking. we
>> do it properly on routers -- there, the loopback has the router's "real"
>> ip address -- but only because the router is on-path and can inject its
>> loopback address (which usually is not subnetted) into the topology.
>
> I am not sure if multihoming is a great unsolved problem in internetworking.
> It just seems to be a problem with IPs ideology. As opposed to let's say
> CLNS ideology of node addresses.
>
[description of how to have every endpoint participate in IGP]
>
> And thats just the tip of the iceberg.

since that was the straightforward way to do things when hosts got 
smarter and addresses were sprouting everywhere, i did it. the number of 
moving parts was high, and their state combinations and state transition 
ordering permutations were extreme, and debugging was hell, and i 
eventually had to say, it can't work with today's technology.

and that was before we learned about ARP spoofing. and before three 
decades of christmas tree packets and buffer overruns. so, i've revised 
my earlier "not with today's technology" assessment to "not ever."

i saw DEC AutoNet-II work at the Systems Research Center in 1990 or so 
and it was a thing of terrible power and beauty. i want a network that 
works like that. but, outside of the lab, and outside of hollywood, i 
aver that it cannot be done with multiple vendors, and should not be 
tried. forget about speed -- state is what kills.

---

Toerless Eckert wrote:
 > On Mon, Oct 23, 2017 at 12:42:29PM -0700, Joe Touch wrote:
 >> The problem with loop back is the assumption of locality, which is
 >> false without additional filters. Ipc typicallly defaults to local
 >> only until extended, which naps better to expectations.
 >
 > I think there is only an assumption of locality on loopback
 > addresses, not interfaces. Which can be broken of course, but so can
 > locality expectations of other mechanisms. Unless one would even
 > start to define the exact behacvior of specific interfaces, yo could
 > never make an assumption of behavior using some type of interface
 > (across different implementations).

the internet is at its best an ad-hoc set of cooperative guidelines, and 
for all ad-hoc purposes for the last two decades, my template for every 
endpoint's host based firewall includes the following rules:

> add     pass    all     from any to any via lo0
> add     deny    all     from any to { ::1 or 127.0.0.0/8 }
> add     deny    all     from { ::1 or 127.0.0.0/8 } to any

i and many others have built mighty edifices upon the assumption of 
locality on the loopback interface. we merely ensure it as one of the 
requirements every endpoint must meet.

---

noting, elsewhere in this thread, someone said high performance like RVM 
API would be hard with IP even via a loopback. sun microsystems and cmu 
mach both had page flipping for page aligned data, largely because we 
all got tired of having to special case the local data path through 
"doors" or shared memory or "unix domain sockets". so, it can be hacked.

i think XNS was clearly superior to IP. but then, betamax was clearly 
superior to VHS, and look where that superiority got them. my short time 
programming device drivers for an AMD-based multibus board at ungermann 
bass to make sunos properly speak to XNS was maybe the most fun i'd ever 
had up until that day. but: the market has its own path.

-- 
P Vixie



From brian.e.carpenter at gmail.com  Mon Oct 23 14:32:06 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Tue, 24 Oct 2017 10:32:06 +1300
Subject: [ih] Origin of the loopback interface
In-Reply-To: <67C11385-5DF8-4CCD-BBD1-4DA6E9D0BE7E@strayalpha.com>
References: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>
	<36223272-DF3B-483B-BEF2-C1F6CCB79B42@strayalpha.com>
	<20171023184748.GT20090@faui40p.informatik.uni-erlangen.de>
	<67C11385-5DF8-4CCD-BBD1-4DA6E9D0BE7E@strayalpha.com>
Message-ID: <35a4fedd-7b5f-bb00-20e1-26dc1d4af6ce@gmail.com>

On 24/10/2017 08:42, Joe Touch wrote:
> The fundamental problem is that ip networking doesn?t see far enough into the os to be sufficient as the sole IPC mechanism. There arren?t enough demuxing identifiers.

I'm not sure this is really a "history" issue but I have to say that Joe is
correct. I'll take the details off list.

    Brian

> 
> It would preclude having a multiprocess stack too. You can?t coordinate components to process Ip using ip. 
> 
> The problem with loop back is the assumption of locality, which is false without additional filters. Ipc typicallly defaults to local only until extended, which naps better to expectations.
> 
> Jie
> 
> 
>> On Oct 23, 2017, at 11:47 AM, Toerless Eckert <tte at cs.fau.de> wrote:
>>
>>> On Mon, Oct 23, 2017 at 11:17:52AM -0700, Joe Touch wrote:
>>>
>>>
>>>> On Oct 23, 2017, at 10:30 AM, Toerless Eckert <tte at cs.fau.de> wrote:
>>>>
>>>> n Mon, Oct 23, 2017 at 07:26:28AM -0700, Joe Touch wrote:
>>>>> Loopback should not be a substitute for IPC. At least one additional reason is that packets sent there might not end up where you think (they could be tunneled elsewhere, e.g..).
>>>>
>>>> [ Btw: I could also tunnel any non-IP form of IPC if i have access to the OS.
>>>> ]
>>>
>>> You can but why would you? Ipc should be more efficient and necessary anyway  
>>
>> You said that loopback IP traffic would not stay local to a node. You did not
>> say wether that would be an attack or a feature. I just said i could do the
>> same thing with any other IPC, eg: security and performance IMHO are
>> not arguments to decide between IP and other IPC.
>>
>> I do not see a need for non-IP based IPC. Ultimately, whenever i want highest
>> performance, i am primarily talking about APIs atypical to classical TCP/IP
>> stacks (aka: beyond message passing APIs. Like RDMA APIs. Ylu just want to
>> make sure your API uses IP addressing of entities, and e voila, you can now
>> provide optimized local and remote implementations in the stacks without apps
>> having to bother learning two separate mechanisms. E.g.: RoCEv2. If you
>> want to constrain the scope of communications, you just use the right
>> addressing.
>>
>> Cheers
>>    Toerless
>>
>>> Joe
>>>
>>>>
>>>> Cheers
>>>>   Teorless
>>
>> -- 
>> ---
>> tte at cs.fau.de
> 
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 




From tte at cs.fau.de  Mon Oct 23 15:00:37 2017
From: tte at cs.fau.de (Toerless Eckert)
Date: Tue, 24 Oct 2017 00:00:37 +0200
Subject: [ih] Origin of the loopback interface
In-Reply-To: <59EE5D1C.2080202@redbarn.org>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
	<59EC70C6.2020809@redbarn.org>
	<20171023172100.GR20090@faui40p.informatik.uni-erlangen.de>
	<59EE5D1C.2080202@redbarn.org>
Message-ID: <20171023220037.GW20090@faui40p.informatik.uni-erlangen.de>

On Mon, Oct 23, 2017 at 02:20:28PM -0700, Paul Vixie wrote:
> [description of how to have every endpoint participate in IGP]
I must be missing one mail in the thread...

> >And thats just the tip of the iceberg.
> 
> since that was the straightforward way to do things when hosts got
> smarter and addresses were sprouting everywhere, i did it. the
> number of moving parts was high, and their state combinations and
> state transition ordering permutations were extreme, and debugging
> was hell, and i eventually had to say, it can't work with today's
> technology.
> 
> and that was before we learned about ARP spoofing. and before three
> decades of christmas tree packets and buffer overruns. so, i've
> revised my earlier "not with today's technology" assessment to "not
> ever."

Node-address based routing is becoming more and more popular in IOT
networks where each device ultimately is also a router with e.g. RPL
(or othrer lightweight state routing ptotocols).

Its also difficult to come to conclusions just looking at what can
be hacked together today. I'd rather look at whats the best that
could be built with host routes and then make a judgement call.

For example you definitely do not want hosts to participate
in an LSP but rather have some form of ES-IS and of course that needs
to be secured (unlike ARP). Etc. pp. 

Of course, user-created state in networks introduces another level of
architectural concerns, and Internet unicast routing didn't bother to design
for it.  But a lot of other areas did & do: Middleboxes, IP multicast,
Mobile networking - just to name a few. So it definitely can be done
at a good amount of scale and dynamics.

> i saw DEC AutoNet-II work at the Systems Research Center in 1990 or
> so and it was a thing of terrible power and beauty. i want a network
> that works like that. but, outside of the lab, and outside of
> hollywood, i aver that it cannot be done with multiple vendors, and
> should not be tried. forget about speed -- state is what kills.

Locator Identifier Separation mechanisms is of course one long understood mechanism
to layer the user created addressing so that you can keep an unmodified
underlay, but IMHo thats just a stopgap (which in Internet terms means
few decades ;-).

But except for the >>100Gbps/link underlay, we are also returning
back to the roots of getting single resource based forwarding & control
(X.86 / fd.io, DPDK, etc.pp). There has not been a lot of exploration
IMHO to best leverage that - data plane driven control & state. The big
no-no in the last 20 years design box: Very fast forwarding plane with
lots of state limits, bottleneck IPC to control plane, underpowered control
plane CPU.

Cheers
    Toerless
> 
> ---
> 
> Toerless Eckert wrote:
> > On Mon, Oct 23, 2017 at 12:42:29PM -0700, Joe Touch wrote:
> >> The problem with loop back is the assumption of locality, which is
> >> false without additional filters. Ipc typicallly defaults to local
> >> only until extended, which naps better to expectations.
> >
> > I think there is only an assumption of locality on loopback
> > addresses, not interfaces. Which can be broken of course, but so can
> > locality expectations of other mechanisms. Unless one would even
> > start to define the exact behacvior of specific interfaces, yo could
> > never make an assumption of behavior using some type of interface
> > (across different implementations).
> 
> the internet is at its best an ad-hoc set of cooperative guidelines,
> and for all ad-hoc purposes for the last two decades, my template
> for every endpoint's host based firewall includes the following
> rules:
> 
> >add     pass    all     from any to any via lo0
> >add     deny    all     from any to { ::1 or 127.0.0.0/8 }
> >add     deny    all     from { ::1 or 127.0.0.0/8 } to any
> 
> i and many others have built mighty edifices upon the assumption of
> locality on the loopback interface. we merely ensure it as one of
> the requirements every endpoint must meet.
> 
> ---
> 
> noting, elsewhere in this thread, someone said high performance like
> RVM API would be hard with IP even via a loopback. sun microsystems
> and cmu mach both had page flipping for page aligned data, largely
> because we all got tired of having to special case the local data
> path through "doors" or shared memory or "unix domain sockets". so,
> it can be hacked.
> 
> i think XNS was clearly superior to IP. but then, betamax was
> clearly superior to VHS, and look where that superiority got them.
> my short time programming device drivers for an AMD-based multibus
> board at ungermann bass to make sunos properly speak to XNS was
> maybe the most fun i'd ever had up until that day. but: the market
> has its own path.
> 
> -- 
> P Vixie

-- 
---
tte at cs.fau.de


From pnr at planet.nl  Mon Oct 23 15:42:46 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Tue, 24 Oct 2017 00:42:46 +0200
Subject: [ih] BBN C-series computers
In-Reply-To: <6700759c-dc9d-5d5f-3fb8-1178ab5d5ff8@gmail.com>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
	<6700759c-dc9d-5d5f-3fb8-1178ab5d5ff8@gmail.com>
Message-ID: <23535B27-49C9-4AA9-BC04-5343CF5DFA3A@planet.nl>


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.?






From bernie at fantasyfarm.com  Mon Oct 23 18:04:08 2017
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Mon, 23 Oct 2017 21:04:08 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <23535B27-49C9-4AA9-BC04-5343CF5DFA3A@planet.nl>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>,
	<6700759c-dc9d-5d5f-3fb8-1178ab5d5ff8@gmail.com>,
	<23535B27-49C9-4AA9-BC04-5343CF5DFA3A@planet.nl>
Message-ID: <59EE9188.2820.3B314669@bernie.fantasyfarm.com>

> - 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:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       






From dave.walden.family at gmail.com  Mon Oct 23 18:26:02 2017
From: dave.walden.family at gmail.com (David Walden)
Date: Mon, 23 Oct 2017 21:26:02 -0400
Subject: [ih] BBN C-series computers
Message-ID: <u8b4vsrdiawy6hsp9h020rld.1508808362948@email.android.com>

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 <bernie at 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:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       




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



From touch at strayalpha.com  Mon Oct 23 21:33:39 2017
From: touch at strayalpha.com (Joe Touch)
Date: Mon, 23 Oct 2017 21:33:39 -0700
Subject: [ih] Origin of the loopback interface
In-Reply-To: <20171023220037.GW20090@faui40p.informatik.uni-erlangen.de>
References: <7293dcf5-5092-0b91-1ec4-447888aac3ee@gmail.com>
	<alpine.NEB.2.20.1710201802440.28910@t1.m.reedmedia.net>
	<6ed85cd4-75d3-526f-f10e-119ad1e34a6c@3kitty.org>
	<38619627-0307-b5f0-2569-1cc47ce6ffa5@meetinghouse.net>
	<90e4ef14-f4d2-5b77-2d68-70903e112f65@gmail.com>
	<a6ae5f16-b255-311f-26c0-10d0c4c2e513@3kitty.org>
	<59EC70C6.2020809@redbarn.org>
	<20171023172100.GR20090@faui40p.informatik.uni-erlangen.de>
	<59EE5D1C.2080202@redbarn.org>
	<20171023220037.GW20090@faui40p.informatik.uni-erlangen.de>
Message-ID: <F7A78F36-66C2-473F-ABBE-AEDADB53C90D@strayalpha.com>



On Oct 23, 2017, at 3:00 PM, Toerless Eckert <tte at cs.fau.de> wrote:

>> i saw DEC AutoNet-II work at the Systems Research Center in 1990 or
>> so and it was a thing of terrible power and beauty. i want a network
>> that works like that. but, outside of the lab, and outside of
>> hollywood, i aver that it cannot be done with multiple vendors, and
>> should not be tried. forget about speed -- state is what kills.
> 
> Locator Identifier Separation mechanisms is of course one long understood mechanism
> to layer the user created addressing so that you can keep an unmodified
> underlay, but IMHo thats just a stopgap (which in Internet terms means
> few decades ;-).

LISP is one example of a broad class of encapsulation-based systems that emulate either subsets or switching devices, e.g., including TRILL, 802.1Q-2014, etc., a class I?ve been referring to as recursive routers and is fundamental to network virtualization.

IMO, they?re no more a stop-gap to networking than VM is to memory.

But we?re digressing from the original thread...

Joe



From paul at redbarn.org  Tue Oct 24 05:12:06 2017
From: paul at redbarn.org (Paul Vixie)
Date: Tue, 24 Oct 2017 14:12:06 +0200
Subject: [ih] vm vs. memory
Message-ID: <59EF2E16.1040906@redbarn.org>



Joe Touch wrote:
...
> IMO, they?re no more a stop-gap to networking than VM is to memory.
>
> But we?re digressing from the original thread...

that's hard to say, but i've forked the thread anyway.

vm is an example of something that started as a workaround but 
introduced us to a whole different way of thinking about memory. we now 
have systems in production that always have physical RAM enough for 
their work load, and who have no backing store for RAM (paging or 
swapping) but which still depend on virtual memory for other reasons:

1. linear address space; all processes think they have addresses 
starting from 0.

2. page-level protection; various parts of memory are only readable, or 
writable, or executable, when needed, and at certain privilege levels.

3. occasional sharing and/or persistence (memory mapped files).

4. occasional distributed persistence (networked virtual memory).

i think a lot of things that begin as stop-gaps turn out to have many 
purposes beyond that initial stopped gap, and would have been invented 
anyway, if somewhat later, for those other reasons.

LISP may be an example. NAT certainly is.

i mention this because not all ideas which were terrible $originally 
remain terrible in $internet_history.

-- 
P Vixie



From dot at dotat.at  Tue Oct 24 06:48:02 2017
From: dot at dotat.at (Tony Finch)
Date: Tue, 24 Oct 2017 14:48:02 +0100
Subject: [ih] Origin of the loopback interface
In-Reply-To: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>
References: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>
Message-ID: <alpine.DEB.2.11.1710241427410.22527@grey.csi.cam.ac.uk>

Toerless Eckert <tte at cs.fau.de> wrote:
> > John Levine <johnl at iecc.com> wrote:
> > >
> > > Even on machines that do have physical interfaces, puting a service
> > > on a loopback address lets me be sure it's only available to other
> > > processes on the same machine without having to screw around with
> > > packet filters.
>
> Any URL explaining why it would be an attack to accept packets
> for an address you have on another interface ? I can not see that attack
> vector.

I don't have a good link handy, so I'll try to explain it here...

In John's setup he assumes that a service bound to 127.0.0.1 is only
reachable by other processes on the same host. Maybe because of that the
service is configured to skip authentication/authorization checks.

If I'm on the same LAN as John's host, I can get packets to his supposedly
isolated service by crafting ethernet frames with his host's MAC address
as the destination but 127.0.0.1 as the IP destination.

You can use this trick for good as well as evil :-) Back in the days of
IP-based web virtual hosting we had a setup which bound about 96,000 IP
addresses on the loopback interface of the web servers. The routers in
front of these web servers had static routes configured for the loopback
web IP addresses with a next-hop of the web server's ethernet interface.

(More details about this hack at http://fanf.livejournal.com/124030.html)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Southwest 6 to gale 8, decreasing 4 or 5 later. Moderate or rough.
Rain, fog patches. Moderate, occasionally very poor.


From tte at cs.fau.de  Tue Oct 24 07:32:25 2017
From: tte at cs.fau.de (Toerless Eckert)
Date: Tue, 24 Oct 2017 16:32:25 +0200
Subject: [ih] Origin of the loopback interface
In-Reply-To: <alpine.DEB.2.11.1710241427410.22527@grey.csi.cam.ac.uk>
References: <20171023173012.GA18466@faui40p.informatik.uni-erlangen.de>
	<alpine.DEB.2.11.1710241427410.22527@grey.csi.cam.ac.uk>
Message-ID: <20171024143225.GX20090@faui40p.informatik.uni-erlangen.de>

On Tue, Oct 24, 2017 at 02:48:02PM +0100, Tony Finch wrote:
> > Any URL explaining why it would be an attack to accept packets
> > for an address you have on another interface ? I can not see that attack
> > vector.
> 
> I don't have a good link handy, so I'll try to explain it here...
> 
> In John's setup he assumes that a service bound to 127.0.0.1 is only
> reachable by other processes on the same host. Maybe because of that the
> service is configured to skip authentication/authorization checks.

And it should not need to (the service).

> If I'm on the same LAN as John's host, I can get packets to his supposedly
> isolated service by crafting ethernet frames with his host's MAC address
> as the destination but 127.0.0.1 as the IP destination.

Right. So at least the (IPv6) architecture security considerations
should to explain how the nodes IP stack needs to filter packets destined
to scoped addresses if received from interfaces not in that scope. Not
sure how much of that verbage exist(ed) at least back when the IPv6
architecture did still endorse site-scope addresses. Pretty sure it
was not written down for node-scoped addresses.

> You can use this trick for good as well as evil :-)

Can't come up with an example how to apply this for good.

> Back in the days of
> IP-based web virtual hosting we had a setup which bound about 96,000 IP
> addresses on the loopback interface of the web servers. The routers in
> front of these web servers had static routes configured for the loopback
> web IP addresses with a next-hop of the web server's ethernet interface.
> 
> (More details about this hack at http://fanf.livejournal.com/124030.html)

Interesting. Looks from that blog as if there is a maze of different methods
of using multiple IP addresses inside a node. Do you think that it would be
good work for IETF to think about better standardization for those mechanisms ?
There is for example draft-templin-v6ops-pdhost-15 which also looks
into that direction but received little interest in the WG so far. Not
claiming that its current payload is good or bad, just  that it goes in
that direction.

Toerless


> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Irish Sea: Southwest 6 to gale 8, decreasing 4 or 5 later. Moderate or rough.
> Rain, fog patches. Moderate, occasionally very poor.


From dave.walden.family at gmail.com  Tue Oct 24 09:06:40 2017
From: dave.walden.family at gmail.com (Dave Walden)
Date: Tue, 24 Oct 2017 12:06:40 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <23535B27-49C9-4AA9-BC04-5343CF5DFA3A@planet.nl>
References: <E06884CD-1096-4E29-8496-10DA9979A305@planet.nl>
	<6700759c-dc9d-5d5f-3fb8-1178ab5d5ff8@gmail.com>
	<23535B27-49C9-4AA9-BC04-5343CF5DFA3A@planet.nl>
Message-ID: <a112b50e-6b45-516a-7b37-8f4d3a80f931@gmail.com>

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-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.

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



From tte at cs.fau.de  Tue Oct 24 09:29:09 2017
From: tte at cs.fau.de (Toerless Eckert)
Date: Tue, 24 Oct 2017 18:29:09 +0200
Subject: [ih] vm vs. memory
Message-ID: <20171024162909.GD19957@faui40p.informatik.uni-erlangen.de>

Hmm... what are the redeeming qualities of NAT ? The fact that
we'll look back with nostalgia at the days when users only had to
rely on NAT to get access to the global village because what they
do now is worse ?

https://ripe75.ripe.net/presentations/22-2017-10-23-death-of-transit.pdf

Oh well, federated AOL-TNG, but hey, the Internet was fun while it lasted,
i promise to switch off the lights when i leave.

Sorry, off-topic. Nice summary for the evolution of memory virtualization.
Still trying to get to the next level @home, IOMMU virtualization
config for virtualized PCI 3D graphics. VT-d over RoCEv3 anybody ? *grin*

On Tue, Oct 24, 2017 at 02:12:06PM +0200, Paul Vixie wrote:
> 
> 
> Joe Touch wrote:
> ...
> > IMO, they?re no more a stop-gap to networking than VM is to memory.
> >
> > But we?re digressing from the original thread...
> 
> that's hard to say, but i've forked the thread anyway.
> 
> vm is an example of something that started as a workaround but 
> introduced us to a whole different way of thinking about memory. we now 
> have systems in production that always have physical RAM enough for 
> their work load, and who have no backing store for RAM (paging or 
> swapping) but which still depend on virtual memory for other reasons:
> 
> 1. linear address space; all processes think they have addresses 
> starting from 0.
> 
> 2. page-level protection; various parts of memory are only readable, or 
> writable, or executable, when needed, and at certain privilege levels.
> 
> 3. occasional sharing and/or persistence (memory mapped files).
> 
> 4. occasional distributed persistence (networked virtual memory).
> 
> i think a lot of things that begin as stop-gaps turn out to have many 
> purposes beyond that initial stopped gap, and would have been invented 
> anyway, if somewhat later, for those other reasons.
> 
> LISP may be an example. NAT certainly is.
> 
> i mention this because not all ideas which were terrible $originally 
> remain terrible in $internet_history.
> 
> -- 
> P Vixie
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.


From dot at dotat.at  Tue Oct 24 10:06:40 2017
From: dot at dotat.at (Tony Finch)
Date: Tue, 24 Oct 2017 18:06:40 +0100
Subject: [ih] vm vs. memory
In-Reply-To: <20171024162909.GD19957@faui40p.informatik.uni-erlangen.de>
References: <20171024162909.GD19957@faui40p.informatik.uni-erlangen.de>
Message-ID: <alpine.DEB.2.11.1710241805540.22527@grey.csi.cam.ac.uk>

Toerless Eckert <tte at cs.fau.de> wrote:

> Hmm... what are the redeeming qualities of NAT ?

http://www.potaroo.net/ispcol/2017-09/natdefence.html

Geoff Huston's essays are always worth reading.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Sole: Southwest 5 or 6, becoming cyclonic 3 or 4, occasionally 5 later. Very
rough. Rain, fog patches. Moderate, occasionally very poor.


From paul at redbarn.org  Tue Oct 24 10:35:12 2017
From: paul at redbarn.org (Paul Vixie)
Date: Tue, 24 Oct 2017 19:35:12 +0200
Subject: [ih] vm vs. memory
In-Reply-To: <20171024162909.GD19957@faui40p.informatik.uni-erlangen.de>
References: <20171024162909.GD19957@faui40p.informatik.uni-erlangen.de>
Message-ID: <59EF79D0.2060906@redbarn.org>

 > On Tue, Oct 24, 2017 at 02:12:06PM +0200, Paul Vixie wrote:
 >>
 >> ...
 >>
 >> LISP may be an example. NAT certainly is.

Toerless Eckert wrote:
> Hmm... what are the redeeming qualities of NAT ?

every other attempt to add rapid renumbering and transparent multihoming 
has been rejected. NAT, by not trying to do those things and by not 
saying it would do those things, snuck under the defenses.

no multi-national enterprise should give real external addresses to all 
of its internal endpoints, for at least three reasons:

1. the internal structure should not be visible or guessable.

2. reachability should be prevented by more than just firewalls.

3. you can add and drop transit providers as often as you want.

NAT did that. nothing else could have or did.

-- 
P Vixie



From johnl at iecc.com  Tue Oct 24 11:07:41 2017
From: johnl at iecc.com (John Levine)
Date: 24 Oct 2017 18:07:41 -0000
Subject: [ih] vm vs. memory
In-Reply-To: <59EF79D0.2060906@redbarn.org>
Message-ID: <20171024180741.6920.qmail@ary.lan>

In article <59EF79D0.2060906 at redbarn.org> you write:
>> Hmm... what are the redeeming qualities of NAT ?
>
>every other attempt to add rapid renumbering and transparent multihoming 
>has been rejected. NAT, by not trying to do those things and by not 
>saying it would do those things, snuck under the defenses.

There's also the fact that for most practical purposes, NAT just
works, and IPv6 still doesn't.

I never have any trouble getting my devices to work behind a NAT.  I
have trouble all the time getting them to work (particularly to work
reliably) on IPv6, even behind routers I control.

R's,
John

PS: I realize this is an ongoing sore point so in the interest
of conciseness, I won't be responding to any explanations about
why my IPv6 problems either don't exist or are my own fault.



From tte at cs.fau.de  Tue Oct 24 11:09:15 2017
From: tte at cs.fau.de (Toerless Eckert)
Date: Tue, 24 Oct 2017 20:09:15 +0200
Subject: [ih] vm vs. memory
Message-ID: <20171024180915.GE19957@faui40p.informatik.uni-erlangen.de>

Yes, these are the classical arguments. 

IMHO, arguments 1. and 2. have mostly failed, especially
in large enterprises. They only provided some hard shell to the
outside, but mayority of attacks can easily come from the inside.
And protection to the outside has evolved long ago from trying
to (unnecessarily) hiding your addressing structure over
to app-level - keep the good bits in, and the bad bits out.

Argument 3 (i think you mean access providers) is more interesting.

I would love to hear from folks more involved in current deployments
what the BCP is for organizations using provider dependent
addresses to be able to quickly switch providers - without NAT.
I guess you would effectively build all org internal addressing & naming
on ULA, and use the provider addresses only for internal<->external
communications, but if you have an actual L3 network in the org, then
there is probably still a lot of renumbering necessary for which
there are no well defined network wide autoamted solutions. Although
i think there will be a new WG, forgot name to start tackling this.

If it was me, would have just evolved and improved on rfc1928.

Cheers
    Toerless

On Tue, Oct 24, 2017 at 07:35:12PM +0200, Paul Vixie wrote:
> > On Tue, Oct 24, 2017 at 02:12:06PM +0200, Paul Vixie wrote:
> >>
> >> ...
> >>
> >> LISP may be an example. NAT certainly is.
> 
> Toerless Eckert wrote:
> >Hmm... what are the redeeming qualities of NAT ?
> 
> every other attempt to add rapid renumbering and transparent
> multihoming has been rejected. NAT, by not trying to do those things
> and by not saying it would do those things, snuck under the
> defenses.
> 
> no multi-national enterprise should give real external addresses to
> all of its internal endpoints, for at least three reasons:
> 
> 1. the internal structure should not be visible or guessable.
> 
> 2. reachability should be prevented by more than just firewalls.
> 
> 3. you can add and drop transit providers as often as you want.
> 
> NAT did that. nothing else could have or did.
> 
> -- 
> P Vixie

-- 
---
tte at cs.fau.de


From jjd at jjd.com  Tue Oct 24 11:52:33 2017
From: jjd at jjd.com (James J Dempsey)
Date: Tue, 24 Oct 2017 14:52:33 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <u8b4vsrdiawy6hsp9h020rld.1508808362948@email.android.com>
References: <u8b4vsrdiawy6hsp9h020rld.1508808362948@email.android.com>
Message-ID: <14210.1508871153@serenity.jjd.com>

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 <dave.walden.family at 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 <bernie at 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--


From brian.e.carpenter at gmail.com  Tue Oct 24 12:22:36 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Wed, 25 Oct 2017 08:22:36 +1300
Subject: [ih] vm vs. memory
In-Reply-To: <20171024180915.GE19957@faui40p.informatik.uni-erlangen.de>
References: <20171024180915.GE19957@faui40p.informatik.uni-erlangen.de>
Message-ID: <9732c406-5f9b-5926-e5ca-947a5c37eddf@gmail.com>

On 25/10/2017 07:09, Toerless Eckert wrote:
> Yes, these are the classical arguments. 
> 
> IMHO, arguments 1. and 2. have mostly failed, especially
> in large enterprises. They only provided some hard shell to the
> outside, but mayority of attacks can easily come from the inside.
> And protection to the outside has evolved long ago from trying
> to (unnecessarily) hiding your addressing structure over
> to app-level - keep the good bits in, and the bad bits out.
> 
> Argument 3 (i think you mean access providers) is more interesting.
> 
> I would love to hear from folks more involved in current deployments
> what the BCP is for organizations using provider dependent
> addresses to be able to quickly switch providers - without NAT.

This is hardly history (except for how we got into this mess**)
but the answer is probably RFC7157 plus RFC8028, with RFC4192
and RFC7010 in the background.

**https://www.cs.auckland.ac.nz/~brian/CCR-201404-IPaddrHarmful.pdf

   Brian

> I guess you would effectively build all org internal addressing & naming
> on ULA, and use the provider addresses only for internal<->external
> communications, but if you have an actual L3 network in the org, then
> there is probably still a lot of renumbering necessary for which
> there are no well defined network wide autoamted solutions. Although
> i think there will be a new WG, forgot name to start tackling this.
> 
> If it was me, would have just evolved and improved on rfc1928.
> 
> Cheers
>     Toerless
> 
> On Tue, Oct 24, 2017 at 07:35:12PM +0200, Paul Vixie wrote:
>>> On Tue, Oct 24, 2017 at 02:12:06PM +0200, Paul Vixie wrote:
>>>>
>>>> ...
>>>>
>>>> LISP may be an example. NAT certainly is.
>>
>> Toerless Eckert wrote:
>>> Hmm... what are the redeeming qualities of NAT ?
>>
>> every other attempt to add rapid renumbering and transparent
>> multihoming has been rejected. NAT, by not trying to do those things
>> and by not saying it would do those things, snuck under the
>> defenses.
>>
>> no multi-national enterprise should give real external addresses to
>> all of its internal endpoints, for at least three reasons:
>>
>> 1. the internal structure should not be visible or guessable.
>>
>> 2. reachability should be prevented by more than just firewalls.
>>
>> 3. you can add and drop transit providers as often as you want.
>>
>> NAT did that. nothing else could have or did.
>>
>> -- 
>> P Vixie
> 


From dhc2 at dcrocker.net  Tue Oct 24 12:26:06 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Tue, 24 Oct 2017 12:26:06 -0700
Subject: [ih] vm vs. memory
In-Reply-To: <59EF79D0.2060906@redbarn.org>
References: <20171024162909.GD19957@faui40p.informatik.uni-erlangen.de>
	<59EF79D0.2060906@redbarn.org>
Message-ID: <95d1c21e-59ec-a0ea-e75d-95790ad80763@dcrocker.net>

On 10/24/2017 10:35 AM, Paul Vixie wrote:
>> Hmm... what are the redeeming qualities of NAT ?
> 
> every other attempt to add rapid renumbering and transparent multihoming
> has been rejected. NAT, by not trying to do those things and by not
> saying it would do those things, snuck under the defenses.
> 
> no multi-national enterprise should give real external addresses to all
> of its internal endpoints, for at least three reasons:
> 
> 1. the internal structure should not be visible or guessable.
> 
> 2. reachability should be prevented by more than just firewalls.
> 
> 3. you can add and drop transit providers as often as you want.
> 
> NAT did that. nothing else could have or did.


Forgive me for doing this, but the above is one of the most concise and 
pragmatic summaries on this topic I've seen, over the history of NAT and 
its opponents.

So I wanted to post it again, in the hope that folk would read it 
thoughtfully at least once, and perhaps twice if you are really diligent.

A very useful quote, from a very bad TV show of my childhood, noted: 
"idealism is fine, but try spreading it on crackers."  NATs are 
pragmatic, and the idealism against them is useful during basic design 
discussions, but counter-productive as an absolute.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From dhc2 at dcrocker.net  Tue Oct 24 12:31:47 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Tue, 24 Oct 2017 12:31:47 -0700
Subject: [ih] vm vs. memory
In-Reply-To: <59EF2E16.1040906@redbarn.org>
References: <59EF2E16.1040906@redbarn.org>
Message-ID: <becebb95-8166-4d61-8fc7-c7ae80a8f0ab@dcrocker.net>

On 10/24/2017 5:12 AM, Paul Vixie wrote:
> vm is an example of something that started as a workaround but
> introduced us to a whole different way of thinking about memory.


And yet, arguably, it is nothing but the productive application of the 
Lampson (or Wheeler) adage: "All problems in computer science can be 
solved by another level of indirection."


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From paul at redbarn.org  Tue Oct 24 12:37:11 2017
From: paul at redbarn.org (P Vix)
Date: Tue, 24 Oct 2017 19:37:11 +0000
Subject: [ih] vm vs. memory
In-Reply-To: <becebb95-8166-4d61-8fc7-c7ae80a8f0ab@dcrocker.net>
References: <59EF2E16.1040906@redbarn.org>
	<becebb95-8166-4d61-8fc7-c7ae80a8f0ab@dcrocker.net>
Message-ID: <4DCB4E63-5513-4571-B5B5-803F6E47EA72@redbarn.org>

That adage doesn't apply to problems you don't yet know you will have.

On October 24, 2017 9:31:47 PM GMT+02:00, Dave Crocker <dhc2 at dcrocker.net> wrote:
>On 10/24/2017 5:12 AM, Paul Vixie wrote:
>> vm is an example of something that started as a workaround but
>> introduced us to a whole different way of thinking about memory.
>
>
>And yet, arguably, it is nothing but the productive application of the 
>Lampson (or Wheeler) adage: "All problems in computer science can be 
>solved by another level of indirection."
>
>
>d/
>-- 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171024/fa0a7fc1/attachment.htm>

From brian.e.carpenter at gmail.com  Tue Oct 24 12:42:43 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Wed, 25 Oct 2017 08:42:43 +1300
Subject: [ih] vm vs. memory
In-Reply-To: <59EF2E16.1040906@redbarn.org>
References: <59EF2E16.1040906@redbarn.org>
Message-ID: <593e3d78-5af7-e30b-a1ae-ad875ddee643@gmail.com>

On 25/10/2017 01:12, Paul Vixie wrote:
> 
> 
> Joe Touch wrote:
> ...
>> IMO, they?re no more a stop-gap to networking than VM is to memory.
>>
>> But we?re digressing from the original thread...
> 
> that's hard to say, but i've forked the thread anyway.
> 
> vm is an example of something that started as a workaround but 

I disagree with that evaluation. It started in practice with the
famous "one-level storage system" paper from Manchester**, with the
specific goal of making a small high-speed memory look like a much
larger one. I don't think it was viewed as a work-around, but rather
as a brilliant engineering solution to the high cost of high-speed
memory, vastly easier to use than explicit overlays.

**One-Level Storage System, T. Kilburn, D. B. G. Edwards, M. J. Lanigan, F. H. Sumner, IRE Trans. Electronic Computers EC11(2), April 1962, 223-235.

Full disclosure: I am biased. Frank Sumner was my M.Sc. supervisor.

   Brian

> introduced us to a whole different way of thinking about memory. we now 
> have systems in production that always have physical RAM enough for 
> their work load, and who have no backing store for RAM (paging or 
> swapping) but which still depend on virtual memory for other reasons:
> 
> 1. linear address space; all processes think they have addresses 
> starting from 0.
> 
> 2. page-level protection; various parts of memory are only readable, or 
> writable, or executable, when needed, and at certain privilege levels.
> 
> 3. occasional sharing and/or persistence (memory mapped files).
> 
> 4. occasional distributed persistence (networked virtual memory).
> 
> i think a lot of things that begin as stop-gaps turn out to have many 
> purposes beyond that initial stopped gap, and would have been invented 
> anyway, if somewhat later, for those other reasons.
> 
> LISP may be an example. NAT certainly is.
> 
> i mention this because not all ideas which were terrible $originally 
> remain terrible in $internet_history.
> 




From nigel at channelisles.net  Tue Oct 24 13:32:36 2017
From: nigel at channelisles.net (Nigel Roberts)
Date: Tue, 24 Oct 2017 21:32:36 +0100
Subject: [ih] vm vs. memory
In-Reply-To: <4DCB4E63-5513-4571-B5B5-803F6E47EA72@redbarn.org>
References: <59EF2E16.1040906@redbarn.org>
	<becebb95-8166-4d61-8fc7-c7ae80a8f0ab@dcrocker.net>
	<4DCB4E63-5513-4571-B5B5-803F6E47EA72@redbarn.org>
Message-ID: <283a80cb-bfba-42d8-04b1-c7884159b16a@channelisles.net>

It does, however, apply to a lot of problems in life, as well as 
computer science . . .



On 10/24/2017 08:37 PM, P Vix wrote:
> That adage doesn't apply to problems you don't yet know you will have.
> 
> On October 24, 2017 9:31:47 PM GMT+02:00, Dave Crocker <dhc2 at dcrocker.net> wrote:
>> On 10/24/2017 5:12 AM, Paul Vixie wrote:
>>> vm is an example of something that started as a workaround but
>>> introduced us to a whole different way of thinking about memory.
>>
>>
>> And yet, arguably, it is nothing but the productive application of the
>> Lampson (or Wheeler) adage: "All problems in computer science can be
>> solved by another level of indirection."
>>
>>
>> d/
>> -- 
>> Dave Crocker
>> Brandenburg InternetWorking
>> bbiw.net
> 
> 
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


From johnl at iecc.com  Tue Oct 24 14:11:23 2017
From: johnl at iecc.com (John Levine)
Date: 24 Oct 2017 21:11:23 -0000
Subject: [ih] vm vs. memory
In-Reply-To: <593e3d78-5af7-e30b-a1ae-ad875ddee643@gmail.com>
Message-ID: <20171024211123.7624.qmail@ary.lan>

In article <593e3d78-5af7-e30b-a1ae-ad875ddee643 at gmail.com> you write:
>I disagree with that evaluation. It started in practice with the
>famous "one-level storage system" paper from Manchester**, with the
>specific goal of making a small high-speed memory look like a much
>larger one. I don't think it was viewed as a work-around, but rather
>as a brilliant engineering solution to the high cost of high-speed
>memory, vastly easier to use than explicit overlays.

But it was a workaround, albeit a much nicer one than explicit
overlays (this I know, having done digital origami with overlay
loaders.)  What they really wanted in both cases was enough RAM to run
the program.  Since they didn't, they had various kludges to fake it.

VM stopped being a workaround when people realized that you could use
the same hardware to unify RAM and disk files.  It didn't take long,
Multics was doing that by 1966 and TSS/360 (badly) in 1967.

R's,
John


From jnc at mercury.lcs.mit.edu  Tue Oct 24 14:16:51 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 24 Oct 2017 17:16:51 -0400 (EDT)
Subject: [ih] vm vs. memory
Message-ID: <20171024211651.4E01018C0A3@mercury.lcs.mit.edu>

    > From: Paul Vixie

    > every other attempt to add rapid renumbering and transparent
    > multihoming has been rejected. NAT, by not trying to do those things
    > and by not saying it would do those things, snuck under the defenses.

Bearing in mind that this is the Internet-_History_ list, and not the
Internet-_Architecture_ list, I will say just a little bit.

If you want your system to be able to do 'rapid re-numbering' and 'transparent
multi-homing' (and I'm not sure quite what you mean by that latter - having
two interfaces, and being able to sustain a connection from either one, is a
whole different kettle of fish from being able to use either interface for a
single connection, which is _much_ harder), you need to list those as
requirements when you sit down and do the basic architecure - including the
routing and addressing architecture (well, the whole naming architecture,
actually; of which addresses - topological names - are just one class).

IPv4 can't do either (those not having been goals when it was designed), and
since v6 is (basically) 'v4 with a few more bits', it's no surprise that it
can't do them either.


I've thought extensively about how to do 'hard multi-homing' (as I'll name
that particular flavour), and it's doable, but it needs to be built in up
front.

As to 'rapid re-numbering', I've given that less thought, although I know (I
think!) how it has to be approached. Again, it has to be built in up front.


NAT may do these things (as a side effect; that wasn't its original goal when
Paul and Van came up with it), but NAT has the issue that it puts a lot of
state in the network, and does so invisibly.

This may or may not be a problem: in theory it should make the network more
'brittle' (by having state out there, state that you can't see, and thus
can't manage), but in practise it seems to work OK - actual problems seem to
be more likely to be caused by DNS issues, etc.

	Noel


From brian.e.carpenter at gmail.com  Tue Oct 24 15:00:39 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Wed, 25 Oct 2017 11:00:39 +1300
Subject: [ih] vm vs. memory
In-Reply-To: <20171024211123.7624.qmail@ary.lan>
References: <20171024211123.7624.qmail@ary.lan>
Message-ID: <519286a2-76c4-ac91-9deb-d9dcc3ae6529@gmail.com>

On 25/10/2017 10:11, John Levine wrote:
> In article <593e3d78-5af7-e30b-a1ae-ad875ddee643 at gmail.com> you write:
>> I disagree with that evaluation. It started in practice with the
>> famous "one-level storage system" paper from Manchester**, with the
>> specific goal of making a small high-speed memory look like a much
>> larger one. I don't think it was viewed as a work-around, but rather
>> as a brilliant engineering solution to the high cost of high-speed
>> memory, vastly easier to use than explicit overlays.
> 
> But it was a workaround, albeit a much nicer one than explicit
> overlays (this I know, having done digital origami with overlay
> loaders.)  What they really wanted in both cases was enough RAM to run
> the program.  Since they didn't, they had various kludges to fake it.
> 
> VM stopped being a workaround when people realized that you could use
> the same hardware to unify RAM and disk files.  

But that's exactly what ATLAS did. The one-level paper goes into
a lot of detail about the ATLAS o/s, and when you wrote code in
Atlas Autocode you simply didn't know that there was both core
and disk memory. (Atlas Autocode was my first real programming
language, ignoring a brief flurry with Titan Autocode).

> It didn't take long,
> Multics was doing that by 1966 and TSS/360 (badly) in 1967.

Yes, Multics did it really nicely. And then we got Peter Denning's
original paper on working sets (http://denninginstitute.com/pjd/PUBS/Workingsets.html ).
In the third paper on that page, Denning says this:

In 1961 the group at Manchester, England,
published a proposal for a one-level
store on the Atlas computer [F3, K3], a
proposal that has had profound influence
on computer System architecture. Their
idea, known now as virtual memory, gives
the programmer the illusion that he has a
very large main memory at his disposal,
even though the computer actually has a
relatively small main memory. At the heart
of their idea is the notion that "address"
is a concept distinct from "physical location."

  Brian


From pnr at planet.nl  Tue Oct 24 15:47:17 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 25 Oct 2017 00:47:17 +0200
Subject: [ih] BBN C-series computers
In-Reply-To: <14210.1508871153@serenity.jjd.com>
References: <u8b4vsrdiawy6hsp9h020rld.1508808362948@email.android.com>
	<14210.1508871153@serenity.jjd.com>
Message-ID: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>


> On 24 Oct 2017, at 20:52, James J Dempsey <jjd at 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).




From johnl at iecc.com  Tue Oct 24 15:53:34 2017
From: johnl at iecc.com (John R. Levine)
Date: 24 Oct 2017 18:53:34 -0400
Subject: [ih] vm vs. memory
In-Reply-To: <519286a2-76c4-ac91-9deb-d9dcc3ae6529@gmail.com>
References: <20171024211123.7624.qmail@ary.lan>
	<519286a2-76c4-ac91-9deb-d9dcc3ae6529@gmail.com>
Message-ID: <alpine.OSX.2.21.1710241851350.7543@ary.qy>

>> VM stopped being a workaround when people realized that you could use
>> the same hardware to unify RAM and disk files.
>
> But that's exactly what ATLAS did. The one-level paper goes into
> a lot of detail about the ATLAS o/s, and when you wrote code in
> Atlas Autocode you simply didn't know that there was both core
> and disk memory. (Atlas Autocode was my first real programming
> language, ignoring a brief flurry with Titan Autocode).

I read the paper and it looked like it just gave you a big flattish 
address space, not a file system.  Multics and TSS had file systems with 
persistent named files.

R's,
John


From dhc2 at dcrocker.net  Tue Oct 24 16:07:27 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Tue, 24 Oct 2017 16:07:27 -0700
Subject: [ih] vm vs. memory
In-Reply-To: <20171024211651.4E01018C0A3@mercury.lcs.mit.edu>
References: <20171024211651.4E01018C0A3@mercury.lcs.mit.edu>
Message-ID: <ea99fcb6-e55b-4288-3637-bce586005579@dcrocker.net>

On 10/24/2017 2:16 PM, Noel Chiappa wrote:
> I've thought extensively about how to do 'hard multi-homing' (as I'll name
> that particular flavour), and it's doable, but it needs to be built in up
> front.

In theory, it's not that difficult.  </insert ironic smiley>

Seriously:  insert not a smiley but a layer that looks like transport to 
the application but actually is session, and have the session open more 
than one transport connection that transit different paths.  (How to get 
the transports to do that has various 'solutions' as an implementation 
exercise or research topic, as you wish.)

With some tuning for synchronization and recovery -- and, ok, that's 
some engineering work, but not difficult -- the loss of one or another 
connection is merely reflected by a moment of delay to the application.

This requires participation by both ends, but the design and operation 
of this session layer wouldn't be that challenging.

BTW, TLS was really designed as a session layer, which means that 
modifying a few TLS libraries might make this a viable enhancement in a 
reasonable timeframe.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From dhc2 at dcrocker.net  Tue Oct 24 16:07:51 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Tue, 24 Oct 2017 16:07:51 -0700
Subject: [ih] vm vs. memory
In-Reply-To: <4DCB4E63-5513-4571-B5B5-803F6E47EA72@redbarn.org>
References: <59EF2E16.1040906@redbarn.org>
	<becebb95-8166-4d61-8fc7-c7ae80a8f0ab@dcrocker.net>
	<4DCB4E63-5513-4571-B5B5-803F6E47EA72@redbarn.org>
Message-ID: <5842068a-6b3d-f89b-d3e0-edb6622069de@dcrocker.net>

On 10/24/2017 12:37 PM, P Vix wrote:
> That adage doesn't apply to problems you don't yet know you will have.
> 
> On October 24, 2017 9:31:47 PM GMT+02:00, Dave Crocker 
> <dhc2 at dcrocker.net> wrote:
...
>     And yet, arguably, it is nothing but the productive application of the
>     Lampson (or Wheeler) adage: "All problems in computer science can be
>     solved by another level of indirection."


It occurs to me that -- absent solid, relevant experience upon which to 
base the prediction of such problems or at least likely benefits -- 
application of the adage tends to have the property of /creating/ 
problems, by virtue of added complexity, administration, inefficiencies, 
and the like...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From paul at redbarn.org  Tue Oct 24 17:13:48 2017
From: paul at redbarn.org (Paul Vixie)
Date: Wed, 25 Oct 2017 02:13:48 +0200
Subject: [ih] vm vs. memory
In-Reply-To: <20171024180741.6920.qmail@ary.lan>
References: <20171024180741.6920.qmail@ary.lan>
Message-ID: <59EFD73C.4040003@redbarn.org>

"egads, what i have i done?" --me

omnibus: there are four replies here.

---

John Levine wrote:
> In article<59EF79D0.2060906 at redbarn.org>  you write:
>>> Hmm... what are the redeeming qualities of NAT ?
>> every other attempt to add rapid renumbering and transparent multihoming
>> has been rejected. NAT, by not trying to do those things and by not
>> saying it would do those things, snuck under the defenses.
>
> There's also the fact that for most practical purposes, NAT just
> works, and IPv6 still doesn't.

to be clearer, ipv6 is not a salve for the ills addressed by NAT. there 
was some hope early on that ipv6 would offer an alternative to the pi/pa 
split, but ultimately every proposal was shot down in favour of a 
marketing slogan to get deployment to happen, somehow, anyway: "ipv6: no 
magic, just more bits."

with ipv6, nat is still required. but we use "ULA" so that if two 
companies both using ipv6 nat merge, neither has to renumber. that is a 
small upgrade from ipv4 where both companies used net-10, and it is not 
significant in internet history.

---

Toerless Eckert wrote:
 > Yes, these are the classical arguments.

[vixie]
 >> 1. the internal structure should not be visible or guessable.
 >>
 >> 2. reachability should be prevented by more than just firewalls.
 >>
 >> 3. you can add and drop transit providers as often as you want.

 > IMHO, arguments 1. and 2. have mostly failed, especially
 > in large enterprises.

you are wrong, by being outside the facts. your observations here are 
examples of absurdist reductionism, reminding me of the time someone 
explained to me why ipv6 added only three effective bits to those 
available to an endpoint, compared to ipv4. your criticism may look good 
on a whiteboard, but it completely fails to impress anybody who ever 
built a real network.

(that was the gentle version, edited after several hours of mellowing.)

 > Argument 3 (i think you mean access providers) is more interesting.

on this, we agree.

 > If it was me, would have just evolved and improved on rfc1928.

me too, which is why <http://family.redbarn.org/~vixie/proxynet.pdf>, 
but it was not accepted for publication, because by 1995, the world was 
converging on SOCKS.

---

Brian E Carpenter wrote:
 > On 25/10/2017 01:12, Paul Vixie wrote:
 >>
 >> vm is an example of something that started as a workaround but ...
 >
 > I disagree with that evaluation. It started in practice with the
 > famous "one-level storage system" paper from Manchester**, with the
 > specific goal of making a small high-speed memory look like a much
 > larger one. I don't think it was viewed as a work-around, but rather
 > as a brilliant engineering solution to the high cost of high-speed
 > memory, vastly easier to use than explicit overlays.

john levine already answered this, as well or better than i could have.

---

Noel Chiappa wrote:
 >      >  From: Paul Vixie
 >
>> every other attempt to add rapid renumbering and transparent
>> multihoming has been rejected. NAT, by not trying to do those
>> things and by not saying it would do those things, snuck under the
>> defenses.
 >
 > Bearing in mind that this is the Internet-_History_ list, and not the
 > Internet-_Architecture_ list, I will say just a little bit.

thank you for restricting your comments to matters of history.

> If you want your system to be able to do 'rapid re-numbering' and
> 'transparent multi-homing' (and I'm not sure quite what you mean by
> that ... you need to list those as requirements when you sit down and
> do the basic architecure - including the routing and addressing
> architecture ...

mr. chiappa, let me first say that you have always been something of a 
hero to me, largely due to your now-famous anti-RIP screed from decades 
ago. you were right in everything you said, and noone ever said it 
better. it therefore alarms me mildly to be disagreeing with you here.

the internet wasn't a wanted system. it's the perfect example of an 
airplane that would have to be launched unready, and then continuously 
rebuilt during flight. noone knew back-in-the-day what it would have to 
do. someone codified this with a famous aphorism, "we don't know what 
the world's digital infrastructure will look like 200 years from now, 
but we know it will be called The Internet."

there were no requirements, only vague ideas about interoperability and 
lack of central control. it was therefore never possible, ever, 
anywhere, to authoritatively "list those as requirements when you sit 
down". we never sat down, and we never will.

> I've thought extensively about how to do 'hard multi-homing' (as I'll
> name that particular flavour), and it's doable, but it needs to be
> built in up front.

i wish you well on your journey; let us all know how that works out for 
you. my own belief is that whatever we do next (ever), will be done from 
the network as it then exists, and that "up front" never happened, and 
never shall happen. i'll quote from my thesis, which Keio graciously 
allowed me to publish only in paper form so that it's weaknesses would 
be difficult to mine. (source code was in Lout:)

> @Section @Title {Rebuilding The Airplane In Flight} @Begin @DP
> All of the work described in this thesis was accomplished continuously with
> Internet and DNS service.  Each protocol change was introduced gradually and
> optionally such that previously existing client or server was adversely
> affected.  At times it was necessary to support incorrect existing practices
> by other implementers due to the size of the installed base.  In situations
> where the existing specification was ambiguous new features had to be encoded
> in a way that avoided this ambiguity or that required implementers of new
> features to do additional work to differentiate among ambiguous cases.
> @PP
> Neither the Internet nor the DNS can be stopped and restarted, nor upgraded
> as a whole unit.  New features must always be introduced in a way that is
> backward compatible and thus ``roll out'' incrementally.  This is similar in
> concept to rebuilding an airplane while in flight except with multiple teams
> working on different parts of the airplane at the same time and without an
> agreed upon plan for the new design.  In real terms this means that features
> such as those described in this document can take decades to fully design and
> deploy.  For this work it took 17 years.
> @End @Section

see also: <http://queue.acm.org/detail.cfm?id=1242499>

-- 
P Vixie



From brian.e.carpenter at gmail.com  Tue Oct 24 17:24:12 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Wed, 25 Oct 2017 13:24:12 +1300
Subject: [ih] vm vs. memory
In-Reply-To: <alpine.OSX.2.21.1710241851350.7543@ary.qy>
References: <20171024211123.7624.qmail@ary.lan>
	<519286a2-76c4-ac91-9deb-d9dcc3ae6529@gmail.com>
	<alpine.OSX.2.21.1710241851350.7543@ary.qy>
Message-ID: <42e5896c-3c1e-959e-d004-6734873dda93@gmail.com>

On 25/10/2017 11:53, John R. Levine wrote:
>>> VM stopped being a workaround when people realized that you could use
>>> the same hardware to unify RAM and disk files.
>>
>> But that's exactly what ATLAS did. The one-level paper goes into
>> a lot of detail about the ATLAS o/s, and when you wrote code in
>> Atlas Autocode you simply didn't know that there was both core
>> and disk memory. (Atlas Autocode was my first real programming
>> language, ignoring a brief flurry with Titan Autocode).
> 
> I read the paper and it looked like it just gave you a big flattish 
> address space, not a file system.  Multics and TSS had file systems with 
> persistent named files.

Yes. There's no doubt that Multics was a great conceptual advance.

    Brian


From johnl at iecc.com  Tue Oct 24 17:34:35 2017
From: johnl at iecc.com (John R. Levine)
Date: 24 Oct 2017 20:34:35 -0400
Subject: [ih] vm vs. memory
In-Reply-To: <42e5896c-3c1e-959e-d004-6734873dda93@gmail.com>
References: <20171024211123.7624.qmail@ary.lan>
	<519286a2-76c4-ac91-9deb-d9dcc3ae6529@gmail.com>
	<alpine.OSX.2.21.1710241851350.7543@ary.qy>
	<42e5896c-3c1e-959e-d004-6734873dda93@gmail.com>
Message-ID: <alpine.OSX.2.21.1710242032430.7624@ary.qy>

>> I read the paper and it looked like it just gave you a big flattish
>> address space, not a file system.  Multics and TSS had file systems with
>> persistent named files.
>
> Yes. There's no doubt that Multics was a great conceptual advance.

In case it's not clear, I agree that the VM in the Atlas was a big deal. 
As far as I can tell, at the time nobody anticpated that the same hardware 
and software could be used to provide file systems.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From crossd at gmail.com  Tue Oct 24 17:38:58 2017
From: crossd at gmail.com (Dan Cross)
Date: Tue, 24 Oct 2017 20:38:58 -0400
Subject: [ih] vm vs. memory
In-Reply-To: <593e3d78-5af7-e30b-a1ae-ad875ddee643@gmail.com>
References: <59EF2E16.1040906@redbarn.org>
	<593e3d78-5af7-e30b-a1ae-ad875ddee643@gmail.com>
Message-ID: <CAEoi9W78rebftgAV-gvBi-GTmzQT3O2zBnLoocaU1WRRok5KKA@mail.gmail.com>

On Tue, Oct 24, 2017 at 3:42 PM, Brian E Carpenter
<brian.e.carpenter at gmail.com> wrote:
> On 25/10/2017 01:12, Paul Vixie wrote:
>> Joe Touch wrote:
>> ...
>>> IMO, they?re no more a stop-gap to networking than VM is to memory.
>>>
>>> But we?re digressing from the original thread...
>>
>> that's hard to say, but i've forked the thread anyway.
>>
>> vm is an example of something that started as a workaround but
>
> I disagree with that evaluation. It started in practice with the
> famous "one-level storage system" paper from Manchester**, with the
> specific goal of making a small high-speed memory look like a much
> larger one. I don't think it was viewed as a work-around, but rather
> as a brilliant engineering solution to the high cost of high-speed
> memory, vastly easier to use than explicit overlays.
>
> **One-Level Storage System, T. Kilburn, D. B. G. Edwards, M. J. Lanigan, F. H. Sumner, IRE Trans. Electronic Computers EC11(2), April 1962, 223-235.
>
> Full disclosure: I am biased. Frank Sumner was my M.Sc. supervisor.

The VM system in Atlas was, apparently, controversial. Rob Pike said
that the decision to put VM (in Paul's sense) into Plan 9 resulted in
raising his boss's ire, due to a bad experience with Atlas:
https://marc.info/?l=9fans&m=111558822910429&w=2

        - Dan C.



From brian.e.carpenter at gmail.com  Tue Oct 24 17:40:11 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Wed, 25 Oct 2017 13:40:11 +1300
Subject: [ih] vm vs. memory
In-Reply-To: <59EFD73C.4040003@redbarn.org>
References: <20171024180741.6920.qmail@ary.lan> <59EFD73C.4040003@redbarn.org>
Message-ID: <37abf1f5-cb1d-7336-caa9-e901131bd4db@gmail.com>

On 25/10/2017 13:13, Paul Vixie wrote:
...
> Neither the Internet nor the DNS can be stopped and restarted, nor upgraded
> as a whole unit.  New features must always be introduced in a way that is
> backward compatible and thus ``roll out'' incrementally. 

+1e6

(Which is why we need to understand history.)

   Brian


From dhc2 at dcrocker.net  Tue Oct 24 17:52:22 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Tue, 24 Oct 2017 17:52:22 -0700
Subject: [ih] vm vs. memory
In-Reply-To: <59EFD73C.4040003@redbarn.org>
References: <20171024180741.6920.qmail@ary.lan> <59EFD73C.4040003@redbarn.org>
Message-ID: <a59fbc39-f20c-752a-902f-39f17898b732@dcrocker.net>

On 10/24/2017 5:13 PM, Paul Vixie wrote:
> with ipv6, nat is still required. but we use "ULA" so that if two
> companies both using ipv6 nat merge, neither has to renumber. that is a
> small upgrade from ipv4 where both companies used net-10, and it is not
> significant in internet history.


Actually in terms of operational pragmatics, and given an on-going load 
of organizational combinatorials, I suspect that's a highly significant 
benefit.

Who knew?

"IPv6, The M&A Friend" (sm)

or:

"IPv6, Permanent Private Numbering" (sm?)


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From bernie at fantasyfarm.com  Tue Oct 24 18:31:41 2017
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Tue, 24 Oct 2017 21:31:41 -0400
Subject: [ih] vm vs. memory
In-Reply-To: <37abf1f5-cb1d-7336-caa9-e901131bd4db@gmail.com>
References: <20171024180741.6920.qmail@ary.lan>, <59EFD73C.4040003@redbarn.org>,
	<37abf1f5-cb1d-7336-caa9-e901131bd4db@gmail.com>
Message-ID: <59EFE97D.16111.4070DBDF@bernie.fantasyfarm.com>

On 25 Oct 2017 at 13:40, Brian E Carpenter wrote:

> On 25/10/2017 13:13, Paul Vixie wrote:
> ...
> > Neither the Internet nor the DNS can be stopped and restarted, nor
> upgraded
> > as a whole unit.  New features must always be introduced in a way that
> is
> > backward compatible and thus ``roll out'' incrementally. 
> 
> +1e6
> 
> (Which is why we need to understand history.)

I first learned that with the ARPANET IMP code.  Before that, the systems 
I worked on could be taken down in the middle of the and new things 
tested, and then the old system put back if necessary.  With the ARPAnet, 
there was almost no time, day or night, that the IMPs could go offline.  
We quickly learned that something had to change, it was in three steps: 
1) put in code that handled the old way AND the new way [and of course, 
figured out which was which].  2) distribute code to switch over to the 
new way [could be done a few systems at a time to limit the damage if 
something went wrong], 3) take out the old-way code.  I can't imagine how 
you'd do something like that in today's internet, where noone has control 
over everything and so there's no way to get *anyone* to change their 
code [if they even can]

I think I only crashed the ARPAnet once [or maybe twice] with a buggy 
patch... sigh..

/Bernie\

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





From pnr at planet.nl  Wed Oct 25 04:17:34 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 25 Oct 2017 13:17:34 +0200
Subject: [ih]  BBN C-series computers
Message-ID: <DF072B64-5A0D-4A77-8AD1-190FFFF0EA8C@planet.nl>


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).









From jnc at mercury.lcs.mit.edu  Wed Oct 25 06:13:48 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 25 Oct 2017 09:13:48 -0400 (EDT)
Subject: [ih] vm vs. memory
Message-ID: <20171025131348.396D318C0A9@mercury.lcs.mit.edu>

    > From: Paul Vixie

    > an alternative to the pi/pa split

In a very large network, the path-selection system needs names (in the
general sense; 'addresses' are a class of names) which have topological
significance. That's from the math; that's the immovable rock.

If names are needed which have properties which conflict with that, you need
another namespace. That's the irresistable force.


    > it therefore alarms me mildly to be disagreeing with you here.

I'm not sure we disagree as much as you think...

    > the internet wasn't a wanted system. ...  an airplane that would have to
    > be launched unready, and then continuously rebuilt during flight. ...
    > ... it was therefore never possible, ever, anywhere, to authoritatively
    > "list those as requirements when you sit down"
    > ...
    > my own belief is that whatever we do next (ever), will be done from the
    > network as it then exists, and that "up front" never happened, and never
    > shall happen.

I don't disagree. But that doesn't mean we did as well as we could have - the
above being an example.

It was perfectly obvious _at the time_ that with only one namespace, immovable
objects were going to meet irresistable forces. But people preferred to, I
dunno, put their heads in the sand? I still don't really understand why people
didn't draw the appropriate conclusion - perhaps the pill was too big to
swallow?


(Actual history interjection: shortly before the IPv6 process, a fellow member
of the IESG said something that I took be an aspersion on my character. Exactly
what it was, I no longer recall [perhaps Craig does, I talked to him about
what I should do]. It was something to the effect that some commercial people
were not keeping the Internet's best interests as their top priority, or
something like that. Anyway, that was kind of the last straw - I was already
terribly stressed out by other things - so I resigned from the IESG to prove
that the accusation was untrue. Needless to say, had I still been on the IESG
at the time of the IPv6 process, that design would _never_ have been accepted
- 'over my dead body'. Here's the kicker: some years later, chatting to the
person, I discovered he hadn't been talking about me at all! On such
accidents does the course of history turn!)


But back to doing architecture on a flying airplane...

The need to evolve a running system does prevent a severe challenge to the
architect. (Architects are usually given a blank sheet of paper, precisely so
they can draw what's _needed_, after an open-ended analysis of the whole
thing.) But after thinking about this for a while, I think one still needs to
perform much the same process, even for an evolving system: analyze the whole
system at a deep level, taking in mind what it needs to do.

The reason is that if you evolve a system _without understanding where you
want to wind up (with a coherent system, designed _as a system_), you'll wind
up with a convoluted cancer that doesn't do a lot of what you want it to.

(There's some aphorism, along the line of 'a journey of a thousand miles
starts with a single step', that catches this idea of 'if you don't know where
you're going, you probably won't get there', but my mind can't recall it at
the moment.)

So, yes, in an evolving system like the Internet, one may not have all the
requirements in hand at any point, _but_ at any point in time, one should have

- i) the requirements, as best they are understood at the time
- ii) an overall system architecture which meets those goals, starting with
  'how many namespaces are there, and what are their semantics'
- iii) a plan for how to evolve the system to get there, from where you are

Of course, the list of requirements will change over time, which will have
ripple-down consequences through the next stages; but note that things like
the second step should are planning 30-50 years out, so if that gets changed,
because of the time lag, you're changing stuff that hasn't happened yet. (And
the third step probably covers a 10-20 year timeframe; the thought being that
at the end of that process, you'll have a system which is good for the 50 year
time-frame.)

Will things happen exactly according to that plan? No, of course things change
(e.g. disruptive technology) in ways one can't forsee. But if one has
correctly understood the fundamentals, those don't change. (We still have
stacks, procedures, etc - because the fundamentals there were correctly
understood.) So the plan has to adapt and evolve. (Corby said something to
this effect in his Multics appraisal paper, about how a system needs a rudder,
so you can change course.)

But unless you know where you're going, you won't get there.

There is no evidence known to me that the I* community ever had anything like
this. I did some on my own, but that's not very effective. I consider this
professional nonfeasance on the part of the Internet engineering commmunity,
but that's water over the dam now.


    > Neither the Internet nor the DNS can be stopped and restarted, nor
    > upgraded as a whole unit.  New features must always be introduced in a
    > way that is backward compatible and thus ``roll out'' incrementally.

Agree 100%.

    > This is similar in concept to rebuilding an airplane while in flight
    > except with multiple teams working on different parts of the airplane at
    > the same time and without an agreed upon plan for the new design.

I can pretty much guarantee you that if you re-build a plane, _without some
overall plan as to what the result will be_, your plane will not work.

	Noel


From dhc2 at dcrocker.net  Wed Oct 25 07:19:12 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Wed, 25 Oct 2017 07:19:12 -0700
Subject: [ih] vm vs. memory
In-Reply-To: <59EFE97D.16111.4070DBDF@bernie.fantasyfarm.com>
References: <20171024180741.6920.qmail@ary.lan> <59EFD73C.4040003@redbarn.org>
	<37abf1f5-cb1d-7336-caa9-e901131bd4db@gmail.com>
	<59EFE97D.16111.4070DBDF@bernie.fantasyfarm.com>
Message-ID: <652dd6f7-748e-f3c7-2ae1-61682fc6b668@dcrocker.net>

On 10/24/2017 6:31 PM, Bernie Cosell wrote:
> We quickly learned that something had to change, it was in three steps:
> 1) put in code that handled the old way AND the new way [and of course,
> figured out which was which].  2) distribute code to switch over to the
> new way [could be done a few systems at a time to limit the damage if
> something went wrong], 3) take out the old-way code.  I can't imagine how
> you'd do something like that in today's internet,


Adoption in general, and transition in particular, are usually treated 
as an afterthought in designing Internet technical standards.  This is 
probably why the major infrastructure upgrades take so long or just 
plain fail.

Incentives, effort, and the pure physics of scale dominate the reality 
of adoption and typically seem to be far more difficult to deal with 
than the task of designing whatever basic capability is the actual goal.

Neither after-though nor idealism are appropriate for overcoming this 
barrier.

However...

One exception to 'after-thought' that I've noticed as a pattern is to 
specify the hybrid capabilities in the same spec as the new spec.  That 
is, there is an explicit effort to pay quite a bit of attention to 
simultaneous support of the old functionality with the new. That's 
goodness, of course.  However this approach makes for excessive 
specification complexity and, usually, bogs the effort down.  It also 
means that there is no specification for the 'pure', desired and 
enhanced activity.

So my current view is that enhancement efforts need to specify the 
enhancement effort in its pure form, that can be characterized as a 
clean-slate, 'assume everyone is doing it' form of specification.  The 
same as if there were no history.  Then, separately, specify the hybrid 
operation.  For one thing, this seems to move more towards a model of 
gatewaying between the two worlds, rather than requiring everyone, 
everywhere, to support old and new forever.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From jjd at jjd.com  Wed Oct 25 08:27:43 2017
From: jjd at jjd.com (James J Dempsey)
Date: Wed, 25 Oct 2017 11:27:43 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
Message-ID: <18841.1508945263@serenity.jjd.com>

Paul Ruizendaal <pnr at planet.nl> wrote:

> > On 24 Oct 2017, at 20:52, James J Dempsey <jjd at 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--



From jack at 3kitty.org  Wed Oct 25 11:27:20 2017
From: jack at 3kitty.org (Jack Haverty)
Date: Wed, 25 Oct 2017 11:27:20 -0700
Subject: [ih] BBN C-series computers
In-Reply-To: <18841.1508945263@serenity.jjd.com>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
Message-ID: <6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>

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 <pnr at planet.nl> wrote:
> 
>>> On 24 Oct 2017, at 20:52, James J Dempsey <jjd at 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-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


From brian.e.carpenter at gmail.com  Wed Oct 25 12:10:32 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Thu, 26 Oct 2017 08:10:32 +1300
Subject: [ih] Could it have been different? [was Re:  vm vs. memory]
In-Reply-To: <20171025131348.396D318C0A9@mercury.lcs.mit.edu>
References: <20171025131348.396D318C0A9@mercury.lcs.mit.edu>
Message-ID: <9e975cdd-94c9-b2d4-c59f-ca43ef4eac9b@gmail.com>

On 26/10/2017 02:13, Noel Chiappa wrote:
...
> Needless to say, had I still been on the IESG
> at the time of the IPv6 process, that design would _never_ have been accepted
> - 'over my dead body'.

Counterfactuals are always fun. However, I believe that the sad fact is that
*no* IPng solution of any kind whatever could in practice have been deployed
smoothly. Why? Because of Tim Berners-Lee, Marc Andreessen and a few other 
people. By the time any IPng code could have been available (the first
commercial release of IPv6 code was in 1996), the growth rate of IPv4 and
the inevitability of NAT44 made deployment very hard indeed; the incentives
were all for deploying more and more IPv4, and remained that way for 15+
years.

Now that IPv4 is truly hitting its limits, the main operational complaint
against IPv6 is that it's too different from IPv4. But the incentives are
finally shifting in IPv6's favour, like it or not.

The reason that there is still thrashing in IPv6 transition discussions
is that the original IPv6 transition plan was designed for a different world.
I suspect that the root cause of the IPv6 issues that John Levine mentioned
lies there.

    Brian


From mfidelman at meetinghouse.net  Wed Oct 25 12:11:27 2017
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Wed, 25 Oct 2017 15:11:27 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
Message-ID: <9c4858a9-2bda-43da-2569-e1a79cc3f70e@meetinghouse.net>

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



From vint at google.com  Wed Oct 25 12:27:59 2017
From: vint at google.com (Vint Cerf)
Date: Wed, 25 Oct 2017 15:27:59 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
Message-ID: <CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>

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 <jack at 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 <pnr at planet.nl> wrote:
> >
> >>> On 24 Oct 2017, at 20:52, James J Dempsey <jjd at 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-history at postel.org
> > http://mailman.postel.org/mailman/listinfo/internet-history
> > Contact list-owner at postel.org for assistance.
> >
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>



-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171025/64f16d6b/attachment.htm>

From vint at google.com  Wed Oct 25 12:28:30 2017
From: vint at google.com (Vint Cerf)
Date: Wed, 25 Oct 2017 15:28:30 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
	<CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>
Message-ID: <CAHxHggfxRnDt_2x0eaR9s84w-o-51yrTb-dnnHM_ix4a_ZY4eA@mail.gmail.com>

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

v


On Wed, Oct 25, 2017 at 3:27 PM, Vint Cerf <vint at 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 <jack at 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 <pnr at planet.nl> wrote:
>> >
>> >>> On 24 Oct 2017, at 20:52, James J Dempsey <jjd at 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-history at postel.org
>> > http://mailman.postel.org/mailman/listinfo/internet-history
>> > Contact list-owner at postel.org for assistance.
>> >
>> _______
>> internet-history mailing list
>> internet-history at postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-owner at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171025/958fa0de/attachment.htm>

From dhc2 at dcrocker.net  Wed Oct 25 13:27:52 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Wed, 25 Oct 2017 13:27:52 -0700
Subject: [ih] Could it have been different? [was Re: vm vs. memory]
In-Reply-To: <9e975cdd-94c9-b2d4-c59f-ca43ef4eac9b@gmail.com>
References: <20171025131348.396D318C0A9@mercury.lcs.mit.edu>
	<9e975cdd-94c9-b2d4-c59f-ca43ef4eac9b@gmail.com>
Message-ID: <3f2e31e1-d9be-a45f-773b-3e2908db9fdd@dcrocker.net>

On 10/25/2017 12:10 PM, Brian E Carpenter wrote:
> On 26/10/2017 02:13, Noel Chiappa wrote:
> ...
>> Needless to say, had I still been on the IESG
>> at the time of the IPv6 process, that design would _never_ have been accepted
>> - 'over my dead body'.
> 
> Counterfactuals are always fun. However, I believe that the sad fact is that
> *no* IPng solution of any kind whatever could in practice have been deployed
> smoothly. Why? Because of Tim Berners-Lee, Marc Andreessen and a few other
> people. By the time any IPng code could have been available (the first
> commercial release of IPv6 code was in 1996), the growth rate of IPv4 and
> the inevitability of NAT44 made deployment very hard indeed; the incentives
> were all for deploying more and more IPv4, and remained that way for 15+
> years.
> 
> Now that IPv4 is truly hitting its limits, the main operational complaint
> against IPv6 is that it's too different from IPv4. But the incentives are
> finally shifting in IPv6's favour, like it or not.
> 
> The reason that there is still thrashing in IPv6 transition discussions
> is that the original IPv6 transition plan was designed for a different world.
> I suspect that the root cause of the IPv6 issues that John Levine mentioned
> lies there.


Certitude about hypothetical pasts also is fun, but possibly 
distracting.  In this case, the premise is that nothing could have 
dislodged IPv4.  Yet we have quite a few examples of other major 
infrastructure upgrades -- and at different levels -- that worked well, 
or at least that worked.  There should be some respect for those 
accompishments and some attempt to understand why they succeeded when 
others -- such as IPv6 -- has not.

To work, an upgrade must either have no effect on the rest of the 
installed base, or it must have strong adoption incentives for those 
doing the adopting.  IPv6 has always suffered from more idealism in its 
incentives than immediate, operational pragmatics.

By way of reiterating a hypothetical alternative IPv6 approach that I've 
offered a number of times:

If Deering's original, simple IPv6 -- which only did exactly what was 
needed and did it cleanly, with a hook for /future/ enhancements -- had 
been adopted pretty much as is, the core IPv6 code would be very nearly 
identical to IPv4 code.

If the initial administration of address space were to apply the 
/existing/ IPv4 addresses -- reserving the remainder for later -- then 
v4/v6 interoperability would have required trivial gatewaying.  By the 
time more address space was actually needed, there would be a 
non-trivial amount of IPv6 code in operation.

The hand-wave, here, is for the application interfaces to IPv6 and, yes, 
that's additional, essential detail.  But my real point is that careful, 
focused attention to adoption as an incremental enhancement to the 
existing IPv4 infrastructure -- rather than inventing a completely 
independent, parallel stack -- then we could have started getting IPv6 
operational experience long before the end of the 1990s.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From dhc2 at dcrocker.net  Wed Oct 25 13:31:14 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Wed, 25 Oct 2017 13:31:14 -0700
Subject: [ih] BBN C-series computers
In-Reply-To: <9c4858a9-2bda-43da-2569-e1a79cc3f70e@meetinghouse.net>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
	<9c4858a9-2bda-43da-2569-e1a79cc3f70e@meetinghouse.net>
Message-ID: <c336514b-6201-05e7-546f-09d61d7021c3@dcrocker.net>

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


From brian.e.carpenter at gmail.com  Wed Oct 25 14:26:18 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Thu, 26 Oct 2017 10:26:18 +1300
Subject: [ih] Could it have been different? [was Re: vm vs. memory]
In-Reply-To: <3f2e31e1-d9be-a45f-773b-3e2908db9fdd@dcrocker.net>
References: <20171025131348.396D318C0A9@mercury.lcs.mit.edu>
	<9e975cdd-94c9-b2d4-c59f-ca43ef4eac9b@gmail.com>
	<3f2e31e1-d9be-a45f-773b-3e2908db9fdd@dcrocker.net>
Message-ID: <18e250da-46af-2e9b-a857-f40cd2e27f3c@gmail.com>

On 26/10/2017 09:27, Dave Crocker wrote:
> On 10/25/2017 12:10 PM, Brian E Carpenter wrote:
>> On 26/10/2017 02:13, Noel Chiappa wrote:
>> ...
>>> Needless to say, had I still been on the IESG
>>> at the time of the IPv6 process, that design would _never_ have been accepted
>>> - 'over my dead body'.
>>
>> Counterfactuals are always fun. However, I believe that the sad fact is that
>> *no* IPng solution of any kind whatever could in practice have been deployed
>> smoothly. Why? Because of Tim Berners-Lee, Marc Andreessen and a few other
>> people. By the time any IPng code could have been available (the first
>> commercial release of IPv6 code was in 1996), the growth rate of IPv4 and
>> the inevitability of NAT44 made deployment very hard indeed; the incentives
>> were all for deploying more and more IPv4, and remained that way for 15+
>> years.
>>
>> Now that IPv4 is truly hitting its limits, the main operational complaint
>> against IPv6 is that it's too different from IPv4. But the incentives are
>> finally shifting in IPv6's favour, like it or not.
>>
>> The reason that there is still thrashing in IPv6 transition discussions
>> is that the original IPv6 transition plan was designed for a different world.
>> I suspect that the root cause of the IPv6 issues that John Levine mentioned
>> lies there.
> 
> 
> Certitude about hypothetical pasts also is fun, but possibly 
> distracting.  In this case, the premise is that nothing could have 
> dislodged IPv4.  Yet we have quite a few examples of other major 
> infrastructure upgrades -- and at different levels -- that worked well, 
> or at least that worked.  There should be some respect for those 
> accompishments and some attempt to understand why they succeeded when 
> others -- such as IPv6 -- has not.
> 
> To work, an upgrade must either have no effect on the rest of the 
> installed base, or it must have strong adoption incentives for those 
> doing the adopting.  IPv6 has always suffered from more idealism in its 
> incentives than immediate, operational pragmatics.
> 
> By way of reiterating a hypothetical alternative IPv6 approach that I've 
> offered a number of times:
> 
> If Deering's original, simple IPv6 -- which only did exactly what was 
> needed and did it cleanly, with a hook for /future/ enhancements -- had 
> been adopted pretty much as is, the core IPv6 code would be very nearly 
> identical to IPv4 code.
> 
> If the initial administration of address space were to apply the 
> /existing/ IPv4 addresses -- reserving the remainder for later -- then 
> v4/v6 interoperability would have required trivial gatewaying.  By the 
> time more address space was actually needed, there would be a 
> non-trivial amount of IPv6 code in operation.
> 
> The hand-wave, here, is for the application interfaces to IPv6 and, yes, 
> that's additional, essential detail.  

Right. I remember doing a tour of the offices close to mine at CERN,
in around 1995, asking everybody who'd written code using the socket
interface how they stored IP addresses - in a struct or in an integer?
They all said "integer". That was the day I knew this would be hard.

> But my real point is that careful, 
> focused attention to adoption as an incremental enhancement to the 
> existing IPv4 infrastructure -- rather than inventing a completely 
> independent, parallel stack -- then we could have started getting IPv6 
> operational experience long before the end of the 1990s.

It's possible. But this wasn't perceived as an issue until the HTTP
explosion was well under way.

   Brian


From jack at 3kitty.org  Wed Oct 25 14:52:44 2017
From: jack at 3kitty.org (Jack Haverty)
Date: Wed, 25 Oct 2017 14:52:44 -0700
Subject: [ih] Internet history - code and people (was Re: BBN C-series
 computers)
In-Reply-To: <CAHxHggfxRnDt_2x0eaR9s84w-o-51yrTb-dnnHM_ix4a_ZY4eA@mail.gmail.com>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
	<CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>
	<CAHxHggfxRnDt_2x0eaR9s84w-o-51yrTb-dnnHM_ix4a_ZY4eA@mail.gmail.com>
Message-ID: <bad47f35-6cc8-2e3f-aaf0-d85cb135dd0a@3kitty.org>

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 <vint at google.com
> <mailto:vint at 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 <jack at 3kitty.org
>     <mailto:jack at 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 <pnr at planet.nl <mailto:pnr at planet.nl>> wrote:
>         >
>         >>> On 24 Oct 2017, at 20:52, James J Dempsey <jjd at jjd.com
>         <mailto:jjd at 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-history at postel.org <mailto:internet-history at postel.org>
>         > http://mailman.postel.org/mailman/listinfo/internet-history
>         <http://mailman.postel.org/mailman/listinfo/internet-history>
>         > Contact list-owner at postel.org <mailto:list-owner at postel.org>
>         for assistance.
>         >
>         _______
>         internet-history mailing list
>         internet-history at postel.org <mailto:internet-history at postel.org>
>         http://mailman.postel.org/mailman/listinfo/internet-history
>         <http://mailman.postel.org/mailman/listinfo/internet-history>
>         Contact list-owner at postel.org <mailto:list-owner at 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


From craig at tereschau.net  Wed Oct 25 15:08:43 2017
From: craig at tereschau.net (Craig Partridge)
Date: Wed, 25 Oct 2017 18:08:43 -0400
Subject: [ih] BBN C-series computers
In-Reply-To: <6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
Message-ID: <CAHQj4Ceima3riAk+_YNr0kf-pwjY0-SNwDp5gs1-6HcT-G=1aw@mail.gmail.com>

On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty <jack at 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. <craig at bbn.com>
partridge at raytheon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171025/a74d36df/attachment.htm>

From vint at google.com  Wed Oct 25 15:44:37 2017
From: vint at google.com (Vint Cerf)
Date: Wed, 25 Oct 2017 18:44:37 -0400
Subject: [ih] Internet history - code and people (was Re: BBN C-series
	computers)
In-Reply-To: <bad47f35-6cc8-2e3f-aaf0-d85cb135dd0a@3kitty.org>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
	<CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>
	<CAHxHggfxRnDt_2x0eaR9s84w-o-51yrTb-dnnHM_ix4a_ZY4eA@mail.gmail.com>
	<bad47f35-6cc8-2e3f-aaf0-d85cb135dd0a@3kitty.org>
Message-ID: <CAHxHggdMOOgUqEx31fCf3_g9PBbqA0CE2x2Epj8ah1vn6PhZ2A@mail.gmail.com>

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 <jack at 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 <vint at google.com
> > <mailto:vint at 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 <jack at 3kitty.org
> >     <mailto:jack at 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 <pnr at planet.nl <mailto:pnr at planet.nl>> wrote:
> >         >
> >         >>> On 24 Oct 2017, at 20:52, James J Dempsey <jjd at jjd.com
> >         <mailto:jjd at 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-history at 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-owner at postel.org <mailto:list-owner at postel.org>
> >         for assistance.
> >         >
> >         _______
> >         internet-history mailing list
> >         internet-history at postel.org <mailto:internet-history at postel.org>
> >         http://mailman.postel.org/mailman/listinfo/internet-history
> >         <http://mailman.postel.org/mailman/listinfo/internet-history>
> >         Contact list-owner at postel.org <mailto:list-owner at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171025/d4cc67ee/attachment.htm>

From wayne at playaholic.com  Wed Oct 25 16:27:20 2017
From: wayne at playaholic.com (Wayne Hathaway)
Date: Wed, 25 Oct 2017 19:27:20 -0400
Subject: [ih] Internet history - code and people (was Re: BBN
 C-series	computers)
In-Reply-To: <CAHxHggdMOOgUqEx31fCf3_g9PBbqA0CE2x2Epj8ah1vn6PhZ2A@mail.gmail.com>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
	<CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>
	<CAHxHggfxRnDt_2x0eaR9s84w-o-51yrTb-dnnHM_ix4a_ZY4eA@mail.gmail.com>
	<bad47f35-6cc8-2e3f-aaf0-d85cb135dd0a@3kitty.org>
	<CAHxHggdMOOgUqEx31fCf3_g9PBbqA0CE2x2Epj8ah1vn6PhZ2A@mail.gmail.com>
Message-ID: <201710252327.v9PNRKlJ009418@mail54c28.carrierzone.com>


	


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;jack at 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;vint at google.com
&gt; &lt;mailto:vint at 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;jack at 3kitty.org
&gt; &lt;mailto:jack at 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;pnr at planet.nl &lt;mailto:pnr at planet.nl&gt;&gt; wrote:
&gt; &gt;
&gt; &gt;&gt;&gt; On 24 Oct 2017, at 20:52, James J Dempsey &lt;jjd at jjd.com
&gt; &lt;mailto:jjd at 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-history at postel.org &lt;mailto:internet-history at 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-owner at postel.org &lt;mailto:list-owner at postel.org&gt;
&gt; for assistance.
&gt; &gt;
&gt; _______
&gt; internet-history mailing list
&gt; internet-history at postel.org &lt;mailto:internet-history at 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-owner at postel.org &lt;mailto:list-owner at 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




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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171025/3082efbd/attachment.htm>

From brian.e.carpenter at gmail.com  Wed Oct 25 18:18:35 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Thu, 26 Oct 2017 14:18:35 +1300
Subject: [ih] Internet history - code and people (was Re: BBN C-series
 computers)
In-Reply-To: <CAHxHggdMOOgUqEx31fCf3_g9PBbqA0CE2x2Epj8ah1vn6PhZ2A@mail.gmail.com>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
	<CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>
	<CAHxHggfxRnDt_2x0eaR9s84w-o-51yrTb-dnnHM_ix4a_ZY4eA@mail.gmail.com>
	<bad47f35-6cc8-2e3f-aaf0-d85cb135dd0a@3kitty.org>
	<CAHxHggdMOOgUqEx31fCf3_g9PBbqA0CE2x2Epj8ah1vn6PhZ2A@mail.gmail.com>
Message-ID: <01457bbc-8c58-c0a7-75ee-cd2279a6364d@gmail.com>

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 <jack at 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 <vint at google.com
>>> <mailto:vint at 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 <jack at 3kitty.org
>>>     <mailto:jack at 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 <pnr at planet.nl <mailto:pnr at planet.nl>> wrote:
>>>         >
>>>         >>> On 24 Oct 2017, at 20:52, James J Dempsey <jjd at jjd.com
>>>         <mailto:jjd at 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--




From paul at redbarn.org  Wed Oct 25 18:42:19 2017
From: paul at redbarn.org (Paul Vixie)
Date: Thu, 26 Oct 2017 03:42:19 +0200
Subject: [ih] fragmentation (Re: Could it have been different? [was Re: vm
 vs. memory])
Message-ID: <59F13D7B.7030503@redbarn.org>



Brian E Carpenter wrote:
...
> Now that IPv4 is truly hitting its limits, the main operational complaint
> against IPv6 is that it's too different from IPv4. But the incentives are
> finally shifting in IPv6's favour, like it or not.

i don't even know what i don't like anymore. but for the history books 
that may be written about our era, if indeed we have a future at all:

tony li said that ipv6 was too little, too soon. this was a play on 
words, because the usual complaint is "too little, too late". tony was 
right, even moreso than i realized at the time. we specified a lot of 
things that didn't work and had to be revised or thrown out -- because 
we did not know what we needed and we thought we were in a hurry. we had 
time, as history will show, to spend another ten years thinking about ipng.

where we are today is that fragmentation is completely hosed. pmtud does 
not work in practice, and also cannot work in theory due to scale 
(forget speed-- it's scale that kills.) the only reliable way to 
communicate with ipv6 is to use a low enough MTU that it never exceeds 
any link MTU. in practice that means an ipv6 payload, plus its headers, 
has to fit in an ethernet packet, so, 1500 octets. you can special case 
the on-link LAN scenario so that if you have 9000 octets available you 
can use them -- but that's the only time you can use more than about 
1200 octets for your payload.

this means one of ipv6's major claimed-up-front advantages, which is 
that only endpoints will fragment rather than gateways doing so as in 
ipv4, never came about. in fact, ipv6 is far worse than ipv4 in this 
way, as we learned by using ip fragmentation on UDP/53 (my idea: bad!)

this also means that we're chained to the MTU of the second-generation 
10-megabit ethernet, which was carefully sized to fit a bunch of radio 
spectrum and cable length parameters which have never applied since 
then. but the IEEE 802 people know they're stuck with 1500 forever, 
since no next generation of ethernet can succeed without being able to 
transparently bridge onto the previous generation.

history is hard, let's do math.

> ; (155*10^6) / (53*8)
>         ~365566.03773584905660377358
> ; (10*10^6) / (1500*8)
>         ~833.33333333333333333333
> ; (100*10^6) / (1500*8)
>         ~8333.33333333333333333333
> ; (1000*10^6) / (1500*8)
>         ~83333.33333333333333333333
> ; (10000*10^6) / (1500*8)
>         ~833333.33333333333333333333
> ; (40000*10^6) / (1500*8)
>         ~3333333.33333333333333333333
> ; (100000*10^6) / (1500*8)
>         ~8333333.33333333333333333333

right, so ATM failed in the market for a lot of reasons (state is what 
kills, not speed, like i said) but one of those reasons was that an OC3C 
at line rate was carrying too many cells per second to be able to handle 
all of their headers in then-current or even projected-soon electronics. 
we were wrong, and ATM has been used at OC12C, OC48C, and i've even seen 
OC192C and OC768C, truly a testament to human cussedness fit for a 
bumper sticker or perhaps a t-shirt.

looks to me like less than half a 10GBE is just as bad, and that at 
40GBE and 100GBE it's well beyond absurdity. thankful as we are for 
moore's law, i regret like anything the inability to send large enough 
packets in the WAN so that we don't all need a 100 kilowatt routers to 
handle the headers.

ipv6's mindless and unnecessary early adoption of an unworkable 
fragmentation regime has chained my applications and those of my 
children and their children to the maximum size of a packet in a closed 
10-megahertz radio network. yay us.

-- 
P Vixie



From paul at redbarn.org  Wed Oct 25 18:59:50 2017
From: paul at redbarn.org (Paul Vixie)
Date: Thu, 26 Oct 2017 03:59:50 +0200
Subject: [ih] vm vs. memory
In-Reply-To: <20171025131348.396D318C0A9@mercury.lcs.mit.edu>
References: <20171025131348.396D318C0A9@mercury.lcs.mit.edu>
Message-ID: <59F14196.5090401@redbarn.org>

warning: this message actually contains some historical references and 
stories concerning the internet.

Noel Chiappa wrote:
> ...
> The reason is that if you evolve a system _without understanding where you
> want to wind up (with a coherent system, designed _as a system_), you'll wind
> up with a convoluted cancer that doesn't do a lot of what you want it to.
> ...

i think that the internet is that, and had to be that, and that anything 
which wasn't going to become that, could not have become what the 
internet has become.

> So, yes, in an evolving system like the Internet, one may not have all the
> requirements in hand at any point, _but_ at any point in time, one should have
>
> - i) the requirements, as best they are understood at the time

such requirements are _highly_ subjective. what we actually do is add 
whatever anybody wants, no matter how bad an idea others may prove it to 
be. internet history interprets noncooperation as damage, and routes 
around it.

> - ii) an overall system architecture which meets those goals, starting with
>    'how many namespaces are there, and what are their semantics'

the IAB certainly tries. like when they said NAT was a bad idea. (hint.)

> - iii) a plan for how to evolve the system to get there, from where you are

there _never was_ enough cohesion among all the people and companies who 
wanted to add their protocol or their app or their feature to the 
internet, to get a meaningful plan. not even when the whole IETF fit in 
one classroom. to imagine getting to such a plan today, i'd have to take 
hard drugs.

> ...
> But unless you know where you're going, you won't get there.
> ...

right! and that's where we are. and, where we're going.

> ...
> I can pretty much guarantee you that if you re-build a plane, _without some
> overall plan as to what the result will be_, your plane will not work.
>
> 	Noel

Eppur si muove.

-- 
P Vixie



From lyndon at orthanc.ca  Wed Oct 25 19:41:19 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Wed, 25 Oct 2017 19:41:19 -0700
Subject: [ih] vm vs. memory
In-Reply-To: <59F14196.5090401@redbarn.org>
References: <20171025131348.396D318C0A9@mercury.lcs.mit.edu>
	<59F14196.5090401@redbarn.org>
Message-ID: <CBA2551F-7DED-4BCF-9A26-B71AB2179432@orthanc.ca>


> On Oct 25, 2017, at 6:59 PM, Paul Vixie <paul at redbarn.org> wrote:
> 
>> But unless you know where you're going, you won't get there.
>> ...
> 
> right! and that's where we are. and, where we're going.

But it's pretty well known that once your design/implementation team count > 5, you're done. 


From touch at strayalpha.com  Wed Oct 25 20:35:14 2017
From: touch at strayalpha.com (Joe Touch)
Date: Wed, 25 Oct 2017 20:35:14 -0700
Subject: [ih] vm vs. memory
In-Reply-To: <59EF2E16.1040906@redbarn.org>
References: <59EF2E16.1040906@redbarn.org>
Message-ID: <368931f1-6b8d-4118-a24a-2e117d6dd444@strayalpha.com>



On 10/24/2017 5:12 AM, Paul Vixie wrote:
> vm is an example of something that started as a workaround but 
> introduced us to a whole different way of thinking about memory. we now 
> have systems in production that always have physical RAM enough for 
> their work load, and who have no backing store for RAM (paging or 
> swapping) but which still depend on virtual memory for other reasons:
Agreed. The same could be said of NAT (created to save address space and
- IMHO - as a way for providers to enforce a pricing model that
differentiates service providers from clients).

Here's a summary of my interpretation of a useful view of NATs, i.e.,
that an "acid test" is that a NAT looks like a single host to the
external net and IMO ought to look like a router to the internal side:
J. Touch, ?Middlebox Models Compatible with the Internet
<http://www.isi.edu/touch/pubs/isi-tr-2016-711.pdf>,? USC/ISI Tech.
Report ISI-TR-711, Oct. 2016.

That's particularly useful when that's what you want (or need) to do,
e.g., to load balance the work of a single host on a bunch of internal
machines. It's painful when that's not what you want (or need) to do,
e.g., use a service someone incorrectly labels as "Internet access" but
is really "access to some content on the Internet".

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171025/741d7c94/attachment.htm>

From touch at strayalpha.com  Wed Oct 25 20:44:55 2017
From: touch at strayalpha.com (Joe Touch)
Date: Wed, 25 Oct 2017 20:44:55 -0700
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <59F13D7B.7030503@redbarn.org>
References: <59F13D7B.7030503@redbarn.org>
Message-ID: <0aa16c01-754f-66fc-42fb-52d771deef02@strayalpha.com>



On 10/25/2017 6:42 PM, Paul Vixie wrote:
> where we are today is that fragmentation is completely hosed. pmtud does 
> not work in practice, 
I do agree there are problems with fragmentation, but some layer of
fragmentation/reassembly is required when any layer below establishes a
"maximum" on message sizes, otherwise no amount of data origin guessing
will overcome a given level of layering and encapsulation.

Especially with PMTUD, but I thought that's why we've shifted to PLPMTUD.

IP fragmentation isn't working as intended, IMO because most routers
don't stay in their lanes - by forwarding only on IP header info.
Devices that peek into contents (DPI) necessarily need to reassemble
(even if as a shadow copy); claiming that "reassembly doesn't belong in
routers" while doing DPI is cherry-picking which parts of the router
requirements to follow and which to break.

(yes, I know PLPMTUD doesn't currently work with UDP, which is why I've
been working on extensions to UDP to support transport-layer fragmentation)

Joe


From AMaitland at Commerco.Com  Thu Oct 26 06:05:03 2017
From: AMaitland at Commerco.Com (Alan Maitland)
Date: Thu, 26 Oct 2017 07:05:03 -0600
Subject: [ih] Internet history - code and people (was Re: BBN C-series
 computers)
In-Reply-To: <CAHxHggdMOOgUqEx31fCf3_g9PBbqA0CE2x2Epj8ah1vn6PhZ2A@mail.gmail.com>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
	<CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>
	<CAHxHggfxRnDt_2x0eaR9s84w-o-51yrTb-dnnHM_ix4a_ZY4eA@mail.gmail.com>
	<bad47f35-6cc8-2e3f-aaf0-d85cb135dd0a@3kitty.org>
	<CAHxHggdMOOgUqEx31fCf3_g9PBbqA0CE2x2Epj8ah1vn6PhZ2A@mail.gmail.com>
Message-ID: <4e4aacdf-42ed-5637-d849-64cd2b34fb78@Commerco.Com>

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 <jack at 3kitty.org 
> <mailto:jack at 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 <vint at google.com
>     <mailto:vint at google.com>
>      > <mailto:vint at google.com <mailto:vint at 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
>     <jack at 3kitty.org <mailto:jack at 3kitty.org>
>      >? ? ?<mailto:jack at 3kitty.org <mailto:jack at 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 <pnr at planet.nl <mailto:pnr at planet.nl>
>     <mailto:pnr at planet.nl <mailto:pnr at planet.nl>>> wrote:
>      >? ? ? ? ?>
>      >? ? ? ? ?>>> On 24 Oct 2017, at 20:52, James J Dempsey
>     <jjd at jjd.com <mailto:jjd at jjd.com>
>      >? ? ? ? ?<mailto:jjd at jjd.com <mailto:jjd at 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-history at postel.org
>     <mailto:internet-history at postel.org>
>     <mailto:internet-history at postel.org
>     <mailto:internet-history at 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-owner at postel.org
>     <mailto:list-owner at postel.org> <mailto:list-owner at postel.org
>     <mailto:list-owner at postel.org>>
>      >? ? ? ? ?for assistance.
>      >? ? ? ? ?>
>      >? ? ? ? ?_______
>      >? ? ? ? ?internet-history mailing list
>      > internet-history at postel.org <mailto:internet-history at postel.org>
>     <mailto:internet-history at postel.org
>     <mailto:internet-history at 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-owner at postel.org
>     <mailto:list-owner at postel.org> <mailto:list-owner at postel.org
>     <mailto:list-owner at 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-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 



From jnc at mercury.lcs.mit.edu  Thu Oct 26 06:14:04 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 26 Oct 2017 09:14:04 -0400 (EDT)
Subject: [ih] vm vs. memory
Message-ID: <20171026131404.A9A2318C08B@mercury.lcs.mit.edu>

    > From: Paul Vixie

    > there _never was_ enough cohesion among all the people and companies
    > ... to get a meaningful plan. not even when the whole IETF fit in one
    > classroom. to imagine getting to such a plan today, i'd have to take
    > hard drugs.

You are, of course, quite correct.

I am left with considerable unease. You can't grow a large system without some
coherent plan for where you're going, what it will look like. But if that is
impossible...

Maybe the answer is some sort of guerilla deal; one person, or a small group,
which _does_ have such a plan, works 'under the radar' to make it happen.

I was kind of doing that at one point, until personal circumstances took me out
of the networking game...

	Noel


From wayne at playaholic.com  Thu Oct 26 07:06:21 2017
From: wayne at playaholic.com (Wayne Hathaway)
Date: Thu, 26 Oct 2017 10:06:21 -0400
Subject: [ih] vm vs. memory
In-Reply-To: <20171026131404.A9A2318C08B@mercury.lcs.mit.edu>
References: <20171026131404.A9A2318C08B@mercury.lcs.mit.edu>
Message-ID: <201710261406.v9QE6LFg018864@mail54c28.carrierzone.com>

This makes me think of "The Cathedral and the Bazaar" by Eric Raymond.  The Internet is
definitely the bazaar side of things, that's for sure!

Wayne Hathaway
wayne at playaholic.com

 

On Thu, 26 Oct 2017 09:14:04 -0400 (EDT), jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:

>> > From: Paul Vixie
>> 
>>     > there _never was_ enough cohesion among all the people and companies
>>     > ... to get a meaningful plan. not even when the whole IETF fit in one
>>     > classroom. to imagine getting to such a plan today, i'd have to take
>>     > hard drugs.
>> 
>> You are, of course, quite correct.
>> 
>> I am left with considerable unease. You can't grow a large system without some
>> coherent plan for where you're going, what it will look like. But if that is
>> impossible...
>> 
>> Maybe the answer is some sort of guerilla deal; one person, or a small group,
>> which _does_ have such a plan, works 'under the radar' to make it happen.
>> 
>> I was kind of doing that at one point, until personal circumstances took me out
>> of the networking game...
>> 
>> 	Noel
>> _______
>> internet-history mailing list
>> internet-history at postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-owner at postel.org for assistance.



From brian.e.carpenter at gmail.com  Thu Oct 26 12:23:07 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Fri, 27 Oct 2017 08:23:07 +1300
Subject: [ih] vm vs. memory
In-Reply-To: <CAEoi9W78rebftgAV-gvBi-GTmzQT3O2zBnLoocaU1WRRok5KKA@mail.gmail.com>
References: <59EF2E16.1040906@redbarn.org>
	<593e3d78-5af7-e30b-a1ae-ad875ddee643@gmail.com>
	<CAEoi9W78rebftgAV-gvBi-GTmzQT3O2zBnLoocaU1WRRok5KKA@mail.gmail.com>
Message-ID: <cacf3566-8b14-ee80-2966-8ac0ad75f8e1@gmail.com>

OK, one more piece of *computing* archaeology, and then we can
get back to the Internet.

On 25/10/2017 13:38, Dan Cross wrote:
> On Tue, Oct 24, 2017 at 3:42 PM, Brian E Carpenter
> <brian.e.carpenter at gmail.com> wrote:
>> On 25/10/2017 01:12, Paul Vixie wrote:
>>> Joe Touch wrote:
>>> ...
>>>> IMO, they?re no more a stop-gap to networking than VM is to memory.
>>>>
>>>> But we?re digressing from the original thread...
>>>
>>> that's hard to say, but i've forked the thread anyway.
>>>
>>> vm is an example of something that started as a workaround but
>>
>> I disagree with that evaluation. It started in practice with the
>> famous "one-level storage system" paper from Manchester**, with the
>> specific goal of making a small high-speed memory look like a much
>> larger one. I don't think it was viewed as a work-around, but rather
>> as a brilliant engineering solution to the high cost of high-speed
>> memory, vastly easier to use than explicit overlays.
>>
>> **One-Level Storage System, T. Kilburn, D. B. G. Edwards, M. J. Lanigan, F. H. Sumner, IRE Trans. Electronic Computers EC11(2), April 1962, 223-235.
>>
>> Full disclosure: I am biased. Frank Sumner was my M.Sc. supervisor.
> 
> The VM system in Atlas was, apparently, controversial. Rob Pike said
> that the decision to put VM (in Paul's sense) into Plan 9 resulted in
> raising his boss's ire, due to a bad experience with Atlas:
> https://marc.info/?l=9fans&m=111558822910429&w=2

Indeed, the thrashing problem is why Peter Denning's insights were so
important. Not that I remember thrashing being a real problem for Atlas
users by 1968 when I was in Manchester. The real problem was when the
operators accidentally tore your paper tape.

There's a rather confusing Sandy Fraser oral history transcript at
https://www.princeton.edu/~hos/mike/transcripts/fraser.htm
but although he mentions an Atlas file system, he doesn't mention
VM issues. There's a more coherent explanation in David Hartley's
article at http://www.cs.man.ac.uk/CCS/res/res44.htm, in which it's
clear that Fraser did this work on the Cambridge Titan, which was
a stripped-down Atlas with incomplete VM: "The Titan operating system
was necessarily different from the Atlas 1 supervisor which was built
around the hardware one-level store that we didn?t have. The Atlas 1
system programmers could just scatter programs and data all over memory
and let the one-level store do the memory management; whereas on Titan,
to keep the machine busy, we had to be very careful how we buffered data."

In other words, Fraser's bias against VM was based on experience with
something that wasn't VM. Duh!

   Brian




From touch at strayalpha.com  Thu Oct 26 13:30:08 2017
From: touch at strayalpha.com (Joe Touch)
Date: Thu, 26 Oct 2017 13:30:08 -0700
Subject: [ih] vm vs. memory
In-Reply-To: <cacf3566-8b14-ee80-2966-8ac0ad75f8e1@gmail.com>
References: <59EF2E16.1040906@redbarn.org>
	<593e3d78-5af7-e30b-a1ae-ad875ddee643@gmail.com>
	<CAEoi9W78rebftgAV-gvBi-GTmzQT3O2zBnLoocaU1WRRok5KKA@mail.gmail.com>
	<cacf3566-8b14-ee80-2966-8ac0ad75f8e1@gmail.com>
Message-ID: <DEADD9E5-0A6F-4B5F-8D9D-C497067DF12D@strayalpha.com>



> On Oct 26, 2017, at 12:23 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
> 
> OK, one more piece of *computing* archaeology, and then we can
> get back to the Internet.

You can also move this discussion to computer-history at postel.org

Joe (who manages both lists)



From dhc2 at dcrocker.net  Thu Oct 26 14:35:04 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu, 26 Oct 2017 14:35:04 -0700
Subject: [ih] Internet history - code and people (was Re: BBN C-series
 computers)
In-Reply-To: <01457bbc-8c58-c0a7-75ee-cd2279a6364d@gmail.com>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
	<CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>
	<CAHxHggfxRnDt_2x0eaR9s84w-o-51yrTb-dnnHM_ix4a_ZY4eA@mail.gmail.com>
	<bad47f35-6cc8-2e3f-aaf0-d85cb135dd0a@3kitty.org>
	<CAHxHggdMOOgUqEx31fCf3_g9PBbqA0CE2x2Epj8ah1vn6PhZ2A@mail.gmail.com>
	<01457bbc-8c58-c0a7-75ee-cd2279a6364d@gmail.com>
Message-ID: <28df6879-dda2-916f-13cd-c58fd8b5b2f6@dcrocker.net>

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


From dhc2 at dcrocker.net  Thu Oct 26 14:43:17 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu, 26 Oct 2017 14:43:17 -0700
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <59F13D7B.7030503@redbarn.org>
References: <59F13D7B.7030503@redbarn.org>
Message-ID: <2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>

On 10/25/2017 6:42 PM, Paul Vixie wrote:
> ony li said that ipv6 was too little, too soon. this was a play on
> words, because the usual complaint is "too little, too late". tony was
> right, even moreso than i realized at the time. we specified a lot of
> things that didn't work and had to be revised or thrown out -- because
> we did not know what we needed and we thought we were in a hurry.


What you've actually summarized falls under 'too /much/ too soon'.  The 
'too much' part matches what I believe I saw.

However rather than 'too soon', one of the problems with the effort was 
that in fact people made a point of not being sufficiently in a hurry. 
This included explicit IETF presentations -- complete with charts -- 
purporting to prove that we had a decade (or whatever) before we 
actually had to make the change.

So the actual practice of the effort is, IMO, better summarized as 'too 
much too late' (and with no serious attention to adoption incentives or 
adoption effort.

The original mandate was for more address space.  All the other 
'features' that were attempted went beyond that mandate.

This was mere scope creep.  Whether because of second system syndrome or 
a failure to sufficiently feel the urgency of getting something fielded 
and working sooner rather than later, I don't know.  But I suspect it 
was both.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From paul at redbarn.org  Thu Oct 26 15:26:44 2017
From: paul at redbarn.org (Paul Vixie)
Date: Fri, 27 Oct 2017 00:26:44 +0200
Subject: [ih] Internet history - code and people (was Re: BBN C-series
 computers)
In-Reply-To: <28df6879-dda2-916f-13cd-c58fd8b5b2f6@dcrocker.net>
References: <97A59C16-3E99-4DC9-9755-736FC29F48D1@planet.nl>
	<18841.1508945263@serenity.jjd.com>
	<6df72a6d-e90e-1dde-ad88-6c131a5508d5@3kitty.org>
	<CAHxHggf+0b7jN2mErcDQs9fXsBFJka50dq9c8DixMnTQ-aZ0Qw@mail.gmail.com>
	<CAHxHggfxRnDt_2x0eaR9s84w-o-51yrTb-dnnHM_ix4a_ZY4eA@mail.gmail.com>
	<bad47f35-6cc8-2e3f-aaf0-d85cb135dd0a@3kitty.org>
	<CAHxHggdMOOgUqEx31fCf3_g9PBbqA0CE2x2Epj8ah1vn6PhZ2A@mail.gmail.com>
	<01457bbc-8c58-c0a7-75ee-cd2279a6364d@gmail.com>
	<28df6879-dda2-916f-13cd-c58fd8b5b2f6@dcrocker.net>
Message-ID: <59F26124.2050105@redbarn.org>



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



From paul at redbarn.org  Thu Oct 26 15:36:35 2017
From: paul at redbarn.org (Paul Vixie)
Date: Fri, 27 Oct 2017 00:36:35 +0200
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
Message-ID: <59F26373.4070502@redbarn.org>



Dave Crocker wrote:
> ...
>
> The original mandate was for more address space. All the other
> 'features' that were attempted went beyond that mandate.
>
> ...

that word, "mandate," i don't think it means what you think it means.

we were volunteers, who worked on what we found deserving of our time. 
or we were employees, who worked on what our bosses said to work on. at 
no time did we or our families or our employers sign a suicide pact 
agreeing to spend the next 16 years of our lives working on a system 
whose utility could only be judged in the future, but which looked 
pretty awful in the moment.

if the fragmentation differences between v4 and v6 were as you say a 
form of scope creep, then i call foul, not on those engineers, but on 
the paper pushing bureaucrats who killed TCPv6, which would have given 
us renumberable connection endpoints. that is, if one was allowed, the 
other should also have been.

i was pushing for a simple expansion of the IP header so that we could 
use source routing on all flows, to connect network 10 at each end, 
through a series of tubes, really, that had unique IP addresses, so that 
the path would become the identity. the dns portion of this design 
looked a lot like what was later called 8+8. i was shouted down, as was 
mike o'dell, so i harken to your suspicion that anything simple would've 
been rejected.

-- 
P Vixie



From craig at tereschau.net  Thu Oct 26 15:12:58 2017
From: craig at tereschau.net (Craig Partridge)
Date: Thu, 26 Oct 2017 18:12:58 -0400
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
Message-ID: <CAHQj4CdxycJ+tsOZYcBE8CwQWNe+WxiOSiBi5d_dv5cUjUgEWg@mail.gmail.com>

On Thu, Oct 26, 2017 at 5:43 PM, Dave Crocker <dhc2 at dcrocker.net> wrote:

> On 10/25/2017 6:42 PM, Paul Vixie wrote:
> > ony li said that ipv6 was too little, too soon. this was a play on
> > words, because the usual complaint is "too little, too late". tony was
> > right, even moreso than i realized at the time. we specified a lot of
> > things that didn't work and had to be revised or thrown out -- because
> > we did not know what we needed and we thought we were in a hurry.
>
> ...
>
> This was mere scope creep.  Whether because of second system syndrome or
> a failure to sufficiently feel the urgency of getting something fielded
> and working sooner rather than later, I don't know.  But I suspect it
> was both.
>

As one of the authors of the IPng Requirements (RFC 1726), I'm going to risk
piping up here.  The requirements in RFC 1726 were for an IPv4 replacement
that scaled -- if you read RFC 1726 (and I just went back and did) it is
carefully
only requiring what we'd already achieved in IPv4 -- with the exception of
saying
we'd like something that configured better than DHCP.

So Tony's closer to right.  We were so scared when we wrote that document
that
we only had a few years that we wrote remarkably conservative requirements.
(I'd actually pushed to be more ambitious and got shot down).

Craig
-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.
For Raytheon business, please email: craig. <craig at bbn.com>
partridge at raytheon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20171026/0dde7161/attachment.htm>

From sob at sobco.com  Thu Oct 26 16:59:08 2017
From: sob at sobco.com (Scott O. Bradner)
Date: Thu, 26 Oct 2017 19:59:08 -0400
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
Message-ID: <1ECB8303-D9A3-44D7-81D7-C72C9E09A7AB@sobco.com>


> On Oct 26, 2017, at 5:43 PM, Dave Crocker <dhc2 at dcrocker.net> wrote:
?

> The original mandate was for more address space.  All the other 
> 'features' that were attempted went beyond that mandate.

the mission, as given, was stated in RFC 1719 section 3
> 
> This was mere scope creep.  Whether because of second system syndrome or 
> a failure to sufficiently feel the urgency of getting something fielded 
> and working sooner rather than later, I don't know.  But I suspect it 
> was both.

fwiw - it was a community decision on mission (creep) - see RFC 1726 (the 
criteria document called for in RFC 1719)

Scott


From brian.e.carpenter at gmail.com  Thu Oct 26 17:10:49 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Fri, 27 Oct 2017 13:10:49 +1300
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <59F26373.4070502@redbarn.org>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
	<59F26373.4070502@redbarn.org>
Message-ID: <e45154de-6763-019a-254d-ec6b624e7d06@gmail.com>

On 27/10/2017 11:36, Paul Vixie wrote:
> 
> 
> Dave Crocker wrote:
>> ...
>>
>> The original mandate was for more address space. All the other
>> 'features' that were attempted went beyond that mandate.
>>
>> ...
> 
> that word, "mandate," i don't think it means what you think it means.
> 
> we were volunteers, who worked on what we found deserving of our time. 
> or we were employees, who worked on what our bosses said to work on. at 
> no time did we or our families or our employers sign a suicide pact 
> agreeing to spend the next 16 years of our lives working on a system 
> whose utility could only be judged in the future, but which looked 
> pretty awful in the moment.
> 
> if the fragmentation differences between v4 and v6 were as you say a 
> form of scope creep, then i call foul, not on those engineers, but on 
> the paper pushing bureaucrats who killed TCPv6, which would have given 
> us renumberable connection endpoints. that is, if one was allowed, the 
> other should also have been.
> 
> i was pushing for a simple expansion of the IP header so that we could 
> use source routing on all flows, to connect network 10 at each end, 
> through a series of tubes, really, that had unique IP addresses, so that 
> the path would become the identity. the dns portion of this design 
> looked a lot like what was later called 8+8. i was shouted down, as was 
> mike o'dell, so i harken to your suspicion that anything simple would've 
> been rejected.

Did you take it as far as a BOF?

https://www.cs.auckland.ac.nz/~brian/draft-carpenter-aeiou-00.txt
went to a BOF but was politely stomped on (IETF 29, Seattle).

    Brian



From paul at redbarn.org  Thu Oct 26 17:28:06 2017
From: paul at redbarn.org (Paul Vixie)
Date: Fri, 27 Oct 2017 02:28:06 +0200
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <e45154de-6763-019a-254d-ec6b624e7d06@gmail.com>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
	<59F26373.4070502@redbarn.org>
	<e45154de-6763-019a-254d-ec6b624e7d06@gmail.com>
Message-ID: <59F27D96.7060305@redbarn.org>



Brian E Carpenter wrote:
> On 27/10/2017 11:36, Paul Vixie wrote:
>> i was pushing for a simple expansion of the IP header so that we could
>> use source routing on all flows, to connect network 10 at each end,
>> through a series of tubes, really, that had unique IP addresses, so that
>> the path would become the identity. the dns portion of this design
>> looked a lot like what was later called 8+8. i was shouted down, as was
>> mike o'dell, so i harken to your suspicion that anything simple would've
>> been rejected.
>
> Did you take it as far as a BOF?

no. at that time i hadn't attended any IETF meetings and i didn't know 
anybody who did, except my colleagues at DECWRL.

> https://www.cs.auckland.ac.nz/~brian/draft-carpenter-aeiou-00.txt
> went to a BOF but was politely stomped on (IETF 29, Seattle).

your design was better considered than mine, and in my opinion would 
have worked sooner and better than we're seeing from IPv6. you should 
not have patterned it as a stopgap, that's probably what doomed it.

-- 
P Vixie



From dhc2 at dcrocker.net  Thu Oct 26 18:05:22 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu, 26 Oct 2017 18:05:22 -0700
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <59F26373.4070502@redbarn.org>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
	<59F26373.4070502@redbarn.org>
Message-ID: <a9519b1e-c1f4-2884-c312-1826ba98bc0d@dcrocker.net>

So, I see that I've touched a nerve.  I'd expected to touch one, but not 
this one.  I'll try to respond carefully; please be gentle, as I fail...


On 10/26/2017 3:36 PM, Paul Vixie wrote:> Dave Crocker wrote:
>> The original mandate was for more address space. All the other
>> 'features' that were attempted went beyond that mandate.
> 
> that word, "mandate," i don't think it means what you think it means.

Of course I do, and it's purely luck that Craig made the point for me: 
cf, RFC 1726.  That was not produced quickly nor in isolation nor by 
only a tiny collection of wayward folk.  It creates a mandate to work on 
a particular problem to a particular goal.

My point is that this was expanded over time.

In effect, the goal became "let's reinvent IP was lots of ambitious 
features" and that's a story template that never ends well.  Or, in this 
case, possible at all.

(I haven't re-read it from when it was developed by my recollection is 
that even it was more ambitious than was needed, but that's just my 
rogue opinion.)

While I realize that fragmentation was your starting point, my comments 
were not meant to be about that one way or the other.

(However I'd had the impression that even IPv4 fragmentation is 
problematic these days, so am surprised it's an issue for v6; but really 
my comments were meant as broadly as the language indicates and not at 
all about a particular like this.)


> we were volunteers, who worked on what we found deserving of our time.

(We can deal with the deceptive IETF myth of 'volunteer' some other time.)

The essence is that, yes, a 'strongly dominant' set of those working on 
IPv6 chose to expand the scope beyond the original intent of the effort, 
namely to simply expand the address space.  My claim then and now is 
that that greatly facilitated the problematic history that ensued.


> if the fragmentation differences between v4 and v6 were as you say a
> form of scope creep, 

but I didn't say that and I apologize for, apparently, not being clear 
that my comments were not at all meant about fragmentation per se. 
Simplistically, since v4 has fragmentation and had a really good reason 
for needing it, I'd expect v6 to have it, absent a really good reason 
not to.


> i was pushing for a simple expansion of the IP header so that we could
> use source routing on all flows, to connect network 10 at each end,
> through a series of tubes, really, that had unique IP addresses, so that

That's an amusing specific, for me.  There was a meeting with Vint and 
others discussing the challenge of testing IPv6, given that there was no 
test lab large enough to make for an interesting case, and I suggested 
tunnelling IP(v6)/IP(v4) to connect an aggregation of test labs.  Vint 
did not initially like the idea though I gather this changed over time.


> the path would become the identity. the dns portion of this design
> looked a lot like what was later called 8+8. i was shouted down, as was
> mike o'dell, so i harken to your suspicion that anything simple would've
> been rejected.

cf my earlier posting that proposed taking alternative numbering scheme 
out of the critical path for adoption.

At the time the topic of numbering had quite a lot of theory and 
research proposals -- often with a great deal of personal fervor, but 
without much detail to back them up or appreciation that they were 
theory, not practice.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From paul at redbarn.org  Fri Oct 27 05:08:24 2017
From: paul at redbarn.org (Paul Vixie)
Date: Fri, 27 Oct 2017 14:08:24 +0200
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <a9519b1e-c1f4-2884-c312-1826ba98bc0d@dcrocker.net>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
	<59F26373.4070502@redbarn.org>
	<a9519b1e-c1f4-2884-c312-1826ba98bc0d@dcrocker.net>
Message-ID: <59F321B8.8040702@redbarn.org>



Dave Crocker wrote:
> On 10/26/2017 3:36 PM, Paul Vixie wrote:> Dave Crocker wrote:
>>> The original mandate was for more address space. All the other
>>> 'features' that were attempted went beyond that mandate.
>>
>> that word, "mandate," i don't think it means what you think it means.
>
> Of course I do, and it's purely luck that Craig made the point for me:
> cf, RFC 1726. That was not produced quickly nor in isolation nor by only
> a tiny collection of wayward folk. It creates a mandate to work on a
> particular problem to a particular goal.

ok, thanks for explaining. this is like the mandate every winner of 
every political race claims, for the policies that got them elected. 
like "the reagan mandate" of 1980, an election in which fewer than half 
of eligible voters actually voted. that is to say, a fake news mandate.

had the ietf actually adhered to the limits of RFC 1726, we would not 
have a radically different fragmentation model in ipv6 compared to ipv4. 
so i think we can tell that not only the actual "internet engineers" of 
the world, but also their chosen vehicle, were in no way constrained by 
the thing you are calling a "mandate".

> My point is that this was expanded over time.

my point is that such expansion was inevitable and should have been 
expected and the people who ratified the mandate ought to have known better.

-- 
P Vixie



From dhc2 at dcrocker.net  Fri Oct 27 08:47:40 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Fri, 27 Oct 2017 08:47:40 -0700
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <59F321B8.8040702@redbarn.org>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
	<59F26373.4070502@redbarn.org>
	<a9519b1e-c1f4-2884-c312-1826ba98bc0d@dcrocker.net>
	<59F321B8.8040702@redbarn.org>
Message-ID: <891886f0-c120-70aa-2db3-5e92099b2bc1@dcrocker.net>

On 10/27/2017 5:08 AM, Paul Vixie wrote:
> 
> 
> Dave Crocker wrote:
>> On 10/26/2017 3:36 PM, Paul Vixie wrote:> Dave Crocker wrote:
>>>> The original mandate was for more address space. All the other
>>>> 'features' that were attempted went beyond that mandate.
>>>
>>> that word, "mandate," i don't think it means what you think it means.
>>
>> Of course I do, and it's purely luck that Craig made the point for me:
>> cf, RFC 1726. That was not produced quickly nor in isolation nor by only
>> a tiny collection of wayward folk. It creates a mandate to work on a
>> particular problem to a particular goal.
> 
> ok, thanks for explaining. this is like the mandate every winner of
> every political race claims,

It is nothing like that at all.  It is like the word "requirement" in a 
formal document meaning 'to require' and delegating the task of 
satisfying the requirement(s) to some folk with what is sometimes called 
a mandate.


> had the ietf actually adhered to the limits of RFC 1726, we would not
> have a radically different fragmentation model in ipv6 compared to ipv4.

On this point of actual technical substance, we agree.


> so i think we can tell that not only the actual "internet engineers" of
> the world, but also their chosen vehicle, were in no way constrained by
> the thing you are calling a "mandate".

Field teams often go astray of their mandate.  That doesn't make the 
mandate not a mandate.


>> My point is that this was expanded over time.
> 
> my point is that such expansion was inevitable and should have been
> expected and the people who ratified the mandate ought to have known better.

"Inevitable" is such a dangerous word.  In this case, you've made a leap 
to its use that skips over so many complex human and social issues, it 
looks more like a statement of religion than engineering.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From paul at redbarn.org  Fri Oct 27 08:58:00 2017
From: paul at redbarn.org (Paul Vixie)
Date: Fri, 27 Oct 2017 17:58:00 +0200
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <891886f0-c120-70aa-2db3-5e92099b2bc1@dcrocker.net>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
	<59F26373.4070502@redbarn.org>
	<a9519b1e-c1f4-2884-c312-1826ba98bc0d@dcrocker.net>
	<59F321B8.8040702@redbarn.org>
	<891886f0-c120-70aa-2db3-5e92099b2bc1@dcrocker.net>
Message-ID: <59F35788.1070804@redbarn.org>



Dave Crocker wrote:
> On 10/27/2017 5:08 AM, Paul Vixie wrote:
>> so i think we can tell that not only the actual "internet engineers" of
>> the world, but also their chosen vehicle, were in no way constrained by
>> the thing you are calling a "mandate".
>
> Field teams often go astray of their mandate. That doesn't make the
> mandate not a mandate.

it was never a mandate on the people who weren't part of the discussions 
of RFC 1726 or whose interests weren't aligned. so the answer to "when 
is something not a mandate?" would include this.

>>> My point is that this was expanded over time.
>>
>> my point is that such expansion was inevitable and should have been
>> expected and the people who ratified the mandate ought to have known
>> better.
>
> "Inevitable" is such a dangerous word. In this case, you've made a leap
> to its use that skips over so many complex human and social issues, it
> looks more like a statement of religion than engineering.

i appreciate your candor, sir. a single counterexample from history 
could mollify me. my own survey showed that whenever an equivalent 
opportunity, motive and means were present, the result might as well 
have been preordained.

-- 
P Vixie



From jnc at mercury.lcs.mit.edu  Fri Oct 27 09:15:15 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 27 Oct 2017 12:15:15 -0400 (EDT)
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
	vm vs. memory])
Message-ID: <20171027161515.85AB118C099@mercury.lcs.mit.edu>

    > From: Dave Crocker

    > The original mandate was for more address space.  All the other
    > 'features' that were attempted went beyond that mandate.
    > This was mere scope creep. Whether because of second system syndrome or
    > a failure to sufficiently feel the urgency of getting something fielded
    > and working sooner rather than later, I don't know.

How ironic. I felt at the time (and said so, vociferously, to the entire
community) that IPv6 was way too small/simple a change.

My reasoning was two-fold:

- If you wanted to get it deployed, it had to have major new capabilities as
incentives. With simply "more addresses", it was totally clear that IPv4+NAT
gave most of that, at an incredibly lower cost.

- If you're going to do an upgrade to a massive, world-wide system, that
upgrade ought to do as much as possible, because one doesn't often get a
chance to do something like that.

Oh well.

   Noel



From dhc2 at dcrocker.net  Fri Oct 27 11:04:25 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Fri, 27 Oct 2017 11:04:25 -0700
Subject: [ih] fragmentation (Re: Could it have been different? [was Re:
 vm vs. memory])
In-Reply-To: <59F35788.1070804@redbarn.org>
References: <59F13D7B.7030503@redbarn.org>
	<2e129525-1cda-e33f-f84a-5d17400ca852@dcrocker.net>
	<59F26373.4070502@redbarn.org>
	<a9519b1e-c1f4-2884-c312-1826ba98bc0d@dcrocker.net>
	<59F321B8.8040702@redbarn.org>
	<891886f0-c120-70aa-2db3-5e92099b2bc1@dcrocker.net>
	<59F35788.1070804@redbarn.org>
Message-ID: <21c1eccb-da24-68b8-758c-de9aede0c62f@dcrocker.net>

On 10/27/2017 8:58 AM, Paul Vixie wrote:
> Dave Crocker wrote:
>> On 10/27/2017 5:08 AM, Paul Vixie wrote:
>>> so i think we can tell that not only the actual "internet engineers" of
>>> the world, but also their chosen vehicle, were in no way constrained by
>>> the thing you are calling a "mandate".
>>
>> Field teams often go astray of their mandate. That doesn't make the
>> mandate not a mandate.
> 
> it was never a mandate on the people who weren't part of the discussions
> of RFC 1726 or whose interests weren't aligned. so the answer to "when
> is something not a mandate?" would include this.

Well, /that/ observation is a touchstone to rather more-interesting 
questions about standards efforts, credibility and efficacy.


>>>> My point is that this was expanded over time.
>>>
>>> my point is that such expansion was inevitable and should have been
>>> expected and the people who ratified the mandate ought to have known
>>> better.
>>
>> "Inevitable" is such a dangerous word. In this case, you've made a leap
>> to its use that skips over so many complex human and social issues, it
>> looks more like a statement of religion than engineering.
> 
> i appreciate your candor, sir. a single counterexample from history
> could mollify me. my own survey showed that whenever an equivalent
> opportunity, motive and means were present, the result might as well
> have been preordained.

We have lots of examples of efforts that retained control over scope, 
did work in a timely fashion, and produced work that was useful in the 
way originally intended.  Consider the successful upgrade efforts, such 
as the sequence of changes to IPv4 address schemes, BGP, SNMP, MIME, 
SMTP extensions...

We do, of course, also have lots of examples that fail on one or more of 
these points.

There do seem to be some factors that contribute to failure or 
contribute to success, but I don't recall seeing them documented and 
justified.  Thaler's RFC 5218 is relevant here, but more for background 
than actual prescription.

My model has been that a combination of participation by those who must 
actually deliver the work to the marketplace -- so, development and ops 
and even business/marketing -- with a very strong dose of urgency, tend 
to produce more pragmatic and timely results.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net