Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!cincsac.arc.nasa.gov!medin
From: medin@cincsac.arc.nasa.gov (Milo S. Medin)
Newsgroups: comp.protocols.appletalk
Subject: Re: UDPTalk as a backbone
Message-ID: <31353@ames.arc.nasa.gov>
Date: 5 Sep 89 07:22:55 GMT
References: <1989Sep3.063402.22872@caen.engin.umich.edu> <31297@ames.arc.nasa.gov> <1989Sep4.202733.6326@caen.engin.umich.edu>
Sender: usenet@ames.arc.nasa.gov
Reply-To: medin@cincsac.arc.nasa.gov.UUCP (Milo S. Medin)
Organization: NASA Science Internet Project Office
Lines: 96

In article <1989Sep4.202733.6326@caen.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes:

>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
>any other way to do name lookups.  And name lookups ARE a good idea.  They
>offer possibilities that other networking systems can't offer.  I think
>Apple's interface to name lookups is poor, but their implementation is sound.
>I think the broadcast problem is overrated, though.  With increasing processor
>speeds, the amount of overhead in receiving a broadcast not meant for you is
>becoming academic.  And a little work on ethernet cards can make it so NO
>processor time is needed to reject broadcasts.  We can't stay static with the
>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.
>
>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.

>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
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!  
>
>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 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.  

I'm sorry IPtalk didn't work out for you.  It's working quite well for us.

						Thanks,
						   Milo