The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for February 1986 (123 messages, 66342 bytes)
NOTICE: recognises the rights of all third-party works.


Date:      4 Feb 86 02:07:01 EST
From:      Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   TOP (ISO) addressing
Apparently a few people on this group are interested in the ISO
protocols.  At least there has been enough interest to post some
of the standards as RFC's (for which I am grateful).  So I hope
there may be someone who can answer a question:

I have been looking at the specifications for TOP.  (For those who
don't know what this is, this is the most likely candidate among
the ISO protocols for a replacement to TCP/IP in the environment
where most of us use it.  ISO is a large family of protocols.
It provides alternatives at many steps, and leaves a number of
things unspecified.  MAP and TOP are specifications that make
choices where choices are needed, and that fill in the unspecified
details.  MAP is intended for manufacturing, whereas TOP is
intended for the office or research environment.  MAP and TOP are
really a family, and make similar choices where there is no
specific reason to do otherwise.)  If I undestand all of the
verbiage correctly (and the probability is high that I do not),
it looks like TOP is likely to run out of address space.  As I
read the spec, an address contains two major parts: a two-byte
subnetwork number and a variable component which for most of us
will turn out to be the host's Ethernet address.  It seems to
me that 16 bits is not very much for the subnetwork number.
As I understand it, the subnetwork number will have to be
globally unique (i.e. no other subnetwork in the world can
have the same subnetwork number).  Even if that is not said in
the spec, it seems clear that it is going to have to be the
case if we are going to allow for the possibility that subnetworks
will communicate with each other over common-carrier X.25 networks
or the Arpanet.  Furthermore, it is said that routing through
gateways is to be based entirely on the subnetwok number.  This
seems to imply that places like Rutgers that are class B
Internet sites will need to use a separate TOP subnetwork number
for each of our internal subnets.  So in practice, it seems
like we are going to need roughly one subnetwork number for
every Ethernet that runs TOP.  I find it hard to believe that
16 bits will be enough.

Does anyone see an error in this argument?
Date:      4 Feb 86 09:43:00 PST
From:      "
To:        "hedrick" <hedrick@rutgers>
Cc:        tcp-ip@sri-nic
Subject:   RE: TOP (ISO) addressing
> Apparently a few people on this group are interested in the ISO
> protocols.  At least there has been enough interest to post some
> of the standards as RFC's (for which I am grateful).  So I hope
> there may be someone who can answer a question:
> I have been looking at the specifications for TOP.

         [deleted text]
> If I undestand all of the
> verbiage correctly (and the probability is high that I do not),
> it looks like TOP is likely to run out of address space.  As I
> read the spec, an address contains two major parts: a two-byte
> subnetwork number and a variable component which for most of us
> will turn out to be the host's Ethernet address.  It seems to
> me that 16 bits is not very much for the subnetwork number.
> As I understand it, the subnetwork number will have to be
> globally unique (i.e. no other subnetwork in the world can
> have the same subnetwork number).  Even if that is not said in
> the spec, it seems clear that it is going to have to be the
> case if we are going to allow for the possibility that subnetworks
> will communicate with each other over common-carrier X.25 networks
> or the Arpanet.  Furthermore, it is said that routing through
> gateways is to be based entirely on the subnetwok number.  This
> seems to imply that places like Rutgers that are class B
> Internet sites will need to use a separate TOP subnetwork number
> for each of our internal subnets.  So in practice, it seems
> like we are going to need roughly one subnetwork number for
> every Ethernet that runs TOP.  I find it hard to believe that
> 16 bits will be enough.

The Top spec is very early in its development (at V1.0).  TOP
is intended to interoperate with MAP at the Network, Transport
and Session layers.  For interoperation at the Network layer,
both MAP and TOP will have to use the same addressing formats.
The MAP 2.1 spec calls out three Network address formats allowed
by the ISO address rules.  One of these formats has a CCITT
administered Initial Domain Identifier (IDI), and the other two
formats are for locally administered addresses.  The address
format in the V1.0 TOP spec is not compatible with any of these.
The TOP spec appears to call out the address format that was
chosen for the Autofact show and I believe is also the NBS OSINET
format.  Also, routing protocols are not currently defined.
Routing and congestion control will be absolutely necessary
before ISO protocols could be used in the DoD community.
MAP 3.0 is supposed to include network routing and management

There is a recently established distribution list for ISO protocol
discussion: <>.


Date:      Tue,  4 Feb 86 16:17:59 EST
Subject:   802.2 SAP for ARP
I'm trying to get an extended (48 bit) one.
We'll see how I do. I'll report next week.

					John Shriver

Date:      Tue 4 Feb 86 22:43:09-PST
From:      Mark Crispin <Crispin@SUMEX-AIM.ARPA>
     Right now, the core gateways claim that FORDNET (128.5) is
unreachable.  However, FORD-SCF1 is sending SYN's at SUMEX's SMTP
server at an alarming rate, tying it up so that very little mail
is coming through.  Either some dumb gateway is forwarding these
packets from FORDNET, or the DCN-GATEWAY is doing so without telling
the EGP world about it.

     Somebody please stop FORD-SCF1 and/or the gateway.

     By the way, I think it is very antisocial of a mailer to
repeatedly SYN a port for hours.  It ought to take no for an answer
and go to sleep for a bit before trying again.
Date:      5 Feb 86 10:06:00 PST
From:      <>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   RE: iso-request@acc-sb-unix

