
Short History of Chaosnet - stargrave
https://twobithistory.org/2018/09/30/chaosnet.html
======
gumby
The article is correct that contact names were essentially the same as port
numbers in TCP. This was a time of great experimentation in LAN protocols (and
network protocols, what we would now call layers 1-4 or maybe -5). By the mid
70s most used thicknet (later called 10base5) coax using CSMA with exponential
backoff (Metcalf's greatest invention at PARC IMHO), so chaosnet was a local
example (of several in New England alone, at the time). There wasn't really
anything off the shelf at the time.

CHAOSNET and lispms are historically intertwined it's true, but hardly
inextricably so. For example the file servers referred to in the article
weren't (until much later) lispms too, but our standard PDP-10 mainframes, so
there were multiple implementations of chaosnet immediately, and it was also
used for mainframe-mainframe communication (yes, you could transparently use
remotely stored files back in the late 1970s). The earliest machines sold by
Symbolics and LMI were just MIT CADRs build externally and badged by the
manufacturer, by the time they built their own machines the Ethernet standard
(also using 10base5) was starting to get traction and their machines used that
instead. I did deploy and use a chaosnet system at the Centre Mondial in Paris
because they had a KL-20 and some CADRs, but that was a rare case; possibly
the only one outside USA, or possibly even outside the east coast of the USA.

Article is correct about the deep ties between BBN and MIT-AI. Honestly at the
time of the ARPANET switching to TCP I really thought of the other address
types as transitional anyway, so I'm not surprised more address types were
never used. Though the whole point of the idea of an Internet was the union of
all other networks (and the origin of the idea of the "cloud" \-- a radical
idea at the time, though focused on routing) the early model was either
protocol-translating gateways or TCP.

When the net switched over from NCP to TCP it didn't really feel like it
affected me until 1984 when I could telnet directly from my machine at PARC (a
Dolphin or Dorado -- they were also in a machine room with the display and kbd
on my desk!) to my machines at the MIT AI lab. It seemed magical not to have
to log into an intermediate machine. This was thanks to a pup gateway (pup was
PARC's equivalent to chaosnet, or perhaps I should say that the other way as
pup was first) and sadly I eventually realized that it wasn't using a chaosnet
gateway on the MIT side (the PDP-10s had their own IMPs). But by the time I
moved back to MIT this worked in the other direction as well.

------
kiwidrew
I've always known CHAOS as the hmmm-that's-weird way of finding out which
version of BIND was running:

    
    
      $ dig @a0.org.afilias-nst.info version.bind txt chaos
      ;; ANSWER SECTION:
      version.bind.		0	CH	TXT	"9.9.9-P5"
    

I never realised that once upon a time there was an actual Chaosnet
protocol...

------
mxuribe
Oh wow, chaosnet is a great name! I learn something new with every post from
Two-bit history!

------
rjsw
There are several emulators that can talk Chaosnet, emulating Lisp Machines
and the PDP-10.

------
chforever
Is ChaosNet remembered more accurately than Maryland summer parties in 1982?
Let's find out!

> Usage of Chaosnet presumably waned as Lisp machines became less and less
> popular.

The relative drop in popularity of Lisp Machines wasn't the primary reason for
ChaosNet use to decline. Until the mid-1980s at MIT, ChaosNet was also widely
used in everyday work on UNIX, VMS, and TOPS-20. ChaosNet was not focused on
the small number of research groups that used Lisp Machines. By the mid-1980s,
most operating system distributions included TCP/IP. There were more deployed
machines that could communicate over TCP/IP than over ChaosNet. However, MIT
did not yet have a supported IP network covering every building (where
"supported" means either centrally supported by MIT, or supported by a major
research lab, depending on the building in question).

The remaining reasons to use ChaosNet were network services and reliability.
For example, SUPDUP arguably provided a much better remote-login experience
than TELNET, and some (or possibly all) machines implemented SUPDUP only over
ChaosNet, not over TCP. There may have been other important ChaosNet-only
services on machines such as reagan (more commonly known as "b" \-- for
"bonzo") at the AI Lab.

In some locations (possibly only on Vassar Street), keeping the ChaosNet
software stack for reliability was worthwhile even though IP was obviously the
only way to directly reach the whole outside world. Using the ChaosNet
software stack, one could communicate within parts of the main campus as well
as NE43, and relaying email to the outside world worked, at least often. That
was sometimes the only networking that a person needed to accomplish their
work. In building 36 and 38, the earliest set of IP addresses was on the
18.27/16 network. That specific implementation of IP may have involved some
type of protocol tunneling or protocol translator. At one time, this was
maintained at the Digital Signal Processing Group (sixth floor of 36) and may
have run on a machine named yosemite-sam (or some other Looney Tunes
character). This was largely successful, but not really "supportable."
Eventually, a separate network was built in 36 and 38 using 18.62/16 IP
addresses, and any machine wired to that network could not use ChaosNet
services elsewhere. Over time (more than a year), every machine moved off of
18.27/16 and onto 18.62/16\. At that point, it rarely made any sense for
anyone outside of NE43 to build or enable ChaosNet support on any machines.

Even before this, the cost/benefit became too high for some people to bother
building, installing, or enabling ChaosNet. For example, Alan Wu, who was the
head of the Electrical Engineering and Computer Science Educational Computing
Facility (EECS ECF) made a decision in the mid-1980s that his staff would no
longer compile ChaosNet into the kernel on their BSD machines. The reasons may
have included the extra work of a nonstandard build tree, and machine crashes
within the ChaosNet code. Similarly, syaadmins in other places saw that it
didn't make sense to devote any resources to the small benefits of ChaosNet.

On a larger scale, Project Athena BSD kernels did not include ChaosNet code
(or, if they ever did at the beginning, it was discontinued after a while or
was never commonly used). However, Athena was probably not a major factor in
the decline of ChaosNet. Athena workstations were never connected to
unsupported networks such as 18.27/16, and Athena users typically had no
SUPDUP use case. ChaosNet use was already mostly gone (outside of NE43) before
individual faculty and staff were generally able to request Athena
workstations for their offices or labs.

