Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!haven!aplcen!lloyd
From: lloyd@aplcen.apl.jhu.edu (Lloyd W. Taylor)
Newsgroups: comp.protocols.appletalk
Subject: The Coming AppleTalk Crisis
Message-ID: <724@aplcen.apl.jhu.edu>
Date: 17 Feb 89 13:58:16 GMT
Reply-To: lloyd@aplcen (Lloyd W. Taylor)
Organization: Johns Hopkins University
Lines: 84


The AppleTalk protocols (as currently implemented) do not scale well to
large ("Enterprise" or "Campus") networks.  There are two behaviours
that become unacceptable when used in large (>200 Mac) ethernet
networks:

	1.  Node Limits.  AppleTalk allows 8 bits for a node address.
	    Address 255 is for broadcast, address 0 is "reserved".  As
	    soon as someone plugs the 254th AppleTalk device into the
	    ethernet, the peanut butter really hits the fan.  No
	    addresses are available, so the Mac cannot communicate.

	2.  Use of Broadcasts.  When a Mac (or other AppleTalk device)
	    is first connected to the network, it 'randomly' selects a
	    node number.  It then sends out 20 broadcasts (in one
	    second) claiming that node number.  If no other device
	    responds ("Sorry, number in use.  Try again."), the Mac
	    simply uses the number it randomly selected.  If on the
	    other hand, the selected address is used, the Mac will
	    randomly select another number, and repeat the cycle.

In the worst case scenario, the Mac will require 253 sets of 20
broadcasts to determine that no addresses are available.  Question:
What will happen to the devices on your ethernet when that kind of
broadcast load hits?

A third related problem is the use of Apple's "Routing Table
Maintenance Protocol" (RTMP) by AppleTalk gateways (such as Kinetics, 
Cayman, and others).  These devices all exchange their routing tables
every 10 seconds via broadcast.  In a large environment with many
gateways, a disproportionately large percentage of broadcast traffic is
due to the exchange of these tables.

There are no good solutions to this problem.  Apple has too many
devices that use AppleTalk already installed to do a major rewrite of
the protocols.  If the protocols are not rewritten, the above scenario
will occur in more and more places, as the number of ethernet-attached
Macs reaches the 253-node/network limit.

The only "compromise" solution that I can see is to redefine the
AppleTalk over Ethernet (EtherTalk) protocols.  The current AppleTalk
protocols would be retained on LocalTalk networks, where their
"plug-and-play" nature is so valuable.  A set of redesigned protocols
would have to implemented on every installed Ethernet-attached Mac,
AppleTalk-Ethernet gateway (e.g. Kinetics, Cayman), ethernet-attached 
server (e.g. AlisaTalk/VMS, TOPS/Unix).  These redesigned protocols
would undoubtedly require a knowledgable administrator to set up node
and net numbers because the complexity of the average Campus Network
is not conducive to the plug-and-play nature of the current AppleTalk.

Apple Corporate has been aware of this problem since at least June of
1987 when I discussed it with Gursharan Sidhu (the creator of
AppleTalk) at the Communications Developers Conference in Boston.  To
date, there has been no clear response (other than "we're working on
it").  

Apple (And especially Gursharan!) deserve a lot of credit for the
design of AppleTalk.  The concept of simply plugging a bunch of Macs
together with a LaserWriter for printer sharing is still the envy of
the PC world.  Apple caught a lot of flak in the early years about the
coomplexity of the protocol.  "Everyone knows that it'll never be used 
for anything but connecting printers" was the conventional wisdom.

Those skeptics have been proved wrong.  AppleTalk networks now span the
globe.  Those of us who have to make them work see major trouble ahead
unless something is done quickly.  The cost will be high.  The
alternative is to ban Macs from the ethernet because of their effect on
other systems.

-- Lloyd Taylor
   Telecomm/Datacomm Manager
   Johns Hopkins University
   Applied Physics Lab
   lloyd@aplcen.apl.jhu.edu


Disclaimer:  To the best of my knowledge, the facts about AppleTalk
stated above are correct, although they have been oversimplified for
the sake of brevity.  I've been struggling with this problem for
almost two years.  If I've misunderstood something, feel free to
correct me.  

The above statements are mine alone, and do not represent the offical
postion of my employer.