My appologies to anyone who failed attempting to send to
<> wishing to get on the ISO mailing.
Iso-request should now work properly (It ends up coming to me


Date:      Wed, 5 Feb 86 08:18:38 EST
From:      Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
I see lots of similar things (routing) since the core gateway egp tables got
full. What I see happening from lots of hosts is that I receive datagrams
(mostly SYNs or UDP Domain requests to our domain server) to which I respond.
The responses bounce at the gateway since it does not find the entry in the
egp table and sends an ICMP net unreachable back to me. The frequent
retransmissions are a different problem which also showed up in a much
elevated way since the egp problem appeared since I get the data but the
response is not able to get back. We could use this situation as a tool
to find lots of flakey implementation because the retransmission problems
are much more easily visible.
Date:      Wed, 5 Feb 86 11:45:11 est
From:      Nathaniel Mishkin <apollo!>
To:        apollo!
Subject:   4.2bsd UDP/IP Bug?
For reasons that don't bear explanation, I recently had to look through
the 4.2bsd "tftp" server and client code.  I saw some strange things
that led me to wonder how UDP works under 4.2 and how it's supposed to

I saw that once the server gets a "request" packet on the "tftp" well-known
port, it forks.  The child continues to read on the same file descriptor
(port).  The parent goes back to the top of its listen loop, creates
a new socket, and binds its end to the "tftp" well-known port again.
According to my understand of how UDP is supposed to work, if the
implementation is correct, then "tftp" could never work since both the
parent and the child would be reading packets from the same port -- it
would be random which were gotten by the parent and which were gotten
by the child.  The apparent reason things work on 4.2 is because the
kernel demultiplexes incoming UDP packets based on BOTH the packet's
local AND foreign port.  If I understand the UDP/IP spec, this is a bug
-- you're supposed to demultiplex incoming packets by looking ONLY at
the local port.

Do I misunderstand UDP?  Is 4.2 broken?  Is 4.3 fixed?  Please respond
to me since I'm not on this list.

            -- Nat Mishkin
               Apollo Computer Inc.

Date:      5 Feb 1986 12:02:57 EST
In response to the message sent  Tue 4 Feb 86 22:43:09-PST from Crispin@SUMEX-AIM.ARPA


No, you have it wrong. FORDnet is being actively asserted as up via EGP
from DCN-GATEWAY, which it in fact really is. You are seeing IDMP
Destination Unreachable messages returned from FORDnet host FORD1,
since the particular subnet used by the offending host appears
down at that host, which is in fact a subnet gateway. The infrastructure
supporting connectivity to the offending host is presently working
correctly; however, your comments re the host itself are well taken.
Please direct your comments to John Nagle (, who is the
responsible person for those Ford Aerospace hosts.

Date:      Wed, 5 Feb 86 15:06:14 EST
From:      Ron Natalie <ron@BRL.ARPA>

I wouldn't quite blame the non-core gateways for this.  It is hardly
there fault that the core-IGP doesn't work.  Currently EGP is in a
state that you have to very carefully meter how you deal with the
core, e.g. you have to watch which core-EGP speaker you load your
routing table with, you've always had to discard entries for your
own networks, etc...

Date:      Wed, 5 Feb 86 19:27:45 -0200
From:      mcvax!imag!pierre@seismo.CSS.GOV (Pierre L. LAFORGUE)
To:        info-vax@sri-kl.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Submission about TCP/IP under VMS
May you think appropriate to post this in your moderated newsgroups?
Thank you very much in advance, if possible.

To insert a VAX/VMS on an Ethernet linking heterogeneous Unix computers,
and later Microvaxes/VMS, we are looking for a TCP-IP software running
under DEC/VMS, and supporting possibly NFS. 
We received no response from Wollongong, but a proposition from GEC-Software
(132-135 Long Acre LONDON WC2E9AH G.B. , Tel 01-2407171) which offers 
TCP-IP and a gateway with DECNET named "Dbridge". As I saw somebody seeking
vendors of TCP-IP, this information should be usefull to him.
My questions are :
1- Is there anyone who experienced the TCP-IP/VMS of GEC-Software ?
   Is it possible to use all of the application level Unix stuff with it,
   as rlogin, rwho, from Unix and from VMS ?
2- Does anybody know a source for NFS/VMS ?
Thank you very much to answer to: pierre@imag.UUCP
(or ...!seismo!mcvax!vmucnam!imag!pierre)
Date:      6 Feb 1986 00:18:35 EST
To:        ron@BRL.ARPA, Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
In response to the message sent      Wed, 5 Feb 86 15:06:14 EST from ron@BRL.ARPA


Careful peruse of RFC-904 should reveal an EGP stalwart should in fact report
every network directly reachable from its own autonomous system, which includes
the net common with the core gateway. With that bit, you should not be surprised
if said core gateway hands your net back to you. In fact, DCN-GATEWAY peers
with up to three core gateways and an odd-lot non-core gateway or two sometimes,
but with unspectacular consequences. Turns out, if you believe EGP hop counts
sent by core gateways (i.e. from the same system) hop counts can be compared
and all except the lowest discarded. This, however, is an unadvertised feature
the existence of which could probably be inferred from the tortuous history of
this protocol and the personality of its developers. What else can be said, except
stay tuned for more formal proposals in this area that might even legitimize
this inference. You did not hear me say these words.

Date:      05-Feb-86 20:50:22-UT
Subject:   Conversations with an Ethernet watcher

Further to my recent note and the previous notes from Mark and Hans-Werver. I
watched packets wade through our DCnet Etherswamp and found alligators still
munching. Briefly, that swamp includes gateways to ARPANET (56K bps), UMICHnet
(9.6K bps) and FORDnet (9.6K bps), as well as a raft of other swamp creatures.
Thus, I can see all packets flying between DCnet gateways and in some cases
the subnet gateways on FORDnet and UMICHnet. The hosts lurking on the subnets
include 3COM, 4.3bsd, Wollongong, Sun, fuzzball and even more bizarre
creatures scattered all over the country. The subnets are connected mostly by
multiple 9.6K bps lines and fuzzball gateways, which run a dynamic routing
algorithm that functions both at the net and subnet level.

As you might expect, we take moderate to severe congestion hits when things
break or when hosts on any of the nets misbehave, which seems fairly often
these days. Mark and Hans-Werner report only the tip of the swampberg, to
phrase a coin. Following is a quick summary of my Etherwatch, captured in the
interval between curiousity and eyestrain and intended not so much as a
specific problem report as a generic speculation on what might be happening in
other ponds.

1. Congestive collapse. When things get really bad the fuzzball routing
   algorithm will occasionally declare a line down, which can activate a
   secondary path, but only after a period of hold-down and possibly
   non-reciprocal connectivity (we call these "one-wire feeds" after a term
   used in the radio/TV broadcast community). When this happens transient
   black holes and ICMP error messages can originate at the strangest places.

2. Black holes. Not all subnet gateways subscribe to the fuzzball routing
   algorithm; in particular, some FORDnet subnet gateways. The fuzzballs
   thus cannot determine reachability and do not generate ICMP error messages.
   Unfortunately, this situation now holds (since Mark's complaint) for all
   FORDnet subnets except 128.5.0. Mark will henceforth get no error messages
   at all when Ford Aerospace gateways or lines west of Dearborn are blitzed.

3. Disregarding error reports. I see what appears to be almost universal
   disregard for ICMP error messages. Certainly Unix and TOPS-20 users
   remain blissfully ignorant of these things, which many gateways, including
   the core gateways and fuzzballs, take some pain to get right. Thus, the
   casual user has no hard evidence to beat up the system or net maintainers.

4. Mismatched routing dynamics. EGP dynamics are very slow compared with most
   IGP dynamics, including the fuzzballs. Thus, nets on the business side of
   our EGP gateway, for example, can flap up and down with the effect that EGP
   advertisements may disagree with the actual routes delivered. Our own
   warranty has a clause relieving liability during transient periods up to
   several minutes.

5. Hidden gateways. There is a lot of subnet plumbing in our waterworks, some
   of it rather leaky (in the best and most common tradition). Thus, ICMP
   error messages can originate at a subnet gateway or even a host without
   implying problems further up the pipe. Unless the recipient of such an
   error message is aware of the subnet configuration, it might mistakenly
   assume the primary (net) gateway is broken.

6. Protocol problems. Certain hosts tapping our plumbing make rather good
   random-noise/congestion generators (not our DCnet hosts, of course). I
   watched Wollongong generate between 1.5 and 5 ACKs for every
   TCP data segment just now. I also saw 4.3bsd(?) and
   get into ACK-ACK fights. Host apparently has a bunch (3) of hung
   TCP connections sending something every few seconds but ignoring what
   appear to be valid reset segments from The and hosts advertise, probably unwisely, windows of 2048 and 4096
   octets respectively, which is much larger than necessary (two to four
   seconds at 9.6K bps) and almost guarantees gateway congestion. Almost every
   initial-connection attempt involves at least two and up to five
   retransmissions at intervals much less than the estimated roundtrip delay.

7. Fairness abusers. Why do some hosts (, among others) open multiple
   parallel SMTP connections to the same host? This might represent a
   misguided attempt to "optimize" the delivery delay, but certainly makes the
   congestion problems that much worse. There are two such connections right
   now between and and three between and No wonder our poor fuzzthings get eaten by the alligators.

8. Tinygrams and jumbograms. Occasionally I see connections across the net
   with probably unwise selection of maximum segment size MSS, with a
   particularily uncomfortable choice of 1024. This guarantees fragmentation
   at least once somewhere on the path and usually twice, as well as clogs
   reassembly resources in congested weather. Smaller values less than the
   ARPANET maximum (906-odd) are much more appropriate. In fact, gains in
   efficiency on many paths with MSS greater than 576 are lost due to
   congestion, itself due to lower buffer-space utilization. At the other end
   of the spectrum, vast spasms of tinygrams (usually character-at-a-time
   TELNET) continue to flood the swamps, in spite of well-documented fixes
   for this.

Date:      Thu, 6 Feb 86 05:31:19 pst
From:      Earl Craighill <ejc%sri-gemini@sri-tsc>
To:        iso-request@acc-sb-unix
Cc:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   RE: iso-request@acc-sb-unix

Please put me on the iso mailing list.  The safest address to use is

Thanx  Earl
Date:      6 Feb 1986  8:39:25 EST (Thursday)
From:      T. Michael Louden (MS W422) <>
To:        ron@brl
Cc:        tcp-ip@sri-nic
Maybe the solution to much of the EGP related problems it to have BBN
upgrade the core to meet the EGP specs., the problem where the core
says that it is the route to your network strikes me as a dangerous
bug that can easily result in a black hole in the INTERNET.
The less serious problems of incomplete status fields on error messages
and not peering with gateways that are not directly connected should
also be fixed.  I have heard suggestions that the Butterfly gateways
should be used to replace the current 11/23s.  I am concerned that
the code in these will be no better since it comes from the same place.
Date:      6 Feb 1986 10:12:41 EST (Thursday)
From:      T. Michael Louden (MS W422) <>
To:        mills@dcn6
Cc:        tcp-ip@sri-nic,
Your net is not directly reachable from the core autonomous system
since your gateway is not part of the core autonomous system.
The core must us your gateway to reach your net.
Thus I do not understand your comments.

Date:      Thu, 6 Feb 86 11:03:12 est
From: (Scott Brim)
Subject:   Tektronix VMS
We have heard that someone has adopted Tektronix's VMS TCP/IP software
and is "fixing it up" (as is it doesn't know about gateways, for
example).  We've also heard, less reliably, that it is someone at CMU.
We're VERY interested and would like to get in touch with anyone who is
working on this.
						Thanks -- Scott
Scott Brim
Cornell University Theory Center	{decvax,ihnp4,cmcl2,vax135}!cornell!swb
607-256-8686				swb@cornella.bitnet
Date:      Thu, 06 Feb 86 10:11:59 EDT
Subject:   GEC Software
A telephone call to London revealed that the VMS tcp-ip software mentioned
here recently by Pierre is in fact the Wollongong software, exported to
England. They refer all US inquiries to Wollongong. Th

However, I am still interested in the DECnet gateway called Dbridge.
Does anyone have info about that, and is it really a "gatweay" ?

                                                 Bob Dixon
                                                 Ohio State University
Date:      6 Feb 1986 11:31:28 EST (Thu)
From:      Dan Hoey <hoey@nrl-aic.ARPA>
To:        mills@dcn6.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Conversations with an Ethernet watcher
    Date: 05-Feb-86 20:50:22-UT


    7. Fairness abusers. Why do some hosts (, among others) open
       multiple parallel SMTP connections to the same host?

Maybe for the same reason they open multiple TELNET connections--when
a user wants to send a message, I see no reason why the system must
queue it until any current traffic to the destination host is past.
Certainly the ability to queue is useful, but hardly required.

Of course, it could just be that they restarted after giving up on a
catatonic SMTP connection, and they couldn't wake up the corpse enough
to kill it.

Dan Hoey
Date:      6 Feb 86 14:52:00 PST
From:      <>
To:        "ts0400%ohstvma.bitnet" <ts0400%ohstvma.bitnet@wiscvm>
Cc:        tcp-ip@sri-nic
Subject:   DBridge

> A telephone call to London revealed that the VMS tcp-ip software mentioned
> here recently by Pierre is in fact the Wollongong software, exported to
> England. They refer all US inquiries to Wollongong. Th
> However, I am still interested in the DECnet gateway called Dbridge.
> Does anyone have info about that, and is it really a "gatweay" ?

DBridge is part of the Wollongong package.  This is a VMS process which
opens a Decnet circuit to another DBridge process across the Decnet.
The DBridge process uses a raw socket to pass IP datagrams to/from the
local TCP/IP kernel and forward them across the Decnet.  This allows
a TCP/IP network to be layered on top of a Decnet.  If one of the TCP/IP
nodes is connected to a real IP network, it can route IP datagrams to/from
that network.

Date:      Thu, 6 Feb 86 14:09 EDT
From:      Chris Johnson <JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA>
To:, johnson%northeastern.csnet@CSNET-RELAY.ARPA
Subject:   Mystic words and phrases.

     All languages have a set of common words which most people use in 
every day speech.  Then there are various subset for technical fields.  
Networking is no exception to this.  Because or in spite of much use of 
certain phrases there also arises abbreviated forms and shortcuts.  I'm 
usually the first to admit that my ignorance is rife.  In this case it's 
about time I got some enlightenment.  The two specialized terms I am 
currently having trouble with are:

         1) EGP   and
         2) fuzzball

I think I understand them from much context hunting but am not sure.  I
don't have ARPA network stuff here and was wondering if someone out
there in the big wide universe would enlighten me as to the true meaning
of these terms.  Please remember that not everyone who listens to this
list is always in tune.  It would be nice if now and then and
abbreviation was expanded. 

     Thank you.

Chris Johnson
johnson@northeastern                                           (CSNet)
johnson%northeastern@csnet-relay                               (ARPAnet)
Date:      Thu,  6 Feb 86 17:44:58 EST
Subject:   Re: GEC Software
DBridge is not a protocol translator. It is a facility to tranport
IP packets over the DECnet transport facilities. What you get in
ISO layers is
	TCP 	7
	TCP	2 (IP)
	DECnet	4
	DECnet	1
Thus you get to use the web of DECnet point-to-point facilities and
long-haul stuff to move IP packets around. Same idea as IP over X.25.

						John Shriver

Date:      6 Feb 1986 18:35:33 EST
To:        louden@MITRE-GATEWAY.ARPA, ron@BRL.ARPA
In response to the message sent   6 Feb 1986  8:39:25 EST (Thursday) from


In BBN's defense, remember that the LSI-11 gateways were evolved way
beyond reasonable conjecture from the first design, include protocol
support (EGP and VAN) unanticipated in the original design and are deployed
in much greater numbers of gateways and networks than are reasonable
with this design. The Buttergates were evolved precisely in response to
many of the existing problems and, assuming money to pay for them is
found, should eventually overtake the LSI-11s.

The presence of apparent routing loops in updates received from the core
system is an expected consequence of the intrinsic GGP routing protocol used in
the LSI-11 gateways for the last seven years. This protocol, as well as other
similar protocols based on min-hop algorithms can for form transient loops when
various nets bob up and down and the hop-count fields are "counted to infinity."
The problem has been long recognized and has nothing intrinsically to do with
EGP or even the particular implementation, but is an intrinsic problem with
min-hop algorithms. The SPF algorithm developed for the ARPANET and adapted for
the Buttergates should make these loops much less likely.

You might speculate on what might happen if we did not have EGP and peered GGP
directly with the core instead. Before we had EGP there was this incident that
became enshrined in legend and called the Great Commando Raid. Someday either
Mike Brescia or I will include that chuckle in our memoirs. The circumstances
were funny enough and won't be repeated here; however, the result was a new
packet type, called the Kiss of Death (KOD) packet, that killed the recipient,
but not before forwarding the packet to the next victim.

Date:      06-Feb-86 15:21:41-UT
To:        T.MichaelLouden(MSW422)<>, mills@dcn6, tcp-ip@sri-nic

Oop, you are absolutely right. My intent was to point out that ARPANET itself
is legitimate to advertise on the part of both the core and non-core gateways
sharing it. While RFC-904 specifies what a non-core gateway must do, there is
no specification on what a core gateway must do; therefore, we can't beat up
those villans for sending your net back to you. A reasonable sketch of a core-
gateway specification might conclude that is, indeed, broken. My foo-paw was a
thlip of the thongue.

Date:      Thu 6 Feb 86 23:54:44-PST
From:      Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA>
Subject:   [jbn@Ford-wdl1.ARPA (John B. Nagle): FORD-SCF1 now under control]
Another varmint bites the dust.  Thanks JBN!!!

Return-Path: <@SUMEX-AIM,@SU-SCORE.ARPA:jbn@Ford-wdl1.ARPA>
Received: from SU-SCORE.ARPA by SUMEX-AIM.ARPA with TCP; Thu 6 Feb 86 14:04:19-PST
Received: from FORD-WDL1.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Feb 86 13:46:26-PST
Received: by FORD-WDL1.ARPA (5.15/5.9)
	id AA17695; Thu, 6 Feb 86 13:51:59 PST
Date: Thu, 6 Feb 86 13:51:59 PST
From: jbn@Ford-wdl1.ARPA (John B. Nagle)
Message-Id: <8602062151.AA17695@FORD-WDL1.ARPA>
Subject: FORD-SCF1 now under control

     The mailer misbehavior at FORD-SCF1 has been taken care of.  That
machine had been accidentally set up with the Berkeley trailer kludge enabled,
but the other end of the synchronous link was not set up for trailers,
so little packets got through but big packets didn't.  We've also changed
the mailer retry interval from 1 minute to 30 minutes.  This should fix
the problem.

					John Nagle
Date:      Fri 7 Feb 86 00:07:50-MST
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        mills@DCN6.ARPA
Cc:        hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Conversations with an Ethernet watcher
Add my voice to the clamor -- it is a bug or misfeature that Berkeley Unix
has multiple simultaneous SMTP streams to the same host.  SMTP is a batching
type process and overall mailer throughput is more important than the small
gains some messages may gain from multiple streams.

It really nailed SUMEX badly that the nastygrams that hit its SMTP server
came from a Berkeley Unix SMTP mailer.  I tried opening multiple listeners
(a listener just negotiates SYNs then hands the connection off to the server...
normally a very fast task) and the damn host just went and grabbed the new
Date:      06-Feb-86 19:33:37-UT
To:        DanHoey<hoey@nrl-aic.ARPA>, mills@dcn6.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re: Conversations with an Ethernet watcher

I will respond with the voice of Jack Haverty, longtime and intrepid Internet
Engineer. If you really need to open n simultaneous connections, each with full
complement of windows, buffers and whatnot, then we must provide sufficient
buffering at all transit points for the aggregate of all such connections, even
if only infrequently used. However, a little care in the engineering of the
client software can result in major savings in total system cost. The multiple-
connection scenario I reported yesterday persisted for most of the day, from
which I infer either an unlikely multiplicity of users patiently waiting for
many messages to barge through the swamps or the existance of multiple mailer
daemons. The former are obviously patience-limited, so I don't worry overmuch
about them; however, I do worry about the latter.

Jack, who is usually more conservative than I, might toss off the following on
an envelope while waiting for an airplane. The two 2048-octet windows on one
machine and three 4096-octet windows on the other require up to 16K for
buffering on transit systems. If comfortably tucked in 576-octet packets (536
data octets), something like 30 packets could be wandering around our gateway.
A conservative might also observe from my observations that multiple ACKs are
sometimes returned from the destination that an additional number (we'll call
it 30) might be soaked up for traffic toward the source. However, those packets
have to live in real buffer space, which with most hardware and software require
a contiguous region of at least the MTU for the net, in the Ethernet case 1500
octets. Thus, our underpowered fuzzthing would have to cough up 60 1500-octet
buffers, or 90K of memory just for those two hosts. See RFC-970 for an even
less palatable scenario. The little dears only have about a fifth of that in
the present configuration, from which Jack would conclude we should either
pull the plug or convert to X.25.

While Jack and I do kid each other mercilessly, you have to admit he has a point.
The Internet Engineer cum Protocol Cop is seldom seen in these parts.

Date:      Fri, 7 Feb 86  8:41:00 EST
From:      Alex McKenzie <mckenzie@BBNH.ARPA>
Subject:   DEC "LANBridge 100"
Someone recently asked about the "Dbridge" and someone else answered that it
was a piece of software.  I don't know about that, but thought I'd add that
there is a new DEC product called the "LANBridge 100" which is intended to
interconnect two Ethernets.  It learns (or can be told, I think) what Ethernet
addresses are on its side "A".  If it sees any Ethernet frames on the Ethernet
on side A whose addresses aren't on this list, it copies the frames to the
Ethernet on its side B.  If it sees any Ethernet frames on side B whose
addresses ARE in the list, it copies these to the Ethernet on side A.  Thus,
it is at ISO level 2, unlike an Ethernet repeater (a level 1 device) or an IP
gateway (a level 3 device).  I thought it might be possible that this device
was intended in the question about the "Dbridge".

Date:      Fri, 07 Feb 86 12:00:53 EDT
Subject:   Ethernet/T1 bridges
We have need for devices that will interconnect distant (few miles)
ethernets via T1 links, and which have enough intelligence to send
only the needed traffic. All protocols must pass transparently.
We have heard that Vitalink makes such a box, but have been unable to
get any details as yet. Also Applitek can do this, but it takes 2
boxes in series at each end, which doubles the cost.
Does anyone know of other options?
Another alternative is to use something like the DEC Lan bridge for the
intelligence, and then some simpler box for just Ethernet/T1 connection.
But we have been unable to locate such a box. Anyone know of any?
Date:      7 Feb 1986 13:03:30 EST
To:        JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Mystic words and phrases.
In response to the message sent      Thu, 6 Feb 86 14:09 EDT from JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA


You're right, and I apologize for thinking everybody has a psionic tap on
the Old Boy Network (resisting heroically the urge to pun that one). EGP
stands for the Exterior Gateway Protocol, which is used to exchange information
between gateways and is described in RFC-904. As for the fuzzballs, he bleats
sheepishly, they are a bunch of frisky PDP11-compatible workstations used
by some of us to develop, test and evaluate new protocols and nets. See for
reference "The Empire Strikes Back," in which "fuzzball" is mentioned in the dialog. In
point of fact, the fuzz predate the movie.

Date:      Sat, 8 Feb 1986  00:21 MST
From:      "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Subject:   TCP/IP via X.25 connection to DDN
Please tell me I'm wrong...  Last I heard, if a site runs TCP/IP
through an X.25 interface to an IMP, it can talk only to other X.25
sites.  Is this (still) true?

Date:      Sat, 8 Feb 86 23:52:15 cst
From:      rick@ngp.UTEXAS.EDU (Rick Watson)
Cc:        rick@ngp.UTEXAS.EDU
Subject:   Re:  GEC Software
Dbridge is a Wollongong product that allows you to transport IP packets
over a DECnet connection.  It connects 2 hosts running (Wollongong)
TCP/IP.  It uses DECnet for the transport layer.  It does no gatewaying
between DECnet and TCP/IP.

The DEC Lan Bridge 100 is an ethernet level gateway. It also does
no protocol translation.

DEC's DECnet for Ultrix is supposed to do some kind of DECnet to 
TCP gatewaying, but I don't know what yet.  I have this software on
order, so I'll let you know what it does when I get it.

Rick Watson
University of Texas Computation Center
 arpa:   rick@ngp.UTEXAS.EDU   rick@ngp.ARPA
 uucp:   ...seismo!ut-sally!ut-ngp!rick   rick@ut-ngp.UUCP
 bitnet: ccaw001@utadnx
 phone:  512/471-3241
Date:      Sat, 8 Feb 1986  23:07 EST
From:      "David D. Story" <FTD%MIT-OZ @ MC.LCS.MIT.EDU>
To:        Chris Johnson <JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Mystic words and phrases.

1) Electronic Graphics Printer
2) IBM selectric style ball (letter quality)


1) A sixth sense that always means trouble.
2) A spitball but with Newsprint.
Date:      9 Feb 1986 12:34-EST
Subject:   Re: TCP/IP via X.25 connection to DDN

Last I hear, BBN had succeeded in figuring out how to make the
X.25 interfaces and the 1822 interfaces interoperate - whether
this code is in the operational network, however, I am not
sure about. I hope you are wrong but your statement was, at
one time in the past, true, and may still be. 

Vint Cerf
Date:      9 Feb 1986 19:23:52 EST
Cc:        clausen%UKans@CSNET-RELAY.ARPA
Subject:   hello

I want to use a Microvax as a "front-end" for our 750 running Unix
B4.2 and one of the ACC interfaces. Do you know of anybody who has a
Microvax (q-bus!) with an ACC interface and 4.2 with the IP/TCP
software running?

Date:      Sun 9 Feb 86 20:53:26-EST
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
Subject:   Re: Ethernet/T1 bridges
	I will point out to everyone (once again) that bridges have
severe technical disadvantages, especially in a system which is intended
to be connected to the main internet. Now, you should take my words
with a grain of salt, because I have a financial interest in seeing
people use routers (aka 'IP gateways') instead of filtering digital
repeaters ('bridges'), but I was saying this for years before I got
involved with a product.
	I don't want to conduct a technical discussion on this (large)
mailing list; if you don't believe me, retrieve (via anonymous FTP)
the file <JNC>BRIDGES.TXT from MIT-XX; it contains an earlier
discussion on this issue. See <JNC>BRIDGES.LOSE for an example of
a user of bridges losing big.

Date:      9 Feb 86 21:09 EST
From:      Corrigan @ DDN1.ARPA
To:        WANCHO @
Cc:        TCP-IP @, WANCHO @
Subject:   Re:  TCP/IP via X.25 connection to DDN
Interoperation of TCP/IP users using 1822 and X.25 interfaces is
first supported in Packet Switch release 6.0.  We are currently fielding 
this release as required (namely at nodes with x.25 subscribers) in the 
MILNET.  We will be fielding it as the standard release in the MILNET
in the next few months.  We will also field it in the ARPANET as soon
as possible.  The holdup there is upgrading all the switches to the
C-30e configuration.  This should also be completed in the next few

Mike Corrigan
Technical Manager

Date:      09 Feb 86 22:27:29 EST (Sun)
From:      Frederick E Serr <fserr@BBNCC5.ARPA>
To:        "Frank J. Wancho" <WANCHO@simtel20.ARPA>
Cc:        TCP-IP@sri-nic.ARPA
Subject:   Re: TCP/IP via X.25 connection to DDN
Interoperability between X.25 and 1822 hosts is implemented in Release 6
of the PSN software.  Unfortunately, the ARPANET is still running the
equivalent of PSN Release 4.  The hardware on the network is currently
being upgraded to allow installation of PSN 5.  I don't know the official
schedule, but I would guess that PSN 5 will go in sometime in March, and
you won't see PSN 6 until a couple of months after that.  Until that time,
hosts with X.25 interfaces on the ARPANET cannot talk to 1822 hosts.

Date:      10 Feb 86 08:23:00 PST
From:      <>
To:        "wancho" <wancho@simtel20>
Cc:        tcp-ip@sri-nic
Subject:   TCP/IP via X.25

The X.25 connection you mentioned in your 8 February message describes,
what is known as "Basic Mode" DDN X.25.  Although TCP/IP is used for
such things as data integrity, 'Basic Mode' service provides communication
only between a X.25 DTE and other X.25 DTE's.  Specifically, only
a X.25 Host can communicate with another X.25 Host on the DDN.

