Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!netnews.engin.umich.edu!billkatt From: billkatt@caen.engin.umich.edu (billkatt) Newsgroups: comp.protocols.appletalk Subject: Re: UDPTalk as a backbone Message-ID: <1989Sep5.192546.15473@caen.engin.umich.edu> Date: 5 Sep 89 19:25:46 GMT Reply-To: billkatt@mingin.engin.umich.edu.UUCP (billkatt) Organization: Univ. of Michigan College of Engineering Lines: 151 Newsgroups: comp.protocols.appletalk Subject: Re: UDPTalk as a backbone Summary: Expires: References: <1989Sep3.063402.22872@caen.engin.umich.edu> <31297@ames.arc.nasa.gov> <1989Sep4.202733.6326@caen.engin.umich.edu> <31353@ames.arc.nasa.gov> Sender: Reply-To: billkatt@caen.engin.umich.edu (billkatt) Followup-To: Distribution: Organization: Computer Aided Engineering Network (CAEN), University of Michigan Keywords: In article <31353@ames.arc.nasa.gov> medin@cincsac.arc.nasa.gov.UUCP (Milo S. Medin) writes: >In article <1989Sep4.202733.6326@caen.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes: All right, I came off as a jerk, I realize that now. I'll try to be a little more constructive and open. I don't like the current situation, but I don't want to discourage the possibility of a future solution which WILL work. > >>I don't see how you can say that. Phase 2 fixes many of the routing traffic >>problems of phase 1. As for the broadcasts, I agree. However, I don't see >>... >>times. Anyone who has a 10mbit ethernet for a backbone two years from now >>isn't taking themselved seriously. > >Increasing processor speeds? Why should all the hosts on the LAN pay the >price for the miscreant Ethertalk hosts broadcasting all over creation? >Phase II will be interesting. I don't see it going far enough >to solve the real problems here, and it is no more standardized than >Phase I. We'll see how it goes. We'll have faster nets here too >(we have gigabit Ultra nets already on the facility - hmmm, no Appletalk drivers >for them though :-))... Being needlessly inefficient is always a bad idea. Gee, you should have told that to the people who wrote UNIX. It seems that UNIX and a lot of the software which runs under it is based on ineffeciency, all the way down to cc. It seems to be the current thing to give up effeciency for portability and flexibility. Lets not be hypocritical here. >> >>I agree with what you say. MacTCP is quite fast and is a better idea for >>many Mac to Unix communications, anyway. What does that have to do with >>UDPTalk? CAP is the only exception (like I said), but CAP does not involve >>routing UDPTalk. > >My point was that we restrict Mac connections to Appletalk nets to localtalk >speeds (since we don't allow Mac's to run Ethertalk on the LAN, only TCP/IP). >The high speed applications are generally better served by IP protocols. Hmmm... You're not the first person I have heard of who does that. Is there an overriding reason? I don't see one. Or do you use a different physical backbone for IP as AppleTalk? > >>Maybe you should research your facts. Kinetics INVENTED UDPTalk. The original >>FastPaths (1's) were invented to bridge LocalTalk to UDPTalk (EtherTalk didn't >>exist yet). What Kinetics doesn't support is atalkad and UDPTalk backboning. >>They don't support it at all, you ask them. I did. I was operating under >>the assumption they did and that everyone must be discontent with Kinetics. >>When I finally figured out that they only support it for communicating to CAP, >>it made sense. FastPaths work very well in that situation. > >Ahem. IPtalk (as implemented by KIP) existed before Kinetics did. I recall >early implementations using the famous Stanford "Butcher-block" gateway. >When Kinetics started making gateways (based on the Stanford design), KIP >of course ran on it. For awhile, it was the only thing that ran on >that hardware. IPtalk actually predates Ethertalk! Atalkad is VERY ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Isn't that what I said? >useful because it allows us to centralize configuration and management. >When you have 40+ K-boxes out there, having users trying to configure things >is a disaster. Besides, they don't want the bother! Now if we could only get >the silly things to boot via TFTP or the like, we wouldn't need access to >Macs on the Localtalk segment at all! You just restated what I said about Kinetics. The Kinetics FastPath sprang from that Graduate Project which was the "Butcher-block" gateway. Kinetics was an offshoot to capitalize (financially) on it. I like the TFTP idea, maybe someone should start from scratch with some new ideas like that. >> >>If you are happy with UDPTalk, then you shouldn't be talking to me about scale. >>We were happy with UDPTalk when we were on a small scale, too. When you >>reach the limits of atalkad or don't want to spend $2500 per LocalTalk, you'll >>see it my way. >> >>Io hope people heed my warning. Many of you have probably read Dave >>Falkenburg's article on KIP/CAP. He was very pro-atalkad in that >>article. You should talk to him now (falken@caen.engin.umich.edu). If you >>read that article and found many good reasons to use atalkad and UDPTalk then, >>you should listen to me (or talk to Dave) and understand the reasons not to >>use UDPTalk now. >> >>We thought we had a great stopgap solution. We kept believing it until we >>had spent $100,000 on FastPaths. Then, within a few short weeks, we switched >>180 degrees and realize we had spent about $40,000 too much. I finally have >>a little peace of mind, too, knowing that our network will finally work right >>again. If you are unhappy with AppleTalk, maybe it is for the same reasons I >>was. > >There are more scale issues to worry about than numbers as well. How do you >manage the network anyways? Especially if you have to have users on the >net configure and load the K-boxes. The LBL KIP I use gives me stats on >error rates the K-box is seeing on the Localtalk and Ethernet sides. That's >not just gravy, we have found serious problems on localtalk nets thanks to that >feature. How do you know how bad off you are if the Kbox won't tell you >what it's seeing? We currently run atalkad. It is holding us back, but the Proteon software isn't available for about two months. We won't have users on the net configuring the K-boxes. It will be necessary to physically go to a box to reconfigure it, but we feel that is better than having Joe User set up his own box. Thankfully, K-boxes require little maintainance once they are set up (unless you are running atalkad, whih wreaks havoc on them) so we will only have a problem when we update the software on the FastPaths. Stats don't mean much to us. We don't really consider LocalTalk a viable networking scheme. We recommend EtherTalk as the lowest speed that is viable. > >We buy K-boxes anyways. We have about 40 now with no end in sight. People >wire things with localtalk and ethernet now. As long as you have localtalk, >you will have K-boxes, and as long as you have K-boxes, they ought to behave >themselves. It's true the LBL KIP has a few more configuration features >than the usual distribution. Some of these makes our life a lot easier in >larger environments. But the bottom line is still the same. We have a LOT >of network plumbing to talk to (more than most sites). All of it speaks IP. >I don't want to have to deal with seperate solutions for all the silly protocols >we have out there (3com, Appletalk, etc...). You can go nuts trying to >build seperate solutions for each special interest group. You can't support >7 things well even with a huge staff. By using standardized solutions, we >can provide excellent service to everyone who uses them, and that means the >folks who can do their work in using that environment will be better off than >those who don't. I'd like our Mac users to be on the right side. Apple's Internet Router is a fantastic way to join LocalTalks to a backbone. You can join two LocalTalks and a combination of 6 EtherTalks and TokenTalks with one machine which can also function as an AppleShare server. So LocalTalks and FastPaths don't go hand-in-hand anymore. 40 FastPaths and no end in sight? I can see and end. You will have to split your network into multiple networks or stop expanding when you reach 64 networks. I am kind of worried about having to run around to re-configure our FastPaths but we simply have no choice. We can't use atalkad anymore. We have a FULL table. > >I'm sorry IPtalk didn't work out for you. It's working quite well for us. Good Luck in the future with it, you'll need it. Keep me posted with what you do when you reach the 64 route limit of atalkad. -Steve