|
|
ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for March 1985 (48 messages, 33261 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Fri 1 Mar 85 09:24:03-PST From: Jake Feinler <FEINLER@SRI-NIC.ARPA> To: contr23@NOSC-TECR.ARPA Cc: feinler@SRI-NIC.ARPA, nic@SRI-NIC.ARPA, red@SRI-NIC.ARPA, ole@SRI-NIC.ARPA, cain@EDN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA Subject: DoD Reference Model
Paul, I would suggest that you check with Ed Cain, Chairman of the Protocol Standards Technical Panel to see what the status of the latest DoD Reference Model is. The work was being done (I believe) through that group with SDC participating. There is also a useful article in Computer Networks, Vol. 7, 307-318 (1983) by Cerf and Cain discussing the DoD Internet Architecture Model. The NIC would be glad to make such a document available if Ed agrees. Regards, Jake Feinler/NIC -------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Sun, 3 Mar 85 13:21:56 EST From: cadtroy!schoff@cadmus To: cadmus!tcp-ip@sri-nic Subject: tftp useful on localnets?
Does anyone use tftp? Do you find the security implications reasonable? In what situations do you normally use tftp? How many implementations are there of TFTP? I have heard of one for the IBMPC done by a university, one done by TWG for the IBMPC, one by Berkeley, another by TWG for VMS, another at Stanford for the MAC ...... Are there any more? Please respond directly to me and I will summarize if it seems resonable to do so. marty schoff@cadmus.ARPA
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Monday, 4 Mar 1985 12:41-PST From: imagen!geof@Shasta To: shasta!cadtroy!schoff@cadmus.ARPA Cc: shasta!tcp-ip@sri-nic.ARPA Subject: Re: tftp useful on localnets?
There are several TFTP implementations that I know of. Most are at MIT, where TFTP originated: - Three in CLU (two on tops-20, one on Unix4.1/BBN-networking) - Three in C (two on V6 Unix, (one ported to IBM-PC); one in 2K rom's for LSI-11 gateway's) - One in BCPL (on Alto) - One in PL/I (on Multics) There is also an implementation at ISI, on a tops-20. I think it is written in BCPL. Berkeley 4.2 comes with a version of TFTP, but I think there are some problems with the implementation. Uses: At MIT (this is 1.5 years out of date), we used TFTP for general file transfer between many machines (for a long while (perhaps still) it was the only protocol that was common to every machine the system's groups used, see above list). Also, it was used for netmail between a unix system and Multics. An Alto spooler program existed that received files in TFTP and sent them to the Dover in EFTP (a Pup protocol). The gateways used TFTP to netboot off one of a number of cooperating hosts. Many machines used TFTP to communicate with the line printer spooler on the V6 machine, and remotely print files. Performance: The best performance I can remember was between cooperating Vax 750's running 4.1 -- 200Kb/s. The V6/PDP-11 system could TFTP at the full speed of its filesystem - about 130Kb/s, so testing results were inconclusive. Typical results were in the range of 100Kb/s between most machines, with the exception of Multics and tops-20's. Both of these were on the Arpanet, which has 50Kb/s links. TFTP is a lock-step protocol, i.e., a protocol with sliding window flow control with a fixed window size of 1. The packet size is fixed at 512 data bytes per packet. TCP implementations should perform much better than TFTP implementations, since TCP allows use of larger packets and a greater degree of parallelism. A side note on this is that most TCP implementations average about the same transfer rates as the TFTP rates we saw from well-tuned TFTP implementations at MIT. Complexity: From the number of TFTP implementations there were at MIT, I hope that I convey the impression that TFTP is T (trivial) to implement, compared to TCP. I've brought up an implementation (although not the best implementation) in a day, from scratch to working code. Security: TFTP provides for none. This was not considered to be a problem at MIT. The server's were all set up to be willing to transfer any file if you gave a full name for it and it was globally accessible on the system. Since TFTP has no directory services, I guess this is a kind of capability protection system. The servers would only create a file if the lowest access user on the system could create it, and would not allow a file to be overwritten. On multics, user's had to explicitly expose their files to the tftp server. Typically, users send a file to a system by running a user process that uses their login priviledges to transfer the file to a public directory on that system. Then they login on the second system and move the file to where it is supposed to go. This is the same mode of operation as UUCP on most systems. - Geof
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Mar 85 11:08:52 EST From: cadtroy!schoff@cadmus To: cadmus!tcp-ip@sri-nic Subject: tftp implementation summary (long)
The following is a summary of responses to my request on tftp implementations.
I had asked this question looking to see how many people used this protocol
as a way to communicate with small machines. I was surprised to see it used
for mail and gateway loading...............
marty
schoff@cadmus.ARPA
{seismo,wanginst}!ucadmus!schoff
***************************************************************************
***************************************************************************
From: Charles Hornig <Hornig@SCRC-STONY-BROOK.ARPA>
Symbolics has implemented TFTP for the Symbolics 3600, mainly so we
could talk to IBM PC's.
From: Christopher A Kent <cak@Purdue.ARPA>
We find it very useful for two things. One is IBM PCs used for
classroom instruction (the code is from MIT) sitting on an ethernet.
THe other is for booting diskless staions -- they have a prom that
understands how to get the bootload from a host via tftp.
The security problems are not too bad -- we tightened up the server a
bit. If you're really paranoid, you can just make files in a certain
area accessible, and force users to put things there.
chris
----------
*****************************************************************************
From: gillies.osbunorth@XEROX.ARPA
Re: TFTP use. I used TFTP while at MIT (I was working in the group that
developed TFTP). We were developing Arpanet C programs for IBM PC's,
and writing and compiling C on a Vax running 4.2BSD. TFTP was used to
download software (extremely quickly, I might add), and was invaluable
because there are very few FTP's available for the IBM PC. FTP takes 2
connections, which highly complicates its implementation on a
single-tasking system. And, after doing some TCP benchmarks, I can say
that FTP for an IBM PC would probably have run much more slowly. I was
developing a multi-connection TCP for the IBM PC.
Doing cross development without TFTP would have been unbearably slow.
And to automate the debug cycle using FTP would have compromised a
computer password (because you must log in with FTP, which would have
been held in MS-DOS jcl files). It did necessitate that I make my UNIX
files "public access", but since our software is distributed publicly to
universities, security was not a top priority.
Don Gillies
*****************************************************************************
From: Rudy.Nedved@CMU-CS-A.ARPA
CMU CS/RI has it and uses it between small research computers like the
ones that control robot arms and some of the IBM PCs we have. It is
too insecure for us and in the future we may modify the protocol or
restrict what hosts can use it. It really needs to send USER/PASSword
down the line.
Rudy Nedved
Facilities Staff
Computer Science Department/Robotics Institute
Carnegie-Mellon University
*****************************************************************************
From: root%bu-cs.UUCP@harvard.ARPA (BostonU SysMgr)
I have used TFTP for one major reason, a workstation that only had
UDP/IP up. For that purpose I took a liberal reading of the RFC (it is
*very* liberal) and extended a filename to mean:
path\0user\0password\0
and modified the 4.2 tftpd to look for (demand) this and if found the
transfer fork would setuid()/setgid() and chdir() into the user's area
[and no longer demand that the pathname be root-relative]. Seems within
reason as I would not run the daemon at all w/o at least this much
security. The RFC seems to encourage such local extensions.
I like TFTP because on a local net with files it can be naturally buried
into applications (it is much more like a subroutine call than an
interactive utility like FTP) such as a print server (one can add 'print'
to the list 'netascii', 'binary', such an extension also is encouraged
by the RFC) where completely reliable transfers are not that critical
usually (just print it again.) The obvious extension would be to add an
XMODEM-like checksum to each block which would probably make it reliable
enough for general usage. When serious errors *do* occur though the
protocol is not very robust and will tend to just give up.
-Barry Shein, Boston University
*****************************************************************************
From: Glenn Gribble <GLENN@CIT-20.ARPA>
We have TFTP servers on 4.2 Vaxes, 4.2 Suns, and a Dec-20. We have user
programs on the Vaxes and Suns, a PDP11, and HP9836s. TFTP is usefull because
it is reasonably reliable and simple to implement. We had to rewrite the
berkeley implementation of TFTP since theirs was not correct. Security is
simply to the level of allowing only world-readable files to be read, and
only files owned by the TFTP server to be written (or a new file may be
created in a world-writeable directory).
glenn {@cit-20.arpa}
-------
*****************************************************************************
From: Bob Walsh <walsh@bbn-labs-b.ARPA>
We use TFTP for downloading the Butterfly here at BBN. We get speeds as
good as FTP over TCP, and speed seems to be limited by the share of the
CPU that the TFTP demon gets.
The Berkeley 4.2 tftp/tftpd are improperly written and do not conform to
the TFTP spec since the tftp conversation does not continue with the server
on a port != 69. Also, the code does not work well on multi-homed hosts
unless it is fixed to use unconnected system calls. I added another
security check: /etc/hosts.tftp is read on start up and upon "kill -1 ..."
This, combined with requirements of file existence and public read/write
should make for a reasonable and secure enough system.
bob walsh
*****************************************************************************
From: Bill Croft <croft@safe.ARPA>
Marty, I hope you will 'resummarize' when you get some responses
to your query. The Mac TFTP you speak of was done by Mark Sherman
of Dartmouth, NOT Stanford. Stanford just did the AppleTalk-Ethernet
gateway. Mark ported the MIT (IBM PC) TFTP to the Mac.
>
> My apologies! (marty)
>
Also, I suspect TWG (The Wollengong Group?) just has ported over the
Berkeley 4.2 BSD TFTP from UNIX to run on VMS under Kashtan's Eunice.
As far as security goes, I know another university (name escapes me
at the moment) has added a name/password scheme to the TFTP protocol.
This was done with a simple extension to the initial RRQ or WRQ blocks.
****************************************************************************
From: POSTEL@USC-ISIF.ARPA
Marty:
At ISI, TFTP is available on TOPS20, Unix (on 780's, 750's, SUNs),
IBM-PCs, Xerox Dandelion's (in Lisp and in Mesa), EPOS (on 11/40, 11/44),
Perq (Pascal).
--jon.
-------
****************************************************************************
From: imagen!geof@Shasta.ARPA
There are several TFTP implementations that I know of. Most are at MIT,
where TFTP originated:
- Three in CLU (two on tops-20, one on Unix4.1/BBN-networking)
- Three in C (two on V6 Unix, (one ported to IBM-PC); one in 2K rom's
for LSI-11 gateway's)
- One in BCPL (on Alto)
- One in PL/I (on Multics)
There is also an implementation at ISI, on a tops-20. I think it is
written in BCPL. Berkeley 4.2 comes with a version of TFTP, but I think
there are some problems with the implementation.
Uses:
At MIT (this is 1.5 years out of date), we used TFTP for
general file transfer between many machines (for a long while (perhaps
still) it was the only protocol that was common to every machine the
system's groups used, see above list). Also, it was used for netmail
between a unix system and Multics. An Alto spooler program existed
that received files in TFTP and sent them to the Dover in EFTP (a Pup
protocol). The gateways used TFTP to netboot off one of a number of
cooperating hosts. Many machines used TFTP to communicate with the
line printer spooler on the V6 machine, and remotely print files.
Performance:
The best performance I can remember was between cooperating Vax
750's running 4.1 -- 200Kb/s. The V6/PDP-11 system could TFTP at the
full speed of its filesystem - about 130Kb/s, so testing results were
inconclusive. Typical results were in the range of 100Kb/s between
most machines, with the exception of Multics and tops-20's. Both of
these were on the Arpanet, which has 50Kb/s links.
TFTP is a lock-step protocol, i.e., a protocol with sliding
window flow control with a fixed window size of 1. The packet size is
fixed at 512 data bytes per packet. TCP implementations should perform
much better than TFTP implementations, since TCP allows use of larger
packets and a greater degree of parallelism. A side note on this is
that most TCP implementations average about the same transfer rates as
the TFTP rates we saw from well-tuned TFTP implementations at MIT.
Complexity:
From the number of TFTP implementations there were at MIT, I
hope that I convey the impression that TFTP is T (trivial) to
implement, compared to TCP. I've brought up an implementation
(although not the best implementation) in a day, from scratch to
working code.
Security:
TFTP provides for none. This was not considered to be a
problem at MIT. The server's were all set up to be willing to transfer
any file if you gave a full name for it and it was globally accessible
on the system. Since TFTP has no directory services, I guess this is a
kind of capability protection system. The servers would only create a
file if the lowest access user on the system could create it, and would
not allow a file to be overwritten. On multics, user's had to
explicitly expose their files to the tftp server. Typically, users
send a file to a system by running a user process that uses their login
priviledges to transfer the file to a public directory on that system.
Then they login on the second system and move the file to where it is
supposed to go. This is the same mode of operation as UUCP on most
systems.
- Geof
****************************************************************************
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
TFTP is much used around here for booting things like
gateways, and also for talking to spoolers: it's nice and simple to
implement. Also, it's common for simpler machines (e.g. IBM PC's) to
have TFTP and not a full blown FTP, since it's so simple. Also, we use
it to bring new machines on the net; we get TFTP up and then ship the
source for everything else in via TFTP! Finally, it's used a great
deal in an 'rcp' (4.2ism) mode for simply getting a single file from
somewhere known: it's not limited to 4.2 machines like 'rcp' is.
We deal with the security problems by running TFTP servers
under a 'guest' (i.e. ANONYMOUS equivalent) ID; anything requiring
security stuff you FTP or TELNET to do.
MIT has TFTP for the UNIX V6 IP layer it has, and also has
TFTP for TOPS-20 (as does ISI). We have worked on the 4.2 ones to
make them work (better); at one point the Berkeley release did not
work according to spec. We also did the ICMPC version.
Noel
-------
****************************************************************************
From: John Leong <leong%CMU-ITC-LINUS@CMU-CS-PT.ARPA>
We (some sites within CMU) uses TFTP quite a bit for file transfer
between our PC and Unix 4.2 and TOPS-20 hosts over general purpose
LANs (Ethernet and ProNet). The software package we used ish
more liberal and more conservative-- by that, I mean:
1) We restrict tftp access to other hosts on the local ethernet, and
2) We liberalized the conditions for writing a file: whereas before the
file had to exist and be world-writable, we only require the normal Unix
world write conditions now: either the above, or a new file in a 777
directory, i.e. /tmp.
There were quite a few bugs in the 4.2 implementation which hve mostly
been fixed by now, by various people....
Geoff Cooper thinks that TCP ought to be faster, but I think you can
make a strong case that on a single local network a simple lockstep
protocol with fairly big packets can do just as well, or better, because
the "in transit time" is so short. If one tried tftp with 1K data
packets as 4.2 tcp uses, I bet it would beat it locally. Of course, one
should hack it so it's process-to-process and not to files in order
measure it accurately.
Actually, a tftp implementation on Tops-20 would be useful to us now,
because ftp is so #@*&!^%. Of course, localnets?
>
> edited by marty.
>
****************************************************************************
From: paul@rice
Marty:
I have written TFTPs for UNIX (4.1 Sys.10, 4.2 on VAXen and SUNs) and
VMS (with Phoenix), including some extensions to handle a more
reasonable mail protocol and remote command execution. They're
actually all the same program compiled with different flags. We use it
for file transfer, mail, remote command execution, and print spooling.
TFTP's lack of security is a problem, but not in the sense that we
worry about people stealing files. Rather, it is an annoyance for
users that they cannot read their private files with TFTP, nor can they
send files into their directories on remote hosts, as these are rarely
world-writeable. Also, I keep telling myself that one of these days I'm
going to add code to reject connection requests from outside Rice, but
I have much more enthusiasm for providing functionality than for
limiting it.
At any rate, TFTP is invaluable for us, as it is the only protocol that
some of our hosts have in common (such as IBM PC's and, one day soon,
Macintoshes).
Oh, to add to your survey, the CMU ITC wrote a TFTP for VM/CMS.
Unfortunately, it's incompatible with the WISCNet TCP/IP, which we use.
Paul
****************************************************************************
From: lepreau@utah-cs.ARPA (Jay Lepreau)
We used to use it quite a bit before TCP was avail on some of our
smaller machines, such as Apollos and PC's, and we still use it some for
that. It's easy to hack up a version fast. I made it much more useful
to us by modifying the security provisions in the 4.2 tftpd to be both
more liberal and more conservative-- by that, I mean:
1) We restrict tftp access to other hosts on the local ethernet, and
2) We liberalized the conditions for writing a file: whereas before the
file had to exist and be world-writable, we only require the normal Unix
world write conditions now: either the above, or a new file in a 777
directory, i.e. /tmp.
There were quite a few bugs in the 4.2 implementation which hve mostly
been fixed by now, by various people....
Geoff Cooper thinks that TCP ought to be faster, but I think you can
make a strong case that on a single local network a simple lockstep
protocol with fairly big packets can do just as well, or better, because
the "in transit time" is so short. If one tried tftp with 1K data
packets as 4.2 tcp uses, I bet it would beat it locally. Of course, one
should hack it so it's process-to-process and not to files in order
measure it accurately.
Actually, a tftp implementation on Tops-20 would be useful to us now,
because ftp is so fucked. Of course, on the Unix systems we
use rcp (and on the Apollos too).
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 1985 04:33-EST From: CERF@USC-ISI.ARPA To: CONTR23@NOSC-TECR.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Info on DoD protocol reference model?
Paul, there is a published paper on the DOD Architecture which was presented at a NATO conference late in 1982 (or early 1983?). Ed Cain and I wrote that paper. It is not as detailed as the SDC material. Mike Padlipsky has written several papers comparing the DOD and ISO reference models. Finally Jon Postel and Danny Cohen have likewise published commentary on this subject. Ed Cain may have reprints of the NATO articles - unfortunately I do not. If Ed does not have them, Bob Lyons at DARPA may have some since I remember sending mine to DARPA for their use. If not Bob Lyons, then perhaps Barry Leiner. Vint Cerf
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 1985 14:05 PST From: Art Berggreen <ART@ACC> To: dca-pgs@ddn1 Cc: info-unix@brl,tcp-ip@sri-nic Subject: RE: 1822 I/F for SUN
> Does anyone know if there is such a thing as
> an LH/DH 1822 Host-IMP interface for the Sun, whereby
> a Sun WS could interface directly to an IMP?
> I have a co-worker who asks me about this,
> and don't know what to tell him.
ACC makes an 1822 board for MULTIBUS. The board has the same basic
fuctionality of the LH-DH/11.
I personally don't know what machines have support for the board.
Contact ACC sales (not me please) for more info.
Art@ACC.ARPA
------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Mar 85 14:24:03 pst From: E. Howard Alt <alt%sri-lanka@sri-tsc> To: dca-pgs@DDN1.ARPA, sun-spots@rice.ARPA Cc: info-unix@brl.ARPA, sullivan@sri-tsca, tcp-ip@sri-nic.ARPA Subject: Re: Query - Host-IMP Interface for SUN?
There is an 1822 board for the Sun. Glenn Hastie (hastie@sri-spam) wrote a driver for it. ACC makes the board. I believe that the no one has actually tested the board hooking it up to an IMP, it has been tested with Packet Radio, though. Howard. PS it should work just fine -- the sun has all of the berkeley IMP software in it.
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 1985 1502-PST (Thursday) From: medin%ucbarpa@Berkeley (Milo Medin) To: dca-pgs@DDN1.ARPA Cc: sullivan@SRI-NIC.ARPA, tcp-ip@sri-nic.ARPA, info-unix@brl.ARPA, sun-spots@rice.ARPA Subject: Re: Query - Host-IMP Interface for SUN?
Uh... I dont think so. You really don't want to do this. If money is an object, build a fuzzball or something as a gateway machine that plugs into the IMP and have it output packets on the ethernet. That way you don't have to kludge up the sun and it'll offload the gateway functions onto the fuzzware... Milo
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 85 13:53 EST From: dca-pgs @ DDN1.ARPA To: sun-spots @ rice.arpa Cc: sullivan,tcp-ip@sri-nic.arpa,info-unix@brl.arpa Subject: Query - Host-IMP Interface for SUN?
Does anyone know if there is such a thing as an LH/DH 1822 Host-IMP interface for the Sun, whereby a Sun WS could interface directly to an IMP? I have a co-worker who asks me about this, and don't know what to tell him. Thanks, Pat Sullivan DCEC Reston, VA
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Mar 85 17:15:11 pst From: E. Howard Alt <alt%sri-lanka@sri-tsc> To: dca-pgs@DDN1.ARPA, medin%ucbarpa@Berkeley Cc: info-unix@brl.ARPA, sullivan@SRI-NIC.ARPA, sun-spots@rice.ARPA, tcp-ip@sri-nic.ARPA Subject: Re: Query - Host-IMP Interface for SUN?
Actually, I think it would be much cheaper to buy the 1822 board for a Sun (I assume they already have one and are asking if they can connect it up to the arpanet) than to buy the hardware for a fuzzball, or a normal gateway... unless they already have the right hardware laying around. Howard.
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Mar 85 21:57 EST From: Mike StJohns <StJohns@MIT-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: ISO TP-4 report.
Having just read the executive summary of the ISO TP-4 vs DOD TCP and not being at all familiar with TP-4 I have a few questions: 1) Is there any major problem in running TP-4 above DOD IP? (I.e. how much of a hassle would it be to run tp-4 in parallel with TCP?) 2) Like wise, how much pain and anguish would there be running FTP, SMTP, and TELNET above TP-4 (while still being able to communicate between disparate hosts via a gateway) (This seems to me to be about the same type of problem the net experienced when it converted from NCP to TCP) Mike
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Wed 20 Mar 85 02:08:22-EST From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: JNC@MIT-XX.ARPA Subject: Re: ISO TP-4 report.
This is a very depressing document, but it's not completely the fault of the NRC (although they did miss some extremely important points). I do understand their motivations for the switch in terms of using the same standard as everyone else. However, NBS and ISO lost incredibly badly. They came up with a design which is different but no better. I cannot imagine why, except to postulate a bad case of 'not-invented-here' ego gratification. To make the points the NRC missed, the most important one is precisely that the TCP/IP architecture is not mature. There are major problems yet to be tackled, and it will not work when scaled up. The NRC group points out that since the two protocols are so alike, the change will be easy. The flip side of that is that the switch won't fix any of the current deficiencies. What's even worse is that since the ISO thing is an international standard, changing it to fix the problems is going to be even more of a hassle due to the immense user base. Second, the NRC group is completely off base in its assement of the risks. They make the naive (at best) assumption that if there are performance problems it is in the implementation (page 21). They completely fail to address the possibility that performance problems may be inherent in the protocol architecture. This is actually just a specific instance of the general point above. Service performance levels in the network have still not really recovered to those of the NCP days. There are a variety of reasons for this, some inherent in the architecture and others of a transitory nature associated with the upheaval. Now, when we need to be devoting skilled manpower to examining the problems and attacking them, we will be forced to go through yet another upheaval, thereby draining the manpower needed for improvement as well as setting us back almost to ground zero on the honing of our implementations. One facet of the second point above is that one thing we learned from TCP is that conventional operating system structures do not mesh well with high-speed networks. However, we haven't really been able to capitalize on that yet; the common systems on the network (UNIX, TOPS-20) are dinosaurs. Once again, attacking this needs skilled people who will be sunk into a semi-pointless conversion effort. I wouldn't have minded converting to an international standard if we got some good new technical capabilities out of it. The painful (and in a much smaller system) NCP to TCP transition had that characteristic; TCP was radically more powerful. The claimed 'advantage' of the TP-4 switch, which is that the two are so similar, is precisely the largest disadvantage. Too bad standards committees didn't go on the B Ark. Noel -------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Mar 85 8:58:35 EST From: Alex McKenzie <mckenzie@BBNH.ARPA> To: tcp-ip@sri-nic.arpa Subject: Re Comments on NRC Report
I won't try to defend either TCP or TP4. I will comment on a few of the recent comments. 1) There should be no major problem in running TP4 above DoD IP. BBN, under contract to NBS, has done so (in a prototype implementation). However, my understanding of the NRC report is that the ISO "IP" (actually called something like "Protocol for Providing the Connectionless Network Service" - see RFC 926) should replace DoD IP at the same time TP4 replaces TCP. NBS has tried very hard to have DoD IP serve as the foundation for ISO IP, and in my biased judgement has mostly succeeded. 2) There should be no major problem running the higher-level DoD protocols above TP4, since (in my judgement) TP4 and TCP provide equivalent functionality. 3) Noel perhaps misunderstands the nature of ISO, and the NBS role. ISO, like any other group, has a certain amount of NIH syndrome - it would be naive to suspect otherwise. But the committees had large numbers of technical participants from manufacturers, trying to solve real engineering problems according to their best technical judgement. NBS participated in ISO via its participation in ANSI (i.e. NBS belongs to ANSI which belongs to ISO). NBS's mission (as I understand it) was to try to influence the formulation of ANSI (and by extension ISO) standards which meet government needs. One of the major contributors to NBS when it asked the rest of the government what its needs were was DoD, and the expression of needs, I think, was of the form 'we need what TCP provides'. Maybe that shouldn't have been so, I don't know, but given that it was it is a measure of NBS's success that TP4 lookes so much like TCP. Why isn't it a verbatim copy? I can mention at least 3 factors which in my opinion bear on this question. a. TP4 is intended to be one of a family of protocols satisfying different needs and making different assumptions about the network services underneath. So it should have a similar style of command names, field structures, etc. to the other members of the family (this may not be an interesting [or valid] objective, but it is not motivated by NIH.) b. Most manufacturers were unable to swallow the idea of intentionally sending into a closed window. They imagine their software will close a window because they really don't want to expend ANY resources processing input. Therefore the protocol needs a reliable way of announcing that a previously-closed window is now open. c. Most manufacturers were unable to swallow the concept of beginning a retransmission at any arbitrary byte boundary. The imagined that once the data stream had been fragmented into a given set of transmission buffers they would want to send AND RECEIVE retransmissions in those units. (Maybe they had heard of things like silly window syndrome?) They felt their implementations would have better performance doig thing this way. DISCLAIMER: I was involved in the development of NCP and TCP. My employer has a vested interest in TCP. For the past several years I have been the manager of a group which, under NBS contract, has participated in the ANSI and ISO committeees responsible for the development of TP4. Therefore I am probably unable to make unbiased statements about any of these things. Regards, Alex McKenzie
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Wed 20 Mar 85 13:03:58-PST From: C. Cutler <CUTLER@SU-SIERRA.ARPA> To: herb@WISC-RSCH.ARPA Cc: JNC@MIT-XX.ARPA, nrc-committee@WISC-RSCH.ARPA, tcp-ip@SRI-NIC.ARPA, CUTLER@SU-SIERRA.ARPA Subject: Re: ISO TP-4 report.
Well said, Herb. Tnx. CCC -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Wed 20 Mar 85 11:53:54-EST From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA> To: mckenzie@BBNH.ARPA, tcp-ip@SRI-NIC.ARPA Cc: JNC@MIT-XX.ARPA Subject: Re: Re Comments on NRC Report
It's quite true that you can look at any change and point out valid reasons for it; the change to variable length addresses has clear motivations and in fact TCP2 (how ancient!) had them. I could argue about some of the TP-4 decisions (especially the true cost of probing closed windows) but these minor technical points aren't the real issue. I also think the NRC underestimated the costs by quite a long ways, perhaps an order of magnitude. There are a lot more machines out there than they seem to think there are (page 32). They may have correctly figured out the cost to the DoD, but there are a lot more people using TCP. I guess the whole thing was a no-win situation. The result was actually about what some people have been predicting for a long time; given the circumstances, the result was predictable. The whole thing is schizoid; as you correctly point out, NBS should get some points for making sure the ISO didn't go off the deep end. However, it is also true that the change buys us little except compatability. Noel -------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Mar 85 13:52:26 cst From: herb@wisc-rsch.arpa (Benington Herb) To: JNC@MIT-XX.ARPA Cc: nrc-committee@wisc-rsch.arpa, tcp-ip@SRI-NIC.ARPA Subject: Re: ISO TP-4 report.
I'm sorry we depressed you but let me comment as an individual who was a member of the NRC panel, who entered the arena with relatively little knowledge of either DoD or ISO standards, and who works for an organization (System Development Corporation/Burroughs) which has very extensive activities in both standards. Your most challenging point is that the TCP/TP/IP architecture is immature, that "it will not work when scaled up", and that "conventional operating system structures do not mesh well with high-speed networks". Except for the issue of internetting and gateways, I can recall no evidence or opinions being presented to the committee which supported your point. I did sense that many members of the committee were concerned that DoD seemed to have placed little priority on measuring performance, on establishing standards and objectives for performance, and on defining an R&D program to improve and assess performance. However, I believe that the committee was satisfied that TP4/IP are mmature enough at this stage to support its recommendations for the following reasons: o Most of the committee members who work for or with large commercial vendors were well aware of the extensive experience of these vendors in developmental implementations of TP4/IP including integration of these implementations with commercial operating systems. The commercial vendors are well aware of the importance of performance and they work hard to achieve it (recognizing the high market demand for more functionality). o Most of these individuals and organizations participated in the ISO process which developed TP/IP and they contributed their own extensive experience with vendor specific protocols. I believe that there has been more protocol R&D associated with SNA, DECNET, DSA, BNA and others than has been conducted by ARPA. (Witness the eventual adoption of X.25 by DDN.) o The fundamantal purpose of the current ISO protocols is to facilitate interconnection of products from different vendors-- it is not to define protocols that will be universally used throughout each vendor's products. (IBM will put "open" protocols within SNA when it makes economic and architectural sense within SNA. It already has gateway products from SNA to ISO.) There is significantly growing demand for "openness" between vendors which will not wait for perfection. R&D must be continued, diverse applications must be experienced and evaluated, standards must evolve, but there is demand for standards now and suppliers believe they are ready to provide them. 1984 NCC was a major milestone in the development of the industry. Protocol maturity must be judged in the context of this climate: many vendors, much system software already developed and operating. I believe that protocol implementation (including integration with commercial operating systems) is the key factor now in achieving performance. I would be interested in specific arguments and evidence to the contrary. I mentioned above that the committee was well aware of some architectural and research issues associated with internetting and gateways. These present some tough issues but they don't seem central to transport and the internet protocol itself. You are concerned that much effort will now be diverted to conversion rather than R&D. The committee had many conversations about the DoD R&D program but it didn't attempt to crystalize some conclusions and recommendations. The DoD is and will be acquiring many data networking systems for operational (rather than developmental) applications. The committee unanimously felt that when it is appropriate to use TP4 in these systems, only commercially available, off-the-shelf implementations should be used--i.e., vendor standard products. DoD shouldn't spend any developmental resources to bring along the ISO products for its own use. Also, the report concludes that TCP communities and TP4 communities can coexist on common data networks. The DoD research community is now TCP based. If the DoD buys the report's recommendations, what should the research community do? Certainly it shouldn't spend its time developing TP4 implementations. In the near term, where standards are needed, TCP seems fine. In cases where major new R&D subnetworks are needed, ISO should receive strong consideration if the application needs commercial products and openness. For example, such a network could be used for the extensive simulations and gaming that are needed for the Strategic Defense Initiative. Finally, a comment on ISO and "not invented here". Alex McKenzie has done a fine job in commenting both organizationally and technically. I want to add two comments which don't conflict with his perspective: First, NBS did a valiant job of pushing for TCP. It wouldn't sell at the time because: Second, an international standards organization is often understandably motivated to want to treat equally all proponents. It's my understanding that in the 1980 time-period, the British, Germans, and the US all had proposals for transport layer protocols. Equity prevailed--hopefully, so did common sense. Herbert Benington
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Mar 85 13:59:25 EST From: Jim Berets <jberets@bbn-vax> To: info-nets%mit-oz@mit-mc.arpa Cc: tcp-ip@sri-nic.arpa, jberets@bbn-vax.arpa Subject: Intel ISO Transport product
I have heard that Intel is offering an ISO Transport layer product. Is this true? Can anyone offer any additional information? Please reply directly to me, as I am not on the list. Thanks, Jim jberets@bbn-vax
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Mar 85 15:02:35 cst From: lhl@wisc-rsch.arpa (L.H. Landweber) To: tcp-ip@sri-nic Subject: ISO TP-4
The following describes our ISO TP-4 implementation. Experiments to date indicate that, with the possible exception of the checksum algorithm, there is likely to be little difference in performance between mature TCP and TP-4 implementations. Furthermore, existing DoD applications will not be affected by the underlying transport protocol. More complete performance results will be available in about 3 to 6 months. We have implemented the NBS version of the ISO Transport Protocol - Level 4 (TP-4) for BSD 4.2 Unix. It resides in the kernel and interfaces down to IP and upward to the socket facilities the same way as TCP. We currently have SMTP, Telnet, FTP and rlogin working with it. Since the socket interface is the same, changing these programs to use TP-4 instead of TCP involved changing only one constant. The implementation is completely new and does not include any code from the NBS implementation. Currently our implementation supports connection establishment data transfer, disconnect and graceful close. We are in the process of completing expedited data. At present, it handles only the normal (7 bit) TPDU sequence space and always uses checksums. We have a joint project with MITRE Corporation to study performance of TP-4 in the Internet environment. The TP-4 software has been installed at MITRE and will soon be installed at a university Arpanet site. Larry Landweber (lhl@uwisc) Al Bricker (bricker@uwisc) Tad Lebeck (tadl@uwisc) Computer Science Department University of Wisconsin 1210 W. Dayton St. Madison, WI (608) 262 1204
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 1985 1021 GMT From: WIECLAWEK, JOE <JAW@JPL-MILVAX.ARPA> To: TCP-IP@SRI-NIC Subject: ISO TP-4
How can I obtain the "ISO TP-4 vs DOD TCP" report and other
TP-4 specs and info.????
Is it available by FTP ???
Thanks,
Joe
------
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 85 08:44:10 EST (Fri) From: Dave Farber <farber@UDel-Huey.ARPA> To: JAW@JPL-MILVAX.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: ISO TP-4
I gather that the report will be distributed as an RFP. In the meantime I have a LIMITED number of reproductions I can send desperate people. Dave
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Mar 85 11:54 PST From: Provan@LLL-MFE.ARPA To: tcp-ip@nic.arpa Subject: Why did ISO choose TP-4 instead of TCP?
I finally finished RFC942, the report on DoD transport protocols. I've got some comments on it that I'll wait a while to make, but one thing about the report struck me and I feel a need to comment on it separately. One of the major theses of the report is that TCP and TP-4 aren't significantly different. If they're so similar, why was TP-4 accepted over TCP as the OSI standard transport protocol? I've heard a little mumbling about this or that being a little better, but the differences outlined in the report seem to favor TCP in my eyes. TP-4 reminds me of NCP. The flow control by segment comes immediately to mind. I'm too young to remember the TCP design days, but I assume they had good reasons based on experience and experimentation to reject the NCP segment flow control in favour of the byte oriented control. But anyway, we have these two basically equivalent protocols. One has many implementations on several operating systems, the other isn't even a final protocol yet and already has variations. Why would even consider using the second one as an international standard? Well, the first explanation we hear is that the Europeans don't like to admit that the Americans can do things better, so they had to claim it was bad and redo it. That probably has a lot to do with it (although *I* certainly have no interest in using a protocol based on those grounds), but it doesn't explain why there's so much American support. The second explanation that occurred to me was that it was a communist plot. No, really, it makes a lot of sense that the Soviet Union would want the United State's Defense Department to spend millions of dollars unnecessarily to develop more network code. Obviously I was beginning to clutch at explanations. But I can't shake the third explanation that occurred to me. Look at who's on this committee: DEC, IBM, AT&T, CDC, and Honeywell. I don't recognize *any* name from Internet discussions. Well, I suppose I should be honoured that they're all so interested in what protocol we use, but anytime a bunch of corporations all agree on something, it must be because they want to sell me something. Sure enough, after thinking a little it seemed obvious: the only reason we're being convinced to change to TP-4 is that they can't sell us anything if we continue using TCP. Look at DEC: if they came out with a TCP implementation for VMS and sold it for $80k, who'd buy it? The Wollongong code it much cheaper and probably better. IBM is in even more trouble, since it doesn't have a significant number of machines on the Internet to begin with, and those are PCs with third party TCP software. Is this true with the other three? AT&T doesn't get anything for the UNIX TCP implementation, does it? If these companies are really just interested in a standard, why didn't they implement TCP years ago? If someone could give me *any* good arguments for adopting TP-4 instead of TCP, I'd love to have my mind changed. But when I see things like required fields of variable length and NBS arbitrarily adding graceful close in defience of the standard, little flags go up telling me something's not hip with this protocol. When I hear rumours that DEC and IBM and all the European phone companies are duking it out in ISO committees to get as much of their protocols as possible, no matter how shabby, into the standard, I lose confidence. Now they're telling us that it's obvious that we should adopt a suite of protocols that are 5 to 10 years behind in design and development from the one we're using. And the best feature they can mention is that the only protocol level that's anywhere near completion is equivalent to the matching level in our protocol. Who are they trying to kid? Sorry for flaming off. I was really excited about the entire OSI effort when I first heard of it, but now I'm disappointed and angry. I feel like I'm being sold a bill of goods. I'm sure there are lots of qualified, confident people trying hard to produce a good protocol suite, but I'm convinced that these protocols are being designed with goals in mind other than that of making a good set of protocols. don provan
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 1985 13:50:39 PST From: POSTEL@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: re: TCP vs TP4
The US should use TP4 for the same reasons the US uses all the other International Standards. Like the Metric System, like the Centigrade temperature scale, like A4 paper, like 220 volts, like.... --jon. -------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Mar 85 19:32:25 EST From: bellcore!karn@umd5 To: umd5!tcp-ip@nic.ARPA
Subject: TP-4
Don, your second explanation may not be so far fetched. The USSR *does*
sit on the ISO, and I'm sure they took considerable pleasure in their
role in causing the DoD to spend millions to convert to TP-4 instead of
funding research on Star Wars. (Then again, given the way things are,
I'm sure the money won't come out of the existing DoD budget.)
I am very puzzled and confused by the whole TP-4 thing. In amateur packet
radio we recently went through a very similar trauma. Somebody came
up with a different link level protocol and insisted that we convert to
it. We heard him out and concluded that his protocol worked fine, but since
it was functionally equivalent to what we already had, a conversion would
be pointless. It is not too late for ARPA and the DoD to do the same thing.
Has anyone sat down and written a detailed, technical, side-by-side
comparison of TP-4 vs TCP? The only difference which I've become aware of is
byte-vs-packet sequence numbering, something I think favors TCP.
The industry press is getting a lot of mileage out of this thing, much
of it consisting of hype and misinformation ("TCP/IP's days are numbered!
Berkeley Unix's days are numbered!"). Many people who are not familiar with
the field are taking this to mean that datagrams are on their way out, since
ISO has long stood for uprightous VC protocols like X.25.
Phil
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 85 2:36:51 PST From: donwinter.pasa@XEROX.ARPA To: POSTEL@USC-ISIF.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: TCP vs TP4
Touchy, touchy, . . . .
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Mar 85 14:17 EST From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> To: POSTEL@USC-ISIF.ARPA, donwinter.pasa@XEROX.ARPA, TCP-IP@SRI-NIC.ARPA Subject: re: TCP vs TP4
Date: 22 Mar 1985 13:50:39 PST
From: POSTEL@USC-ISIF.ARPA
The US should use TP4 for the same reasons the US uses all the other
International Standards. Like the Metric System, like the Centigrade
temperature scale, like A4 paper, like 220 volts, like....
That's one of the most enlightened observations I've seen on this
subject yet! (Seriously!!)
Date: 23 Mar 85 2:36:51 PST
From: donwinter.pasa@XEROX.ARPA
Touchy, touchy, . . . .
But can you blame him??
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 85 18:18:18 PST From: DonWinter.pasa@XEROX.ARPA To: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> Cc: POSTEL@USC-ISIF.ARPA, donwinter.pasa@XEROX.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: TCP vs TP4
Jon has obviously never had to carry with him the array of plugs and transformers neessary to run my contact lens sterilizer on international travel. 220V is NOT a standard. Why should the US NOT join in the International Standards? As long as this doesn't imply that we end up with a centralized PTT.
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Mar 85 19:22 PST From: Provan@LLL-MFE.ARPA To: tcp-ip@nic.arpa Subject: Comments on RFC942
I've finally finished rfc942, so now I'm ready to comment on it. Y'all sure are fast readers. I'll try not to duplicate the comments I made in the previous note, but some of the points have application here. First of all, this entire report is based on the assumption that the OSI is going to be the wave of the future and the NBS protocols are going to be right up there surfing it. I hear this over and over from the people involved in OSI work (so much that I'm starting to believe it), but I still haven't heard much more than yawns from anywhere else. And just the simple question of the graceful close versus the sudden abort makes me wonder what NBS has to do with OSI. Is the idea that this is such a trivial difference that manufacturers are going to have one version of their software for NBS believers and another for all the others? This issue really has me confused. The report often says that if only DoD would jump on the bandwagon, everything would get done licketysplit. DoD has been on the TCP bandwagon for several years now, yet there isn't universal vendor support for TCP. I'm only aware of one situation (TOPS-20) where TCP is supplied by the manufacturer that sells the operating system. I see no difference between this state of affairs and the OSI IP. It'll be the same network trying to get it produced. Why waste time on that if we can get TCP vendor supported? Well, the real answer is we can't get either supported, probably. And my experience tells me that a user will probably be unable to insert his own network layer in a vendor supplied TP-4, so the TP-4 implementations will probably be useless to DoD until OSI IP is implemented. All we'll accomplish is to waste as much time implementing TP-4 as we spent implementing TCP in the first place. I love the cavalier attitude the committee takes toward the unspecified addressing format. Sure it'll be good enough. Of course it will handle the DoD networks. Well, unless they limit the number of networks or the number of hosts or don't allow a protocol field. But I suppose NBS will ignore any difficulties here in the same way they added graceful closes. Nothing like an international standard, eh? I think it's ridiculous to claim that OSI will satisfy DoD's needs. Routing is a perfect illustration. ISO hasn't even begun to do anything concerning routing. A lot of work has been done in the Internet. What are these people supposed to do? Continue developing gateway protocols and then throw them all out like TCP when ISO comes out with its standard? Or just stop working on the problem until ISO comes up with it? I don't think the Internet can wait 5 or 10 years for that to happen. If the Internet continues on the course it's taking now, in 5 years we'll be done with routing and be off solving new problems that the ISO will just be realizing exist. We can't just stop and wait for ISO to catch up. And if they're so intent on ignoring work done in the Internet, we can't really be expected to work along with them, either. Another point the report makes is that DoD has very special requirements that the rest of the world doesn't have. I think this is a bogus point on two counts. First of all, the DoD requirements are quantitative, not qualitative. It's not that other networks don't require reliability, for example, it's just that they don't need to be reliable during a nuclear attack. Other networks need to handle sudden surges in loads, too, just not as sudden or as great as the load on the military nets when the first missles are launched. I look at it like military quality micro-chips: the military chips don't do anything different, they're just more likely to do it correctly under fire. In other words, the DoD requirements are a question of implementation, not of the protocols used. Secondly, for any given point in the past, the DoD requirements have merely been a few years more advanced than anyone else's. A few years ago, DoD had a requirement to hook many hosts together when noone else did. They went out and made a network that could do it. Nowadays, everyone needs to hook many hosts together. Meanwhile, DoD has developed a need to communicate across many networks, requiring an IP level protocol along with all the stuff that people are working on now. It doesn't take much of a brain to realize that most other networks will need the same ability in the near future. Many universities already depend on it. It's blatantly obvious that DoD must be the leader in the network field. That's why the ARPAnet was established. It can't afford to follow someone else, especially a body with the kinds of delays ISO has. In fact, the ISO can't afford not to follow the Internet, although they obviously don't see it that way. Finally, who *are* these people trying to sell us this line? I don't recognize a single name as having a pratical knowledge of the Internet. But I do see DEC, IBM, AT&T, CDC, and Honeywell. Does anyone on this committee, or in any of the ISO committees, have any experience with multi-vendor networks? If there's one thing I've learned working on the Internet, it's that the best way to deceive yourself about the quality of a network implementation is to test it against itself. Once you start trying to work with other implementations, it's an entirely different ball game. What does DEC or IBM know about that? They're the *worst* people to judge what will make a good multi-vendor transport protocol.
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 85 23:18:44 EST (Sat) From: mrose@UDel-Dewey.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: Re: TCP vs TP4
Gee, I thought the whole point of internetting was to let heterogeneous networks communicate. Why don't we just build some gateways instead of converting to TP4? If the claim is made that protocol translation isn't advanced enough as a technology, then this is a good opportunity to start doing research in it. I don't know about you guys, but this business about "you can have any car you want as long as it's a model-T, and any color you want as long as it's black" begins to wear thin after a while in an area where inter-operability is the name of the game. /mtr
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 85 01:00:05 EST From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: support for TCP/ISO
There is probably at least something to the argument that vendors will support the ISO protocols better than they support TCP. I am trying to hook all of our campus machines together using TCP. I find that a number of the vendors I talk to regard TCP as temporary, and are putting their work into ISO. DEC seems to have a commitment to support ISO. They are trying to make sure that TCP support is available for their major machines, but trying not to do any more than the bare minimum needed. I have heard (but more indirectly -- I don't have any close contact with IBM) that IBM's attitude is similar. Intel and Prime seem to be ignoring TCP almost completely, but are doing ISO support. Indeed my major problem with the proposal is that it seems to be unrealistic in its view of the short-term. The report says, in effect, that TCP is now in reasonable shape, so we can afford to continue using it until ISO is developed by vendors. I'm not sure that my experience supports that. Here are the results of attempting to use TCP on all of our systems: - VMS. This is probably in the best shape, though for some purposes the DEC-20 implementation is better. - Unix. This works, too. Telnet connections have incredibly high overhead, which is a serious problem for us. - DEC-20. This is in fairly good shape. We are seeing a number of crashes due to TCP support, but it should be possible to fix these. - IBM MVS. No implementation of TCP for Ethernet currently exists. Several are on the horizon, but we have been sitting here in "just another 2 months" since last summer. - Prime. No implementation of TCP for Ethenet currently exists. There may be an implementation for X.25. Prime seems to be concentrating on ISO, or at least such is the rumor. - Intel. Intel themselves seem strongly committed to ISO. It seems to be possible to get TCP from third parties, but we haven't yet. Even if we do, it may not talk to our other TCP's because of the Ethernet/IEEE incompatibility. By the way, I am being charitable in saying that VMS, Unix, and DEC-20 have TCP implementations at all. None of them generates "sync" when clearing terminal output, nor do they negotiate binary on when going into a program such as EMACS. Unix has adopted the incredible strategy of implementing these features using a different, but incompatible protocol (RLOGIN), even though the facilities to do it are present in the Telnet protocol. The DEC-20 appears to generate the DM part of the sync, but not the Urgent. As we don't have source for Wollongong, we can't tell what is wrong there. This is not a terribly encouraging situation. I certainly wouldn't want to sit in this situation for a few years, waiting for ISO to take over the world. -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Sun, 24 Mar 85 16:30:30 est From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> To: tcp-ip@sri-nic.csnet Subject: Re: support for TCP/ISO
I too am trying to hook all our campus systems together using primarily TCP. Adding a few more vendors: IBM/VM - Two implementations each with their merits (Spartacus/WiscNet), quality not yet known [we are putting up both right now, hardware is in, software mostly in] DG:AOS/VS - They are testing the software here, seems very promising and I *certainly* believe DG is serious about supporting TCP/IP native. AT&T 3Bx - Rumour has that AT&T has a contract in progress to host TCP/IP under SYSV (very strong rumour -- I believe it's almost done) 4.2bsd - certainly many vendors (including DEC/ULTRIX) supporting this for their systems (eg. SUN.) IBM/PC - Fusion has an implementation (I have never tried it) Cray (II) - I believe their intention is to support it (?) Added into the comments by Chuck, I find the sum of the same to be very encouraging. Yes, there are a few bugs and misfeatures. I think the purpose of the 4.2bsd RLOGIN protocols had more to do with a new (un-RFC'd) security scheme allowing login to 'equivalent' hosts without passwords rather than the similarities it had to telnet (remember, most importantly RLOGIN was part of their RSH and REXEC() scheme of remote execution and multi-host, user-easy extension of pipes.) You add all of these vendors together and I believe you're talking 'reasonable' TCP/IP support for what? 97% of the systems out there? How far off could I be? What's missing? MVS (serious, but yes, there are projects out there), PR1ME and, and...? Atari? Apple? Harris? I think that unless we have a mass exodus (read: mass hysteria) away from TCP the bugs will get fixed long before ISO is running. The only major hole I see is a DEC supported VMS TCP. Now DEC is supporting TCP on TOPS-20 and ULTRIX, how much would users really have to hammer on them to convince them to do it with all three systems that could do that (I assume RSX, RSTS and RT11 to be effectively dead and a non-issue, users of those systems will live with whatever can be scrounged together.) I think we just have to convince DEC of the obvious: That DECNET (like SNA) is a wrong thought and we will *never* buy it, period, so they stop holding out hoping someday people will 'see the light' and start screaming for DECNET. I personally suspect that DEC will one of these days just bless the Wollongong TCP/IP for VMS (whatever they call that, 'Approved Vendor' or some such.) -Barry Shein, Boston University
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Sun, 24 Mar 85 20:24 EST From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> To: DonWinter.pasa@XEROX.ARPA, David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> Cc: POSTEL@USC-ISIF.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: TCP vs TP4
Date: 23 Mar 85 18:18:18 PST
From: DonWinter.pasa@XEROX.ARPA
Jon has obviously never had to carry with him the array of plugs and
transformers neessary to run my contact lens sterilizer on international
travel. 220V is NOT a standard.
Why should the US NOT join in the International Standards? As long as
this doesn't imply that we end up with a centralized PTT.
Sigh... I'm all in favor of supporting a good, usable, featureful,
standard. Jon's comment was about the arrogance of the US, which I
found to be a healthy and refreshing dose of cynicism (and/or sarcasm).
[The US isn't the only country with arrogance; I'm told speaking English
in certain parts of France will get you nowhere.]
Admissions: I implemented TCP for the Symbolics 3600 and I know a
moderate amount about IP. There are glaring problems and deficiences,
so the only reason I am in favor of supporting them is because everybody
else does (modulo TP-4 on the horizon). I have not read the TP-4
document, nor will I in the near future. I have skimmed these discussions
and have the following, mostly non-technical, comments to make:
* I think it would be great to have an international, good, usabable,
featureful, standard.
* TCP/IP fails in the good and featureful aspects, in my opinion. (TCP
has several advantages to the upper levels of the CHAOSNET protocol,
but CHAOS routing has several advantages to IP routing.)
* TP-4, as gleaned from the discussion, is mostly TCP with
modifications to make even more people happy. (My opinion of TCP is
that it was designed by a committee where any feature anybody wanted
was put in, regardless of worth or value. By saying "more people
happy" for TP-4, I mean that the committee is international instead
of national and therefore prone to yet more randomness.)
* TP-4 seems to have a bit of arrogance itself about it; namely "TCP
wasn't good enough, so we fixed it up. <Rude noise.>"
* I've seen comments about address formats (or lack thereof). Hell,
bite the bullet, go to 64 bit addresses and come up with a
hierarchical (like the mail domain system (with its problems fixed,
of course) subnet routing scheme with redundant paths that WORKS.
The first 16 bits can be a country code, the next 8 can be a type of
customer (commercial, university, government, etc), the next 16 can
be a super-group (e.g., which company, which university, which
government branch) and the last 24 bits (accidentally the same size
as the company-flexible part of Ethernet addresses) be allocated
within the super-group.
If even half of this is true, I expect TP-4 does not differ in any
profound ways with TCP, and therefore it is not good nor featureful. The
ONLY reason to convert is because "everybody else is using it and it is
no worse than what we have now" and not because "it is obviously the
right thing". That in itself should be persuasive enough for the US
to convert.
For the record, here are some of my complaints about TCP/IP:
* Last I knew, IP routing does not support redundant routes.
Therefore, the graph of gateways is acyclic (the IMPs are cyclic, but
as far as IP is concerned, the collection of IMPs is ONE gateway) and
any gateway going down segments the network. [Maybe I'm just
confused.]
* I think SYN and FIN taking up segment space is a bit silly.
* I think RST packets should contain textual data which is the reason
for the reset.
* I think FIN should contain textual data which is the reason for
closing.
* I would like to get rid of these silly port numbers. A request (SYN)
should have a symbolic contact name that identifies the service,
e.g., "TELNET", "SUPDUP", "FTP", "TFTP", "NAME", etc. The port
number slot gets recycled into local-index. See the CHAOSNET
protocol.
* I think the urgent pointer was not thought out well. The ONLY
application I know of for this is TELNET, and I don't know who uses
it these days. (One version of the 4.2bsd TCP implementation
actually treated urgent in the lowest levels, regardless of the user
side, and treated it wrong, I think.)
* There should be an in-sequence out-of-band provision; ASCII
terminals have a BREAK key, CHAOSNET has an EOF packet. TCP has an
urgent pointer, but that is an out-of-sequence out-of-band signal,
i.e., a subsequent urgent supersedes previous ones.
* Adaptive retransmission is one order of magnitude harder than
on-the-ball people think it is, and two orders harder than the TCP
spec implies. Sorry, I don't have any solutions. I've thought about
it for a long time and every scheme is meta-stable. At a minimum, I
think the problem, even if it can't be solved, is wothy of a master's
degree, which, in theory, means more thinking than anybody has yet
given to the problem.
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 85 10:09 EST From: dca-pgs @ DDN1.ARPA To: tcp-ip @ sri-nic.arpa Subject: IBM-Supported TCP/IP for VM - Reforwarded
Comment: Forwarded message(s): ----------------------------------------------------- Received: from su-shasta.arpa by SRI-NIC.ARPA with TCP; Thu 27 Dec 84 10:04:47-PST Received-2: from imagen by Shasta with UUCP; Thu, 27 Dec 84 10:05 PST Date: Thursday, 27 Dec 1984 09:27-PST To: shasta!TCP-IP @ SRI-NIC Subject: "TCP/IP for VM Systems Available Commercially" From: imagen!cpr @ su-shasta.arpa Text: FYI, the following article appeared in the latest CSNET News, Fall, 1984, No. 6, and is reprinted without permission in its entirety (please, someone at the CIC let me know if this is Bad Practice): "IBM has formally announced that it will market the software known as ''The VM Interface Program for TCP/IP,'' developed jointly by IBM and the University of Wisconsin. With this software, IBM VM hosts can connect to CSNET X25Net and use the ARPANET/DoD protocols for mail, file transfer, and remote login. Previously, the software was available to universities and colleges only, as the ''WISCNET'' package. (See CSNET News, No. 5.) "The VM Interface Program for TCP/IP provides the following functions: - An implementation of the standard DoD protocols TCP and IP under VM/SP Release 2 or 3. - File transfer to and from remote sites using file transfer protocol (FTP) - Electronic mail to remote sites using the VM NOTE facility as an interface to simple mail transfer protocol (SMTP) - Remote terminal login using the TELNET protocol "Sample programs are also provided for the Series/1 EDX system, Series/1 RPS system, or Device Access Control Unit to support interfaces to local area and packet-switched networks, including ProNet, Ethernet, and X.25. "There is a one-time chare of $17,000 for the software. "If you would like more specific information about the net TCP/IP interface software, please contact your local IBM sales representative and refer to Availability Notice G320-9219." -------------END OF FORWARDED MESSAGE(S)-------------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 85 11:11 EST From: dca-pgs @ DDN1.ARPA To: root%bostonu.csnet @ csnet-relay.arpa, tcp-ip @ sri-nic.arpa Cc: dca-pgs @ DDN1.ARPA Subject: Vendor Support for TCP/IP (MVS and Others)
For IBM/MVS, a 3rd-party vendor, Network Solutions Inc., provides installation and product-level support with the public-domain DARPA/UCLA TCP/IP networking package, using ACC hardware at the networking level. If that sounds like a funny way to do business, not to worry...it's the same thing Wollongong does, and that seems to work all right. I don't know if the package has an Ethernet driver&hardware available or not, but that would appear to be an easy fix. The DDN PMO has awarded a contract to Network Solutions and ACC to interface "1 or more" MVS/TSO systems to Milnet. By the way, we do have a MVS host here at DCEC connected to Milnet with the UCLA package; I think there's a total of 5 connected to Milnet & Arpanet at present. The DDN PMO has awarded interface contracts (based on TCP/IP) for other machines: CDC, Honeywell, Sperry, and IBM VM. It should also be noted that CDC, Sperry, and Burroughs have made public commitments to support TCP/IP-based interfaces as a DoD requirement (which it still very much is). A real good source of this kind of info is the TCP/IP Implementors & Vendors List, FTPable from the NIC under log anonymous pathname: <netinfo>tcp-ip-implementations.txt If someone is not on Milnet or Arpanet and wants a copy, I'll E-mail them one. I'm afraid that the NAS report may have greatly underestimated the installed investment in TCP/IP. Best, Pat Sullivan DCEC, Reston, VA.
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 85 12:57:41 EST (Mon) From: Mike O'Brien <obrien@CSNET-SH.ARPA> To: imagen!cpr@SU-SHASTA.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: IBM-Supported TCP/IP for VM - Reforwarded
No problem. CSNET allow reprinting of anything in the CSNET News so long as proper credit is given.
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Mon 25 Mar 85 17:59:23-PST From: Francine Perillo <PERILLO@SRI-NIC.ARPA> To: dca-pgs@DDN1.ARPA, root%bostonu.csnet@CSNET-RELAY.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Vendor Support for TCP/IP (MVS and Others)
Better yet, if you cannot FTP a copy of the TCP/IP Implementations and Vendors Guide, the NIC will mail you a pretty hardcopy. Send your requests to NIC@SRI-NIC. -Francine Perillo -------
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 1985 17:24-EST From: John Leong <leong%CMU-ITC-LINUS@CMU-CS-PT.ARPA> To: tcp-ip@nic.arpa Subject: TP-4
Whether TCP is a good protocol or not, there is all likelyhood
that it will be supported by a lot of manufacturers as a
standard. The reason can be found by tracing the history
of the ISO standard. ISO themselve did not really do any
development as such. Of the different TP's, TP0 comes from
CCITT and the rest, including TP-4, is heavily influenced by
ECMA (European Computer Manufacturers Association).
The composition of ECMA is quite interesting. Besides a
collection of European companies like Philips, Siemen, ICL,
Olivette, Ericsson, etc. the rest are composed of all the
US companies such as IBM, DEC, etc. Since TP-4 comes out
of this group (after more than 3 years of effort), the
implication is that all the major US companies will at least
not against it if not actively supporting it.
Realistically, however, TP-4 implementations will unlikely to
become offical product for most companies within the next few
years - unless there are some explicit incentives (e.g.: DoD
insists that all suppliers must have TP-4). Most companies will
likely to be busy doing other more financially rewarding
things such as interfacing to SNA's latest child - LU6.2 (boring).
In the longer term, it looks like it will fly : even if it is
yet another designed by committe protocol.
An interesting observation is that while both TP-4 and X25 are
ISO protocols; TP-4 does not have as strong a clout as X25.
X25 comes from CCITT and defines the network interface. Since
networking is PTT (government) monopoly in Europe you must play
by the rule or you dont play at all ... and even IBM have to
comply. Since TP-4 is an end-to-end (ISO level 4) protocol,
that is a different story.
leong
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 26 Mar 1985 08:35-EST From: CERF@USC-ISI.ARPA To: Provan@LLL-MFE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Why did ISO choose TP-4 instead of TCP?
Don, To add to your observations, there are fairly good indications that the major vendors have already or are in the process of putting together TCP/IP implementations for their commercially available operating systems. I do not mean that they are expecting to sell these products to the general public, but they do plan to sell them to DOD, at least, because this is what DOD has asked for and is willing to acquire. In general, DOD benefits from using supported products - the maintenance for which the vendor picks up the tab. These TCP/IP products will be supported, so far as I know. there is even one vendor who is planning to make TCP/IP an internal standard. Since this information is privileged, I cannot say which vendor. If the primary argument for adopting TP-4 is that it will be supported as a product by the vendors, this may be less a consideration today than it was even a year ago, given vendor initiatives and DOD initiatives to acquire or arrange implementations. There remains the international standard argument, interoperability with NATO. This is still a strong political argument for which I do not know of a good counter-argument since the NATO countries are, indeed, relying on the ISO protocols, as untested as they are. I do not agree with the recommendation of the committee that the US DOD should adopt TP-4 as a co-standard. My more cautious view is that one should wait until commercially available implementations are available and then test them. The TP-4 is still in its infancy and is likely to change, just as X.25 has changed rather a lot since 1975. It is hard to adopt a moving target as a standard, it seems to me. Vint
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Wed, 27 Mar 85 14:51 EST From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP vs TP4
Hell, throw in the english to russian automatic translator. It can't be any harder than X.400-SMTP.
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 27 Mar 85 11:22:18 BST From: Robert Cole <robert@ucl-cs.arpa> To: TCP-IP@sri-nic.arpa Subject: Re: TCP vs TP4
Whilst your out there hacking interoperability gateways I would like a SNA/DECNET gateway, TCP-IP/XNS gateway, TCP-X25 gateway, TELNET-X.29 gateway, SMTP-X.400 gateway etc, etc.... Robert Cole,
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Thu, 28 Mar 85 00:38:46 EST From: Tom Hutton <hutton@seismo.ARPA> To: tcp-ip@sri-nic Cc: hutton@css-s3sun Subject: imp interface for gould powernode series
Im not sure if this is the proper list for this item but I thought I would start here. I have a Gould powernode 6000 series system on order and have been trying to figure out if it can support the required interface to an imp. So far Ive gotten conflicting responses from Gould reps, and the documentation also conflicts. Its supports goulds version of 4.2BSD, and it mentions the imp in several manual pages but dosent go into details on the sync interface to the net routines. Anyone have any experience with these systems. Thanks, Thomas Hutton
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Thu, 28 Mar 85 13:37:50 EST From: Mike Muuss <mike@BRL-TGR.ARPA> To: Tom Hutton <hutton@SEISMO.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, hutton@CSS-S3SUN.ARPA Subject: Re: imp interface for gould powernode series
Tom - I have a Gould PN 6080 here on the network (BRL-SEM). However, it is attached via an Ethernet to one of our local gateways. At present there is no way to attach a Gould machine to an IMP; however, we plan to help Gould develop an HDH interface using an SCM board; don't expect this to be availible until Q3 or so. -Mike
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 29 March 1985 1057-PST (Friday) From: stanonik@nprdc To: tcp-ip@sri-nic Subject: domain name resolvers
The last schedule for implementing domains (RFC921) set 15 May 1985 as the date to begin significant use of resolvers. Are any resolvers available for 4.2bsd Unix? Thanks, Ron Stanonik stanonik@nprdc
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Fri 29 Mar 85 12:33:22-PST From: C. Cutler <CUTLER@SU-SIERRA.ARPA> To: mike@BRL-TGR.ARPA Cc: hutton@SEISMO.ARPA, tcp-ip@SRI-NIC.ARPA, hutton@CSS-S3SUN.ARPA, CUTLER@SU-SIERRA.ARPA Subject: Re: imp interface for gould powernode series
-------
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 29 Mar 85 16:07:22 EST (Fri) From: Mike O'Brien <obrien@CSNET-SH.ARPA> To: stanonik@NPRDC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: domain name resolvers
I think it's cute that we're supposed to start using this stuff soon, but RFC 883, which is the Grand Master Specifier for all this stuff, carries a big fat warning-in-a-box that it's preliminary only, and no one should try to implement anything using it for a spec. Does anyone "authoritative" (pun intentional) have anything to say about this?
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 30 Mar 1985 14:50:35 PST From: POSTEL@USC-ISIF.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: domain name resolvers
Two different domain name resolvers were developed and experimented with for Berkeley Unix. The DRUID system was developed by Peter Karp at Stanford University. The BIND system was developed by Doug Terry at Berkeley. The Unix support group at Berkeley is preparing a major revision of the BIND system for inclusion in the next release of Berkeley Unix. These systems (both DRUID and BIND) are not just the resolver, but include servers as well. --jon. -------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Sat, 30 Mar 85 12:12 EST From: Charles Hornig <Hornig@SCRC-STONY-BROOK.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: domain conversion
Can anyone offer guidance on the question: "When can I start using my domain-style mail address (Hornig@Stony-Brook.SCRC.Symbolics.COM) in mail headers sent to the ARPANET?" RFC 921 does not seem to mention this topic.
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 31 Mar 85 14:55:53 EST (Sun) From: Dave Farber <farber@rochester.arpa> To: dca-pgs@ddn1.arpa Cc: root%bostonu.csnet@csnet-relay.arpa, tcp-ip@sri-nic.arpa Subject: Re: Vendor Support for TCP/IP (MVS and Others)
I have tried to be quiet but.. The NAS committee did not operate under the impression that the installed investment in TCP was not great. If we had, we would have opted for different recommendations. We understood and I believe stated so that there was a large base there. HOWEVER, the argument made is that much of this software is special systems produced not part of the normal commercial line of software products and as such is and must be more expensive than normal products of a vendor. Many of us believed that the adoption of international and national standards (please remember that ISO TP4 is the draft Federal standard as published by NBS) will in the long run make for a lower cost and better more widely available products. Dave
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Sun, 31 Mar 85 14:21 IST From: Henry Nussbacher <vshank%weizmann.BITNET@WISCVM.ARPA> To: <tcp-ip@sri-nic.arpa> Subject: An analogy
On a planet far far away - in a time long long ago... There were two groups - one called the Eups and the other group was known as the Mericos. The planet they lived on was called Urth and there were no seas or oceans, only land. Neither group knew how they got there but when they did, the entire planet was crisscrossed with railroad tracks. Some Mericos decided one day to build a railroad train that would run around the entire circumference of the planet. As the Merico train passed small towns and villages other Mericos would put wheels on their houses and hook up to this very long train that had formed. As time went by, the train got longer and longer. All the Mericos had long since coated the wheels of their homes with rubber and had installed shock absorbers to their homes so as to minimize the jarring effects of riding railroad tracks for months on end. Life was good. Suddenly, the railroad train passed through Eup country. Since this was an open-ended train and discrimation did not exist, the Eups decided they too would like to connect to this worldwide train. But they said, "Why do you need rubberized wheels and why do you need shock absorbers?" So the Mericos said, "We have been living on this train for 2 years now and without it life would be intolerable!" Well the Eups didn't find the answer suitable enough. So they said, "We will join your train but we will not install rubberized wheels or shock absorbers. And since we think we know a little more than you, we want all of you to remove your shock absorbers and your rubberized wheels since they really are not needed." The Mericos complied and the Eups joined in. After a month of riding on this worldwide train, the Eups called a meeting. They said, "We have analyzed the recent vibration problems on the Urth train, and have the following recommendations to make. One - every house should coat their wheels with high impact plastic. Two - every house should install shock absorbers under their house." The Mericos asked, "But isn't that the way it used to be? Didn't we tell you we knew better from experience?" The Eups refused to listen and ended the meeting. Nowadays, the worldwide Urth train winds its way across the planet and all houses connected to it are quite happy. Morale: Everything has a way of working out right. It's just the road getting there that is bumpy. Hank
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |