Re: "the net"... campus-type links, and conceptualizing remote data

[David Farber <dave () farber net>]

Begin forwarded message:

From: Richard Bennett <richard () bennett com>
Date: September 14, 2009 6:09:31 PM EDT
To: Gordon Peterson <gep2 () terabites com>
Cc: "David P. Reed" <dpreed () reed com>, Dan Lynch <dan () lynch com>, Dave  
Crocker <dcrocker () bbiw net>, Dave Farber <dave () farber net>, ip <ip () v2 listbox com 
>, John Shoch <shoch () alloyventures com>, Harold Burstyn <burstynh () iname com 
>, Lauren Weinstein <lauren () vortex com>, Paul Robichaux <paul () robichaux net 
>, Steve Crocker <steve () shinkuro com>
Subject: Re: [IP] "the net"... campus-type links, and conceptualizing  
remote data

Speaking of infrared datalinks, it's maybe interesting to note that  
one of the first (if not The First) wireless LANs used an IR physical  
layer. This was the Photolink system by a company in Los Gatos named  
"Photonics" circa 1999 or so. Photolink was a cable replacement for  
Appletalk. Since Appletalk was a pretty robust system, Photonics   
didn't think it needed a MAC protocol of its own, but they were  
quickly disabused of the notion. Photolink II replaced directional IR  
with pervasive IR and added a MAC protocol that was one of the major  
inputs into the IEEE 802.11 process. Check the .11 stds and you'll see  
that the initial one specified both an RF PHY and an IR PHY. The lack  
of security reflects the IR heritage: if you wanted a private IR LAN,  
you closed your door.

The Photonics products were created in the era when people were afraid  
that cell phones caused brain cancer; they figured schools would  
prefer IR because it was safer than RF. The company folded after RF  
WLANs took off, but the MAC protocol lives on.

RB

