\documentstyle[fullpage]{article}
\title{Hierarchies on Athena}
\author{Greg Hudson}
\begin{document}
\maketitle

In his article ``The Architecture of Complexity,'' Simon for the most
part discusses heterogeneous hierarchies, where a system's subsystems
are qualitatively different from the system itself (for instance,
molecules are qualitatively different from the atoms they are composed
of).  I will discuss one heterogeneous hierarchy on Athena, and one
recursive hierarchy where subdivisions can have the same properties as
the whole.

MIT's main network is an example of a heterogeneous hierarchy.  MITnet
is composed of many subnets, each of which contains up to a hundred or
so machines.  Each subnet has a router, all of which are connected
together through a simple FDDI ring.  MIT's FDDI ring is connected,
through Nearnet and other providers, to other sites' networks, and the
providers have their own interconnections.

The advantage of this network organization is that it simplifies
routing.  If a machine on SIPB's subnet wants to send a packet to a
machine in the Watchmaker zone, the routers need only know what subnet
that machine is on, and nothing more.  Similarly, if a machine in
Wisconsin wants to send a packet to a machine on MIT's net,
Wisconsin's routers need only know where MIT's router is, not where
the machine is located within MIT's net.

At the subnet level, no routing information is required, since all
packets on the subnet flow by all the machines on the subnet.  This
clearly doesn't scale, and it is important that the number of machines
on a subnet is fairly small.  At the next level up, MIT's internal
routers need only know about other subnets at MIT, a small number of
hosts.  Above this level, things break down: the routers for
well-connected sites and Internet providers need to know about all the
networks on the Internet, a rapidly growing set.  This is because a
machine's IP address does not give any information about providers.
Internet routing would be considerably simpler if routers only needed
to know about the various Internet providers; this may or may not be
the case in the next-generation IP addressing scheme.

A good example of another kind of hierarchy, recursive hierarchies, is
Athena's mailing list structure.  A mailing list consists of a list of
receivers, each of which can be either a user or, recursively, another
mailing list.  For example, the list ``infosys'' contains sublists
such as ``dcns'' and ``css'' for the various groups in Information
Systems.  The list ``dcns'' in turn contains ``dcns-dev,'' ``dcnsm,''
etc., for various (often overlapping) subgroups of DCNS.  Only at the
subgroups level do you find actual users on the mailing lists.  This
particular mailing list structure usually reflects the management
hierarchy of Information Systems.

Given these hierarchical lists, I can send mail to as specific or as
general a group as I want.  If I want all of IS to know about a
conference, I can send to ``infosys,'' but meetings for the
development group are announced only to ``dcns.''  One could emulate
the same structure with lists containing only individual users, but
then maintenance of those lists would become much more complicated and
error-prone.  With the hierarchical list structure, new UROP students
in the Watchmaker zone need only be added to the ``dcns-dev'' list.

In addition, the hierarchical mailing list system is self-documenting:
I can look at the sublists of ``infosys'' and determine easily what
groups are supposed to be on it, while a list of users who receive
mail when I send to ``infosys'' would be all but useless for that
purpose.

These are just two examples of how management of Athena-related
systems is made simpler using hierarchies.  Other examples include
toolkit applications, filesystems, and Unix process groups.

\end{document}