As DCA has mandated that all host be interoperable with each other another
form of X.25 has been devised which is called "Standard Mode".  This is
to allow hosts which have been previously connected to the net, either
with 1822 or 1822-J (HDH) connections, to communicate with X.25 hosts.
TCP/IP is used as the upper-level protocols to provide continuity and
full interoperablity.

As you may or may not know, DCA is in the process of qualifying various
vendors implementations of the DDN X.25 specification.  It is important
for user evaluation to determine if the vendor has a fully qualified
product in accordance with the test scenarios of the DDN X.25 Standard
Service for achieving full interoperability.

For additional information contact the NIC and request the circular
entitled:  "Defense Data Network X.25 Host Interface Specification,
December 1983.


Gary Krall
Date:      Mon, 10 Feb 86 06:58:24 est
From:      rsparbe@nswc-wo.ARPA
To:        tcp-ip@sri-nic
Subject:   Inter operable X.25
Could someone tell me if the problem I am having with sending mail to one
site could be related to the HDH/X.25 inter operability issue.

We run a HDH and 1822 hosts.  The other sites have X.25 connections.

We cannot send mail to each other.  I know there could be many different
problems, but is it possible the problem relates to the release 5.0 
software running on the net not allowing HDH/X.25 inter operability?

Please answer direct to me at rsparbe@nswc-wo.



Date:      10 Feb 1986 1111-PST (Monday)
From:      Barry Leiner <leiner@RIACS.ARPA>
To:        "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Subject:   Re: TCP/IP via X.25 connection to DDN
Someone from DDN or BBN should respond directly, but let me state what
I believe to be the case.

There are two types of X.25 interface to the Milnet/DDN.  The first,
which was put in place first, was called Basic (for some obscure
reason) and the second called Standard. Not sure if those are still the

The Basic interface is an X.25 end to end service, and was put in place
to support hosts that talk only X.25.  This is supposed to be a
"temporary" interface, as all hosts are eventually supposed to use

The STandard interface is an X.25 interface to the DDN, on top of which
hosts are to run TCP/IP.  My understanding is that, for this interface,
X.25 is terminated in the local imp, and therefore should be
interoperable with other local interfaces, in particular 1822.  


Date:      Mon, 10 Feb 86 09:57:38 EDT
Subject:   Re:  GEC Software
Thanks for the info, Rick.
The word I got from DEC regarding Ultrix (after intense questionning) is that
it supports tcp/ip and DECnet, but does not provide any gateway function.
We urged them to provide such a gateway and even offered to contract with
them to do so, but they said there is not enough market for it, and it is
contrary to company policy. Their policy is to offer token support to
tcp/ip via selling things like Wollongong and Ultrix, but to expend no
real effort on tcp/ip. Instead they are aiming for migtation to future
ISO standards, bypassing tcp/ip.    If you get any word to the contrary,
I'd be anxious to hear it.
Date:      10 Feb 1986 17:14:37 PST
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   SXecurity and Precedence Options
Does anyone know of any implementations of those options?
I realize that the "nodes" "IMPS" in such a network would also have to
properly implement those options (or support them somehow).

Date:      10 Feb 1986 18:04-PST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SXecurity and Precedence Options
Please  note:  There  is  a  revised  version  of the IP security
option.  The IP option as detailed in the IP RFC and the  IP  MIL
STD is "officially" defunct.

To  answer your question, the only implementation I know of which
uses any form of security option is at the 1ISG at  the  Pentagon
on         their         Multics         systems.         Contact         for

Date:      11 Feb 86 08:20:00 PST
From:      <>
To:        "clausen" <clausen@usc-isid>
Cc:        tcp-ip@sri-nic
Subject:   uVAX interface

ACC's interface for a uVAX, termed the ACP 5250, is being shipped to
our beta-site this week.  We are anticipating DDN qualification for
standard mode operation within the next 2-3 weeks.  The first
implementation will support a VMS device driver which will be integrated
into the Internet TCP/IP package.  We are anticipating that support
will follow in fairly short order for Wollongong's package, 4.2 and 4.3,
and Ultrix.  A good lead time for ordering purposes would be 60 days
ARO, to allow for the above to take place.

Hope this helps.

Gary Krall
Date:      11 Feb 1986 08:09:31 CST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Removal from mailing list

Please remove DDN-REQT@GUNTER-ADAM FROfrom the tcp-ip mailing list.

Link Verstegen

Date:      11 Feb 1986 12:11:39 EST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Tails and Dogs
Feeling that I owe myself one indulgence for not flaming about
the recent rash of unexpanded alien acronyms ("TOP" and [shudder]
"MAP"), I fear I've got to risk taking on Dave Mills (and perhaps
the spirit of Jack Haverty, though I hope and trust not) on what
I take to be a rather pernicious implication:  Loath as I am to
be cruel to fuzzballs--not only on cruelty to animals grounds but
also out of respect for their/their person's ability to bite back--
and with some trepidation that I've misconstrued the relevant
cryptomillsisms, if Dave really thinks there should be limitations
imposed on logical constructs ("connections," whether SMTP or other)
to cater to the shortcomings of physical constructs (gateways,
whether fuzzy or other), then he seems to be to be letting the tail
wag the dog.

In the first place, aren't gateways fundamentally supposed to be
"receive and forward" devices?  If so, what's the fuss about
consuming their buffers?  In the second place, if line speeds
preclude rapid enough forwarding after receipt, isn't this a
"virtual comm subnet" problem of the "congestion control" kind?
If so, why should it be solved by imposing constraints on Hosts
other than through an appropriate, real, called-for for years
congestion control mechanism?  In other words, the Hosts should worry
about how many connections they need/want and how much data they
can accept over them, and "the net" (all flavors of gateway and
all flavors of comm subnet) should worry about getting bits from
Host to Host.  (And if some Hosts "abuse" the net by demanding
character-at-a-time traffic, let 'em--but charge by the kilo-
packet, not the mega-bit.)

In those thrilling days of yesteryear, Multics caused the TIPs to
crash by sending out full-ALL-field's-worths-of-one-bits in NCP's
flow control mechanism (something about they couldn't afford the
table space, assumed nobody would ever send a full allocation,
wound up clobbering the adjacent field...):  I played along then,
in the spirit of "all pioneers together," and made the NCP send
small enough ALLs for them to handle, even though Multics was
perfectly happy to accept however many bits it was--but that was
some 15 years ago!  "Great Wheel of Reincarnation" notwithstanding,
can't we solve the problems where the problems are yet?

     cheers, map

P.S.  In my longhand draft of this, I was going to take issue with
the notion that 2 or 4 K "octet" windows are too large, but it
seems like gilding the ragweed compared to the more abstract issue
of rendering unto the Hosts that which is the Hosts' and unto the
net that which is the net's.  It's not just an issue of whether
SMTP should be barred from using multiple TCP connections, though.
(To the same Host, of course; presumably even the greatest friend
of fuzzies wouldn't argue that we should force mail through "post
office" sorts of things over single connections with small windows
just to ease the strain on the gateways, when many Hosts are involved.)
Windows are and should be, in my humble but dogmatic opinion, Host
artifacts which pertain to Host-Host flow control; employing them
in lieu of a congestion control mechanism at least violates Layering
and at best is a bad hack.

P.P.S.  Apologies for any cryptomapisms  herein, it's just that even
if I were up to a fully-"tutorial" treatment--which I'm not--it
doesn't seem worthwhile to burden everybody with all those bytes,
however many connections they go over and however small the windows
are thought to have to be.
Date:      11 Feb 86 13:36 EST
From:      Rudy.Nedved@A.CS.CMU.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Tails and Dogs
I have yet to hear a solid definition that is not disputed by someone
for the terms "gateway", "router", "repeater" and "bridge". I don't
believe a gateway simply forwards packets nor do I believe the 
software in a gateway can be simply stated in a paragraph or less
of writing. This is based on CMU's and the ARPA Internet's crazy
internet and the myriad of different pieces and functions (everything
from 1200 async lines to x.25 virtual circuit lines to satellite
links to multichannel broadband networks).

Anyhow, the issue is not a congestion one. If you look out your window
during rush hour, can you imagine some kinda of congestion control
mechanism that will gracefully deal with the problem? I can't but
trying to stagger network connections is a big help just like
some companies encourage or command employees to show up at
different times to help rush hour traffic. Of course, to certain
degree rush hour traffic is impossible to solve, just like around
CMU we have rush hour printing and mail time at 430 (everyone is
trying to do last minute work they put off all day) and then people
wonder why their mail has not arrived by 5pm.

The concept that a mail delivery system creates a process and
connection for each recipient or each host at the same time has
got to be a burden on the local system if the mail list is huge.
At some point it has to queue things or disaster will strike.

Of course I agree that the gateways should shutdown a connection
if attempts to limit the load fail since that may be the only
way to encourage software builders and maintainers to not abuse
resources. Anyone who does not practice software engineering or
"using current resources with an eye toward the future" and instead
practices the "infinite resource" design concept is going to make
the users real sorry (of course the guy has left by then and is
doing a research project in another company).

Date:      11 FEB 86 16:18:06
To:        tcp-ip@sri-nic
Subject:   Heterogeneous net
At our location we are planning to (finally) install Ethernet which will 
connect several machines: 2 vintage VAX-750, a MicroVAX-II, a TI-Explorer, 
several SUN systems, as well as a few assorted IBM-PC/XT and ATs. We would like
to be able to access files on other machines, print on the few laser printers 
(on the MicroVAX and one SUN), and support remote log-in as much as possible.

We are currently gathering information from various vendors but would 
appreciate any words of wisdom or benefits of experience from the rest of the 
world.  How can the various joys of NFS, TELNET, DECNET, not to mention naked 
TCP IP be combined?

Any responses by phone will also be appreciated:

   (408) 446-6553    Ron Chestnut

Date:      12 Feb 86 03:21:23 PST (Wed)
From:      gds@sri-spam
To:        tcp-ip@sri-nic.ARPA
Subject:   4.2bsd routing strategy for multihomed host
I had a vax running 4.2bsd BBN TCP/IP on our local ethernet, however
recently it has acquired an ACC and is attached to an IMP also.  Well,
today I was looking at our routing tables and playing around with
opening connections from other hosts on other networks, and was
wondering if my current routing strategy is correct.

Since my vax was only on an ethernet, my /etc/gateways file reflects all
the other networks as being relative to our arpanet-ethernet gateway.  I
took a look on another vax (lll-crg) to see what its routing tables and
/etc/gateways file look like, and they list all the networks and their
associated gateways.  It looked to me as if all the reachable networks
were in their routing tables also.  What I did was to make the arpanet
half of the arpanet-ethernet gateway my default gateway, so that when I
don't know how to get somewhere directly, I get a redirect from the
arpanet-half telling me where to go.  I don't have very many entries in
my routing tables (perhaps that is because a lot of sites don't connect
to us).

At any rate, I was wondering if my strategy is correct.  To me, it seems
that if I can use a smart gateway to tell me where to go, it saves me
the trouble of knowing what all the gateways to the reachable networks
are.  However I am not sure about the side-effects of using a smart
gateway -- I have pinged out my gateway on numerous occasions, plus our
IMP (107) occasionally goes out of service and needs to be reloaded.

For the record, the vax is sri-joyce, usually on, and
temporarily on

Date:      12 Feb 1986 07:28:23 CST
To:        "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Subject:   Re: TCP/IP via X.25 connection to DDN
You'rree NOT wrongf!  However, PSN Release 6.0 will allow X.25 /w/TCP-IP
to talk to 1822 w/TCP-IP.  I don't have a schedule for release of 6.0.
Darrel B.
Date:      12 Feb 86 19:49:34 EST (Wed)
From:      "Thomas Narten" <narten@Purdue.EDU>
Subject:   Re: 4.2bsd routing strategy for multihomed host
We also have one connection to the Internet, but we have several local
nets as well. We have a dedicated gateway (taliesyn) that is connected
to an ARPANET IMP. We run routed on all our machines, our /etc/gateways
are set up so that the ONLY entry in it is for a default route to
taliesyn. We do this only for all machines that are on the SAME LAN as

All other machines have an empty /etc/gateway's file. They pick up a
default route through one of the machines on the same network as

The nice thing about this is that there are no static routes. The
default route (which you might say is static) is only used as a last
resort. If taliesyn is down, the route is bogus, but you are cut off
from the Internet so it doesn't matter. The other routes that get
exchanged are for the local nets of which there aren't that many.

Date:      Thu 13 Feb 86 01:37:30-MST
From:      Jay Lepreau <Lepreau@UTAH-20.ARPA>
To:        mills@DCN6.ARPA
Cc:        hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Conversations with an Ethernet watcher
Re multiple SMTP connections: what do you want, a hung connection to one
host "forever" to prevent any further connections to that host?  Personally,
I don't.

To further abuse the highway analogy-- if I send a car out to deliver
something and it doesn't arrive, it could be caught in rush hour traffic but
it could also have had an accident.
Date:      Thu, 13 Feb 86 3:29:11 EST
From:      Ron Natalie <ron@BRL.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   IPTO-FACTO
Does anyone know why the IPTO gateway on ARPANET is sending ICMP redirects
to my MILNET hosts?

Date:      13 Feb 1986 05:14-EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Tails and Dogs

One of the wonderful things about layered architectures is that they have
a tendency to result in resource allocation problems in each layer.
Generally, the solution to the resource allocation problem at one layer
(congestion control, flow control, Receiver not Ready ....) does nothing
for the resource allocation problem at some other layer.

As a consequence, we seem to relearn now and then that we have to invent
resource allocation strategies for each layer to use to protect its
resources.  The methods may vary from layer to layer, of course, depending
on the functionality of the layer, the freedom it may have to discard
information (or lack of freedom to do so), etc.

The best example I can think of is in a packet net - there may be
end to end flow control above the network layer (e.g TCP) and
flow control on the access link (e.g. HDLC), but the network needs
internal (end/end) flow control to avoid lockups and store/forward
congestion control to deal with trunking/tandem resource limits.

The biggest challenge in communication system design is recognizing
all these various limitations and figuring out a constellation of
resource allocation strategies which are consistent and which can
yield high performance.  Usually, this requires that one look at
the problem at all (or at least, several) layers at once and not
focus solely on one layer and hope that solving its problems will
solve all of them - it will simply move the place where congestion
occurs to someplace else... like a balloon filled with water; you
squeeze here and it pops out there.

Date:      13 Feb 1986 05:25-EST
Subject:   Re: hello

I see you got a fairly positive answer already on your question - nice
having all those hundreds of people to query!

Glad to see you back on the net. How is Kansas?

Sigrid sends her best regards.

Date:      Thu, 13 Feb 86 18:50:54 -0800
From: (Mike Karels)
Subject:   Re: Conversations with an Ethernet watcher
Dave, I was most tempted to flames by your first message in this series,
but restrained myself to see what other reactions would be.  Fortunately,
others have beaten me to the punch.

Concerning the Unix mailer (sendmail), though, I'd like to add an
informational point.  The major reason that multiple connections
are made to a single destination host is that mail is not queued
separately for each host.  I have long wanted it to do so,
and I believe that the program's author now agrees.  My reasons
have more to do with serializing the work when a major mail node
has been down or unreachable than with easing the task of the gateways.
If ucbvax is down for a day, innumerable connections are received
from everywhere as soon as it comes up.  Only by cutting off
new connections when the machine overloads can it avoid disaster.
However, the amount of work required to change sendmail's way
of doing business is nontrivial, and I don't know who will take
on such a problem.

Date:      13 Feb 86 14:48:00 PST
From:      <>
To:        "sutter" <sutter@ohio-state>
Cc:        blumenthal@bbn-unix,tcp-ip@sri-nic
Subject:   HP 3000 support

You need to speak with Steve Blumenthal at BBN.  They have an implementation
for the HP 3000, that handles TCP/IP, user and server Telnet, user FTP,
and unfortunately no SMTP support.  It uses a INP as the interface to the
network which will support either 1822 or HDH.

Hope that helps,

Gary Krall
Date:      13 Feb 1986 17:07:30 PST
To:        mills@DCN6.ARPA, Lepreau@UTAH-20.ARPA, hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Conversations with an Ethernet watcher
In response to the message sent  13-Feb-86 19:38:33-UT from


At ISI we run a TOPS-20 mail receiver that uses separate subprocesses
to receive mail on multiple simultaneous connections.  The number of
subprocesses is limited to 5, and a status program displays the number
of subprocesses active plus the max which were ever needed simultaneously.

Typical behavior is 0-3 subprocesses with open connections at any time,
and it's a rare day which never sees a need for all 5.

Date:      Thu, 13 Feb 86 15:02:18 est
From:      Bob Sutterfield <sutter@ohio-state.ARPA>
To:        net.dcom@ohio-state.ARPA, net.lan@ohio-state.ARPA, net.mail@ohio-state.ARPA, net.wanted@ohio-state.ARPA,
Subject:   TCP/IP for HP-3000
We need to connect a VMS VAX (of which I am the System Manager) with a
Hewlett-Packard 3000 series machine (of which the System Manager has no net
access).  Minimal service level will be dial-up mail, though the rest would
be nice, too.  It seems that our best bet will be to run TCP/IP on both.

