Andrew-Birner%ZENITH.CP6%LADC@BCO-MULTICS.ARPA (Andrew Birner) (07/13/88)
We are testing the waters of TCP-IP, before jumping in with both feet;
unfortunately, the water looks rather murky from here, and we'd like to learn
a bit more about the bottom conditions before taking the plunge. Our VAX
system manager, Mark Shumaker, has asked me to submit the following for
comments, suggestions, and/or flamage; e-mail replies may be directed to me at
the reply-to address for this message, which should be:
<Zenith/A_Birner%LADC@BCO-MULTICS.ARPA>
Please do not direct replies to the address shown as sending this message, as
there is a one-way pipe in the path (a regretable political necessity).
==============================================================================
{At the risk of starting another war....}
We have a VAX-11/780, a VAX-8650, and a varying number of PC's and
clones networked; DECnet has been our primary (and only) network
product. Now we need access to some other environments: Prime
2250/Primos (Ugh!), Honeywell DPS-66/CP-6 (Yay!), and possibly
Mentor/UN*X (---!) systems. The common networking scheme for
all these suckers is TCP/IP. Our (the Systems Manager's) intent
has been to put together a subsidiary TCP/IP network which
will allow transfer of files from the Prime, Honeywell, and Mentor
to the 780 (our network control and file server node), with the PC
and 8650 users then having DECnet access to the files. There are
no current requirements for anything other than file transfer
on this subsidiary network.
One of our more vocal users is promoting the thesis that TCP/IP
should be our primary (indeed, only) network product. I need to
investigate this further. Can anyone help me with:
1) I keep hearing horror or war stories about interoperability
among different implementations of the TCP protocols, even
with the basic FTP and TELNET. At the TCP/IP pre-symposium
seminar at Anaheim '87, the speaker said that some user
patching of TCP code would most probably be required in
heterogeneous multi-vendor networks to assure interoperability
(paraphrasing). Can anyone comment on this matter, particularly
since in at least one of our environments, the vendor will
not disclose source code?
2) Does anyone know of a product (hardware, software, or both) that
acts as a DECnet-to-TCP bridge? This looks like it should be a
fairly simple thing to do, at least for the 'basic' protocols,
but then I don't plan to do it myself so it *should* look easy...
3) Can anyone put me into contact with the System Manager at a
multi-vendor TCP/IP site (both hardware and software from dif-
ferent sources, preferably including Prime, VAX, PC's, and at
least one other) which is running satisfactorily and which did
not have to do major modifications to the TCP code?
4) We are using DECnet utilities for:
a) File transfers from PC to PC, VAX to VAX, PC to VAX, VAX to PC.
b) Virtual disk partitions on the VAX for the PC's for working
storage, for archiving PC data, and for backups of PC data.
c) SETHOST scripts imbedded in .BAT files in the PC's to allow
the PC users to perform certain actions in the VMS environment
without necessarily being aware that the process is not on the PC.
d) Transparent File Access functions imbedded in C programs in the
PC's for getting directories, files, and data from files on
remote nodes (PC and VAX).
e) In development are Transparent Task-to-Task applications that
run on the PC's and communicate with a process on the VAX.
f) Remote print and plotter outputs to computer-room devices.
What are our chances of finding reasonably bug-free TCP software
for the VAX and PC's which will allow us to continue these usages?
5) I have heard some bad reviews of the Wollongong TCP/IP VAX product,
and that some (unnamed) University has a much better one. Can
anyone comment on the status of VAX TCP implementations? And is
VMS V5 supposed to have one?
This looks like quite a lot of questions, but the matter is serious
to us and I want to do justice to the investigation. I will be
grateful for any assistance, suggestions, or comments. Post them
here, or mail them to me, or contact me directly at (312) 391-7908.
Thank you.
Mark Shumaker
Zenith Electronics Corp.
==============================================================================
- Andy -hedrick@topaz.rutgers.edu (Charles Hedrick) (07/15/88)
We use both DECnet and TCP/IP. (Indeed I wrote the DECnet code for the cisco gateways, and also do a lot of TCP/IP software work.) I no longer feel quite as strongly about TCP/IP's advantages as I used to, though I'd still choose it in most situations. What it mostly comes down to is this: If you have a moderate size network, particularly with a fairly simple topology, and you are willing to lock yourselves into DEC, then their network products work very well. (Indeed in many cases DECnet is noticably easier to configure than IP, though part of that is because any single-vendor system is easier to deal with than a multi-vendor system.) Otherwise, you should use IP. I see the comparison as follows: DECnet: It is fairly easy to configure. It is well-integrated into the VAX system, so some remote system management stuff is much easier to do, and remote file access is more transparent. It is generally cheaper. This is the up side, and is generally sufficent for small institutions that are locked into DEC, or into combinations that DEC supports (e.g. DEC and IBM). For the down side: DECnet routing tends to be slightly unstable. In many configurations it doesn't matter, but I have heard reports from a site that has many overseas lines that routing changes cause a cascade of routing broadcasts that makes life very unpleasant for a while. I have also heard a report from Berkeley that having many routers on a single Ethernet causes trouble, because the hellos synchronize, and produces spikes of broadcast traffic that can exceed the capacity of some Ethernet controllers to handle. Another problem for large configurations is that 16 bits is not enough address space. There are several national or international DECnet networks. Their growth is limited by the availability of area numbers. A given machine can talk to at most one such network. If your campus wants to be involved in more than one, you'll probably have to do some sort of ad hoc partition of your routing. DECnet does not have some of the robustness features of IP, e.g. the ability to deal with packet corruption. (This should not be an issue, as serial lines are done on top of DDCMP, which does good error control. But in large networks, you really do want end to end error control.) And obviously DECnet will tend to lock you into DEC. The specs are public, and there are now implementations for various other systems. But you'll still probably find yourself using DEC routers, terminal servers, etc. (By the way, LAT is particularly noxious in this respect. The protocol for it is not public. This means that even other vendors that support DECnet do not support LAT. So I recommend avoiding LAT even in networks that use DECnet.) IP: The up side of IP is that just about everybody supports it, or at least can point you to a software house that does. It seems to have a wider variety of services available (finger, rwho, etc.). Its mail systems tend to be designed to handle more complex configurations. (Interfacing DEC's mail system into an environoment with DECnet, IP, and BITnet is always a real trip.) Some of the newer services seem to have no equivalent on DECnet, e.g. the network file system. I haven't heard or X or NeWS over DECnet, though I'd think DEC might have an X over DECnet for its VMS-based workstations. The community of people who are doing interesting projects in workstation system software seems to be working mostly with IP. IP is designed to handle very large and complex networks. 32 bits of address space is enough for the next few years. The downside is in many ways the converse of the upside. Because it is supported by many vendors, and because it is designed for complex networks, you have more chance that vendors' implementations will not communicate, and more setup options. In general interoperability is much better than it was 5 years ago. I haven't had to fix bugs that caused interoperability problems for several years. The main remaining problem is that not all implementations support subnets, and as a corrollary they may not agree on a broadcast address. This can be solved, as the new implementations can be set to use the old broadcast address, and commercial gateways use proxy ARP to deal with implementations that don't understand subnets. However you do have to know something about your implementations, so it complicates setup. Setting up IP is a bit more complex, because routing isn't as automatic. There is no standard routing protocol. (There is one that most people implement -- RIP -- but it isn't an official standard.) This means that you have to think about your routing design. Once you know what you are doing, it's easy to set up machines, but it does mean you have to spend time figurng out the technology and deciding how to use it in your case. The serious IP gateways have a zillion setup options. However a DECnet router does too. I think they're about comparable in complexity. However they tend to be used in different cases. The complex IP gateway options are normally used when you are setting up a network that connects many organizations with differing routing strategies and contraints about who will talk to whom. To answer your specific questions: (1) I doubt that patching is needed these days, as long as you get current, supported software. (2) The smoothest DEC/IP bridge is an Ultrix system with software intended to do just that. However any machine that has both DECnet and TCP/IP can act as a bridge if you don't expect too much. (3) We are probably a good reference site, but you might be better off finding a place that has used Ultrix's DECnet/IP gatewaying software. (4) I think you can find IP software that will do what you are doing, but I'm not sure you'd find the changeover worth doing. I'd add IP to a reasonable set of machines, and start using it for new things, but I'm not sure I'd erase all my DECnet software. In particular, I'd modify your proposal by putting IP on the 8650 also, and one at least one PC just so you can play with it. There are a number of IP implementations for the PC, so you should talk to someone who knows more about them. (5) We still use Wollongong for VMS. They have gotten a lot better recently, and are now aggessively following the latest Berkeley technology. Ideologically pure solutions sound real neat, but probably aren't the best in the long run. DECnet is just fine for the machines it supports, particularly in a small network. Unless you have to spend a lot of time administering it, there's no reason to remove it. But if you depend solely on DECnet, there's a lot of good technology you won't be able to use. The IP community is a lot of fun, gets you a lot of flexibility in a number of directions, but it also takes a commitment of time to learn the technology.
gkn@M5.SDSC.EDU (Gerard K. Newman) (07/17/88)
From: hedrick@topaz.rutgers.edu (Charles Hedrick) Subject: Re: Questions on TCP-IP (vs. DECNET) Date: 15 Jul 88 06:20:12 GMT Organization: Rutgers Univ., New Brunswick, N.J. DECnet routing tends to be slightly unstable. This is true to some extent, in that a serial line attached to (say) a DECSA router can cause lots of triggered routing updates on an ethernet. But I've also seen some amazingly unstable routing caused by unstable serial lines on IP gateways. Interfacing DEC's mail system into an environoment with DECnet, IP, and BITnet is always a real trip. Yes, it is, although there is some very good software out there which will do just that. My 4 protocol mail gateway (DECnet, IP, BITNET, and MFENET) handles about 5K messages per week with very little non-automated attention. Some of the newer services seem to have no equivalent on DECnet, e.g. the network file system. I haven't heard or X or NeWS over DECnet, though I'd think DEC might have an X over DECnet for its VMS-based workstations. DEC markets a product called DFS which is a distributed file system, but it isn't really based on DECnet. Likewise, the VAXcluster file system isn't based on DECnet, but it too is a distributed file system. DECWINDOWS is DEC's X-Windows product which supports X11R2 on top of DECnet. It is not yet out of field test. gkn ---------------------------------------- Internet: GKN@SDS.SDSC.EDU Bitnet: GKN@SDSC Span: SDSC::GKN (27.1) MFEnet: GKN@SDS USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138-5608 Phone: 619.534.5076