The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for April 1985 (86 messages, 46161 bytes)
NOTICE: recognises the rights of all third-party works.


Date:      1 Apr 1985 10:18:35 PST
To:        tcp-ip@SRI-NIC.ARPA
Cc:        sunshine@USC-ISIF.ARPA
Subject:   Reply to some NRC report flamers
I would like to reply to just a few of the most outrageous statments
appearing in this bulletin board on the recently released National
Research Council report on use of ISO protocols by DOD.

First, to get my background up front, I was a member
of the committee.  For the past two years I have been with private
industry in a small company (Sytek) that makes broadband local
network equipment.  Prior to that I spent three years at ISI, 4 years
at Rand, and several years at Stanford with Vint
Cerf, all working on the Arpa Internet, and helping desing TCP
and IP, so I am probably considered biased toward DoD protocols.

Provan at LLL-MFE asks "who are these people ... I don't recognize a single
name as having practical knowledge of the Internet"
I have already given my credentials.  Other committee members were
Larry Landweber of U. Wisconsin, a founder of CSNET, and Dave Farber
of U. Delaware, a longtime user and contributor to internet.  We were
also advised by Jon Postel, Ed Cain, Phil Selvaggi, Col John Lane, and many
others in DoD.  I am sorry if Provan does not recognize any of these names.

Provan also accuses ISO of ignoring the good work done in the Internet
community.  There are many complexities to this question, but part of
the problem has been the Internet community's lack of enthusiasm to
contribute and "sell" its work to ISO.  Nonetheless, many of the ideas
have indeed found there way.  The best example is the ISO connectionless
internet protocol which is nearly identical to the Internet IP.  The clss
4 TP is another example.  there are format and some mechanism differences
dictated by need for consistency with other standards, later wisdome and
experience, etc. (the DoD protocols are not perfect!)

Bellcore!karn@umd5 asks "has anyone sat down and written a detaile,
technical, side-by-side comparison of TP-4 vs TCP?"  I can only conclude
he has never seen the NRC report, since Chapter III is precisely that.

Provan in his first note (22 March)  asks if "someone could give him
any good arguments for adopting TP-4 ...", and Postel seems
toi whimsically echo this point.  If the protocols are similar functionally,
why indeed make any change?  The main reason is the long term benefits
to be obtained by using commercial standards that are widely supported by
vendors in off-the-shelf equipment.  Let me emphasize the long term phrase.
No one is suggesting DoD throw out existing implementations of DoD
protocols.  We ARE suggesting that in future procurments for new systems
and to replace or upgrade current systems, that equipment with the ISO
standard protocols should be consdiered if there are indeed commercial
implementations available.  Gradually over the life cycle of DoD systems,

there would be an adoption of standard equipment.

To summarize the expected benefits of using standard protocols, I can
best quote from the report's summary:

   "Costs to the DoD for development, production, and maintenance are
   significantly lower becaue (1) vendors spread the cost over
   a much larger user base, (2) commercial vendors are generally more
   efficient in their operations, and (3) vendors look for ways to improve
  their roduct to meet competition.

   The DoD generally gets more effective products because vendors
   integrate the protocol functions into their entire software and hardware
   line.  Thus DoD may be able eventually to use commercial software
   products that are built on top of, and thereby take
   advantage of, the transport protocols.

   By depending on industry to manage the development and maintenance of
   products, the department can use its scarce management and technical
   resources on activities unique to its mission."

Only time will tell whether the committee's expectations about vendor
adoption of the ISo standard protocols will be true.  To me, things do
seem to be moving in that direction.  DoD contractors need not feel
threatened by this: there will still be plenty of pioneering work to
do in advanced areas, or those unique to the military, to keep the
research dollars flowing to the MITs, ISI,s, BBN's, Mitre's, and all the
vendor Federal Systems Divisions now living comfortably on the DoD
special system procurement and research system.
I don't think that it is asking too much to let the areas that are
pretty well understood, and that the commercial vendors seem eager to take
over, pass on to other hands in the fullness of time.

If you have questions on other parts of the report (after reading it,
of course), I am willing to accept BRIEF phone calls.
No net mail please.

Carl Sunshine
Date:      1 Apr 1985 11:25:21 PST
Subject:   re: domain conversion

One can start using domain style names anytime after the following three
conditions are met:

(1) It is after 15=jan-85
(2) The domain style name has been registered with the NIC.  That is the
    NIC has sent you back a notice saying it is ok to use the name you
    applied for.
(3) The name is listed in the databases of some (i.e., more than one) domain
    name server.

Date:      1 Apr 1985 12:06 PST
From:      Art Berggreen <ART@ACC>
Cc:        TCP-IP@SRI-NIC
Subject:   Common Carrier T1

I have been trying to get a handle on the bit stream framing requirements
for using common carrier T1 circuits (DS1).  There seems to be a feeling
that, at least, 193 bit framing must be followed.

My conversations with various people (including people inside various
ATT companies and BELLCORE) lead me to the conclusion that the 193
bit framing has no technical basis and was rather a convention that
ATT wanted to enforce before divestiture.  Since divestiture, it appears
possible to utilize common carrier T1 service without regard to
framing (the ones density requirement will always be there).

Any one have DEFINITE information to the contrary?

    				Art Berggreen<Art@ACC.ARPA>

Date:      Mon, 1 Apr 85 14:39:02 EST
From:      Ron Natalie <ron@BRL-TGR.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, sunshine@USC-ISIF.ARPA
Subject:   Re:  Reply to some NRC report flamers
> No one is suggesting DoD throw out existing implementations of DoD
> protocols.  We ARE suggesting that in future procurments for new systems
> and to replace or upgrade current systems, that equipment with the ISO
> standard protocols should be consdiered if there are indeed commercial
> implementations available.  Gradually over the life cycle of DoD systems,
> there would be an adoption of standard equipment.

But there's the rub isn't it.  I must still specify the DOD protocols for
all new systems because they must interface not only to the over 40 systems
here but to the already TCP/IP interconnected MILNET.  For the REAL long
term, I agree with Noel, by the time TCP/IP is ready to be phased over to
a something else, a new set of protocols, ISO or otherwise, will probably
be the target.  I think TP4 is a dead end proposition as far as DOD goes.

>  The DoD generally gets more effective products because vendors
>  integrate the protocol functions into their entire software and hardware
>  line.  Thus DoD may be able eventually to use commercial software
>  products that are built on top of, and thereby take
>  advantage of, the transport protocols.

Then we aren't talking TP4 here are we?  If TP4 is so much the same
as TCP, then the higher network levels ought to be the same.  Even now
there is a move to switch to the ISO protocols for mail.

> No net mail please.

I'm always skeptical about people who claim to be experts about a system
and don't use it.  It's sort of like a aviation instructor who never goes

Date:      2 Apr 1985 11:33:08 PST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: domain name resolvers

Anyone working on an implementation of the domain name system or interested
in knowing the details that differ from the protocol described in RFCs 882
and 883 should contact Paul Mockapetris (MOCKAPETRIS@USC-ISIF.ARPA).

Date:      2 Apr 85 16:46 EST
From:      Rudy.Nedved@CMU-CS-A.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: domain name resolvers
It would be a significant improvement if a document was written or the current
one corrected instead of querying someone and piecing together the details from
a few discussion files. It makes it hard to hand to a programmer and tell 'em
to implement it.

There are still significant bugs in the current TOPS-20 domain service.

    - SRI-NIC still sends UDP replies from a different address then
      it received it on.
    - Significant response delays and the first packet is dropped.
    - Asking for weird pieces of information like HINFO (to improve
      interactions by FTP) gets no information back other then the 
      QNAME header.

