glen@aecom.YU.EDU (Glen M. Marianko) (03/28/89)
You learn something new every day - so, why not pass it along. Well, here is one that caught me by suprise. We have an ethernet with two fastpath gateways (doesn't matter which version/model), Macs connected to the localtalks on each and an SE AFPServer with Kinetics Etherport card on the ethernet. I put a Lanalyzer on the ethernet and what I found put me into a spin which didn't end until a gracious engineer at Kinetics explained things. Basically, looking at the Lanalyzer when I launched an application from a Mac on appletalk, I saw packets sometimes go directly to the fastpath that directly bridged that segment, and - get this - other times it would go to the OTHER fastpath which would forward the packets to the bridging fastpath. Now, to any normal network designer that would seem like a terrible nono - first it imposes a buffering delay getting packets from one fastpath to the other, let alone the extra overhead of heaving more than 2-for-1 packets on the ethernet! Careful observation of the ethernet showed that the server would switch to the other gateway after that gateway did a Broadcast. Assuming you had a large enough application to load, you could see the path to your Mac alternate from the direct-connect fastpath to the other and back after the respective broadcasts. Turns out Appletalk has a single line table in the server for routing packets to routers/bridges on different segments. Every time the fastpath broadcast an "I'm a bridge" packet, the server would update its table and send the packets to that bridge. Gee - is it me or do we really NEED Appletalk 2.0 YESTERDAY! Hail to TCP/IP. -- Glen Marianko, Supervisor of Data Communications glen@aecom.yu.edu
morgan@JESSICA.STANFORD.EDU (03/29/89)
Glen: [ Glen Marianko comments that AppleTalk's dynamic router discovery method leads to inefficient routing. ] Let's not (once again) bash AppleTalk for not being something it wasn't intended to be, and let's not forget you don't get something for nothing. 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. 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. 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. - RL "Bob" Morgan Networking Systems Stanford
Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) (03/29/89)
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. 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). Bob's point about people time being more expensive than machine time should not be ignored. But in my case, my people are losing time due to deficiencies in the implementation. I could care less how hard the kbox has to work, the electricity costs about the same. Rob
paul@taniwha.UUCP (Paul Campbell) (03/29/89)
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"
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (03/30/89)
In article <334@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: > >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? > > I would point out that the conventional wisdom in the TCP/IP community is that, for a variety of reasons, workstations (or non-routers) should not snoop on or participate in router protocols, like RTMP. Of course, the TCP/IP community is still grappling with a router discovery protocol and dealing with multi-homed (multi-interface) hosts. I would think that there might be a clean way to ascertain the router to use during the process of name lookup. I think there should also be an independent router announcement protocol for implementations that want to keep a list of active routers for the purpose of selecting a default if the name lookup protocol is insufficient in all cases. Have to give some careful thought to direct versus thru-router name lookup, etc, but that's all part of the issue of dynamic router and internet topology discovery and what part of that process belongs in the "host"s.
pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek) (03/30/89)
In article <Added.8Y=x0ty00UkT4BcE8k@andrew.cmu.edu> morgan@JESSICA.STANFORD.EDU writes: >[ Glen Marianko comments that AppleTalk's dynamic router discovery >method leads to inefficient routing. ] > >Let's not (once again) bash AppleTalk for not being something it >wasn't intended to be, and let's not forget you don't get something >for nothing. > >[additional speculation as to Glen's 'problem'] > >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. > > - RL "Bob" Morgan > Networking Systems > Stanford I wholeheartedly agree with Bob. Appletalk was not designed to be the network to which the entire world could attach and operate efficiently. I also sincerely hope that future versions of AppleTalk maintain the ease of use and configurability that AppleTalk has today. Not having to configure addresses, paths, routers, etc., etc., etc., in my mind makes up for any possible inefficiency. I would hope that those areas which may be of concern (e.g., routers) would be addressed WITHOUT mucking up the existing AppleTalk protocols. Having been involved in networking software for over 12 years, I would like to take this opportunity to thank Apple and the individuals involved in the design of AppleTalk for bringing us a new (and IMHO, better) way of doing things. M. A. Pasek Switching Software Development NCR Comten, Inc. (612) 638-7668 CNG Development 2700 N. Snelling Ave. pasek@c10sd3.StPaul.NCR.COM Roseville, MN 55113
pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek) (03/30/89)
In article <11090.607116692@GNOME.CS.CMU.EDU> Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) writes: > [stuff deleted] .......and the 128K mac >(which nobody has anymore) .....[remainder deleted] Bet ME and lose!! M. A. Pasek Switching Software Development NCR Comten, Inc. (612) 638-7668 CNG Development 2700 N. Snelling Ave. pasek@c10sd3.StPaul.NCR.COM Roseville, MN 55113
tom@wcc.oz (Tom Evans) (04/04/89)
In article <2224@aecom.YU.EDU>, glen@aecom.YU.EDU (Glen M. Marianko) writes: > I saw packets sometimes go directly to the fastpath > that directly bridged that segment, and - get this - other times it > would go to the OTHER fastpath which would forward the packets to the > bridging fastpath. This has been explained in other postings, but... Would putting the Ethernet and each of the two LocalTalk networks in different ZONES fix it? Are the "I'm a bridge" broadcasts zone-limited? [ ] Yes [ ] No [ ] TURKEY! My .sig's bigger than this article so I won't...
alexis@ccnysci.UUCP (Alexis Rosen) (04/07/89)
Liason 2.0, from InfoSphere, ships with a little INIT called Network Tuner.
I'm not 100% sure what this thing does (it's about 2K, as I recall), but I
distinctly had the impression that it was designed to improve usage of
bridges and routers by regular nodes. Perhaps this does what Paul suggested?
I will ask Evan Solley the next time I talk to him...
---
Alexis Rosen
alexis@ccnysci.{uucp,bitnet}urlichs@smurf.ira.uka.de (Matthias Urlichs) (04/09/89)
In comp.protocols.appletalk alexis@ccnysci.UUCP (Alexis Rosen) writes:
<
< Liason 2.0, from InfoSphere, ships with a little INIT called Network Tuner.
< I'm not 100% sure what this thing does (it's about 2K, as I recall), but I
< distinctly had the impression that it was designed to improve usage of
< bridges and routers by regular nodes. Perhaps this does what Paul suggested?
This INIT should be installed on Macs which want to communicate over an
async/modem line but don't run Liaison (which includes it).
Basically, ATP timeout which work splendidly for "normal" AppleTalk
are much too short for modem use. You get a retry request halfway through the
answering packet and this results in 2-3 times lowered throughput at best,
and breaking longish file transfers (or Timbuktu screen updates :-) at worst.
I have written such an INIT myself; it's pretty trivial to do.
Q: I don't have seen Liaison 2.0 yet, what does it do (in addition to 1.0.1)?
PS: Timbuktu works over a 2400-Baud Liaison line pretty well (and pretty slow,
but well, such is life). Just three hints:
- Do use a normal pattern as Desktop background, and not a picture.
Otherwise, every time a teeny bit of desktop needs to be updated,
Liaison sends the whole picture...
- Disable broadcasts and (more important) sending screen bit changes
unless you want to run MacPaint 1.x or Hypercard. (Hint: You don't want to.)
- Avoid Timbuktu'ing to the host Liaison is running under. Reason:
Liaison blinks a little arrow under the Apple in the menu bar, which
generates lots of network traffic and prolongs the already too-big lag
between your actions and the usr interface reaction. :-(
PPS:Did you know that Timbuktu is saving the bits under a menu on the
observing machine too? Without that feature, I wouldn't dream of using it
over less than 9600 Baud.
--
Matthias Urlichs -- Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- FRG
urlichs@smurf.ira.uka.de -- ++49+721-621127@PTTjmg@cernvax.UUCP (jmg) (04/10/89)
In article <Added.8Y=x0ty00UkT4BcE8k@andrew.cmu.edu> 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
alexis@ccnysci.UUCP (Alexis Rosen) (04/13/89)
In article <899@smurf.ira.uka.de> urlichs@smurf.ira.uka.de (Matthias Urlichs) writes: >In comp.protocols.appletalk alexis@ccnysci.UUCP (Alexis Rosen) writes: >< Liason 2.0, from InfoSphere, ships with a little INIT called Network Tuner. >< I'm not 100% sure what this thing does (it's about 2K, as I recall), but I >< distinctly had the impression that it was designed to improve usage of >< bridges and routers by regular nodes. Perhaps this does what Paul suggested? > >This INIT should be installed on Macs which want to communicate over an >async/modem line but don't run Liaison (which includes it). >Basically, ATP timeout which work splendidly for "normal" AppleTalk >are much too short for modem use. You get a retry request halfway through the >answering packet and this results in 2-3 times lowered throughput at best, >and breaking longish file transfers (or Timbuktu screen updates :-) at worst. >I have written such an INIT myself; it's pretty trivial to do. Um. Quoting from the 2.0 release notes: "An improved Network Tuner always selects the most direct route to a different network to eliminate the usual extra hop on nets with more than one bridge." This sure sounds like what Paul was talking about... I'll talk to evan tomorrow and find out for sure. Liason 2.0 has Dial-back, activity logs, net resource hiding, monitoring, integrated FlashTalk support (yay!), better async throughput, lots better MNP support, better support of relayed calls, and some (very) minor bug fixes. It's an extraordinarily elegant piece of work. --- Alexis Rosen alexis@ccnysci.{uucp,bitnet}