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: <1989Sep6.173858.24519@caen.engin.umich.edu>
Date: 6 Sep 89 17:38:58 GMT
References: <1989Sep4.202733.6326@caen.engin.umich.edu> <1435@intercon.UUCP> <1989Sep5.193002.15583@caen.engin.umich.edu> <4727*kenw@noah.arc.cdn>
Reply-To: billkatt@caen.engin.umich.edu (billkatt)
Organization: Computer Aided Engineering Network (CAEN), University of Michigan
Lines: 97

In article <4727*kenw@noah.arc.cdn> kenw@noah.arc.CDN (Ken Wallewein) writes:
>
>  I've been watching this discussion on IPTALK/UDPTALK with considerable 
>interest.  We are a relatively small site, with a half-dozen K-box 4s and 
>maybe a couple of dozen TCP/IP nodes.  We have the K-boxen set up to run
>EtherTalk and IP/UDPTALK, and have interesting times getting uShare and 
>NCSA Telnet and PacerLink to coexist peacefully.  We do not run CAP at all.
>
>  So.  Having established our interest in the matter, could somebody please
>try to summarize what this argument has been about?  There's been a lot of
>assumption of context.  As far as I can see, there's:
>

>Six good questions to answer...  Answered below.

>  One of you went to all-IPTalk/UDPTalk, and one went to all-EtherTalk. It's
>still not clear to me what constraints and capabilities prompted either
>decision.  For the sake of the less experienced among us: summarize, please. 
>
>
>/kenw

Good idea.  I'll try to summarize what we're arguing about and why I take my
side.  BTW, I went all EtherTalk.

  We have differences about which protocol to use as a backbone.  There is
EtherTalk, which is a close relative to LocalTalk with its use of broadcasts
and the like.  Another possibility is UDPTalk (or IPTalk, different names,
same thing) which does things in a generally more IP-ish way.

  a) EtherTalk routers broadcast too often.  Actually, all AppleTalk routers
     broadcast a lot.  FastPaths even broadcast RTMP packets onto their
     Ethernet in UDPTalk.  I agree with the statement that no one has proven
     this a problem.  I would also like to note that I think there are a lot
     more NBP lookup broadcasts than RTMP broadcasts on any AppleTalk network.

  b) UDPTalk give better stats, agreed, but I don't agree that it scales better.
     I will say that it definitely doesn't scale worse.  Scaling does matter
     in large installations, especially if ethernet is used as a backbone
     instead of something faster.  We really don't need the stats, since our
     IP router can provide the info.  We usually hear of flakey networks
     immediately, anyway.

  c) UDPtalk is quite flakier, especially around here.  I'm not sure why.
     Theoretically, it should work as well as EtherTalk.  I have no one to
     blame, since we are using atalkad with K*STAR, which Kinetics doesn't
     support.  Most of our boxes stay up for months, but some don't.

  d) UDPTalk is a lot more expensive.  I used to think it was such a big deal,
     since large installation have large budgets.  Now I'm not so sure.  The
     lower costs of EtherTalk can make it available to more Departments within
     the University here (see below for more info).  It doesn't have
     commerical support, although Kinetics finally mentions atalkad in their
     manual for the first time in a recent revision.  They still don't support
     it, though.

  e) Who cares who made the first box?  Not me.  They've progressed a lot
     since then, anyway.

  f) Routing, bridging, etc. This is a big subject.

First, you can't mix and match.  You can use EtherTalk/LocalTalk together
freely unless you use UDPTalk as a routing medium (i.e. atalkad)
You can run EtherTalk/LocalTalk and UDPTalk (with atalkad) together,
but only in parallel.  All networks and routes must be supplied by the
administrative host (atalkad) if you have IP subnetting.  Additional routes
will not propagate, since RTMP (which is updated with new routes) broadcasts
from boxes with additional (non-supplied) routes will not be received from
across IP gateways.  Because of this, every router must be a FastPath or
GatorBox.  In addition, atalkad has an inherent limitation of 64 total routes
(networks).  This becomes a big factor in large installations.  There is a
debate over wether atalkad could be modified to support more routes.  I've
looked into it, and it looks difficult, but could be possible.  I'll let the
fact that no one has done it speak for itself.

I'll agree that some FastPaths are necessary, to allow LocalTalk machines to
run NCSA Telnet (IP in AppleTalk to IP translation), but argue that using
FastPaths exclusively is something to be avoided because of cost.  As a side
note, I figure Apple's internet router will support this translation soon.

I'll try to outline the experience here with UDPTalk.  We started out on
UDPTalk because it was the only way to connect our LocalTalk networks
together via our existing networks (and with any kind of speed).  Now that
we are using EtherTalk as our primary network medium for Macs (instead of
LocaTalk), we are unhappy with the slow speed and restrictions.

We currently have 61 networks (routes) on one of our two AppleTalk internets
here at U of M.  We are blocked from going any further because of atalkad,
and would like to be able to use more cost-effective routers on our network.
This had lead us to change our backbone to EtherTalk from UDPTalk.  We still
use UDPTalk for CAP, but it is no longer viable for us as a backbone.

I would like to point out that we still use UDPTalk as our backbone for
approximately two more months, until the software enabling us to run AppleTalk
on our Proteon backbone becomes available.

-Steve