Clarification problems with the domain specification:

    - Given an address (, how do you get the name in a heavily
      distributed domain enviroment?
    - Given a host name alias ("A" or "A.BC"), what is the correct procedure
      for resolving the name? What about the traling "." business?

I am interested in a smooth transition from the current mechanisms to the
domain based mechanisms. I assume SRI-NIC will be critical component and I find
the server has certain bugs and the domain specification is missing certain
clarifications that prevent such a smooth transition. Major modifications seem
to be required for software and significant education costs for the users
(4000+ people).

The domain system is definitely a solution and has most of the problems solved
but it seems to lean toward a general network database with everything in
it...Too much too soon...

Date:      3 Apr 1985 08:37:37 PST
To:        ART@ACC.ARPA
Subject:   Re: Common Carrier T1


I have to admit it:  I nearly fell for it, until I noticed the date of your
message.  Really one of the cleverest and most subtle April-fools messages!!!



  In the remote case that this is a genuine inquiry:  There is a LOT to the
  technical requirement for T1-framing.  There are STRICT rules for the
  193rd bit -- without it all the equipment of the carrier will indicate
  errors and would send warning messages to their NCC's which probably will
  result in  discontinuing your service, unless special costly arrangements
  are made around it.  There also others rules like the good old
  "no-consecutive-16-zeroes" and "at-least-3-ones-in-any-sequence-of-24-bits",
  and more.  Some of these rules are no longer mandatory in Europe, and within
  N years they will not be needed here either, hopefully for a small N.
  The 193rd-bit will be in for LONG time.  I bet.
Date:      03-Apr-85 05:40:48-UT
From:      mills@dcn6
To:        tcp-ip@nic
Subject:   Another domain-name server

A bared-bones domain-name server is up on several fuzzballs, including DCN1
( It does nothing fancy and is driven directly from a hash of
the NIC HOSTS.TXT file. For convenience, it does an invert-thing if you
give it an address in nn.nn.nn.nn format. It is not intended as a general-access
service, but you may find it useful in testing.

Date:      3 Apr 1985 1345-PST (Wednesday)
From:      holg@isi-vaxa
To:        tcp-ip@nic
Subject:   Re: TCP vs TP4
By the way, some interesting comments on this controversy can be found in
ISBN 0-13-2681129-3.

Date:      Wed, 3 Apr 85 14:01:46 pst
From:      E. Howard Alt <alt%sri-lanka@sri-tsc>
To:        tcp-ip@nic
Subject:   rsx-11m tcp/ip

   Does anyone have TCP/IP for RSX-11?

Date:      09 Apr 85  0947 PST
From:      Joe Weening <JJW@SU-AI.ARPA>
Subject:   Network printing protocols
Has anyone thought about a TCP-based protocol for sending files to printers
accessed via the network?  Right now the only facility I know about is that
some printers take TCP connections on port 35 (the well-known port for "any
printer server"), but the protocol depends on the specific printer, which
seems like a bad idea.

I'm looking for a general protocol that has the following features:

 > User identification and authentication

 > Indication of the format of the file being printed (e.g., text, Press,
   ImPress, DVI, etc.)

 > Options meaningful for any printer (number of copies, etc.)

 > Other options specific to the particular printer (fonts, page size
   and orientation, etc.)

 > Accounting information

There are undoubtedly other necessary things that I haven't thought of.

If such a protocol already exists, I'd be glad to hear about it.  (I don't
think there are any RFC's on it.)  Otherwise, someone with the time and
experience to do this could put together an RFC.

						Joe Weening

Date:      Tue 9 Apr 85 15:28:39-PST
From:      Joseph I. Pallas <PALLAS@SU-SCORE.ARPA>
Subject:   Re: Network printing protocols
    Unix has a remote spooling system built into its spooler (LPD).
    There is currently an LPD implementation of sorts for TOPS-20.
    We are doing a VMS implementation of the half that queues and
    sends files (i.e. a user end but not a server end).

Surely it is an oxymoron to speak of a second implementation of an
undocumented protocol.

Date:      9 Apr 85 14:54:17 EST
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        JJW@SU-AI.ARPA
Subject:   Re: Network printing protocols
Unix has a remote spooling system built into its spooler (LPD).
There is currently an LPD implementation of sorts for TOPS-20.
We are doing a VMS implementation of the half that queues and
sends files (i.e. a user end but not a server end).
Date:      Wed 10 Apr 85 03:21:42-EST
From:      Ken Rossman <sy.Ken@CU20B.ARPA>
Subject:   Re: Network printing protocols
We're looking at nearly the same problem right now with our printers.  Our
situation currently differs from yours, Joe, mostly in that each printer we
want to get on the air is "owned" by a mainframe, rather than having its
own hardware interface to the network.  We're looking at a couple of

  - Running a printer spooler based on a Unix printer spooler.  We have
    TOPS-20 systems as well as Unix system here talking TCP/IP, so we will
    probably use a TOPS-20 implementation by Chris Maio of the CS
    department here for those systems (was that the TOPS-20 version someone
    mentioned earlier?).

  - Inventing a "dumb" protocol based on file transfer, with two different
    file types: 1) Files to be printed, and 2) Control files indicating
    what to do with the files to be printed.  This, I understand, is
    similar to what the Unix printer protocol does, though we'll probably
    do it using FTP directly.  We're doing it this way right now because we
    need print services soon between our IBM and DEC systems, and we run
    the WISCVM TCP package in IBM-land, and want to use the tools that are
    there already.

It sure would be nice if a "real" general network printer protocol were
designed, so we'd all have some guidelines to code around.  I'd add one
item to Joe's "wish list" for the protocol, though.  Since we run more than
one type of printer per system, just being able to "address" a printer by
some network host name isn't enough.  Printer unit information would be
helpful -- we do this here now by breaking down the destination into two
logical chunks: system and unit (in our case, the unit is a name, not just
a number).  Other device-specific and print-format-specific control
information is also passed along.

I suspect there are a few printer hardware manufacturers out there (Imagen
comes to my mind initially) who are implementing network hardware
interfaces to put their printers directly on something like an Ethernet.
Anyone from this group care to toss out some thoughts concerning protocol?

Date:      Wed, 10 Apr 85 08:42:18 EST
From:      louie@umd5 (Louis Mamakos)
Subject:   Re: Network printing protocols
We use the MDQS package here on our UNIX hosts.  It can handle multiple
queues and multiple devices, with a very flexable mapping between devices
and queues.  It also spools across the network to other hosts with MDQS
servers, and has access lists to specifiy which internet hosts can spool
to a queue.   It is an extermely flexable package, and was developed at
BRL.  Maybe someone there will provide some information on how to obtain 
a copy; I think that is comes as part of their System V emulation on 4.2BSD

We've done an MDQS implementation for our Sperry mahines, and in fact use
the high-speed line printers on the Sperry machine as the line printer for
a small PDP11 system.  

Worth looking into.

Louis A. Mamakos WA3YMH   University of Maryland, Computer Science Center
 UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie
Date:      Wed 10 Apr 85 16:32:41-MST
From:      The alleged mind of Walt <Haas@UTAH-20.ARPA>
Subject:   Re: Network printing protocols
I have written a Unix-style LPD server for TOPS-20 if anybody wants
it, however no support is available.  It was announced a while ago on TOPS-20.

Regards  -- Walt
Date:      Wed, 10 Apr 85 19:45:03 EST
From:      Mike Muuss <mike@BRL-TGR.ARPA>
To:        Joe Weening <JJW@SU-AI.ARPA>
Subject:   Re:  Network printing protocols
BRL's MDQS (Multi-Device Queueing System) has a TCP-based exchange
protocol that handles shuffling requests (print request, batch requests,
etc) from machine to machine.  Authentication and audit trail issues
are addressed.

For more information, contact Doug Kingston <DPK@BRL>

 -Mike Muuss

  AV  283-6678
  FTS 939-6678

ArpaNet:  Mike @ BRL
UUCP:     ...!{decvax,cbosgd}!brl-bmd!mike
  Mike Muuss
  Leader, Advanced Computer Systems Team
  Computer Science and Mathematics Branch
  Systems Engineering and Concepts Analysis Division
  U.S. Army Ballistic Research Laboratory
  Attn: AMXBR-SECAD (Muuss)
  APG, MD  21005
Date:      Wed, 10 Apr 85 21:31:20 EST
From:      Doug Kingston <dpk@BRL-TGR.ARPA>
To:        Louis Mamakos <louie@UMD5.ARPA>
Subject:   Re:  Network printing protocols
The Multi-Device Queuing System (MDQS) is developed and maintained
by US Army Ballistics Research Lab.  It is in the public domain
and available for anonymous FTP from BRL-VGR.ARPA.  The only
restriction is that the software cannot be resold, though it may
be included in other systems free of charge.  Documentation and
manual pages are included in the distribution.  We normally run
it under 4.2BSD but it will also run on vanilla System V machines
and a few other less known UNIX systems.


Date:      11 Apr 1985 18:57:26 PST
Subject:   Re: domain name resolvers
In response to the message sent   2 Apr 85 16:46 EST from Rudy.Nedved@CMU-CS-A.ARPA

You make some good points:

It would be a significant improvement if a document was written or the
current one corrected instead of querying someone and piecing together
the details from a few discussion files. It makes it hard to hand to a
programmer and tell 'em to implement it.

***>	I am preparing an updated set of RFCs.  I sollicit your suggestions
	for improving the present documents.  In the mean time, all of the
	changes you need to the spec are contained in two messages in

There are still significant bugs in the current TOPS-20 domain service.

    - SRI-NIC still sends UDP replies from a different address then
      it received it on.

**>	A fix for this problem will be installed in the distribution sources
	and at the NIC.

    - Significant response delays and the first packet is dropped.

**>	The NIC is running a prior release of the domain software.  The new
	version is significantly faster, and additional improvements are
	being implemented.

    - Asking for weird pieces of information like HINFO (to improve
      interactions by FTP) gets no information back other then the 
      QNAME header.

**>	Part of this problem is a bug in the compression algorithm which
	has been found.

	The major part is that the NIC is using tables of data which are
	derived by an automatic translation of HOSTS.TXT.  The data
	for ports, OS, CPU etc in HOSTS.TXT is more often incorrect or
	badly formatted than not.  The NIC is working on generation of
	correct tables from their internal database.

Clarification problems with the domain specification:

    - Given an address (, how do you get the name in a heavily
      distributed domain enviroment?

**>	The IN-ADDR mechanism is described in the RFCs.

    - Given a host name alias ("A" or "A.BC"), what is the correct procedure
      for resolving the name? What about the traling "." business?

**>	The RFCs don't define a standard shorthand for "local" names or
	whatever.  Internally it isn't an issue: the name service always
	uses full domain names, and the CNAME mechanism allows for aliases.
	Prior discussion of suitable printed names didn't seem to converge;
	there was opposition to the trailing dot.  In the TOPS-20 JSYS
	code, the assumption is that the name is fully qualified and the
	trailling dot is omitted; this approach is closest to current names.

I am interested in a smooth transition from the current mechanisms to
the domain based mechanisms. I assume SRI-NIC will be critical component
and I find the server has certain bugs and the domain specification is
missing certain clarifications that prevent such a smooth transition.
Major modifications seem to be required for software and significant
education costs for the users (4000+ people).

The domain system is definitely a solution and has most of the problems
solved but it seems to lean toward a general network database with
everything in it...Too much too soon...


**>	The GTDOM JSYS was designed to allow a simple replacement
	of GTHST with GTDOM for host addresses.  The master file,
	refreshing, and other features were aimed at allowing a
	incremental implementation.  I agree that it is a big change,
	but I'm not sure that the trauma would be worthwhile for lesser
	goals.  I have certainly heard a lot of arguments that it
	doesn't go far enough, and that dynamic update, authentication,
	etc. should have been in it.

Date:      12 April 1985 0836-PST (Friday)
From:      stanonik@nprdc
To:        tcp-ip@sri-nic
Cc:        stanonik@nprdc
Subject:   long delay connections
We've always had problems connecting to ucl-cs (we're in california,
ucl-cs is in london).  The symptoms bounce between "host unreachable",
"connection timed out", and "connection refused".  Mail in particular
seems to queue for at least a day before getting through.  Is this
response/reliability typical?  I've assumed so, because the connection
must hop through several gateways, including a slow(?) and congested(?)
link over/under(?) the atlantic.  We're running 4.2bsd on a vax 780.
Back in the 4.1bsd days, we were running bbn's tcp/ip, and had gotten
some modifications to help with long delay connections.  Has any tuning
been done on 4.2bsd for long delay connections?  Or is this response/
reliability the norm?  How about sites running something other than
4.2bsd?  Fuzzballs?  Dec 10's, 20's?


Ron Stanonik
Date:      12 Apr 85 19:09:38 PST (Fri)
From:      Van Jacobson <van@lbl-csam>
To:        stanonik@nprdc.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: long delay connections
The problems you're seeing are probably due to mistakes in the
round-trip-timer code of the distributed 4.2bsd.  All of the bugs
reported to Berkeley have been fixed in 4.3bsd (& the 4.3bsd
release is immanent).

If you have source & don't want to wait for 4.3, here's a slightly
annotated diff listing of the fixes.  The annotations are mine &
may be neither correct nor comprehensible.  The fixes are from
various people around the country & seem to work (we've shipped
a lot of mail through ucl-cs with no problems).  The diff line numbers
will probably bear no resemblance to your sources.

 - Van Jacobson, Lawrence Berkeley Lab

(these lines added to tcp_timer turn off the round trip timing when you
*** tcp_timer.c
*** 153,163 *****
  		tp->snd_nxt = tp->snd_una;
+ 		/*
+ 		 * If timing a segment in this window, stop the timer.
+ 		 */
+ 		if (tp->t_rtt && SEQ_GT(tp->t_rtseq, tp->snd_una))
+ 			tp->t_rtt = 0;
  		(void) tcp_output(tp);
(deleting the following line prevents you from computing a bogus, too small
rtt when you get a ack for less than all the outstanding data).
*** tcp_input.c
*** 503,509
  		else {
  			    tcp_beta * tp->t_srtt, TCPTV_MIN, TCPTV_MAX);
- 			tp->t_rtt = 1;
  			tp->t_rxtshift = 0;
  		if (acked > so->so_snd.sb_cc) {

(if a timeout was caused by the subnet getting overloaded & discarding packets,
you don't want to retransmit everything because that will just make the problem
worse.  This change limits the sender to one MSS segment per timeout interval
until packets start getting through without timeouts)
*** tcp_output.c
*** 60,70 *****
  		return (0);	/* ??? */	/* past FIN */
  	if (len > tp->t_maxseg) {
  		len = tp->t_maxseg;
+ 		/*
+ 		 * Don't send more than one segment if retransmitting.
+ 		 */
+ 		if (tp->t_rxtshift == 0)
+ 			sendalot = 1;
  	flags = tcp_outflags[tp->t_state];
(this line was just someone's mistake.  It prevents you from ever computing the
rtt on the first packet.  In fact, it keeps you from computing the rtt on about
half the packets).
*** 271,277
  		    tp->snd_nxt != tp->snd_una) {
  			    tcp_beta * tp->t_srtt, TCPTV_MIN, TCPTV_MAX);
- 			tp->t_rtt = 0;
  			tp->t_rxtshift = 0;
  		tp->t_timer[TCPT_PERSIST] = 0;
Date:      12 Apr 1985 16:31:30 EST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Another Perspective on the NRC Flap
I wrote the following with the intent of sending it to the NRC
Chairman Fink and making it an RFC.  Neither course seems worth
the effort anymore (especially as I've since gotten a copy of
the full report [though not from NBS] and am reluctant to waste
time, energy, and spleen updating it in light of whatever else
I'd find if I were willing to read, rather than the skimming I've
already done, the full thing).  Just so it doesn't go completely
to waste, though, perhaps some of the readers here will find it
of interest.

[But first an Aside on Cheap Shots:  I don't have any problems
with Carl's not wanting netmail, myself--I just think it would
have been more ... appropriate, somehow, if he'd included his
phone number.  On the other hand, I do have problems with his
implying that our research community is against the commercial
stuff because it will cost us research money; as I said in The
Book--which I notice Chloe was kind enough to post a reference
to--"It's NOT a Not Invented Here problem, it's a Not Reinvented
Right one" (or words to that effect).]

[One other prefatory comment: I haven't been following the
deliberations here scrupulously, so if my stuff is duplicative
I'm sorry for any waste of readers' time; it's just that I have
trouble remembering to use BBOARD, much less remembering how to
use it.]

    Comments on National Research Council Protocols Report

                        M. A. Padlipsky

        Although my response is perforce based upon its
   Executive Summary, I find the conclusions of the report
   "Transport Protocols for Department of Defense Data
   Networks" extremely puzzling, for several reasons, and
   would like to register my comments with you as rapidly as
   possible, without waiting for either the full report or
   corporate coordination with my employer.  (My request for
   a full copy has yet to be honored by the NBS
   representative to whom it was made last December.)

        On balance, the report strikes me as extremely
   flawed, both in its reasoning and in what it omits.
   President Kennedy is supposed to have said that the
   greatest enemy of Truth is not a lie, but a persistent,
   persuasive, unrealistic myth.  The conviction that
   "vendor-supplied" intercomputer networking protocols
   (and, it must be noted, protocol interpreters) are,
   almost unequivocally, desirable, though apparently not
   ignobly motivated, may well be just such a myth.  As I
   will attempt to suggest, the report amounts to
   recommending that we simply throw away (not even trade
   in) a working, late-model automobile in favor of a set of
   tires and a chassis because the latter will cost less to
   purchase now than the former did previously and will also
   cost less to maintain.  That the money for the former has
   already been spent whereas the money for the latter is
   new, that the latter isn't even a complete automobile,
   and that the former doesn't require premium unleaded fuel
   are all subordinated to, apparently, the perceived
   "savings".  (To push the analogy a little further,
   another motivation is that the new machine has a right-
   hand steering wheel, more suitable for use on certain
   foreign roads; I'll also attempt to show that the old
   machine can be made to behave as if had both left- and
   right-hand steering wheels.)  My own reasoning (much of
   which can be found in my recent book, THE ELEMENTS OF
   NETWORKING STYLE, Prentice-Hall, 1985) is as follows:

        In the first place, although the Executive Summary
   acknowledges the importance of protocols "above" the
   "Transport" level, the recommendation to have the DoD
   adopt TP-4 appears to ignore both the current absence of
   and future cost of development and/or procurement and/or


   conversion to such protocols (ISO Reference Model L5-7,
   ARPANET Reference Model L III; see also Chapter 5 of my
   book, "A Perspective on the ARPANET Reference Model") in
   their international standard manifestations.  Clearly, if
   the report's reasoning as to the economic advantages of
   TP-4 is correct, similar considerations must apply to
   "the rest" of the protocol suite.  Thus, emerging
   international standards must be intended to be adopted at
   levels above ISO L 4-3C (ARM L II).  Yet these protocols
   will engender not only further delays in the waiting for
   them, but also further painful conversions in the
   deployment.  As the report appears to acknowledge the
   position that even waiting for and deploying TP-4 are
   unattractive in the DoD context, surely weight should
   have been attached to the additional delays and
   conversions.  (This contextual incompleteness is why I
   cite a "real" car vs. tires and chassis in my opening
   analogy.  It might seem fanciful, but I submit it's
   extremely relevant:  in a sense, the panel is opting for
   a few oranges over a bushel of apples if it does not
   assess the impact of acquiring the entire ISORM "SUITE").

        In the second place, the Executive Summary's
   language suggests that weight was being attached to the
   "development" costs of TCP -- this despite the fact that
   TCP is already developed and, for that matter, procurable
   for a number of DoD operating systems.  Indeed, the
   entire attempt at economic analysis seems questionable to
   me, for reasons discussed at some length in Chapter 8 of
   my book, "The Illusion of Vendor Support", which offers
   support not only for the higher fuel costs aspect of the
   automotive analogy but also for the notion that we'll
   have to go back to the dealer for a more powerful engine
   (i.e., that the ISORM suite's protocol interpreters in
   toto will necessitate upgrading of processors in order to
   leave enough CPU power to run the non-protocol software).

        In the third place, insufficient attention appears
   to have been paid to the "technicoaesthetic" merits, or
   lack of same, of the emerging international standards.
   These are dealt with passim in my book, but perhaps bear
   some treatment here.  For example, Economy of Mechanism
   is a usually accepted technicoaesthetic canon.  The
   ISORM's greater-than-seven layers obviously entail a more
   elaborate mechanism than the ARM's three, even without
   appealing to the greater number of headers and "overhead"
   bits engendered by the extra layers.  A striking
   consideration not mentioned explicitly in the book which


   appeals to essentially the same technicoaesthetic
   principle is that given the emerging international
   standards' approach to communications subnetworks
   (wherein, although not "official," X.25 is usually
   assumed to comprise L 3-1/L I), the very cost of
   communicating is necessarily elevated by factors of four
   or more due to the quite small packet sizes
   permitted/encouraged at the comm subnet level.  That is,
   the ISORM leads to bigger messages' being transmitted in
   smaller chunks (each chunk charged for); hence, even if
   the procurement costs were lower -- which I don't
   stipulate -- the operational costs would arguably be
   higher.  (Again, higher "fuel costs".)

        In the fourth place, the treatment of Security
   appears to be extremely cavalier.  My understanding (as a
   member of the DoD Protocol Standards Technical Panel) is
   that those of us in the networking research community who
   are directly affiliated with or sponsored by the DoD are
   not even allowed under current doctrine to discuss our
   concerns in this area with those in the uncleared,
   commercial arena.  As a matter of fact, it was extremely
   surprising that Ray Mcfarland of the DoD Computer
   Security Center was not listed as one of the expert
   witnesses whose testimony was taken by the panel, even if
   all he could have done was to enter this position on the
   record.  (For that matter, even though Drs. Postel and
   Cerf are certainly outstanding advocates of the TCP
   cause, the absences of Dr. David Clark of M.I.T., the
   ARPA "Internet Architect", and Ed Cain of the Defense
   Communications Engineering Center, the chairman of the
   PSTP, in addition to them were also surprising to me.)
   The panel's blithe assertion that Security can be ladled
   on to TP-4 is probably contrary to fact and certainly

        Finally, although other arguments could be raised
   against the report's conclusions, I'd like to observe
   that a potentially quite attractive solution to the
   problem of "interoperating" with NATO without abandoning
   the in-place DoD protocol suite does not appear to have
   been taken into account.  The approach (mentioned in
   Chapters 2 and 10, "What the Windmill Looks Like Up
   Close" and "Gateways, Architectures, and Heffalumps,"
   respectively) is what I call parallel invocation of
   protocol suites.  Very briefly, it argues that with a
   suitable Host-Front End Protocol (such as the one I've
   proposed in ARPANET "RFC's" 928 and 929) and Outboard


   Processing Environment, one could invoke remote
   applications of interest via the protocol suites they
   "expect" to be invoked through without having to (over-)
   constrain oneself to a single protocol suite.  (This, of
   course, deals with the steering wheel sidedness aspect of
   the automotive analogy.)  Even the "Janus Host" tactic
   mentioned in Chapter 10 could potentially allow for
   sufficient interoperability with NATO to cast
   considerable doubt on the premise that the "automatic"
   ability to do so is a plus for the ISORM.  (Further, as
   observed in Chapter 8, the likelihood of incompatible
   option choices casts a good deal of doubt on how
   "automatic" it would be -- until the fixes are paid for.)

        Please be assured that I am not attempting to
   suggest that the panel be reconvened and forced to study
   my book.  (I did comply with a staff request to send the
   earlier versions of several of the chapters, but the
   book, of course, hadn't yet been published, so I'm not
   even carping about their "research" -- although the
   staffer did know the book was in progress, so perhaps my
   own absence from the witness list could also be faulted
   somewhat.)  Rather, I am attempting to suggest that, if
   accepted, the report would lead to the DoD's wasting both
   money and time, neither of which it -- and the country --
   can afford.  I would, then, be so bold as to suggest that
   the report in question be reconsidered, since it appears
   to have failed to consider several significant factors --
   including, I might add, the consideration that
   embellishing TP-4 to satisfy the stated "DoD Operational
   and Technical Needs" can scarcely be assumed to come for
   free, even if the additional "Needs" of Efficiency and
   Timeliness (of availability in general and of responses
   on a per-transmission basis in particular) were not to be
   accepted as missing members of the list ... and even if
   it were not my conviction that a state-of-the-art in the
   hand is worth more than seven promises in the bush.  You
   Pay For What You Get.

        Perhaps in five years or so, when there will
   probably be a complete ISORM Suite and when vendor-
   implemented option mismatches have had a chance to be
   thrashed out and when holes in the Model such as "null
   layers" and "connectionless mode" and "management
   sublayers" have been plugged and when we have a chance to
   measure the impact all this mechanism will have on the
   containing Hosts, it might be reasonable to consider
   going over.  Today, to do so is to buy a pig in utero


   rather than even a pig in a poke.  Just because the pig
   we already own comes from a family farm rather than an
   Agribusiness is no reason to be so incautious as that, I


Date:      12 Apr 1985 19:24:42 EST
To:        stanonik@NPRDC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: long delay connections
In response to the message sent  12 April 1985 0836-PST (Friday) from  stanonik@NPRDC


Your problems with 4.2 are well-known and documented. Fuzzballs have been
specially built to handle long-delay paths and have several features
designed to minimize the impact on intervening gateways of the type used
on SATNET paths, such as the send-policy and ack-policy algorithms described
to this list recently. According to Berkeley gurus, similar policies are
planned for the next release.

My experience has been that, with carefully engineered algorithms, SATNET
performance can be quite satisfactory.

Date:      14 Apr 85 08:36:22 EST (Sun)
From:      Dave Farber <farber@UDel-Huey.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Another Perspective on the NRC Flap
I must respond very briefly to your comments on security.
We were instructed as to the wording we could put in the report
summerizing our rather non trivial exploration of the security
issues of TCP and TP4. I am sure you can understand the lack of extensive
verbage in this area.

Date:      14 Apr 85 12:17:41 EST (Sun)
From:      Dave Farber <farber@UDel-Huey.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Another Perspective on the NRC Flap
I will take your note as the venicle for again offering a limited
number of reproductions of the full report

Please send your Name and address to westog@udel-ee
requesting a copy of the NRC report. I have about 15.

Date:      14 Apr 85 17:23:14 PST
From:      DonWinter.pasa@Xerox.ARPA
To:        Dave Farber <farber@UDel-Huey.ARPA>
Subject:   Re: Another Perspective on the NRC Flap
Isn't RFC 942 a reproduction of the complete report?
Date:      14 Apr 85 22:43:50 EST (Sun)
From:      Dave Farber <farber@UDel-Huey.ARPA>
To:        DonWinter.pasa@XEROX.ARPA
Subject:   Re: Another Perspective on the NRC Flap
I just checked and it is indeed a full reporduction. I had not checked before.
I assumed from the fact that people seemed to not have read
the full document( from some of the comments they made) and 
assumed invalidly that the rfc was abbreviated. Anyway
if there are any out there who like hard copy typset I
will be happy to send one. BTW, the people who contracted
to do the printing were a good example of lowest bid
work. They did not know how to handle hypens when they
reformatted. Most careless.

Date:      Mon 15 Apr 85 12:10:39-PST
From:      Greg Satz <SATZ@SU-SCORE.ARPA>
To:        postmaster@UCI-ICSA.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
This really stinks. SU-SIERRA just got a new Internet interface and the
NIC hasn't yet put it in the host table. Why should Sierra users who
want to mail to UCI get penalized? You probably have heard many
complaints about this before.

Date: Mon 15 Apr 85 12:05:55-PST
From: The Mailer Daemon <Mailer@SU-SIERRA.ARPA>
Subject: Message of 15-Apr-85 12:04:41

Message failed for the following:
morgan@UCI-ICSA.ARPA: 521 Mail system claims is an unknown host
Date: Mon 15 Apr 85 12:04:41-PST

[Rest of message deleted]
Date:      15 Apr 1985 10:05:31 EST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Clarification
My thanks to the several people who wrote both publically and
privately in re the availability of the full NRC report.  Also,
my apologies for any confusion I might inadvertantly have
engendered.  I'll try to be less subtle here:
1. I have a copy of the full report.
2. I decline to go through the exercise of studying the full
   report closely and updating the comments I wrote when I only
   had the Executive Summary because I don't believe it's worth
   the effort.  (I.e., positions seem cast in concrete [to put
   it kindly]; I just didn't want my comments to go to waste;
   I don't think I'll manage to change anybody's mind by my
   wit and eloquence [unless they manage to change minds in
   what I take to be the wrong directon, of course].)
3. The point I find striking about distribution of the full report
   is that I was promised a copy by the NBS rep at the December
   PSTP meeting--which still hasn't happened.  This is striking in
   that it gives me some faint reason to believe that somebody
   (other than myself) must have some grounds to think that perhaps
   my wit and eloquence might have the power to change some minds
   after all ... I mean, why else would they try to keep me
   out of it?
4. If there were a mark that meant "I'm only being about 49%
   facetious," I'd put it here.
5. In 3., "other than" does NOT mean "in addition to".

cheers, map
Date:      15 Apr 1985 12:28:36 EST
To:        farber@UDEL-HUEY.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Another Perspective on the NRC Flap
In response to your message sent  14 Apr 85 08:36:22 EST (Sun)

Hi, Dave (and onlookers)--

Good to hear that the discussion of Security was more extensive than
suggested by the report.  However, the fact that I'm not even sure
I could discuss it with you at length (if we both even wanted to--
which I for one don't, as a matter of fact) is a lot closer
to what I think the crux is: namely, that Security is merely the most
evident of the many areas in which the assumption (or even much-debated
conclusion) that DoD-needed alterations to the emerging
commercial standards can be achieved within reasonable time and cost
limits strikes me as being extremely questionable.  Indeed,
I'd even go so far as to suggest that the very acknowledgment of the
necessity of such changes calls the report's conclusion into question,
since the "off-the-shelf" premise (which I take to be very major)
is negated by it (unless you want to get into "a little bit pregnant"
sorts of arguments as to just how many changes makes it no longer
off-the-shelf--which won't be fruitful, since my position is "one").

At any rate, I really didn't mean to start off a new round of spleen-
venting with my comments, so I'd better not indulge myself on the
topic of how much many/most contractors charge the DoD even NOT to do
things (that were "in the A-Spec," typically) and just settle for
wondering what happens when the alterted realizations of the
standards start getting mutually incompatible....  (I suggest, that
is, that the power AND THE DANGER of standards both stem from the
standards' being STANDARD--and don't even be tempted to try to see
what my answer is to "backward compatibility" arguments.)

Enough.  I'm already getting sorry I rediscovered BBOARD, and I
don't want everybody to be.

cheers, map
Date:      Mon 15 Apr 85 13:56:02-EST
From:      Mark McCall <MCCALL@RADC-TOPS20.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   LAN TCP/IP implementations

I am working on a major DOD program which will be using TCP/IP outboarded
in interface units on a network of heterogeneous hosts and workstations.
The LAN will be based on a commercial broadband offering.  One of the 
hosts currently supports a version of NCP which allows up to 128 logical
connections to the host.  The problem we have is how to carry over this
capability when we convert to the outboarded TCP.  We currently have specified
interface units which will support 64 logical connections and plan to provide
multiple paths to a host - if required.

I am interested in opinions relative to the feasibility of our current
plan, as stated above, and to the feasibility of supporting up to 128
logical connections in an interface unit.  The interface unit is expected 
to be based on Intel 8086, 80186, 80286, or Motorola 68000 microprocessors.
Any input will be appreciated.

Please respond to "mccall@radc-tops20" or to this mailing list.
Date:      15 Apr 85 19:23:17 PST (Mon)
From:      John Romine <jromine@uci-icsa>
To:        Greg Satz <>
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
Well, I used to hear about it from time to time when I was the UCI
PostMaster, but I'm not anymore so I don't.

UCI took (takes?) the attitude that they don't want to accept mail that will
be unreturnable (or unreplyable).  Also, I seem to remember something about
hosts not using a net address that wasn't registered with the NIC.  (Does
that mean in the NIC table?)

At any rate, I'd say this falls into the category of UCI not being an
extremely friendly neighbor.  That is, not being liberal enough in what we
accept, to allow mail from unregistered net addresses.  At least we try to be
conservative with what we send out.

If we want to talk about deficiencies in various hosts' mailsystems (I
don't), we can always discuss why certain TOPS-20 sites can't seem to
generate a Date: field which adheres to the standard.  I'd just as soon not
complain about other people's mailsystems, and hope to not get too many
complaints about mine.

Date:      Mon 15 Apr 85 19:28:16-PST
From:      David Roode <ROODE@SRI-NIC.ARPA>
Cc:        postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
Well, hopefully the DDN PMO people will generate an ACTIVATE HOST
form so the NIC can place the SIERRA ARPANET address in the host
Date:      Mon 15 Apr 85 19:43:44-PST
From:      David Roode <ROODE@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   apologies
You may get 2 copies of the last message sent to TCP-IP.
The mail processing daemon here at SRI-NIC was inadvertently
interrupted midway through the delivery cycle for the
message from John Romine which will cause some people to receive
an extra copy.

I wanted to respond to John Romine's and Greg Satz's questions
concerning the recognition of the SU-SIERRA Arpanet address
by explaining that what is happening is that the IMP port
is operational in a TEST status.  Sierra must communicate the
operational status of the port to their contact back at DCA,
and at that time DCA will tell NIC to place the host in the
official host table.  It is not technically kosher to 
utilize the port for operational purposes in the meantime.
Date:      16 Apr 1985 07:07-EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: LAN TCP/IP implementations

You don't say what sorts of traffic these 128 connections might handle.
There is certainly nothing about the TCP/IP which should prevent it from
handling 128 simultaneous calls.  And if you have MC68000 or 8086 
capability microprocessors, they should be adequate in terms of CPU -
the real limiting factor is probably packets/second and checksum calculations.
If the applications are echoplex in nature and call for many small packets
per second, you may have some problems with large numbers of concurrent

Another issue is memory space - because TCP uses a window/retransmission
scheme, a long delay before receiving an acknowledgement from a
corresponding party (ie.e the other end) can increase memory needs. This
is exacerbated by high bandwidth file transfers.  Of course, each 
connection requires some memory just to keep track of state.

Perhaps some of the implementers of TCP in microprocessor environments
can offer their experiences as to maximum number of and types of
TCP connections they've been able to support?

Vint Cerf
Date:      Tue 16 Apr 85 12:32:23-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        jromine@UCI-ICSA.ARPA
Cc:        SATZ@SU-SCORE.ARPA, postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
     The problem with Date: fields in the TOPS-20 mailsystem is an old
issue and has been hashed out ad nauseum on this and other lists.
Basically, TOPS-20 has a system call which outputs formatted date/time
fields, unlike most operating systems where you have to do the grunge
work yourself.  The transition from RFC 733 to RFC 822 somehow managed
to pick one of the few human-readable date/time formats which this
system call cannot output.  I consider the problem an operating system
problem/lack of feature and have had enough positive input from the
operating system's vendor on the subject that I believe the support for
RFC 822 format will be added to TOPS-20.

     The problem could, of course, be fixed with some work in the mail
software, but I don't think it's worth it.

     There are several other issues about the RFC 822 date/time format
and why in general it is a losing format.  I don't wish to engage in
long religious wars on the topic.  I just wish I had caught it before
RFC 822 was made official when I had a chance of getting something more
ameniable to TOPS-20 (and for parsing in general).

-- Mark --
Date:      Tue 16 Apr 85 12:40:16-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        jromine@UCI-ICSA.ARPA
Cc:        SATZ@SU-SCORE.ARPA, postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
     It is reprehensible to refuse electronic mail from an address which
isn't in your host table.  A large body of sites exists in which the site
itself has no ARPA Internet business but certain of its users do.  The
organization management elects NOT to list that site with the NIC even
though the site has Internet connectivity (for internal uses) but allows
the users with ARPA Internet business to communicate with the ARPA Internet.
Stanford University is one organzation operating with this model.

     It is completely possible to respond/return mail to a site which
isn't registered -- go by the numbers!  The syntax of dotted decimals
is defined in RFC's 821 and 822.  While the authors didn't envision its
regular use for this purpose, the syntax does exist and can be used for
this purpose.

     The much-maligned TOPS-20 mailsystem was carefully coded to consider
the [a.b.c.d] syntax to be a "host name" string just like names in the NIC
table and in fact is incapable of telling the difference except at the very
lowest level.  If your mailsystem can't support the dotted decimal syntax,
maybe you might take a hint from an obsolete operating system and write
the support in the low-level HostNameToAddress and AddressToHostName
Date:      16 Apr 1985 16:51-PST
From:      Joel Goldberger <JGoldberger@USC-ISIB.ARPA>
To:        MRC@SIMTEL20.ARPA
Cc:        jromine@UCI-ICSA.ARPA, SATZ@SU-SCORE.ARPA postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Rejection of hosts not in the NIC table
Berkeley Sendmail explicitly supports dotted decimal notation.  I won't
try to speculate on what software UCI is running, but they must have
installed this less than helpful feature themselves.

- Joel Goldberger -
Date:      Tue 16 Apr 85 18:02:26-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
Cc:        jromine@UCI-ICSA.ARPA, SATZ@SU-SCORE.ARPA, postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
Dave -

     I still actively develop and maintain the TOPS-20 mailsystem, but
that doesn't mean that every site runs the software as I distribute it.
ISI in particular runs its own completely different SMTP server.

     Only software using the "HSTNAM module" for name/address parsing
and translation will have the automatic [a.b.c.d] format handling that
I described.  Most versions of MM use this module (I don't know about ISI's),
but I can't speak for Babyl, Msg, Hermes, or MS.

-- Mark --
Date:      16 Apr 1985 18:50:51 EST
To:        MRC@SIMTEL20.ARPA, jromine@UCI-ICSA.ARPA
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
In response to the message sent  Tue 16 Apr 85 12:40:16-MST from MRC@SIMTEL20.ARPA


Your "much-aligned TOPS-20 mailsystem" must have gone bum since you last had
hooks in it - the ISI systems, at least, now punt with "[a.b.c.d]" formats,
both for originating and answering mail.

I agree with your point, however.

Date:      17 Apr 85 14:57:17
From:      Dale Chase <Chase@ISIB>
Cc:        tcp-ip@SRI-NIC.ARPA,  MRC@SIMTEL20.ARPA
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
Dave- Both MM and SMTP at ISI are happy to accept dotted decimal
formats for hostnames.  If you still think one of them doesn't,
give me some more info (offline from this list) and I'll investigate.


Date:      17 Apr 1985 18:14-PST
From:      William "Chops" Westfield <BillW@SU-SCORE.ARPA>
To:        chris@COLUMBIA.ARPA
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 1...
That some of the tops-20 hosts at stanford send out mail FROM: user@HOST,
where host is not in the NIC host table is not MRC's fault.  Those
people have carefully broken the feature where such hosts would be
written as [a.b.c.d],  on the basis that the latter form is ugly.
I recently brought up CSD's new 20 (SU-SUSHI), and sure enough it
sent out mail saying FROM: BILLW@[] until I broke MM to
cause it to to say BillW@Sushi...  Of course this is partly MRC's
fault, because MM should have gone on to discover that Sushi was
a valid PUP name, and put that name there (at least for PUP speaking
hosts!).  However, if a host is ON the internet, then MRC's low level
routines don't understand the concept of "not in the host table, try
some othre host table" - the routine will ALWAYS return some host name,
even if it is []...


PS: SU-Sushi is now in the NIC host table - I would not have felt
    justified in breaking MM if it hadn't been a temporary condition.
Date:      Wed, 17 Apr 85 20:12:03 est
From: (Chris Maio)
Cc:        MRC@SIMTEL20.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
I think there's a little confusion here - if a Stanford host is not in the NIC
table but has a local host table with it's own name in it, then it will *not*
generate dotted decimal notation in the From: header of outgoing messages - the
sending mailer has no idea whether its name is known to other hosts, and this
seems to be uci's motivation in not accepting mail from those sites.  I find it
somewhat annoying to get requests for help or info from somebody at Stanford
and have to do detective work to figure out how to reply, and I don't think
it's reasonable to expect the average user to read the RFCs to figure out that
he can look in the Return-Path to get a dotted decimal address.

One easy solution to making "hidden" hosts a little more socially acceptable is
to route outgoing mail through a sendmail host which is in the NIC table to
rewrite the sender's address, e.g. "user%hiddenhost@knownhost".  However, the
whole idea of hiding hosts from the NIC bothers me, since it's difficult to
determine who the host administrator is.

- Chris
Date:      17 Apr 85 21:50:34 EST
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   request for a buddy
RUTGERS now has permission to be a domain.  As you no doubt know,
this involves establishing a duplicate server, preferably on some
other IMP (so an IMP failure does not take both servers down).  Is
there anybody else out there who needs a duplicate server and would
like to cooperate with us?  I.e. we act as your backup and visa
versa.  My theory is that there should be a computer match-making
service for this purpose, but if people who are interested would
reply to me directly, I can keep a list and respond to anyone else
who is interested.
Date:      Thursday, 18 Apr 1985 10:52-PST
From:      imagen!geof@Shasta
To:        shasta!tcp-ip@sri-nic
Subject:   Routing capabilities of Berkeley 4.2 Unix

Does 4.2 Unix have code in it to send ICMP redirects?  

I want to use a local 4.2 machine as a redirecting gateway to all our
other hosts.  The 4.2 machine is configured to know the `best route'
that I want.  When I send packets to it, it forwards them correctly,
but doesn't send a redirect.  Since I don't want to use the 4.2 host as
a gateway, but only as a source of redirects, this is unacceptable.

Perhaps some switch needs to be enabled to make this work right?

- Geof
Date:      18 Apr 85 11:14:15 PST (Thu)
From:      Einar Stefferud <stef@uci-icsa>
To: (Chris Maio)
Cc:        Chase@usc-isib,,,, stef@uci-icsa
Subject:   Re: [The Mailer Daemon <Mailer@SU-SIERRA.ARPA>: Message of 15-Apr-85 12:04:41]
Thanks Chris for your lucid comments which explain our UCI position.
Users on unregistered hosts should use a known relay to send mail. 

I also want to thank David Roode for pointing out that from the SRI-NIC
and DCA perspective, hosts that are in test state and not yet approved
for entry in the official NIC HOST TABLES are in fact not yet entitled
to netwide recognition.  They should use gateways and relays.

As the Officially registered Host Administrator for UCI, I reaffirm
that we do not plan to accept mail conections from hosts we do not find
in our host tables, which we get from SRI-NIC on a most regular and
punctual basis.

Our reasons are simple and to the point.  We very much believe in being
friendly, but draw the line at being promiscuous.

1) We do not have the resources to chase down addressing addressing
problems that would result.

2) We do not see any reason to trust just anybody that attempts an SMTP
connection, no matter who you might be, if we cannot identify you.

3) A perfectly valid alterntative exists for you to use a gateway or
relay if you are not registered with the NIC.

4) It is your responsibility to be known, not ours to sleuth you out.

5) Any competent mail transfer system should be able to automatically
route all mail to the Internet via some known relay.

6) What does or does not run on TOPS-20 sites is of no relevance to UCI
in this matter.

Thank you all for your contributions to this discussion.  I hope this
will close it out.  --- Stef
Date:      18 Apr 1985 1502-PST (Thursday)
From:      Jeff Mogul <mogul@Navajo>
To:        imagen!geof@shasta
Cc:        tcp-ip@sri-nic, karels@ucbarpa
Subject:   Re: Routing capabilities of Berkeley 4.2 Unix
Geof asks:
	Does 4.2 Unix have code in it to send ICMP redirects?  

From a quick reading of the source code, the answer is "no".

From a deeper understanding of the 4.2 networking implementation,
the answer is "no way."  The problem is that 4.2 does not track
the physical source of a packet (i.e., which interface it arrived
on); this information is thrown away in the device driver.

So, by the time the IP layer makes a routing decision on
a packet it is forwarding, it has no idea if the packet arrived
on the same interface it is to be sent out on,  which would
be grounds for issuing a redirect.  I suppose there might
be other ways of determining that a redirect is in order,
but I can't think of any that are as simple and foolproof
as comparing the incoming and outgoing interfaces.

Moreover, the lack of tracking means that it is impossible,
under the 4.2 structure, to properly (safely) implement:

o	ICMP Information Request
o	ICMP Address Format Request (soon to be "Address Mask")
o	Reverse-path forwarding of broadcasts
o	Non-local broadcasts ("letter bombs")

I spent a few days trying to construct a tagging system that
would not require major changes to all of the 4.2 network
code; the best I could do is still a kludge, so I gave up.

I don't know if this will change in 4.3; perhaps someone
at Berkeley could enlighten us?

P.S.: Or, maybe someone can prove me wrong ... I sure hope so!
Date:      18 Apr 85 16:55:45 EST (Thu)
From:      Christopher A Kent <cak@Purdue.ARPA>
To:        imagen!geof@shasta.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Routing capabilities of Berkeley 4.2 Unix
Last time I looked, it wasn't there. Too bad.

Date:      Thu, 18 Apr 85 17:38:54 EST
From:      Joe Pistritto <jcp@BRL-TGR.ARPA>
To:        Christopher A Kent <cak@PURDUE.ARPA>
Cc:        imagen!geof@SU-SHASTA.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Routing capabilities of Berkeley 4.2 Unix
Actually, I do have a program that will adjust the default route under
4.2 among a number of possible gateways, using ICMP ECHOs to verify
that the gateway is there, and selecting an alternate if its not.
This doesn't, of course, have any relation to EGP.

Date:      18 Apr 85 22:39:26 EST (Thu)
From:      dizio@UDel-Dewey.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   satellite

     I'm currently writting a paper which deals with the effects
a satellite communication network could have upon transport layer
protocols.  In particular flow control considerations.   I've
looked in some of IEEE's issues which deal with satellite communications
but all the papers I've read are mainly concerned with setting up these
types of network(physically)  and sharing the communications channel.
I would appreciate any information with regard to where I could look to
find out more about this subject(ie. papers books,  etc..).  
                                        Thanks in advance 
Date:      19 Apr 1985 1759-PST (Friday)
From:      Jeff Mogul <mogul@Navajo>
To:        bill%gvax@Cornell.ARPA (William A. Nesheim)
Subject:   Re: 4.2 routing ...
Bill Nesheim writes:
    I've been working on implementing XNS routing and packet forwarding
    under 4.2.  We want to have one of our vaxes act as an Internetwork
    Routing Service for the Xerox hardware on the net.  Directed broadcast
    is used in the Xerox internet to locate Clearinghouse Servers, a fairly
    important activity, so we couldn't just leave it out.

    The only way to implement this safely is for the internet layer to be
    able to look at the lower level headers of the packets it recieves.  I
    did this for the ethernet by tacking a mbuf with m_type == MT_HEADER
    onto the front of the mbuf data chain in the ethernet interface driver,
    and copying the ethernet header into it.  The IDP input routine then
    can use this mbuf if it exists, or just not deliver "letter bombs" if
    it isn't. (eg, first mbuf m_type == MT_DATA).

Actually, I stand by my original suggestion: you don't need the LAN
header (as Bill notes, that causes a lot of kludgey code, anyway); you
need a stamp showing which interface the packet arrived on.  This can
be any "unique ID" for the interface; the "struct if" address of
the interface is sufficient, since you only need it for equality
comparisons.  This works for all protocols and local network

In fact, I do not believe you can deduce this information from
the LAN header, in the general case.  In the case of the 10Mbaud
EtherNet, you can (because the ether source host ID is universally
unique), but on (say) the 3Mbaud ethernet the LAN header does not
tell you which interface a packet arrived on, because each LAN
has its own host number address space.

I speak from some experience, having implemented directed broadcasting
for Pup in two different gateways.

By the way, I agree with you that directed broadcasting is

Date:      Fri, 19 Apr 85 15:30:48 est
From:      bill%gvax@Cornell.ARPA (William A. Nesheim)
Subject:   4.2 routing ...

Jeff Mogul <mogul@Navajo> writes:

>Moreover, the lack of tracking means that it is impossible,
>under the 4.2 structure, to properly (safely) implement:
>o	ICMP Information Request
>o	ICMP Address Format Request (soon to be "Address Mask")
>o	Reverse-path forwarding of broadcasts
>o	Non-local broadcasts ("letter bombs")

I've been working on implementing XNS routing and packet forwarding
under 4.2.  We want to have one of our vaxes act as an Internetwork
Routing Service for the Xerox hardware on the net.  Directed broadcast
is used in the Xerox internet to locate Clearinghouse Servers, a fairly
important activity, so we couldn't just leave it out.

The only way to implement this safely is for the internet layer to be
able to look at the lower level headers of the packets it recieves.  I
did this for the ethernet by tacking a mbuf with m_type == MT_HEADER
onto the front of the mbuf data chain in the ethernet interface driver,
and copying the ethernet header into it.  The IDP input routine then
can use this mbuf if it exists, or just not deliver "letter bombs" if
it isn't. (eg, first mbuf m_type == MT_DATA).

This is really a kludge, as the lower level header depends on the
network the packet was delivered on, so we have to put some knowledge
of this lower level into the internet layer for this scheme to work.

Question:  Has anyone come up with a fairly generic template for a
"Transmission Media Protocol" header that could deliver all the
information needed for ICMP, Reverse-path forwarding of broadcasts, and
Non-local broadcasts?

			-- Bill Nesheim
			Cornell U. Dept. of Computer Science
Date:      Fri, 19 Apr 85 19:12:45 est
From: (Chris Maio)
Subject:   IP gateways
Can someone recommend a good source for ethernet IP gateways, preferably
something like a 68000 box with source code available for a reasonable cost?
Columbia is looking to link several campus 10Mb ethernets together, and the
simplest solution, using 4.2bsd hosts as gateways, would not provide for the
use of non-IP-based protocols (e.g. LAT, DECnet) between ethernets.  I'd like
to find a gateway implementation that could be extended to handle these other
protocols; either commercially or "homebrew" implementations would probably be
fine as long as source is available.

One possible alternative would be an ethernet store-and-forward gateway, but I
have heard only vague information about two devices that might be useful: an
very expensive box from Versalink (designed for linking ethernets which are
physically far apart) and an as-yet-unannounced box (?) from DEC which I know
little about.  Does anyone have any more info on these or similar devices?

- Chris

P.S.  I heard a rumor that MIT had developed store-and-forward gateway code for
Bridge's hardware - if this is true, is it available?
Date:      Sat, 20 Apr 85 00:01:55 pst
From:      engvax!KVC@cit-vax
To:        ."cit-vax!tcp-ip@sri-nic.ARPA"@__ENGVAX
Subject:   Re: Ethernet gateways..
I just had a meeting with the VITALINK people re: their ethernet bridge. 
What they've done is taken hardware from Bridge and built a completely
protocol-independent gateway for linking ethernets.  This is the same
device that DEC is currently recommending. I have also heard that DEC is
developing their own box, but don't know how true that really is. 

The VITALINK TransLAN (cute name, huh...) has a node on each ethernet that
is going to be linked.  The node listens to the traffic on the net and
builds internal tables of known nodes as it sees traffic go by. The
VITALINKs are also talking to each other, so the tables allow the box to
map destination fields on one net to source fields on another. After
whatever (configurable) learning period has gone by, the VITALINK boxes
begin routing packets between one another based on the tables. They do
continue to update tables after they start routing. 

The nice thing about this gateway is that it routes solely based on the
ethernet packets.  This avoids any dependency on higher level protocols.
At the last DECUS symposium in Anaheim (southern california), they had a 
VITALINK link (via satellite) between ethernets in Anaheim, Boston
(DECworld), and somewhere else in Mass. or New Hampshire.  The had TCP/IP,
LAT and DECnet all running on the one huge ethernet.  I logged into a
system in Boston using LAT without realizing at first where the system
was.  Of course the satellite delay gave things away, but it was still
quite useable.

It looks like the VITALINK bridges can be linked with just about any
medium you care to name.  I'm not exactly sure what interfaces the box has
got on it, but we talked about leased phone lines (even as slow as 9600
baud), fiber optics, microwave, satellites, and T1.  Currently the thing
only supports a link up to 224kb, so full T1 is out.  They are planning,
however, to support up to full T1 speeds (1.something-or-other Mb), within
a few months. 

Price seemed a little steep.  I recall somewhere around $20,000 per box
(and you need one per ethernet).  It's so much more flexible than a 68000
doing IP routing, though, that we'd probably spring for it when the need
comes up. 

Anyway, hope this helps someone out there.  I've got phone numbers if
someone wants to talk to VITALINK directly.  Just drop me a message...

	/Kevin Carosso          engvax!kvc @ CIT-VAX.ARPA
	 Hughes Aircraft Co.

ps.  I have nothing whatever to do with VITALINK, beyond being interested
     in their product.
Date:      Sat 20 Apr 85 09:55:15-EST
From:      Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA>
To:        chris@COLUMBIA.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP gateways
I  agree  with the recomendations for the VITALINK stuff. I spent a bit
of time at the last DECUS playing with it and it seems to  work  really

While  I  was  playing  with  the  VITALINK stuff something interesting
happened. DECs engineering net got  split  in  New  England  somewheres
between  a  plant  in  Mass  and  a plant in New Hampshire. The network
determined that the path through DECWORLD and DECUS and the rest of DEC
was the optimal route and starting sending very huge amounts of traffic
through the VITALINK stuff. It worked just fine.
Date:      20 Apr 1985 1557-PST (Saturday)
From:      medin%ucbarpa@Berkeley (Milo Medin)
To:        chris@columbia.ARPA (Chris Maio)
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: IP gateways

The VITALINK box isn't really meant to do what you want to do,
and its slow besides.  We at NASA are using a box built by
Applitek to build a backbone fiberoptic net to hook together
various ethernets running different protocols.

The box costs about 12K (this plugs into a CATV broadband cable,
the details on the glass one escape me), and encapsulates the
ethernet packet into a special protocol that is spoken
on the backbone which doesnt have ethernet's distance and
loading problems.  Now, here's the best part, the sustained
throughput from the ether to the backbone is 3 Mbits/sec.  Thats
a lot better than 224 kb or even T1.  As usual, only outbound
packets from the ethernets wind up on the backbone.  This
box doesnt deal with satellites like the vitalink does, 
so it can use less complex routing protocols inside.  I think
its based on a multi-68000 processor configuration.  Check
them out, its cheaper than Vitalink and is desiigned for what
you want to do.  Oh, you can hook more than 2 of these together to
bridge several nets using one common backbone cable.


Date:      21 Apr 1985 08:47:41 EST
Subject:   HDLC TO DCP40

Date:      Sun 21 Apr 85 11:33:50-EST
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        mogul@SU-NAVAJO.ARPA, bill%gvax@CORNELL.ARPA
Subject:   Re: 4.2 routing ...
	Jeff is entirely on the mark. Passing LAN headers up is usually
the wrong thing, unless you have a higher level protocol that depends on
seeing them (like old NCP).
	The suggestion of having a 'Transmission Media Protocol' to
convey information caused me to barf in my socks. It's true that you need
this information, but inventing a protocol to do it is using a
sledgehammer on a gnat. Packet nets are already under attack from people
who say they are too complicated; let's try and keep it simple!
	The information about which interface a packet arrived on is one
of a number of pieces of information that are properly associated with a
packet but not part of it, and belong in the 'packet descriptor', along
with obvious things like the address and length of the packet. This
packet descriptor is almost inherently implementation dependant, although
obviously they will all look pretty much alike. 
	 In the multi-protocol packet switch (i.e. gateway) that I did,
the information about interfaces (both inbound and outbound) is kept as
pointers to 'network structures'; the network structure is an abstraction
that includes both data and code (as pointers to procedures), sort of
like a CLU cluster. There is one structure for each network on the
system, and they completely describe it to the upper levels of the
network code.
	The other pieces of information that are kept in a packet
descriptor are a pointer to the 'protocol structure' of the owning
protocol (useful for things like informing the protocol layer if the
network layer decides to discard the packet some time after it is given
to the network layer), the destination address on the local network
(kept here rather than in the packet for ease of access, since it
is used for a variety of things, such as round-robining of output
packets), the retransmit count (used on networks with low level
flow control, since protocol performance degrades dramatically when
packets get dropped, and you want to avoid doing that if at all
possible), etc.

	In general, this is another case of the 'multiply-homed host
versus packet switch' hassle. People think that because they have the
former they have the latter. Not so; packet switches are much more
complicated bits of mechanism. This is exactly why the IP architecture
deliberately separates machines into hosts and gateways; the job of the
gateways is much more complicated and will continue to change and
get more sophisticated.

Date:      Mon, 22 Apr 85 11:24 EST
From:      David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
To:        William A. Nesheim <bill%gvax@CORNELL.ARPA>, TCP-IP@SRI-NIC.ARPA,
Subject:   4.2 routing ...
    Date: Fri, 19 Apr 85 15:30:48 est
    From: bill%gvax@Cornell.ARPA (William A. Nesheim)

    Question:  Has anyone come up with a fairly generic template for a
    "Transmission Media Protocol" header that could deliver all the
    information needed for ICMP, Reverse-path forwarding of broadcasts, and
    Non-local broadcasts?

One thing we did (Symbolics Lisp Machines) is to pass along the
interface object that received the packet.  What you then do is ask the
interface "Hey, where'd this packet come from, anyway?" and give it the
packet as a reference.  It also passes in the protocol object (e.g.,
INTERNET, CHAOS, XNS).  The query returns the hardware source of the
packet, in the format specific to the interface, and (in the case of
Ethernet if the address resolution cache has the entry) the software
protocol address in the format specific to the protocol.  From this the
routing layer can do pretty arbitrary things and has all the necessary
information to do so.

I don't know how easy this is to backtranslate into more conventional
programming languages and structures.  I >am< convinced this is fairly
generic (note it isn't a template).  Also note that you only have to do
this in not-too-frequent circumstances -- normal operation just
processes the packet and sends it up to TCP (or whereever).

Date:      Mon 22 Apr 85 16:27:38-EST
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        chris@COLUMBIA.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: IP gateways
	MIT does have a multi-protocol packet switch. It is called the
C Gateway, and I developed it over the years 1980-1982 since I saw
the need coming for what has since come to be called the 'multi-protocol
spine' approach to networks. In this model, a single set of physical
links and packet switches has layered on it a set of 'virtual' protocol
networks, one for each transport protocol supported in the system. (Note
that the protocol nets do not have to be congruent; in the MIT system
some switches and nets are IP only, others are mixed, etc.) For people
interested in more details to this approach, please send mail to
Esther@MIT-XX asking for the "MIT Campus Network Implementation"
planning document.

	The code was originally done for the PDP11. It has been ported to
the 68K at MIT (this port should not be confused with the Portable C
Gateway, which is a commercial deriviative I am working on); one of these
ports was to the Bridge box. However, neither port was ever completed and
put in service. The only service code at MIT is the PDP11 version.  The
code (both PDP11 and both 68K versions) is publicly available, however;
people wanting it should contact Dave Bridgham, dab@mit-borax for more

Date:      Mon 22 Apr 85 19:52:00-EST
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        engvax!KVC@CIT-VAX.ARPA
Cc:        JNC@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Ethernet gateways..
	Before everyone decides that digital filtering repeaters (i.e.
what some people call bridges) are the answer to all the world's
problems, let me point out a few disadvantages to that approach.

	The basic advantage of a bridge is that it operates at the
network framing level (level 2 in the ISO model), so that the operation
is invisible to the higher layers. The basic disadvantage of the bridge
is that it operates at the network framing level, so that the operation
is invisible to the higher layers.
	The key point here is that these boxes really are packet
switches, and whenever you have packet switches, be they bridges (at
level 2), or gateways (at level 3), you have the exact same set of
issues and problems. However, while you may be able to deal with them
at level 3 (the internetwork layer of the protocol), which is explicitly
designed for this application, you usually can't at level 2.

	To begin with, an obvious problem is that you can't connect
together networks with different level 2 formats via a bridge. Also, it
has to be a network where hosts are uniquely identified. Finally, on
networks that provide data reliability (checksums) and delivery
acknowledgement as part of the network level, these can generally no
longer be guaranteed in a system with bridges. This may cause problems
with some application protocols. These are obvious, and are in fact not
the worst problems.

	More serious ones come into play when you start to consider the
effect of using different technologies in the links than in the networks
on each end. An example would be a medium speed serial link between two
bridges on Ethernets. Networks are all diferent, in obvious things like
delay and bandwith as well as less obvious things like cost (X.25 links
cost $$$) and authorization (most types of business traffic are not
allowed on government data nets).
	These issues need to be considered in routing and other
decisisions. For instance, a distributed algorithm running on a set of
computers connected by a variety of links might adjust the communication
protocol depending on the link type. On slow links, it might use a
CPU-intensive method of exchanging data, whereas on a fast link it might
use some simple approach that wastes bandwith. (Routing algorithms are a
good example and some do vary their behaviour depending on the link
type.) This sort of approach is clearly impossible in a system where the
link characteristics vary if bridges are in use.
	Another example of problems in this regard are with what is
called 'type of service' routing, where the user indicates to the network
a particular type of service (e.g. low delay) and the gateways are
expected to pick a route that minimizes delay. Clearly, if what the
gateway thinks is an Ethernet includes satellite delays, it will not be
able to route correctly. The IP system is starting to address the TOS
routing issues now in the conext of satellite links, so this is not an
unrealistic example.

	Finally, even if the bridges only operate over a homogenous
set of links, there are still problems. Congestion control is one
example. Switches can get overloaded. This is even true if the
switch can operate at network speeds. Suppose you had two bridges
(each of which can handle 10Mb/sec) into an Ethernet. If each of
them is getting 6Mb/sec in, all of which must go into the single
Ethernet, there is no way to do that, even though each switch is
well below its performance limit.

	A lot of people think that bridges are also inherently faster.
This is not so. Most of the work in packet switches of both types has
to do with handling the network interfaces. Only a limited fraction
has to do with parsing and constructing the level 2 headers and
routing the packet. A little consideration will show that routing
at level 2 is probably as expensive as routing at level 3, so the
difference in performance is small. Based on extrapolation from
measured performance on PDP11's, level 3 packets switches based on
12 MHz 68K's with no wait state memory should be over 4 Mb/sec,
as fast as the best bridge figures given.

	I could go on for a while, but you get the idea. The basic
problem is that these boxes are packet switches, just like gateways.
Packet switches have a generic class of issues, and you don't solve
thme by sweeping them under the level 2 rug. Bridges do have
applications where they are the right thing, but they also have their

Date:      23 Apr 85 09:17:03 PST
To:        "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
Cc:        engvax!KVC@CIT-VAX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Ethernet gateways..
Another problem with bridges.... It's harder to put bridges in parallel
for greater reliability or more horsepower.

If you use broadcasting to locate gateways, you even get some load
sharing for free since the less loaded machine will probably respond
Date:      Tue, 23 Apr 85 11:56 EST
From:      don.provan@CMU-CS-A.ARPA
To:        "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
Cc:        engvax!KVC@CIT-VAX.ARPA, JNC@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Ethernet gateways..
I don't remember how we got on to this, but if I had two ethernets
I wanted to talk to each other and nothing was commercially available,
my first thought would be a level two router.  It seems to sidestep
several issues that would normally make coding such a beast a hassle.
I wouldn't be very concerned about optimum routes or the gateway not
being able to keep up with the networks.  After all, anything would be better
than the 0 baud link I started with.

I'm not sure what I'm supposed to conclude from your observation that
such a gateway is a level 2 packet switch.  Aren't the ARPAnet IMPs
level 2 packet switches?  It's not really that different of an
application in the simple situation.

But then, I don't have any ethernets, so I may be full of it.
Date:      Tue 23 Apr 85 14:57:59-EST
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        don.provan@CMU-CS-A.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA
Subject:   Re: Ethernet gateways..
	Well, like I said, there are some cases where a bridge is
useful. The one you mentioned (connected together two ISOLATED
Ethernets) is such a case. However, in this day and age I think it is
very unlikely (except in the commercial world) for networks to exist
in isolation. As soon as you take those Ethernets and connect them to
the Internet, you are better off with the interconnection being a
	I'm also dubious about the statement that it "seems to
sidestep several issues that would normally make coding such a beast a
hassle".  To begin with, I don't think that most sites should be
involved in building such things, just like you don't normally build
CPU's or operating systems for support purposes (as opposed to
research). You just go out and buy a box that does the right thing.
Secondly, systems always grow, and things like loop detection (needed
if you have redundancy, which is usually desirable) are problems in
any packet switch system. See the papers on the DEC bridge, where they
address these problems. In all but the most toy layouts generic packet
switch problems appear. Since network systems tend to grow rapidly
once available, toy installations soon become non-toy, and if you
don't plan ahead for the problems they zap you.

	Yes, the ARPANet gateways are level 2 packet switches. They
fact that they are, and that that fact is not visible at level 3,
is becoming an immense drag. Consider; an FTP from Harvard to Stanford
might profitably go over the ARPANet to BBN, over the high speed
satellite net to SRI, and back over the ARPANet to Stanford. However,
the fact that the ARPANet looks like a monolithic link at level 3
prevents this, since no information about connectivity and loading
in the IMPs makes it up to the routing layer in level 3.

Date:      Tue 23 Apr 85 19:13:26-PST
From:      Mark Crispin <Crispin@SUMEX-AIM.ARPA>
Subject:   NRC Report
I have just finished reading the NRC report.  I find myself feeling
rather dissatisfied with it.  It reads as if the NRC was charged to
come up with an n-page justification as to why DoD should migrate
from TCP to TP4 and that "if you can't dazzle them with brilliance,
baffle them with bullsh-t."  Given some of the names on the council,
I wonder if this isn't far from the truth.

Specifically, a great many issues are pushed aside quite casually
with comments such as "it is expected that ISO will specify", "it is
quite likely that...will [happen soon]", "a program of testing and
development would minimize these risks", "the impact of this is
uncertain...neither is better than the other".  First the document
acknowledges the great many TCP implementations in existance then
it proceeds to state that all the vendors will rush to implement
TP4 and ignore TCP.

I may be willing to believe all these statements, but I am appalled
by the lack of substantiation offered.  I see no hard data for any
of the several TCP => TP4 migration issues:
 . cost - what are the actual costs involved in converting DoD's
   networks over to TCP.  It isn't enough to state that software
   will be available off the shelf -- what about machines that are
   operational now but don't have any commercial vendor developing
   software for them.  What are the costs of retiring/replacing vs.
   DoD development of TP4 support software for them?
 . protocol operation - have any serious operational studies been
   made comparing TCP vs. TP4 in a production environment?

I am not satisfied at all with the pat-on-the-head assurance that
ISO will come up with suitable Internet layer specifications to
provide the functionality of ICMP and EGP.

I imagine it is too late to ask for any of this now (presumably a
decision has already been made), but I really wish that more hard
facts and figures had been presented instead of repeated assurances
that all would be well and that the market sector would take care
of DoD from now on.
Date:      Tue 23 Apr 85 23:11:21-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
Subject:   NRC report
     I don't want to be placed in the position of blindly saying the
NRC's recommendations are blind/wrong or not well-thought-out.  Now
that I've read it, my main criticism is that it is not convincing.
A rather vague set of promises and some rather sweeping statements
are made with no hard data to back them.

     I am also concerned that if the NRC's proposal is adopted and
TP4 does not pan out, the damage to the existing ongoing TCP development
effort may be serious enough to be a major impact on the operational
Internet.  Whether or not TP4 is a "co-standard" as opposed to a "new
standard", the fact remains that TP4 would be there to replace TCP.
It's hard to imagine continued TCP development work in the face of such
an impending migration.

     In order to support a migration from TCP to TP4, the Internet
community is going to require better reasons than those the NRC report
Date:      Tue 23 Apr 85 23:52:30-EST
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: NRC Report
	I don't think I've heard from anyone (except the authors) who
had nice things to say about this report. There are many substantial
problems, some of which you noted, which have not been rebutted by
those of the authors who defended the paper in this forum.
	Note that this report is in fact a recommendation, and is not
necessarily binding on the DoD. Can anyone on this list (perhaps from
DCEC or DCA or suchlike) tell us what the reaction is in those
quarters to the substantive problems with the recommendation raised by
Mark and others? Is the die in fact cast, or will the points raised
by people in the Internet community be considered when the DoD
makes its decision about what to do?

Date:      Thu 25 Apr 85 01:46:19-EST
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        JNC@MIT-XX.ARPA
Subject:   Info needed: TCP for VMS and MOS LHDH driver
	I am looking for two pieces of information. First, does
anyone know of TCP implementations for VMS? I know that there
is one from Wollongong but don't know how good it is or how
much it costs. Any others? Second, I need an LHDH driver for
PDP11 MOS. Anybody have one? Thanks..
Date:      25 Apr 1985 02:57-EST
To:        JNC@MIT-XX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Info needed: TCP for VMS and MOS LHDH driver
Wollongong is reputed to be fairly good but buried pretty deep in the
VMS kernel.  NRC (the people who bring you hyperchannel) are doing one
for VMS, but dunno the timeframe for delivery.

Date:      Thu, 25 Apr 85 12:41:37 pst
From:      engvax!KVC@cit-vax
To:        ."cit-vax!tcp-ip@SRI-NIC.ARPA"@__ENGVAX
Subject:   Re: TCP/IP for VMS
There are (were) three implementations of TCP/IP for VAX/VMS that I
know of.

The most popular is probably the Wollongong one.  As I understand it,
it's a port of the UNIX kernel networking code to VMS in the form of
a (large) device driver.

Tektronix wrote a TCP/IP for VMS some time ago for their own internal
use.  They have been distributing it outside of Tek for a year or two
now.  It takes the form of an ACP (similar to the DECnet ACP).  Advantages
are that it's free and you get complete source.  Disadvantages are that
you cannot expect support from Tek.  Informally, however, they've been
pretty good to me about sending updates, etc.  Also, the source is in BLISS,
which could be a problem if you don't have a BLISS compiler.  It probably
isn't as complete as the Wollongong stuff.

There used to be a TCP/IP from someone called COMPION.  Distribution was
taken over about a year ago by someone else I'd never heard of before
called FlexComm.  Don't know very much about this, except it looks fairly
complete from their information packet.  I heard rumours a long time ago
that it was slow.  That may not be true anymore.

Since I have the Tek TCP/IP, that's the only one I know a lot about.  The
others are fairly expensive, but if you don't want to support it yourself
that's probably worth paying for.

Contacts for the three packages are:

	FlexComm Corporation                - this address is a year old
	15245 Pacific Highway South         - product was called ACCESS
	Seattle, Wa. 98188
	(206) 243-1641
	The Wollongong Group                - also a year old address
	2103 El Camino Real
	Suite 104A
	Oceanside, Ca. 92054
	(619) 439-5083

	Tektronix:                          - this number worked a few weeks
	Noelan Olsen                        - ago
	(503) 627-5278

Hope this is useful to someone

	/Kevin Carosso         engvax!kvc @ CIT-VAX.ARPA
	 Hughes Aircraft Co.
Date:      Thu 25 Apr 85 14:27:32-PST
From:      Francine Perillo <PERILLO@SRI-NIC.ARPA>
To:        don.provan@CMU-CS-A.ARPA, CERF@USC-ISI.ARPA
Cc:        JNC@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Info needed: TCP for VMS and MOS LHDH driver
The April 1985 version of the TCP/IP Implementations and Vendors
Guide has references to all the products mentioned in this list
during the last few days.  Please FTP a copy from the SRI-NIC host
using pathname

Date:      Thu, 25 Apr 85 16:45 EST
From:      don.provan@CMU-CS-A.ARPA
Cc:        JNC@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Info needed: TCP for VMS and MOS LHDH driver
According to Hardcopy, NRC "is releasing" a network product called
Fusion that supports IP/TCP.  The article makes it sound pretty good,
but then, all Hardcopy articles make their subjects look good.
You can get more information, apparently, by writing them:
	Network Reseach Corp.
	1101 Colorado Ave.
	Santa Monica, CA 90401

In case you want to look up the article, it's in the April, 1985 issue.
Date:      25 Apr 1985 22:21-EST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Excelan

Has anyone had any experience with the EXCELAN TCP/IP?  I have been
asked about this but have not had any introduction or experience with

thanks in advance.

Vint Cerf
Date:      26 Apr 85  0550 PST
From:      Joe Weening <JJW@SU-AI.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Domain names
To allow a smooth transition to the new domain name system, I suggest that
as hosts make the change to their new names, the NIC should update
HOSTS.TXT with these names.  (Keeping the old ones as nicknames, perhaps.)
Otherwise when a host that does not yet query name servers tries to reply
to mail containing a new domain name, it will fail.

The point of adding the ".ARPA" names to HOSTS.TXT a while back was to
make sure that everyone is able to parse domain-style names; hence there
should be no technical problems in adding the new names.


Date:      26 Apr 1985 0717-PST
From:      Contr23 <CONTR23 at NOSC-TECR>
To:        TCP-IP at SRI-NIC
Subject:   tcp etc for vms
Here at E-Systems we are currently implementing ip,tcp,ftp,telnet,smtp
for the vax 11/780 vms. The work is a port of code we developed for an
embedded m68000 system. It is written completely in Ada. We are now testing
using our two vax's connected be ethernet.

This is not a commercial product as such. The original code was developed
using the telesoft compiler, and therefore contains many workarounds to
accomidate that compilers limitations (it is a subset compiler). We are
currently using the dec compiler, but since we are also supporting the
68000 version, we cannot make wholesale changes to the code until
a more adequate compiler is also available for that micro.

We are under contract to MIS JPMO for this effort, which is part of the
'nosc tools'; therefore the source code will be available to all who
desire it. It currently is not on the net, but will be within the next

We are also hoping that we will get the opportunity to further develop
this code to result in a bone fide public domain highly useful portable
implementation of the protocol suite. I will update this list on our
progress and some preliminary results in the next few weeks.

Paul Higgins
E-Systems, ECI division.

Correction: We are under contract to WIS JPMO. That acronym is misspelled
Date:      Friday, 26 Apr 1985 11:47-PST
From:      imagen!geof@Shasta
To:        shasta!CERF@USC-ISI.ARPA
Cc:        shasta!tcp-ip@SRI-NIC.ARPA
Subject:   Re: Excelan

I can tell you something about them, although I have never actually
held an excelan board in my hand, so to speak.  Excelan has two
multibus boards that contain front-end processors and Ethernet
interfaces.  The cheaper (older) board uses an 8088 and a state-machine
based Ethernet interface.  This is now deprecated in favor of a newer
board that uses an 80186 and the Intel 82586 LAN controller.  The
boards can be purchased with "base" software, can boot software from
the main host, or can be configured with TCP-IP ROM's.  The TCP-IP is a
port of the BBN code (I'm not sure if they took it direct from BBN or
via Berkeley.).

The board acts as a multibus master, and uses a message-passing
protocol to communicate with the main processor.  The TCP software
appears to be "done right" -- it is possible to send and receive
Ethernet, Internet, and UDP packets, as well as data from TCP
connections.  Last I saw, the boards implemented ARP, although you had
to "enable" its use somewhere.  I have seen connections between Excelan
boards and SUN's and IMAGEN's and PYRAMID's, at the Usenix conference
TCP demonstration last spring.  The Excelan board thus appears to meet
the specs sufficiently well to be useful.

Excelan also has a Unix driver for their board that they will sell you.
The driver implements a 4.1C socket interface (maybe they have 4.2 by
now -- they are almost the same anyway) to TCP.  They also have at
least RLOGIN and RCP (don't snicker, I agree with you).  I don't know
about FTP, TELNET, and SMTP (although you can presumably port the
berkeley sources very easily if you have access to them).

The last I heard, the performance from the 8088 -- as expected -- was
limited to about 80-100Kb/s total throughput (all connections).  The
80186 and some software tuning apparently fix this problem.  I don't
think that they make claims anywhere near the 1 Mb/s FTP claims of CMC
for THEIR board (10 MHz 68k + Lance chip).

The price (I haven't a recent price list) I seem to remember as being
around $1100 for the 8088-based board and around $1700 for the faster
board.  Maybe someone out there has better numbers than these.

- Geof Cooepr
Date:      Fri, 26 Apr 85 12:48 EST
From:      Charles Hornig <Hornig@STONY-BROOK.SCRC.Symbolics.COM>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        salex@RICE.ARPA, jnc@PROTEON.ARPA
Subject:   an experiment with domain names
Since we at Symbolics have switched to using our domain name, we have
had some trouble with other mailers not understanding them.  To see how
bad the problem was, I did a survey of the 1008 hosts advertising SMTP
service in the NIC host table.  I opened a connection to each of them
from my machine and followed the following script for a simple mail
relay from that host back to my mailbox.

(220 Greeting message)
(250 Response)
(250 Resonse)
(250 Response)
(354 Response)
Test message to TARGET-HOST.ARPA.
(220 Response)
(221 Response)

The Symbolics.COM domain is registered with the NIC and both of its
domain servers were running at the time of the test.

Here are my results:

383 hosts were not up, not accessible, or refused the connection.
 40 hosts refused to relay mail.
 54 hosts complained about an unknown user name.
 39 hosts complained about an unknown host name.
 62 hosts complained about an unknown domain name.
 43 hosts gave a variety of other errors or reset the connection.
387 hosts accepted the mail.

Of the 387 hosts which accepted the mail, I have received the 
following responses:

  5 from our local SCRC mailers.
  1 piece of normal relayed mail.
  2 notes from postmasters about strange conditions:
      --> a mail loop
      --> a host sending mail to itself

I am not heartened by these results.  Maybe we should go back to .ARPA,
which people at least understand?

Congratulations to PROTEON.ARPA, for being the only non-Symbolics mailer
to relay the mail properly.

Date:      26 Apr 1985 1452-EST (Friday)
From:      jrodrig@EDN-VAX (Jose Rodriguez)
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Excelan

A friend of mine integrated their outboard implementation (ethernet, 
I think) to a well known machine without a large effort. Considering
that an inboard implementation of TCP is non-trivial I guess 
the Excelan product helped them a fair amount. I have seen the specs of
their HFE protocol and they use a half reasonable scheme on top of
dual ported memory. I have no figures on performance but at least 
it should not be too bad. 

(By the way I am talking about their TCP/IP/Ethernet Multibus product)

SDC McLean R&D

Date:      26 Apr 1985 17:15:15 EST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   On your experiment with domain names

I love your experiment. I quickly taught most of our fuzzballs how to tangle
through the name-server jungle to get to your zoo. At the moment the
fuzzy namesolvers can do that magic, but tcp connections to your host time out. On the other hand, ICMP
echoes do work. Assuming your fe-mailer has temporary palsy, I left one
fuzzy ( knocking on that door with an smtp greeting message.

One of the troubles found here is that name service via the NIC is flaky
due the multi-homing problem mentioned previously. Another seems to be
that your name servers and friends do not
return an authoritative "not found" for unknown hosts in the
domain. Rightly or not, our namesolvers report "server not responding" unless
either an A record appears in the answer section or a "not found" is returned.

Try tickling,, or with your script.

Date:      29 Apr 1985 1839 PST
From:      Ron Tencati <TENCATI@JPL-VLSI.ARPA>
To:        tcp-ip@sri-nic
Subject:   Imminent Domains

I guess I'm a little confrused.  In order to use the new domains, does my
smtp program have to be rewritten, or can mail be forwarded to sites known
to have domain servers, and will they route to the proper destination.

I have not had time to read the latest RFC's, so I apologize for my
ignorance until I do read them.

Date:      Mon, 29 Apr 85 15:13:24 EDT
From:      Mark W. Terpin <MWT@MIT-MC>
To:        tcp-ip@SRI-NIC
Subject:   Excelan info
I've been using the Excelan board somewhat in conjunction with
a TI NuMachine Unix running V7, and didn't have too much difficulty 
adapting the Excelan Unix driver to work.  The only hard
part was getting the nubus/multibus mapping to work.

The Unix driver seems to have been culled from the 4.2 sources.
It comes with servers and user programs for ftp, rlogin, rsh, and
telnet.  It doesn't have smtp, although they do provide a 'fake
uucp' which uses tcp, that can be used to transmit mail, although
I never installed it.

ARP does sort of have to be enabled... basically, when you install
it, you just have to give the '-e ARP' option to the netstart
command in the /etc/rc file.   This causes it to set a certain bit 
in the 8086 binary for TCP which gets downloaded to the 
Excelan board.  

The performance is decent, considering it's a model 101 with
an 8088, and I'm using polling instead of interrupts -- it's
been about as fast as the Chaos implementation on the NuMachine
which uses a 3Com board.   I could run some benchmarks if anyone
is interested.   (Excelan distributed some benchmarks with their
latest software release a couple months ago, that were run
on some Intel Unix workstation (whose processor is about twice
as fast as the NuMachine's I've been told), and they reported
to get 260 Kbits/second host-to-host throughput with the model 101
and 630 Kbits/second with the model 201, which has an 80186).


Date:      Tue 30 Apr 85 00:03:26-PDT
From:      Mark Lottor <MKL@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   An extra bit
Disclaimer:  This is a personal opinion based on the
experiences of a few people.  The contents of this
message are not in any way connected with SRI International.

We just spent 3 weeks debugging a problem with a 'homebrew'
Ethernet interface.  The problem was that we could talk to
3Com boards just fine, but we couldn't communicate with
any Interlan boards.  Well, to make a long packet short,
we finally discovered the problem.  We were transmitting
ONE extra bit at the end of our packets.  According to
the Ethernet specs, this is acceptable and receivers
should truncate excess bits to an even number of octets.
The Interlan boards we used (about 10) did not do this
and just threw the packets away, some of them never even
reported seeing any packet go by.  We therefore conclude
that the Interlan board is in violation of the Ethernet spec.
Date:      30 Apr 1985 11:27:37 PDT
Subject:   re: Imminent Domains

Ron Tencati:

No and Yes.  The first thing should be that funny names start appearing in
the HOST.TXT file you copy from the NIC.  Your SMTP should be able to handle
that already -- if not, you better get to work right now.  In a few months,
many hosts will be using the domain service for listing their names and
looking up other host names.  You should have a plan for converting your
SMTP to use the domain service by 15-July-85.  You really should review
RFC-921 (It is only 13 pages).

Date:      Tue, 30 Apr 85 11:49:15 pdt
From:      bellcore!sabre!martin@Berkeley
To:        tcp-ip@sri-nic.ARPA
Cc:        bellcore!ucbvax!imagen!geof@Berkeley
Subject:   Re: Excelan
We have unibus excelan boards (exos/204) in some 5.0 vaxen's and they
work well. the tcp/ip is a good implementation and we now have the
code to deal with routing, so we can talk via gateways. they do have
arp. we are talking to pyramids/suns/4.2vaxens/mit pc's.

the library functions (to access files like /etc/hosts) are not the
same as 4.2, but they claim they are changing that. i have got 4.2 
programs to work without to much trouble.

martin levy
Date:      Tuesday, 30 Apr 1985 17:27-EDT
From:      lfried@Mitre-Bedford
To:        tcp-ip@sri-nic
Cc:        lfried@mitre-bedford
Subject:   Performance of TCP-IP

	I am looking for data on the impact on system performance of
 using tcp/ip; also on the pros & cons of implementing these protocols
 in a FEP vs main processor. Any information on packet processing overhead
 due to the tcp and ip checksums would be useful. Personal experiences
 with these issues or references to publications dealing with them would
 be appreciated.

		L. Fried
Date:      30 Apr 85 22:45:25 EDT (Tue)
From:      Mike Minnich <mminnich@UDel-Huey.ARPA>
To:        lfried@MITRE-BEDFORD.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Performance of TCP-IP
The Computer Systems Research Group at Berkeley recently published
a technical report on this topic that will give you some numbers
on protocol processing overhead in UNIX 4.2BSD.

Report No. UCB/CSD 84/217