I've run QUERY on sri-nic and seen that there are several hosts listed as
being HP-3000s.  However, in "sri-nic:<netinfo>tcp-ip-implementations.txt"
there is no mention of a TCP/IP implementation for the HP-3000.  Where do I
try next?  Any other ideas?  Thanks for your help...
Human: Bob Sutterfield
 Mail: sutter@osu-eddie.UUCP    sutterfield-r%osu-20@osu-eddie.UUCP
   or: sutter@ohio-state.ARPA   sutterfield-r%osu-20@ohio-state.ARPA

Date:      Thu, 13 Feb 86 19:10:11 EST
From:      Mike Muuss <mike@BRL.ARPA>
Cc:        JayLepreau <>,,,
Subject:   Network Mail Observations
BRL machines processes lots of mail, and so does the CSNET-Relay, but
with different patterns of usage.  The busier BRL machines handle
200-1000 messages/day, but with an average of like 200 recipients/message,
some local, many not.  (Statistics here are aproximate, from memory
from the last time I looked, half a year ago).  To handle incoming mail,
we permit two simultaneous SMTP servers;  this seems fine.
To handle outgoing mail, our busier machines run from 3 to 5 deliver
processes.  There are (strict) timeouts on all parts of the SMTP
dialog (different timeouts at different stages), so that none of the
delivery processes "hang up" for very long.  This may have the occasional
side effect of "ganging up" on some recipient host.  If that host is
also implementing a policy of limiting the number of inbound connections,
then this can't ever get too bad.

From hours of watching the SMTP dialogs (in a spare window), it seems
to me that a lot of delivery time is spent engaged in the back-and-forth
validation of the recipient addresses, one at a time.  With the majority
of our messages going to several people at any given site, and the very
long round-trip times through the core during the daytime (RTT from
MILNET in Maryland to ARPANET in California runs 3-12 seconds in the
daytime), this is a non-trivial factor.  For people at the end of
low-bandwidth pipelines, the transmission of the data portion of the
message tends to take most of the time.  (We require a recipient host
to accept data at a minimum rate of about 300 baud plus a constant,
or we timeout the transmission).

Overall, we feel that our mail system is pretty well balanced, and
represents a significant, but reasonable, load on our systems.
(If anybody cares, we run MMDF II and IIb on 4.2 and 4.3beta UNIX systems).

The single biggest improvement for our mail traffic would probably
come from better core gateway performance (jab jab).

The next biggest improvement would come from additional bandwidth
on our IMP (more trunks).  And speaking of which, I heard a rumor that
a recent (last 3-4 months) change to the IMPs changed the behavior of
the IMPs w.r.t. traffic originating at the IMP -vs- through traffic.
(To more strongly favor through traffic).  On the face of it, this
is probably the right thing to do for overall system optimization.
However, we noticed a SERIOUS loss of available bandwidth, a loss
which seems to have only partly been restored.  Am I dreaming?

Date:      13 Feb 86 22:44 PST
From:      Jeff Makey <Makey@LOGICON.ARPA>
Cc:        Makey@LOGICON.ARPA
Subject:   Choosing a gateway
     There are quite a few gateways between the ARPANET and the MILNET.
What is a good strategy for choosing a gateway between two nets when
more than one exists?  It seems to me that some relevant factors are:

     (1) whether a gateway is up at the moment I want to use it;

     (2) how heavily a gateway is loaded; and

     (3) the distance (in terms of IMP hops) from my host to a gateway.

How can my TCP/IP daemon evaluate these factors?  Is there an RFC or
some other available documentation that will answer these questions?

                          :: Jeff Makey

Date:      13-Feb-86 19:38:33-UT
To:        JayLepreau<Lepreau@UTAH-20.ARPA>, mills@DCN6.ARPA, hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Conversations with an Ethernet watcher

I don't want to prolong the agony more than the issue justifies, so subsequent
bickering should probably be restricted between us. However, to your point:
Each of your SMTP connections - one or more - should have a user timeout in
any case, so that your concern more properly is represented by the question
whether more than a single such connection can deliver the throughput required
in the face of occasional (likely) temporary hangups. It's not hard to generate
an engineering answer to this question, given the expected (or measured) incidence
of hangup, timeout interval and so forth. Next, you compute the network bandwidth
necessary to accomplish all the successful and not-so-successful transactions,
then construct a requirements analysis, then procure the necessary bucks. When
the last step fails you go back and try to make what you can afford work the
best way it can, which was the point of my memo.

I would be tickled pink to participate in an exercise designed to explore
the scenario space of our present mail system. Can you (or anyone) at some
"busy" site provide data on the number of SMTP agents active at any time,
retransmission parameters, failure messages and all that stuff? Ed Cain of
the Testing Task Force has been stirring that pot as well. I have rather extensive
logs on our fuzzies, but the volume of mail traffic is underwhelming.

Date:      14 Feb 86 10:32:01 PST (Fri)
From:      Milo S. Medin (NASA ARC Code ED) <medin@orion.ARPA>
Subject:   Re: Killing time

Very interesting Dave.  I've got a few SUN's lying around, feel free to
send the data to me, or point me to it on dcn9 (my account there still works).

Date:      14 Feb 86 10:46:17 PST (Fri)
From:      Milo S. Medin (NASA ARC Code ED) <medin@orion.ARPA>
To:        "Milo S. Medin" (NASA ARC Code ED) <medin@orion.ARPA>
Subject:   Re: Killing time

Sorry folks, hit the wrong type of reply, and it was too late to stop it
when I realized what happened...

Date:      14-Feb-86 04:48:45-UT
Subject:   Re: Confessions of an Ethernet watcher
Mike, Mike and Paul,

I'm finding this exchange highly informative, although it was certainly not my
intent in starting this off to provoke flames or even warm gases. Whether any
of us realized it or not, thorughout the spectrum from the TOPS-20s to the
scruffy fuzzballs, we are building real networks, even if the nodes are mailer
and femailer entities and the links are flaky transport-level connections. You
guys and others here have raised issues of congestion, routing, flow control
and fairness, not to mention multicasting and alternate-route fallback.

This scenario is being studied by the Testing Task Force, chaired by Ed Cain
of DCEC. Ed has been clamoring for hard data, which from your and my watches
is available only by holographing our eyeballs. More reports like yours would
be warmly welcomed. Especially useful are reports on mean aggregate traffic
per day and per busiest hour, as well as typical and maximum simultaneous
transport connections (for mailer and femailer separately). Of particular
interest would be the strategy used in response to errors: requeueing interval
and priority, dependency on type of error and position in the protocols stack.
Hard data on the incidences of such errors, such as might be captured in the
system log file, would be invaluable. It would also be useful to have a sketch
of the queueing discipline, connection-service discipline and fairness
principles, as well as a description of any special mechanisms for congestion
and flow controls.

I'm not sure I want to volunteer to manage the collection and distribution of
such a trove, but I would be glad to tickle the discussion and contribute what
interesting data I can collect. It is my view, as expressed in several fora,
that the effort to collect this kind of information and construct an
appropriate network-mail model is a legitimate research area which should be
funded accordingly.

Date:      Fri, 14 Feb 86 10:27:28 EST
From:      Ron Natalie <ron@BRL.ARPA>
Subject:   Re:  Tails and Dogs

  One of the wonderful things about layered architectures is that they have
  a tendency to result in resource allocation problems in each layer.

Layered Architectures are like Onions.  They're smelly and make you cry
a lot.

Date:      14-Feb-86 07:37:08-UT
Subject:   Killing time

It has been about six months since the series of experiments on Internet clock
synchronization reported in RFC-756 et seq, so I thought you might enjoy a
capsule description of a recent repeat of some of them. Some fascinating (at
least to a slightly fractured bunch of us) phenomena seem to be oozing from
the data which might have to wait detailed archeological excavation; however,
some tidbits sticking from the murk are relishable in this note.

The experiments involved sending datagrams between intrepid fuzzball DCN6 to
each and every one of the 2135 hosts listed in the latest NIC file HOSTS.TXT.
Three protocols were used, one with ICMP Timestamp messages, a second with the
TIME protocol based on UDP and the third with the new NTP protocol, also based
on UDP. Four messages in each of the three protocols were sent to each host
and each reply recorded and processed to produce an offset estimate
representing the difference, in milliseconds, between the clock at the target
machine and the clock at DCN6. The DCN6 clock is synchronized using local-net
protocols to within a few milliseconds of a WWVB radio clock, so for the
purposes here its clock can be considered a reference standard.

Before describinb the results of the experiments themselves, it might be of
interest (says he coyly) to reflect on the health of the Internet innards in
which these datagrams were digested. The following menus summarize the
metabolic products of the three-course meal, which took over 24 hours and
25000 datagrams to swallow. ICMP Timestamp, UDP/NTP and UDP/TIME volleys were
sent to each host one after the other, so that accurate comparisons could be
made between them. If at least one valid reply was received for a protocol,
the volley was recorded as successful; while, if not, the last received error
message (if available) or "no response" was recorded.

2135	ICMP timestamp request sent
722	ICMP timestamp valid reply
72	ICMP invalid timestamp reply (marked unknown or invalid time)
170	ICMP host unreachable
111	ICMP net unreachable
11	ICMP time exceeded (probably a loop)
4	Local host down
1215	No response

2135	UDP/TIME request sent
229	UDP/TIME valid reply
4	UDP invalid packet format (echo host swapped ports)
161	ICMP host unreachable
114	ICMP net unreachable
433	ICMP port unreachable (TIME not implemented)
42	ICMP protocol unreachable (UDP not implemented)
11	ICMP time exceeded (probably a loop)
4	Local host down
1137	No response

2135	UDP/NTP request sent
24	UDP/NTP valid reply
178	ICMP host unreachable
115	ICMP net unreachable
521	ICMP port unreachable (NTP not implemented)
42	ICMP protocol unreachable (UDP not implemented)
10	ICMP time exceeded (probably a loop)
4	Local host down
1241	No response

The most disturbing feature of the above is the astonishing incidence of black
holes (no response). The scarred old warriors among us hate these things
passionately, since they often result in long hours of snoop when something
breaks. A little prying revealed that some number of these were the result of
dropping an otherwise valid reply due to IP or UDP format or checksum problems
at the sender. These provoke more deja vu than surprise, since similar bugs
have been reported and re-reported in famous implementations for years. One
inspired felon even returned all ICMP error messages with a runt ICMP header
too short by four octets. I did manage to explain all the ICMP-time-exceeded
and local-host-down complaints (except one) as originating in our swamp.

Turning now to the valid sample population, it is apparent that the discipline
of the truth-timetellers is somewhat better than last time - only one host was
found nearly exactly one day off (sic) and two were found with blatently
nonsense ICMP times. Taking just the 139 hosts (298 total replies) with
samples from two or more of the three protocols, for example, reveals the
following summary:

Host	      Address		    ICMP	NTP	   UDP	Notes
DCN6.ARPA     []              0        -48        612
DCN-WWVB.ARPA []             1       -466           	WWVB echo
ETAM-ECHO.ARP []              -3        105       -199	IP echo
ISI-ECHO.ARPA []           -6         26        -22	IP echo
DCN5.ARPA     []              7        -20       -168
DCN1.ARPA     []             -8        -35       -162
DCN8.ARPA     []            -21        -29       -514
GW.UMICH.EDU  []             -48         -7       -219
TANUM-ECHO.AR []             -48       3528      -3718	IP echo
WWV.UMICH.EDU []            -58       -627           	WWV echo
FORD1.ARPA    []             62         -6        -16
DCN-WWV.ARPA  []           -75        -11           	WWV echo
UMD1.UMD.EDU  []            100         55        360
SATNET-ECHO.A []             277        180        703	IP echo
GOONHILLY-ECH []             294        141      -3021	IP echo
XYZZY.UMICH.E []            -321       -315       -578
RAISTING-ECHO []             479        -12      -4821	IP echo
ORNL-MSR.ARPA []            497                  -915
STC.ARPA      []          -665          3      -2858	IP echo
SALLY.UTEXAS. []          -1478                 -2542
AMES.ARPA     []          -1490      -1294      -1408
IPTO-FAX.ARPA []        -1975      -2119      -1882
IPTO-ECHO.ARP []        -2000       -627           	UDP echo
ORION.ARPA    []         2074        914       1314
USC-OBERON.AR []          2484                   932
ROCHESTER.ARP []           3633                  2500
SCORPIO.THINK []       5196                  4395
C.CS.UIUC.EDU []          5242                  4568
MIT-MULTICS.A []           -6606                 -7651
BRAND.USC.EDU []         7887                  6792
DWORKIN.USC.E []         8516                  7306
GRANITE.ARPA  []      -10023                -10790
A.CS.UIUC.EDU []         -10373                -10988
ICSC.UCI.EDU  []         10414                  9654
ICSD.UCI.EDU  []         11184                 12025
NETWOLF.UMD.E []        -11498                -12204
COLUMBIA.EDU  []         -11868                -14486
NYU-CSD2.ARPA []      -14138                -14036
DOCKMASTER.AR []         -15842                -17585
DCN9.ARPA     []         -16860     -16866     -17677
NOSC-GUPPY.AR []        -17211                -17908
TRANTOR.UMD.E []         17922      17938      16846
HI-MULTICS.AR []          21274                 20242
TB.CC.CMU.EDU []       22848                 24304
SU-SAFE.ARPA  []        25114                 25908
PATCH.ARPA    []          -26211                -27396
BBNCC5.ARPA   []       -27836                -32280
ATRP.MIT.EDU  []          30453                 29554
NPRDC-PACIFIC []        -31432                -32233
TF.CC.CMU.EDU []       33023                 34611
GARFIELD.COLU []       -36358                -35630
TC.CC.CMU.EDU []       39542                 40695
USGS2-MULTICS []         -45500                -46397
B.CS.UIUC.EDU []        -51185                -52065
CU-ARPA.CS.CO []         -54810                -55610
ICSE.UCI.EDU  []        -58193                -59623
USC-ISIC.ARPA []         -59430                -59212
TD.CC.CMU.EDU []       59699                 60560
NPRDC.ARPA    []           67029                 64915
UCI.EDU       []        -70709                -71224
CIP3.UCI.EDU  []        -74679                -76161
SU-AIMVAX.ARP []        84666                 83903
NYU-ACF5.ARPA []       -88445                -91559
MERLIN.PURDUE []         88691                 87860
MITRE-BEDFORD []          90742                 90366
NS2.CS.UCL.AC []         97395                 96411
MEDIA-LAB.ARP []         100189                 99256
TE.CC.CMU.EDU []      107915                108221
CIP4.UCI.EDU  []      -109144               -109610
BLAYS.PURDUE. []        123395                119781
FAS.RI.CMU.ED []    -129306               -130533
CAD.CS.CMU.ED []    -134145               -135394
THEORY.CS.CMU []    -137348               -138211
GANDALF.CS.CM []    -139830               -140677
CIVE.RI.CMU.E []    -139857               -140732
H.CS.CMU.EDU  []    -140138               -141135
SAM.CS.CMU.ED []    -140886               -141504
K.CS.CMU.EDU  []    -143272               -144436
SENSOR.RI.CMU []    -144797               -145883
SPEECH1.CS.CM []    -145322               -146576
ME.RI.CMU.EDU []    -145774               -146565
CIP.UCI.EDU   []       -146244               -146019
NYU-ACF2.ARPA []        146843                145399
C.CS.CMU.EDU  []         149915                150837
IUS1.CS.CMU.E []    -150642               -151298
VI.RI.CMU.EDU []    -150781               -151567
SPICE.CS.CMU. []    -151411               -152188
ARM.RI.CMU.ED []    -152310               -153136
MAPS.CS.CMU.E []    -152825               -153692
ISL1.RI.CMU.E []    -154190               -155976
ML.RI.CMU.EDU []    -155618               -156754
IUS2.CS.CMU.E []    -157583               -158408
A.SEI.CMU.EDU []    -158382               -159449
SU-MOJAVE.ARP []       -162822               -163537
SPEECH2.CS.CM []    -165127               -166118
SU-SONOMA.ARP []       -167543               -167882
PT.CS.CMU.EDU []    -198025               -198966
MITRE.ARPA    []         201594                200484
NYU.ARPA      []         207805                207160
SU-ARGUS.ARPA []        -216438               -216367
ROVER.RI.CMU. []    -218641               -219583
MIT-HERA.ARPA []        -226707               -227641
MIT-APOLLO.AR []       -233509               -234152
SU-HELENS.ARP []          241465                240527
MIT-DEMETER.A []        -265113               -266357
MIT-APHRODITE []       -265862               -266957
MIT-CASTOR.AR []        -267411               -268406
MIT-ATLAS.ARP []       -268763               -269762
MIT-HELEN.ARP []       -269498               -270900
MIT-HECTOR.AR []       -275008               -275890
MIT-THESEUS.A []        -280386               -281468
MIT-ARTEMIS.A []       -282770               -283816
MIT-ORPHEUS.A []        -286828               -287853
MIT-MENELAUS. []       -294194               -294229
SU-FUJI.ARPA  []          295277                294896
MIT-JASON.ARP []        -296300               -297382
MICRO.UDEL.ED []        297334                296792
MIT-PRIAM.ARP []       -300702               -301975
MIT-PARIS.ARP []       -301652               -302932
ATHENA.MIT.ED []        -301792               -303244
MIT-ODYSSEUS. []       -303007               -304354
MIT-ZEUS.ARPA []        -305836               -307120
MIT-HERACLES. []        -309782               -310816
RADC-MULTICS. []        -313852               -314576
MIT-POSEIDON. []        -321949               -322546
DEWEY.UDEL.ED []        322621                322913
SU-COYOTE.ARP []      -322956               -323303
BBNG.ARPA     []       -331109               -331111
UW-KRAKATOA.A []       -333876               -334815
MIT-AGAMEMNON []       -341461               -342518
NYU-ACF4.ARPA []     -419460               -420123
CIP2.UCI.EDU  []       -435654               -435619
SU-LINDY.ARPA []        -449513               -448490
VLSI.CS.CMU.E []    -480627               -481678
NYU-CSD1.ARPA []     -715648               -717005
SU-PESCADERO. []         -751799               -751814
AMES-ATLAS.AR []     -792499               -793442
S1-A.ARPA     []      114428000               -773226
SU-AI.ARPA    []      115126000                -76368

