lloyd@aplcen.apl.jhu.edu (Lloyd W. Taylor) (02/17/89)
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.hpoppe@bierstadt.ucar.edu (Herb Poppe) (02/18/89)
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. [long discussion deleted] According to the latest MacWeek (if I remember correctly) AppleTalk 2.0 (which is rumored to be out this summer) addresses some of these problems. In particular, it deals with the 255 node issue. Herb Poppe NCAR INTERNET: hpoppe@ncar.ucar.edu (303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET Boulder, CO 80307 UUCP: hpoppe@scdpyr.UUCP
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (02/18/89)
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
desnoyer@Apple.COM (Peter Desnoyers) (02/18/89)
I just wanted to point out that a lot of people at Apple are acutely aware of the problems of large Appletalk internets. We work on one. We are all waiting for the promised Ethertalk upgrade with as much anticipation as you are. Peter Desnoyers
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (02/18/89)
In article <25980@apple.Apple.COM> desnoyer@Apple.COM (Peter Desnoyers) writes: >I just wanted to point out that a lot of people at Apple are acutely >aware of the problems of large Appletalk internets. We work on one. We >are all waiting for the promised Ethertalk upgrade with as much >anticipation as you are. > > Peter Desnoyers Here is evidence of what I am speaking of in my follow-up on the upcoming AppleTalk crisis. Apple (or at least P Desnoyers) does not understand that the solution to the AppleTalk problem is not more nodes on EtherTalk. More nodes on EtherTalk will simply encourage people to put large EtherTalk nets on top of their TCP/IP nets and then -watch out!- when they start wondering why their network has gone to hell. I see no evidence that Apple, with all its resources, understands what a large network means in terms of protocol. If someone from Apple would like to discuss what I am talking about, you can reach me at kwe@bu-it.bu.edu. I am ready to find out if you are serious about networking.
desnoyer@Apple.COM (Peter Desnoyers) (02/18/89)
In article <28088@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: >In article <25980@apple.Apple.COM> desnoyer@Apple.COM (Peter Desnoyers) writes: >> [polite, relatively information-less comment that we suffer the same >>problems] >> Peter Desnoyers > > Here is evidence of what I am speaking of in my follow-up on >the upcoming AppleTalk crisis. Apple (or at least P Desnoyers) does >not understand that the solution to the AppleTalk problem is not more >nodes on EtherTalk. > Give me a break. At least wait for me to say something which you can then mis-interpret, rather than divining my opinions from thin air. I don't work on Appletalk. I don't know what they've promised to deliver in their upgrade. I don't want to repeat gossip and half-remembered presentations and have it picked up as fact. > More nodes on EtherTalk will simply encourage people to put >large EtherTalk nets on top of their TCP/IP nets and then -watch out!- ^^^^^^^^^ That's a weird place to put them - encapsulating appletalk in ethernet in tcp in ip in ethernet... :-) Anyway, so much for flaming. Perhaps Kent should read up on OSI, ISDN, and a few other topics before he goes around expressing the view that TCP and IP represent the be-all and end-all of network development. Peter Desnoyers
hedrick@athos.rutgers.edu (Charles Hedrick) (02/19/89)
The encapsulation he was talking about is appletalk in UDP. No TCP, and only one Ethernet. Many (most?) large university installations do their campus-wide AppleTalk that way. It is partly historical. When the practice started there was no EtherTalk. So this was the simplest way to connect LocalTalk networks that were on opposite ends of campus. Use a Kinetics box to take LocalTalk packets in one side, stick a UDP header on them, and then put them on a campus Ethernet where they would be routed to a Kinetics box on the destination Ethernet. Now that there is an EtherTalk, one could consider having the packets travel through the campus network as EtherTalk. This would still require the same hardware, since you'd still have to get the packets from the LocalTalk to the Ethernet. But you would be saving yourself is the extra UDP and IP headers. While we're always happy to save a few bytes in packets, there are two problems with this: - many people consider EtherTalk inappropriate for a large network. The excessive broadcasting is only one problem. There are also questions about the quality of the routing algorithms. - some university networks consist of a complex combination of Ethernets, serial lines, broadband, fiber, etc. It's hard enough to route IP reliably through this. We don't want to have to manage a separate routing structure for every vendor's protocol. So we'd rather stick an IP header on the packets for transit through the network than have to maintain Appletalk routing over the whole network. (And this assumes that our routers even support Appletalk. Many do not.) OSI is still not widely enough available to be a real alternative for most campuses. But I assume if networks move from IP to OSI, similar encapsulation will be done using the OSI equivalent of UDP. (Of course one could hope that by then Appletalk would have direct support of OSI.) IP may or may not be the be-all and end-all of network development. (Many of us suspect that, like Algol 60, it is a great improvement over all its successors.) But at the moment there are good reasons why it is the basis for most campus networks. Any company interested in selling to us needs to realize that our campus network is based on IP, and there's probably not much they can do to change that.