Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!kwe
From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
Newsgroups: comp.protocols.appletalk
Subject: Re: The Coming AppleTalk Crisis
Message-ID: <28066@bu-cs.BU.EDU>
Date: 17 Feb 89 17:07:51 GMT
References: <724@aplcen.apl.jhu.edu>
Reply-To: kwe@buit13.bu.edu (Kent England)
Followup-To: comp.protocols.appletalk
Organization: Boston U. Information Technology
Lines: 71

In article <724@aplcen.apl.jhu.edu> lloyd@aplcen (Lloyd W. Taylor) writes:
>
>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.
>	2.  Use of Broadcasts.  
>
>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.
>

	I would nominate some other features of AppleTalk that do not
scale well.  The name binding protocol doesn't scale well to large
internets. 

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

	That other protocol set already exists, it is called TCP/IP.
It would be simple for Apple to make AppleTalk run on TCP/IP.

	The Internet is the world's largest experiment in
internetworking.  Things like the Domain Name System and IP routing
are outstanding achievements in large-scale networking.

	AppleTalk is the world's most "plug-and-play" network [please,
no flames or religious-wars comments].  It is a significant experiment
in what it takes, protocol-wise, to make LANs work without system
administration. 

	The world needs a networking standard that combines the best
of both TCP/IP and AppleTalk.  If Apple doesn't address the problems
of large scale networking, AppleTalk will disappear and be remembered
as an interesting experiment.  Not many people are interested in LANs
that are exclusively local.

	What can Apple do to try to incorporate some degree of dynamic
configurability into TCP/IP?  This is an issue that is understood in
the community, but nothing much is happening (unless it falls out of
the host requirements RFC).  What can Apple do to plug the best
features of AppleTalk into the TCP/IP suite?  Does Apple even realize
that large-scale networks are different and that we who know them will
not tolerate AppleTalk as it is today?  Upping the number of nodes is
simply making the problem worse and that is all Apple proposes to do
in AppleTalk 2.0.  Does Apple really think I am going to let people
plug EtherTalk into my internet, even if Apple ups the node limit to
10,000 nodes?  No way- the protocol does not scale and AppleTalk will
be limited to LocalTalk as a simple way to plug Macs into FastPaths or
other LocalTalk-to-TCP/IP gateways.

	I will not build large AppleTalks if they are not scale-able.
A small scale AppleTalk protocol suite is about as interesting as
RS-232.

	Kent England, Boston University