WWVB echo	Synchronized to WWVB radio; swaps addresses and ports
WWV echo	Synchronized to WWV radio; swaps addresses and ports
GOES echo	Synchronized to GOES satellite; swaps addresses and ports
UDP echo	Swaps addresses and ports
IP echo		Swaps addresses

If anybody is interested in further details, raw data or pretty pics to light
up your Sun, please tinkle me directly.

Date:      14 Feb 1986 12:41:47 EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Tails and Dogs
In response to your message sent  13 Feb 1986 05:14-EST

   Always good to hear from you, especially on the present topic,
and even more especially since it lets me avoid being churlish
(which would have been the case had I had to answer the other
response independently; now I can merely observe that I'm sure
you agree that in the context of the TCP-IP "bulletin board"
Gateways must be IP Gateways unless otherwise specified and
connections must be TCP connections U.O.S. and hence Gateways
can't drop connections, without being explicitly rude to "Rudy.Nedved"
[if I remember aright], and I might even go so far as to imagine
you'd agree that it's at best peculiar to enter a discussion
with a declaration that you don't believe the terms being
discussed can be defined).  [Well, I never said it would let me
avoid being a little snide, but good grief, this isn't SF-Lovers!
I mean, I'll apologize if he was being facetious about undefinability
--though the business about Gateways dropping connections
certainly suggests that he's not using our definitions--but it
really is annoying, and rather insulting, to get a message that
in essence says Since I don't know what you're talking about,
you can't know what you're talking about.  (That's probably more
than the incident's worth--but you should have seen my longhand
draft of a day or two ago.)]
   At any rate, subject to a little interpretation of the last
paragraph I find myself in complete agreement with your comments--
particularly the second paragraph, which I take to be an elegant
statement of what I was trying to say in the first place.
The real question, in my mind, anyway, is what's meant by "looking
at" the layers severally.  Consider the (I think treacherous) analogy
to staggered work hours and traffic congestion: what if somebody said
Gee, that works so well that not only will we make it mandatory, we'll
also send traffic cops into the buildings and have them turn off
the elevators and lock the stairwells so those damn commuters can't
flood our scarce street resources?  Not only bad safety engineering
practice, but really dubious on Constitutional grounds, yes?  Well,
isn't it even more dubious on Layering grounds to HAVE TO use fewer
TCP connections or HAVE TO send out fewer datagrams (in the full 
awareness some will have to be retransmitted)?  That is, it's
perfectly licit to expect the Hosts to use the net intelligently,
but when push comes to shove the net's there for the Hosts' benefit,
not conversely, so the net has no business "demanding" the Hosts'
lay off--except, of course, by giving the Gateways-part-of-the-net
an analogue to the IMPs' ability to keep the ready line down (or
whatever the equivalent is in HDLC/LAP B/whatever).  And strong
though my feelings are against arguing with the inventors of things
about what the things are for, if you of all people support the
use of TCP windows for something other than Host-Host flow control,
well, let's step into the nearest time machine and go back around
a dozen years and talk about what's wrong will NCP ALL again.
   Another way of attempting to express my concern is that while
I have considerable sympathy (and even empathy) for people who are
trying to split logs with toy hatchets because nobody will give them
real ones, and will even buy whatever wood they can generate for me,
I don't think they've got any business telling me I shouldn't look
for somebody with a chain saw if I need more wood to keep the house
warm enough to live in.  I'm not asking for "infinite resources,"
just appropriate technology.
   But that's probably what your last paragraph meant anyway...
and I daresay Dave wouldn't really let the cops lock the stairwells,
even if I'm not so sure what he'd do with the elevators....
   cheers, map
Date:      14 Feb 1986 14:11:39 EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Tails and Dogs
In response to your message sent  13 Feb 1986 05:14-EST

Ooops.  Realized while suffering through lunch (dental anguish, not
worse than usual provender) that I should have said give the
Gateways an APPROPRIATE analogue to the ready line, since if Source
Quenches and (or?) Redirects worked I'm confident Dave wouldn't
have (inadvertantly?) gotten me started on this tack.

And, since a new msg came in just now: I'll defer to your rejoinder
in re Onions...unless you can't come up with anything better than
IF you know how to deal with them, onions CAN be a tearless way of
adding indispensible flavor to certain recipes.

re-cheers, map
Date:      14 Feb 86 18:03:52 GMT
From:      Brian Goodmon <goodmon%encore.uucp@BRL.ARPA>
Subject:   The LAN's Prayer
Rwhod who art in /etc, well-known be thy port; thy packets come,
thy protocol be done, in user space as it is in kernel.  Give us
this day our daily dump, and forgive us our bugs as we forgive
those who submit SPR's against them.  Lead us not into address
resolution, and deliver us from ISO.  For thine is the transport
and the session and the physical forever, EOF.
Date:      14 Feb 1986 23:30-EST
To:        sutter@OHIO-STATE.ARPA
Cc:        net.dcom@OHIO-STATE.ARPA, net.lan@OHIO-STATE.ARPA net.mail@OHIO-STATE.ARPA, net.wanted@OHIO-STATE.ARPA tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP/IP for HP-3000
BBN did a TCP/IP for HP3000. Also, I believe HP is doing one as well,
although I don't think it is in product form as yet.

Vint Cerf
Date:      14-Feb-86 21:48:34-UT
To:        MiloS.Medin(NASAARCCodeED)<medin@orion.ARPA>,,, Re:Killingtime@DCN6.ARPA
Subject:   Re: Killing time

Snarf *.BIT on DCN1, ANONYMOUS, GUEST, then light up your Sun with

Date:      Sat, 15 Feb 86 09:08:53 EST
From:      "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   comments about Bridge Communication's IP bridge.
I have two ethernets *almost* connected by a 56KB line.
Almost because I have the V.35 connectors staring into space
waiting for me to decide what bridge/gateway to buy. The Bridge Inc
box is an attractive off-the-shelf hardware combination of

What experiences have people had (if any) with their IP bridging
software. Does anyone have their own software for the box?


Date:      15 Feb 1986 09:58-EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Tails and Dogs

There was an old joke once about crossing an onion with a donkey and getting
a piece of ass that brought tears to your eyes.  I suppose one might say the
same thing about crossing architectures with onions, although I am not sure
what the connotations are.

I was not advocating that the TCP level of flow control be used, somehow,
to protect the network - just the opposite. The point is that the network
(lower) layer must have mechanisms to protect its resources DESPITE the
presence of the higher level end/end flow control.

This does NOT, however, mean that one should design systems by deliberately
being blind to how things work.  John Nagle's recent RFC's and Dave Mills'
work on tiny pipes/flow control algorithms are manifestations of the Jack
Haverty school of engineering: "the smarter you are about the environment,
the better you can tune the system to give optimum performance."

The hard line to draw or engineering judgement to make is when to 
deliberately ignore specific information or not rely on it to achieve
greater generality, but probably at the cost of poorer performance.
Much of the initial INTERNET design deliberately took the latter approach
in the interest of bringing an experimental facility into being from
which we could learn in what ways it made sense to be "smart."

Hope this makes my point a bit more clearly.

Date:      16-Feb-86 22:10:23-UT
Subject:   Incestuous clockwatching

I have had several messages of the general form "Why didn't my host show up in
your list of clock respondents?" If said host did not respond to at least two
of the three protocols: ICMP Timestamp, UDP/NTP or UDP/TIME, it was
intentionally not included. In almost all cases those hosts that responded
with UDP/NTP or UDP/TIME responded also to ICMP Timestamp. Accordingly, for
those of you who are interested, I have put up the file TIME.TXT on DCN1
(ANONYMOUS/GUEST) containing all the IMCP Timestamp responses ordered by
(apparent) subnet.

Examination of the data in that file, by the way, suggests some revealing
insights. The intent of the experiment that produced the file was to
determine to what extent local nets tend to cluster closely around the "wrong"
time, presumably due to incestuous clockwatching. In some local nets this
tendency is readily apparent, with almost all hosts eagerly tracking some tens
of seconds or minutes off with maybe a few broken or defiant exceptions. This
has interesting implications for the design of synchronization algorithms such
as suggested in RFC-956, since a large local net could in principle "take
over" the world of clocks with the wrong time. Interestingly enough, however,
the clustering algorithm of RFC-956 was fed the entire data base collected in
last wwek's experiment, but it still came up with the "real" time to within a
few millisceonds.

For the crew working on NTP implementations, the following list of known
reference hosts and clocks is as follows, along with the unsmoothed offset
(milliseconds) measured with respect to DCN6 just to give you some idea of the
accuracies that can be expected. The best accuracies are normally obtained
with ICMP Timestamp (I), with UDP/NTP (N) next and UDP/TIME (U) last. The
hosts marked * are corrected to agree to zero offset relative to radio time,
but only with ICMP Timestamp. The offsets shown are almost completely
dominated by network-delay dispersion, except for UDP/TIME, which has an
inherent precision of one second.

P Host Name	Address		Offset
I GW.UMICH.EDU  []	-30
N GW.UMICH.EDU  []	-152
U GW.UMICH.EDU  []	-118
I DCN1.ARPA     []	-9
N DCN1.ARPA     []	8
U DCN1.ARPA     []	-73
I DCN-WWV.ARPA  []	-14	*
I DCN-WWVB.ARPA []	-60	*
I FORD1.ARPA    []	49
N FORD1.ARPA    []	40
U FORD1.ARPA    []	-167
I UMD1.UMD.EDU  []	-183
N UMD1.UMD.EDU  []	-81
U UMD1.UMD.EDU  []	656
I UMD-WWVB.UMD. []	174	*

Date:      17 Feb 86 10:51:21 EST (Mon)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        Ron Natalie <ron@brl.ARPA>
Cc:        tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA
Subject:   Re: IPTO-FACTO

     Does anyone know why the IPTO gateway on ARPANET is sending ICMP redirects
     to my MILNET hosts?


There were three separate factors which conspired together (&&) to cause the
newly installed IPTO butterfly gateway to send you (and others) redirects.

1. the redirect code did not include the test that the IP source of the packet
   must be on the same net as the gateway's input interface to permit a
   redirect to be sent.

2. the butterfly gateway includes minimal GGP code to advertize its own
   connected net (ARPA-LAN, 192.5.18, in this case) to those 'core' gateways
   which ask.

3. the butterfly gateway was plugged in to replace an lsi-11 'core' gateway,
   but the plug transfer was done too fast (5 seconds rather than 5 minutes)
   for the other core gateways to notice the fact that a core gateway had gone

Because of (3), the core gateways did not get any new information from
IPTO which would have only listed the ARPA-LAN net.  This meant that when some
nets went down, a route was mistakenly thought to exist through IPTO.

Because of (1), IPTO was sending redirects for these packets not only to
arpanet hosts, but also to hosts on milnet and other nets farther out.

On Thursday morning, about 1100 EST, the IPTO gateway was brought up after
being down for at least 10 minutes, forcing the core gateways to clear out the
extraneous information.  Friday, the gateway was reloaded with the redirect
bug fixed.

Mike Brescia
Date:      Tue 18 Feb 86 03:40:13-EST
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        tcp-ip@SRI-NIC.ARPA, egp-people@BBN-UNIX.ARPA
Cc:        mit-ip-people@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU
Subject:   More EGP musical tables
	OK, we have run out of a different kind of table resource in the
EGP core gateways. (Yow, am I having *fun* yet?) This time, you don't even
get to be a neighbour; there is no table space for new EGP neighbours.
	This happened to the MIT-AI-GW. It couldn't connect up to the two
core EGP gateways it has been using for months. Since my EGP was refused by
both of the core neighbours in its static 'toehold' table, it was
completely out in the cold; it couldn't even try to shift to an alternate.
(My EGP has all these heurisitics where you can set a 'minimum neighbour
count' and it trys to keep that many neighbours around all the time by
trying to peer with new neighbours its initial neighbours tell it about.)
	I called up the NOC, and they couldn't help, but I did get the info
on which core gateways were running EGP; I tried them all, and after
several failures found that the *last one* had room.

	Does anyone from BBN know why this suddenly happened? Are there
just more EGP gateways out there, using up the table space? Was there an
adverse effect from the release of the memory mapping software? If the
table size cannot be increased, can EGP be put in more core gateways
to spread the load?
	Whatever the reason, this is very disturbing, since hardwired
'bootstrap' information that has been good for months has effectively gone
bad. Bad marks on the 'realiable service' front.

Date:      Tue 18 Feb 86 12:39:51-PST
From:      "ARAM BOORNAZIAN" <aboornazian@bbnv1.ARPA>
To:        "tcp-ip" <tcp-ip@sri-nic.ARPA>
Subject:   Cerf and Natalie continued
There is a class of tools that make a job possible.  The Layered Architecture
is in that class.

Date:      18 Feb 1986 10:45:24 EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Tails and Dogs
In response to your message sent  15 Feb 1986 09:58-EST


Mulishly ignoring the opening presented by your first paragraph,
I'll merely observe that it's getting uncanny how your second
paragraphs make just the points I want to.

In the interests of getting on, I choose to infer from your
third paragraph that I must have been wrong in thinking Dave
WAS implicitly advocating Bad Things in the msg that started
me off, and hence will couch  my lance until somebody shoves
another windmill into my path.  (Rosinante and I are both getting
on enough that it no longer seems worthwhile to cross roads for
windmills, however attractive, but it's certainly beyond our
scope to go around 'em if they're right there--to end with just a 
bit of horsing around, as it were.)

cheers, map

P.S. It might be a purist's point, but I do hope everybody
remembers that
Date:      18 Feb 86 14:10:00 PST
From:      <>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   Logical addressing
Does anyone know if the IMPs on the network currently support
logical addressing for X.25 options?  In the DDN X.25 Interface
Specification a reference is made to the "Logical Addressing Facility",
and that implementation of DDN logical addressing by a host is
optional.  If a host elected to implement this option would the
IMP software support this, and does PSN 6.0 already have this implemented?

Gary Krall

Date:      18 Feb 1986 13:10:25 EST
Subject:   Re: Tails and Dogs
In response to the message sent  18 Feb 1986 10:45:24 EST from PADLIPSKY@USC-ISI.ARPA

Good Lord, what have I done? It started with a few wayward packets and now
we have windmills, horses, bad puns and Bad Things. May the Bird of
Paradise redundancy all over your floor. Having had the first word, can
I have the last and can this be it?
Date:      18 Feb 86 18:00:40 EST (Tue)
From:      Stan Ames <sra@mitre-bedford.ARPA>
To:        tcp-ip@sri-nic.ARPA, sra@mitre-bedford.ARPA
Subject:   rlogin support for non unix hosts
We are currently performing an independant assessment of the WIS program.  One
of the issues raised is whether commercial equipment could be used to solve
the WIS requirements.

One of the requirements of WIS is a single login.  A potential solution is to
use the rlogin capability found on most Unix hosts.  Does anyone know whether
this command is to be found in network implementations for machines other than
Unix.  Specifically does rlogin exist for IBM mainframes or VAXs running VMS.


Stan Ames

sra at mitre-bedford
Date:      Wed, 19 Feb 86 10:56:36 EST
From:      Joel B Levin <levin@bbncc2.ARPA>
Subject:   Logical Addressing

In answer to Gary Krall's query of 18 February:

PSN 5.0 and PSN 6.0 fully support logical addressing as described in BBN
report 5476, the DDN X.25 Interface Specification.  Use of this facility
is by arrangement with the administrators of the network.

	Joel B. Levin

Date:      Wed, 19 Feb 86 10:12:09 GMT
From:      Jon Crowcroft <>
Subject:   Re:  [George J. Carre: comments about Bridge Communication's IP bridge.]

As part of an Alvey project, University College London
have been using Bridge Incs Gs/3 boxes to bridge 5
sites with local ethernets together,
over 64 kbps serial lines.

Each site has 2 bridge boxes, each box with 2 serial line
boards capable of around 200 pkts/sec thruput.

We use our own IP software, rather than bridges since it was'nt
available when we installed the network.

Re their software.

1. The Bridge Inc developement system and kernel is neat for
building network software

2. The serial line driver software is a bit
tacky, but can be made to do what you want. We have to fragment
IP over the serial line down to 576 bytes to get good
performance, but thats standard anyway.

3. Bridge don't do dynamic routing, we do (an IGP + EGP setup)

4. We support most of ICMP, but not all IP options (eg
Redirects, Quenches. Not Source-Route or Route-Record)

Date:      20 February 1986 0729-PST (Thursday)
From: (Ron Stanonik)
Subject:   4.3bsd subnetting
Berkeley 4.3bsd (beta) contains subnetting, but no support
for non-subnetted hosts (suns) on the subnet.  Rumor has it
that 4.3bsd (distributed) also lacks support for non-subnetted
hosts on the subnet.  The subnetting rfc's suggest some solutions
based on arp changes.  Has anyone implemented these, or any
other solutions?


Ron Stanonik
Date:      20-Feb-86 01:17:59-UT
Cc:        hwb@GW.UMICH.EDU
Subject:   Swapped IP address bytes.
What's going on here? First Cornell started to send lots of requests
while having the destination IP address obviously swapped, and now
BBN starts to be doing the same. Is this one of the jokes BBN had
half a year or so ago with BBN-META or what's up? The following is
going on for more than 90 minutes now, and I don't consider it to
be very funny (even though I was fairly amused when I saw it 
in the first place). More seriously, since BBN is now the second place
which is doing this, I wonder whether some "new" problem is showing up.

	-- Hans-Werner Braun
PS: ICMP 003 000 is a (sub)net unreachable response


23:45:24 010 ?TRAP-I-ICMP 003 000 [] -> []
23:45:33 010 ?TRAP-I-ICMP 003 000 [] -> []
23:45:48 010 ?TRAP-I-ICMP 003 000 [] -> []
23:46:03 010 ?TRAP-I-ICMP 003 000 [] -> []
23:46:19 010 ?TRAP-I-ICMP 003 000 [] -> []
23:46:34 010 ?TRAP-I-ICMP 003 000 [] -> []
23:46:49 010 ?TRAP-I-ICMP 003 000 [] -> []
23:47:04 010 ?TRAP-I-ICMP 003 000 [] -> []
23:47:19 010 ?TRAP-I-ICMP 003 000 [] -> []
23:47:35 010 ?TRAP-I-ICMP 003 000 [] -> []
23:47:49 010 ?TRAP-I-ICMP 003 000 [] -> []
23:48:19 010 ?TRAP-I-ICMP 003 000 [] -> []
23:49:05 010 ?TRAP-I-ICMP 003 000 [] -> []
23:49:18 010 ?TRAP-I-ICMP 003 000 [] -> []
23:49:33 010 ?TRAP-I-ICMP 003 000 [] -> []
23:49:48 010 ?TRAP-I-ICMP 003 000 [] -> []
Date:      20 Feb 86 07:55:16 EST (Thu)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        hwb@gw.umich.EDU
Cc:        tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA
Subject:   Re: Swapped IP address bytes.

     PS: ICMP 003 000 is a (sub)net unreachable response

     23:45:24 010 ?TRAP-I-ICMP 003 000 [] -> []

It would be informative if you would mention what the 010 means, and whether
we can deduce the protocol involved.  It would also be informative if you
would examine the NIC tables for info about what the address numbers map into.

Note that is 'suran-vax' at BBN, and net 128.23 is the BBN packet
radio (suran) net.  I surmise that some debugging of a new monitoring program
is going on.  Be glad that it is happening around midnight rather than around

Date:      Thu 20 Feb 86 09:28:17-EST
From:      Dan Tappan <Tappan@G.BBN.COM>
To:        hwb@GW.UMICH.EDU
Cc:        brescia@CCV.BBN.COM, tcp-ip@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, Tappan@G.BBN.COM
Subject:   Re: Swapped IP address bytes.
The problem turns out to have been a program being ported from a SUN
to the VAX - and not properly handling the byte swapping. Not a problem
with 4.2. I wouldn't be suprised is cornell's problem was similar.

Date:      Thu, 20 Feb 86 16:46:25 PST
From:      wayne@wilbur.ARPA (Wayne Hathaway)
To:        iso@acc-sb-unix.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Papers for classroom use?
[Apologies for sending this to two lists.  I'll keep it short.  Chomp.]

I teach a computer networks class at the University of Santa Clara, using
Tanenbaum.  The book is quite good for the lower OSI layers, but is very
weak at ISO IP and above.  Does anybody know of any articles, papers etc.
that would serve as good handouts for things like ISO IP, TP4, Session
protocols, and so forth?  Looking for 10-15 pages max, "survey" type
stuff, suitable for handouts to be fleshed out with class discussion.

Adthanksvance for any pointers.

Wayne Hathaway
Date:      Thu, 20 Feb 86 18:39:32 cst
From:      jsq@zotz.UTEXAS.EDU (John Quarterman)
To:        stanonik@NPRDC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL-TGR.ARPA, wallen@NPRDC.ARPA
Subject:   Re:  4.3bsd subnetting
I'm working on fitting Smoot Carl-Mitchell's 4.2BSD ARP hack into 4.3BSD.
Should be ready in about a week.  Somebody else may have already done it,
or something like it.
Date:      20-Feb-86 13:16:42-UT
To:        MikeBrescia<brescia@BBNCCV.ARPA>, hwb@gw.umich.EDU, tcp-ip@sri-nic.ARPA, tcp-ip@sri-nic.ARPA
Cc:        hwb@GW.UMICH.EDU
Subject:   Re: Swapped IP address bytes.

Sorry about the lack of information and probably sad wording in my message.
The 10 is only of local significance and the time was in UT and therefore
off by five hours compared to EST. I had a hard time to type because I got
these messages every 15 seconds, which is not a good excuse but at least some
reason for strangeities in my messages. The reason I was sending it so
broadly was because I noticed before that a few hosts at Cornell started to
do the same about two weeks or so ago. Now that even a host at BBN starts
doing it I wonder whether there is a more general problem (may be with 4.3?).
The mentioned connection requests arrived on a Fuzzball which allowed me to
remap the destination host to UMICH1.ARPA. Then I saw that it was actually
a Telnet request. By the way, I figured that out after I sent the message;
my major reason were the swapped IP bytes and nothing else. Anyway, this
showed me that SRN-VAX.ARPA attempted a telnet (Port #23) request. This means
that there might be another problem, too, since SRN-VAX tried to get a Telnet
connection for over 90 minutes while retrying about every 15 seconds and
always getting net unreachables.
I hope this helps more than my original message. Thank's for checking into
this so far. Please let me know if I can be of more help to figure out what
the problem is.
	-- Hans-Werner
Date:      Thu, 20 Feb 86 23:35:17 EST
From:      jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
Subject:   Interesting Ethernet/UNIX 4.2 observation.
I thought I would share this one with everybody:

	We have just finished installing an Ethernet with ~40 single
user Vaxstation II's running UNIX 4.2 on it. We also have a few IBM RT
PC's as well. The Vaxstations use the MIT Developed RVD protocol to
access the files in "/usr" which are in fact located on a VAX 11/750.
I mention RVD not because it is related to the problem described, but
because it means that these workstations make quite regular use of the
network even when involved in otherwise non-network activity. And
obviously they also depend strongly on the network in order to
function properly at all.

	Therefore it was a major problem when people began complaining
to me about the network dying for 20 second intervals about once a
minute.  The network would come back to life with the Vaxstations
spiting out an error about their Ethernet board being wedged and
having to be restarted.

	One might normally expect there to be some hardware problem
behind all this. This turned out to only partially be the case, which
is to say the hardware problem found was of a design nature, not just
one broken board... read on.

	A running examination of network hardware statistics showed
that we were getting a large number of collisions about once a minute,
exactly.  At this point we turned on "Netwatch." For those who don't
know what it is: Netwatch is a program which is part of the MIT PC/IP
package for the IBM PC (PC/XT/AT and compatibles). It allows one to
examine packet traffic on the Ethernet and also does some automatic
packet analysis (ie. Type of packet, Protocol, Source and
Destination etc).

	The problem turned out to be that one workstation was
misconfigured so that it thought it was on network 46 (whereas the
real network is 18.72, we use a subnetting scheme). Most UNIX 4.2
systems have a cute little daemon named "rwhod" that broadcasts
information to all other stations once per minute. In the case of our
misconfigured workstation this packet was sent to the Ethernet
broadcast address and to IP address Now this resulted in all
other workstations on the network receiving this packet and deciding
that they would be good citizens and forward it on to our gateway.
Because this level of processing occurs at interrupt level, and most
of our stations are not loaded to the point that significant interrupt
latency occurs, all ~40 workstations would simultaneously attempt to
forward this packet to our gateway. This resulted in a monster
collision on the Ethernet. Now combine this with a hardware design
problem in the Ethernet controller that results in the Ethernet
hardware having a good probability for wedging up in the (otherwise
rare) case of monster collision, and add a 20 second timeout in the
device driver software and you have a neat problem on your hands.

	Obviously we fixed the misconfigured machine, however this
problem has occurred several times since (we are still installing

	Btw. tracing down the location of the offending machine is
also a bit of a bear. The network is in an office area. Each office
has two Ethernet drops, each coming from a dedicated transceiver above
the (icky dirty) ceiling. The offices are generally locked. People
leave their workstations on, up and in operation. Admittedly this
Ethernet topology is just asking for this kind of problem (ie. what do
you do when an interface starts jabbering).

	To help track this kind of problem down I have established a
database of IP address => Ethernet Address => Physical Location.
Luckily the software tools our workstations have do not allow a user
to easily change his Ethernet address, so that can be relied on to
determine the location of the offending machine.

Moral of the story:

1) The Ethernet topology described above may not be the best possible
   for an office area (but we all probably know that anyway).

2) A Network Spy program like netwatch is an invaluable tool.

   idea. In fact it is probably best that when a workstation receives
   a packet incorrectly sent to it, the packet be DISCARDed and
   perhaps logged for debugging purposes.
   Note that if a workstation sends an ICMP destination
   unreachable message back to the source, the monster
   collision would still occur as ALL workstations would try
   to send the ICMP message.

4) Ethernet controllers that work "most" of the time may not be
   good enough.


P.S. Sorry this message was so long.
Date:      Fri 21 Feb 86 04:22:24-PST
From:      William "Chops" Westfield <BILLW@SU-SCORE.ARPA>
To:        tops-20@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Tops20 TVT performance improvments
BUG:	Under certain situations, throughput on TOPS20 TVTs drops to
	approximately 0 for long periods of time.  I believe that
	the problem got worse with v6.1, and may be the reason
	that the TVT SMTP server doesn't work well under 6.1.

Reproduce by:
	I think this shows up best when trying to run a dialout
	type program while logged in on a TVT.  However, the
	following program will exhibit the problem too:

	start:	movei 6,^d32
	loop:	movei 1,"%"
		movei 1,^d30
		sojg 6,loop

	The tops20 TVT scanner attempts to send characters that are
	part of "echoing" immediately.  It's criteria for recognizing
	"echoes" is that there be fewer than 8 characters in the
	terminal output buffer.  Since the TCP process runs at a very
	high priority, it will probably get to look at the TTY output
	buffers if the user process blocks for any reason.  In the
	case above, therefore, there is a good chance that 32
	separate 1 byte packets are queued.  And there are certainly
	lots of machines that don't like to receive 32 almost
	back-to-back short packets.  This leads to many retransmissions
	and excessive use of CPU time on both systems, not to mention
	any gateways that might be in between them.

Fix:	Make TOPS20 TCP pickier about what it considers echoing.
	In addition to there being only a few characters in the
	buffer, have it insist that the retransmission queue for
	that connection be empty.  (If a person types faster than
	the Round trip times, it won't hurt to have his echoing
	clumped together a little anyway.)  This is much simpler
	than having the TCP repacketize retransmissions.

	By the way, it turns out that this is "reinventing the
	wheel", as almost identical suggestions were made by
	John Nagle in RFC896.  It is surprising, however, that
	this makes such a difference even on local ethernets
	with no gateways involved.  Admittedly, tops20's
	scheduling of TCP provides a pathological case!

	The relevant code is in TVTSRV, just before OPSCA7:
	[This is from 6.1 sources.  There should be an easy
	 equivalent for 5.x. From SCORE:: <6-1-monitor>TVTSRV.MAC ]

	 SKIPA T4,T1		; Yes.  Get PZ to call SNDTVT
	  JRST OPSCA7		; No.
	MOVX T1,^D200		; The function to queue for PZ if a lot
	MOVX T2,<XCDSEC,,ENCPKT> ; to send - wait a bit, maybe more
	CAIGE T4,^D8		; Less that 8 is echoing so
	 MOVX T2,<XCDSEC,,FRCPKT> ; Force it now
	CALL (T2)		; See Note above
IFN STANSW,<	;;; there is not going to be any more output if all of the
		;;; output buffers are full, so send packets immediately.
	CALL TTSOBF		;output buffer full?
	CAIGE T4,^D8		; or looks like echoing.
	 SKIPA T2,[XCDSEC,,FRCPKT] ; Force it now
	  MOVX T2,<XCDSEC,,ENCPKT> ;  otherwise wait for more data
	LOAD T1,QNEXT,<+TCBRXQ(TCB)>	;check if retranmission queue empty?
	CAIE T1,TCBRXQ(TCB)	;skip if RXQ empty
	CAIL T4,^D8		; or if a large packet
	  MOVX T2,<XCDSEC,,ENCPKT> ; otherwise wait for more data
	MOVEI T1,^D200		;	for a couple hundred millisecs.
	CALL (T2)		;call appropriate packet routine.
OPSCA7:	MOVE T2,LINADR		; Restore address of terminal block
OPSCA8:	CALL ULKTTY		; Decrease reference count, OKINT
Date:      Fri 21 Feb 86 06:12:11-PST
From:      Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA>
Cc:        tops-20@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Tops20 TVT performance improvments
A release 5.4 equivalent of BillW's change is follows.  It does make a

	 SKIPA T4,T1		; Yes.  Get PZ to call SNDTVT
	  JRST OPSCA7		; No.
	MOVX T1,^D200		; The function to queue for PZ if a lot
	XMOVEI T2,ENCPKT	; to send - wait a bit, maybe more
	CAIGE T4,^D8		; Less that 8 is echoing so
	  XMOVEI T2,FRCPKT	; Queue for PZ promptly
	CALL (T2)		; See Note above
;;; FRCPKT is called if:
;;; . There are less than 8 bytes (probably echoing) in the packet and the
;;;   retransmission queue is empty
;;; OR
;;; . The terminal output buffer is full
;;; Otherwise ENCPKT is called instead

	CALL TTSOBF		; Is output buffer full?
	  CALL FRCPKT		; Yes, might as well send it now
	  CAIL T4,^D8		; Looks like echoing?
	    LOAD T1,QNEXT,<+TCBRXQ(TCB)> ; Yes, get RXQ
	    CAIE T1,TCBRXQ(TCB)	; Is the retransmission queue empty?
	    CALL FRCPKT		; Yes, queue for PZ promptly
	    MOVX T1,^D200	; Output not full and not echoing, wait a bit
	    CALL ENCPKT		;  for more to output
OPSCA7:	MOVE T2,LINADR		; Restore address of terminal block
OPSCA8:	CALL ULKTTY		; Decrease reference count, OKINT

I don't believe this problem was the cause of the TVT SMTP server problem,
nor will this fix repair it.  The TVT SMTP server doesn't echo.
Date:      Fri, 21 Feb 86 09:31:42 EST
Subject:   workstation != gateway
I totally concur with Jeff that workstations should not think they are
gateways. That is a massive abuse of the IP spec. It should be possible
to turn off all gateway functionality in 4.2 and 4.3BSD machines.

My example of the problem was forwarding loops of unusally addressed
broadcast packets. This happened on a full-duplex network (proNET),
where a packet came in and went out as a hardware broadcast. This is
yet another danger of gateway/workstations, but one you don't see
with half-duplex networks like Ethernet.

					John Shriver

Date:      Fri, 21 Feb 86 10:18 EST
From:      David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To:        Jeffrey I. Schiller <jis@BITSY.MIT.EDU>, tcp-ip@SRI-NIC.ARPA
Subject:   Interesting Ethernet/UNIX 4.2 observation.
    Date: Thu, 20 Feb 86 23:35:17 EST
    From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)

    Moral of the story:

    1) The Ethernet topology described above may not be the best possible
       for an office area (but we all probably know that anyway).

    2) A Network Spy program like netwatch is an invaluable tool.

       idea. In fact it is probably best that when a workstation receives
       a packet incorrectly sent to it, the packet be DISCARDed and
       perhaps logged for debugging purposes.
       Note that if a workstation sends an ICMP destination
       unreachable message back to the source, the monster
       collision would still occur as ALL workstations would try
       to send the ICMP message.

    4) Ethernet controllers that work "most" of the time may not be
       good enough.

There are two more morals:

    5) Unix is being antisocial by BROADCASTING information (rwhod) once
       a minute.  As far as I know, only Unix cares about this.

    6) Unix is being antisocial by BROADCASTING requests (rwho) once
       every few minutes.

Consider 200 nodes on the same cable.  That is a moral#5 broadcast
packet averaging 4 times a second, and a moral#6 packet at a hopefully
slower rate.

There are other things than Unix in the world.  If Unix doesn't have
system configuration parameters to turn either or both of these off; it
should.  Why must EACH Unix do this sort of thing all night long when
there is no user that is actually requesting the information.  It's sort
of like me programming my machine to send a message to this mailing list
every half hour just to let everybody know my machine is still up.

Summary of morals 5 and 6: fix Unix.

Date:      Fri, 21 Feb 86 12:10:46 est
From:      martin%blade@mouton.ARPA (Martin J Levy)
Subject:   Re:  workstation != gateway
There are two problems  with the 4.2bsd release running on a
workstation.  The first is the concept of IP forwarding, you can turn
this off by setting the kernel variable "ipforwarding" to 0. This can
be done with adb(1), or by recompiling. The second problem is a bit
more serious.  The router running under 4.2bsd is ment to keep quiet if
it's running on a machine with one one interface and just listen to
route packets. But under some conditions it will send out a route
packet and some machines on the local network will belive that the
workstation is a valid gateway to another network. This is of course
wrong. It's just a coding error, but it got out on the release tape.

There is another school of thought that believes that a host (ie a
workstation) with one one interface should not run a routing protocol
and just use a default route and expect ICMP redirects to guide it to
the correct gateway. If that view is taken then you will never get the
case of a workstation acting as a gateway

martin levy.
bellcore, nj.
Date:      21 Feb 1986 14:57:45 EST (Friday)
From:      T. Michael Louden (MS W422) <>
To:        tcp-ip@sri-nic
Subject:   Re: workstation != gateway
There was a second problem mentioned that is just as bad!
Neither Gateways nor Workstations should reply with an unreachable
message to a packet sent to the broadcast address!!
This can cause a big mess!! ( I have been a victim if this one also!)
Date:      Fri, 21 Feb 86 15:48:56 est
From:      dab@BORAX.LCS.MIT.EDU (David A. Bridgham)
Subject:   workstation != gateway
	In general, machines (either gateways or workstations) should
not forward packets that were broadcast.  This can causes all manner
of breakage with packet loops and flooded nets (Send an ICMP ping to
the broadcast address of a ringnet that has machines on it which
forward broadcast packets.  It will take a couple of minutes for the
time-to-live fields to get rid of all the packets, during which time
the machines on that net will not be much use.).
	The exception of course is the case where there is a specified
mechanism for multi-subnet broadcast and that is being used.
Date:      Fri 21 Feb 86 19:15:46-EST
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        martin%blade@MOUTON.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  workstation != gateway
	Right. There isn't a spec for exactly what a gateway has to
do; if there was such a spec it would need massive updating, since the
job of the gateways is continually changing. The IP Engineering Group
is exploring some pretty substantial changes to gateways, which will
make tracking the gateway functions even more difficult.
	My recommendation has for quite some time been that hosts and
gateways are very different, and that we should provide a 'specification
for a host IP layer' that will insulate hosts from changes in the
switches. It's not easy to make a host into a gateway, as the Berkeley
people found to their (and our) cost. Worse yet, the Engineering group
is stuck with either having its options limited by backward compatabilty
with unsuitable designs (as is the case with RIP [routed] and EGP).
	People building host IP layers should eschew adding 'simple
gateway functionality'; it's not simple. If you do, you'll be stuck with
something that a) doesn't work right, and b) will break even if it works
OK now, as the architecture changes. I like to make the analogy with the
electric power grid; it's easy to build an appliance you can plug in
that uses power (equivalnte of host); it's a much trickeier job to build
a generator you can plug into the system to support it (gateway).
	Too many people say "Oh, I already have a PDP11 (VAX, Sun, PC,
RT, etc); I'll just add another interface board and whip up a little
code." It's not that simple; 'nothing in networks is ever as simple as
it seems'. As the system grows, and we add mechanisms to deal with the
problem we are now seeing (e.g. the massive congestion, etc) it will just
get more complicated. 'There's no such thing as a free lunch.' Believe

Date:      Fri, 21 Feb 86 22:03:03 EST
From:      jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To:        martin%blade@mouton.ARPA (Martin J Levy)
Subject:   Re:  workstation != gateway
Our workstations DON'T run a routed routing daemon. They do in fact
maintain a default route to a "smart" gateway. The problem we were
experiencing was the result of a misconfigured machine sending a broadcast
packet that the other machines misinterpreted as a packet that needed
to be forwared.

Setting ip_forwarding to 0 doesn't help the problem because what would
happen in that case (under 4.2) is that all ~40 stations would simultaneously
attempt to send an ICMP destination unreachable message, which would
cause a monster collision (I am repeating myself slightly here).

To summarize: The problem is that 4.2 thinks it is a gateway, so that when
someone accidently sends it a misdirected packet, it does something...
usually it is something harmless, but not always.

Date:      22 Feb 1986 12:17-EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: rlogin support for non unix hosts
MCI Mail uses VMS on an X.25 network. Users authenticate themselves
at the TAC (PAD) level and a network authentication server tells the
TAC (PAD) which host to connect the user to (mailboxes move around,
but users don't need to be aware of it). We use a non-standard X.3/28/29
virtual call protocol to make the connection to the target VAX and
carry the user identifying information in the initial call request
to avoid the need for double login.

Date:      Sun, 23 Feb 86 16:37:53 PST
To:        jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
Subject:   Re: Interesting Ethernet/UNIX 4.2 observation.
Neat story. Thanks for sharing the info.

The Pup specs have always included a bit of important fine print about
sending back error Pups: don't send them in response to another error
Pup, and don't send them in response to a broadcast Pup. I think
"broadcast" should be extended to include the physical layer as well as
the logical layer to catch ARP type mixups.

I couldn't find the corresponding idea in the ICMP specs. Did I flip the
pages too fast?

We recently uncovered a similar glitch. We had a bug in our ARP like
code. It was returning an unitialized variable if the target machine
hadn't yet responded to the ARP request. That gives a 50% chance of the
multicast bit being on. Our gateways are willing to "forward" a Pup back
out the same interface it came in on. (That occasionally happens while
the routing tables are changing.) We have 6 or 8 gateways on that net
and they all include the same bug, so I'd expect a real explosion. All
we got was occasional "too many hops" errors. I guess the frames were
mostly reused in a lucky pattern.

BTW: Broadcasting an echo packet is a wonderful stress test for a
Date:      Sun, 23 Feb 86 23:22:24 EST
From:      Chris Torek <>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  Interesting Ethernet/UNIX 4.2 observation.
Unix does not broadcast rwho requests; rwho runs entirely locally.
Rwhod *must* send updates in order to allow downtime determination
at remote sites (though if all you are interested in is load average
and users, sending updates makes little sense).  In addition, there
is no easy way to determine who really *is* interested in the
information; the problem is quite similar to that of determining
to whom to send routing information.  The obvious easy answer is
to use broadcasts (on networks that support the concept).

In 4.3, rwhod sends broadcasts only once every two minutes.  If
this is still too much for your network, why are you running it at
all?  And if you are running it because it is more useful than it
is expensive, why are you complaining?  If you know how to make it
work better, change it!

This is not intended as flamage.  I am entirely serious: if it is
broken, fix it; if it is useless, do not use it; but please do not
simply complain that Unix is flawed because rwho uses broadcasts.
It comes configured that way only because those who make the tapes
find it more useful than costly.  It is quite simple to turn off.

Date:      24 Feb 86 09:11:05 EST (Mon)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: Interesting Ethernet/UNIX 4.2 observation.

One of the objections to 'rwho' is that it broadcasts.  It would be like
having one mailing list in usenet, and reading all the junk to get to the good
stuff.  What features would be needed on the local ethernet, and in the
cooperating U**'s, to have such services as 'rwho' multicast instead of
broadcast?  How would the multicast address be assigned?  How would you do it
on other nets which do not have logical addressing or multicast?

Is RFC966 (Deering and Cheriton, Host Groups: A Multicast Extension to the
Internet Protocol) a framework?

Date:      24 Feb 86 09:34:06 EST (Mon)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Interesting Ethernet/UNIX 4.2 observation. (gateway & multicast)

We have gateway interfaces to 3 different networks which implement a hardware
broadcast address, and in each of them have seen the effects of looping
packets because the gateway forwarded broadcast packets back onto the net.  We
have put in the extra check to drop at the local net layer, IP datagrams which
are addressed to the local net hardware broadcast address. (ARP is not dropped
because it uses a different link/protocol number.)

This means that the gateways will not respond to echo packets addressed to
'broadcast', but this means we can keep the <packet addressed to gateway> test
simple, and not have to search all the possible broadcast addresses also.

Date:      24 Feb 1986 1241-PST (Monday)
From:      Jeff Mogul <>
To:        Barry Shein <bzs%bostonu.csnet@CSNET-RELAY.ARPA>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   What to do about rwhod
    P.S. Just a thought, perhaps the ultimate solution will be smart
    interfaces that can be told a little about what packets the host
    is interested in and drop all others, tho again ultimately the
    problem will be the bandwidth of the cable. sigh.

I.e., multicast, as other people have suggested, would be the ideal
solution to the rwhod problem (and similar ones, such as
broadcast-based routing protocols.)  Unfortunately, it's not clear how
easy it will be to implement multicast support in 4.2 (and successors)
even if someone comes up with a good IP multicast spec.

Alternatively, maybe rwho/d could be run on a "lazy-evaluation" basis.
Change the rwhod servers so that the only time they broadcast status
packets is when they start up.  When someone types "ruptime" or "rwho",
if the information stored at the local host is more than, say, 5
minutes out of date, an "rwho status request" packet is broadcast; the
rwhod servers on the net respond with packets directed at the
requesting host.  This means that some packets are broadcast, but only
when the information is both wanted and hasn't been updated recently;
the number of broadcasts in the worst case is no more than currently,
and in the best case is epsilon more than zero.

The disadvantage of this scheme is that you no longer can be sure just
how long a catatonic host has been down, unless people having been
requesting updates fairly often.  There are obvious algorithms to
maintain this sort of information, i.e. use a designated central site
to poll other sites (non-broadcast) at reasonable intervals, and use
broadcasts only to join the group or recover from the loss of a central
Date:      Mon, 24 Feb 86 10:22 EST
From:      David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Interesting Ethernet/UNIX 4.2 observation.
    Date: Sun, 23 Feb 86 23:22:24 EST
    From: Chris Torek <>

[Sigh, our domain code isn't quite in yet... I'm assuming this gets to
you through the mailing list...]

[Disclaimer: I don't use Unix.  For that matter, I seriously dislike

    Unix does not broadcast rwho requests; rwho runs entirely locally.
    Rwhod *must* send updates in order to allow downtime determination
    at remote sites (though if all you are interested in is load average
    and users, sending updates makes little sense).  In addition, there
    is no easy way to determine who really *is* interested in the
    information; the problem is quite similar to that of determining
    to whom to send routing information.  The obvious easy answer is
    to use broadcasts (on networks that support the concept).

Maybe I'm confused then.  Somebody is sending out broadcast packets to
UDP port 513 (decimal).  Is that RWHO or RWHOD?  Our Lisp machine system
thinks that the protocol is called :UNIX-RWHO.  Maybe that is wrong.

    In 4.3, rwhod sends broadcasts only once every two minutes.  If
    this is still too much for your network, why are you running it at
I wish we weren't.  Tell me the flag to set, and I'll tell our unix
people to set it.  If you tell me, 'Well, you have to go in a modify
code...' I'll ask why there isn't a flag.
    And if you are running it because it is more useful than it
    is expensive, why are you complaining?
I don't know if anybody uses the information.  I would guess not.  We
aren't a unix house.
    If you know how to make it work better, change it!
I've fixed my machine to ignore these, but that doesn't affect the other
100+ workstations that are still wasting time responding to our 3 unix

    This is not intended as flamage.  I am entirely serious: if it is
    broken, fix it; if it is useless, do not use it; but please do not
    simply complain that Unix is flawed because rwho uses broadcasts.
    It comes configured that way only because those who make the tapes
    find it more useful than costly.  It is quite simple to turn off.

Tell me how.

Date:      Mon, 24 Feb 86 19:50:29 -0800
From: (Mike Karels)
To:        "J. Noel Chiappa" <>
Subject:   Re: workstation != gateway
I agree with Noel and others that hosts and gateways have rather
different properties, and that the gateways' role is changing faster
than that of hosts.  If there were a specification for a host IP layer
that insulated hosts from all future changes (except, of course, those
required to bring them into compliance initially, and whenever the spec
did finally change), then I would only have to worry about changes
affecting gateways at Berkeley.  Until that time, I will have to
continue to support both hosts and gateways.  If I were to do each
separately, I would have twice the work.  Instead, I have chosen to
extend and correct the gateway support that was in 4.2 and continue to
use "hosts" as gateways.  Although there is no spec for what a gateway
has to do, I think that it is quite likely that a 4.3BSD Unix system
would pass most reasonable specs.  At the same time, 4.3 is better
at 4.2 at discovering that it is not in a position to act as a gateway
and remaining quiet.  (Before the corrections fly, as a result of this
discussion I changed 4.3 not to respond with ICMP unreachables
if it is unable/unwilling to forward packets).

The idea of well-defined interface between hosts and gateways to avoid
future need for changes in the host is attractive.  However, such an
interface must be sufficient for optimal use of the network by the
host, resilient to future change in the gateways and other network
underpinnings, and compatible with varying usage of IP-based networks
from isolated LAN's, to single hosts on the Arpanet, to subnetted
and heterogeneous high-speed networks interconnected to one or more
long-haul nets.  I find it hard to believe that such a specification
will be sufficiently functional that people will not be forced to extend
it for some situations, but will be sufficiently simple and close
to the current specifications that it will be widely adopted by vendors.
Minor variations, such as multi-homed hosts, require the host
to be much more knowledgeable about its environment.  Even Noel,
in complaining of the need to be compatible with the Berkeley routing
protocol and EGP, recognizes that there are limits to the changes that
are possible now.  I don't think that compatibility with either
of these is actually necessary.  Incidentally, Noel, the unknowing
might take your statement to imply that both of these "unsuitable designs"
originated at Berkeley; we won't take the blame for EGP, nor will we
claim that the "RIP" protocol is suitable for the things that you are
trying to do with it.

An unfortunate fraction of the discussion that resulted from Jeff Schiller's
original note was based on oversimplification or misinformation.
For example, a number of comments mentioned "the broadcast address":
wayward packets sent to the broadcast address should not receive error
indications or be forwarded.  Which broadcast address?  If the hardware
broadcast address, this can be handled easily on machines that support
only IP and 10Mb/s Ethernet.  This is a bit more difficult in the 4.2
architecture, which supports numerous types of network interfaces
as well as multiple protocol families.  By the time IP or ICMP
receives the packet, the hardware sender address is not longer around,
and IP/ICMP neither do nor should know how to tell if a hardware
address is a broadcast.  On the other hand, if the comments were
directed at handling packets with an IP broadcast address, there
is the problem of determining the sender's notion of a broadcast. 
Possibilities on a subnetted net include (as "ThisNet.0",
"ThisSubnet.0", "ThisNet.ff", "ThisSubnet.ff", "SomeOtherNetOrSubnet.0",
"SomeOtherNetOrSubnet.ff", "0.0" from diskless workstations trying
to find out where they are, and perhaps 32 bits of ones.  (4.3 recognizes
and receives all of the above except for the two "SomeOtherNetOrSubnet".
The outgoing broadcast address is the address with a host part of all ones,
but this can be set to use other addresses for compatibility.)
If two packet-forwarders on the same net disagree as to the broadcast
address, chaos will likely ensue.  On one of our subnets, each time
a router broadcasts an update, it receives 4 redirects from the 3600's
on the net that don't understand subnet broadcasts.

Another bit of misinformation concerned the Unix insistence on
broadcasting this information.  The broadcast "rwho" status updates are
sent by a user-level program ("/etc/rwhod").  It uses no requests,
broadcast or otherwise.  If a site doesn't want to run this program,
they need only delete the line invoking it from the system startup file.
The Unix kernel does not demand or provide any network servers or
clients; they are all implemented as user-level processes, and any or
all may be omitted or substituted at any site.  This includes the
routing program "routed", which may be used to manage routing
within a set of connected local nets, or which may be omitted
in favor of a default gateway or manually-installed routes.

The use of multicast for such functions as Unix "rwho" status,
routing, ARP requests, etc. is attractive.  However, many
of these things are not restricted to networks and hardware
interfaces that support multicast.

By the way, I was interested to hear that the BBN gateways reject
all IP packets sent to the hardware broadcast address.  It seems that
one of the "hosts" on the net will have to answer the broadcast
ICMP information requests and network mask requests.

Date:      24 Feb 1986 14:35-PST
From:      Steve Deering <deering@su-pescadero.ARPA>
To:        Philip Budne <BUDD%BUCS20%bostonu.csnet@CSNET-RELAY.ARPA>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Ethernet / Unix Rwhod
> I have often wondered if the problem might be better solved using
> "multicast" ethernet addresses.  This way only sites which care about
> the information ever see it on the host end of the ethernet.
> The problem is specifying how to map IP addresses into outgoing
> ethernet multicasts.

See RFC966 for a proposal for IP multicasting.  I am planning to publish,
sometime soon, a complete specification and report on our implementation

I believe ALL use of broadcast should be replaced by multicast.  Ethernet
and all flavours of IEEE 802.2 networks support the proper addressing mode,
and interfaces that provide adequate multicast filtering are available,
so that we can now obtain the benefits of cheap multidestination (and
unknown destination) delivery without interrupting every machine on a

If it didn't mean changing the whole world, I would advocate changing
ARP to use a multicast address.  Currently, when we want to use the
Internet protocols on our workstations, we must listen to the broadcast
address just so we can hear ARPs.  That opens us up to all the other
broadcast junk that flies around the Stanford subnets (UNIX rwho packets,
PUP routing updates, Sun ND boot requests, XNS broadcasts, Chaos
broadcasts, DecNet diagnostic packets, etc., etc.)  In this kind of
environment, there is no type of packet that EVERYONE wants to hear.

						-- Steve Deering
Date:      Mon, 24 Feb 86 12:06:37 EST
From:      Barry Shein <bzs%bostonu.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re:  Interesting Ethernet/UNIX 4.2 observation.

The fix to UNIX to stop broadcasting rwho information is trivial,
remove the lines that start it up from the /etc/rc (text) file.
On suns for example the system is delivered with the lines commented

Another compromise might be to reduce the frequency with which
this info updated from one minute to, say, 5 or 10 minutes though
this might render it useless to some. Unfortunately that at best
just pushes the inevitable back further. Our users here seem to
like the 'ruptime' command so much that people have hacked in little
forwarders so it crosses from one local ethernet to another and all
machines can be seen. I am not saying this is right or wrong, just
that people do like the feature and frequent update is probably the
only way to acheive it, if I have to order it shut down I bet people
scream, but they always scream...

Obviously we are running into a problem that is not at all peculiar
to UNIX. Anyone could write a program that seems useful but generates
lots of traffic on a net. Even if broadcast addresses are priviliged
this could make things worse as the user circumvents this by looping
through a hosts.txt file on each machine sending, say, udp packets
to everyone.

On the other hand, the danger of resource hogging has always been
a problem, there is nothing new here EXCEPT that it used to be
limited to the machines the culprits had accounts on.

In other words, I suspect we are dealing with a purely administrative
problem here (which *might* have some technical solutions, as usual.)

	-Barry Shein, Boston University

P.S. Just a thought, perhaps the ultimate solution will be smart
interfaces that can be told a little about what packets the host
is interested in and drop all others, tho again ultimately the
problem will be the bandwidth of the cable. sigh.

Date:      Mon 24 Feb 86 14:08:49-EST
From:      Philip Budne <BUDD%BUCS20%bostonu.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip%sri-nic@bu-cs.bunet
Subject:   Ethenet / Unix Rwhod
Regarding rwho haters;

Rwhod is a single program that sends broadcast packets on a frequent
basis, as well as listens for packets from other sites and writes the
received packets to a spool directory.  Ruptime and rwho just scan
through this directory and type out the information.

I have often wondered if the problem might be better solved using
"multicast" ethernet addresses.  This way only sites which care about
the information ever see it on the host end of the ethernet.

The problem is specifying how to map IP addresses into outgoing
ethernet multicasts.

I must confess that I am quite fond of user environment information
programs, here we run RWHOD under Unix, TOPS-20, VMS, and on a 3b2.
In my previous job inside DEC, I had to fight to install even a finger
program and a passive server for it.  The argument always involved
WASTE OF RESOURCES.  These people also frowned on EMACS as a hog, and
never took me seriously because I worked on something as silly as a
compiler (and one that was written in a high level language!).  And
then there were the people who frowned at attaching an ethernet to
their precious system "causes interrupts" they told me...

	Philip Budne
	Boston University / Distributed Systems

Date:      24 Feb 1986 18:20:53 PST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: interesting ethernet/unix 4.2 observation -- icmp errors

See RFC-792 page 1 last paragraph, "To avoid the infinite regress of messages
about messages etc., no ICMP messages are send about ICMP messages."

Date:      Tue 25 Feb 86 01:00:07-EST
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        karels@MONET.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, JNC@XX.LCS.MIT.EDU
Subject:   Re: workstation != gateway

	I never intended to saddle Berkeley with the blame for EGP!  I
will also say in Berkeley's defense, that I'm not sure that *anyone*
recognized that IGP's would have to cart around info as to the source
of routes until long after Routed was done. Still, there's *no*
upwardly compatible way to extend it that we could find. (Defining a
whole new protocol with a different version doesn't count.)

	One issue that people over look with all these different
broadcast addresses is that they can be fairly expensive to check for
in gateways. I recognize all the same formats as you do, and in our
(additedly hyper-optimized) gateway it's *expensive*! I have figured
out some optimization recently, but it's still going to cost a fair
chunk. Right now, routing is about 5-10% of fowarding costs. Was it
wise to slow down basic packet forwarding, by e.g. 5%, to make broadcast
(used on %.01 of packets) work?
	Unless you want to assume that broadcast packets are flagged
by a hardware boardcast address (not a good assumption for a variety
of reasons) checking for broadcast will be somewhat expensive.
Depending on how multi-cast was added, it might also wind up as
somewhat expensive. (BTW, I wish people wwould start using FFFFFFFF
for 'local wire broadcast' like the spec recommends; it is so much
easier to deal with, and you don't have to think about what parts to
mask off and on.)

	I can't believe that BBN gateways discard input packets sent
to the broadcast address. (My gateways discards packets sent to an
address that happens to be the local broadcast address, unless
specifically told to broadcast the packet, but don't do anything like
that to an incoming packet.) What on earth do you gain? Any packet that
algorithm would discard could have been sent directly to the gateway
in any case, and it prevents some really useful functions.

Date:      Tue, 25 Feb 86 09:40:09 pst
From:      imagen!geof@decwrl.DEC.COM (Geof Cooper)
Subject:   Re: workstation != gateway -- CLANG CLANG CLANG

 >      ...  Which broadcast address?  If the hardware
 >      broadcast address, this can be handled easily on machines that support
 >      only IP and 10Mb/s Ethernet.  This is a bit more difficult in the 4.2
 >      architecture, which supports numerous types of network interfaces
 >      as well as multiple protocol families.  By the time IP or ICMP
 >      receives the packet, the hardware sender address is not longer around,
 >      and IP/ICMP neither do ****NOR SHOULD KNOW**** how to tell if a hardware
 >      address is a broadcast.  (emphasis added)

Excuse me, my bogometer just went off with an almost audible clang.  Perhaps you
have devised an architecture whereby it is awkward to transmit the information
that a packet was broadcast.  It does not follow that this information SHOULD
be obscured.  The reason why it should NOT be obscured is exactly what you and
Noel have been talking about -- sometimes a higher level protocol would like to
know information available in the network header.  For example, an ICMP
router should probably flag the case where a packet is forwarded to the
interface whence it came.  And, as was just mentioned, various services such
as ICMP want to make sure that they don't respond with an error packet to a
request that was broadcast.

Local net information can be thought of as an attribute of the packet, and
passed across the network layer in a modular fashion.  The multi-interface device
layer that we use here at Imagen passes these attributes along with the packet
to the higher layer.  The format of the local network header is abstracted, and unknown
to the higher layer.  The attributes passed include the hardware address, which is
tagged with the interface type, a la 4.2.  A special set of "virtual addresses"
is known to the interface.  Some of these are things like Internet and XNS-IDP
addresses, which are mostly used at higher levels.  One is "NULL" -- no interface
(black hole), and one is "BROADCAST".  A packet sent to virtual address "BROADCAST"
causes the interface to make a best effort at broadcasting the packet.

Since the internet layer can get hold of the local address, it can have an interface
to ARP that says: "by the way, here is a binding that I happen to know is true,
please remember it."  This greatly enhances ARP performance, and modularity
is not violated.  The ARP layer is handed two tagged addresses, one a virtual
address and one a hardware address, and is told to associate the two.  If ARP is
not used for particular hardware, the ARP layer just discards the information
about that hardware.

In summary, you CAN pass broadcast and other network-layer information to higher level
protocols, and you can do so in a way that is compatible with the principles of
modularity and layering.  What's more, higher level protocols SHOULD be able to
find out this information; witness that I've given you some good uses for the it.

Now, want to fix 4.3? :-)

- Geof Cooper
Date:      25 Feb 1986 1736-PST (Tuesday)
From:      Jeff Mogul <>
To:        imagen!
Cc:, tcp-ip@sri-nic.ARPA,
Subject:   Re: workstation != gateway -- CLANG CLANG CLANG
Although I entirely agree with Geof that the 4.2 networking architecture
got this part wrong, in fairness to the current crew at Berkeley it should
be noted that 4.3 remembers which interface a packet arrived on.  This
should make it possible, finally, to implement ICMPs such as Address Mask
and Information Request, perhaps even Host Redirect, and reverse-path
forwarding of broadcasts (if anyone wants it.)

Maybe the lesson that should be learned from Geof's message is that
the incoming interface is not the only piece of information that should
stay stuck onto a packet for its entire lifetime in a gateway.  Whether
it is reasonable given the current 4.2/4.3 networking architecture to
track things such as
	packet source (data link layer address)
	was it sent as a broadcast?
	how long is it? [so that higher levels don't have to count it again]
	when it arrived [for accurate metering]
etc. may depend on how committed people are to the current model, where
only the "data" gets passed between layers.  I think this stems from a
basic confusion between networking and IPC in 4.2; there seems to me to
be an attempt to shoehorn both kinds of communication into a single model.
Date:      Tue, 25 Feb 86 16:12:49 est
From:      dab@BORAX.LCS.MIT.EDU (David A. Bridgham)
Subject:   workstation != gateway
	When I said that machines should not forward broadcast packets
I meant packets that were broadcast on the local net (i.e. addressed
to the hardware broadcast address).  Sorry for being unclear.
	I agree that the IP layer *shouldn't* have to know that a packet
was broadcast, but until the IP broadcast spec (which is rather recent
and most hosts still don't follow) that was the only reliable way to
decide that a packet had been broadcast and therefore not forward it.
(Gateways still might want to do that for general network robustness
Date:      Thu, 27 Feb 86 18:50:49 EST
From:      Mike Muuss <mike@BRL.ARPA>
Subject:   Poor mil/arpa performance
As another data point, I offer the following two
PING studies, conducted 1820-1840 EST from BRLNET3 (192.5.23.x): PING Statistics----
204 packets transmitted, 203 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 60/230/4860 PING Statistics----
38 packets transmitted, 38 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 320/434/840 PING Statistics----
554 packets transmitted, 148 packets received, 73% packet loss
round-trip (ms)  min/avg/max = 2300/13914/28960

BRL-TAC is on the same MILNET IMP as our (two) Gateways.  The max of 4,860ms
implies that we are suffering some interface blocking (even though
we do RFNM counting), but examining the PING log only showed one such

NOSC is on the West Coast (BRL is in Maryland) -- transcontinental MILNET
bandwidth seems just fine.

SEISMO is on the ARPANET in Washington DC, on the other side of the core
from us, yet network performance to them is awful.

I mention this because BRL has business (of significant volume) with
a number of ARPANET sites, mainly Utah, Seismo, Berkeley, and BBN (yes,
the Butterfly part of BBN seems to be on the ARPANET, and having them
debug our Butterfly through the core drives them bonkers).


Given the difficulties in getting trunks installed (in understand, and
you have my sympathies), I think DCA has done a bang-up job of keeping
the MILNET in good, working order.  It's effective to use at most any
hour, and that is good.  They deserve our congratulations!

There exists this bottleneck called "the MIL/ARPA" bridges, and the
additional complications of the "EGP extra hop" problem which causes
up to 3 times as much IMP Trunk bandwitdh to be used for each packet.
(ie, BRL-GATEWAY to our EGP-speaking core peer via MILNET, from him
to the MIL/ARPA bridge via MILNET, then to the destination via ARPANET).
The same sort of thing can happen on returning packets too (depends on
whether there is a gateway involved on the ARPANET side, usually yes).


The MILNET is sound.  Praise DCA!

The MIL/ARPA bridges are teetering under the load.  They are important.
EGP makes it worse.  What can we do?

Date:      Fri, 28 Feb 86 00:33:49 EST
From:      Rick Adams <rick@seismo.CSS.GOV>
To:        mike@BRL.ARPA,
Subject:   Re:  Poor mil/arpa performance
seismo's darpa project admin is physically in the next building, but
is connected to a milnet tac. seismo is on the arpanet. The
response is SO BAD that we are actively trying to have her and her
associates moved from arpa2-mil-tac to arpa3-tac in hopes of her
getting characters echoed is less than geological time.

It's really hard explaining that the only thing you can do for  your
"boss" is to run a dedicated line to her office; that her nifty
dedicated port on the tac is almost useless.

It's kind of scary thinking about how far the packets are really going
to traverse that 100 yards seperating us physically.

The arpa/milnet bridges are clearly inadequate.


Date:      28 Feb 86 09:03:23 EST (Fri)
From:      Mike Brescia <brescia@BBNCCV.ARPA>
To:        Rick Adams <rick@seismo.css.GOV>
Cc:        tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA
Subject:   Re: Poor mil/arpa performance

     response is SO BAD that we are actively trying to have her and her
     associates moved from arpa2-mil-tac to arpa3-tac in hopes of her
     getting characters echoed is less than geological time.

The idea of homing choice between mil- and arpa-net was to put users and hosts
on the correct net, or the most used net for that host or person.

What kind of terminal is she using, and is she telnet-ing to seismo
( or going to one of your hosts on local nets?  The terminal type
would mainly govern what kind of applications she uses; video at 9600 baud
would imply using a screen editor, and I find with emacs/pen that
psychologically, I expect (DEMAND!) quick response.

The TAC software version, and transmit mode effect how much the characters are
accumulated above one keystroke per packet.  (Is she a 5wpm typist, or 50 wpm?)
What about your host and its approach to echo characters?  Are you forcing the
exchage of 8 packets for every keystroke?  ((key + echo) * tcp-ack * rfnm)

     It's kind of scary thinking about how far the packets are really going
     to traverse that 100 yards seperating us physically.

It's the smallest possible, since the connection is
	tac - milimp106 - gateway - arpaimp28 - arpaimp25 - seismo
(However if the connection is to a local net at seismo, all bets are off.  The
route is guaranteed to be ++~good.)

     The arpa/milnet bridges are clearly inadequate.

The fact that they are allowed to drop packets (because they have no handle to
do flow control) means the end point TCP must make up for it.  Lacking a
commitment to deliver is a strange way to run a railroad.  Let's fix it.

Date:      Fri, 28 Feb 86 11:16:49 est
From: (Scott Brim)
Subject:   Microvax Ultrix version 1.2: Pronet driver that tolerates subnetting??
Does anyone have one or know where I might continue the search?
Version 1.2 is the spanking brand new one.
						Thanks much,
Date:      Fri, 28 Feb 86 14:06:21 est
From:      romkey@BORAX.LCS.MIT.EDU (John Romkey)
Subject:   Microvax Ultrix version 1.2: Pronet driver that tolerates subnetting??
You might try getting in touch with John Shriver ( or
Mark Rosenstein ( They both read TCP/IP, so they
might get in touch with you...
				- john romkey
Date:      Fri, 28 Feb 86 14:10:34 EST
Subject:   pronet driver
I will get a Ultrix-32 and -32m V1.2 driver working as soon as DEC
gets me a copy of the operating system. Proteon is on an MIT
subnet, so we need subnets too. (We jury-rigged V1.1.) Is anyone
at DEC Unix Engineering Group listening? I could use a copy
soon--I'm paying $400 a month for software support...

BTW: this is why exists. Let's
direct this discussion there.

					John Shriver