Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!mtxinu!taniwha!paul From: paul@taniwha.UUCP (Paul Campbell) Newsgroups: comp.protocols.appletalk Subject: Re: Appletalk Bridge/Routing Inefficiency? Message-ID: <334@taniwha.UUCP> Date: 28 Mar 89 22:52:13 GMT References: <11090.607116692@GNOME.CS.CMU.EDU> Reply-To: paul@taniwha.UUCP (Paul Campbell) Organization: Taniwha Systems Design, Oakland Lines: 63 In article <11090.607116692@GNOME.CS.CMU.EDU> Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) writes: >Bob Morgan makes a good point about AppleTalk and dynamic router discovery. >But the problem that Glenn pointed out is that once a route is discovered, >it is silly (and I think unwise) to throw all your traffic from router to >router. I agree, routers should be the smart things, and the 128K mac >(which nobody has anymore) should be able to blindly go bouncing back and >forth between N routers everytime it gets an RTMP packet. But in my case, I >have on the order of 3 connections going at a time. I think a scheme not >unlike ARP caches could be used to at least lower the massive fluctuations >on the network (we all seem to understand aging cache entries, right?). If >I have two routers, why burden each of them with *all* the traffic half the >time? Isn't it smarter to (in the usual case) give each router half the >traffic *all* the time? It seems to me that would be a more stable network. To be fair this is only a problem on physical nets with more than one router (most people I know of are on nets with 0 or 1 routers, obviously people on backbones are going to suffer from this 'problem'). If you have 2 routers you are going to get the correct one 50% of the time (ignoring packets for the physical net you are connected to), with 3 routers 33% etc etc - with the penalty of 1 extra hop when you get the wrong one. Obviously putting normal users on the backbone may not always be a good idea (routers of course always know who to send to). >Having AppleTalk autoconfigure would also be more acceptable if you *could* >give your driver some hints about the reality of the situation. That way, >the default behavior would be to act like things are now, but you could say, >modify the retransmit interval in AppleShare with the control panel >(hint,hint). A few possibilities come to mind for workstations: 1) maintain an RTMP cache just like a router (you don't need to keep a ZIP table if you still have the routers generate the NBP lookups), this is not easy code to write and the tables can end up using large amounts on memory on some of those giant nets 2) Whenever you receive a packet from another net remember what the source net number and the LAP node number were, put them in the cache, use the RTMP packets from that LAP address to keep them valid (to validate the bridge lap address and to validate that it's still the fastest way to get to it [in case of the config changes]). Use the cache entries on transmission, if one isn't present then fall back to the old method (the reply will fill a cache entry) [maybe you don't put NBP response packets in the cache] 3) Just watch the RTMP packets and remember the one that is closest to the most nets, that way you turn your 50% more towards 70% etc (unless you really are right in the middle of things), or the one that is closest to the most nets that you recently sent packets to etc etc Well there's a start, and we didn't touch the protocol, personally I like #2 falling back to #3, any other suggestions? Paul -- Paul Campbell, Taniwha Systems Design, Oakland CA ..!mtxinu!taniwha!paul "'Give me your tired, your poor - I'll piss on them' that`s what the Statue of Bigotry sais. 'Let`s club them to death, get it over with and just dump them on the Boulevard'" - Lou Reed, "New York"