Gordon Peterson wrote:
> While we're talking about interesting early networks and such, maybe  
> this is a good time to mention Datapoint's alternative to microwave- 
> type cross-campus links.  Although we had been running our own ARC  
> System LANs for a while already, we had two young men who drove a  
> white minivan back and forth up and down the hill carrying disk  
> cartridges between our various corporate offices at the top of the  
> hill along Datapoint Drive (in San Antonio) and the manufacturing  
> plant at the bottom of the hill, less than a mile away.
>
> For a time, the ham radio guys that had been among the early tech/ 
> R&D guys in the company (and here I'm referring to Vic Poor,  
> Jonathan Schmidt, Harry Pyle and David Monroe) were intrigued by  
> cheap, small, sub-$100 microwave transmitters, but quickly became  
> discouraged in that technology because of the required FCC site  
> surveys, licenses and other restrictions that could easily jump the  
> total cost of an installed, working link to a quarter of a million  
> dollars or more, and months to years of administrative delays before  
> going into production use.
>
> Previously, Harry had used a Datapoint 2200 to send RF Morse code  
> across the ham radio Morse code channels at very high rates...  
> thousands or tens of thousands of words per minute, which had gotten  
> the attention of the FCC (Harry pointed out to them that the  
> applicable regulations didn't specify any maximum speed at all for  
> the transmission of Morse code.  :-) )
>
> It seemed frustrating that we could easily SEE the building we  
> wanted to transmit our data to.  Instead of using microwave (which  
> was frought with regulations and license red tape), it seemed like  
> we could almost just send semaphore or Morse code signals with a  
> flashlight...!  The concept developed into a product that Datapoint  
> called LightLink, a system which used simple infrared LEDs and large  
> fresnel lenses to send two parallel beams of infrared light, each  
> about a foot in diameter, between the two endpoints.
>
> The large-diameter beam (as compared to a simple thin laser beam)  
> made the system largely immune to disruptions such as falling  
> raindrops, a bird flying through the beam, or whatnot.  (We used to  
> joke about the "giant pterodactyl" problem, a huge bird with a  
> wingspan area large enough to block the entire beam!  ;-) )   
> Instantaneous disruptions, if any were handled by either ARCnet's or  
> The ARC System's packet and error recovery mechnisms.  In the event  
> of more extended problems (if the fog was so thick that you couldn't  
> visually see the building at all at the other end, the link would  
> generally go down) the ARCnets at either end of the link would  
> reconfigure themselves automatically as two independent networks,  
> which would also automatically (under ARCnet protocols) recombine as  
> one when the link became good again.  Our experience was that there  
> was typically just a few hours a year that weather conditions were  
> so bad that connectivity was interrupted.
>
> The LightLink system (unlike ChaosNet, apparently) was completely  
> protocol-neutral, running at the full 2.5 megabits, and plugged into  
> an existing ARCnet LAN just as if it were a piece of ordinary coax.   
> The system was very high speed (for the time), easy to set up, had  
> essentially no latency, was spec'd to run up to about a mile per  
> LightLink, was comparatively inexpensive (and involving no recurring  
> monthly bandwidth expense), and required no FCC licensing or site  
> surveys at all.
>
> The LightLink system was used widely through the NY financial  
> district (for example between the Federal Reserve and Chase  
> Manhattan), across freeways, across campuses, and so forth.  We at  
> Datapoint used LightLink to connect about half a dozen of our  
> different office buildings and manufacturing facility along and near  
> Datapoint Drive.
>
>
> On a separate note, I think it's also interesting that when  
> Datapoint started work on what became ARCnet they also only had a  
> vague notion of what they wanted this fast, easy-to-set up packet  
> network to look like at the user level... this same kind of familiar- 
> from-ARPAnet "Telnet/FTP" type thing perhaps, as well as sharing  
> printers somehow.  Previously, communications between small  
> computers had been typified by what I call the "Decnet-style"  
> networking, where one had special applications interfaces to open  
> remote files and transfer data, generally requiring specifying for  
> each file opened what machine the file was on, which disk volume it  
> was on, and a user name and password for that file. This always  
> struck me as clumsy, and prevented existing applications from  
> transparently accessing files on remote machines as easily as they  
> could for local files.
>
> Therefore, one of my major innovations (in 1976) for The ARC System  
> was to allow the user to establish their connections to shared  
> remote data outside of their applications, simply establishing  
> mappings to various remote collections of data as "mounting a  
> network volume" into imaginary local disk drives.  This allowed  
> specifying volume names, user names, passwords and such ahead of  
> time, and then having them all just look like a collection of  
> virtual local disk drives, regardless of which disk, server (or even  
> which LAN, since we allowed any given applications or server  
> processor to connect to up to six separate ARCnet LANs at once) the  
> files were actually on.  Existing applications didn't know or need  
> to care that the files were even hosted remotely, let alone WHERE  
> they were (currently) hosted.
>
> The "Map Network Volume" concept endures and is heavily used to this  
> day on most successful applications-oriented networks.  FTP is still  
> around, although I still feel that mapping that FTP server  
> transparently to a virtual disk volume is a better model (and I  
> generally use software that provides that service, rather than using  
> the still-clumsy FTP model).  And Telnet is still used (besides  
> SMTP!), although again I believe that it usually makes more sense to  
> simply map the data resources into your own machine's environment  
> and then use your own (usually more comprehensive) tools on your own  
> system to manipulate it.
>
> David P. Reed wrote:
> > Regarding my having my facts straight:
> >
> > I just walked over to the shelf to the left of my computer, picked  
> > up my available paper copy of the ARPANET PROTOCOL HANDBOOK, NIC  
> > 7104, REV. January 1978.  On page 41, there is a document numbered  
> > NIC 29628 (Dec. 13, 1977).  It is entitled "Transmission Control  
> > Protocol (TCP)", and it was written by Jon Postel.  The relevant  
> > fact-based paragraph (paragraph 2) is as follows (my italics for  
> > emphasis):
> >
> > "TCP /is being used/ in the ARPA-sponsored work on packet switched  
> > radio communication (PRNET) and packet switched satellite  
> > communication (SATNET), and interconnections of these experimental  
> > facilities with each other and the ARPANET.  TCP implementations / 
> > exist/ for PDP10 TENEX systems and PDP-11 systems, and TCP  
> > implementations are under development for TOPS20, Multics, the  
> > Norwegian NORD-10 system, and UCLA-CCN's IBM-360/91. Some hosts in  
> > the MIT LCSNET will intercommunicate with hosts in the ARPANET  
> > using TCP."
> >
> > Now I am very familiar with this, because I was pretty much the  
> > core software and design staff of "MIT LCSNET" at the time.   As  
> > Dave Farber knows, we were working (in collaboration with him) on a  
> > version of the token ring idea as an alternative to the "bus"-style  
> > coaxial Ethernet.   And all of this stuff was up and running in  
> > prototype form, and was interconnected with the ARPANET by gateways  
> > that did NOT translate to NCP, but instead overlaid NCP by using  
> > point-to-point nailed up virtual circuits.   We also shortly  
> > thereafter had in 545 Tech Square and over dedicated microwave  
> > links across campus (thanks to Tom Knight and buddies) what was  
> > called "the ChaosNet" which again served as a layer 2 for TCP  
> > transport.  Chaosnet was a bus network somewhat like Ethernet.    
> > Chaosnet carried its own private layer 2 protocol, and also allowed  
> > TCP packets to be transported.  Finally, we acquired in early 1981  
> > a complete Xerox Alto 4 Mb/s ethernet network that ran PUP and  
> > eventually a TCP implementation by Dave Clark, again before 1983.
> >
> > The idea that TCP was "developed to replace NCP" on the ARPANET is  
> > just wrong.  Completely, utterly and foolishly wrong.
> >
> > I don't know why anyone would take your word as an expert, Mr.  
> > Bennett.  I don't think the ITIF should pay you a dime.  You are no  
> > expert.  You know damn little, actually.
> >
> >
> >
> >
> > On 09/12/2009 05:06 PM, Richard Bennett wrote:
> > > David, you don't quite have your facts straight. TCP didn't run  
> > > *on top* of NCP on the ARPANET, it was a replacement for NCP. NCP  
> > > was the early host-host protocol for ARPANET, a transport layer,  
> > > not a network layer. The Host-IMP protocol and IMP-IMP protocols  
> > > were outside the scope of NCP.
> > >
> > > It turns out that BBN's IMP-IMP code had a datagram mode in  
> > > addition to the more commonly used connection mode, as did  
> > > ARPANET's progeny, X.25. I wonder if the implementation of IP over  
> > > ARPANET actually used it. The ex-BBNers don't seem to know.
> > >
> > > RB
> > >
> > > David P. Reed wrote:
> > > > I cannot begin to understand why the "flag day" was important as  
> > > > anything other than a symbol.  Everyone had already made the  
> > > > transition earlier, and there was no dramatic "cutover".  The  
> > > > reason is simple: TCP ran on *top* of NCP when it traversed the  
> > > > ARPANET.  And by this time, the NCP network may have been very  
> > > > important to those who were still connected only via IMPs, but  
> > > > guess what?  Many, many computers were connected by ethernets,  
> > > > etc. which NEVER ran NCP. Ever.  They used TCP over 802, based on  
> > > > ARP, etc.
> > > >
> > > > So Richard, you imagine a world that didn't actually exist.  In  
> > > > the early 1980's I was managing the Dover printers, which talked  
> > > > to ITS machines and so forth, and to SAIL, and to TENEX machines  
> > > > around the country using TCP, etc.   The ITS and TENEX and  
> > > > Multics systems had implementations of file sharing based on  
> > > > private file sharing protocols that ran on TCP, providing a  
> > > > internet-wide file system - and the only role NCP played was as  
> > > > one of many "layer 2" transport subnets on some of the paths that  
> > > > had been built in the ARPANET.  At that time there were many  
> > > > cross-country links that were over non-NCP paths.
> > > >
> > > > So it was only the *laggards* who were somehow lost in the past  
> > > > who were still using Telnet over NCP by 1983.
> > > >
> > > > The result of looking for an imaginary "cutover" in the flag day  
> > > > of the time is to completely distort history.  It's  a nice date,  
> > > > and some work was done, but no one noticed much, because by then  
> > > > NCP was pretty much unimportant.
> > > >
> > > > On 09/11/2009 05:16 PM, Richard Bennett wrote:
> > > > > OK, same apps modulo the Small Matter of Programming to use the  
> > > > > sockets API instead of whatever facility NCP provided. I suppose  
> > > > > the point is that from the end user's perspective, nothing  
> > > > > happened on New Year's Day 1983 except a few programmers missed  
> > > > > some bowl games as a consequence of being otherwise engaged and  
> > > > > telnet got a little more sluggish. Seems like ftp should have  
> > > > > been faster, however.
> > > > >
> > > > > Dan Lynch wrote:
> > > > > > Oh Richard, you jest.  I was sorta responsible for getting all  
> > > > > > the
> > > > > > applications converted to run on TCP/IP across the research  
> > > > > > world. That was
> > > > > > a generally unfunded activity, but it had to be done anyway.   
> > > > > > Telnet, FTP,
> > > > > > various email systems (varying a lot at the client level, but a  
> > > > > > single
> > > > > > protocol (SMTP) at the server level) were all rewritten  
> > > > > > extensively to run
> > > > > > on TCP/IP.  The user saw little performance change.  Making  
> > > > > > Telnet just as
> > > > > > responsive as before was challenging due to buffer management  
> > > > > > differences in
> > > > > > NCP vs.TCP.   Lots of other details I have forgotten in 27  
> > > > > > years...
> > > > > > Dan
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 9/11/09 1:43 PM, "Richard Bennett" <richard () bennett com>  
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > > > I'm curious about something, being a latecomer to The 'Net  
> > > > > > > (1986). After
> > > > > > > the Flag Day transition, users continued to run the same ftp,  
> > > > > > > telnet,
> > > > > > > email applications as before, and the BBN network continued to  
> > > > > > > operate
> > > > > > > as before, with the same IMP-IMP and IMP-Host protocols as  
> > > > > > > ever. Was
> > > > > > > there any perceptible difference to the end user from the  
> > > > > > > transition
> > > > > > > from NCP to TCP? Did the apps run any faster, was telnet more
> > > > > > > responsive, did file transfers finish quicker?
> > > > > > >
> > > > > > > I can imagine that the pipelining in TCP might have sped  
> > > > > > > things up a
> > > > > > > bit, but can also see that it might not have had much effect  
> > > > > > > as the
> > > > > > > actual transit network was still the same ole connection- 
> > > > > > > oriented system
> > > > > > > as before.
> > > > > > >
> > > > > > > RB
> > > > > > >
> > > > > > > Dave CROCKER wrote:
> > > > > > >
> > > > > > > > Dan,
> > > > > > > >
> > > > > > > > Thanks for reminding us of the earlier name.
> > > > > > > >
> > > > > > > > It occurs to me that, in fact, the Arpanet was at the heart  
> > > > > > > > of an
> > > > > > > > actual small-i internet significantly before the introduction  
> > > > > > > > of
> > > > > > > > TCP/IP into production operation and the January 1983  
> > > > > > > > switchover to
> > > > > > > > using it.
> > > > > > > >
> > > > > > > > In the 70s and very early 80's Xerox PARC, Berkeley and CSNet  
> > > > > > > > were all
> > > > > > > > providing email gatewaying -- that is, relaying amongst  
> > > > > > > > heterogeneous
> > > > > > > > systems -- to accomplish a seamless email internet.  Someone  
> > > > > > > > on a
> > > > > > > > CSNet Phonenet site could exchange email with someone on the  
> > > > > > > > PARC XNS
> > > > > > > > service quite handily, via the Arpanet, with no TCP/IP  
> > > > > > > > anywhere in view.b
> > > > > > > >
> > > > > > > > Not only did this create a perception of using a single,  
> > > > > > > > integrated
> > > > > > > > service, I claim it relied on the technical underpinnings of  
> > > > > > > > the same
> > > > > > > > kind of architectural overlay that was the essence of the IP  
> > > > > > > > model for
> > > > > > > > internetworking.
> > > > > > > >
> > > > > > > > This complexity and subtlety of service variations was why I  
> > > > > > > > later
> > > > > > > > wrote RFC 1775, To Be "On" the Internet.
> > > > > > > >
> > > > > > > > d/
> > > > > > > >
> > > > > > > > Dan Lynch wrote:
> > > > > > > >
> > > > > > > > > I do believe that it was even called the Catanet at the  
> > > > > > > > > beginning as in
> > > > > > > > > conCatenation of networks when we thought of a single  
> > > > > > > > > network as a
> > > > > > > > > set of
> > > > > > > > > data links.
> > > > > > > > ...
> > > > > > > >
> > > > > > > > > On 9/11/09 7:46 AM, "Dave Crocker" <dcrocker () bbiw net> wrote:
> > > > > > > > >
> > > > > > > > > > David Farber wrote:
> > > > > > > > > >
> > > > > > > > > > > From: Steve Crocker <steve () shinkuro com>
> > > > > > > > > > >       At the upper layers,
> > > > > > > > > > > the user community, the open protocol architecture and the
> > > > > > > > > > > expansion of
> > > > > > > > > > > applications continued more or less continuously.  From this
> > > > > > > > > > > perspective, the Arpanet and Internet are part of a  
> > > > > > > > > > > continuous arc.
> > > > > > > > > > It's worth stressing that this continuity is a technical  
> > > > > > > > > > reality,
> > > > > > > > > > not just a
> > > > > > > > > > (possibly indelicate) user perception.
> > > > > > > > > >
> > > > > > > > > > The same Telnet, FTP and email services have been in  
> > > > > > > > > > operation since
> > > > > > > > > > the early
> > > > > > > > > > '70s.  Calling it "the net" is a (possibly delicate) way to  
> > > > > > > > > > assuage the
> > > > > > > > > > sensitivities some of us might have about basic differences  
> > > > > > > > > > in the
> > > > > > > > > > lower
> > > > > > > > > > layers. It lets us, as speakers, reserve "Internet" for its
> > > > > > > > > > lower-layer precision.
> > > > > > > > > >
> > > > > > > > > > But we probably should not get any more upset about having  
> > > > > > > > > > this
> > > > > > > > > > continuously
> > > > > > > > > > available user environment popularly be called "The  
> > > > > > > > > > Internet" than
> > > > > > > > > > we are in
> > > > > > > > > > having an internet packet relaying device now be called a  
> > > > > > > > > > router,
> > > > > > > > > > rather than
> > > > > > > > > > its original "gateway".
> > > > > > > > > >
> > > > > > > > > > Highly precise historical distinctions have their place,  
> > > > > > > > > > but the
> > > > > > > > > > fact that
> > > > > > > > > > popular discourse finds them an excessive burden does not
> > > > > > > > > > automatically make
> > > > > > > > > > that discourse incorrect.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Tel. 707-967-0203   Cell  650-776-7313
> > > > > > My assistant is Dori Kirk   Tel. 707-255-7094  dori () lynch com
> > > > >
> > > > > --
> > > > > Richard Bennett
> > > > > Research Fellow
> > > > > Information Technology and Innovation Foundation
> > > > > Washington, DC
> > >
> > > --
> > > Richard Bennett
> > > Research Fellow
> > > Information Technology and Innovation Foundation
> > > Washington, DC

--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC





-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com