matt@nanovx.UUCP (Matt Brandt) (02/19/89)
I think the problems (other than the node limit) are overstated. Be reasonable. On a large internet you might have a hundred or so bridges. The broadcasts made by bridges to each other aren't really all that big a burdon (100 packets every ten seconds?) The node address aquisition isn't as bad as it is made out to be either. Typically an appletalk station remembers it's last address so that when it boots it tries that one first. You end up with a pretty static set of node ID's after a very short while (the first time all of the stations are active at once). From then on you just have a little extra fault tolerance in that if the address happens to be aquired by a new node you don't get a catastrophic failure when you try to bring up your node. I think this is much better than the standard ethernet practice of having the node number statically assigned. The node limit is being addressed by allowing multiple LOGICAL appletalk networks to co-exist on the same PHISICAL ethernet. This ups the node limit to 65526 * 253. No real bridging is needed to communicate to a seperate logical net. The station just notices that it is on the same wire and sends the packet directly. AppleTalk is generally much better thought out than most other protocols. The only problem is that it was thought out as a small nework solution. Thats what you get when you try to solve a problem (large networks) with the wrong solution (AppleTalk). I think it does a pretty good job considering...
leres@ace.ee.lbl.gov (Craig Leres) (02/21/89)
Matt Brandt writes: > I think the problems (other than the node limit) are overstated. Be reasonable. > On a large internet you might have a hundred or so bridges. The broadcasts > made by bridges to each other aren't really all that big a burdon (100 > packets every ten seconds?) A "background" broadcast rate of 10 pps is not reasonable. Sustained broadcast rates over 1 pps prevent diskless Sun workstations from booting. Also, the 36K packets per hour use up an unreasonable amount of resources on every station on the ethernet. > AppleTalk is generally much better thought out than most other protocols. The > only problem is that it was thought out as a small nework solution. Thats > what you get when you try to solve a problem (large networks) with the wrong > solution (AppleTalk). I think it does a pretty good job considering... Well, I'll grant you that AppleTalk is certainly "much better thought out" than EtherTalk (or than Sun's diskless boot protocol for that matter). Craig
wnn@dsunx1.dsrd.ornl.gov (W. N. Naegeli) (02/22/89)
Craig Leres writes: > A "background" broadcast rate of 10 pps is not reasonable. Sustained > broadcast rates over 1 pps prevent diskless Sun workstations from > booting. Also, the 36K packets per hour use up an unreasonable amount > of resources on every station on the ethernet. I am not a network protocol expert, but it appears to me that one of the principal problems with EtherTalk is that it uses broadcasts where multi- casts would do. If broadcasts were used only initially and then multicasts were used at perhaps a somewhat longer interval than the present 10 seconds I believe all the complaints I hear from other network users would go away. If "EtherTalk II" or whatever they'll call it also alows logical networks on the same cable we'll get increased flexibility in addition to a practi- cally unlimited number of node addresses. I am looking at AppleTalk as a cost-effective general-purpose solution for small and medium-size networks rather than for high performance or huge networks. Above all, AppleTalk needs to be a good citizen on existing networks. Currently it really is somewhat of an 'enfant terrible,' but blaming it for problems experienced for users who are even less well behaved, notably the diskless SUN workstations that hog network resources, is inappropriate. Sure, the idea of diskless workstations is great, but they should either use their own Ether cable or use a medium with much higher bandwith. It's really a solution for the future that doesn't match very well with the network technology of yesterday. Wolfgang N. Naegeli Oak Ridge National Laboratory wnn@dsunx1.dsrd.ornl.gov (128.219.96.46) (615) 574-6143
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (02/22/89)
Peter, I am sorry. I flamed all over you when I shouldn't have. I wish I knew exactly who at Apple to flame over, but I probably shouldn't do that either. At any rate, I will endeavor to be more polite and instructive in future as all good netnewsers should be. The even-tempered Mr. Hedrick gave the proper, reasoned response that I should have given in the first place. Please study his article carefully. wnn@dsunx1.dsrd.ornl.gov (W. N. Naegeli) mentions multicast. Of course, multicast would be an excellent way to lessen the broadcast load on the Ethernet. AppleTalk and IP could benefit from widespread implementation of multicast. Backward compatibility holds up the process. Perhaps AT has a chance to make some progress in this area? In summary, my points were: 1) AppleTalk needs much work before it will scale up well. 2) TCP/IP needs much work before it will plug and play easily. (I wish that was all I had said the first time.) Kent England, Boston University
desnoyer@Apple.COM (Peter Desnoyers) (02/22/89)
Just a final word on this whole flame war (I promise) - You can say anything you like about AppleTalk and I won't mind - I may well agree with you - just as long as you don't blame me for it. Sorry if I got touchy about that in previous postings. Peter Desnoyers
koehn@cat24.CS.WISC.EDU (Bradley Koehn) (02/23/89)
I have what may or may not be a relief to the problem, if not a solution. Why not run Appletalk through both serial ports? This way, you could dedicate one port to exclusive local traffic (printing, file servers, etc.), anduse the other for global traffic (global servers, company-wide email, etc.)? I realize this would not solve the node-limit problem, but it could significantly reduce traffic without the overhead of bridges, and still remain compatible with current Appletalk equiptment. Brad Koehn, U of W Madison "Fly like an Emu!" DISCLAIMER: My thoughts and opinions are just that. Mine.
leres@ace.ee.lbl.gov (Craig Leres) (02/23/89)
W. N. Naegeli writes: > I am not a network protocol expert, but it appears to me that one of the > principal problems with EtherTalk is that it uses broadcasts where multi- > casts would do. If broadcasts were used only initially and then multicasts > were used at perhaps a somewhat longer interval than the present 10 seconds > I believe all the complaints I hear from other network users would go away. Unless all the ethernet interfaces you're using have hardware support for multicasts, I'm afraid you're out of luck. Do you want to limit yourself to DEC hardware? Or perhaps go promiscuous and check EVERY packet to see if it's the multicast you've been waiting for? In any case, multicasts don't fix anything, they just help you the hide bad side effects of a poorly designed protocol. A large DECnet network uses a great deal of ethernet bandwidth just doing "background" multicasts. Remember that multicasts are really a special kind of broadcast and any protocol that does a lot of broadcasting is broken. ARP is about the only protocol I can think of that uses broadcasts without abusing them. Even so, if enough other things go wrong, you can still have ARP broadcast storms. If you have great interest in the Multicast Religious Wars, please check out the comp.protocols.tcp-ip archives. > I am looking at AppleTalk as a cost-effective general-purpose solution for > small and medium-size networks rather than for high performance or huge > networks. Above all, AppleTalk needs to be a good citizen on existing > networks. Currently it really is somewhat of an 'enfant terrible,' but > blaming it for problems experienced for users who are even less well behaved, > notably the diskless SUN workstations that hog network resources, is > inappropriate. Sure, the idea of diskless workstations is great, but they > should either use their own Ether cable or use a medium with much higher > bandwith. It's really a solution for the future that doesn't match very well > with the network technology of yesterday. Based on my experience here at LBL, I must disagree with your remark about diskless Suns. They do not hog network resources. Of the bandwidth used on our main ethernet segment, most is taken up with "background multicasts for LAVC and DECnet. Perhaps you misinterpreted my comment about diskless Suns not being able to boot when the broadcast rate exceeds 1 pps. The problem here is not that Suns need a lot of bandwidth when they boot. Instead, it's that the Sun rom boot code gets confused if it receives an unexpected packet during a one second window. Craig
liam@cs.qmc.ac.uk (William Roberts) (03/21/89)
I agree that 10 packets per second is too many - the bridges
should not need to send that many RTMP packets; even one every
10 seconds is rather too frequent for my liking.
I'm mildly worried by the "logical net is same physical net"
suggestion, which sounds OK, but needs thinking through
carefully. The key question is
How can you TELL that another node is on the same logical net?
The wrong answer is "use ARP"; this will generate a lot of
unnecessary ARP traffic, especially when talking to things like
LaserWriters which aren't on the Ethernet cable, but you'd use
ARP just in case they were.
A better method would be to extend the RTMP protocol to
indicate that two logical nets were actually the same - then
sophisticated nodes could work out the routing for themselves.
They'd probably have to anyway - it would be grotesque for a
bridge to broadcast routing information on every LOGICAL network.
There is also the question of how a node discovers its network
number - if this is done dynamically by broadcast on the local
physical network, how is a node to work out which LOGICAL net
it belongs to?
The basic idea is worth thinking about, but it will take a lot
more thinking... especially if you don't want to wreck the
otherwise fairly neat AppleTalk setup. I have always thought it
a brilliant insight that nodes and networks don't need numbers
unless there are others to be distinct from!
--
William Roberts ARPA: liam@cs.qmc.ac.uk
Queen Mary College UUCP: liam@qmc-cs.UUCP
190 Mile End Road Tel: 01-975 5250
LONDON, E1 4NS, UK Fax: 01-981 7517