Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!cernvax!jmg From: jmg@cernvax.UUCP (jmg) Newsgroups: comp.protocols.appletalk Subject: Re: Appletalk Bridge/Routing Inefficiency? Message-ID: <972@cernvax.UUCP> Date: 10 Apr 89 15:13:29 GMT References: <2224@aecom.YU.EDU> Reply-To: jmg@cernvax.UUCP () Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Lines: 67 In article morgan@JESSICA.STANFORD.EDU writes: > >I'll bet you probably didn't notice anything unusual with this net >performance-wise until you put your Lanalyzer on the Ethernet. Any >large packet can be sent to the wrong Kbox and resent on the Ethernet >in far less time than it takes to transmit it on the LocalTalk, so >this "inefficiency" is trivial from the client Mac's point of view. >Assuming your Ethernet isn't overloaded already, it's not really a >problem there, either. An older Kbox may be a bottleneck, but then it >wasn't designed to support high-performance file service, either. > Unfortunately, this is NOT a question of Ethernet overload. We have a large Ethernet with a lot of bridges (OK, so does Bob!). Some of these bridges are fast, some are less fast, some are slow. In general, a bridge is there to cater for the traffic which MUST pass through it, so a slow bridge can be fine for an Ethernet which stays pretty self-contained. However, what we have now (and I mean me, here) is a situation where we put a real high-performance server onto the Ethernet (could be Novell, 3Com or others). The totality of traffic from this may be quite large, even though an individual part onto a particular LocalTalk may be low. If this totality ALL starts to go through a slow bridge then ....... (lost packets, timeouts). In addition, if I have a problem on any particular Ethernet then this might affect ALL server traffic, which at some time or other will be going onto (and back out of) that Ethernet. It is clear that running a simple Mac (with ethernet interface) as a server means we cannot avoid the problem. However, I believe that we should tell the providers of the special high-performance servers to get around this. I do not claim to know enough about the AppleTalk protocols to specify an answer: other people have done so. My guesses would be: 1. Have the server make a more intelligent decision by looking at the various broadcast packets put out by the various AppleTalk routers. 2. (If the dialogue is request-reply) Send a reply back to the (Ethernet) source address (assuming that you can know this). 3. Make the server look like an independent AppleTalk (albeit perhaps combining multiple servers onto a single zone). I have a vague idea that someone (Alisa? Pacer?) already does this. >What you may have noticed is that when you set up this network you >didn't have to configure *anything* having to do with router >addresses, default routes, etc. The dynamic protocol that bothers you >is what makes that possible. The philosophy is that the client >station, which may be a 128K Mac, shouldn't have to know anything >except the address of *some* router, not necessarily the "best" one. >The router, being smarter, will worry about routing. If a router >fails, the client will find out about another working one promptly, >and use it. > The fact that I do not have to reconfigure anything is nice, but not inconsistent with efficient routing. The philosophy is simple, agreed, but I see nothing that stops it being made slightly more sophisticated in necessary cases. >I consider the time I spend explaining to neophyte network >administrators about default IP router addresses, and fixing >misconfigured machines, to be the real "inefficiency". I hope >AppleTalk 2 doesn't lose too much ease of use in its pursuit of >performance. I hope AppleTalk 2 meets all our needs (and comes out Real Soon Now). -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland