The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for November 1987 (403 messages, 234858 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/11.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Nov-87 07:05:06 EST
From:      farber@UDEL.EDU (Dave Farber)
To:        comp.protocols.tcp-ip
Subject:   Re: supdup protocol

The first notion I know of to separate the front end of an
editor and the back end was at least 1963 (the one I know was
at BTL back then). (Note the term AT LEAST)

Dave

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Nov-87 11:49:43 EST
From:      hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

Now that source routing is becoming accepted, IP gateways are no
longer guaranteed to provide security.  A host can pretend to be
a host on a different subnet, but use source-routing in such a 
way that the other guy is told to route the packet back thru the
bad guy's real address.  The bad guy of course does not forward
the packet.

IP gateways are normally used because they provide isolation.  This
issue has been discussed so many times that I am reluctant to do it
once more.  In general, a LANbridge is more reasonable the fewer
Ethernets you have (making provisions for future growth), the fewer
different kinds of systems you have, and the better central control
you have over the systems on your network.  We have had disasters that
made every VMS system on a network connected by level 2 routing
unusable.  The problem should not get thru an IP gateway.  We have had
several disasters that were confined to a single Ethernet only because
of the use of IP gateways.  However if you have good network
monitoring and system management, a stable network/software
environment, or a small network, a level 2 system can be made to work.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Nov-87 12:07:57 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge, "equivalence"

We emphasize the security issues involved in "equivalent" hosts in our
manuals (it appears at least 3 different places).  We advise anyone
with security concerns just to "say no" to rsh and rcp, and use ftp or
an rexec client we provide instead.  However, there are still a lot of
people distributing and using Unices derived from 4.2 which require that
any host requesting printer services be "equivalent", and our package
includes an lpr client...

4.3 fixes this.  Are the guilty parties listening?

James B. VanBokkelen
FTP Software Inc.

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Nov-87 12:38:21 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

If you mean Bridge Communications' IP routing products, there is at least
one flavor and vintage of them out there which fragments all IP packets
longer than 540 bytes.  4bsd and relatives send TCP segments of 512 (552
bytes IP length) bytes by default, and TFTP packets are just large enough
to get caught, too.

I don't know about the big-machine people, but it has a fairly horrendous
effect on the older PC Ethernet cards, which aren't nearly fast enough to
catch both fragments reliably.  It is even worse when attempting to use one
of the public domain software packages that doesn't support IP reassembly.

jbvb

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Nov-87 17:40:37 EST
From:      schoff@NIC.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge


    Now that source routing is becoming accepted, IP gateways are no
    longer guaranteed to provide security.  A host can pretend to be
    a host on a different subnet, but use source-routing in such a 
    way that the other guy is told to route the packet back thru the
    bad guy's real address.  The bad guy of course does not forward
    the packet.

Chuck,

I don't need source routing to do that.  I can do that right now.

Marty

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Nov-87 21:43:59 EST
From:      jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To:        comp.protocols.tcp-ip
Subject:   Separation of Layers


	I should point out that at MIT we no longer use network
addresses as a form of authenticity. We now use our encryption based
"Kerberos" authentication service. The code you wrote to use the
subnet as a means of determining authentication has long since been
retired.

			-Jeff

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 08:00:25 EST
From:      snorthc@NSWC-OAS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

OK, I'll bite.  We have been looking at NFS as a UNIX/VMS server solution
for PCs.  From the begining of the investigation we were looking for
things like the 'huge security holes'.  Somehow I must have missed it.
I certainly have heard Netters alluding to such a thing.  Would you be
willing to spell out the problem, perhaps even complete with recommended
solutions or workarounds?

I may just be a hopeless case.  I had never considered using an IP
gateway for security purposes either.  When I read you message a tiny light
went on in my head for just a second... then I started thinking about
name/domain serving, additional levels of indirection, and so forth
and the light went out.  Do you encrypt your secure side?

Stephen Northcutt (snorthc@nswc-g.arpa)
(703) 663-7796 office, (703) 663-7191 lab

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 08:38:38 EST
From:      snorthc@NSWC-OAS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

James,
	You have my complete attention.  We have a growing investment in
Bridge Communications' IP routing products.  We also have a sizable, but
static investment in older PC ethernet cards (3C500/1, NI5010 ).
One such Bridge box that has served us well in the past is the GS-3.
A box that may have a place in our future is the IB-1.  You can probably
guess which PCIP we are using.  Most of our hosts are 4bsd.
Are we in danger, I suspect we are running either the latest,
or next to latest rev. of software for all products?  We certainly haven't
noticed a problem.  The cable is monitered for problems with a lanalyser
from time to time.  Perhaps this fragmentation problem is limited to an
older rev of Bridge s/w, at least I hope so.  In the two years I have been
here there has been a steady parade of s/w & ROM upgrades from Bridge.

The only time we have ever noticed a problem was with a DEC DEMPER of
all things.  It got connected to the cable with an improperly-labeled-
but-suspected-ver1-xceiver.  The 3c500s connected by thin net started
losing about every other packet.  The 3c505s were fine.  Changing the
xceiver fixed things.

In any case whose routing box do you recommend?

	Stephen Northcutt (snorthc@nswc-g.arpa)

Disclaimer:  I haven't had my coffee yet!  Only relationship I have with
companies explicitly/implicitly mentioned is as a happy customer.  Bridge
is asked to forgive me for mangling their part #'s (GS/3).

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 09:51:18 EST
From:      naftoli@aecom.YU.EDU (Robert N. Berlinger)
To:        comp.protocols.tcp-ip
Subject:   Subnetting: I'm not sure I understand

I'm not sure I understand subnetting fully.  Assuming you have a class C
address -- will subnetting allow you to have more than 255 hosts on the
network?
-- 
Robert N. Berlinger					naftoli@aecom.yu.edu
Supervisor of Systems Support
Albert Einstein College of Medicine			Compuserve: 73047,741	
UUCP: ...{philabs,cucard,pegasus,rocky2}!aecom!naftoli	GEnie:	    R.Berlinger

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 10:38:59 EST
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   pmdf over tcp-ip


Ed,

    The answer is yes -- at least, recent versions of VMS PMDF can run
SMTP over TCP.

Craig

PS:  For those of you who don't know what PMDF is...  There are several
versions of PMDF (which in turn are based on MMDF).  VMS PMDF is Ned
Freed's version of PMDF which is loosely based on the original Unix PMDF
by Ira Winston, which in turn is based on early versions of MMDF (by
Dave Crocker).  The 'P' stands for Pascal -- it was originally a simple
mail system designed for use with CSNET's PhoneNet.  The VMS version
has grown to rival MMDF in size and complexity.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 11:15:12 EST
From:      geoffb@ALE.TRW.COM (G. Geoffrey Baehr)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet bridge


Concerning Charles Hedrick's note about level 2 bridges, it is precisely
the quality of bridge management software that allows one to depend on a
level 2 solution. What information does exist from these bridges currently
seems to be non-uniform and of questionable value. Is there some bridge
out there which does have a specified reporting mechanism,or one which may
be queried in some manner. I have in mind the RBMS (Remote Bridge Management
Software) from DEC, but alas, this spec is not released by DEC to we common
folk. Without a diagnostic/reporting mechanism, level 2 bridges appear to
offer more potential for net-wide disaster. 

Geoffrey Baehr

I would be interested in knowing whether any vendor intends to implement 
portions of the HEMS work in their current or future products.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 11:15:34 EST
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ..."layering violations"


	Yes, I know they're *supposed* to. I meant to say that I've seen many
	gateways use the destination IP address of the original datagram as the
	source address for the IP datagram containing the ICMP message, and this
	makes it impossible to discern where the problem is.
	
	One implementation around here returns every broadcast it sees with
	a "port unreachable" ICMP message and puts the IP broadcast address in
	the IP source field!
	
	Phil
	
Phil,  I wish you would name names.  Being coy about whose box is
screwing up isn't doing anyone a favor.  Since there is no Internet
Conformance testing service, we have to  collaborate as a group to
"encourage" conformance from the vendors.

Bob Braden

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 11:35:16 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  On broadcasts, congestion and gong

Mike,

Thanks very much for thie information. I (and Bob Braden, I'm sure)
will be looking forward to your definitive statements on how 4.3+ conforms,
as well as any comments you have on what should be changed for the next
draft of the document.

Dave

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 12:27:00 EST
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: ..."layering violations"

Phil--
   A sidelight on keeping connections open "forever" seems appropriate,
just in case anybody doesn't attach enough strength to the quotation
marks you rightly used:  In the early days of the Multics "NCP" [sic],
we discovered that we were sending "RST"s (the old Host-Host Protocol
Reset command, which was sent whenever an NCP came back up, to "everybody"
--well, you could do that sort of thing when there weren't four dozen
Hosts in the world) without end to a particular Host.  It turned out the
problem was that we were getting "Incomplete Transmission" from our IMP,
so we tried again, since that code was supposed to mean that a temporary
problem had prevented successful transmission; however, the Host in
question had somehow jumpered their IMP interface in such a fashion as
to convince their IMP that they really were up when they weren't and so
we got the code in a circumstance where we really shouldn't have.
Naturally, we put a limit on the retransmisions after an Incomplete
Transmission was encountered after that (and we probably should have
had one in the first place).  The moral does seem worth pointing out,
though: keep connections open for appropriately small values of forever.
(For example, if you happen to get a Host Down, you might as well close
even if you're only a daemon, since the other side should come up again
out of Sequence Number synch--shouldn't it?)
   cheers, map
-------

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 12:32:52 EST
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   TCP and teaching bridges and routers about routes


> 	Interestingly enough, this is an area where the source routing
> scheme of IBM/ 802.5 is superior to the "proxy-ARP" routers (and maybe to
> the TransLan ether bridge schemes).  With the latter approaches, if a
> bridge/router which is not within "local broadcast" range fails, then there
> is no way for the local TCP to request that the path be redetermined.
> In the source route (802.5 variety) scheme, the local TCP merely causes a
> new route to be determined via a new "all rings broadcast" XID.

It is correct that the TCP cannot ask a DEC LANbridge (or other
equivalenly implemented learnig bridges) to try again on the route.
That is because the management protocols they use will detect the
failure before the TCP does, activate a new (previously backup)
bridge, and dynamically rethread the route.  The whole point of a
LEARNING bridge is that you don't have to TEACH it.  You do have to
TEACH an IBM Token-Ring bridge.

Of course, IP routers running dynamic routing protocols offer exactly
the same advantages.  They too will reconfigure faster than TCP can
notice when one intermediate path fails.  The host does not need to
ask for any help, at most it will get an ICMP redirect.

The only case where this advantage of routers will fail is in the ARP
proxy subnet hack.  This is why ARP proxy subnetting REQUIRES ARP
cache aging, which pure ARP, used for its intended purpose, does not.
That's why ARP proxy subnetting is a workaround, and not a standard.

Oh yes, you lose all the advantages of the frame-copied and
address-recognized bits in 802.5 when you use IBM bridges.  All that
frame copied means to the sender is that the first bridge copied it.
A later bridge may have to drop it (congestion), or be dead.  You
don't lose these advantages with routers, because they try again if
they don't get frame-copied.  This is why a ring makes a good router
backbone.

So far as I can see, IBM Token-Ring source routing combines the bad
aspects of routing and bridging into a big layering violation.  It
will persist, however, due to SNA's reliance on it.

(These are my opinions, and have not been certified or blessed by
Proteon.) 

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 14:34:27 EST
From:      mcdermot@merlin.unm.edu (John McDermott)
To:        comp.protocols.tcp-ip
Subject:   TCP/DECnet interchange router for VMesS

Organization:Applied Technology Asociates


I have a problem which I hope someone has already solved:  I have a
TCP/IP net and a large DECnet net both served by a common VAX (vms).
Some hosts on the decnet network also run tcp/ip.  All tcp is CMU/TEK for vms.
Now the question: are there drivers to encapsulate ip packets, send them
over the DECnet and then make them available for retransmission at the other
end?  I need this because my VAX with Decnet is connected to the rest of
the DECnet network by a 56kb line and that line cannot be used for both
decnet and tcp/ip (for political reasons at least).  Any help would be really
appreciated.

Try afwl-vax.arpa!atavax.decnet!mcdermott  or maybe there is enough
interest here you should just post any results.  Thanks.
--john
John McDermott			ARPA: mcdermott%atavax.decnet@afwl-vax.arpa
Applied Technology Assoc	W (505) 247-8371
1900 Randolph SE
Albuquerque, NM 87106		H (505) 255-7796

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 16:42:51 EST
From:      wire@iwarpj.intel.com (Wire Moore)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Slang Glossary

The reading getting a might thick for me, and others I suspect, who are
green to this group.  Would someone post a glossary of the slang this group 
favors? 

Thanks.

[fuzzball? bogon? gong?]

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 16:49:14 EST
From:      david@E.MS.UKY.EDU (David Herron E-Mail Hack)
To:        comp.protocols.tcp-ip
Subject:   Re:  Ethernet Bridge

Well ... the only hole which I know by heart is the following
situation.  You have someone with a workstation and he has the root
password for his workstation.  He also has some local disk storage.  He
makes a setuid shell on his local disk.  Then he goes over to another
system and executes his shell, thus giving him root on that system.  In
our case we use equiv hosts to simplify a lot of things, but don't use
fully transitive equivalancies in a lot of cases.  The reason this is a
hole has to do with Unix using a simple integer to encode the user id
... If there were some sort of indication of the host that the user id
pertained to ...

Oh, in the particular situation, the user MUST have root access to his 
own workstation so that he can properly do his research.  Fortunately
he's a nice guy ... :-)

For a good time read section 2.2.2. of Suns NFS Protocol Specification.
It talks about the above bug and others.

As for using an IP gateway for security ... Well, consider me something
of a beginner in TCP/IP issues.  But I still have to manage the local
end of our net, and give advice to the people around me.  I understand
enough that the idea of a gateway knowing that a certain class of IP
numbers can only come from one side of the gateway makes sense.  But
this source routing stuff which someone mentioned is unfamiliar
territory to me.  I've been reading the discussion about source routing
and know that it apparently only applies to token ring.  However, it
seems that if there is to be support for source routing in the kernal,
then you could use it from any sort of network hardware.  Is the idea
with source routing to encapsulate an IP packet inside another one
which is addressed to a gateway machine, and the encapsulating packet
says where to send the encapsulated packet?

The use of IP gateways to wall off sections of the net to contain IP storms
makes sense ... We may set things up that way ... does anyone have any
recommendations on a good IP gateway?
--
<---- David Herron,  Local E-Mail Hack,  david@ms.uky.edu, david@ms.uky.csnet
<----                    {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- "The market doesn't drop hundreds of points on a normal day..." --
<---- 		Fidelity Investments Co73D
X473D

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Nov 87 16:49:14 EST
From:      David Herron E-Mail Hack <david@ms.uky.edu>
To:        snorthc@NSWC-OAS.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, david@a.ms.uky.edu
Subject:   Re:  Ethernet Bridge
Well ... the only hole which I know by heart is the following
situation.  You have someone with a workstation and he has the root
password for his workstation.  He also has some local disk storage.  He
makes a setuid shell on his local disk.  Then he goes over to another
system and executes his shell, thus giving him root on that system.  In
our case we use equiv hosts to simplify a lot of things, but don't use
fully transitive equivalancies in a lot of cases.  The reason this is a
hole has to do with Unix using a simple integer to encode the user id
... If there were some sort of indication of the host that the user id
pertained to ...

Oh, in the particular situation, the user MUST have root access to his 
own workstation so that he can properly do his research.  Fortunately
he's a nice guy ... :-)

For a good time read section 2.2.2. of Suns NFS Protocol Specification.
It talks about the above bug and others.

As for using an IP gateway for security ... Well, consider me something
of a beginner in TCP/IP issues.  But I still have to manage the local
end of our net, and give advice to the people around me.  I understand
enough that the idea of a gateway knowing that a certain class of IP
numbers can only come from one side of the gateway makes sense.  But
this source routing stuff which someone mentioned is unfamiliar
territory to me.  I've been reading the discussion about source routing
and know that it apparently only applies to token ring.  However, it
seems that if there is to be support for source routing in the kernal,
then you could use it from any sort of network hardware.  Is the idea
with source routing to encapsulate an IP packet inside another one
which is addressed to a gateway machine, and the encapsulating packet
says where to send the encapsulated packet?

The use of IP gateways to wall off sections of the net to contain IP storms
makes sense ... We may set things up that way ... does anyone have any
recommendations on a good IP gateway?
--
<---- David Herron,  Local E-Mail Hack,  david@ms.uky.edu, david@ms.uky.csnet
<----                    {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- "The market doesn't drop hundreds of points on a normal day..." --
<---- 		Fidelity Investments Corporation
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 16:55:01 EST
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Multiple subnets on one physical net

MAIL FROM RAF  SATURDAY  10/31/87  8:21:02 P.M.

I guess that this may have been discussed before, but due to a
problem with our mailer here I wasn't getting much mail from this
list at the time.

Anyway, we recently acquired a class B network number for our
planned campus network and the issue arises about how to divide the
16-bit address space between subnet numbers and host numbers.  If we
make the subnet field small, we probably won't have enough subnet
numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each)
and a lot of address space is wasted on small subnets.  If we make
the subnet field large, we won't have enough host numbers for our
largest subnet (an 8 bit subnet field gives 254 networks of 254
nodes each).  This naturally leads to the question:  can multiple
subnet numbers be assigned to the same physical network?

Since we plan to use Proteon p4200 Gateways for at least some
things, I called Proteon and asked them.  They told me that there is
no problem, as each network interface can be assigned up to 16 IP
addresses, thus allowing it to respond to an IP address for each of
up to 16 subnets that reside on the same physical network.  I was
told that this was desirable because many hosts require that any
gateway that they use be on their own subnet.

Now I was recently shown a copy of a message from last July that
said that in such a situation, a Unix system would receive Ethernet
broadcast packets containing IP broadcast packets for other subnet
numbers, not realize that they were broadcast packets for another
subnet, and try to process (forward or redirect) them in some way.
More recently, I received a message on this list that said that a
Unix system would not try to perform gateway functions unless it had
more than one network interface, regardless of how its parameters
were set.

Anyway, what is the truth?  Can we assign multiple subnet numbers to
the same physical network or not?  What have others done about this
problem?

Roger Fajman
RAF@NIHCU.BITNET
National Institutes of Health

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Mon, 02 Nov 87  16:55:01 EST
From:      "Roger Fajman" <RAF%NIHCU.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Multiple subnets on one physical net
MAIL FROM RAF  SATURDAY  10/31/87  8:21:02 P.M.

I guess that this may have been discussed before, but due to a
problem with our mailer here I wasn't getting much mail from this
list at the time.

Anyway, we recently acquired a class B network number for our
planned campus network and the issue arises about how to divide the
16-bit address space between subnet numbers and host numbers.  If we
make the subnet field small, we probably won't have enough subnet
numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each)
and a lot of address space is wasted on small subnets.  If we make
the subnet field large, we won't have enough host numbers for our
largest subnet (an 8 bit subnet field gives 254 networks of 254
nodes each).  This naturally leads to the question:  can multiple
subnet numbers be assigned to the same physical network?

Since we plan to use Proteon p4200 Gateways for at least some
things, I called Proteon and asked them.  They told me that there is
no problem, as each network interface can be assigned up to 16 IP
addresses, thus allowing it to respond to an IP address for each of
up to 16 subnets that reside on the same physical network.  I was
told that this was desirable because many hosts require that any
gateway that they use be on their own subnet.

Now I was recently shown a copy of a message from last July that
said that in such a situation, a Unix system would receive Ethernet
broadcast packets containing IP broadcast packets for other subnet
numbers, not realize that they were broadcast packets for another
subnet, and try to process (forward or redirect) them in some way.
More recently, I received a message on this list that said that a
Unix system would not try to perform gateway functions unless it had
more than one network interface, regardless of how its parameters
were set.

Anyway, what is the truth?  Can we assign multiple subnet numbers to
the same physical network or not?  What have others done about this
problem?

Roger Fajman
RAF@NIHCU.BITNET
National Institutes of Health
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 16:55:58 EST
From:      rfox@amelia (Richard Fox)
To:        comp.protocols.tcp-ip
Subject:   Re: my subscription


Please add me to the distribution list please.

     rfox@ames-amelia

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 17:30:25 EST
From:      lekash@ORVILLE.NAS.NASA.GOV
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet - Hyperchannel Gateway

>From our experience, the actual sustained rate is 600/sec, assuming
no associated data and no contention on a dedicated trunk.  [Measured
between two Crays on a one meter coax trunk.]

Measured between two crays running what?  We measured 5mbits/second
effective data from silicon graphics workstations running unix to 
a cray2 running unix.  Using a 4096 associated data, and a little 
arithmetic, this is 1220 packets/second.  The cray2 has an A130,
the workstation an A400 hyperchannel adapter.  

17 mbit/sec was measured memory to memory on TCP on the same 
cray2, going out one adapter, and in another.  I will admit 
that this is thus a somewhat suspect number, but we don't have
a second cray2, yet.  

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 18:11:16 EST
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: ..."layering violations"

In article <8711010759.AA08856@okeeffe.Berkeley.EDU>, karels@OKEEFFE.BERKELEY.EDU (Mike Karels) writes:
> Two comments on your recent message.  First, about TCP behavior
> when ICMP unreachables are received: I definitely agree that TCP
> ought not to quit when it receives an unreachable.  However, in Unix
> and probably most other systems, it's hard to report "soft" errors
> to a network client.  In 4.3, I chose to return a single error
> on the next send or receive, but the TCP connection remains open.
> Unfortunately, most network applications carefully check for errors
> on each send/receive, and they give up on the first error.
> (4.2 aborted the connection when ICMP errors were received,
> and thus the application had no chance to keep trying.)

TCP doesn't return an error to the application when it retransmits, so
why should it do so when it receives a sporadic ICMP unreachable
message? I think a better approach would be for TCP to ignore these
messages, except to keep the last one or two around in case the
application specifically wanted to see them (e.g., by doing a special
ioctl on the socket).

> I also agree that you're right to distinguish between interactive
> network users and automatic daemons.  However, it's precisely for
> the daemons that are willing to wait patiently forever that "keep alive"
> messages are needed.  Although the telnet client will give up and close
> the connection manually, there needs to be a way to prevent systems
> from accumulating useless, disconnected telnet servers and other such
> trash.  Most application-level programs don't have their own keep-alive
> or are-you-there to detect network failure.  For those reasons, we use
> TCP-level keepalives (which are also not well provided-for at this level)
> only on network servers that don't have their own time-out scheme.

I strongly disagree that this should be done at the TCP level. I took
keepalives out of most of our systems some time ago. It's really nice
not to have to recreate a half dozen rlogin windows on my Sun each time
my SLIP link drops and has to be redialed.  It's also nice not to have
a steady stream of useless traffic on my amateur packet radio channel
when somebody logs in but remains idle for long periods.

The only way you accumulate useless, disconnected telnet servers is when
the client machines crash. If you *really* want to get rid of them, just
have a shell script do a write to anybody idle for more than X days --
the data will trigger a TCP Reset which will close the connection for
you. On the other hand, while they are aesthetically unpleasing, idle
sessions really don't hurt anything -- main memory is cheap and paging
memory even cheaper.

A year or two ago I thought as you do on keepalives, but a discussion
with Jon Postel turned me around. :-)

Phil

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 18:54:31 EST
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   details on misbehaving IP implementations

I've been asked to be less coy about mentioning misbehaving host
implementations by name. Fine. Herewith is a brief summary of what I see on
our own network after about 5 minutes of monitoring with a "bogon trap"
of my own design:

1. A bunch of Excelan hosts emitting rwho/UDP broadcasts with 128.96.0.0
(our local broadcast address) in *both* the IP source and destination
fields.

2. A Vax running 4.3BSD (or at least that's what the login banner says)
that returns an ICMP Unreachable Port to the sender of each RIP packet it
sees.

3. A Vax running MicroVMS V4.6 that's doing the same thing.

4. A big group of Symbolics LISP machines that return ICMP Unreachable
Protocol messages in response to IP broadcasts with a locally-defined protocol
field (255).

None of these machines are under my administrative control so I cannot
verify actual software version numbers, etc.

Phil

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2-Nov-87 19:28:22 EST
From:      AI.CLIVE@MCC.COM (Clive Dawson)
To:        comp.protocols.tcp-ip
Subject:   Re: Security and Access Restrictions


	If you have a serious interest in security then simply checking the
	IP addresses is not adequate because it is very easy to spoof IP
	addresses.

Is it really THAT easy to spoof IP addresses?  I agree that it's easy
for me to put a bogus IP address on an outbound packet.  But how do
I get the remote host to send packets back to me instead of to the
host I'm spoofing?   Perhaps an improvement to the described
security mechanism would be to match the various addresses appearing
in the packet (IP header, TCP or UDP header, etc.) to see if there
are disagreements.

Clive
-------

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Nov-87 08:25:56 EST
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Security and Access Restrictions


I am interested in learning about Visa.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Nov-87 11:46:22 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

I checked, and the specific model which does the fragmentation is the Bridge
GS/3.  The guy who has this problem told me that his gateway gurus had done
all they could to try to get this fixed, but that it hadn't been, at least the
last time he checked (~60 days ago).  He says they tell him the GS/7 fixes
these problems, and his site is apparently converting.  If your network
monitoring doesn't reveal any fragmentation of 552-byte IP length datagrams
(512 byte TCP segment + headers), then you must have gotten a fix, or else
your configuration is enough different that it doesn't happen.  Our code
did not handle IP reassembly before version 1.16.

James B. VanBokkelen
FTP Software Inc.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Nov-87 13:54:22 EST
From:      RTB@SEED.AMS.COM (Robert Baynes)
To:        comp.protocols.tcp-ip
Subject:   TRANSLAN III Questions


	AMS is an organization with two geographically separate
	offices, one in Providence, RI and one in Ann Arbor, MI.  We
	are in the process of upgrading the modems on the leased line
	between the two offices from 9.6 Kbaud to 19.2 Kbaud.  We are
	also considering installing at both sites a product from
	Vitalink called Translan III.  This would eliminate a
	multiplexor setup on both ends.
	
	At the Ann Arbor end, the Translan would be connected to an
	Ethernet on which Interlan NTS100 XNS terminal servers are
	primary hardware for connecting terminals.
				 
	At the Providence end, the Translan would be connected to an
	Ethernet on which NTS100s are wired to DECserver 100 and 200
	LAT terminal servers.  This would permit Ann Arbor users to
	connect to systems in the Providence office which support only
	LAT.
	
	With this configuration, only XNS terminal server traffic and
	occasional TCP/IP file transfer traffic would be transferred
	over the leased line between Providence and Ann Arbor (i.e.,
	no LAT traffic would need to be transferred).

	I would like to hear from anyone who is using a Translan III
	in a similar configuration.  I would especially like to hear
	from people who are using the product to pass terminal server
	traffic between Ethernets using a leased line.

	Thanks for any information.
	
	Bob Baynes 
	American Mathematical Society

	Internet: RTB@SEED.AMS.COM
		 (RTB@[192.16.180.3])

-------

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Nov-87 15:56:04 EST
From:      snorthc@NSWC-OAS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

James,
	Thank you for the follow up on the Bridge GS/3.  It does seem
that the GS/3 might be one of the weaker links in Bridge's Product suite.
If FTP software did not support reassembly of packets before 1.16
that helps to explain why we could not discern any difference between
its performance* and PCIPs (assuming any packets ever got fragmented).
I do seem to remember FTP v. 1.11 or 1.12's SMTP used to make the
GS/3s complain, 1.14 fixed that.
	While GS/3s on the whole (and at a time there were far less
alternatives available) seemed to work quite well, I do have one war
story.  We had a T1 link connecting two remote geographic sites with
a GS/3 at each end.  Whenever the T1 link went down (often in the boonies)
the GS/3s would go off into space and someone would have to press a
black button on the front of each GS/3.  However Bridge has long since
delivered a s/w upgrade and the morning ritual of resetting the GS-3 has
been retired.
	I wonder who makes the best gateway-in-a-box (this week).

		Stephen Northcutt (snorthc@nswc-g.arpa)

* we have never benchmarked TFTP and rarely use it, another reason we
may not have suffered too much.

Disclaimer: Only relationship between Bridge, FTP s/w and me is I try
to buy what they try to sell.

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Nov-87 17:02:30 EST
From:      jerry@oliveb.UUCP (Jerry Aguirre)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Can I print on a terminal server port

I would like to be able print from a 4.3BSD Unix system on a printer
connected to a TCP/IP terminal server.  With the increasing use of
terminal servers, some hosts being configured with no serial ports, this
seems like a common enough problem that someone might have already done
it.

Please send me mail if you have tried this.  I will summarize responses
to the net.

					Jerry Aguirre
					Systems Administration
					Olivetti ATC

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3-Nov-87 20:39:26 EST
From:      ejnorman@uwmacc.UUCP (Eric Norman)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

In article <7603@g.ms.uky.edu> david@ms.uky.edu (David Herron) asks:
> 
> What do people think about the security issues?  Right now, the
> concern is someone creating a situation where one of our equiv
> hosts is down, the bad-guy boots a machine that says he is
> the now-down machine and creates an suid shell on another of

Well let's see.  Suppose I have hosts Bossie and Elsie here that
trust each other and Bossie goes down and you're going to try to
make Elsie think you're Bossie from the other side of a LAN-100.
Now, what I'm gonna do is put a permanent entry in Elsie's ARP
cache with Bossie's IP number and ethernet address.  Well, I
reckon you can get a packet to Elsie that she'll think came from
Bossie, but I'd like to know how you're going to see the packets
coming from Elsie destined for Bossie.

Eric Norman
Internet:     ejnorman@unix2.macc.wisc.edu
UUCP:         ...{allegra,ihnp4,seismo}!uwvax!ejnorman
Life:         Detroit!Alexandria!Omaha!Indianapolis!Madison!Hyde
  
"Tis far easier for a peacock to show his true colors
 than it is for a lion to swallow his pride."
		-- Arte Johnson
--

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Nov-87 01:11:04 EST
From:      kermit@BRL.ARPA (Chuck Kennedy)
To:        comp.protocols.tcp-ip
Subject:   Wretched MIL/ARPA Gateway performance

This evening, network performance was somewhat less that "optimal".
The results are shown in the table below and represent the results
of running ping for at least 2 minutes to check out round-trip packet
delay and packet loss to various selected hosts.  All tests were run
from the host brl-vmb.arpa.

The first interesting finding is that performance on the Milnet is
quite good.  Even a cross-country connection from brl-vmb.arpa on the
East coast to nprdc.arpa on the West coast had 0% packet loss, an
average round-trip time of 348 ms and a maximum round-trip time of 1418
ms.  By comparison, a cross-country connection to ucbvax.berkeley.edu
exhibited a 61% packet loss, an average round-trip time of 9064 ms and a
maximum round-trip time of 22514 ms.

Why the large discrepancy between responses from these two hosts?
One possibility that looms is the Arpa-Milnet gateway.  Running
simultaneous pings to both sides of dcec-milnet-gw.arpa (BRL's default
Arpa-Milnet gateway) reveal large packet losses.  Admittedly, the
simultaneous pinging can influence the packet loss level.  However,
even non-simultaneous pings to the different addresses of the
gateway indicated large packet losses.

One other revealing test is a simultaneous ping to the Arpa side
of the gateway and to ucbvax.  Packet loss just to the gateway was 40%,
increasing to just 44% for packet loss to ucbvax.  Average round-trip
time to the gateway was 5743 ms while round-trip time to ucbvax was 7448
ms, almost 2 seconds longer.  This would seem to indicate that much of
the problem is in the gateway.  There is probably an additional problem
between the gateway and ucbvax since average round-trip time cross-country
via Milnet is only 348 ms.

Sample time: 2315-2340 on November 3, 1987
Ping was run for at least 2 minutes to gather the results below:

Internet #	hostname		min/avg/max		loss
----------	---------------------	-------------		----
26.2.0.29	aberdeen-mil-tac.arpa	33/348/6566		  1%

26.0.0.45	ardec-mil-tac.arpa	99/208/3614		  0%

26.0.0.50	amc-hq.arpa		114/148/748		  0%

Non-simultaneous
26.0.0.104	dcec-milnet-gw.arpa	6651/19174/32842	 76%
10.7.0.20	dcec-milnet-gw.arpa	518/4452/13966		 30%
26.0.0.104	dcec-milnet-gw.arpa	433/3408/14547		 41%

Simultaneous
26.0.0.104	dcec-milnet-gw.arpa	433/4020/15399		 36%
10.7.0.20	dcec-milnet-gw.arpa	599/4724/21784		 50%

26.3.0.3	nprdc.arpa		333/442/1418		  0%

10.2.0.78	ucbvax.berkeley.edu	1948/9064/22514		 61%

Simultaneous
10.7.0.20	dcec-milnet-gw.arpa	548/5743/24565		 40%
10.2.0.78	ucbvax.berkeley.edu	933/7448/22865		 44%

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Nov-87 10:23:53 EST
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Private/Public Ownership of Software

Early this summer, a comment was made in this forum concerning the ownership
of software.  As I recall the issue was raised concerning software developed
by Mitre for a governmental agency.  The gist of the statement was that the
software in question was not in the public domain as it had not been develop-
ed at the specific request of the agency but was developed to satisfy require-
ments established by the agency.  Can the author or anyone else provide me
a copy of the comment?  (I foolishly deleted the message after reading it
the first time not realizing that it might have more importance than the
disk space it was occupying.)

Merton Campbell Crockett                mcc@etn-wlv.eaton.com
AN/GYQ-21(V) Program
EATON Information Management Systems
31717 La Tienda Drive, Box 5009
Westlake Village, CA 91359

PS:  After scrolling through two (2) months of messages that accumulated
     while I was in Germany, I see we have yet to decide what the behav-
     ior of terminal should be.  Instead of TELNET appearing on the sub-
     ject line, we have SUPDUP or RTCE (?) appearing on the subject line.

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Nov-87 12:30:23 EST
From:      espo@bpa.BELL-ATL.COM (Bob Esposito)
To:        comp.protocols.tcp-ip
Subject:   SGMP


	Does anyone know where I can get info concerning SGMP (Simple
	Gateway Mgmt. Protocol)?  Anything would be helpful.

	Thanks in Advance,


-- 
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===
 Bob Esposito,  Bell of Pennsylvania - espo@bpa.bell-atl.com - (215) 466-6831
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Nov-87 12:45:49 EST
From:      minshall@OPAL.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Separation of Layers

Well, I've never been great on understanding which level is which.

However, a TCP address is the two-ple <IP address, TCP port number>.
This is the TCP address.  That is the way it is.  The nice thing here
is that the TCP address contains sufficient information to determine
the IP address (and, the bad thing here is that...).

Next, a TCP connection is defined by the two-ple <local TCP address,
remote TCP address>.  A TCP connection *cannot* be defined by the
two-ple <local TCP port, remote TCP port> - port numbers only have
significance when concatenated with an IP address (imagine telnet
clients on two machines trying to connect to the telnet server, port
23 or whatever, on one server machine).

If I understand the world of ISO correctly, *everything* has an
address (or is it a name?) which is (maybe) globally unique.
In that case what you are saying would make sense - ISO TCP
shouldn't care about the ISO IP source address some packet of
data came from.  However, DARPA TCP/IP is not built that way.
(It would, it is true, be nice if every host had exactly one "name";
then a TCP address could be <host "name", port number>.)

Greg Minshall

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Nov-87 15:10:23 EST
From:      steve@BRILLIG.UMD.EDU (Steve D. Miller)
To:        comp.protocols.tcp-ip
Subject:   Fetching host tables from the NIC


   For a few days now, I've had problems in reaching the NIC.  When I try to
fetch HOSTS.TXT, do a whois lookup, or just to telnet in, I sometimes get
TCP resets, and sometimes just get timeouts.  When I last telnetted to the
SMTP port on the NIC, though, it worked fine.  If it was just timeouts, I
wouldn't be so surprised, but it seems strange to me that the NIC would tell
me to go away when I try to reach certain well-known ports and not others.

   Is something funny going on out there?  I'd sure like to update my
host tables, for those last few machines who need to use it...

	-Steve

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Nov-87 17:07:28 EST
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   ARPANET PSN 7.0 BETA TEST SCHEDULE


                  ARPANET PSN 7.0 BETA TEST SCHEDULE


The following is the current schedule for the new End-to-End cutover for
all ARPANET nodes.  This schedule has been approved by DCA and DARPA.
It is requested that host administrators be aware of this test, but
not take action to reduce traffic load during testing.

All ARPANET nodes will be running PSN 7.0 on the following dates and
times:

        Date	         	     Time

7 NOV 87     			8:00-5:00 (EST)
14 NOV **thru** 15 NOV		8:00-5:00 (EST)
18 NOV				1:00-4:00 (EST)	

Hosts experiencing problems are asked to call the ARPANET Monitoring
Center at (617) 873-3571/3070 or (800) 492-4992.  Only by your
notification can we know that you are encountering problems.  Please
call.

There will be a follow-up meeting to discuss the status of the ARPANET
beta testing of the new End-to-End protocols on November 20, 10:30 am
at the Washington Building, Room 201, 7600 Old Springhouse Road,
McLean, VA. 
-------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Nov-87 19:31:27 EST
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Separation of Layers


Yes, it sounds like my interpretation won't work.  I really was not
trying to get TCP/IP to fit into the ISO model which I consider
malformed at best.  I have some Basic Rate and Primary Rate Interface
cards for various machines, and I want to run TCP/IP over them.  But I
want the option of establishing point to point serial links between
machines or X.31 connections to PSPDNs rather than just packet calls
to my PBX or local switch which seem to have either miserable or
non-existent packet handlers.  In this environment I want to
dynamically assign IP addresses to channels or groups of channels and
I want to tear down links over which there is no traffic because I
want to avoid phone bills which could be large in the case of
point-to-point rather than packet billing.  In such an environment I
could anticipate the physical link for an rlogin session going away
and then suddenly when there was activity over the TCP VC a new
physical link on perhaps a different interface might be established
which might end up with a new IP address. 

Alternatively if possible I would probably like to move calls off the
ISDN medium onto the ethernet medium if a dead network suddenly became
alive.  

But given that IP and TCP are apparently really only one layer it
can't be done.  

In any case the problem probably isn't too important since ISDN is too
slow to be useful for real networking.  Of course for multihomed hosts
the reliability issue might be important, but I guess it just can't be
done.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Nov-87 22:43:08 EST
From:      phil@amdcad.AMD.COM (Phil Ngai)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

In article <8711040945.AA17936@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes:
>We have a growing investment in
>Bridge Communications' IP routing products.  
>One such Bridge box that has served us well in the past is the GS-3.

Now that Bridge Communications has been purchased by 3Com, I look
forward to the day when we can refer to BCI's GS/3 IP routers as 3Com
boxes instead of "bridge boxes". 

-- 
I speak for myself, not the company.

Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4-Nov-87 23:27:32 EST
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Internet routing problems

Our gateway between bellcore-net and the ARPANET is
ipswitch.bellcore.com, a Sun 3/160 running Sun Unix 3.4 and Sun Link DDN
5.0. We're running Kirton's EGP as distributed by Sun.

Lately I've noticed some rather persistent routing connectivity problems
in the Internet. Many destinations fail to respond to packets sent from
hosts on bellcore-net (128.96) but are shown to be up when I initiate
connections from ipswitch. A given host can be unresponsive for days. I
know that ipswitch is sending the proper connectivity information to the
core because I can see bellcore-net in another ARPANET machine's routing
table.

I suspect the problem is related to the inability of many gateways to
handle ever-larger EGP updates. I noticed problems on ipswitch in that
entries for outside sites would appear in the routing table shortly
after booting, but after several minutes they would disappear leaving
only the entry for network 10.  Some sleuthing revealed that every
incoming EGP update had a checksum error. I increased the size of
MAXPACKETSIZE in defs.h from 1006 to 2048 and recompiled. The problem
has not recurred. I suspect that there are many other gateways out there
with the same problem; what can we do to get them fixed?

Phil

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 09:58:00 EST
From:      CLYNN@G.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: details on misbehaving IP implementations

Phil,
	I think that 2 and 3 (returning port unreachable) are not bugs but
are actually doing what the spec says they should.
	4 (returning protocol unreachable in response to broadcasts) is
probably not a good idea, but the specs were written before broadcast
were widely used.

Charlie

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 1987 09:58-EST
From:      CLYNN@G.BBN.COM
To:        faline!karn@BELLCORE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: details on misbehaving IP implementations
Phil,
	I think that 2 and 3 (returning port unreachable) are not bugs but
are actually doing what the spec says they should.
	4 (returning protocol unreachable in response to broadcasts) is
probably not a good idea, but the specs were written before broadcast
were widely used.

Charlie
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 Nov 87 14:34:46 -0500
From:      M C Srivas <srivas@UDEL.EDU>
To:        system@UDEL.EDU, acm@UDEL.EDU, f-troup@UDEL.EDU, arpanet-bboards@mc.lcs.mit.edu, big-lan@suvm.acs.syr.edu, ibm-nets%bitnic.BITNET@wiscvm.wisc.edu, info-nets@think.com, protocols@rutgers.edu, tcp-ip@sri-nic.arpa, telecom@xx.lcs.mit.edu
Subject:   Robert Lucky
Does anyone know where I could access papers published by Rob Lucky?
His papers will most probably deal with limitations, etc. of the various
optical networking technologies. Thanks.

Srivas.
______________________________________________________________________________

  	Network:
  		ARPA:	srivas@udel.edu
  		BITNET:	srivas@udel.edu
  		CSNET:	srivas%udel.edu@relay.cs.net
  		UUCP:	...!ihnp4!berkeley	-\
  			...!allegra!berkeley	-->!srivas@udel.edu
  			...!harvard		-/
______________________________________________________________________________ 
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 12:08:20 EST
From:      heker@JVNCA.CSC.ORG.UUCP
To:        comp.protocols.tcp-ip
Subject:   routing changes

We are experiencing a large number of routing changes in the kernel of one
of our VAX8600 "gateways".  The number of changes has increased dramatically
due to some route instabilities (that are not the topic of this message).

The question is how the number of changes can affect the performance of 
our system?.

We see about 1000 route changes in the kernel in periods of 10 minutes.  This
is as you can see *extremely* high.  But does this degrade the system 
performance at all?.

I also want to point out that this route changes are then propagated to 
other systems (VAX750s).  And all dance at the same rithm.

Any comments about this will be greately appreciated.

						-- Sergio

-----------------------------------------------------------------------------
Sergio Heker				tel:	(609) 520-2000
Internet: "heker@jvnca.csc.org"		Bitnet:	"heker@jvnc"
JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager
-----------------------------------------------------------------------------

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 87 07:37:27 GMT
From:      jbs@eddie.mit.edu  (Jeff Siegal)
To:        tcp-ip@sri-nic.arpa
Subject:   ARPANET<->MILNET problems
I've been trying to ftp some files from ECLA.USC.EDU (on MILNET) to
MIT (on ARPANET) and have had no success for the past week.  The Unix
ping program reports round-trip-times of 20-40 seconds and packet
loss rates varying between 70 and 100 percent.

Is there some current problem that is likely to be corrected, or
should we give up and resort to Federal Express and magtape?

Jeff Siegal
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 12:38:57 EST
From:      minshall@OPAL.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Separation of Layers


>...
> Alternatively if possible I would probably like to move calls off the
> ISDN medium onto the ethernet medium if a dead network suddenly became
> alive.  
> 
> But given that IP and TCP are apparently really only one layer it
> can't be done.  
> 
> In any case the problem probably isn't too important since ISDN is too
> slow to be useful for real networking.  Of course for multihomed hosts
> the reliability issue might be important, but I guess it just can't be
> done.

No, TCP and IP are not one layer.

Back in the days of experimental ethernets, there were only 8 bits of
addressing in the ethernet packets.  The way of mapping an IP address
to an ethernet address was to use the lower order 8 bits of the IP
address as the ethernet address (though actually what really happened
was that the ethernet address was assigned to the lower order 8 bits
of the IP address).

You wouldn't argue that the ethernet and IP were really one layer; however,
the mapping between IP address and ethernet address was merely that of
extracting - a projection.

On current ethernet, a projection from the 32-bit IP address space won't
work, since the map needs to be onto, and the ethernet address space
is 48 bits.  So, we have ARP.

A TCP address is composed of two parts: a 32-bit IP address, and an
8-bit port identifier.  To convert a TCP address into an IP address
is, again, a projection.

That this is so does not somehow merge the two layers into one.  They are
two layers.

(By the way, a machine is certainly free to send a packet on an interface
with address 128.32.13.4, and give it an IP source address of 10.0.3.4;
this is even justified if that machine has an interface with "address"
10.0.3.4 and that interface is down and there is an already existing
connection to a local port of 10.0.3.4.  However, you are correct in
assuming that in this situation, the connection partner will probably
not survive the fact that the 10.0.3.4 interface has gone down - unless
the sender uses IP source routing and the partner remembers the last
source route received on the connection.)

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 14:22:12 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  routing changes

Sergio,

I'm not sure what you mean by "routing changes." There certainly are vast
quantities of changes involving relatively small changes in delay and
even uncomfortable quantites involving significant (factor of two) changes.
Not many of these involve changes in route, however. While the situation
is serious and must be fixed, I don't think the routing overhead itself
is a significant factor in performance. Hellograms are rate-limited to
no more than one every 400 ms in even the worst case.

Let's hear it for all those gated's honking strange distances to the
fuzzies. Can someone answer the questions I put out about their behavior?

Dave

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 16:07:00 EST
From:      Petty@MIT-MULTICS.ARPA
To:        comp.protocols.tcp-ip
Subject:   ARP over FDDI

Hello

I am new to the network.  If this topic has already been addressed, I
aplologize in advance.

I am curious if anyone has thought about using ARP over an FDDI
network?  It seems like a match made in UCBerkeley.  The problem
as I see it, is that FDDI can have either 16 or 48 bit addresses.
If the gurus of FDDI who hand out the numbers would ensure that
the first 32 bits of a 48 bit hardware address were non-zero,
then life would be good.

Thanks in advance.

Jim Petty
Spartacus Inc.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 17:06:28 EST
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge


    Now, what I'm gonna do is put a permanent entry in Elsie's
    ARP cache with Bossie's IP number and ethernet address.

Well, first of all, the idea of loading up your host with
permanent ARP entries is pretty gross, and defeats the the
purpose of ARP anyway.

Second, and more important is that hardware ethernet addresses
aren't any more imutable that IP addresses anyway - I can easilly
change my hardware adrress to anything I want.  DECNet does this
sort of thing as a matter of course - setting the decnet host
numbers into the hardware address.  Thus having a permanant
ARP entry doesn't buy you much additional security anyway.

Bill Westfield
cisco Systems.
-------

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 18:50:29 EST
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Multiple subnets on one physical network

I guess that this may have been discussed before, but due to a
problem with our mailer here I wasn't getting much mail from this
list at the time.

Anyway, we recently acquired a class B network number for our
planned campus network and the issue arises about how to divide the
16-bit address space between subnet numbers and host numbers.  If we
make the subnet field small, we probably won't have enough subnet
numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each)
and a lot of address space is wasted on small subnets.  If we make
the subnet field large, we won't have enough host numbers for our
largest subnet (an 8 bit subnet field gives 254 networks of 254
nodes each).  This naturally leads to the question:  can multiple
subnet numbers be assigned to the same physical network?

Since we plan to use Proteon p4200 Gateways for at least some
things, I called Proteon and asked them.  They told me that there is
no problem, as each network interface can be assigned up to 16 IP
addresses, thus allowing it to respond to an IP address for each of
up to 16 subnets that reside on the same physical network.  I was
told that this was desirable because many hosts require that any
gateway that they use be on their own subnet.

Now I was recently shown a copy of a message from last July that
said that in such a situation, a Unix system would receive Ethernet
broadcast packets containing IP broadcast packets for other subnet
numbers, not realize that they were broadcast packets for another
subnet, and try to process (forward or redirect) them in some way.
More recently, I received a message on this list that said that a
Unix system would not try to perform gateway functions unless it had
more than one network interface, regardless of how its parameters
were set.

Anyway, what is the truth?  Can we assign multiple subnet numbers to
the same physical network or not?  What have others done about this
problem?

Roger Fajman
RAF@NIHCU.BITNET
National Institutes of Health

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 Nov 87  18:50:29 EST
From:      "Roger Fajman" <RAF%NIHCU.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Multiple subnets on one physical network
I guess that this may have been discussed before, but due to a
problem with our mailer here I wasn't getting much mail from this
list at the time.

Anyway, we recently acquired a class B network number for our
planned campus network and the issue arises about how to divide the
16-bit address space between subnet numbers and host numbers.  If we
make the subnet field small, we probably won't have enough subnet
numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each)
and a lot of address space is wasted on small subnets.  If we make
the subnet field large, we won't have enough host numbers for our
largest subnet (an 8 bit subnet field gives 254 networks of 254
nodes each).  This naturally leads to the question:  can multiple
subnet numbers be assigned to the same physical network?

Since we plan to use Proteon p4200 Gateways for at least some
things, I called Proteon and asked them.  They told me that there is
no problem, as each network interface can be assigned up to 16 IP
addresses, thus allowing it to respond to an IP address for each of
up to 16 subnets that reside on the same physical network.  I was
told that this was desirable because many hosts require that any
gateway that they use be on their own subnet.

Now I was recently shown a copy of a message from last July that
said that in such a situation, a Unix system would receive Ethernet
broadcast packets containing IP broadcast packets for other subnet
numbers, not realize that they were broadcast packets for another
subnet, and try to process (forward or redirect) them in some way.
More recently, I received a message on this list that said that a
Unix system would not try to perform gateway functions unless it had
more than one network interface, regardless of how its parameters
were set.

Anyway, what is the truth?  Can we assign multiple subnet numbers to
the same physical network or not?  What have others done about this
problem?

Roger Fajman
RAF@NIHCU.BITNET
National Institutes of Health
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 19:17:50 EST
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Telephone Access Controllers (TACs) and SLIP...

Is there any interest in a TAC like device capable of running SLIP
(Serial Line IP) on its terminal interfaces ?  As I currently
envision this, each serial line could be a logical host when acting
as an IP device, and just a normal port when acting as a terminal.
This might provide some performance improvement over things like
kermit for downloading/uploading files....

Bill Westfield
cisco Systems.
-------

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 19:26:59 EST
From:      satish@ACC-SB-UNIX.ARPA (Satish B. Joshi)
To:        comp.protocols.tcp-ip
Subject:   Ethernet/IP Testing/Monitoring Tools



	Does anyone know of any tools for monitoring and/or testing networks
in Ethernet, Unix-4.3BSD(VAX), and TCP/IP environment? I believe that some 
tools similar to SUN's "etherfind", and software to generate bogus IP 
datagrams were discussed here.

	I will appreciate any information about software to test protocols, 
specific interface boards or gateways, and to monitor Ethernets. Thanks.

Satish <satish@acc-sb-unix.arpa>
------

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Nov 87 22:10:12 EST
From:      fedor@nic.nyser.net (Mark Fedor)
To:        Mills@udel.edu, heker@jvnca.csc.org
Cc:        boyle@jvnca.csc.org, nsfnet@sh.cs.net, tcp-ip@sri-nic.arpa
Subject:   Re:  routing changes
>
>Date: Thu, 5 Nov 87 15:40:15 est
>From: Sergio Heker <heker@jvnca.csc.org>
>
>Dave,
>
>What I mean by routing changes, are actual routing changes in the kernel
>as per "gated".  The following list is only a sample for one particular
>network and over 10 minutes.  It illustrates metric changes and not
>route changes, but at some points, these metric changes, as observed from
>our bunker translate into counting to infinity from neighboring gateways
>(as we have observed for certain networks).  The problem is two fold,
>one is to determine how much this affects our systems, and second is to
>determine the cause for this unstable information.
>
>--------
>
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 11102, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 11778, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 12446, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1647, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1405, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1647  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 3615, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 2464, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 4242, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 7120, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 3512, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1647, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402  fromproto  HELLO
>CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1406, proto  HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402  fromproto  HELLO
>
>-------
>
>						-- Sergio
>
>
>-----------------------------------------------------------------------------
>Sergio Heker				tel:	(609) 520-2000
>Internet: "heker@jvnca.csc.org"		Bitnet:	"heker@jvnc"
>JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager
>-----------------------------------------------------------------------------
>
>>>

	Sergio,

	The excerpt from the log file shows no kernel route changes
	at all!

	The unix kernel only keeps info about the destination and
	gateway of a route (among other things), but not the metric.
	Notice that the gateway never changed so there was never a
	kernel change during the log above.  Gated keeps the metric
	and the metric change was made by gated.

	Now that this is out of the way, when this metric changing
	occurs, it of course takes up more system time cause gated
	is working harder.

	When the gateway changes like mad is when you get kernel route
	table thrashing.

	Mark

	P.S.  I don't know off hand why this is happening, although
		it is a midnet....


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 22:31:54 EST
From:      ORCHARD/BRUC@SCARECROW.WAISMAN.WISC.EDU (Bruce Orchard)
To:        comp.protocols.tcp-ip
Subject:   TCP maximum segment size determination

Consider a TCP connection passing through 3 networks: An Ethernet,
the ARPANET, and another Ethernet.  There are gateways between
each Ethernet and the ARPANET.  At connection time, each host must
choose a maximum segment size for the TCP segments it transmits.
The selection algorithm is generally to take the minimum of the
maximum size allowed by the receiver (given in the TCP maximum
segment size option), the maximum size allowed by the network the
host is connected to (in this case, an Ethernet), and the maximum
the transmitting host can handle.  Allowing integral multiples of
the local network maximum would be reasonable too.  All this has
to allow enough space for headers.

Now the maximum size allowed by an Ethernet is 1500 bytes, but the
maximum allowed by the ARPANET is 1007 bytes.  If a maximum
segment size greater than 1007 is picked by the transmitting end,
the gateway going into the ARPANET will fragment the message.  A
segment of 1500 bytes would get split into one of about 1000 bytes
and another of about 500 bytes.  One particularly poor choice I
have seen used is a maximum segment size of 1024 bytes.  Since the
1024 bytes excludes headers, this results in one fragment of 1007
bytes and another 77 bytes.

The real problem is that the transmitting end has no knowledge of
the limits of networks it is not connected to.  Therefore, I
propose adding a new option to the IP header.  This option would
give the minimum of the maximum transmission units of any network
that handled the packet.  The originating end would set it to a
large value.  Each node that transmitted the packet would compare
the value given in the option to the maximum transmission unit of
the outgoing network.  If the network value were less, the value
in the option would be reduced to the network value.

This IP header option would be used by TCP on the packet that
includes the TCP maximum segment size option.  The receiving TCP
would consider both the maximum allowed by its peer TCP (in the
TCP option) and the maximum allowed by any network along the way.
It would probably take the lessor of the two.

One limitation of this proposal is that all packets of a TCP
connection do not necessarily pass through the same networks.
Actually, given the way the networks are connected, all packets
usually go through the same networks.  Also, if one packet takes a
different route from an earlier packet, the second route could be
on the same kind of network (for example, two parallel Ethernets).
Regardless, the consequence of a poor choice is reduced
throughput, not failure.

Bruce Orchard
University of Wisconsin-Madison

P.S.  Is the MTU of SATNET really 256 bytes, as given in IEN 192?

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 22:32:05 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  routing changes

Sergio,

Ah yes, the infamous 192.31.x nets. These dudes have been bouncing all over t
the map for some time now. The distance values for these nets are not provided
by the fuzzballs, but by gated at some site or other. WHen they count to
infinity they have in fact become unreachable. This is a classic example
of what unstable metrics can do to a distributed Bellman-Ford algorithm. I
have been working feversihly to harden the algorithm so that even these wild
swings won't destabilize the algorithm, but when distances change from one
sample to the next by over fifty percent, what can any algorithm do? I repeat
my statement made at least a dozen times: where is the source of those violent
delay excursions and what gated is generating them?

Having said that, note that even these severe transients should not adversely
affect the system throughput, at least for the nets not rocking to and fro,
since the hello messages are rate-limited. On the other hand, traffic for
nets counting to infinity can clearly gobble up dangerous levels of traffic.
That's why I have been spending so much time trying to avoid the counting
problem. THe only way to do that is to latch sudden increases in delay
and prevent further decreases until the hold-down timer expires, which is
what the present system does. I have had to experiment somewhat in order to
gauge the sensitivity of the latch, which is presently set at a factor of
two. The latch regularily snares at least some of the surges, but not all, as
you can see from your data. I can't make the latch more sensitive without
snaring a lot of benign wobbles, such as occasional retransmissions on UIUC -
NCAR lines, for example. Nevertheless, I have tuned the algorithm a lot in the
past month and, at least in the testing swamps, it seems to be working well.

It has been suggested that JVNC has more trouble than most because that is
the only spot running gated on two machines on the same Ether. I thought
Maryland was doing that as well. While they seem to be having trouble of
their own, destabilized routes do not seem to be a serious problem there.
There are two things I would recommend (again): first, identify all those
gated configurations where only a single path is available to the networks
being squawked and set the squawked delay to zero, just plain zero. Second,
where multiple paths to a net exist, pray to the metric-translation god and
really, truly and verily conform to the rules I suggested in my earlier memo.
In any case, the clock-offset fields associated with each net in the hello
message should be set to zero and the date in the header should be marked
invalid. This seems like a pretty simple thing to check.

Dave

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 22:35:13 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  routing changes

Folks,

My apologies to the tcp-ip list for my recent reply to Sergio's message,
which must have seemed rather esoteric to most of you. I overlooked the
"tcp-ip" addressee in the return address list of the message. On the other
hand, if someone wants to start that game, I would be happy to play.

Dave

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 22:40:31 EST
From:      fedor@NIC.NYSER.NET (Mark Fedor)
To:        comp.protocols.tcp-ip
Subject:   Re:  routing changes

>Date:     Thu, 5 Nov 87 14:22:12 EST
>From: Mills@udel.edu
>Subject:  Re:  routing changes
>

	[ DELETED TEXT - MF ]

>Let's hear it for all those gated's honking strange distances to the
>fuzzies. Can someone answer the questions I put out about their behavior?
>
>Dave
>

	Dave,

	I must admit due to some traveling and moving, I have not
	read my mail too carefully.  As soon as I catch up and
	find the questions you put out, I will be glad to answer
	them.  Or you can send me a summary of your questions and
	I'll see what I can do.....

	Mark
	NYSERNet Inc.  (this is the last time I specify this!  Y'all
			should know I work there by now.)    :^)

	P.S.  can you elaborate "strange distances"?

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5-Nov-87 23:38:35 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  routing changes

Mark,

Yeah, I know who you work for now, but if I admitted that you might have
an excuse to wiggle off the hook. The hook seems to have already impaled
me, as you may have noticed.

Strange distances mean anything from 100 ms to somewhere in the middle of
Channel 4. Sergio's is a typical example. As for rounding up all the messages
I sent on the topic, gimme a break. There must be a hundred of them last
month alone. From reports by returning scouts to the INENG meeting, the
likely cause may be (a) incompatible gated versions and/or configurations,
(b) unstable ripspeakers behind gated or (c) metric conversion violations
when more than a single access path is available.

Dave

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Nov-87 02:20:54 EST
From:      hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   new Arpanet end to end protocol

I have just heard from a reliable source a fairly interesting fact
about the new end to end protocol implemented in PSN 7.0.  (Note that
my terminology is probably slightly off in this message.  I don't know
anything about the imp to host protocol, so I am almost certainly
introducing some distortion in passing on this information.)
Apparently one of the efficiency improvements in the new end to end
protocol is that the IMP's will no longer attempt to return a RFNM for
each packet.  You will be expected to look at the ID number included
in the RFNM's.  Any outstanding RFNM's with ID numbers lower than the
current one are also to be considered as acknowledged.  Many
implementations apparently simply count RFNM's.  They assume that one
acknowledgement is received per packet.  This will no longer be true
with the new end to end protocol, and so these implementations will
break.  I have some reason to think that most existing implementations
fall into this category.  Tests of the new end to end protocol are
scheduled for Nov 7, 14-15, and 18.  Implementors should be alert to
misbehaviors during these test periods.

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 87 05:18:57 GMT
From:      ihnp4!homxb!mtuxo!mtune!codas!ufcsv!beach!esj@ucbvax.Berkeley.EDU  (Eric S. Johnson)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ARPANET<->MILNET problems
In article <7353@eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal) writes:
>I've been trying to ftp some files from ECLA.USC.EDU (on MILNET) to
>MIT (on ARPANET) and have had no success for the past week.  The Unix
>ping program reports round-trip-times of 20-40 seconds and packet
>loss rates varying between 70 and 100 percent.
>
>Is there some current problem that is likely to be corrected, or
>should we give up and resort to Federal Express and magtape?
>
>Jeff Siegal

I have had a very similer problem making contact to a host inside
of the berkeley network. Same horrible round trip times and 
loss rates. It puzzles me because our contact with ucbarpa and
ucbvax (both arpa sites) is fine, but the contact with the site
inside the berk-net is rotten. 

I had a clear steady connection on Friday (10-30) in the mid morning.
But instead of making a large transfer then, I thought I would be a 
nice guy and wait till late that night. Sometime that day something
snaped and I haven't been able to make a decent connection since.

Perhaps related: I also have not been able to make contact with
univ. of Wisc hosts, yet have easy contact with cs.wisc.edu. 
(again directly on the arpanet)

As I understand it, some modifications are being made to the core
Arpa/Milnet routers (and maybe NSF). Does someone know if this is 
the cause of my problems, and when/if things will clear up again?


--
In Real Life:			UUCP: ...{ihnp4,rutgers}!codas!ufcsv!ufcsg!esj
Eric S. Johnson II              Internet: esj@beach.cis.ufl.edu
University of Florida           Ignore headers, reply only to above!
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Nov-87 10:31:44 EST
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: ..."layering violations"

Although you probably make a valuable distinction (given confirmation
that X.25 actually does have a "Host Down" return--I remember something
like Virtual Circuit Failure, or the like, myself), I was not, of course,
talking about X.25 explicitly.  (Nor was I talking about daemons explicitly.)
Always delighted to learn of still another X.25 faux pas, though.
(I'd confirm the Host Down question myself, but I don't have an X.25
spec handy, even though I acknowdlege that it's a seminal fascicle.)

Just so the principle doesn't get lost in the worrying over the example,
let me rephrase: Just as there's no need to close connections before
their time, there's no need to keep them open beyond their time.  Good
judgment is expected to be applied to the issue of what time it is
in the life of given connections in given contexts.  OK?

cheers, map

P.S.  Maybe it's a quibble, but wouldn't X.25 call it DTE Down, anyway?
(Or is it DCE?  Well, DxE, at least.)
-------

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Nov-87 12:27:19 EST
From:      jbvb@ftp.UUCP (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   ARCnet

Is there any standard for ARCnet encapsulation of IP?  Has anyone even done it?
Given things I have heard from ARCnet manufacturers, example hardware drivers
are available.

The process looks like:

1. Locate or develop a standard for IP encapsulation and address resolution.
I have been told that ARCnet has a 1-byte hardware address.  This would seem
to point at a convention like ProNET (map low byte of the hardware address to
the low byte of the IP address), instead of a permutation of ARP.

2. Obtain an example hardware driver and some hardware.  Starting with MIT's
P1300 driver, I would imagine that one could get on-line in a month or
less.  I would probably have already done this if I had time, or felt
sufficiently wizardly to promulgate an encapsulation scheme.

James B. VanBokkelen
FTP Software Inc.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Nov-87 14:45:07 EST
From:      SATZ@MATHOM.CISCO.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   EGP instability

Is anyone else having trouble maintaining their peer relationships
with the core? We are seeing excessive problems with high packet
loss and eventually being dropped.
-------

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Nov-87 15:02:51 EST
From:      jim@ektools.UUCP (James Hugh Moore)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP in the Public Domain?

------------------------------------------------------------------------------

What part of tcp-ip is in the public domain?  I understand that DARPA or
some related government agency specified what tcp-ip is.   


Does anyone have the reference to the government document, or an english
version of it?

Is there source code for tcp-ip on anything (especially an implementation
for arcnet would be nice) that is public domain?

Does anyone know of an existing implementation under arcnet or qnx?

If these questions seem kind rudimentary, I am a mathematician, and I am
posting for a friend, and he needs the answers.

I want to thank you in advance for all of your time and effort!!!

					     May God Bless You, in Jesus Name

					     Jim Moore

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
James H. Moore, 
Software Tools Group
Product Software Engineering Lab
Eastman Kodak Co.
Email:  allegra!rochester!kodak!ektools!jim
USMail: Dept 47, EP 5-2, Eastman Kodak Co., Rochester, NY 14650

Disclaimer: Opinions expressed are my own, and DO NOT represent the opinions
or policies etc of Eastman Kodak Co. as a whole.
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 87 11:43:58 GMT
From:      steinmetz!vdsvax!barnett@uunet.uu.net  (Bruce G Barnett)
To:        tcp-ip@sri-nic.arpa
Subject:   Is there an EGP that is available?
If we wanted to run EGP (External Gateway Protocol) on an Internet/mail
gateway for the purposes of dynamically finding routes to other
machines, where do we get this program?

Is the source available? 

I know that Sun sells it with their DDN SunLink product. 
What about Ultrix/4.3bsd?

What are the other protocols available - and what do people recommend?
Thanks,
-- 
	Bruce G. Barnett 	<barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>
				uunet!steinmetz!barnett
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Nov 87 16:56:57 EST
From:      MORAN <moran@vax1.acs.udel.edu>
To:        acm@UDEL.EDU, arpanet-bboards@mc.lcs.mit.edu, big-lan@suvm.acs.syr.edu, f-troup@UDEL.EDU, ibm-nets%bitnic.BITNET@wiscvm.wisc.edu, info-nets@think.com, protocols@rutgers.edu, srivas@UDEL.EDU, system@UDEL.EDU, tcp-ip@sri-nic.arpa, telecom@xx.lcs.mit.edu
Subject:   Re:  Robert Lucky
No.
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6-Nov-87 18:28:30 EST
From:      eugen@clan.UUCP (Eugen Bacic)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: TCP/IP source

I am also looking for the source for a complete PD TCP/IP implemention.  
I would appreciate any information anyone regarding their experiences
with Phil Karns implentation.

Eugen Bacic @ ..!utzoo!dciem!nrcaer!clan!eugen

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 03:17:23 EST
From:      schoff@NIC.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: Separation of Layers


    	I should point out that at MIT we no longer use network
    addresses as a form of authenticity. We now use our encryption based
    "Kerberos" authentication service. The code you wrote to use the
    subnet as a means of determining authentication has long since been
    retired.

Is there going to be an RFC on the authentication service???

Marty

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 12:06:17 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Slang Glossary

A fuzzball is a gateway, or IP router, (running on PDP11s, I think) which
Dave Mills authored.  They are common, because the software is in the
public domain, and they seem to have many desirable characteristics,
particularly for tinkerers.

A bogon is a particle (alias packet) that transmits bogosity.  I guess it is
also a happy accident that it rhymes with Vogon, because the bogus info is
frequently offensive and/or destructive.

Gong?  I dunno.

jbvb

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 12:15:37 EST
From:      wesommer@athena.mit.edu (William Sommerfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge (really: NFS "security")

In article <8711062349.AA04106@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes:
>OK, I'll bite.  We have been looking at NFS as a UNIX/VMS server solution
>for PCs.  From the begining of the investigation we were looking for
>things like the 'huge security holes'.  

Huge security holes is correct.  [I won't even talk about vulnerability
to malformed packets]

At least in the implementations that I have seen (the "portable NFS
release"), the NFS server daemon does not look at the client's IP address at
all; thus, it will permit access to anyone who can send you UDP
packets on port 2049.

There is a minor complication, which is that to do anything
meaningful, you need to know a "file handle" for a directory on one
filesystem.  Once you have the file handle, you can do anything you
want to the file system, because you can claim an arbitrary user-id in
the packet, and the server will trust you.

The idea that you have to be "root" on the client to do this is
incorrect.  It is possible to write a user-level program, using the
Sun RPC library, which talks directly to the NFS server of your choice
(I know.. it took me about a day to do this, working from the NFS
protocol spec).

Anyway, back to the weak spot.  You can get a file handle from the
mount daemon (/usr/etc/rpc.mountd).  It reads /etc/exports to find out
which hosts it can give out file handles to.  Unfortunately, in some
versions, it trusts the client to name itself (there is a hostname in
the request packet, filled in by the client).

In addition, it is possible to make up a valid file handle from whole
cloth.  In the current implementations, the file handle is the tuple
of {device_id, inode_number, generation_number}.  The device_id is the
UNIX major and minor device number of the device the partition is on.
The inode number is just a simple index into the inode table of the
filesystem (inode number 2 is the root of the partition, for
historical reasons), and the generation number is there to ensure that
if an inode is reused for a new file, the new file doesn't get
confused with the old.  These are initialized to all zero by the
standard (non-NFS) newfs.

There is a program, called "fsirand", which randomizes the generation
numbers of all the inodes on a partition.  It is important to run this
for _all_ partitions mounted on the server, not just the ones which
you want exported, because otherwise someone will be able to use the
{device_id, 2, 0} file handle, and get at the root of one of your
other filesystems.

Thus, the generation numbers become almost as critical as the root
password to the server.  Is any effort exerted to keep them secret?
No.  They fly around on the ethernet in the clear.  They can also be
extracted if you have access to read kernel memory (/dev/kmem or
/dev/mem) on the server (typically allowed on pre-4.3 BSD unix
systems).

There is light at the end of this tunnel, fortunately.

Here at Athena, we implemented a very small patch to NFS which gets
around this chain of security holes.  We modified the NFS server to
maintain a hash table which maps {client IP address, user_id} to
{local uid, group set}.  Map entries are controlled by a modified
rpc.mountd which uses the Kerberos authentication system to verify the
authenticity of the client.  Rather than trusting the client machine
to give the user id and group set of the user, the server instead
looks for a mapping in the hash table.  If no mapping is found, the
request is either remapped to uid -2, or rejected immediately,
depending on how the server is configured.  This has been in use for
about five or six months (and in heavy use since September), with very
few problems.

This is not as secure as Sun's experimental secure NFS system, which
includes an authenticator on each request, but our approach involves a
minimal performance overhead (when you use VAX 11/750's as servers,
you need all the help you can get...), and requires no modifications
to the client kernel, and also doesn't require any protocol changes to
NFS itself.

					Bill Sommerfeld
					wesommer@athena.mit.edu

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 12:15:57 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting: I'm not sure I understand

Subnetting is explained best in RFC950.  Most of what it is good for is
allowing you to divide one of the larger types of network (Class A or
Class B - 24 or 16 bits worth of host number) up into smaller administrative
or cable-oriented networks.  You are assumed to have IP routers (gateways)
between them to handle internal forwarding, but to the rest of the world,
you look monolithic (i.e. they send to net 128.127, and don't care that it
has 254 subnets, each of the form 128.127.xxx, because your gateways hide
that from the world).

You can use it on class C addresses, but with only 254 hosts, there is
less to divide.  Almost all subnetting implementations allow you to do
your division on bit boundaries, but there have been a few which could
only do it by bytes.

jbvb

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 12:33:35 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple subnets on one physical net

As usual, everyone was right, in the context.  Mike Karels described
the behaviour of his Unix, 4.3, which ought to work right in this
situation.  Other people have described *their* Unices, and other O/Ss,
like Phil's LISPMs, which are going to give trouble.

There are several problems you'll run into:  The first is that some 4.2-
derived systems believe in broadcast addresses of Net.0, and other systems
believe in Net.255.  The second is that some manufacturers leave their
Unices believing that they are IP routers, even when they have only one
network interface.  The third is that some manufacturers don't include
code to implement the law "don't reply to broadcast packets unless you're
*really* *sure* you ought to".  The fourth is that some manufacturers
don't understand about subnets.

The end result of this is that on one net I know, an Old-Broadcastian sends
an rwho packet, and 29 (or more - my monitor was only an XT) Sun and Vax
New-Broadcastians immediately attempt to either forward the packet (they
think they're gateways), or send an ICMP Net Unreachable (gateway-ism
partly disabled).  Great fun.  Also available between systems that do
and don't grok subnets, and the two together are greater than the sum
or the parts.  Phil Karn cited some misbehavers.  There are others.  All
can be fixed if you have source, most can be fixed through patience and
vigilance on the part of a network administrator (watching and making
people correct mis-configured systems).

jbvb

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Sat, 07 Nov 87 17:43:29 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Greg Satz <SATZ@MATHOM.CISCO.COM>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: EGP instability

     Is anyone else having trouble maintaining their peer relationships
     with the core? We are seeing excessive problems with high packet
     loss and eventually being dropped.

Greg, There is an arpanet/internet 'event' happening which shows up as long
queues in both directions between the PSNs and the core gateways.  Also, the
psn-gateway connection is broken frequently which causes all the queued
packets to be discarded.  Does your gateway on the arpanet get clogged also?
One change that may have affected the system is the introduction of fragmented
NR messages (EGP updates), which now take 2 arpanet messages each longer than
128 bytes; the fragments are about 1000 bytes and 200 bytes, and growing.

Some facets of the problem that are being explored are the differences between
the arpanet PSN software release 7 and the old release 6, speeding up the
processors in the core systems (upgrade lsi-11/23 to /73), and checking the
timing on the EGP implementations.

    Mike
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 17:13:32 EST
From:      hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Slang Glossary


  fuzzball - the name of a kind of IP router.  It is based on an LSI-11,
	and is used on the NSFnet backbone and various other critical places.
	The code is maintained by Dave Mills, and is often referred to by
	him as "fuzzware".
  swamp - a collection of networks.  The implication is that they overall
	architecture is somewhat dubious (e.g. connected by a mixture of
	level 2 and level 3 things, with several networks numbers on a 
	single cable).
  bogon - a bogus packet, often a packet that has escaped the net it is
	supposed to be on, e.g. a packet on the Arpanet addressed to
	127.0.0.1 (the Unix loopback interface address), however it is
	also used to refer to packets with other kinds of errors.
  Martian - properly speaking, a packet addressed to net 126.0.0.0,
	which is reserved for the Central University of Mars.  By extension,
	any packet addressed to an unallocated or reserved IP address,
	or to a broadcast address.  (These packets could also be called
	bogons, of course.)  A "Martian filter" is a pieces of code designed
	to discard Martians.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 17:46:28 EST
From:      jones@NGP.UTEXAS.EDU (William L. Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet - Hyperchannel Gateway

How much cray2 cpu was required to run the memory to memory TCP
test at 17 mbit/sec?

                                William L. Jones
                                University of Texas System CHPC

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 21:09:15 EST
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/DECnet interchange router for VMesS


    Date: 2 Nov 87 19:34:27 GMT
    From: unmvax!merlin!mcdermot@ucbvax.Berkeley.EDU  (John McDermott)

    I have a problem which I hope someone has already solved:  I have a
    TCP/IP net and a large DECnet net both served by a common VAX (vms).
    Some hosts on the decnet network also run tcp/ip.  All tcp is CMU/TEK for vms.
    Now the question: are there drivers to encapsulate ip packets, send them
    over the DECnet and then make them available for retransmission at the other
    end?  I need this because my VAX with Decnet is connected to the rest of
    the DECnet network by a 56kb line and that line cannot be used for both
    decnet and tcp/ip (for political reasons at least).  Any help would be really
    appreciated.

Well, you did say `any'.  Mike Parker at McGill University (address
musocs!mcgill-vision!mouse@eddie.mit.edu) wrote an IP over DECnet
device driver for UNIX 4.3BSD.  If you have any 4.3 hosts on your
subnet, you could make it the IP gateway to the other side of that
phone line.  I believe that is what they do at McGill and it seems
to work fairly well.  I heard about someone doing the same for VMS,
but I don't remember who (was it Lou Salkind at NYU?)

Hope this helps,

-Philip

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 21:23:00 EST
From:      slevy@UMN-REI-UC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

On IP & Ethernet address spoofing --

If there's no LAN bridge between you and the target, it's easy.
If there is, you may still be able to fool the bridge into passing
stuff onto your side.  If you want to look like host X (of IP address X.IP
and MAC-level address X.MAC), it may suffice to send out some packets
with MAC source address X.MAC.  When the bridge sees those, it may well
get confused about where X.MAC really is, and start routing X.MAC-destined
packets onto your part of the wire.  Presumably this depends on the bridge's
design, and I've never actually tried it, but it does sound plausible.

Another trick, not dependent on the bridge behavior, would be to send
an ICMP host redirect to the target, telling it to route traffic to X
via your own IP address (or some bogus one which you were willing to ARP for).
That should work even when X is up.  We're considering making our own
hosts ignore ICMP redirects for this reason, despite the loss of functionality.

We're also considering fixing our gateways in an unorthodox way --
to look at the IP -source- address of arriving packets.  If a packet arrives
from host Y, on an interface to which that gateway would never route packets
to Y, the gateway discards the packet.  If all the gateways in a system[*] act
this way, a spoofer can pretend to be someone else on the same net, but
not someone on another net.  So IP gateways can be made to be firewalls
in a way that MAC-layer bridges can't (unless the bridges get their routing
tables from the net administrator rather than learning by listening).
In this case the gateways, too, need to be careful about what ICMP redirects
they believe... perhaps by having an administrator-supplied list of GW's,
where redirects are believed only if they point to (not just come from!)
a legitimate GW.

[*]Well... the above sort of works.  I think it only really is reliable if
the structure of the "system" is a special one -- where all the gateways
and all the paths between them are trustworthy, and all the untrusted nets
are one GW away from the trusted backbone.  Redundancy is still possible,
and the backbone can have any structure, but rigid separation of
trusted from untrusted hosts & wires still is a pretty severe restriction.
Maybe this amounts to an argument for higher-level, end-to-end
authentication.


While I'm at this, how about NFS security.  I think the fake setuid hole
can be plugged: SUN's NFS at least has a "nosuid" mount option, and
you can just arrange to mount all non-system file systems with it.
Then only the server of system files needs to be secure.
However, a local superuser can get access to any non-root user's files
simply by setting his uid to the right thing.  So can any Joe with a PC
who goes to the trouble to write an NFS client, which can claim to be any
IP address, Ethernet address, and uid it wishes.  And as far as I know,
NFS (unlike TCP) won't even turn a hair if multiple clients on a net
claim to be the same machine -- each ignores responses to the others' requests.

SUN's RPC authentication scheme, which derives keys from user passwords,
distributes them with a public-key scheme, and uses DES to authenticate
transactions after the keys are established, seems promising in this regard.
(It was written up in a paper in Summer '86 Usenix, and was supposed to
be released with Sun 4.0 the last I heard, along with an NFS that optionally
uses it.)  One thing I worry about, though.  It appears secure enough
that people might be willing to allow root access across NFS.  But,
if anyone finds a hole allowing them to be root -without rebooting the machine-
they'll easily gain root access to everything sharing filesystems
with them -- a hole bigger than the present one.

					Stuart Levy, Minn. Supercomputer Center
					slevy@uf.msc.umn.edu, 612-626-0211

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 21:46:12 EST
From:      g-tasman@GUMBY.WISC.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ..."layering violations"


     You suggest that if a "host down" indication is received, a daemon
should immediately close the associated TCP connection.

     With an 1822 Distant Host connection to DDN, this may be a fairly
reasonable approach.  However, a typical DDN connection of late has been
X.25 or HDH.  Here, "host down" may have a more transitory meaning:  simply 
that there was noise on the host access line.  The remote host may well
reappear with all TCP connections intact.

     Consider in particular the case of a Telnet server.  If connections 
are cleared prematurely/incorrectly, extremely annoyed users will result.
On the other hand, I understand all too well the importance of eventually 
detecting and closing "half-open" connections which result from an actual
crash (since these will eventually inhibit new remote terminal sessions).

     The issue of distinguishing between a dead host and an "unhealthy"
host access line is likely to become increasingly serious over time, as more
DDN hosts switch to synchronous access protocols.  For a network client,
remote host status can simply be reported to the (human) user.  For a server,
however, I don't see a straightforward solution.


   						Mitchell Tasman
     

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7-Nov-87 23:58:39 EST
From:      Mills@UDEL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   INARC Workshop announcement

Folks,

This is a repeat of last month's announcement on a planned meeting of the
Internet Architecture Task Force. Please note the meeting dates have been
changed from the original 17-18 November to 17-18 December. The meeting place
is unchanged. Please note also the revised and clarified wording in the
announcement itself.

The Internet Architecture Task Force (INARC) studies technical issues in the
evolution of the Internet from its present architectural model to new models
appropriate for very large, very fast internets of the future. It is organized
as a recurring workshop where researchers, designers and implementors can
discuss novel ideas and experiences without limitation to the architecture and
engineering of the present Internet. The output of this effort represents
advance planning for a next-generation internet, as well as fresh insights
into the problems of the current one.

The INARC is planning a two-day retreat/workshop for 17-18 December at BBN to
discuss a fresh start on advanced internet concepts and issues. The agenda for
this meeting will be to explore architecture and engineering issues in the
design of a next-generation internet system. The format will consist of
invited presentations on selected topics followed by a general discussion on
related issues. Written contributions of suitable format and content will
be submitted for publication in the ACM Computer Communication Review.

In order to have the most stimulating discussion possible, the INARC is
expanding the list of invitees to include any researchers with agenda to
plow, axe to grind, sword to wield or any other useful instrument for that
matter. While not a precondition for admission, participants are encouraged to
contribute concise presentations, either written or oral (fifteen to thirty
minutes), in electronic form to mills@udel.edu or in hardcopy form to

Dr. David L. Mills
Electrical Engineering Department
University of Delaware
Newark, DE 19716
(302) 451-6534 or 737-9211

Speakers will be selected on the basis of quality, relevance and interest.
Every effort will be made to accomodate all participants that wish to attend;
however, participants are asked to contact the chairman by electronic mail or
telephone at least a week in advance to confirm their intention to attend.

Following is a list of possible areas and issues of interest
to the community. Readers are invited to submit additions, deletions and
amendments.

1. How should the next-generation internet be structured, as a network of
   internets, an internet of internets or both or neither? Do we need a
   hierarchy of internets? Can/must the present Internet become a component of
   this hierarchy?

2. What routing paradigms will be appropriate for the new internet? Will the
   use of thinly populated routing agents be preferred over pervasive routing
   data distribution? Can innovative object-oriented source routing mechanisms
   help in reducing the impact of huge, rapidly changing data bases?

3. Can we get a handle on the issues involved in policy-based routing? Can a
   set of standard route restrictions (socioecononic, technopolitic or
   bogonmetric) be developed at reasonable cost that fit an acceptable
   administrational framework (with help from the Autonomous Networks Task
   Force)? How can we rationalize these issues with network control and
   access-control issues?

4. How do we handle the expected profusion of routing data? Should it be
   hierarchical or flat? Should it be partitioned on the basis of use, service
   or administrative organization? Can it be made very dynamic, at least for
   some fraction of clients, to support mobile hosts? Can it be made very
   robust in the face of hackers, earthquakes and martians?

5. Should we make a new effort to erase intrinsic route-binding in the
   existing addressing mechanism of the Internet IP address and ISO NSAP
   address? Can we evolve extrinsic binding mechanisms that are fast enough,
   cheap enough and large enough to be useful on an internet basis?

6. Must constraints on the size and speed of the next-generation internet be
   imposed? What assumptions scale on the delay, bandwidth and cost of the
   network components (networks and gateways) and what assumptions do not?

7. What kind of techniques will be necessary to accellerate reliable transport
   service from present speeds in the low megabit range to speeds in the
   FDDI range (low hundreds of megabits)? Can present checksum, window and
   backward-correction (ARQ) schemes be evolved for this service, or should we
   shift emphasis to forward-correction (FEC) and streaming schemes.

8. What will the internet switch architecture be like? Where will the
   performance bottlenecks likely be? What constraints on physical, link
   and network-layer protocols will be advisable in order to support the
   fastest speeds? Is it possible to build a range of switches running
   from low-cost, low-performance to high-cost, high-performance?

9. What form should a comprehensive congestion-control mechanism take? Should
   it be based on explicit or implicit resource binding? Should it be global
   in scope? Should it operate on flows, volumes or some other traffic
   characteristic?

10. Do we understand the technical issues involved with service-oriented
   routing, such as schedule-to-deadline, multiple access/multiple
   destination, delay/throughput reservation and resource binding? How can
   these issues be coupled with effective congestion-control mechanisms?

11. What will be the relative importance of delay-based versus flow-based
   service specifications to the client population? How will this affect the
   architecture and design? Can the design be made flexible enough to provide
   a range of services at acceptable cost? If so, can the internet operation
   setpoint be varied, automatically or manually, to adapt to different
   regimes quickly and with acceptable thrashing?

12. What should the next-generation internet header look like? Should it have
   a variable-length format or fixed-length format? How should options,
   fragmentation and lifetime be structured? Should source routing or
   encapsulation be an intrinsic or derived feature of the architecture?

13. What advice can we give to other task forces on the impact of the
   next-generation internet in their areas of study? What research agenda,
   if any, should we propose to the various NSF, DARPA and other agencies?
   What advice can we give these agencies on the importance, level of effort
   and probablity of success of the agenda to their current missions?

Dave

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Nov-87 00:51:37 EST
From:      david@elroy.Jpl.Nasa.Gov (David Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge (really: NFS "security")

In article <1761@bloom-beacon.MIT.EDU>, wesommer@athena.mit.edu (William Sommerfeld) writes:
> In article <8711062349.AA04106@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes:
> >OK, I'll bite.  We have been looking at NFS as a UNIX/VMS server solution
> >for PCs.  From the begining of the investigation we were looking for
> >things like the 'huge security holes'.  
> 
> Huge security holes is correct.  [I won't even talk about vulnerability
> to malformed packets]
>  ...
 
> There is a minor complication, which is that to do anything
> meaningful, you need to know a "file handle" for a directory on one
> filesystem.  Once you have the file handle, you can do anything you
> want to the file system, because you can claim an arbitrary user-id in
> the packet, and the server will trust you.
> ...
[More discussion of the file handle contents]


It is very true that NFS is not very secure and it is doubtful that
it ever will be VERY secure.  As with most network protocols, someone
with a little patience and a packet monitor can figure out the protocol.
The best way to fight this is to have packet data that is not easy
to spoof or even figure out.  Using various encryption methods such as
public/private key or DES etc helps.  

Your point about the file handle points out a current weak spot that
does not have to exist.  The file handle is created on the server and
only it is required to know the contents.  The client just blindly
passes it back whenever it wants that file.  You have described quite
well the portable NFS file handle for Unix, but on machines such as
VMS this doesn't hold, it's file handle is completely different
and possibly somewhat strange.  The server does not have to use a simple
method such as placing the inode in the in the file handle, it could 
encrypt the inode number with DES first for example.

In general to make a protocol such as NFS truly portable and easy to
use you must make some sacrifices in security.  It is possible to
spoof RFS or DECNET but it is more difficult because the protocol
is much tighter.

But NFS has a lot of room to grow and I do forsee improvement.

	-David Robinson

-- 
	David Robinson		elroy!david@csvax.caltech.edu     ARPA
				david@elroy.jpl.nasa.gov
				ames!elroy!david UUCP
Disclaimer: No one listens to me anyway!

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Nov-87 07:58:52 EST
From:      yeongw@NISC.NYSER.NET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  SGMP

>	Does anyone know where I can get info concerning SGMP (Simple
>	Gateway Mgmt. Protocol)?  Anything would be helpful.
The RFC-to-be can be obtained by anonymous ftp from nisc.nyser.net
128.213.1.13 in pub/simple-mon.rfc. There is an sgmp mailing list,
simple-umon@nisc.nyser.net for sgmp developers.

Wengyik Yeong
yeongw@nisc.nyser.net
..!rutgers!nysernic!yeongw

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Nov-87 12:02:59 EST
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Security and Access Restrictions

CISCO and other IP gateways have access control lists that allow you
to restrict which packets can go to which hosts passing through a gateway.
We use this primarily to keep students on our public terminal servers off
the arpanet.

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Nov-87 12:12:14 EST
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/DECnet interchange router for VMesS

Wollongong makes such a thing (I believe they call it dbridge).
We used it for a while and although it worked just fine, it was
real slow for the IP traffic.  However, I talked to some people
more recently and they say that it is much improved.  We stopped
running it because we put a more sophisticated serial line in
place.

Your only other alternative is to use one of the routers that
does both IP and DECNET (Proteon, CISCO...) or something like
a level-2 serial bridge (UB Data Link Bridge, Vegalink TRANSLan).

-Ron

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Nov-87 12:15:15 EST
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: can pmdf be run over tcp-ip?

The P in PMDF stands not for phone but for PASCAL.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Nov-87 14:34:43 EST
From:      Mills@UDEL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Life after source quench

Folks,

Thanks to Hans-Werner Braun, who scrounged the log of the NCAR (National
Center for Atmospheric Research) fuzzball gateway on the NSFNET Backbone net,
we may have additional insight as to the effectiveness of its quench
mechanism and the implications for TCP implementations. The NCAR fuzzball is
seriously overloaded at times and, using the preemption and quench policies
described previously to this group, can be quite vocal about it. ICMP Source
Quench messages are sent when the mean queue length exceeds about 1.5 and at a
rate depending on the number of 256-octet blocks queued for a selected host.
Presently, only the host with the largest number of blocks is selected on the
assumption that quenchable flows do not occur very often and are almost always
due to a single host. See my previous messages for justification.

The following data illustrates typical scenarios found at NCAR. Each line
represents one quench message sent for traffic in the direction shown between
the two hosts. The two three-digit numbers are the ICMP type and code fields
(octal), where the code (second) field reveals the number of 256-octet blocks
queued at the time the quench was sent. (This interpretation of the code field
is at variance with the spec, but this is research, right?)

As expected, quenchable flows are relatively infrequent and are characterized
by large traffic surges lasting up to several minutes. For example, the code
field for the first line shows 120 (170 octa1) 256-octet segments sent by host
128.6.4.7 to host 128.102.16.10 living on a single output queue! In the first
surge the flow lasted about a minute during which six quenches were sent. It
is not cear from these data what the preemption policy was doing, but it is
likely that some quantity of packets were being dropped during this period.

HOST : 128.6.4.7 : RUTGERS.EDU,RUTGERS.RUTGERS.EDU,RUTGERS.ARPA : SUN-3/180
18:25:45 ?TRAP-I-ICMP 004 170 [128.6.4.7] -> [128.102.16.10]
18:25:46 ?TRAP-I-ICMP 004 135 [128.6.4.7] -> [128.102.16.10]
18:25:47 ?TRAP-I-ICMP 004 105 [128.6.4.7] -> [128.102.16.10]
18:26:38 ?TRAP-I-ICMP 004 127 [128.6.4.7] -> [128.102.16.10]
18:26:42 ?TRAP-I-ICMP 004 140 [128.6.4.7] -> [128.102.16.10]
18:26:44 ?TRAP-I-ICMP 004 135 [128.6.4.7] -> [128.102.16.10]

The next surge shows a seven-minute surge at the beginning and two shorter
surges at the end, with only sporadic quenches between.

HOST : 128.117.8.7 : (unlisted - who is this USAN dude?)
20:26:43 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
20:26:45 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2]
20:26:46 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2]
20:27:16 ?TRAP-I-ICMP 004 101 [128.117.8.7] -> [128.118.28.2]
20:27:28 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
20:27:30 ?TRAP-I-ICMP 004 151 [128.117.8.7] -> [128.118.28.2]
20:27:30 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
20:27:45 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2]
20:28:11 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.118.28.2]
20:28:12 ?TRAP-I-ICMP 004 142 [128.117.8.7] -> [128.118.28.2]
20:28:32 ?TRAP-I-ICMP 004 142 [128.117.8.7] -> [128.118.28.2]
20:28:33 ?TRAP-I-ICMP 004 110 [128.117.8.7] -> [128.118.28.2]
20:28:48 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
20:29:31 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
20:29:31 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2]
20:30:27 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.118.28.2]
20:30:47 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2]
20:31:23 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
20:31:24 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2]
20:31:36 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2]
20:31:37 ?TRAP-I-ICMP 004 151 [128.117.8.7] -> [128.118.28.2]
20:31:41 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2]
20:31:53 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
20:32:06 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2]
20:32:07 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
20:32:10 ?TRAP-I-ICMP 004 142 [128.117.8.7] -> [128.118.28.2]
20:32:27 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2]
20:32:33 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2]
20:32:34 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
20:32:35 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2]
20:32:56 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2]
20:32:58 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2]
20:33:15 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2]
20:48:14 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2]
20:54:21 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.118.28.2]
21:46:50 ?TRAP-I-ICMP 004 104 [128.117.8.7] -> [128.118.28.2]
21:46:51 ?TRAP-I-ICMP 004 104 [128.117.8.7] -> [128.112.18.2]
21:58:30 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.112.18.2]
21:58:37 ?TRAP-I-ICMP 004 110 [128.117.8.7] -> [128.112.18.2]
23:28:31 ?TRAP-I-ICMP 004 112 [128.117.8.7] -> [128.112.18.2]
23:28:35 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.112.18.2]
23:28:36 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.112.18.2]
23:28:37 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.112.18.2]
23:28:40 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.112.18.2]
23:28:43 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.112.18.2]

The next one is a real hotrod, with 17 quenches in 24 seconds.

HOST : 129.93.1.3 : (unlisted)
22:04:31 ?TRAP-I-ICMP 004 113 [129.93.1.3] -> [128.84.252.18]
22:04:35 ?TRAP-I-ICMP 004 110 [129.93.1.3] -> [128.84.252.18]
22:04:36 ?TRAP-I-ICMP 004 116 [129.93.1.3] -> [128.84.252.18]
22:04:36 ?TRAP-I-ICMP 004 127 [129.93.1.3] -> [128.84.252.18]
22:04:37 ?TRAP-I-ICMP 004 140 [129.93.1.3] -> [128.84.252.18]
22:04:37 ?TRAP-I-ICMP 004 151 [129.93.1.3] -> [128.84.252.18]
22:04:38 ?TRAP-I-ICMP 004 146 [129.93.1.3] -> [128.84.252.18]
22:04:38 ?TRAP-I-ICMP 004 132 [129.93.1.3] -> [128.84.252.18]
22:04:39 ?TRAP-I-ICMP 004 105 [129.93.1.3] -> [128.84.252.18]
22:04:51 ?TRAP-I-ICMP 004 113 [129.93.1.3] -> [128.84.252.18]
22:04:52 ?TRAP-I-ICMP 004 143 [129.93.1.3] -> [128.84.252.18]
22:04:52 ?TRAP-I-ICMP 004 165 [129.93.1.3] -> [128.84.252.18]
22:04:53 ?TRAP-I-ICMP 004 170 [129.93.1.3] -> [128.84.252.18]
22:04:53 ?TRAP-I-ICMP 004 157 [129.93.1.3] -> [128.84.252.18]
22:04:54 ?TRAP-I-ICMP 004 140 [129.93.1.3] -> [128.84.252.18]
22:04:54 ?TRAP-I-ICMP 004 127 [129.93.1.3] -> [128.84.252.18]
22:04:55 ?TRAP-I-ICMP 004 102 [129.93.1.3] -> [128.84.252.18]

I am told the Craymonsters do in fact something useful with ICMP Source Quench
messages. There is some evidence for that in the following, which shows a
surge lasting about a minute, but with the quenches mostly spread out at about
thirty-second intervals (except the last one), not in terrible spasms like the
above. If a Craymonster can be tamed with a quench every thirty seconds or so,
they may be pussycats, not monsters, after all.

HOST : 128.174.10.48 : NCSAD.ARPA : CRAY-X/MP :
22:15:30 ?TRAP-I-ICMP 004 102 [128.174.10.48] -> [128.84.252.18]
22:16:06 ?TRAP-I-ICMP 004 110 [128.174.10.48] -> [128.84.252.18]
22:16:36 ?TRAP-I-ICMP 004 110 [128.174.10.48] -> [128.84.252.18]
22:16:37 ?TRAP-I-ICMP 004 124 [128.174.10.48] -> [128.84.252.18]

The data suggest that a quench policy operating with a relatively long
integration time, such as the fuzzball policy and the policy suggested by Raj
Jain (the so-called DEC-bit) can indeed be effective. However, it is not at
all clear from the above data that the surges are due to a single TCP
connection, unless that connection was using window sizes in the 26000-octet
range. If multiple connections are involved, an effective quench strategy may
need to operate over several simultaneous and concurrent connections and
retain state over periods up to a minute or more. The operating system would
then have to restrain individual connections as a function of environment
variables independent of window modulation by the protocol itself. If it is
true that single connections with humungus windows are most prevalent, then
TCP window-drawdown strategies such as previously suggested would work
peachy-keen.

Comments from the host administrators of the above hosts would be welcome.
Can somebody describe the Craykitten anti-monster implementation?

Dave

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Nov-87 15:07:50 EST
From:      chris@ACC-SB-UNIX.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   distribution list

Can you please add me to the TCP-IP list. From what I've seen most correspondence is pertinent to what I've been doing at ACC.
			Thanks very much,
					  Chris VandenBerg
					  Applications Engineer
					  (chris@acc-sb-unix.arpa)

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Nov-87 17:00:41 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge


    ...
    Now, what I'm gonna do is put a permanent entry in Elsie's ARP
    cache with Bossie's IP number and ethernet address.  Well, I
    reckon you can get a packet to Elsie that she'll think came from
    Bossie, but I'd like to know how you're going to see the packets
    coming from Elsie destined for Bossie.

    Eric Norman

I haven't yet encountered an Ethernet interface that didn't allow you to
program its hardware address at initialization time.  DECnet relies on
this to get by without ARP.  With some software (ours, for instance), you
must patch (or use a PROM burner) to change the Ether address, but a lot of
other packages offer it as a configuration option, so don't count on a
pre-loaded ARP cache to protect security where hosts are "equivalent".

I'm not a big-time NFS hacker, but I've been told that in an environment
where users can re-boot (or power cycle) their workstations and bring them
up single-user, any file that is accessible by anyone over the network
should be assumed to be accessible by everyone.

James B. VanBokkelen
FTP Software Inc.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sun, 8-Nov-87 21:29:38 EST
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: ARPANET<->MILNET problems


    Date: 5 Nov 87 07:37:27 GMT
    From: jbs@eddie.mit.edu  (Jeff Siegal)

    I've been trying to ftp some files from ECLA.USC.EDU (on MILNET) to
    MIT (on ARPANET) and have had no success for the past week.  The Unix
    ping program reports round-trip-times of 20-40 seconds and packet
    loss rates varying between 70 and 100 percent.

    Is there some current problem that is likely to be corrected, or
    should we give up and resort to Federal Express and magtape?

    Jeff Siegal

I have been having similar problems to Jeff's.  I have been trying to
reach a couple of hosts at CMU, with little success.  FTPs and TELNETs
timeout before the connection is established.  None of my pings have
gotten through.  On the few occasions (2 or 3 times in many hours) that
my FTPs did connect, logging in took about 2 minutes, and getting a 14k
file took more than 40 minutes, sometimes not even finishing...

Reaching the NIC has not been a problem, though.  Is this a side
effect of 7.1 or isolated problems?  I haven't been able to reach
the NOC, but will call them Monday...

-Philip

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 00:11:26 EST
From:      lyndon@ncc.UUCP (Lyndon Nerenberg)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Microport TCP recommendations

We have a 286/AT clone running Microport System V/AT and
MSDOS 3.2.  We're looking for a TCP/IP implementation to
run under both OS's (preferably from the same vendor).

The DOS side requires telnet and ftp. Under UNIX, we require
telnet, ftp, rlogin, and something that runs SMTP and can
talk to sendmail (native sendmail would be nice). The UNIX
implementation must also support NFS.

The environment consists of the AT, a Sun 3/280, and a mixture
of Convergent hardware running on a thicknet.

If you're running such a setup, please drop me a line describing
your configuration.

Thanks all,

Lyndon Nerenberg
Nexus Computing Inc.
{alberta,pyramid,uwvax}!ncc!lyndon  ||  lyndon%ncc.uucp@spool.wisc.edu

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 01:05:18 EST
From:      david@elroy.Jpl.Nasa.Gov (David Robinson)
To:        comp.protocols.tcp-ip
Subject:   Ethernet versions

As most people know their are a couple ethernet standards, Version 1,
Version 2 and IEEE 803.2.  When one installs a new ethernet board
they must have the correct transeiver level to match the type that
the board supports, fortunately a lot of modern boards have
jumpers to support different versions.  I have found that you can
run both level 1 and level 2 transeivers on the same cable.

The question:  What is the difference between the versions and what
effect is their on the physical wire to run two different types
of transeivers?  I have heard people say that it is best to have all
the same type but no "real" evidence to base that comment on.

Could someone mail me either a description of the differences or
pointers to the available documentation that would answer these questions.

As always if their is enough interest I will summarize to the net.

-- 
	David Robinson		elroy!david@csvax.caltech.edu     ARPA
				david@elroy.jpl.nasa.gov
				ames!elroy!david UUCP
Disclaimer: No one listens to me anyway!

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 01:28:57 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP Slang Glossary

Wire,

You have a wonderful treat in store for you. Don't worry about the slang,
since after all it changes warp and woof as the seasons do go by. After
a few months of delicious indifference it will all come clear to you in a
flash: bogons are alien invaders, gong is the stuff outhouses sit on and
fuzzballs are what dry-cleaning establishments remove for a living. Do
I lie? Ask anybody.

Dave

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 87 09:06:00 PST
From:      "Jerry Scott" <jerry@twg.arpa>
To:        "mcdermott%atavax.decnet" <mcdermott%atavax.decnet@afwl-vax.arpa>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   RE: TCP/DECnet interchange router for VMS
Van Jacobson and Craig Leres implemented a IP over DECNET interface
a few years back.  Basically it allows IP to use DECNET as though it
were a hardware interface.  Wollongong and SRI both support this
software in their standard products under the product name DBRIDGE.

Jerry Scott
------
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 06:37:57 EST
From:      krol@UXC.CSO.UIUC.EDU (Ed Krol)
To:        comp.protocols.tcp-ip
Subject:   Life after source quench


The following is an excerpt from a paper by Charlie Kline 
(kline@uxc.cso.uiuc.edu) given at this summers Sigcom in Stowe describing
the Cray CTSS source quenched algorithm which Dave seems impressed
by:

  CTSS TCP/IP treats quenches as IP events rather than TCP events. Berkeley
  responds to quenches by reducing the size of the TCP window. We respond, as
  suggested by Postel in a draft RFC, by introducing a delay between the
  sending of IP packets to the host which is producing the quenches. The delay
  increases linearly as more quenches are received. If no quenches are
  received in a certain interval, the interval is decreased exponentially.

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 08:47:31 EST
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Internet performance

A note regarding Internet and ARPANET performance:

Many users have noted a degradation in Internet and ARPANET
performance over the past few weeks, especially in end-to-end
round-trip delay.  There've been a few messages to tcp-ip about
it, especially over the past week.

BBN has been investigating the situation; while we have a pretty
good handle on what's been happening, we don't yet fully
understand why.

The problem seems to center around the three ARPANET EGP Server
gateways.  The amount of ARPANET traffic destined for these
gateways has increased dramatically in recent weeks.  Moreover,
they seem to be slower in processing incoming traffic.  This has
led to severe but highly localized congestion in the ARPANET.
ARPANET round-trip delays to these gateways have skyrocketed;
some gateways may not be able to maintain their EGP "connections"
with the servers, resulting in Internet connectivity problems.

Current speculation is that this is all related to the recent
increase in the size of EGP routing updates such that these must
now be fragmented by the servers into two ARPANET messages --
i.e., EGP routing update traffic in the ARPANET has effectively
doubled. 

It's also possible that there's some tie-in between this problem
and the ARPANET PSN 7 upgrade.  There's no evidence that points
in this direction, but on the other hand we have not yet ruled it
out.

On a more general note, it's also worth pointing out that in
recent months, traffic on the ARPANET has grown at annualized
rate of 50%, and this growth shows no signs of letting up.
ARPANET and Internet capacity and performance is going to
continue to be an issue in the future.

Ken Pogran
BBN Communications

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Nov 87 08:47:31 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        pogran@ccq.bbn.com
Subject:   Internet performance
A note regarding Internet and ARPANET performance:

Many users have noted a degradation in Internet and ARPANET
performance over the past few weeks, especially in end-to-end
round-trip delay.  There've been a few messages to tcp-ip about
it, especially over the past week.

BBN has been investigating the situation; while we have a pretty
good handle on what's been happening, we don't yet fully
understand why.

The problem seems to center around the three ARPANET EGP Server
gateways.  The amount of ARPANET traffic destined for these
gateways has increased dramatically in recent weeks.  Moreover,
they seem to be slower in processing incoming traffic.  This has
led to severe but highly localized congestion in the ARPANET.
ARPANET round-trip delays to these gateways have skyrocketed;
some gateways may not be able to maintain their EGP "connections"
with the servers, resulting in Internet connectivity problems.

Current speculation is that this is all related to the recent
increase in the size of EGP routing updates such that these must
now be fragmented by the servers into two ARPANET messages --
i.e., EGP routing update traffic in the ARPANET has effectively
doubled. 

It's also possible that there's some tie-in between this problem
and the ARPANET PSN 7 upgrade.  There's no evidence that points
in this direction, but on the other hand we have not yet ruled it
out.

On a more general note, it's also worth pointing out that in
recent months, traffic on the ARPANET has grown at annualized
rate of 50%, and this growth shows no signs of letting up.
ARPANET and Internet capacity and performance is going to
continue to be an issue in the future.

Ken Pogran
BBN Communications
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 11:21:41 EST
From:      tron@mrecvax.UUCP (Carlos Mendioroz)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.wizards
Subject:   ICMP redirect messages. How to send ?


  Hi!

  We have just installed a second ethernet interface on a uVax II running
ULTRIX 1.2m and we would like to use it as a gateway between them.

  So far, so good. The problem is that the rest of the machines on both
nets don't support the route protocol (/etc/routed) but they understand
ICMP redirect messages, so the solution would be that the uVax sends
such messages for the machines to update their route tables.

  Has anybody done such a thing ? Is there any program that uses the raw
socket interface from where I can start doing it ?

Thanks in advance.

-Carlos Mendioroz <tron@mrecvax.UUCP>
  UUCP: {uunet|pyramid|utai}!atina!mrecvax!tron
  

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 12:06:00 EST
From:      jerry@TWG.ARPA ("Jerry Scott")
To:        comp.protocols.tcp-ip
Subject:   RE: TCP/DECnet interchange router for VMS

Van Jacobson and Craig Leres implemented a IP over DECNET interface
a few years back.  Basically it allows IP to use DECNET as though it
were a hardware interface.  Wollongong and SRI both support this
software in their standard products under the product name DBRIDGE.

Jerry Scott
------

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 12:58:11 EST
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   SGMP


SGMP = Simple Gateway Mgmt Protocol = RFC-1028

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 13:08:26 EST
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

We have GS/3's, and I've never seen them exhibit this problem.

I just ran an Ethernet trace to make sure.  A pair of GS/3s
running software version 11000 (connected by a 56Kb line, though that
shouldn't matter) just passed a 1064-byte IP packet without fragmenting
(or if it was fragmented over the line, the receiver reasssembled it
before sending it on the Ethernet).

The older software, version 10000, did have a different problem with
IP fragmentation.  It didn't -cause- any packets to be fragmented.
However, if the original sender had already fragmented an IP message,
the GS/3 would only -transmit- the first fragment.  They made us a patched
version of the software (called 10019, I think) to evade this problem.
I don't think the current 11000 release does anything wrong in this regard.

					Stuart Levy, slevy@uf.msc.umn.edu
					Minn. Supercomputer Center, 612 626 0211

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 13:11:02 EST
From:      kline@uxc.cso.uiuc.EDU (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Re: Life after source quench

Gosh Professor Mills, you guys all yelled at me so much when I
mentioned that d.ncsa.uiuc.edu didn't respond to quenches that I
thought I'd better do it right. Do I get an A on my project?

As Ed pointed out, the method that our "Craykitten" uses in response to
a source quench is simply to shackle all packets in the IP output queue
destined for the originator of the quench (I mean the ip_dst of the
packet returned in the quench) such that there is a delay of X
milliseconds before each is transmitted. X is initially zero, and the
current parameter is to increase it by 500 milliseconds for each quench
received. If no quenches are received for 30 seconds, X is halved. An X
lower than 500 causes the quench reaction to stop. This all happens in
the IP module, and TCP is unaware of the quenches.

I'm sure that the reason that the fuzzball is issuing quenches every
thirty seconds is because if only one quench is sent, IP throttles back
to one packet every 500 milliseconds (which should keep the fuzzball
happy), but when the 30 second quench reaction stops, IP starts
vomiting the packets full blast again, which causes another quench. I'm
pleased that the quench mechanism creates such effective data rate
communication between an IP module and IP gateways.

I can't take credit for the method, it's an implementation of Postel's
proposal. I only messed with the parameters.

-----
Charley Kline
University of Illinois Computing Services
kline@uxc.cso.uiuc.edu
kline@uiucvmd.bitnet
{ihnp4,uunet,pur-ee,convex}!uiucuxc!kline

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 13:27:09 EST
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple subnets on one physical net

It is important for the general health of an complex IP network to
keep hosts that are not supposed to be functioning as routers (gateways)
from forwarding packets at all.   This more than anything else has
caused more problems, e.g.:

	Host receives broadcast packet with wrong type broadcast
	IP address and tries to ARP for it, sending host into
	tight loop (Old Wollongong VMS TCP/IP).

	Host receives packet for some host other than itself, tries
	to send an ICMP error packet and generates bogus ARP field
	causing other hosts to think that it was the host that sent
	the packet (Ungerman Bass TCP).

-Ron

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 13:29:03 EST
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Can I print on a terminal server port

Roy Marantz here at Rutgers is working on this for lpd.  The printcap
has a terminal server name/ TCP port number entry for these printers.
There is currently still some bug that prevents this from working.

-Ron

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 13:47:07 EST
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Bridge

OK, since you've never heard anybody malign Bridge, I'll volunteer.
Bridge makes nice reliable boxes, but they don't always get the protocls
right.  Their terminal servers are classic examples.  They don't answer
pings, they botch the Telnet options, etc.

_Ron

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 14:10:28 EST
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Fetching host tables from the NIC

You ought to use the domain system rather than host tables,
but since you are on MILNET you can ftp or use the port 101
server to pull the NIC host table off BRL-AOS.  It is available
in the file <NETINFO>HOSTS.TXT

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 09 Nov 87 18:14:30 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        "Phil R. Karn" <faline!karn@BELLCORE.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: Internet routing problems
Phil,

I recommend that you get on the EGP-PEOPLE mailing list.  Send request to
'egp-people-request@bbn.com'.  Your problem first had a fix announced there a
year ago February (that's 1986).

I would have restricted this note to a private answer, but I want to suggest
that anyone else reading TCP-IP and operating an EGP gateway get on the
EGP-PEOPLE list also.

    Mike
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 16:48:20 EST
From:      timg@devvax.JPL.NASA.GOV (Tim Graham)
To:        comp.protocols.tcp-ip
Subject:   guaranteed datagram protocols


I have a query concerning the existence of tested and reliable guaranteed
datagram protocols.  By this I mean protocols which would sit "above"
the UDP protocol in the TCP/UDP/IP suite, but which would guarantee ordered
and reliable delivery of messages.  I suppose that such a protocol would
have to do appropriate sequencing and retransmitting to accomplish this.

The problem which motivates this request is a desire to maintain 
"many-to-one" connections while guaranteeing that any segments sent will
be received at the remote end, and that they will be received in the
order in which they were sent.

Any information concerning products which even remotely resemble this
description would be greatly appreciated.

Thanks in advance for any information you may have.
-- 
Tim Graham       Jet Propulsion Laboratory/California Institute of Technology
-----------------------------------------------------------------------------
4800 Oak Grove Drive  Pasadena, CA. 91109  MS: 301-260A        (818) 354-1448 
UUCP: ...cit-vax!elroy!jpl-devvax!timg            ARPA: elroy!timg@jpl-devvax

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 17:57:00 EST
From:      Kastenholz@MIT-MULTICS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: ARP on FDDI

Jim,

There is a rather simplistic solution to the 16 vs 48 bit FDDI address
problem - assign two physical hardware types to FDDI - one for 16 bit
addresses and one for 48 bit addresses.

This may violate some underlying deep philosophical intent of ARP, but
it looks like it should work.

Frank Kastenholz

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 17:57:34 EST
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   ARPANET/Internet performance investigation

BBN has been investigating recent ARPANET and Internet
performance problems.  Here's a brief report.

The biggest single problem has been the performance of key LSI-11
gateways, especially the three "EGP Server" Gateways on the
ARPANET located at BBN, Purdue, and ISI.  These gateways are
LSI-11/23s, and they are flat out of cycles.  As the Internet has
grown, they have been spending more and more of their time
preparing EGP routing updates, at the expense of other
activities, such as servicing their I/O queues.  One result of
this has been the buildup of long queues of messages for these
gateways in the PSNs to which they are attached.  Frequently,
messages have remained on the queues for more than 30 seconds --
which causes the PSN to declare the gateway "tardy" and reset its
interface to that gateway, thereby flushing the queue (returning
"Incomplete Transmission" messages to the originators) and
starting the process over again.

The short-term fix for this problem is to replace the processors
in these gateways with the faster LSI-11/73s.  This was done at
BBN last Friday, with excellent results.  BRL and U-Maryland have
generously offered the loan of 11/73 processors which will be
installed in the ARPANET EGP servers at Purdue and ISI.  With
these faster processors installed, the Internet should be back to
"normal" -- for another 2-6 months, given the current rate of
growth.

The long-term fix is the installation of Butterfly Gateways to
replace the LSI-11s that are the DDN Mailbridge Gateways.  This
will enable us to retire the LSI-11 EGP servers.  The Butterfly
Mailbridges will provide significantly better performance.
Deployment of the Butterfly Mailbridges in the DDN is expected in
the April timeframe.

Ken Pogran
BBN Communications

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Nov 87 17:57:34 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        pogran@ccq.bbn.com
Subject:   ARPANET/Internet performance investigation
BBN has been investigating recent ARPANET and Internet
performance problems.  Here's a brief report.

The biggest single problem has been the performance of key LSI-11
gateways, especially the three "EGP Server" Gateways on the
ARPANET located at BBN, Purdue, and ISI.  These gateways are
LSI-11/23s, and they are flat out of cycles.  As the Internet has
grown, they have been spending more and more of their time
preparing EGP routing updates, at the expense of other
activities, such as servicing their I/O queues.  One result of
this has been the buildup of long queues of messages for these
gateways in the PSNs to which they are attached.  Frequently,
messages have remained on the queues for more than 30 seconds --
which causes the PSN to declare the gateway "tardy" and reset its
interface to that gateway, thereby flushing the queue (returning
"Incomplete Transmission" messages to the originators) and
starting the process over again.

The short-term fix for this problem is to replace the processors
in these gateways with the faster LSI-11/73s.  This was done at
BBN last Friday, with excellent results.  BRL and U-Maryland have
generously offered the loan of 11/73 processors which will be
installed in the ARPANET EGP servers at Purdue and ISI.  With
these faster processors installed, the Internet should be back to
"normal" -- for another 2-6 months, given the current rate of
growth.

The long-term fix is the installation of Butterfly Gateways to
replace the LSI-11s that are the DDN Mailbridge Gateways.  This
will enable us to retire the LSI-11 EGP servers.  The Butterfly
Mailbridges will provide significantly better performance.
Deployment of the Butterfly Mailbridges in the DDN is expected in
the April timeframe.

Ken Pogran
BBN Communications
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 22:06:56 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Life after source quench

Ed,

Thanks for the info; however, to fully evaluate the Cray response I would need
to know the parameters of the algorithm: what is the delay, the increment and
the weighting constant for the decrease? How long does it wait for decrease?
In order to set these properaly, it would be helpful for the Cray to know
something about the overall path, such as path delay, estimated flow rate,
packet loss rate, etc. At least on countermotivation for effecting the
quench policy at the IP level is that this information is hard to come by.

Dave

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9-Nov-87 22:41:28 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Life after source quench

Charley,

Gee, you didn't say how mungus the packet is - 65K give/take fragments?
An incremental delay of 500 ms is probably okay for the 56-Kbps Backbone
or ARPANET, but certainly not for the ARPANET/MILNET gateways. To do it
right, you should know something more about the path, such as overall
delay, estimated flow rates and loss rates. TCP of course could give
that to you, assuming TCP were involved. I doubt UDP or raw IP would
generate the observed horsepower; on the other hand, a Craycreature
may well be needed to supply the watts for tomorrow's domain-name
server turbines.

If your suggested scenario is correct and the quench needs nick only
one every thirty seconds or so, that would be real swell news. However,
Hans-Werner Braun reports finding quench gushers for the UIUC Craykiller
at other times, which suggests additional testing and observation may
be in order.

Dave

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 01:23:43 EST
From:      dlw@OPAL.BERKELEY.EDU (David Wasley)
To:        comp.protocols.tcp-ip
Subject:   Re:  Telephone Access Controllers (TACs) and SLIP...

I have a very strong interest in such a thing. I envision it as presenting
host addresses on a single subnet to the various ports. The protocol would
be to "log in" to the system (validation and all that) and be given an IP
address & mask for the duration of the session. After that, it is all IP
until carrier drops. Is there a well defined, documented protocol for this
initial dialogue? How would you deal with dynamic name/address mapping?
I can see dynamic registry with a DNS, and timeout/de-registry. But what
about the email relay that wants to deliver to me and must be told that
I've just connected? (This is one reason I want real, secure validation.)

If such a thing existed, I can see supporting a "rotary" of 64 ports (min)
for general campus network access here. They should run up to 64Kb/s.
The line protocol should be SDLC with a well defined IP encapsulation
so my PC, uVax, MAC-II, or SUN can implement it. Etc. It should have logging
of course...

Maybe all this is obvious. Maybe there is one out there?? I haven't seen it.
(Yeah, we could make one, but I'd rather see a standard product :-)

	David Wasley
	U C Berkeley

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 87 09:49:17 -0500
From:      Andy Malis <malis@CC5.BBN.COM>
To:        Charles Hedrick <hedrick@ARAMIS.RUTGERS.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: new Arpanet end to end protocol
Charles,

Your message is quite wrong (I know - I designed the new
End-to-End).  I would be interested in knowing (in private) who
your "reliable source" is, so that such rumors can be source
quenched.  After the recent messages on the tcp-ip list, I'm sure
we all realize how important source quenching is.

The truth of the matter is:

PSN 7.0 has two different End-to-End protocols (old EE and new
EE).  Either one or the other runs at any particular time, and
the two cannot interoperate.  The ARPANET is currently using PSN
7.0 with the old EE.  It is the new EE that will be tested on
Nov. 7, 14-15, and 18.

The old EE protocol explicitly returned, across the PSN subnet, a
separate RFNM packet for each message delivered to a destination
host.  This RFNM packet was then converted, in the source PSN,
into the 1822 RFNM for that message and delivered to the source
host.  This had the result that, depending on traffic mixes,
roughly about 45% to 50% of the packets going through the subnet
were RFNMs.  Since the PSN does so much per-packet processing,
even for these RFNMs, the network was passing much less host
traffic than otherwise might be possible.

We fixed this in the new EE by making it an explicitly windowed
protocol IN THE SUBNET.  The destination PSNs have the ability to
aggregate ACKs (the new EE internal equivalent to RFNMs) and send
multiple ACKs for the same connection in windowed ACK (by using
an INTERNAL message sequence number).  In addition, these ACKs
can now be piggybacked on data traffic, and many ACKs for
different EE connections can be shipped together in the same
subnet packet to a source PSN.

The important thing to note is that when the destination PSN
receives an ACK for a connection, it generates, and sends to the
source host, a separate 1822 RFNM for EACH and EVERY message
submitted by the host and being acknowledged by the ACK.  There
are no host-visible sequence numbers; the 1822 protocol stays the
same as before.

What may have confused you is the fact that we at BBN are,
concurrent with the PSN 7.0 testing, trying to track down which
ARPANET hosts might be affected by a known BSD 4.2 network
software problem that may cause RFNMs to be lost in the host
itself (I believe it is related to the size of the message
received PREVIOUS to the RFNM).  This bug has been fixed in BSD
4.3, and I have been told that Lars Poulsen of ACC
(lars@acc.arpa) has a patch for BSD 4.2-derived host software.

By the way, we have measured in our internal BBNNET (which has
been running PSN 7.0 with the new EE only for over five months
now) that only about 14% of the packets through the network only
contain ACKs - the rest of the ACKs are being piggybacked on the
data traffic.  We are very pleased with this result.  Also, most
of our BBNNET hosts (around 125 C/70s, VAXEN, TOPS-20s, TACs, and
others) use 1822, and they have had no problems with the new EE.

Regards,
Andy
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Nov 87 10:13:22 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        orchard/bruc@scarecrow.waisman.wisc.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: TCP maximum segment size determination

Bruce,

    Last week I volunteered at the IETF meeting to write a proposal for
just such an IP option.  You should see it within a couple of weeks
(seeing it implemented may take a while longer...)

    By the way, the scheme is sound even if the path changes if you
treat the IP option and the TCP MSS values as distinct.

    I.e. in the TCP MSS you should advertise the maximum segment
size you wish to accept and the remote end should keep this value
and separately keep track of what IP reports.  You would use the minimum
of the two MSS's reported when sending. Then if you get an indication
that the route has changed (such as an ICMP redirect), you can send the
IP option again, and update the effective MSS (up or down).  There's
still the problem of packets following different paths -- this may
have a solution but I'm still looking for something that doesn't feel
like a kludge of a three way handshake.

Craig
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 11:57:00 EST
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Telephone Access Controllers (TACs) and SLIP...


I would be a little nervous about dynamic name/address binding
so that the host could receive calls (mail, file transfer, etc),
but comfortable with originating calls - assuming, of course,
that this meant you could not masquerade as an arbitrary
host name by using SGMP and asking for messages for that host.

Apart from security concerns (which may be present regardless
of ability to receive calls as well as originating them), getting
the Internet to handle dynamic name/address binding, avoiding
spoofing and dealing with the potential for multiple name servers
to be out of sync, causing confusion, seems quite an ambitious
chore. Perhaps Mr. Wasley has thought this through and can offer
his view of the architectural considerations?

Vint

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 12:37:25 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP maximum segment size determination

The lower the performance of your network interface, the more trouble *any*
fragmentation means to you.  On PCs, we try to eliminate fragmentation by
specifying a small MSS when routing via any gateway (subnets-are-local
would be nice to do, but we haven't yet).  The IP option you propose would
help, but not until all gateways handled it properly.

If gateway gurus saw their way clear to do so, they might help some fraction
of the world by arranging that IP fragments aren't transmitted consecutively
(if there is other traffic to handle) or by inserting a little time delay
if the Ether or other non-serial media is idle.  Presently, fragmenting an
IP datagram is the best simple way I know to determine how close together a
given hardware/software combination can send packets.  If the gateway goes
faster than the host can handle, suddenly it is time for a TCP retransmit...

I can't say when/where I heard this, but I always thought that SATNET had an
MTU of 128 bytes.

jbvb

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 13:53:21 EST
From:      mac@idacrd.UUCP (Bob McGwier)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Microport TCP recommendations

in article <141@ncc.UUCP>, lyndon@ncc.UUCP (Lyndon Nerenberg) says:
> Xref: idacrd comp.protocols.tcp-ip:1594 comp.dcom.lans:885
>

Lyndon:

I would have thought you knew that Phil's stuff has been ported to
system V.  Contact Bdale Garbee.

Bob
 

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 14:44:23 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet/IP Testing/Monitoring Tools

FTP Software sells a low-cost network monitor called LANWatch.  This is
derived from the MIT freeware program NETWATCH, with many features added.
Our symbolic filters and detailed packet examination mode understand most
IP protocols and formats, from IP and ICMP to TCP.  We sell the package as
software-only, you supply the PC and the interface.  We provide enough source
so users can extend the symbolic filters and packet displays to include
protocols we don't support.  We also provide source for the off-line analysis
programs that process packets dumped to disk.

We support a number of different PC network cards, and our performance
depends on which card and how fast a machine you put it in.  Even with a
fast one in a fast AT, our packet capture ratio is unlikely to match that
of a network monitor with special hardware.  However, we feel that our
cost makes up for a good deal in that department.

The present release, 1.0, only has symbolic breakdowns for IP & relatives.
LANWatch 1.1 will have a much better understanding of XNS, DECNet and 802.2/IP
protocols, and it should be available next month.  We don't have any traffic
generation tools in the package yet.

James B. VanBokkelen
FTP Software Inc.
P.O. Box 150
Kendall Sq. Branch P.O.
Boston, MA  02142
(617) 868-4878

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 14:56:52 EST
From:      daveb@geac.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: host down (was  ..."layering violations")

In article <8711030915.AA00844@gumby.wisc.edu> 
	Mitchell Tasman (g-tasman@GUMBY.WISC.EDU) writes:
[discussion of the behavior on "host down"]... a daemon
| should immediately close the associated TCP connection.
| 
|      With an 1822 Distant Host connection to DDN, this may be a fairly
| reasonable approach.  However, a typical DDN connection of late has been
| X.25 or HDH.  Here, "host down" may have a more transitory meaning:  simply 
| that there was noise on the host access line.  The remote host may well
| reappear with all TCP connections intact.

  My experience with short-haul or secondary nets has been that
there are two distinct kinds of events which TCP might regard as a
"host down".

  One is a real host-down and the other is the aforementioned QRN
(noise) on the line.  The latter is particularly annoying on what is
supposed to be a low-error medium...

  Methinks that TCP is being a bit pessimistic: IP is not supposed
to be error-free, and I suggest that TCP may be misinterpreting the
errors which a short-haul network seems to love to produce as a more
serious and long-term event than it really should.

  Could map or someone comment? 

 --dave (on the other hand, i could be biting my foot) c-b

-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 15:30:52 EST
From:      danny@itm.UUCP (Danny)
To:        comp.protocols.tcp-ip
Subject:   Bridge Terminal Server Problems

Hear me O ye wise ones!  Incline thine ears, that ye may understand,
and save thy humble servant!

    I've a problem (no it's not my English).  We have a Bridge
Communications Server (CS100) which is connected to our ethernet.  Our
computer is a Celerity C1230 running BSD4.3.  Now, the Bridge box
assigns a IP address to each port, e.g.: port 0 is "77.0.0.100", and
the Celerity is "77.0.0.2".  We just want to hang printers off of the
Bridge box; so each printer has an address and host name of its own.

    Now, the problem.  I can connect to (for example) necc using telnet.
Everything's fine.  What I type on the terminal, is printed on the
Nec (5515).  We also run MDQS from BRL.  I wrote a short routine to
open a socket, connect it to a host (necc), and dup2 it as stdout (which
is what an MDQS server requires).  When I submit a request to necc,
the connection succeeds!  Then, usually, the server immediatly dies with
a SIGPIPE.  That's kinda OK.  FIRST, should the connection succeed?
I don't think so.

    Then, after a few rounds of the server restarting itself, it will
run to completion!  Where does the data go?  I thought that TCP
garentees delivery, but to where you wanted it to go.

    So, why is the Bridge box accepting two connections to the same
serial-port/address?  Why does the second then mysteriously fail?
Where does the data go when it succeeds?

    HELP!
    
                                            Danny
-- 
				Daniel S. Cox
				(seismo!gatech!itm!danny)

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 15:55:32 EST
From:      timk@ncsa.uiuc.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet source code -- free



NCSA Telnet source code is now available.

The National Center for Supercomputing Applications announces our source
code release of NCSA Telnet version 2.1.

This message includes:

	Source Code pricing information
	Some changes from 2.0 to 2.1 (you may not need to upgrade)
	Mailing list for telnet related questions/bugs (telnet@ncsa.uiuc.edu)
	User/Developer forum at TCP/IP conference in December


Source Code

There are a variety of disk options if you don't want to spend all night
transferring files (even compressed ones).  See the price list at the end
of this note for details.  Note that the Anonymous FTP directories are
available on one convenient tape and it contains all of the files from the
other disks.

Compilers:  	PC - Lattice C 3.1, Microsoft C 4.0 (MSC not debugged).  
		Mac - Aztec C, there will be an MPW version soon.

All of these files are available via anonymous FTP on NSFnet and ARPANET
from host 128.174.20.50 (ftp.ncsa.uiuc.edu).


Enhancements in version 2.1

For the PC, we have added a driver for the MICOM NI5210 (not the NI5010)
board, and a driver for the IBM (Ungermann-Bass) NIC Ethernet board.  You
use the same configuration files for each board, but select a different
.EXE file to run.

For the Macintosh, we include support for Apple's new EtherTalk driver
directly for use with the new EtherTalk Ethernet board.  We also support the
Kinetics' EtherSC and EtherPort SE products with their EtherTalk driver.

Unless you have these hardware needs, you may not need to upgrade from 2.0
to 2.1.  You should upgrade from anything pre-2.0 to version 2.1.  


Mailing list and conference meeting

We are sponsoring a mailing list for people interested in keeping up with the
NCSA Telnet distribution and the various groups taking part in future 
development.  The address is telnet@ncsa.uiuc.edu.  Send a message to 
telnet-request@ncsa.uiuc.edu to get on the list.

There will be a meeting at Advanced Computing Environment's TCP/IP conference
in December.  We will discuss user problems and the status of various
development projects.  This will be a good time to ask technical questions.


Thanks for your interest, some details follow the signature,

Tim Krauskopf
National Center for Supercomputing Applications (NCSA)
University of Illinois

timk@ncsa.uiuc.edu            (ARPA)
timk%newton@uxc.cso.uiuc.edu  (alternate)
14013@ncsavmsa                (BITNET)

--------------------------------------------------------------------
Fact Sheet
----------

National Center for Supercomputing Applications presents:

NCSA Telnet for the PC, version 2.1
NCSA Telnet for the Macintosh, version 2.1

These programs are copyrighted, but distributed with no license fee.  
Source code is available.

Features included in version 2.1 of NCSA Telnet:
-----------------------------------------------
DARPA standard telnet 
Built-in standard FTP server for file transfer
VT102 emulation in multiple, simultaneous sessions
Class A,B and C addressing with standard subnetting
Tektronix 4014 graphics emulation
Scrollback for each session
Each session in a different window (Macintosh)
Supports Croft gateway - KIP (Macintosh)
Support for EtherTalk (Macintosh)
Capture text to a file (PC)
Full color support (PC)
Support for 3COM, MICOM and IBM (Ungermann-Bass) boards (PC)

How to obtain:
-------------
1) From a friend

The disk, documentation and files may be copied freely and distributed in
binary form, unmodified, with copyright notices intact.  This distribution
is free and no copies may be sold for profit.

2) Anonymous FTP from   ftp.ncsa.uiuc.edu   (128.174.20.50) 

You may want to ftp the README file to determine which files to transfer
to your home machine.

For the PC version, you have your choice of tar files which are individual
for each type of Ethernet board.  For each tar file, there is also a
compressed tar file with the same contents.  The documentation file goes
with any type of Ethernet. After the files are extracted from the tar
file, some transfer method (e.g. kermit, NCSA Telnet) should be used to
download the files to the PC.  The documentation is in line printer
format.  Remember to download .EXE files in binary mode.

The Macintosh version consists of several files encoded with BinHex 4.0,
Pack-It or Stuff-It.  You may want to consult the README file to determine
which files to transfer.  Download them with a binary transfer method
(kermit, NCSA Telnet) and extract the individual files.  The documentation 
is in Microsoft Word 3.0 format.

3) Diskette

On-disk copies, with a printed manual are available for a small fee, which
covers materials, handling and postage.  Orders can only be accepted if
accompanied by a check made out to the University of Illinois.  Send to:

NCSA Telnet orders (specify PC or Macintosh and product)
152 Computing Applications Building
605 E. Springfield Ave.
Champaign, IL 61820

Here is the price list:
	NCSA Telnet for the PC (2.1,2.1M,2.1IBM)	$20.00	
		(three 360K disks, PC user/installation guide)
	NCSA Telnet for the Macintosh (2.1,2.1E)	$20.00
		(two 400K disks, Macintosh user/installation guide)
	NCSA Telnet for the PC source			$20.00
		(two 1.2M disks, Developer's guide)
	NCSA Telnet for the Macintosh source		$20.00
		(one 800K disk, Developer's guide)
	Anonymous FTP source reel tape			$30.00
		(recent contents of our anonymous ftp directory, 
		1600BPI 9track Sun-BSD tar format, Developer's guide)
	Anonymous FTP source cartridge tape		$50.00
		(recent contents of our anonymous ftp directory, 
		1/4 inch cartridge tape Sun tar format, Developer's guide)

Hardware required:
-----------------
PC: IBM PC,XT, AT or compatible. 
	3COM 3C501 Etherlink board.
	or IBM RT PC Baseband adapter.
	or Ungermann-Bass PC-NIC board.
	or MICOM NI5210 Ethernet board.

Mac: Macintosh Plus, SE or Macintosh II.  
     FastPath from Kinetics Inc.  Walnut Creek, CA   (415) 947-0998 and
	Kinetics gateway software or Stanford KIP (Croft) gateway software.
    or
     EtherSC or EtherportSE and EtherTalk software from Kinetics.
    or
     Apple EtherTalk board and software for the Macintosh II.

Mailing List:
------------
Mail to telnet-request@ncsa.uiuc.edu to be added to the list of recipients.
To post messages to the list, mail to telnet@ncsa.uiuc.edu.
If your mailer cannot resolve ncsa.uiuc.edu (128.174.20.42), route mail
through uxc.cso.uiuc.edu, also known as uiucuxc.arpa.

Other questions:
---------------
mail to telbug@ncsa.uiuc.edu (alternate: telbug%ncsa@uxc.cso.uiuc.edu)

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 16:55:23 EST
From:      Welch%osu-20@OHIO-STATE.ARPA (Arun)
To:        comp.protocols.tcp-ip
Subject:   Telnet options

Could someone tell me what telnet options 32 and 94 are, and which
RFC's are associated with them?  We've got a host (a dec-20 running
tops) which is returning them, causing my workstatio (a xerox 1186) to
lose... I couldn't find them anywhere in Assigned Numbers or in the
DDN Handbook.


...arun



----------------------------------------------------------------------------
Arun Welch
Systems Programmer, Lab for AI Research, Ohio State University.
welch@ohio-state.{CSNET,ARPA}
-------

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 18:01:28 EST
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  Telephone Access Controllers (TACs) and SLIP...

No, what pople REALLY want is a SLIP card on your
gateway box so that they can connect a network via SLIP to the
local ethernet.

We have 6 such connections beating the hell out of a vax 780.

---rick

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 19:46:14 EST
From:      nguyen@amd.AMD.COM (Quinn Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet versions

In article <4800@elroy.Jpl.Nasa.Gov>, david@elroy.Jpl.Nasa.Gov (David Robinson) writes:
> As most people know their are a couple ethernet standards, Version 1,
> Version 2 and IEEE 803.2.  When one installs a new ethernet board
> ...
> The question:  What is the difference between the versions and what
> effect is their on the physical wire to run two different types
> of transeivers?  I have heard people say that it is best to have all
> the same type but no "real" evidence to base that comment on.
> 

Ethernet version 2 and ANSI/IEEE 802.3 (10BASE5) signals are
physically the same.
Version 1 and 2 signals are the same in the coax.
The main differences are on the Drop cable:
- SQE (Signal Quality Error) generation after a packet transmission
required for version 2 and 802.3 but not for version 1.
- Half-step idle signal (differentially 0) with transformer
isolation required for version 2 and 802.3 but not for version 1.
 If a MAU (transceiver) does not generate SQE and only accepts,
generates full-step signals (Ver. 1), it may have problem connecting
to a version 2 DTE or vice versa.
Other issues are device to device line static isolation, ground,
etc. which are not relevant to transceiver connection...
in term of functionality.
  Hope this may help.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 22:58:58 EST
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: details on misbehaving IP implementations

Phil's 2 and 3 (returning port unreachable), like his 4 (protocol
unreachable) may not be bugs due to unclear specs, but are certainly not a
good idea.  A future spec for hosts (similar to rfc 1009 for gateways) being
written by a group in the IETF will probably specifiy that ICMP error
messages should not be sent due to IP broadcasts.  ICMP echo requests may
not be prohibited however, since they are not error messages.

Drew

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10-Nov-87 23:52:11 EST
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP maximum segment size determination

My apologies if someone has already thought of this, but mail to my site is
being delayed by up to 5 days, and seems to arrive in random order.  But,
here goes anyway:

    Date:  Thu, 05 Nov 87 21:31:54 CST
    From:  Bruce Orchard <ORCHARD/BRUC@scarecrow.waisman.wisc.edu>
    Subject: TCP maximum segment size determination

    [ ... ]
    large value.  Each node that transmitted the packet would compare
    the value given in the option to the maximum transmission unit of
    the outgoing network.  If the network value were less, the value
    in the option would be reduced to the network value.

    [ ... ]
    One limitation of this proposal is that all packets of a TCP
    connection do not necessarily pass through the same networks.
    Actually, given the way the networks are connected, all packets
    usually go through the same networks.  Also, if one packet takes a
    different route from an earlier packet, the second route could be
    on the same kind of network (for example, two parallel Ethernets).
    Regardless, the consequence of a poor choice is reduced
    throughput, not failure.

What about the required overhead for gateways and routers to have
to further inspect each packet?  It could be optimized so that only TCP
packets are inspected, but still, that would seem to add to the burden of
possibly compute-bound gateways...

    P.S.  Is the MTU of SATNET really 256 bytes, as given in IEN 192?

Could be worse, could be the 128 byte MTU of most X.75 implementations...

-Philip

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Nov 87 00:44:58 EST
From:      "Philip A. Prindeville" <PAP4@AI.AI.MIT.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        pcip@LOUIE.UDEL.EDU
Subject:   IP encapsulation over ARCnet
I'm currently looking into the problem of a standard for IP over
ARCnet.  Some of the problems are trivial, such as mapping local
IP addresses to 8-bit node numbers;  others are more involved:
ARCNet has an MTU of 508 bytes, and does not like packets
between 253 and 256 bytes.  Would all persons interested in such
a standard or willing to lend their expertise please contact me.

Sorry to bother everyone else, but I thought the Subject: was
self-explanatory...

Thanks,

-Philip
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Nov 87 00:46:33 EST
From:      "Philip A. Prindeville" <PAP4@AI.AI.MIT.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        pcip@LOUIE.UDEL.EDU
Subject:   IP encapsulation over ARCnet
I'm currently looking into the problem of a standard for IP over
ARCnet.  Some of the problems are trivial, such as mapping local
IP addresses to 8-bit node numbers; others are more involved:
ARCNet has an MTU of 508 bytes, and does not like packets
between 253 and 256 bytes.  Would all persons interested in such
a standard or willing to lend their expertise please contact me.

Sorry to bother everyone else, but I thought the Subject: was
self-explanatory...

Thanks,

-Philip
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 09:19:26 EST
From:      COINS@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   QUESTION

ANYONE (I'M NOT PROUD)

   I'M RUNNING PWB ON A PDP1170.  DOES ANYONE HAVE DET
UP ON ANY VERSION OF UNIX?  IF SO PLEASE DROP ME A NOTE.

THKS.
RON SMITH
-------

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 09:52:45 EST
From:      ernie@nucsrl.UUCP (Ernest Woodward)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet routing problems

> / nucsrl:comp.protocols.tcp-ip / karn@faline.bellcore.com (Phil R. Karn)
> / 10:27 pm  Nov  4, 1987 /
> 
> Lately I've noticed some rather persistent routing connectivity problems
> in the Internet. Many destinations fail to respond to packets sent from
> hosts on bellcore-net (128.96) but are shown to be up when I initiate
> connections from ipswitch. A given host can be unresponsive for days. 
> ...
> I suspect the problem is related to the inability of many gateways to
> handle ever-larger EGP updates.             ...
>
> I increased the size of
> MAXPACKETSIZE in defs.h from 1006 to 2048 and recompiled. The problem
> has not recurred. I suspect that there are many other gateways out there
> with the same problem; what can we do to get them fixed?
> 
> Phil
----------
	I have had routing problems for the last two weeks and failed to
understand why my egp neighbors could not assist me in routing. I believe that
the above information on my EGP implementation may be the problem. I am also
trying to implement gated, and it may be important to check that it also uses
an appropriate MAXPACKETSIZE. I am still testing routing daemons to determine
if the MAXPACKETSIZE was the root of all my problems over the last two weeks.

	The moral of the story is that I would like to see information like
that presented by Phil distributed in the same fashion as the updates on the
SRI host tables. All ARPANET host administrators might need this information
and I am not sure that all of the administrators have access to USENET or have
registration on the comp.protocols.tcp-ip mailing lists. Or, those on the
mailing lists/USENET might not get as lucky as I and notice this important
information amongst several other articles.

Ernie Woodward
Northwestern University
Academic Computing and Network Services

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 10:10:15 EST
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Telephone Access Controllers (TACs) and SLIP...

Of course, we want one, but then you knew that.

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 12:16:07 EST
From:      wrk@abvax.UUCP (William R. King)
To:        comp.protocols.tcp-ip
Subject:   reverse arp implementation question

In RFC 903 (Reverse Arp Protocol) the statement is made that if
a reverse arp packet is received with a opcode of either 1 or 2
(arp request, arp reply) that this packet can be passed on to the
normal arp code for processing.

My question is, when the normal arp code processes this request and
decides that a reply is necessary, does the data link layer 
protocol field contain the value for ARP or RARP?  Or for that
matter, does it matter?

Thanks.
Bill King
Allen-Bradley Company, Inc
!{decvax,pyramid,mandrill}!abvax!wrk

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 12:37:47 EST
From:      rohit@hpindda.HP.COM (Rohit Aggarwal)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet/IP Testing/Monitoring Tools


Hello

	Hewlett Packard and Excelan (San Jose) make Lan Analyzers.
	Both will do the job you have described.

				

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 12:57:50 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP in the Public Domain?

The specifications are all public domain.  There are implementations for
a number of different machines and operating systems that are P/D.  I don't
know of anyone who is actually running IP on Arcnet, but I know someone
who is trying to write a driver for one of the P/D IBM PC packages.  He
is pap4@ai.ai.mit.edu (Philip Prindeville).

You can get the specs, and a list which includes almost all the P/D code
and most commercial products, over the ARPAnet from the machine SRI-NIC.ARPA.
Use FTP, login as "anonymous", the specifications are in RFC: and the
Vendor's Guide is in NETINFO:.  If you don't have ARPAnet access, the
documents can be ordered on paper from SRI in Menlo Park, CA, or the
Defense Technical Information Center in ?Alexandria? VA.  For someone who
doesn't know much about TCP/IP, get the "DDN Protocol Handbook", which
costs a little over $100 (but is 6 - 8 inches high).

Will someone who has the whole address and phone number handy post it?

jbvb

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 15:14:41 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP Slang Glossary

James,

Gong (n). Medieval term for privvy, or what pased for them in that era.
Today used whimsically to describe the aftermath of a bogon attack. Think
of our community as the Galapagos of the English language.

Dave

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 15:39:07 EST
From:      fsimmons@umn-d-ub.D.UMN.EDU (Frank Simmons)
To:        comp.protocols.tcp-ip
Subject:   CMU-TEK TCP/IP


 DOes anyone have any experience with this product on a Micro-vax II?

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 18:03:03 EST
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP instability


     Is anyone else having trouble maintaining their peer relationships
     with the core? We are seeing excessive problems with high packet
     loss and eventually being dropped.

Greg, There is an arpanet/internet 'event' happening which shows up as long
queues in both directions between the PSNs and the core gateways.  Also, the
psn-gateway connection is broken frequently which causes all the queued
packets to be discarded.  Does your gateway on the arpanet get clogged also?
One change that may have affected the system is the introduction of fragmented
NR messages (EGP updates), which now take 2 arpanet messages each longer than
128 bytes; the fragments are about 1000 bytes and 200 bytes, and growing.

Some facets of the problem that are being explored are the differences between
the arpanet PSN software release 7 and the old release 6, speeding up the
processors in the core systems (upgrade lsi-11/23 to /73), and checking the
timing on the EGP implementations.

    Mike

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 20:59:23 EST
From:      spp@zion.Berkeley.EDU (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   Reference to SLIP

A while ago I put out a query asking for references to 
SLIP.  There is a "SLIP" defined in RFC914, but I'm pretty
sure this does not have anything to do with the SLIP
protocol people are actually using.

I've found several implementations, but no references, 
good descriptions, or claims as to origin.  Can anybody
help me on this one?? thanks much!

steve

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11-Nov-87 21:15:25 EST
From:      chris@GYRE.UMD.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP maximum segment size determination

There is a good standard argument against setting the MSS via an IP
option, and that is that the route the SYN packet takes is not
necessarily the same as the route that other packets will take.  (In
practise, I think we see a fair number of routes that,
diagrammatically, look like this:

			net1
	 /------>f1------------>f2-----\
	|				v
	X				Y
	^				|
	 \-------g1<------------g2<----/
			net2

where the return path is consistently different from the originating
path.  And of course, since the Internet does not rely on virtual
circuits, it can reroute dynamically, invalidating MSSes on the fly.)

4.3BSD sets the MSS to 576 (which becomes 536 data bytes) when
crossing a gateway.  This is not necessarily ideal but is the
official recommended practise.

Chris

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 01:31:07 EST
From:      chris@MIMSY.UMD.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   milarpa performance

At around 0121 EST 12 Nov 1987 (i.e., this morning) the arpa-milnet
gateway performance went from seriously awful to about 1/3 decent.
Pinging sirius.caltech.edu (picked because we happened to be sending
mail to them at the time) before and after produced a 92% packet
loss with an average delay of 20 seconds before, and 67% packet
loss with an average round trip delay of 2.88 seconds.

What happened?  Can we expect further improvements?

Chris

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 10:14:41 EST
From:      Hopper.XRCC-NS@XEROX.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   FTP for VMS from PSC


Does anyone out there have experience with the Process Software
Corporation's implementation of FTP in VMS?  We need to set up a system
to allow transfer of files from a VMS VAX to an ISI 68020 bsd UNIX
system and am trying to find a cost effective solution, PSC's price list
for a single VMS license is $1995 ( updates $595).

Mike Hopper...............Hopper.XRCC-NS@XEROX.COM

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 10:32:22 EST
From:      rhk@vilya.UUCP
To:        comp.protocols.tcp-ip
Subject:   smtp on Symbolics lisp machines


Does anyone have any expierence running tcp on Symbolics 3640's
and 3675's ?
We've installed an ethernet in our building and are using tcp
to transfer files from unix (Wollygong tcp on a 3b2-400) to the
Symbolics. We also have a AT&T 6300 using tcp from FTP Software.

The problem is that while ftp works fine we can't get smtp to
work. It seems that the Symbolics doesn't follow the format of
smtp and usr a CR NL at the end of a line.

We added a Sun 2 as a reference machine to clear up finger pointing
at Wollygong. With this group of machines smtp works fine between
the Sun, the 3b2, and the pc. To add to the confusion the smtp on
the pc works to the Symbolics as well as to the others?

Any thoughts would be appreciated.

	rich kensicki
	{attunix,ihnp4}!vilya!rhk
	201-299-3005

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 12:33:54 EST
From:      PADLIPSKY@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: host down (was  ..."layering violations")

Since you asked....

"TCP", per se (or "TCP The Protocol"), doesn't take an explicit stand
on when to give up that I recall.  I emphatically agree with you (and
Phil Karn, who started the subtopic off, and Mitchell Tasman, who pointed
out that there are extra pitfalls in the X.25 environment [which I was
not, repeat not, addressing in my first msg on the subtopic]) that it's
contrary to the robustness goal of TCP to give up too easily.  I still
would hope that implementers to whom that view is a revelation don't
swing too far the other way and keep "obviously" shot connections
around needlessly, since in some contexts the storage shouldn't be
wasted and in other contexts (perhaps even in all contexts) there's
a waste of transmissions to get SNs back in synchrony.  The call, however
forlorn, is just to "do it right"--and when you get right down to it, the
liabilities of taking too optimistic a view aren't all that severe...
except, of course, if you're wasting transmissions for "liveness"
checks, or needlesssly sending some latter-day analogue of the old
NCP RST, or being charged by some comm subnet for the apparently open
connection, or....  Oops, guess I still feel you oughta be prudent.

Well, that's probably more than enough on the subtopic for/from me, so:


cheers, map
-------

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 1987 16:30-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        BILLW@MATHOM.CISCO.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TACs and SLIP...
For a terminal server plugged into a class A c30 net, use the 3rd
octet of the IP address to differentiate the  SLIP  ports.   I.e.
transparent gateways or port expander model.  Mike
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 13:49:09 EST
From:      ccruss@deneb.ucdavis.edu (0059;0000000000;230;9999;98;)
To:        comp.protocols.tcp-ip
Subject:   Institution-wide whois

As  promised, here is the the list  of organizations that have indicated 
that they have a central whois server and database. 

---------------------------------------- 

SRI-NIC 

This  is the original whois  database for the DDN  network and has grown 
over  the  years  to  be  the  central  source of information for all of 
Internet.  The database contains information on most of the networks and 
many  of the people associated with  the Internet world. SRI-NIC.ARPA is 
the  default host  for many  whois programs.  Sending a  request with  a 
target  of "help"  will return  a help  page. Whois  at SRI-NIC  is also 
available via electronic mail. 

Whois usage 

    whois help 

Usage from electronic mail 

    Send mail to 

        service@sri-nic.arpa 

    Enter "whois" and the target name on the "Subject:" line. The result 
    will  be sent  via return  email, assuming  the "From:"  line on the 
    original message is a valid address. 

    Example: 

         To: service@sri-nic.arpa 
         From: user@host.campus.edu 
         Subject: whois help 

---------------------------------------- 

CSNET and the NNSC (NSF Network Service Center) 

This  database contains information on sites  and people associated with 
the  above networks. A help page is returned by specifying "help" as the 
target. 

Whois usage 

    whois -h sh.cs.net help 

---------------------------------------- 

STANFORD UNIVERSITY 

The Stanford whois database contains information for the 30,000 students 
and  faculty associated with the Stanford campus. Help is not available. 
Multiple  matches  to  a  target  returns  a  list  of  matches. Further 
information  on a single person can be obtained by specifying the unique 
identifier returned by the list. 

Whois usage 

    whois -h stanford.edu <target-name> 

________________________________________ 

UNIVERSITY OF CALIFORNIA, DAVIS 

The  UC Davis whois database contains entries for the 15,000 faculty and 
staff  on campus. The service can return information on an individual or 
return  a list  of people  in a  particular department.  A help  page is 
returned  by  specifying  "help"  as  the  target.  The  service is also 
available via electronic mail. 

Usage from whois 

    whois -h ucdavis.edu help 

Usage from electronic mail 

    Send mail to 

         Internet: whois@ucdavis.edu 
         Bitnet: whois@ucdavis 
         UUCP: ...!ucbvax!ucdavis!whois 

    Enter  the whois target name on the "Subject:" line. The result will 
    be  sent via return email, assuming the "From:" line on the original 
    message is a valid address. 

    Example: 

         To: whois@ucdavis.edu 
         From: user@host.campus.edu 
         Subject: help 

---------------------------------------- 

I  received several messages  from sites indicating  that they currently 
did  not have  a server  or database.  However, they  were interested in 
setting one up and asked about our software. Here is the information. 

Our  whois server and email interface  run on a 4.3 bsd  system. It is a 
combination  of local  code and  a Unify  database. The  main reason for 
using  Unify  is  because  it  was  already  on  the  system. If you are 
interested,  the sources for the local code,  which can be used with the 
Unify  system or modified  to work with  another database, are available 
via   anonymous  ftp   from  ucdavis.edu   and  are   in  the  directory  
dist/ucdwhois/. 

We  also use this  same database for  the campus email  delivery system. 
Included in the database is the actual usercode and host that mail for a 
MAILID  is  to  be  delivered.  Details  on  the  database structure are 
included in the tar file. 

Russ 
                                Russell Hobby               
                         Data Communications Manager 
     U. C. Davis                 
     Computing Services       BITNET:    RDHOBBY@UCDAVIS 
     Davis Ca 95616           UUCP:      ...!ucbvax!ucdavis!rdhobby 
     (916) 752-0236           INTERNET:  rdhobby@ucdavis.edu

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 15:40:37 EST
From:      hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple subnets on one physical network

The truth is that every different implementation has its own quirks,
and you're going to have to find a combination of features that works
with the particular set of implementations that you have.  The
cleanest thing is probably to have each interface on the gateway have
a single address.  The Unix versions that I know of only require that
the gateway be on a directly connected network.  You can tell them
that all the subnets are directly connected, by using "route add" with
a zero metric.  So there is no problem.  It is true that many systems
(not just Unix) will try to forward packets for addresses that they
don't recognize.  4.3 can have this turned off.  In a situation where
there are multiple subnets on one cable, I would use a broadcast
address of 255.255.255.255, rather than mentioning the specific net
number.  4.3 lets you set the broadcast address to be used on an
interface.  So do some other systems.  Whether all of yours do is
anybody's guess.  I'm afraid you're going to have to look in detail at
each system you have and find a combination of things that works.

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 16:57:50 EST
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   TACs and SLIP...

Oops.  My question was slightly misunderstood (But it did cause a lot
of interesting responses).  Perhaps a more detailed explanation is
called for, if I can do it without getting overly commercial...

There are essentially two models possible for doing a "slip server".
At cisco, we refer to these as the "terminal server" model, and the
"gateway" model.

In the gateway model, each slip connection has its own subnet, possibly
with another network on the other end of the link.  Information about
how to reach hosts on the other side is all exchanged via normal routing
protocols, and the box is acting as a real gateway.  The host can pick
its own IP address by virtue of pretending to be a gateway between the
SLIP link (whose address is fixed) and the host's network.

In the terminal server model, each slip connection is mapped to a
particular IP address, and the box ARPs for all of the resulting IP
addresses - essentially acting as a giant, extra long, very slow,
multi-port ethernet transceiver.  Each slip speaking box gets assigned
an IP address on the same subnet as the terminal server itself.  Since
no routing information is exchanged, only one IP address at the other
end is possible, and the slip server gets to pick it.

cisco has implemented the terminal server model of a slip server as
part of our terminal server.  If enabled, users could issue a SLIP
command, and the exec prints out info telling them their IP address,
and then it goes into a mode where only IP packets are transferred.
(How to exchange this sort of information in a machine oriented
fashion is an unresolved issue - we're interested in any suggestions).
SLIP lines (actually, lines in general) can run up to 38.4Kbps, and
of course lines can get configured permanently in SLIP mode too.
Up to 96 terminal lines can be put on one box.

We think that the gateway model is also implementable, though the idea
of an 97 way gateway is somewhat mind-boggling.  What may happen in
this area is a SLIP driver for the serial (normally HDLC) cards we are
currently using.  Up to 6 lines per box would be possible.

The original question I asked was meant to mean:

Given that we have implemented SLIP on our ethernet terminal server,
and that we also sell a DDN terminal server (a "TAC" with 1822 or
X.25 interfaces), should be also attempt to have the DDN Terminal
server ALSO support slip, by way of the logical host mechanism that
exists in the DDN network world.

Im still interested in the answer to that question, but the discussion
on SLIP issues in general is interesting too, though it might be more
appropriate for, say, the PCIP mailing list.

Bill Westfield
cisco Systems.
-------

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 18:32:00 EST
From:      CF4A8X@IRISHMVS.BITNET ("Mark D. Eggers  239-7258", 219)
To:        comp.protocols.tcp-ip
Subject:   Name Server for Ultrix 2.0

Does anyone know of a name server implementation for Ultrix
2.0 ?  I haven't seen it in the documentation . . . .

Thanks for any information

/mde/

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Nov 87 18:32 EST
From:      "Mark D. Eggers (219) 239-7258"      <CF4A8X%IRISHMVS.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Name Server for Ultrix 2.0
Does anyone know of a name server implementation for Ultrix
2.0 ?  I haven't seen it in the documentation . . . .

Thanks for any information

/mde/
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 19:30:00 EST
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: TACs and SLIP...

For a terminal server plugged into a class A c30 net, use the 3rd
octet of the IP address to differentiate the  SLIP  ports.   I.e.
transparent gateways or port expander model.  Mike

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12-Nov-87 21:56:20 EST
From:      schoff@NISC.NYSER.NET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: SGMP


    
    	Does anyone know where I can get info concerning SGMP (Simple
    	Gateway Mgmt. Protocol)?  Anything would be helpful.

    	Thanks in Advance,


    -- 
    ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===
   -===
     Bob Esposito,  Bell of Pennsylvania - espo@bpa.bell-atl.com - (215) 466-68
   31
    ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===
   -===

why don't you call the NYSERNet NISC at 518-283-8860 and ask
for either Mark Fedor or myself, (we're two of the authors of the RFC).

Marty

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 06:48:00 EST
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Solicitation for comments

In a large scale, highly heterogeneous internet, knowing the entire
topology requires that a substantial amount of information be shared
among a far-flung set of components. This is not easy - nor is the
data necessarily very timely when it finally arrives. 

Basing routing on out-of-date information seems like an
invitation to congestion - or are you discounting that on the
basis of something you haven't mentioned yet?

Vint

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 06:51:53 EST
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP over FDDI

What's the problem with 16 or 48 bit addresses?  All 802.x networks are like
this.  However, it is clearly specified that you can't have a particular
network with both sizes in use at the same time.  I'll bet FDDI is the same,
though I don't have a spec in hand.  In either case, the hardware length
field in the ARP packet should be used to specify the size.

Drew

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 07:38:00 EST
From:      Gavin@DREA-BALROG.ARPA (Gavin L. Hemphill)
To:        comp.protocols.tcp-ip
Subject:   Re: MILNET <=> ARPANET problems

I also have been seeing the problems mentioned in previous messages when
trying to establish connections between a host on DRENET (DREA-XX.ARPA)
and hosts on the ARPANET (looooong round trip times many packets dropped
etc.) but just to add some new information I seem to be able to make
reasonably reliable connections between the same host and hosts on the
MILNET.  Now I know, given our network topology that the packets to/from
the MILNET are flowing through the ARPANET so why can't I make
connections to machines on the ARPANET?
	G++
-------

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 09:13:40 EST
From:      daveb@geac.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Telephone Access Controllers (TACs) and SLIP...

In article <12348296366.8.BILLW@MATHOM.CISCO.COM> BILLW@MATHOM.CISCO.COM (William Westfield) writes:
>Is there any interest in a TAC like device capable of running SLIP
>(Serial Line IP) on its terminal interfaces ?  As I currently
>envision this, each serial line could be a logical host when acting
>as an IP device, and just a normal port when acting as a terminal.
>This might provide some performance improvement over things like
>kermit for downloading/uploading files....
>
>Bill Westfield
>cisco Systems.

  This is a subset of the idea of an "async gateway processor",
which is a small, general-purpose computer gutted to run several
gateway programs.

  A plausable set might be:
	IP to ordinary ttys (ie, normal TACyness)
	IP to SLIP
	TCP/IP telnet/TACyness kermit (recent large-block kind)
	TCP/IP telnet/TACyness to MNP (a mostly-transparent modem protocol)
	TCP/IP telnet/TACyness to X.pc (if you feel masocistic)
  A good cantidate for such a machine might be one of the
"unix-like" small realtime systems running on mas-market hardware.

 --dave
-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 09:50:33 EST
From:      brian@sdcsvax.UCSD.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   MINFO, MAILA, MB, MR, MG usage

We've come to the conclusion here at UCSD that a few of our mailbox
handling problems can be solved by using the nameserver system on
campus as a method of maintaining and distributing a sort of global
mailbox mapping table.  Clearly something of this nature was intended
when the MAILB, MB, MR, MG, and MINFO stuff was designed into the
nameserver system.

Yet I can find no solid suggestions for use, nor any mention of actual
implementations of these features.  The early domain RFCs mention the
possible uses, but offer no practical suggestions nor do they really
define the semantics of each of the possible mailbox RRs.  RFC974 also
denies any specification.

Is this uncharted territory?  Have others used these RRs?

I'm in the process of hacking them into the Berkeley Unix MTA -
sendmail.  Any suggestions would be welcome.

	Brian Kantor	UCSD Postmaster & Keeper of the News
		UCSD Office of Academic Computing
		Academic Network Operations Group  
		UCSD B-028, La Jolla, CA 92093 USA
		brian@sdcsvax.ucsd.edu	(619) 534-6865

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 09:58:01 EST
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Networks & vendor upgrades/fixes


    ....  If you are running an old release you should upgrade.

    	-- WIN

This is one of the problems faced by network managers and users.  Upgrading
them might be easy, if they were my machines, and their software was under
maintenance.  Not many manufacturers offer software upgrades on a "1 master
per site" basis, and the fees I remember from my PDP-11 days are in the
thousands of dollars a year.  Most licenses allow users to copy the new
software to many machines, but having only one set of current manuals breaks
down if more than 5 or 6 people are using them, or they aren't close together.

Regardless, there is a fair amount of effort involved in installing a new
release, whatever the cost, and not many users of these machines are up to
doing so themselves, even if they had time.  Customization and O/S-version-
dependent third-party software can make upgrading essentially impossible,
even if attempted by the original installer.

All of which is why many organizations which are setting up large networks
want homogenous hardware, rigid version control, and source code.  Perhaps
the manufacturers should put on their thinking caps...

jbvb

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 09:59:47 EST
From:      roytar@syntrex.uucp (Roy Tarantino)
To:        comp.protocols.tcp-ip
Subject:   distribution list

Please add me to the maillist for this group.
Thanks,
	Roy Tarantino
	...!rugters!pyrnj!syntrex!roytar

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 10:09:21 EST
From:      nemnich@NRL-CMF.ARPA
To:        comp.protocols.tcp-ip
Subject:   ARPANET<->MILNET problems

I have had the misfortune of having to cross the MILNET/ARPANET boundary for
the past two months.  I don't think the problems are related to the new PSN
software, since I am not seeing that much of a difference since it was
installed.  Also, things are moving right along when I stay on the MILNET or
the ARPANET.  The gateways must be incredibly overloaded; I see lots of packet
loss when pinging across the boundary.

A question for those with the data: How evenly spread is the load among the
ARPA/MILNET gateways?

--Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA
  Temporarily at NRL, Washington, DC: +1 202 767 9044
  bruce@think.com, ihnp4!think!bruce, bjn@mitvma.bitnet

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 10:37:39 EST
From:      ehrlich@psuvax1.psu.edu (Dan Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   Re: Life after source quench

In article <8711081434.aa25516@Huey.UDEL.EDU> Mills@UDEL.EDU writes:
> ...
>HOST : 128.117.8.7 : (unlisted - who is this USAN dude?)
>20:26:43 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]

I do not know who [128.117.8.7] is but [128.118.28.2] is
psumeteo01.psu.edu, a MicroVAX II run by the meteorology department
here at Penn State.  I believe that they run VMS and are using an
EXCELAN card to there TCP/IP.  If I can be of more help get in touch.

> ...
>Dave


-- 
Dan Ehrlich <ehrlich@psuvax1.{psu.edu,bitnet,uucp}>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA   16802
+1 814 863 1142 or +1 814 865 9723

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 10:42:06 EST
From:      gc@bnl.ARPA (Graham Campbell)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet versions

In article <4652@amd.AMD.COM> nguyen@amd.AMD.COM (Quinn Nguyen) writes:
>In article <4800@elroy.Jpl.Nasa.Gov>, david@elroy.Jpl.Nasa.Gov (David Robinson) writes:
>> As most people know their are a couple ethernet standards, Version 1,
>> Version 2 and IEEE 803.2.  When one installs a new ethernet board
>> ...
>> The question:  What is the difference between the versions and what
> ...
>Other issues are device to device line static isolation, ground,
>etc. which are not relevant to transceiver connection...
>in term of functionality.

However if you interpret "functionality" to include "does it function",
then the other issues are very relevant.   We have had the experience
where a IEEE 803.2 transceiver would work, but a Version 2 transceiver
would not work.  The difference apparently was in the shielding and
extra pins used in the connectors for the shielding.  From my description
you can tell that I do not understand the problem very well and would
appreciate a reference to the complete differences (if it exists).

Graham



-- 
Graham Campbell  (gc@bnl.arpa, gc@bnl.bitnet, ...!phillabs!sbcs!bnl!gc)

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 11:33:19 EST
From:      jas@MONK.PROTEON.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   ARP over FDDI

Nope, FDDI is more clever.  You can mix address sizes on the same
ring.  Why do architects of next-generation network whatevers keep
insisting on variable-size everything?

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 11:47:38 EST
From:      retrac@titan.rice.edu (John Carter)
To:        comp.protocols.tcp-ip
Subject:   Results of my query on best TCP-IP performance

References:



Hello,

    A couple of weeks ago I posted a query about what the absolute best
case for tcp-ip throughput on a 10 Mbit/sec ethernet was.  I didn't get many
responses, but I'm very grateful for those that did reply (Thanks!).

    The numbers are pretty good, but for comparison purposes keep in mind
that these are best case numbers and also make note of the processors on
which the measurements were made (since processor speed is the dominant
cost).

----
From: David Robinson <david@elroy.jpl.nasa.gov>

The best I have personally seen is between two Sun-3/260's doing
memory-memory transfers is 3.2Mbits/sec.  Their UDP topped out
at 5Mbits/sec.  This was on a fairly quite net, rwhod and routed
traffic only.  From my experience excelan boards have been the
worst, slower than my lowly Sun-2, but what can be expected from
a 80186??

I do not know what the limiting factor of the Sun's is by I suspect
that it is CPU bound, the e-net controllers each have large
memmory buffers (256K?).

	-David Robinson
	david@elroy.jpl.nasa.gov


----
From: lekash@orville.nas.nasa.gov

Better performance for ethernet is not that likely until someone
builds a better interface card.  Thats the current bottleneck.
If you go to other media, say pronet-80, or hyperchannel, you
can get much higher rates.  we were seeing up to 17mbits/sec over
hyperchanel, proteon claims over seven for their ring.  I
would guess with performance tuning, those numbers will
increase. (We might even do some here.)

					john


----
From: nowicki%rose@sun.com (Bill Nowicki)

Disclaimer: this is NOT an official number, just my latest test in an
uncontrolled environment with an unannounced software configuration.
But between a pair of Sun-4/260s I am able to transfer with TCP over an
Ethernet at 5.0 Mbits/second.  

	-- WIN

----


  Thanks again to David, John and Bill!

  The next article should be a follow-up query.

John Carter
Rice University

=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
*   UUCP: {Backbone or Internet site}!rice!retrac       oo                   =
=   ARPA:  retrac@rice.edu                              <                    *
*   CSNET: retrac@rice.edu                              U  - Bleh.           =
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 11:54:35 EST
From:      lekash@orville.nas.nasa.GOV.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  Life after source quench

I take care of 128.102.16.10.
It's one of the '2nd-root-servers'
Quite why someone at rutgers is sending
such a stream of to it, I couldn't tell
you.  Maybe a broken server at their
end, and they are cleverly using the
wrong set of servers due to a leak somewhere.

				john

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 11:56:53 EST
From:      tcs@USNA.MIL.UUCP
To:        comp.protocols.tcp-ip
Subject:   Tektronix 6130 bugs

Hi,
	We have a Tektronix 6130 here at the Naval Academy.  Unfortunately,
it seems to have some interoperability problems with regard to the ethernet.

It has its own nameserver which doesn't seem to know about RFC 882
domain nameserver operation and domain style names.  It falls back to reading
/etc/hosts for systems not running the Tektronix nameserver.  The manual
states:
	Only the following characters are allowed in a
        hostname:  letters (upper or lower), digits, underline
        _, or minus sign -.
                    
Does anyone know of a real fix for this?

We have also had problems with rwho and ruptime, among others.  Is anyone 
successfully using a Tek 6130 in an internet environment?

Thanks,
	-tcs

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 12:12:19 EST
From:      retrac@titan.rice.edu (John Carter)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Query for best protocol performance on a 10 Mbit/sec ethernet

Hello,

    I'm studying high throughput bulk data transfer protocols and am
interested in finding out what the best performing current protocols can
achieve.  I'd like to know what are some best/average case times for various
protocols to transmit 10 megabytes over a 10 Mbit/sec ethernet.  To be more
specific, what are the best or average times for your favorite bulk data
transfer protocol (tcp-ip, etc.) to transfer 10 Mbytes from the main memory
of one machine to the main memory of another machine (as measured from the
time the sender invokes the protocol until the receiver receives the entire
chunk of data and the sender is informed of this).  I'm primarily interested
in performance over a 10 Mbit/sec ethernet (which is pretty standard) but 
wouldn't mind hearing about other systems.  An alternative performance
measure is the best case throughput (megabits/sec) that your favorite protocol
achieves - in this case mention how much data you transferred to get the
result.

    Please include a short description of your configuration (e.g. a pair of
Sun 3/180's on a 10 Mbit/sec ethernet running Sun Unix 3.2).  Also
mention any performance tuning hacks you may have done to the original
protocol (if any).  This should make it obvious what the bottleneck in the
system is (usually the CPUs) and other things.  If its an uncommon or special
purpose protocol, a reference would be helpful.

    Mail your responses to me directly via e-mail.  After the responses begin
to taper off, I'll post the results to comp.protocols.misc.

    Thanks in advance for any time and effort you make on my behalf!

John Carter
Dept. of Computer Science
Rice University

P.S. I've posted the results of a similar query restricted to tcp-ip in
     comp.protocols.tcp-ip for anyone that's interested but doesn't normally
     read that newsgroup.

=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
*   UUCP: {Backbone or Internet site}!rice!retrac       oo                   =
=   ARPA:  retrac@rice.edu                              <                    *
*   CSNET: retrac@rice.edu                              U  - Bleh.           =
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 13:17:37 EST
From:      merlin@hqda-ai.UUCP (David S. Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: smtp on Symbolics lisp machines

In article <353@vilya.UUCP>, rhk@vilya.UUCP (KENSICKI) writes:
> 
> Does anyone have any expierence running tcp on Symbolics 3640's
> and 3675's ?
> It seems that the Symbolics doesn't follow the format of
> smtp and usr a CR NL at the end of a line.

     I did this here.  The SMTP works fine, but the Unix machines
in general are botched.  The Sun, in particular, sends newline
(LF) at the end of line.  The Symbolics obediently sat there and
waited for a CR LF combination, which the Sun never sent.

     The fix was to add "E=\r\n" to the sendmail.cf on the Sun.

     Beware of the Symbolics store-and-forward mailer.  This
system believes that if you have a Symbolics user "chris", then
every "chris" in the world is just another name for your local
user.  I could not get around this - I had to tell the Symbolics
machines that they did not have store-and-forward, but the Sun
did.  I also set all-addresses-forward.  The Symbolics then give
everything to the Sun, which is smart enough to get it to the
correct machine.

-- 
David S. Hayes, The Merlin of Avalon	PhoneNet:  (202) 694-6900
UUCP:  *!uunet!cos!hqda-ai!merlin	ARPA:  ai01@hios-pent.arpa

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 14:03:25 EST
From:      kelsen@ge-dab.GE.COM (Mike Kelsen)
To:        comp.protocols.tcp-ip
Subject:   Re: smtp on Symbolics lisp machines


     We experienced a similar problem with mail between a VAX 11/780
running ULTRIX 2.0 and our Symbolics.  To correct the problem, we 
modified the /usr/lib/sendmail.cf file on the VAX to include the
following line for mailing to the Symbolics:

     Mether, P=[IPC], F=msDFMuC, S=11, R=21, E=\r\n, A=IPC $h

     If this doesn't work as is, try to rearrange the items on the 
line.  That's how we got ours to work!  Good Luck!

      Michael S. Kelsen
      mcnc!ge-rtp!ge-dab!kelsen
      kelsen%ge-dab.GE.COM@mcnc.org

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 15:21:02 EST
From:      cruff@scdpyr.UUCP (Craig Ruff)
To:        comp.protocols.tcp-ip
Subject:   Re: Life after source quench

In article <3083@psuvax1.psu.edu> ehrlich@psuvax1.psu.edu (Dan Ehrlich) writes:
>In article <8711081434.aa25516@Huey.UDEL.EDU> Mills@UDEL.EDU writes:
>> ...
>>HOST : 128.117.8.7 : (unlisted - who is this USAN dude?)
>>20:26:43 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2]
>
>I do not know who [128.117.8.7] is but [128.118.28.2] is

128.117.8.7 is an IBM 4381 here at NCAR running Spartacus KNET software.
-- 
Craig Ruff      NCAR                         INTERNET: cruff@scdpyr.UCAR.EDU
(303) 497-1211  P.O. Box 3000                   CSNET: cruff@ncar.CSNET
		Boulder, CO  80307               UUCP: cruff@scdpyr.UUCP

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 16:27:27 EST
From:      BILLW@MATHOM.CISCO.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   ARP and various things other than ethernet....

Note that it is not necessary for the hardware address of a host to
be larger than the software address in order for ARP to work.  There
isn't any reason why ARP can be used, more or less as-is, for any
hardware network having a broadcast concept...

Bill Westfield
cisco Systems.
-------

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 16:38:56 EST
From:      abc@brl-adm.ARPA (Brint Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: smtp on Symbolics lisp machines

In article <353@vilya.UUCP> rhk@vilya.UUCP (KENSICKI) writes:

| Does anyone have any expierence running tcp on Symbolics 3640's
| and 3675's ?
 
| Any thoughts would be appreciated.

Send a note to slug@r20.utexas.edu.  

Surely someone there can help you.

_Brint
-- 
Brint Cooper

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 17:36:44 EST
From:      hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  Life after source quench

There can't really be two sets of root servers.  The problem is that
when a server doesn't know the answer to a question, it generally
sends a response that refers the questioner to the root.  Bind
processes such responses by adding all the data they give to its
cache, and then posing its question again.  (The hope is that some of
the data just added will let it find the answer this time.)  So if the
official root servers point to any other servers that even indirectly
ever refer us to a server that lists the bogus root servers in a
response, we will eventually end up with the bogus root servers in our
cache.  Furthermore, the problem is contagious, because now we will
refer other people to talk to us to you as a root server.  I don't
doubt that there are still bugs in our named (although I think it is
better than any of the released versions).  But it doesn't dream up
name servers out of whole cloth.  I believe you are seeing a
combination of a bug that causes unreasonably large rates of name
server requests, with the fact that somebody has referred us to you as
a root server.  Thus you get caught in the crossfire between us and
the roots.  Tonight I'm going to spend some more time inside named.  I
have found a number of pieces of code in it already that are
non-functional.  I suspect I'll find another one or two tonight.

(Definition: When I use the term "bogus root name server", I mean any
name server that claims to be a root name server, which is not listed
as one by SRI-NIC when we ask it who the root servers are.)

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 19:06:00 EST
From:      Kastenholz@MIT-MULTICS.ARPA
To:        comp.protocols.tcp-ip
Subject:   RPC/NFS over IP Routers


Does anybody have any experience, rules of thumb, guidelines, etc, about
running the Sun NFS/RPC protocols over an IP gateway/router (e.g.
Bridge GS/n) over a long haul line of any speed (T1, X.25, 9600Baud,
56Kb line, etc)?

The configuration that I am dealing with is a large central site that is
the main file store, with a number of PC's as work stations.  Access to
the file store (VAX 8xxx) will be by RPC/NFS.  Some of the alternatives
that we are looking at are using MAC level bridges to connect the
Ethernets and using a *big* machine to act as a file stager at the
remote Ethernet (e.g.  a Sun) and doing some form of program driven file
transfer from the VAX to the Sun and then RPC/NFS from pc to sun on the
local net.

Please send any replies to me.  I will post a summary in a couple of
days if there is enough.

Thanks Frank Kastenholz ATEX Inc.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 20:53:39 EST
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Idle chatter about reference models

Caveat:  Since this is idle chatter (see Subject:) the words martian, bogon,
	fuzzball, and playpen will not appear in the body of this message.


	My office-mate just received a colorful poster from CMC comparing
a seven-layer DoD Internet reference model to the seven-layer ISORM.  I've
attatched a little chart comparing those two RMs to the old four-layer
ARM [1] for the idly curious.
	The most glaring oddity (aside from typos and a cute phone number)
is the depiction of EGP, GGP and HMP as Transport layer protocols.  When I
expressed my surprise at this to my office-mate he wanted to know where they
did belong (magic-marker in hand).  My instinctive answer was that EGP and
GGP belonged in the Internetwork layer and that HMP belonged in Massachusetts.
	Since I'm just a hanger-on in this field, I was wondering to which
layer the protocol police would assign EGP and GGP (and their descendants).
I would also like to know if the aforementioned ARM has ever been supplanted.


				Mike


1. While displaying an affinity for M. Padlipsky's naming scheme (RFC871),
   the four-layer model to which I refer is the one described by B. Leiner,
   et. al. in "The DARPA Internet Protocol Suite".

--------------------------------------------------------
ISORM		CMCRM			   ARM
--------------------------------------------------------
Application	Application		Application
--------------------------------
Presentation	
		Utility
Session
--------------------------------------------------------
Transport	Transport		Service
--------------------------------------------------------
		Internetwork		Internetwork
				------------------------
Network		Network			Network
--------------------------------
Data Link	Data Link
--------------------------------
Physical	Physical
--------------------------------------------------------

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 21:29:00 EST
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP maximum segment size determination

ORCHARD/BRUC@SCARECROW.WAISMAN.WISC.EDU (Bruce Orchard) writes:
    I propose adding a new option to the IP header.  This option would
    give the minimum of the maximum transmission units of any network
    that handled the packet.  The originating end would set it to a
    large value.  Each node that transmitted the packet would compare
    the value given in the option to the maximum transmission unit of
    the outgoing network.  If the network value were less, the value
    in the option would be reduced to the network value.

This is one of the several options proposed in 	"Fragmentation
Considered Harmful", by Chris Kent and myself, presented at the
SIGCOMM '87 Workshop this past August.  I understood that the proceedings
would be distributed to members of SIGCOMM, but so far I have not
seen anything except the unpaginated version distributed at the
workshop.  Chris and I are preparing a slightly expanded version
which should be available as a tech report sometime in the next few
months.

Although I think this is a great idea (and some day we'll take the
proposal given in the paper and turn it into an RFC) it's not real
likely that it is practical in the IP Internet, given the low likelihood
of changing enough hosts and gateways to make it work.  Instead, we
recommend simply biting the bullet and using 576 bytes whenever you're
not absolutely sure where a packet is going.  576 bytes isn't always
fragmentation-proof, but it's a reasonable compromise.

    P.S.  Is the MTU of SATNET really 256 bytes, as given in IEN 192?

It's probably slightly less.  I've had a hard time discovering the
exact value.

-Jeff

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13-Nov-87 22:45:25 EST
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: Is there an EGP that is available?


    Date: 6 Nov 87 11:43:58 GMT
    From: steinmetz!vdsvax!barnett@uunet.uu.net  (Bruce G Barnett)
    Subject: Is there an EGP that is available?

    If we wanted to run EGP (External Gateway Protocol) on an Internet/mail
    gateway for the purposes of dynamically finding routes to other
    machines, where do we get this program?

    Is the source available? 

    I know that Sun sells it with their DDN SunLink product. 
    What about Ultrix/4.3bsd?

    What are the other protocols available - and what do people recommend?
    Thanks,
    -- 
    	Bruce G. Barnett 	<barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>
    				uunet!steinmetz!barnett

Bruce,

EGP is not a routing protocol.  It is a `reachability'
protocol.  There isn't sufficient information in EGP
to avoid certain routing pitfalls, like looping...

I believe it is FTP'ble either trantor.umd.edu.
The archive is called "gated.tar", and is in the
/pub directory.

The source is in the public domain (I think).

It should be the most current version.  Also,
Phil Karn recently found a minor patch for it that
he claims avoids most of the ARPAnet trauma seen
in the last few weeks, when EGP packets are fragmented
and/or excessively delayed.

His posting was also on TCP-IP.

-Philip

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Nov-87 02:01:52 EST
From:      hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   why Rutgers named has been attacking randomly selected net sites

Rutgers has been running the beta test named 4.7.  One very neat new
features of 4.7 is that it implements a two-level caching scheme.
That is, you can designate 2 or 3 machines as your primary servers.
All other named's are set up to send requests through them.  This lets
you have a small number of well-populated caches, and avoids having
every machine on your network have to interact with the Arpanet.  This
should be a great performance win for the net as a whole.
Unfortunately, this causes a bug that was present as early as 4.4 (the
earliest code we have around now) to have very serious effects.  In
ns_resp, rd is set instead of qr in a couple of places where responses
are generated.  (For those of you who don't have the bits memorized,
rd is used in a query to mean that you are requesting the name server
to handle the request recursively for you.  qr must be set in all
responses.  It indicates that it is a response, rather than a query.
There is no obvious meaning to rd in a response, though the spec does
call for it to be copied from the original query.)  The effect is that
qr is not set in certain responses.  With the two-level cache,
interesting things result.  The original host sends a query to the
primary server.  It eventually gives up, and sends a response back.
But qr is not set.  So the original server things that this is a
query.  It dutifully handles the query, by sending it back to the
primary server.  If you have more than one primary server, each
request generates N more.  The net effect is obvious.  Apparently we
have attacked various more or less innocent servers because of this
bug.  I believe it is what caused the high packet rates that Dave
Mills saw to some otherwise innocent site at NASA.  I just fixed the
problem.  Site running 4.7 should be very careful about this.  I would
think there might also be situations where this bug would cause
trouble even in earlier releases, but I can't be sure.

It is of course possible that I am misunderstanding what this code is
supposed to do, and that I will end up with a very red face.  (This
has happened recently in other contexts.)  But we have definitely seen
the infinite packets, and the seriousness of the problem seemed to
justify broadcasting a warning quickly.

*** ns_resp.c.BAK	Fri Nov 13 23:34:35 1987
--- ns_resp.c	Sat Nov 14 01:09:50 1987
***************
*** 523,529 ****
  			if (debug >= 3)
  				fprintf(ddt,"resp: leaving, MAXCNAMES exceeded\n");
  #endif
!  			hp->id = qp->q_id; hp->rd = hp->ra = 1;		
  	 		(void) send_msg(qp->q_msg, qp->q_msglen, qp);
  		 	qremove(qp);
  	 		return;
--- 523,529 ----
  			if (debug >= 3)
  				fprintf(ddt,"resp: leaving, MAXCNAMES exceeded\n");
  #endif
!  			hp->id = qp->q_id; hp->qr = hp->ra = 1;		
  	 		(void) send_msg(qp->q_msg, qp->q_msglen, qp);
  		 	qremove(qp);
  	 		return;
***************
*** 595,601 ****
  	stats[S_RESPOK].cnt++;
  #endif
  	/* The "standard" return code */
! 	hp->id = qp->q_id; hp->rd = hp->ra = 1;
  	(void) send_msg(msg, msglen, qp);
  	qremove(qp);
  	return;
--- 595,601 ----
  	stats[S_RESPOK].cnt++;
  #endif
  	/* The "standard" return code */
! 	hp->id = qp->q_id; hp->qr = hp->ra = 1;
  	(void) send_msg(msg, msglen, qp);
  	qremove(qp);
  	return;
***************
*** 617,623 ****
  #endif
  	hp = (HEADER *)(cname ? qp->q_cmsg : qp->q_msg);
  	hp->rcode = SERVFAIL;
! 	hp->id = qp->q_id; hp->rd = hp->ra = 1;
  	(void) send_msg((char *)hp, (cname ? qp->q_cmsglen : qp->q_msglen), qp);
  	qremove(qp);
  	return;
--- 617,623 ----
  #endif
  	hp = (HEADER *)(cname ? qp->q_cmsg : qp->q_msg);
  	hp->rcode = SERVFAIL;
! 	hp->id = qp->q_id; hp->qr = hp->ra = 1;
  	(void) send_msg((char *)hp, (cname ? qp->q_cmsglen : qp->q_msglen), qp);
  	qremove(qp);
  	return;

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14 Nov 87 11:47:57 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        oconnor@sccgate.scc.com
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: idle chatter about reference models

Mike,

    I'd say HMP belonged at the transport layer.  It can be reasonably
neatly dropped into a binary bsd kernel as a transport protocol, and
it has the usual transport functions (transport user addressing, sequence
numbers, etc).

    As for the four level ARM -- I recently argued to someone that we're
approaching five levels:

	     Application
	    [Presentation]
	      Transport
	     Internetwork
	       Network


The argument being that while we have no standard Presentation layer,
we are certainly using presentation schemes (XDR, Courier, ASN.1, multimedia
formats, etc.)

Craig
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Nov-87 12:36:54 EST
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet versions


On the coax there is no differenece electrically between Version I
Version II, and IEEE 802.3.  There is an encoding difference in the
bytes.  The 802.3 uses the two bytes following the source address for
a length field.  The older Ethernet standards use this as a type field
for determining what protocol to use for the rest of the packet.  Most
IP networks these days are constructed using the old Ethernet interpretation
regardless of what kind of transceiver they use.

The difference between the Version I transceiver and the version II
is the presence of the so called "heartbeat" signal or SQE.  What this
does is blip the collision detect line after each transmission.  This
is an added protection for detecting broken transcievers and cabling that
may be jabbering on the net.

The IEEE 802.3 transciever is similar to the Version II transciever, but
has one additional signal state on the collision detect line for something
like MAU (that's what they call the transciever) not ready.  I'm not sure
what anybody does with this (if anything).

Of course, as stated earlier, the various standards call for different
sizes of conductors and grounding considerations, although the essential
signals conductors are the same.

-Ron

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14 Nov 87 16:55:10 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        William Westfield <BILLW@MATHOM.CISCO.COM>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: ARP and various things other than ethernet....
     isn't any reason why ARP can be used, more or less as-is, for any
     hardware network having a broadcast concept...

.. or even any network with a distinguished, well known address, by which you
reach the server(s) that store the address information.  There is no
philosophical need to have the data base distributed to the level that each
host stores only that part of the data base that pertains to it.  However, it
definitely is convenient to have the host in charge of its own data.  

I just wanted to make the point that address FFFFFFFFFFFF is not magic, nor is
broadcast.

    Mike
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Nov-87 15:22:33 EST
From:      scott@boake2.UUCP (Scott Boake)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: TCP/IP source

In article <309@clan.UUCP>, eugen@clan.UUCP (Eugen Bacic) writes:
> I am also looking for the source for a complete PD TCP/IP implemention.  
> I would appreciate any information anyone regarding their experiences
> with Phil Karns implentation.
> 
> Eugen Bacic @ ..!utzoo!dciem!nrcaer!clan!eugen

I am VERY interested in getting this type of software also.  I want to try
to hook up some of the less expensive Ethernet boards (ie. Western Digital)
to other machines running TCP/IP, RFS, NFS, etc.

If you have any software / technical notes / books / RFCs / etc. to point
me in the directions please mail them!  Or tell me where / how I may obtain
them.  (If they are books and you have the ISBN # handy, please include it.
That makes ordering books MUCH easier!)

Scott
----------
Scott Boake					Small Systems Consulting
+1 813 544 - 8152				P.O. Box 2142
						5030 - 78rd Ave North Suite 10
..!peora!codas!usfvax2!jc3b21!boake2!scott	Pinellas Park, FL 34665

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Nov-87 16:03:36 EST
From:      stan@gcylab.UUCP (Generally useless individual)
To:        comp.protocols.tcp-ip
Subject:   STD BUS Ethernet Card


From: rpics!gcylab!stan (Stanfield Smith) 516-294-7170

Sorry if this is the wrong net for this subject, but I need help to
locate a manufacturer of an ethernet card (similar to the 3C501) for
my standard bus system.  If anyone knows of such a manufacturer, I
would really appreciate the information.  At this point I will even
settle for the name of someone who is merely thinking about offering
such a product.

Stan

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14-Nov-87 19:36:27 EST
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet routing problems

Phil,

I recommend that you get on the EGP-PEOPLE mailing list.  Send request to
'egp-people-request@bbn.com'.  Your problem first had a fix announced there a
year ago February (that's 1986).

I would have restricted this note to a private answer, but I want to suggest
that anyone else reading TCP-IP and operating an EGP gateway get on the
EGP-PEOPLE list also.

    Mike

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Nov-87 02:20:44 EST
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  Telephone Access Controllers (TACs) and SLIP...


	From: dlw%opal.Berkeley.EDU@violet.berkeley.edu (David Wasley)

	... The protocol would be to "log in" to the system (validation
	and all that) and be given an IP address & mask for the duration
	of the session. After that, it is all IP until carrier drops.
	Is there a well defined, documented protocol for this initial
	dialogue?

Not as far as I know; but I had something like this in mind when I
rewired Rick Adams's version of SLIP for 4.3BSD.  That is why slattach
waits `forever' in a sigpause(): to find out about carrier loss.  If
you are a client of some dialup IP server, you might want to redial
automatically.

(Those of you with 4.3BSD source can look at /usr/src/etc/slattach.c to
see how the attach works.  It should be easy enough to write dialup and
protocol code that would run first.)

	How would you deal with dynamic name/address mapping?

I will leave this one for others.

Chris

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Nov 87 11:35:35 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Cc:        dlw%opal.berkeley.edu@violet.berkeley.edu, billw@mathom.cisco.com
Subject:   dial-up SLIP

At CSNET we're experimenting with an idea which is close to this.

The basic idea is that when an IP packet hits our gateway destined
for a remote machine  we make a phone call, establish the link, and
keep it running as long as there is continued traffic.  When the
traffic stops, we shut down the line.

There are lots of nasty little problems in this scheme:
    
    - The TCP SYN takes a huge hit for establishing the phone call.
    So the initial RTT estimate will be much too high.

    - Topology.  That SYN probably can't take multiple hops in which
    the phone gets dialed.  (We're using a star topology with gateway
    in the center).

    - How to maintain line quality.  We know how variable long-distance
    connectivity is.

Interestingly, keeping track of when the line is busy probably isn't a
problem (we already had to handle that problem in X25Net).

Also note that this system is designed to support more than IP.  We want to
be able to use more than IP over the interface (line control packets, ISO IP,
XNS, etc).  So we had to put leaders in.

Finally, address mapping is fixed.  Each address is assigned, and we
do a deterministic IP address to phone # mapping to do the phone call.
We then log in at the remote end, and start up the line protocol.

Craig
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Nov 87 11:38:09 -0500
From:      Robert Hinden <hinden@PARK-STREET.BBN.COM>
To:        "Michael J. O'Connor" <oconnor@SCCGATE.SCC.COM>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Idle chatter about reference models
Mike,

I enjoyed you reference to HMP being in the "Massachusetts" layer.  It
might be more accurate to say that it is in the Massachusetts "stack" :-).

I do think it is correct that is should be shown as a transport layer
protocol.

EGP, GGP, and other similar internet protocols provide services
normally thought of as in the transport [, presentation ?] and
application layers.  The output of these protocols are used to provide
routing data for the internet layer.  I don't think that this puts
them in the internet layer.

Bob
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Nov-87 09:36:22 EST
From:      mshiels@orchid.waterloo.edu (Michael A. Shiels)
To:        comp.protocols.tcp-ip
Subject:   Gateway protocols and RFCs and uses for them


Does anyone have a table of the different gateway protocols and the appropriate
RFCs for them??  And also a list of whos hardware/software uses the different
ones.

If some one can send me the RFC table I can compile a list of the hardware/
software based upon e-mail to me.  I am trying to get some PC gateway
software running and would like to implement any gateway protocol that
is needed to interact with most other software.

Thanx.

-- 
  Michael A. Shiels (MaS Network Software)
  mshiels@orchid.waterloo.EDU
UUCP: ...path...!watmath!orchid!mshiels

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Nov-87 11:24:48 EST
From:      slevy@UMN-REI-UC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  Telephone Access Controllers (TACs) and SLIP...

Is dynamic IP addressing necessary?  Rather than having the dialled-into
system pick an address for its caller, how about if the caller asks
for a particular IP address and authenticates itself with, say,
a password?  That same calling host would always ask for the same address.
The name-address association could be permanent, only the connections 
would be temporary.

				Stuart Levy, Minn. Supercomputer Center
				slevy@uc.msc.umn.edu, 612 626 0211

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Nov 87 17:47:11 -0500
From:      haverty@CCV.BBN.COM
To:        Robert Hinden <hinden@PARK-STREET.BBN.COM>
Cc:        "Michael J. O'Connor" <oconnor@SCCGATE.SCC.COM>, tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM
Subject:   Re: Idle chatter about reference models
To throw mny two cents in...

I think HMP isn't "in the stack" at all, in the sense that it is NOT part
of a user data communications activity.  HMP is an application top level
protocol, between an entity at one end, i.e., the monitoring/management
operation, and an entity at the other end, i.e., the piece of code down within
some computer somewhere that is watching the activity within that computer
and interacting with the management site.  IN other words, the participants
in HMP are just like any other network users such as FTP or a data query
and retrieval system; it just happens to be the case that their activity is
associated with the operational management of a communications system.  Consider
for example if an HMP-like protocol were used to monitor the CPU-load and
disk-activity of a distributed collection of Unix systems, i.e., like
a constantly running remote "dpy" or "ps". In this case it's pretty clear that
the protocol between the players is an application in itself; HMP differs only
in that it is looking at the operation of components of a data communications
system.

Jack

PS to Dave Mills -- I do "read the mail" on the list all the time, just
a little slow in diving in.
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Nov-87 19:23:00 EST
From:      IO71241@MAINE.BITNET.UUCP
To:        comp.protocols.tcp-ip
Subject:   INFO

PLEASE SEND ME INFO ON TCP/IP PROTOCOL

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Nov 1987 19:23 EST
From:      MIKE BEAL <IO71241%MAINE.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   INFO
PLEASE SEND ME INFO ON TCP/IP PROTOCOL
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15-Nov-87 20:11:26 EST
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Terminal server efficiency


How important is the offered TCP window size for Ethernet
terminal servers?  

Our Bridge LS1 terminal server offers a maximum window size
of 164 bytes.  Our Micom terminal server offers a 384 byte
window.  The small window forces our computers to send a full
screen update as many small packets instead of fewer larger
packets.  It seems to me that this is expensive in terms
of CPU bandwidth both for the connected computer and any
intervening gateways.  What do people think?  Is this important?

Here's some data.  I logged in to a 4.3BSD computer, read a 7
screen file (154 line, 10430 byte) with unix 'more' and logged out.
In all cases the terminal baud rate was 9600.  "Total packets"
includes those necessary to log in and give the commands.

Terminal           software      Max Offered        Total packets
attached to        version       rcv window         (both ways)

Bridge LS1         13000          164                481
Micom NTS-100      V1.3-AC        384                241
VAX 750            4.3BSD        4096                159


Our Micom NTS-100 is running software that is still in beta test.
The production software offers a 320 byte window.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Mon 16 Nov 87 05:52:46-PST
From:      Kirk Lougheed <Lougheed@MATHOM.CISCO.COM>
To:        saturn!eshop@JADE.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Terminal server efficiency
Jim -

The TCP maximum segment size, the number of data bytes that can be sent in a
single TCP segment, probably dominates the efficiency considerations of the
terminal server test you describe.  When sending large amounts of data to a
terminal server (display editors, parallel and serial printers), you want to
have each TCP segment to be as large as possible.  Window size would be of
secondary importance.

A reasonable default maximum segment size is 536 bytes (IP's "minimum
maximum" of 576 less 40 bytes of IP and TCP header).  If the two hosts are
on the same physical cable, it is reasonable to negotiate a maximum segment
size closer to the MTU of the cable.

Such extremely small maximum segment sizes and offered window sizes probably
indicate a lack of memory in the terminal servers.

The ability to piggy-back acknowledgements is an even more important
efficiency consideration for terminal servers. If you use Telnet with remote
echoing and don't do piggy-backing, sending a single character packet
results into two packets being sent back (the echo and the acknowledgment)
which in return generates a responding acknowledgement.  Four packets.  If
you can do piggy-backing, you can get the number of packets per character
down to three (slow typist) or even two (fast typist).  That assumes of
course that you aren't employing some strategy to put more than one character
per packet.

I recommend reading Clark's RFC 813, "Window and Acknowledgement Strategy in
TCP" for more details on how TCP implementations can be more efficient.
That will allow you to ask all sorts of potentially embarrassing questions
of your vendors.

Regards,
Kirk Lougheed
cisco Systems, Inc.
-------
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 08:13:23 PST
From:      Mark Crispin <MRC@PANDA.COM>
To:        Welch%OSU-20@OHIO-STATE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Telnet options
Arun -

     I have never seen those Telnet options, but I may have an explanation.
The DEC-20 Telnet service as distributed by DEC (and earlier versions from
BBN) has a number of bugs including some which may cause incorrect Telnet
protocol to be sent.  I wrote a long series of fixes for these bugs, but to
my knowledge only STL-HOST1, SIMTEL20, and DREA-XX are running the full set
of fixes.  Other sites are running earlier, half-assed versions of these
fixes or none at all.

     Most unfortunately, the authors of certain programs have decided to
exploit certain of these bugs to intentionally send Telnet protocol from an
application without Telnet service being aware of it.  It's partially
because of this problem that I've been unable to convince Stanford TOPS-20's
to adopt these fixes.

-- Mark --
-------
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Nov-87 05:34:54 EST
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP maximum segment size determination


Bruce,

    Last week I volunteered at the IETF meeting to write a proposal for
just such an IP option.  You should see it within a couple of weeks
(seeing it implemented may take a while longer...)

    By the way, the scheme is sound even if the path changes if you
treat the IP option and the TCP MSS values as distinct.

    I.e. in the TCP MSS you should advertise the maximum segment
size you wish to accept and the remote end should keep this value
and separately keep track of what IP reports.  You would use the minimum
of the two MSS's reported when sending. Then if you get an indication
that the route has changed (such as an ICMP redirect), you can send the
IP option again, and update the effective MSS (up or down).  There's
still the problem of packets following different paths -- this may
have a solution but I'm still looking for something that doesn't feel
like a kludge of a three way handshake.

Craig

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Nov-87 05:49:20 EST
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: new Arpanet end to end protocol

Charles,

Your message is quite wrong (I know - I designed the new
End-to-End).  I would be interested in knowing (in private) who
your "reliable source" is, so that such rumors can be source
quenched.  After the recent messages on the tcp-ip list, I'm sure
we all realize how important source quenching is.

The truth of the matter is:

PSN 7.0 has two different End-to-End protocols (old EE and new
EE).  Either one or the other runs at any particular time, and
the two cannot interoperate.  The ARPANET is currently using PSN
7.0 with the old EE.  It is the new EE that will be tested on
Nov. 7, 14-15, and 18.

The old EE protocol explicitly returned, across the PSN subnet, a
separate RFNM packet for each message delivered to a destination
host.  This RFNM packet was then converted, in the source PSN,
into the 1822 RFNM for that message and delivered to the source
host.  This had the result that, depending on traffic mixes,
roughly about 45% to 50% of the packets going through the subnet
were RFNMs.  Since the PSN does so much per-packet processing,
even for these RFNMs, the network was passing much less host
traffic than otherwise might be possible.

We fixed this in the new EE by making it an explicitly windowed
protocol IN THE SUBNET.  The destination PSNs have the ability to
aggregate ACKs (the new EE internal equivalent to RFNMs) and send
multiple ACKs for the same connection in windowed ACK (by using
an INTERNAL message sequence number).  In addition, these ACKs
can now be piggybacked on data traffic, and many ACKs for
different EE connections can be shipped together in the same
subnet packet to a source PSN.

The important thing to note is that when the destination PSN
receives an ACK for a connection, it generates, and sends to the
source host, a separate 1822 RFNM for EACH and EVERY message
submitted by the host and being acknowledged by the ACK.  There
are no host-visible sequence numbers; the 1822 protocol stays the
same as before.

What may have confused you is the fact that we at BBN are,
concurrent with the PSN 7.0 testing, trying to track down which
ARPANET hosts might be affected by a known BSD 4.2 network
software problem that may cause RFNMs to be lost in the host
itself (I believe it is related to the size of the message
received PREVIOUS to the RFNM).  This bug has been fixed in BSD
4.3, and I have been told that Lars Poulsen of ACC
(lars@acc.arpa) has a patch for BSD 4.2-derived host software.

By the way, we have measured in our internal BBNNET (which has
been running PSN 7.0 with the new EE only for over five months
now) that only about 14% of the packets through the network only
contain ACKs - the rest of the ACKs are being piggybacked on the
data traffic.  We are very pleased with this result.  Also, most
of our BBNNET hosts (around 125 C/70s, VAXEN, TOPS-20s, TACs, and
others) use 1822, and they have had no problems with the new EE.

Regards,
Andy

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 10:06:43 PST
From:      minshall@violet.Berkeley.EDU
To:        Arun <Welch%osu-20@ohio-state.arpa>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Telnet options
Arun Welch,

I don't know what the options are.  I suspect they were invented by
your Dec box.

That the Dec box would invent an option is a bit depressing; however,
that your Xerox box should die when presented with an unknown option
is even more depressing.  The standard response to DO FOO (where
FOO is unknown) is WONT FOO - and that should be the end of that.

Greg Minshall
-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 11:19:31 -0500
From:      caloccia@nisc.nyser.net
To:        Mark Fedor <fedor@nisc.nyser.net>
Cc:        nsfnet@nnsc.nsf.net, tcp-ip@sri-nic.arpa, caloccia@nisc.nyser.net
Subject:   Re: Strange returned mail.

my guess is that it is an expansion of some list that 's gone bad.
the site looks like NTA in Norway (nta.no) -- my guess would be tcp-ip.
--bill

    

    	I just received about 7 messages like the one that follows.
    	I'm clueless as to why I got them.  I never tried
    	to send to this place.  Is this another one of those
    	unsolved network mysteries?

    	Any answers?  clues?

    	Thanks.

    	Mark

    ------- Forwarded Message

    Return-Path: postmaster%odin.re.nta.uninett@TOR.NTA.NO
    Received: by nisc.nyser.net (5.54/1.14)
    	id AA08642; Fri, 13 Nov 87 12:13:14 EST
    Date: Fri, 13 Nov 87 16:43:08 +0100
    Posted-Date: Fri, 13 Nov 87 16:43:08 +0100
    Message-Id: <8711131543.AA10354@tor.nta.no>
    Received: by tor.nta.no (5.54/3.21)
    	id AA10354; Fri, 13 Nov 87 16:43:08 +0100
    To: fedor@nisc.nyser.net
    From: UNINETT-ARPA Gateway <postmaster%odin.re.nta.uninett@TOR.NTA.NO>
    Subject: EAN Mail Network -- failed mail
    Status: RO

    Mail Failure Diagnostics:
    Rejected-Message-id: <8711060340.AA17823@nic.nyser.net>

    Message Recipients:
       baard@vax.elab.unit.uninett: maximum time expired

    ------- End of Forwarded Message

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87  08:47:52 CDT
From:      MARK%UNLCDC3.BITNET@wiscvm.wisc.edu, (Mark Meyer, UNL Computing Resource Center (402)472-5434)
To:        tcp-ip@sri-nic.arpa
Subject:   Post offices for PCs in a network
I am interested in solutions to the problem of have a bunch of PCs
on our campus local net which want to send and receive mail.  Obviously,
they should send mail to some server (or post office) and receive mail
back from it.  I know that POP exists and there are some other ad hoc
solutions.  Can anyone write up a concise but systematic description of
the current and most feasible solutions, please?
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 09:19 EST
From:      David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
To:        Kastenholz@MIT-MULTICS.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: ARP on FDDI
    Date:  Mon, 9 Nov 87 17:57 EST
    From:  Kastenholz@MIT-Multics.ARPA

    There is a rather simplistic solution to the 16 vs 48 bit FDDI address
    problem - assign two physical hardware types to FDDI - one for 16 bit
    addresses and one for 48 bit addresses.

    This may violate some underlying deep philosophical intent of ARP, but
    it looks like it should work.

If being the author of ARP means anything after four years...  The type
hardware types sounds completely reasonable to me.  From the scant
readings I've seen about FDDI, it seems that there are really two
distinct versions (one with 16 bit addresses and one with 48) and they
cannot coexist on the same cable, lest they confuse each other.  Even if
they do/could coexist, I see no reason they shouldn't be considered
separate for the purposes of ARP hardware type.

It is also possible and allowable to dispatch off of both the hardware
type and the hardware length, provided there is only one possible
semantics after the last dispatch.  I suspect many implementations,
including the ones I've written, only dispatch off of the hardware type
and check the length for consistency.

From this 5 minutes of thought, I would opt for two hardware types,
perhaps called FDDI-16 and FDDI-48.

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 10:12 EST
From:      Kodinsky@MIT-Multics.ARPA
To:        Kastenholz@MIT-Multics.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: ARP on FDDI
Hi Frank,

I got some replies to my question.  They reminded me that the ARP
message uses variable length fields





-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 10:18 EST
From:      Kodinsky@MIT-Multics.ARPA
To:        Kastenholz@MIT-Multics.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: ARP on FDDI
Hi Frank,

My terminal died in the middle of the last attempt.  What people told me
was that there is a length field in the ARP message format.  And that
ethernet also has a 16 and 48 bit address length.  Anyway I found out
that ARP is an expected thing in the TCP world.

Thanks for your note,

Jim
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 10:32:43 EST
From:      John Owens <OWENSJ%VTVM1.BITNET@wiscvm.wisc.edu>
To:        TCP-IP Discussion List <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: ARPANET<->MILNET problems
>I have had a very similer problem making contact to a host inside
>of the berkeley network. Same horrible round trip times and
>loss rates. It puzzles me because our contact with ucbarpa and
>ucbvax (both arpa sites) is fine, but the contact with the site
>inside the berk-net is rotten.

>Perhaps related: I also have not been able to make contact with
>univ. of Wisc hosts, yet have easy contact with cs.wisc.edu.
>(again directly on the arpanet)

It definitely looks like a routing problem, since the networks you
can't reach (internal campus networks) have high numbers, and the
hosts you can reach are on the low-numbered ARPANET (10).  It's as
if the core gateways are only keeping routes for a certain number of
networks.  (Possibly the ones you can't reach are in the new second
fragment of the EGP update, as mentioned earlier....)
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      16 November 1987, 10:52:56 EST
From:      Jacob Rekhter <YAKOV@ibm.com>
To:        tcp-ip@sri-nic.arpa
Subject:   Node updates versus Link updates
I'd like to solicit some comments on the following issue:

"What are the advantages/disadvantages of using both Node
State Updates and Link State Updates versus using just
Link State Updates for Adaptive IP Routing ?"
Notice, that I do not propose to completely ignore all
metrics associated with a node, but rather to reflect
conditions on the node in Link State metrics.
Many thanks in advance for all who will reply.
Jacob Rekhter (YAKOV@IBM.COM)

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 11:19:22 EST
From:      fedor@d.nyser.net (Mark Fedor)
To:        atina!mrecvax!tron@uunet.uu.net, tcp-ip@sri-nic.arpa
Subject:   Re:  ICMP redirect messages. How to send ?

	Hi.  If I remember correctly, while poking through
	the Ultrix Networking code, there is no support
	for ULTRIX 1.2 (and I think 2.0) to SEND ICMP_REDIRECTS.

	Although you could hack it in, I suppose, but if you are
	going to do that you might as well go 4.3BSD....

	Good Luck....

	Mark Fedor
	NYSERNet, Inc.

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Nov-87 11:31:04 EST
From:      montnaro@sprite.steinmetz (Skip Montanaro)
To:        comp.protocols.tcp-ip
Subject:   Re: Life after source quench

In article <8711091811.AA23668@uxc.cso.uiuc.edu> kline@uxc.cso.uiuc.EDU
(Charley Kline) writes:
>I'm sure that the reason that the fuzzball is issuing quenches every
>thirty seconds is because if only one quench is sent, IP throttles back
>to one packet every 500 milliseconds (which should keep the fuzzball
>happy), but when the 30 second quench reaction stops, IP starts
>vomiting the packets full blast again, which causes another quench. I'm
>pleased that the quench mechanism creates such effective data rate
>communication between an IP module and IP gateways.
>
>I can't take credit for the method, it's an implementation of Postel's
>proposal. I only messed with the parameters.

I'm no whiz at anything related to TCP/IP (although I find this group
interesting, if not necessary, reading), but this seems like a
situation that calls for either

1. Some hysteresis. Is it wise (correct?) to have the start quench and
stop quench thresholds be the same?

2. Finer granularity. Given the rate at which most machines can spew
out packets, 500 milliseconds sounds rather coarse.

Skip (montanaro@ge-crd.arpa or uunet!steinmetz!sprite!montanaro)

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Nov-87 11:31:32 EST
From:      mark@applix.UUCP (Mark Fox)
To:        comp.unix.questions,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   STREAMS pipe driver

I just heard about this beast from someone with SVR3 sources. Apparently,
AT&T implemented this as a replacement for FIFOs but in their wisdom decided
not to document it.

Since we have processes that communicate with other processes on the
same machine as well as with others on remote machines, we need the
equivalent of Unix-domain or loop-back sockets. As you might expect,
we need to be able to multiplex input from local and remote processes. Now
an idle process could pend reading its FIFO and field SIGPOLLs. But a "more
elegant" approach, it would seem, is for a process to pend on a blocking
select (er, poll :-) system call awaiting messages from any process, local or
remote, that wants to talk to it. This is where a STREAMS pipe driver fits in.

Is the latter approach reasonable? Are people porting the pipe driver?
Is anybody willing to provide me with or post documentation on how to use it?
I have the Streams Programmer's Guide but I don't have a Unix source
license :-(

Thanx!
-- 
                                    Mark Fox
       Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300
                    uucp:  {ames,rutgers}!harvard!m2c!applix!mark

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 11:51:47 EST
From:      Mills@UDEL.EDU
To:        "James B. VanBokkelen" <JBVB@ai.ai.mit.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  TCP maximum segment size determination
James,

SATNET MTU = 256 octets last I heard. Some packet radio systems have MTU a
few octets less than this. I know of no system with MTU of 128 octets.

Dave
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 14:56:29 PST
From:      postel@venera.isi.edu
To:        tcp-ip@sri-nic.arpa
Subject:   re: telnet options

 ----- Begin Forwarded Message -----
 Date: Tue 10 Nov 87 16:55:23-EST
 From: Arun <Welch%osu-20@ohio-state.arpa>
 Subject: Telnet options
 To: tcp-ip@sri-nic.arpa

 Could someone tell me what telnet options 32 and 94 are, and which
 RFC's are associated with them?  We've got a host (a dec-20 running
 tops) which is returning them, causing my workstatio (a xerox 1186) to
 lose... I couldn't find them anywhere in Assigned Numbers or in the
 DDN Handbook.

...arun
----- End Forwarded Message -----


There is no authorized use of Telnet option codes 32 or 94.  However, your
workstation should not "lose".  It should be able to decline any telnet option
it does not understand, even if that option is not previously known.

--jon.
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 14:57:56 PST
From:      postel@venera.isi.edu
To:        tcp-ip@sri-nic.arpa
Subject:   datagram vs reliable

By definition a "datagram" can not be reliable or guaranteed.

See the Introduction section of the Internet Protocol specification, RFC-791.

--jon.
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 12:00:36 est
From:      vwhite@nswc-g.ARPA
To:        BIG-LAN%SUVM.BITNET@wiscvm.wisc.edu, TCP-IP@sri-nic.arpa, cdaniel, cdjohns@k30b, dfutche, drose, snorthc
Responses to Request for Information

13 November 1987

A couple of months ago, I sent out a request for information about
PC networking software that would link IBM AT compatibles with Unix
minicomputers over TCP/IP.  Responses are still coming in to that
request.  However, here is a synopsis of the replies to date.

Based on our research, to which these replies greatly contributed,
we are leaning toward a NetBIOS solution, with 386s running Xenix and 
minicomputers running Unix variants as servers.  We are looking at
NetBIOS over TCP, but intend to investigate NetBIOS
over OSI in the future.   We now testing several products in house;
should the test results prove unsatisfactory, we will probably
recommend Sun's NFS as a fallback solution.

We've heard several opinions, some of which we can't quote here, that
NetBIOS has a highly questionable future.  However, we have seen
a great number of vendors providing NetBIOS based applications 
software and NetBIOS over TCP boards.  Many vendors are working
on RFC (1001, 1002) compliant versions of their products.
We know that the Air Force ULANA procurement for
Unix systems requires a NetBIOS interface be provided within one
year of award.   We know of both baseband and broadband boards which 
support NetBIOS, giving us greater latitude in our implementation.   

We've also heard opinions that users won't really be happy with
a virtual drive, as they need the pure DOS environment for
some applications and the pure Unix environment for others.  Those
who espouse this belief prefer to connect the environments with
telnet and ftp.   We agree that this might be the best for some situations,
especially in scientific and engineering communities.  In fact, most
of those who liked this solution were operating in exactly that kind
of environment.  However, our community consists of a large number of
business users who don't have much computer experience and don't have 
the time or inclination to learn a complex user interface.  Our direction 
is to find something as transparent as possible for them.  With that 
direction, we are continuing the quest for the virtual drive.

We are also still following up on replies to our original posting
and on other leads.  We welcome further input and will post a second
synopsis later if there is sufficient interest.

Thanks to all who contributed.

Vicky White
vwhite@nswc-g.arpa
703-663-7745

-----------------------------------------------------------------------
From suneast!hinode!geoff@Sun.COM Thu Sep 10 13:38:53 1987

You need to talk to us about PC-NFS. It provides:

Transparent file sharing using NFS, currently supported on Sun,
 Pyramid, VAX and many other systems.

Transparent print service, including access from existing applications.

Telnet, FTP, rsh and rcp utilities.

Use of TCP/IP over IEEE802.3. Ethernet cards supported currently are 
 the 3Com 3C501, U-B NIC and Micom-Interlan NI5010; others are to
 be added in the next release.

There is also a Programmer's Toolkit which provides full emulation
of the 4.2BSD network programming environment (TCP & UDP sockets)
plus Sun RPC/XDR and Yellow Pages.

Geoff Arnold
PC-NFS Architect
Sun Microsystems East Coast Division
2 Federal St.
Billerica MA 01821

617-671-0317

ARPA: garnold@sun.com

-----------------------------------------------------------------------
From usrey@gold.bacs.indiana.edu Fri Sep 11 16:14:28 1987

At indiana Unuversity we have a broadband cable plant that joins most of the
buildings on a very large campus. We have an ethernet channel on that system
that attaches mosts mainframe and mini's along with most PC LANs. The mini's
are mostly vaxes with Ultrix or VMS and the PC LANS are mostly ethernet based
running Novell. The PCs on the lans can access the hosts via tcpip programs
OR attach to a Novell server but is isnt too smooth switching between the two
applications. If you would like more detail regarding our network then feel
free to contact me.

Terry R. Usrey
usrey@gold.bacs.indiana.edu
------


-----------------------------------------------------------------------
From @wiscvm.wisc.edu:TS0400@OHSTVMA.BITNET Thu Sep 10 16:20:24 1987

We are solving this problem as follows. Banyan servers are connected to
PC Lans, via either ethernet or token ring (both are supported). The servers
provide a very friendly user interface, and transparent file and print
access. The internal Banyan mail is not smtp-compatible, but we have
contracted with them to provide an smtp gateway function in the server that
will act as a post office and hold all PC mail until needed. That will be
available to us for testing in about 2 months, and after we accept it, Banyan
will sell it to everyone.
 In the meantime, tcp/ip software from FTP, Inc can be put in the PCs which
supports smtp,ftp and telnet directly to the PC, with the server acting as
a passthru device. The server is connected to the existing tcp/ip ethernets
we have, on a separate port from the PC LAN. FTP, inc software will be RFC
compliant in the near future. Banyan will be integrating it into their
product more in the future so that FTP and Telnet will also be transparent
eventually and ftp, inc software will no longer be required on each PC.

                                           Bob Dixon
                                           Ohio State University

----------------------------------------------------------------------------
>From pcip-request@louie.udel.edu  Thu Sep 17 16:37:54 1987 remote from nswc-g

  Banyan says that in a few months their server will provide tcp/ip functions
to PC users on the LAN as if the users were on a mainframe. The server has a
single IP address, and maps Banyan-style operations into tcp/ip operations
when dealing with the outside world. For example, users create mail with the
normal Banyan-specific menu syntax, etc but when required by its address, the
mail is forwarded by the server to the internet as smtp. Incoming mail
carries the internal Banyan address as the "user" portion and the server
adress as the "host" portion of the internet mail address. The server acts as
a post office and holds the mail until requested by a PC user.

                                            Bob Dixon
                                            Ohio State University

-------------------------------------------------------------------------
From @WISCVM.WISC.EDU:TS0400@OHSTVMA.BITNET Fri Oct  2 16:02:36 1987

It is true that the Banyan server talks to the PCs using VINES protocol,
over either ethernet or token ring. However, as seriees of developments will
incorporate tcp/ip into that.
1. As of today ( I have it running in my own PC ) you can buy a version of
   FTP, Inc tcp/ip PC software which will coexist with VINES. That means
   that the server can be connected to an external tcp/ip network and the
   PC user can use the FTP, Inc software for telnet, ftp, etc just as if he
   were not in a Banyan network at all.
   It is not integrated into the Banyan menus, etc but it works fine.
2. You can buy (and we are, but don't have it yet) a program called LAN
   SHELL that enables the FTP stuff to be incorporated into the menus.
3. Banyan says they are incorporaring the FTP software into the server
   so that individual copies of FTP stuff would no longer be needed.
   Supposedly this year, but who knows for sure.

    A medium size Banyan supports about 25 users. They have 4 sizes for all
   needs. I have heard about the VAX plan and it sounds great, but nothing
   concrete yet. I can communicate fine with VAXes now with the tcp/ip
   software, but that does not give shared files, etc as the VINES thing would.

                                                Bob

----------------------------------------------------------------------------
From @wiscvm.wisc.edu:BEAME@MCMASTER.BITNET Wed Sep 16 11:54:21 1987

Hello,
      NetBios IS the way to go for current PCs, but I have been talking to IBM
about the network interface in OS/2 and they responded that they still don't
know what communications are going to look like in the extended OS/2.

      NetBios over TCP/IP is the way to go. Bridge Communications (now part of
3Com corporation) has a PC board (PCS-1) which has TCP/IP, TELNET and RFC1001,
RFC1002 compliant NetBios. This solves everything but the mail problem. I
beleive the RFC for PC mail can be easily implimented and interfaced to the
TCP/IP available on the PCS-1 card as well as on a unix or Ultrix system.

      My firm is also working on an RFC compliant NetBios which uses the 3Com
EtherLink board. If you have time to wait, several companies are currently
working on compliant NetBioses. But as to an OS/2 version, only time (about
1 year) and IBM will tell.


    Carl Beame
    Development Analyst,
    McMaster University
    BEAME@MCMASTER.BITNET


----------------------------------------------------------------------------


I realize that this is long after the fact but maybe this will be
useful.

I manage end-user computing activities at DARPA and have (over the
past two years) been through an evaluation and procurement process to
put all DARPA personnel on a local net gatewayed to the Internet.  The
system we chose is currently being installed.

We chose 3Com hardware and 3+ software although developments between
the time the RFP was drafted (approx. one year ago) and now would lead
me more towards something that I would expect to mature into a true
NETBIOS over TCP/IP product.  Deciding when to freeze specifications
was the toughest part of the procurement, in retrospect it would have
been better to have been more general in our specification to take
advantage of developments that occurred during the procurement cycle.

As part of the procurement we specified an optional 3Com <-> Internet
gateway.  This has been proposed but there is an associated
development cycle, it should be delivered around Feb. 1988.  The
proposed solution looks like it might work (Wollongong on a Microvax)
but I am withholding judgement until I see it.

We chose 3Com primarily because of Mac support in addition to PC
support and ethernet, we would have rather had something based on the
DoD protocol suite, of course, but could not find any commercial
offerings.  Our user base is approximately 120 PC's and 50 Macs, the
Macs population is growing faster than the PC population although we
passed one workstation per user (some have both and we also have users
who have machines at home) some time ago.  We had an existing IEEE
802.3 cable plant and that influenced our decision heavily (it is
already gatewayed to the Milnet and Arpanet).  Also, money was not so
much an issue as capabilities and speed.

I would be happy to give you more details on the things we have found
if you would like, I am not certain that a system the size of ours can
be scaled to one twenty times its size but it seems like your
objectives are similar to ours.  Let me know if I can provide
additional information.

Glen Foster

----------------------------------------------------------------------------
From vwhite@nswc-g Thu Oct  1 10:11:14 1987

Glen,

Thank you very much for your information.  I think your situation
is very similar to ours, despite the difference in scale, and you
may be able to give us some useful advice.

You said you wish you had something that would evolve into a
NetBIOS over TCP implementation.  Why do you want this instead
of one of the nonNetBIOS products now available, like pcnfs or
PC-Interface from Locus?  Do your applications really need the
NetBIOS interface?  What are the advantages of NetBIOS?  Do
you think it is the up and coming standard and will win out
over competitors like nfs or pc-interface?  We just aren't very
clear on these questions and would like to have the opinions
of somebody else who's been there.  I realize that pcnfs, at least,
was not available when you made your purchase, but if you were
doing it today, what would you do?

Are your PCs clustered closely together or spread out over
a wider geographical area?  How many do you put on one 3com
server?

Do you just use the 3com mail program? Will your gateway transfer
that to internet mail?  We already have a lot of minicomputers
using smtp and must have a way to get the PCs to talk mail to
them from the outset.

Thanks for the help; I think we can learn a lot from you.  If
it would be easier to talk about it over the phone you can
give me a call or send me your number.

Vicky White
(703) 663-7745
vwhite@nswc-g.arpa

----------------------------------------------------------------------------
From gfoster@vax.darpa.mil Thu Oct  1 19:06:03 1987

Vicky,

I hope I can remember your questions, my main mail box is on a.isi.edu
but they are flakey and went down in the middle of my reply (twice!)

I think NETBIOS will be big (if OS/2 is big), I have seen a couple of
nice applications running on PC databases over NB (dBASE and Paradox).
When NB servers become multi-tasking in a standard way (OS/2) I think
we will see more developers writing applications that are truly
distributed.  3Com has stated that they are moving in that direction,
I met with them this morning and learned a good bit -- the bad news is
that they are not going to do much with TCP/IP on PC's.

I have PC-NFS on my desktop PC (actually an AST Premium 286) and have
been using it more lately than 3+.  I am becoming more and more UNIX
oriented though and can not be considered an average user.  It has
some bugs that may make it difficult for non-technical users.

We are all in one building, spread out between floors and have a thick
cable ethernet running in the phone closets from the first floor to
the twelfth (where the computer room is).  (We actually have two
running parallel but that is another story.)  To hook up the PC's, we
are using thin cable segments repeatered to the trunk, like:

                PC     PC
                |      |
  ----T-------------------
      |
      R
      |
======T======================T==================================
                             |
                             |
                             R
             PC              |
             |               |
        ---------------------T--------

T = transceiver, R = repeaters, PC = you guessed it

We hope to get away with no more than two thin segments per floor but
are pushing it on the length spec.  The servers will be cabled to the
trunk with their own transceivers and xcvr cables so that if a user
trashes his cable he doesn't take down the whole net.  We have found
some repeaters that will automagically isolate either side of the
cable if it is shorted or open.  (American Photonics) We have had some
embarrassing outages using Xerox repeaters when the thin cable was
accidentally opened.  These were reasonably easy to diagnose and
repair but we only had three segments, it would be a real pain if we
had a lot of places to look.  Ethernet attachment hardware is a joke,
both thin cable and transceiver cable attachments are major headaches
and can easily be detached by a vacuum cleaner or curious user.  (I
know how to handle this, it's just like my VCR!)

We are figuring 10-12 users per 3Server (u/3S), we want very high
performance and aren't as concerned about the cost.  If we were
worried about the cost I would go to 20-25 u/3S in our environment
(mostly office automation -- word processing, spreadsheets and
communications) and I think we could handle up to 40 u/3S if we had to
and still have reasonable hard disk response.  By reasonable I mean
about as fast as an XT hard disk or maybe a little faster.  If I were
putting hefty dbms applications on, I would start at 4-6 u/3S and add
them one at a time until we got a problem.  I would definitely get the
cache card with more than 15 u/3S (and probably will anyway).  I would
never, ever try to use a concurrent workstation/server, Ctrl-Alt-Del
is too ingrained in PC users' minds.

The mail gateway is supposed to take mail intended to go off-site and
format it to RFC821/RFC822 etc. specs and then dump it back on the
ethernet where it will be picked up by the gateway.  Locally we will
use 3+ mail and 3+Mac mail with hoped-for user transparency.  Sure
hope it works . . .

I forget your other questions, give me a call if you want (703)
527-1451.  If you ever get up to D. C. you are welcome to stop in and
see how we have things laid out.  The installation should progress now
through Nov. 20th.  We took a trip over to the Census Bureau early on
in our evaluation and it was very enlightening.  NSF is also scoping
out PC nets and you might be able to get some pointers from them.

Good luck,
Glen

----------------------------------------------------------------------------
notes from phone coversation with Glen Foster 10/5/87:

Reiterated that 3com was chosen primarily for Mac connection;
also, they seemed most agreeable to customizing to Darpa's 
environment.  He says Novell gave lip service this but wouldn't
really get down to brass tacks; his opinion is "Novell is market
driven company, 3Com is technology driven" (have we heard that
somewhere before?)

Says NFS and similar products which have come down to PCs from
minis don't take advantage of all the features of a pc; tend to
treat them like dumb terminals; ignore alt key, function keys;
also require more knowledge and sophistication from user; products
which originate from PC side are more PC user friendly, but
don't always provide services desired (like ftp or smtp)

Their vendor (Management Systems Designers of Vienna) is going
to provide an smtp gateway for them (in 90 days); they'll use
3Com mail on the lan

He suggested we talk to Census Bureau and NSF for further ideas.
I attempted to contact both but have been unsuccessful so far.

-vew

-----------------------------------------------------------------------
From as-pln-bf@HUACHUCA-EM.ARPA Fri Oct  9 18:51:51 1987

You might be able to get the info you are looking for from the engineers
that are at the Army Small Computer Engineering Center (SCEC).  They are
very sharp on networks etc.  Their DDN address is USASCEC 'at' SIMTEL20.ARPA.


-----------------------------------------------------------------------
From USASCEC@SIMTEL20.ARPA Wed Oct 28 12:42:56 1987

  Sorry for the late response - most of our folks have been TDY.  I'm afraid
that we're not going to be able to provide much help to you, since we preach
the use of OSI standards - right now we're using TP4 instead of TCP/IP, and
we are not going back.  If you want to know how to do what you intend to
with TP4, we can tell you more.  Basically, we support MS-NET protocols on
802.3 LANs, using PC hardware from either Ungermann-Bass or Intel.  We have
XENIX (Intel 310/320) and UNIX(Sperry 5000/80) based servers, implementing
the Intel developed OpenNET protocols(compatible w/ MS-NET).  Our servers
have the capability to connect to the DDN (X.25) and SNA world.  The most
important detail is that all the above equipment is available from
standard Army contracts.  Also, the next major office automation procurement
will be for systems that connect to that same LAN.  The Navy and DLA are
going in with us on that one, so although it will be an Army contract,
it looks as if ALL DoD agencies might be able to order from it.  In case
you don't know about it, the AF tends to support TCP/IP protocols.  You
might check with them if you're stuck with that.
  -- CPT David Anselmi
     AV 879-8247/7450
--------------------------------------------------------------------------


notes from phone conversation with David Anselmi
9 Nov 87

They have Intel's OpenNet, which is Netb on iso; PCs can be file and
print servers, though for performance not recommended; for servers 
they are using the Intel 310 (a 286 system) and 320 (a 386); says with
their workload, he recommends no more than 8 users to a 386 server, though
it's supposed to support 12.  

has virtual drive; virtual terminal service; file upload/download; can
use menu interface for all interaction, including system administration; 
performance good except he doesn't like the menu
interface and prefers to use direct commands

for mail they log into the server over ethernet or rs232; mail available
only to and from the servers; technically feasible to do it to PCs,
but they didn't; no SMTP; OpenNet mail;

have run network DBASE III over this and it's okay;

hasn't tried other NetBIOS networks here (like IBM PC Net or Network OS)
but thinks they ought to work

no mac support

They are hoping to buy minicomputers: Sperry
5000/880, to support up to 64 users; no advance info on actual performance;
(note: requiring POSIX conformance there); will run Unix V.2 with OpenNet;
not yet available.  Minis should service PCs just like their Intels. award
expected sometime 88 (June-Aug-Sept); other DoD may be able to buy off it.

now have a Sperry 5000 which is their DDN gateway for ftp and telnet; 
working on mail interface; also have a tcp, ddn gateway on an Intel
320; this Intel can also support a tcp lan in addition to the iso
lan; 

not going to specify x.400 yet; will do it later

tcp to iso companies: 1)Retix, Santa Monica
		      2)Sydney, Vancouver

----------------------------------------------------------------------------

From mcc@etn-wlv.eaton.com Fri Sep 11 10:14:41 1987

Vicky, Dan, et. al.:

If you can get access to the Request For Proposal (RFP) and the vendor propos-
als for LONS, RAPIDE, UTAIN/MAIS, and ULANA; you may find some of the answers
to the questions that you have raised.  

LONS and its predecessor LONEX (Local Office Network Experiment) are probably
more in line with what you want to do.  LONEX has been operational since the
early 80's at Rome Air Development Center (RADC), Griffiss AFB and has links
to and facilities at Hanscom Field and Wright-Patterson AFB.  This message is
being generated from home on a Tandy 2000 linked to the LONEX development and
maintenance network at EATON IMSD in Westlake Village, CA which is also linked
into RADC-LONEX.ARPA.

LONEX was originally designed for a broadband with dedicated links to Hanscom
and Wright-Patterson; however, the broadband has been replaced with Ethernet
and the dedicated links are being replaced by the MILNET.  The original plan
was to support a large number of users using VT100 or VT100 compatible term-
inals; however, that is also changing with many of the organisations using
LONEX replacing them with PC's.

PC's are not as fully integrated as you would like and generally use terminal
emulation packages to interface with the network.  I, personally, use the
Softronic's SoftermPC package on which I have implemented a seamless disk
capability so that disks on the network look like local hard disks to my PC.
I can tell you from experience it can be painful--applications developed for
MS-DOS choke if you have to use UNIX pathnames to get to your data.  For
some silly reason they attempt to parse switches whenever they see a "/".

Anyway, the LONEX system runs on anything that can run on any processor that
supports 2.9bsd or 4.3bsd.  It goes "boom" on System Vanilla.  It supports
several of the more popular spreadsheet programs and databases and depending
on the size of your spreadsheets moves the processing to more appropriate
machines.  Users in essence always execute from their home processor regard-
less of where they may be and for the most part its transparent to the user.
If you normally work at Hanscom but are temporarily at Wright Patterson, you
may notice some latency. (This feature is probably the biggest reason why
there hasn't been a stronger hue and cry for more fully integrating PCs into
the system.  As long as you can get to a TAC, you can work on your reports
from anywhere in the world.  You don't have to lug the PC along and if you're
forced to fly commercial, you avoid the hassle at customs where they try to
extract the import duties on your PC).

Enough this.  Request a tour and briefing from RADC to determine if it is
useful and to find the pitfalls.

Merton Campbell Crockett		mcc@etn-wlv.eaton.com
AN/GYQ-21(V) Program			mcc%lonex@etn-wlv.eaton.com
EATON Information Management Systems
31717 La Tienda Drive, Box 5009
Westlake Village, CA 91539

----------------------------------------------------------------------------
From perry@vax.darpa.mil Fri Sep 11 15:46:42 1987

My understanding from the folks at RADC is the LONEX is going away, an
no further enhancements are allowed to the system.  I wonder what
they are moving to?

dennis
----------------------------------------------------------------------------

From sms@radc-lonex.arpa Sat Sep 12 17:22:05 1987
>My understanding from the folks at RADC is the LONEX is going away, an
>no further enhancements are allowed to the system.  I wonder what
>they are moving to?
>
>dennis
>-------
>
	As a 'founding father' of the LONEX system here are my two (and a
	half) cents worth...

	The rumours do persist of LONEX's departure, primarily coming from
	those who are responsible for the successor system.  The system
	that was supposed to have replaced LONEX is almost a year and a
	half behind schedule and does not even come close to providing
	the services and capabilities of the present system.  This isn't
	the place i suspect to delve into the shortcomings/etc of the
	respective systems, if anyone wants my perspective drop me a line
	(obviously it leans towards the current system).

	The LONEX contract runs thru March 1988 at least, so we'll be here
	for a while yet.  Enhancements are being quietly done, major changes 
	are not allowed on a production system.

	Besides, as Jerry Pournelle says (loosely remembered)
	"Last year's state of the art is today's production system".

				Steven M. Schultz
				sms@radc-lonex.arpa
				(usually sms@etn-wlv.eaton.com)
	todays 

----------------------------------------------------------------------------
From mcc@etn-wlv.eaton.com Sat Sep 12 17:46:20 1987

Dennis:

The operational system to replace the experimental system is LONS and that
is the official line; however, I think there is a great deal of resistance
at the LONEX user level.  I'm not sure what the final configuration of LONS
is going to be; however, one component seems to be a single VAX system that
provides the same user services provided by the array of PDP11/44, PDP11/70,
and VAX systems used ithe LONEX system.

While LONS is the "official" system, I doubt that LONEX will disappear in
the near future.  You have a large group of users that are familiar with the
facilities of LONEX.  Experience at EATON indicates that it is very easy to
move secretaries whose primary use of the system to prepare letters and mem-
orandae from one system to another but it is quite another to move people
that use a system for preparing technical documentation and proposals part-
icularly if these documents are going to be modified and reproduced over a
period of time.  In essence, the "old" system will not be replaced until a
catastrophic event occurs--because no one wants to spend the money to con-
vert all the data from the formats required by the "old" system to that re-
quited by the "new" system.

Merton Campbell Crockett

----------------------------------------------------------------------------
From perry@vax.darpa.mil Sat Sep 12 18:06:16 1987

Merton, I had heard the LONEX was going to go away because I had
asked the RADC people to fix lonex so that, at least on there system,
mail send to an individual would include who is on the 'cc' line.  I
wanted to make certain that eveyone involved in the discussion was
being copied.  Lonex apparently cannot do that.  It sends out mail
with blank cc lines and I do not know who else got the message, nor
can I answer to everyone.  If lonex is going to be around, this would
be a good thing to fix.  The RADC peole say that this would be a major
change to the guts of the system and will not be done.

dennis

----------------------------------------------------------------------------
From mcc@etn-wlv.eaton.com Sat Sep 12 18:58:53 1987

Dennis:

I'm a little confused.  The LONEX Mail Facility does indicate who the cc:
recipients are on each message when you display the message.  Of course,
there may be some slight differences between the RADC and EATON versions.
A definitive answer can be gotten from Steven M Schultz (sms@etn-wlv.eaton.com)
currently on location (sms@radc-lonex.arpa) about any differences.

Merton Campbell Crockett

----------------------------------------------------------------------------
From perry@vax.darpa.mil Sat Sep 12 19:14:14 1987

Merton, we made a test, and at least the RADC lonex does not include
any names on the cc line.  It does indeed send copies of the mail
to those indicated on the cc lines of the lonex user who generates
the mail, but the mail that is sent out does not include that 
information.  Instead, lonex generates a mail message to everyone
as if they were the only one getting the message.

dennis

----------------------------------------------------------------------------

>From mcc@etn-wlv.eaton.com Sat Sep 12 22:10:03 1987
>
>Dennis:
>
>I did a few tests in response to your last message.  The behaviour of the
>LONEX Mail Facility is very dependent upon where the mail originates.  When
>the mail is originated from the LONEX Mail Facility, all recipients of the
>message will be displayed with the exception of the bcc: recipients.  When
>the mail is received from the in-house ELIS system, the bcc: recipients are
>displayed as well--for some reason that system includes the bcc: in all
>message headers.
>
>When the message originates on the DDN, only the addressee, originator, and
>the individual forwarding the mail appears.  If there are multiple address-
>ees in the To: line or any recipients in the Cc: line, the information is
>lost.  The problem is at the transition between the two mail systems.  The
>problem is the mapping between the two header formats; however, I shouldn't
>think it is that substantial a problem to fix.  Steve Schultz probably can
>give the best estimate of the changes required.
>
>Merton

--------------------------------------------------------------------------
Merton, Dennis, Dan, Vicky, 

	Guess it's about time i got in the act what with my name being
	mentioned (i felt my ears burning, so i figured someone was
	talking about me).

	RE: the '>'d stuff below:

	The 'problem' with the LONEX mail system not generating Cc: lines
	quite right was only brought to my attention a few weeks ago and
	since then there has been precious little time to look into it
	in detail.  Now that i know 1) that there is a problem and 2)
	that somebody cares(?) i will attend to it.  Don't hold your breath
	(people turn blue that way) but eventually i'll get it patched up.

				Steven M. Schultz
				(sms@etn-wlv.eaton.com normally
				 right now i'm TDY at "sms@radc-lonex.arpa")
P.S. Even with its problems, the LONEX mail system can send/receive mail
     from the DDN, something that LONS can not at the present do.
-----------------------------------------------------------------------
>From mcc@etn-wlv.eaton.com Sat Sep 12 22:10:03 1987
>
>Dennis:
>
>
>When the message originates on the DDN, only the addressee, originator, and
>the individual forwarding the mail appears.  If there are multiple address-
>ees in the To: line or any recipients in the Cc: line, the information is
>lost.  The problem is at the transition between the two mail systems.  The
>problem is the mapping between the two header formats; however, I shouldn't
>think it is that substantial a problem to fix.  Steve Schultz probably can
>give the best estimate of the changes required.
>
>Merton

--------------------------------------------------------------------------
29 September 1987

Merton, Dennis, Steven:

Thank you for responses about the LONEX system.  We have some
questions:

It sounds as if the primary function of LONEX is
keeping most of the processing on a larger system,
away from the PCs, but is doing load balancing to share
the work among several such larger systems.  Are we on the
right track?  How about the supported spreadsheet and database 
programs; are they implemented on the server or the PCs? 

Where is the mail delivered?  Do users have mailboxes on the
server?  (It doesn't sound like mail is delivered directly
to the PC.)  Can users send mail from the PC or must they
do so directly from the server?  How about printing?  Must
the user queue print jobs from the server or can he do so from
the PC?

Why are these terminals and PCs connected to your larger systems
via an ethernet?  Most of the implementations we've seen in
which PCs accessed servers only as terminal emulators use asynchronous
connections; it's cheaper and can handle the requirement.  Is
LONEX offering a service that makes the ethernet important?  (perhaps
those database programs are distributed database servers?)

You said LONEX runs on 2.9bsd or 4.3.  Did you mean, in addition,
anything in the middle?  How about vendor implementations of 4.2 such
as those of Pyramid or CCI?  What software is required on the PC?

Do any of the other packages you mentioned (RAPIDE, UTAIN/MAIS, or ULANA)
implement a file server?  If you could describe them briefly we might 
know whether it was worthwhile to go looking for more information.

Thanks for the help!  We want to learn as much as we can
from other people before we make any decisions.

Vicky White
Code K33
NSWC
Dahlgren, VA  22448
(703) 663-7745
vwhite@nswc-g.arpa

--------------------------------------------------------------------------

From sms@etn-wlv.eaton.com Tue Sep 29 19:48:32 1987

Vicky, Dennis,

	Good to hear from you again.  I'm back from the East coast
	(not by choice, i think upstate NY is nicer than So. Cal.).

	I've bracketed my responses in lines of ===== below.

				steven m. schultz
				sms@etn-wlv.eaton.com
------------------------------------------------------------------------
>
>It sounds as if the primary function of LONEX is
>keeping most of the processing on a larger system,
>away from the PCs, but is doing load balancing to share
>the work among several such larger systems.  Are we on the
>right track?  How about the supported spreadsheet and database 
>programs; are they implemented on the server or the PCs? 
======
	Correct, mostly.  The 'system' at Griffiss AFB and Hanscom (Bedford MA)
	consists of 16 'mini'computers - 14 PDP-11/44s running 2.9BSD
	and two VAX-11/750s running 4.3BSD (the system in Westlake Village CA
	has two PDP-11/44s and 1 VAX-11/750).   The QCALC spreadsheet program
	is a corehog, users on the PDP-11s run QCALC thru a servor over the
	ethernet.  The database we have (although not too many users choose
	to learn it) is UNIFY and that runs directly on each processor (PDP-11s
	included).
======

>
>Where is the mail delivered?  Do users have mailboxes on the
>server?  (It doesn't sound like mail is delivered directly
>to the PC.)  Can users send mail from the PC or must they
>do so directly from the server?  How about printing?  Must
>the user queue print jobs from the server or can he do so from
>the PC?
======
	The mail is delivered to a users home processor (queued if need
	be until it comes up), i.e one of the PDP-11s or the VAX (at
	present only special users are allowed on the VAX).  DDN mail
	(and yes, i've a fix to our incorrect mail headers due to be
	released Real Soon Now).  I am a  little confused at your mention
	of 'servor', perhaps it's a semantic nit, but i view them more as
	'hosts' or 'home processors' since that's where the files, etc
	reside.  
	Printing can be done from any processor to any printer in the
	network via the spooling system that runs on the hosts.
======
>
>Why are these terminals and PCs connected to your larger systems
>via an ethernet?  Most of the implementations we've seen in
>which PCs accessed servers only as terminal emulators use asynchronous
>connections; it's cheaper and can handle the requirement.  Is
>LONEX offering a service that makes the ethernet important?  (perhaps
>those database programs are distributed database servers?)
======
	Umm, sounds like something got mangled in transmission... You're
	quite right in that the terminals and any PCs present are connected
	via serial lines (DH11 or DMF32) and the PCs run terminal emulators.
	The ethernet is used for the hosts to communicate on, not for terminals.
======
>
>You said LONEX runs on 2.9bsd or 4.3.  Did you mean, in addition,
>anything in the middle?  How about vendor implementations of 4.2 such
>as those of Pyramid or CCI?  What software is required on the PC?
======
	A qualified 'almost yes' to this one.  If/when I can convert
	completely to TCP/IP as the communications package (perhaps possible
	with 2.10BSD) instead of the homerolled XNS variant presently in
	use THEN LONEX should run on any BSD (i've a low tolerance level
	for System Vanilla) originated Unix.  

	The present system has much larger numbers of 16bit machines than
	32bit machines, so the PDP-11s have been where the software was
	primarily written and tested before porting to the VAXen.

	All of the 'applications'/'user programs' in the LONEX system DO
	run with just recompilation on 4.3 or 2.9 as the sources are identical.
	I'm sure  there are machine dependencies left even after running 'lint',
	but they should be fairly easy to squash. 

	At present the placement of some of the local directories and files
	is hysterical (oops, historical) and should be changed, this would
	make for easier merging with other versions of Unix.

	The most commonly used software for the PC is a good VT1XX emulator
	with Kermit or Xmodem.
=====
>
>Do any of the other packages you mentioned (RAPIDE, UTAIN/MAIS, or ULANA)
>implement a file server?  If you could describe them briefly we might 
>know whether it was worthwhile to go looking for more information.
>
>Thanks for the help!  We want to learn as much as we can
>from other people before we make any decisions.
=====
	When Merton gets back from Germany he can try to answer this one,
	i'm not very knoweledgeable about the other programs you mentioned,
	keeping a network here and two back east hanging together plus
	whatever tweeks the software needs seems to be enough activity for
	me.

	It appears to me that you are looking for a system that is oriented
	around PCs rather than CRTs, or have i missed something?  I think
	Merton mentioned in one of his items that PCs at present are not
	tightly integrated into LONEX (not too suprising, LONEX effectively 
	predates PCs and the government did buy/lease an awful lot of VT1XX
	and VT2XX terminals), beyond file transfer capabilities.

	Hope this answers more questions than it raises, feel free to
	ask for clarification on any mud i wrote.

	Later...

				steven m. schultz
				EATON IMSD
				31717  La Tienda Dr.
				MS 228
				Westlake Village CA 91359

				sms@etn-wlv.eaton.com
=====

--------------------------------------------------------------------------
From timk@ncsa.ncsa.uiuc.edu Fri Sep 11 11:13:42 1987

Vicky,

At the National Center for Supercomputing Applications, we are facing the
same types of connection problems that you mentioned in the note which
was forwarded to the ARPANET tcp-ip mailing list.  We have looked at most
of the alternatives you have, and have gone through several steps which
you may want to learn from.  We have Suns, Vaxes, Alliant, Silicon Graphics,
and a Cray XMP.  We access them from PCs and Macs with TCP/IP.

1. Transparent file systems to Suns and other minis are not as valuable to
   PC users as you might think.  We use local hard disks and convenient
   ftp service.  LANS, like Novell, which provide file services without
   involving the minis, would be more attractive, though we don't use any.
   (substitute "large workstation" for minicomputer if you like)

2. The most important thing for us has been powerful terminal access to the
   larger computers.  We developed our own because the available ones were
   not powerful enough.  File transfer is next most important.

3. Try our TCP/IP package for PCs and Macs.  I am appending our old release 
   information, the new version will support new Ethernet boards, have
   Tektronix graphics emulation and several more new features (October 1).

4. We have "rigged" solutions which I am willing to discuss, which cover the
   mail and printing parts of your requirement list.  We are planning to work
   on "proper" solutions to these problems in the next year.

5. Most of the people I talk to lean toward PC-NFS when choosing the commercial
   versions.  My personal opinion is that they are solving the wrong problem.

Good luck in your search, give me a call if it will help (217)244-0638.

Tim Krauskopf
National Center for Supercomputing Applications (NCSA)
University of Illinois

timk%newton@uxc.cso.uiuc.edu  (ARPA)
14013@ncsavmsa                (BITNET)

Fact Sheet
----------

National Center for Supercomputing Applications presents:

NCSA Telnet for the PC, version 1.1
NCSA Telnet for the Macintosh, version 1.1

These programs are copyrighted, but distributed in binary form with 
no license fee.  Source code is not available.  We are exploring the
possibility of distributing linkable libraries which support TCP/IP.

Description:
-----------
NCSA Telnet for the PC is an MS/DOS application which enhances
communication with other computers over Ethernet.  It uses the DARPA
standard TCP/IP protocols, giving the PC access to all of the
machines on the ARPANET and NSFnet.  The basic framework consists of
the standard telnet with an FTP server built-in.  During a telnet
session, you can initiate an FTP session from a remote host and
transfer files to and from your PC, in the background.  NCSA Telnet
provides a virtual terminal, emulating a VT100, which can connect to
any telnet host on the network.  A unique multiple session capability
makes this multiple virtual terminals by allowing you to log in to
several machines at once, or one machine several times, with each
session completely separate from the others.  A simple keystroke
switches the screen display from one session to the next.

NCSA Telnet for the Macintosh takes these basic features and adds
support for the user interface that Macintosh users expect from Mac
applications.  Each session is displayed in a different window,
Macintosh menus are used throughout, desk accessories are supported,
and text can be copied from a session window to the clipboard.  With
a large screen, such as the Macintosh II's displays or the Radius
display, several simulataneous VT100 screens can be viewed at the
same time without overlapping windows.

Development of NCSA Telnet began in August of 1986 in an effort to
improve microcomputer access to NCSA's Cray XMP supercomputer and the
various other workstations connected to our local networks.  Our
local Ethernet supports VAXes, Sun workstations, and an Alliant FX/8,
which can all be reached from a PC, using NCSA Telnet.  Shortly after
the original implementation on the PC, we decided to port the code to
the Macintosh for use over Appletalk, through a Kinetics Appletalk to
Ethernet gateway.  These programs have been in constant use at NCSA
since January, 1987 and are still undergoing improvements.


Features included in version 1.1 of NCSA Telnet:
-----------------------------------------------
DARPA standard telnet 
Built-in standard FTP server for file transfer
VT102 emulation in multiple, simultaneous sessions
Class A,B and C addressing with standard subnetting
Each session in a different window (Macintosh)
Tektronix 4010 graphics emulation (Macintosh)
Supports Croft gateway, i.e. KIP (Macintosh)
Capture text to a file (PC)
Full color support (PC)

How to obtain:
-------------
1) Anonymous FTP from   uxc.cso.uiuc.edu   in the NCSA subdirectory.

The PC version is a tar file which contain binary files.  After the
files are extracted from the tar file, some binary transfer (e.g.
kermit) should be used to download the files to the PC.  The
Macintosh version is several files encoded with BinHex 4.0.  Download
them with a similar transfer method (kermit) and use BinHex 4.0 to
extract the files.  Printable documentation is included with each
version; the Mac documentation is in MacWrite format.  After
downloading, you may copy the files as often as you wish, unmodified,
in binary form, with the copyright notices intact.

2) With appropriate communications software, the program and documentation
can be downloaded over phone lines from the University of Illinois EXCEL
bulletin board.  The phone number is (217)333-8301 and it operates at
300,1200 and 2400 baud.  For the Macintosh version your communications
software must support the MacBinary protocol.  Kermit or Xmodem can be
used to download the PC version. (available 7/8/87)

3) On-disk copies, with a printed manual are available for $20 each, which
covers handling and postage.  Orders can only be accepted if accompanied
by a check made out to the University of Illinois.  Send to:

NCSA Telnet orders (specify PC or Macintosh version)
152 Computing Applications Building
605 E. Springfield Ave.
Champaign, IL 61820

Hardware required:
-----------------
PC: IBM PC, AT or compatible. 3COM 3C501 Etherlink board.
	Support for other boards planned, which would you require?
	Upcoming:  Ungermann-Bass, IBM, MICOM NI5210

Mac: Macintosh Plus, SE or Macintosh II.  
	Kinetics, Inc. FastPath, EtherSC or the new SE Ethernet board.
	Kinetics gateway software or Stanford KIP (Croft) gateway software.

The best source of information about Kinetics is directly from the company.
Kinetics Inc.                     FastPath approx. $2500
Suite 110                         EtherSC approx. $1250
2500 Camino Diablo                educational and volume discounts
Walnut Creek, CA  94596
(415) 947-0998

Other questions:
---------------
mail to telbug%newton@uxc.cso.uiuc.edu

=============================================================
notes from phone conversation with Tim Sept. 11 87:

Tim's reasons for not wanting a pc-nfs like solution are:

	1)their users don't want it; they have a heavy need
	to use the Cray directly and do the work there; converting
	these files from Unix to DOS or the other way around is
	just too much trouble.

	2)It is not, in his opinion, good computer science.  
	He says, if you really want an nfs-like environment, get
	something from a PC lan manufacturer like Novell.  They can
	do it better because that's all they do; they aren't trying
	to do a bunch of other things in their operating system
	like Unix is.  Therefore the design is cleaner and has 
	fewer problems.  If you just want file transfers without
	necessarily the tranparency of nfs, a telnet-like program is
	better. (same reasons: less overhead, less to do, cleaner
	design)  He likes separating the worlds of big machines
	and pcs, and thinks you get
	better vendor support and happier users that way.

By the way, I guess many of you knew this, but he says smtp
has a retrieval facility (like the POP mail facility) but it isn't well
known and isn't implemented in Berkeley.  

They have tried 3com and Unix on Suns.  They wrote their own telnet
application with a built in ftp which he actively promotes; try it/you'll
like it.  Why did they do that instead of using an existing implementation?
Try it and we'll see how much better theirs is.  

They are moving toward POP.  They want to avoid a simple smtp on a PC
since it requires leaving the PC on overnight.

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 15:36:20 PST
From:      mcc@etn-wlv.EATON.COM (Merton Campbell Crockett)
To:        PAP4@ai.ai.mit.edu, tcp-ip@sri-nic.arpa
Cc:        pcip@louie.udel.edu
Subject:   Re:  IP encapsulation over ARCnet
Saw the message once--didn't need to see it again.  I don't know which is worse-
-messages taking forever to traverse the network or receiving the same message
twice.  Why don't we make all message traffic slow (Electronic Snail) and then
eliminate the redundancy feature.

Perhaps I should "biff n" to avoid the "Noyed".  Maybe we should add a new
item to the TCP/IP jargon list:

	Noyed (n):  duplicate message or packet.
	Annoyed (v): the feeling one gets when one receives a noyed.

Merton Campbell Crockett
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 1987 1704-PST (Monday)
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        tcp-ip@sri-nic.ARPA
Subject:   re: TCP maximum segment size determination
Craig Partridge writes (regarding the use of a "probe" mechanism
to find out the real MTU of a path):

    By the way, the scheme is sound even if the path changes if you
    treat the IP option and the TCP MSS values as distinct.

I would amplify this: any mechanism to discover MTUs should be viewed
as an IP-level mechanism, available to all protocols (not just TCP).

TCP, in turn, should already be asking the IP layer "what is the largest
appropriate MTU for this connection/destination/path?" and then never
sending anything larger.  This can be done in the absence of any new
protocol, and is in fact approximately what is done in 4.3BSD (except
that there the layering is somewhat blurred, in that the TCP code goes
and looks directly at the interface MTU, rather than asking IP via
a nicely abstracted interface.)

Craig is also right that if the MTU changes during a connection (e.g.,
because the route changes) then it should be possible to adapt.  However,
instead of using his proposed mechanism (as I understand it) of:
	TCP receives redirect
	TCP initiates new probe
	TCP updates MSS
I would instead keep most of this at the IP level
	IP receives redirect (or "time to re-probe" timer expires)
	IP initiates new probe
	IP receives probe info and passes new MTU to TCP analogous to
		what it does with a source quench
Thus, TCP only has to accept MTU values from IP, not manage the protocol
of obtaining them.

If packets are traveling along paths with different MTUs, and the
rate at which paths change is faster than 2*RTT, then perhaps it should
be possible to recognize this and simply stick with the lower (lowest)
MTU rather than try to second-guess what is either an oscillating or
load-balancing gateway.  How often does this happen, though?

I think it's important to realize that we should be able to obtain
moderate improvements in the likely cases without having to try for
optimal behaviour in the general case.

-Jeff
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 1987 1714-PST (Monday)
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: TCP maximum segment size determination
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") writes that
    If gateway gurus saw their way clear to do so, they might help some
    fraction of the world by arranging that IP fragments aren't transmitted
    consecutively (if there is other traffic to handle) or by inserting a
    little time delay if the Ether or other non-serial media is idle.

Alas, this doesn't work if there's another gateway further along the
route, since that gateway has no practical way of knowing that two
fragments arriving with a slight delay between them are fragments of
the same datagram.  This gateway will normally "iron out" the delays
inserted previously, especially if there is any queueing delay (say
because the first fragment is huge and the second is tiny).

At Stanford we tried to play a similar game by fixing the gateway
(which was actually one of JNC's prototypes for the Proteon gateway)
between the ARPAnet and our ethernet to delay between any pair of
packets to the same local-wire destination.  If all the gateways
did this, in theory it would work because then no matter what path
the fragments took through the Internet, they would always be spaced
out at the last step.  Unfortunately, this didn't work 100% because
delaying for any reasonable period of time can't guarantee that a
timesharing system (with poor interrupt latency) will always have
time to get ready for the next packet, and because it can always
be distracted by local-net traffic (especially broadcasts and
multicasts).

-Jeff
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 14:25:59 EST
From:      Bill Lee <HZA9%MARIST.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Removal from list
Tcp-ip has been very informative for me, but due to my schedule, I just
don't have the time to read it anymore...so, please remove me from the
mailing list..


Thanx much,

Bill Lee
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 1987 1726-PST (Monday)
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: TCP maximum segment size determination
PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") writes about
the use of an IP header option to probe for MTUs:

    What about the required overhead for gateways and routers to have
    to further inspect each packet?

(1) It should not be necessary to probe on every packet.  All bets
are off, though, if the gateways are (a) oscillating, or (b) doing
loadsharing in a way that creates dramatically variable routes (a
mistake anyway, in my opinion).
(2) A well-designed probe protocol should not cost that much.  Alas,
with IP we are stuck using IP header options, and they aren't that
cheap.  If I were designing the next version of IP ...
(3) Source route already requires such inspection.  (This is not
necessarily an argument in favor of a new IP option, but because of
points #1 and #2 the load should be a lot lower than source routing).

    It could be optimized so that only TCP packets are inspected, but
    still, that would seem to add to the burden of possibly
    compute-bound gateways...
Arggh!  This sort of mechanism should NOT be TCP-specific ... that
makes the gateway logic more complex that it needs to be, it fails
to solve the equally pressing problem with other protocols (anyone
out there having problems with NFS/UDP fragmentation?), and besides,
it's not necessary ... because the source host is the one that decides
when to add the IP header option, it only needs to send the option when
necessary, and the gateways can tell quickly if any options are present.

A final point: if I thought that the best we could do with path-probing
is only "add only a little load to the gateways" then I would be against
it.  The whole point is to
	add a little per-packet overhead
to avoid
	loading the network with retransmissions of lost packets
and hope that the latter outweighs the former.

-Jeff
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Nov-87 17:27:07 EST
From:      brian@casemo.UUCP (Brian Cuthie )
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Microport TCP recommendations

In article <328@idacrd.UUCP>, mac@idacrd.UUCP (Bob McGwier) writes:
> in article <141@ncc.UUCP>, lyndon@ncc.UUCP (Lyndon Nerenberg) says:
> > Xref: idacrd comp.protocols.tcp-ip:1594 comp.dcom.lans:885
> >
> 
> Lyndon:
> 
> I would have thought you knew that Phil's stuff has been ported to
> system V.  Contact Bdale Garbee.
> 
> Bob
>  


How do we get the sys V version of the KA9Q stuff ??   I've been waiting for
a while for a posting that would suggest that it's actually available.  Last
I had heard, it was still in beta test (so to speak).  I'm dying to have it !


Cheers,
brian

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 18:18:15 EST
From:      cam@columbia-pdn (Chris Markle acc_gnsc)
To:        tcp-ip@sri-nic.arpa
Subject:   Who Has Implemented NVDET (RFC 732)?
Folks,

Which vendors, etc. have implemented the Telnet Data Entry Terminal (Network
Virtual Data Entry Terminal or NVDET) per RFC 732?

Chris Markle - cam%columbia-pdn@acc-sb-unix.arpa - (301)290-8100
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 18:26:22 EST
From:      Brad Clements <bkc@clutx.clarkson.edu>
To:        PAP4@ai.ai.mit.edu, tcp-ip@sri-nic.arpa
Cc:        bkc@clutx.clarkson.edu
Subject:   Re:  IP encapsulation over ARCnet


Here are some thoughts on IP fragmentation, odd sizes and IP address resolution.


One important thing to keep in mind is that not all ARCNet cards
support long packets. 

Not all users will know their ARCnet hardware node ID.
In talking to Billy Cox at Datapoint, we discussed wether or not
to implement an 'arp like' system or simply to map the low byte of the
IP address to the node ID. There are arguements for both options. Mr. Cox
made a good point favoring the ARP style solution in that a particular
user (with a given IP address) may need to move to another computer
due to hardware problems but wish to retain his IP address. If hardware
mapping was involved, he could not do this.

Also, it would be nice for the driver to know which Nodes will accept
long packets and which will not.

I suggest something like this:

1) Implement a simple ARP system that allows a node to indicate wether it
   accepts long or short packets.
2) Keep the Hardware Node ID and IP address and long.short packet flag in a table
   with an appropriate time-to-live.
3) Use the table information to fragment (where necessary) packets and deliver
   to the appropriate hardware address.

The table would be built from replies from broadcast packets (destination ID 0)
If two or more nodes responded to an inquiry for a single IP address, a diagnostic could be passed up through the system and the IP addr completely ignored.

For fragmentation and odd sizes, I suggest something like this (stolen ideas)
The first byte after the packet type byte (packet types proposed are 240 for IP and 241 for ARP) would be a mode byte which indicates odd sizes and first/last
packets in a fragmentation.

Bit      7	6	5	4	3	2	1	0
	First	Last				Size2	Size1	Size0

Bits 3 through 5 or don't cares.
	The size bits work as follows:

	Actual Packet Size		Size2	Size1	Size0
	Packetsize			0	0	0
	253				0	0	1
	254				0	1	0
	255				0	1	1
	256				1	0	0

The actual packet size INCLUDES the packet type and the mode byte.
This gives a hardware maximum packet size of 506 bytes.

If bits 0 - 2 are zero, the packet size is what is indicated by the
packet size byte minus the bytes used by the destination ID/Source ID 
and packet length. This would be 3 or 4 bytes for short or long
packets respectively.

If the size bits are not zero, the size indicated in the table above
is the datapacket size not counting destination ID/Source ID or packet length
bytes.

Fragmentation works as follows:
 If a packet does not need to be fragmented 
     a) the destination packet size is big enough to receive the IP packet
     b) the first and last bits are set in the mode byte and the size
	bits are set accordingly.
     c) the packet is transmitted and if the TMA bit is set a SUCCESS
	response is passed up to IP.
 If a packet needs to be fragmented:
     a) the destination either can not accept the entire IP packet
     b) The first bit is set for the first packet, the last bit
	is set for the last packet and neither bits are set for middle
	packets.
     c) If the TMA status is not set on ANY of the packets, the entire
	IP packet is discarded and a FAILURE is returned to IP.
	This assumes a TMA timeout of some kind.

     d) The size bits are set accordingly for each packet transmitted.
For the receiving ARC driver:
If the first and last bits are set:
     A) a single IP packet is retrieved after decoding its size from the
	size bits.
     b) The ip packet is passed up the chain.

If the first bit is set:
     a) an 'mbuf' chain is started, indicating which source ID the packets
	are going to be from. The first packet is copied into the mbuf.

If neither the first nor the last bit is set:
     a) a search is made for an mbuf chain with the same source ID.
	If none is found the packet is discarded.
     b) Otherwise the packet is added to the appropriate mbuf chain.
If the last bit is set:
     a) a search is made for an mbuf chain with the same source ID.
	If none is found the packet is discarded.
     b) Otherwise the packet is added to the mbuf chain and the entire
	IP packet is passed up to IP. 
     c) The mbuf chain is cleared from memory.

Some notes on how this works:
  The procedure assumes that an ARC driver which did fragment an IP packet
  will always transmit the fragments in the proper order before processing
  any other output.

  This allows for other ARC nodes to send IP fragments to the receiver
  while other fragmented packets are being received. This means that
  enough memory must be available for packet reconstruction.

  Finally this assumes that the receiving ARCnet driver will not enable
  receiving unless memory is available to receive the packet.


  An mbuf chain would have a time-to-live within which time the last
  packet must be received. If the last packet is not received the
  entire chain is discarded.

One possible enhancement is to use bits 3 -5 to indicate the number
of ARC packets remaining to be sent. This would allow the receiver
to pre-allocate enough space when the first packet was received, keep
track of sequencing, and ensure that each packet got through. No mechinism
is defined for retransmitting a missing ARC packet, since the source
assumes that once the TMA bit is set the receiver properly received the
packet.

Using bits 3 - 5 would allow an IP maximum size of 8 * 506 = 4048 bytes.

This scheme suggested here was dreamed up in a few minutes and will probably
need modification. I personally feel that some form of ARP should be
support to allow for flexibility. Packet fragmentation and odd size
handling would be easy to handle using the 'mode byte' concept. This
fragmentation scheme relies on the features of ARCnet itself, in that
the TMA must be looked at (with a timeout) and that a single ARC node
will not transmit IP packet fragments out of sequence.
This scheme can be easily implemented under both receive and transmit
interupts.

Brad Clements

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Nov 87 18:28:11 EST
From:      cam@columbia-pdn (Chris Markle acc_gnsc)
To:        tcp-ip@sri-nic.arpa
Cc:        rjs@columbia-pdn@acc-sb-unix
Subject:   Question on ICMP Parm Problem Messages
Folks,

In an ICMP parm problem message one is to return the Internet header and
64 bits of the orginal datagram's data.

What is suggested when the parm problem is a corrupted (eg. 0) IP header
length (IHL) field or IP total length field? RFC 792 doesn't seem to mention
what to do in this case.

In the case of 0 IP total length but good IP header length is just sending the
IP header OK? In the case of 0 IP total length and 0 IP header length is 
just sending the minimum IP header length (ie. 20 bytes) OK?

Chris Markle - cam%columbia-pdn@acc-sb-unix.arpa - (301)290-8100
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Mon 16 Nov 87 18:42:01-EST
From:      Arun <Welch%osu-20@ohio-state.arpa>
To:        minshall@violet.Berkeley.EDU
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Telnet options
Thanks to everyone who responded with info on the telnet options. It
turns out that it was a combination of problems on both ends of the
connection:
1) The tops-20 host was coming up with unknown options for it's own
purposes (apparently a common problem with them).
2) The Xerox host was doing a table lookup on the options, and when it
didn't find the option in it's table, it died.  What it should have
done was respond with a DONT or a WONT...  It should be an easy fix to
incorporate into the code.

Ah well, these are the joys of networking on heterogenous machines, I
guess.


...arun




----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@ohio-state.{CSNET,ARPA}
welch@red.rutgers.edu  (a guest account, but mail gets to me eventually)
-------
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16-Nov-87 20:47:18 EST
From:      OLE@CSLI.STANFORD.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   NetBIOS Compatibility Demo


There will be a NetBIOS Compatibility Demonstration at the 2nd TCP/IP
Interoperability Conference. Several vendors will demonstrate conformance
to RFC 1001 and RFC 1002. The demo will be held on Thursday December 3rd
from 6:30pm to 8:00pm at the Hyatt Regency Crystal City in Arlington, VA.
This demo is open to the public.

Ole
-------

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Nov-87 01:16:29 EST
From:      paulf@umunhum.STANFORD.EDU (paulf)
To:        comp.protocols.tcp-ip
Subject:   fuzzware wanted

Okay, where can I find a copy of the fuzzball code to play with?


-=Paul Flaherty, N9FZX		 | "One Internet to rule them all,
Computer Systems Laboratory	 |	    One Internet to find them,
Stanford University		 |  One Internet to bring them all
Domain: paulf@shasta.Stanford.EDU|	    and in the ether bind them." -ToIH

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Nov-87 04:36:51 EST
From:      swb@TCGOULD.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Slang Glossary


  >A bogon is a particle (alias packet) that transmits bogosity.  I guess it is
  >also a happy accident that it rhymes with Vogon, because the bogus info is
  >frequently offensive and/or destructive.

Happy accident?  Absolutely intentional; the analogy with a particle
came later.  "Vogons may read you bad poetry, but bogons make you
study obsolete RFCs."

  >Gong?  I dunno.  

This is Dave Mills's, derived from "gongfermer".  It's worth asking
him to repost his explanation.
							Scott

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Nov-87 05:04:13 EST
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   new BOF

I am conducting a BOF at the upcoming TCP/IP conference in Arlington VA
called "Standard socket level interface for PC's".  Many vendors now have or
will soon have resident TCP/IP code for PC's, however, there is no standard
interface.  Many of these vendors also have socket-style libraries or
resident code with no standard for which calls are supported or how one
interfaces to them.  The purpose of the BOF is to generate interest in
standardizing a BSD socket style interface to TCP/IP for IBMPC MS/DOS
applications.  All are welcome to attend, especially PC TCP/IP vendor
representatives.

Drew

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 08:33:44 EST
From:      Steve Goldstein <goldstei@mitre.arpa>
To:        Mills@UDEL.EDU
Cc:        "James B. VanBokkelen" <JBVB@ai.ai.mit.edu>, amdcad!amd!intelca!mipos3!omepd!wire@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, goldstei@mitre.arpa
Subject:   Re: TCP/IP Slang Glossary
Makes sense, Dave, 'cause in the DECnet (you should pardon the expression!)
world, gongs are called "Donikers".

Steve
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Nov-87 09:06:12 EST
From:      YAKOV@IBM.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Solicitation for comments

I'd like to solicit some comments on the following proposal for
IP routing:

    Instead of computing routes on a hop-by-hop basis, the
first gateway which receives packet from a host will compute complete route
(like IP source routing) and all other gateways on the path
to destination will route just based on that source routing.
That assumes, that each gateway has complete topology of the network,
and that it runs some sort of SPF (Shortest Path First) Algorithm
which can generate complete path for a given destination.
This idea (of source routing instead of hop-by-hop routing)
is similar to what is used in MAC Layer IEEE 802.5 bridges.

Both positive and negative comments are welcomed.
Many thanks in advance to all who will reply.

Jacob Rekhter (YAKOV@IBM.COM)

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1987 10:06-EST
From:      CLYNN@G.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Question on ICMP Parm Problem Messages
Chris,
	If the IP header length is bad, I would send a parameter problem
message with a pointer of 0 and include a worst-case IP header (60 octets)
+ 64 bits of data; if something is that bad, give as much help as possible.
	For a bad IP length the pointer should be 2 or 3, and include the
IP header as specified in the IP Header Length field.  Note that there is
more than one possible IP length error: a) too small to include the IP
header [I do not think I have ever seen a specification that the layer
above IP HAS to have a non-zero length, although it seems rather unlikely],
or b) that the length is too large for the datagram passed to the IP from
below.  (Maybe a convention could be [informally?] established that a
pointer of 2 means the IP Length was too large and 3 that it was too small;
all in the spirit of adding as much diagnostic information as possible.)
PS: "columbia-pdn" is an interesting domain-style name.
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 10:06:37 EST
From:      tsuchiya@gateway.mitre.org (Paul Tsuchiya)
To:        YAKOV@ibm.com, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Solicitation for comments
It is a little hard to comment on your proposal since you did not
state what the advantages of doing source routing are.  There have
been several advantages put forth in the context of multi-path
routing and TOS routing (BBN has worked on this).  Some others believe
that it is useful for threading ones way through a thicket of
administrative restrictions on paths, but I have yet to see a
solid proposal on the idea.

Also, the similarity between what you propose and the 802.5 source
routing seems to end at the simple fact that they both put source
routes in their headers.  Using SPF to calculate the headers and
using what 802.5 are two completely different things.  I don't understand
all of the details of 802.5, but I understand it is really badly done.

Ultimately, I don't have my mind made up one way or the other about
source routing--I guess it rather depends on the specific proposal.
So I put it back to you, what do you consider to be the advantage
that causes you to propose it in the first place?

_________________________________________________________________
Paul F. Tsuchiya		The MITRE Corp.
tsuchiya@gateway.mitre.org	7525 Colshire Dr.
703-883-7352			McLean, VA 22102 USA
_________________________________________________________________

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1987 10:26-EST
From:      CLYNN@G.BBN.COM
To:        mogul@DECWRL.DEC.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP maximum segment size determination
We implemented a variation of the delay scheme: never send two
consecutive packets to the same next hop (on a single interface) if
there was another packet in the queue for some other destination.  It
was easy to implement, at most delays a packet by one packet's
transmission time, and does not suffer from the requeueing problem you
described.  It might even fit in well with recent interest in "fair
queueing" (it brings to mind the days when I was reliably sending
>20,000 byte datagrams across the ARPANET - the back to back problem
was very clear when IP fragmented it into >20 consecutive full size
ARPANET packets!).

Charlie
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Tue 17 Nov 87 10:30:20-EST
From:      Lixia Zhang <Lixia@XX.LCS.MIT.EDU>
To:        YAKOV@ibm.com, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Solicitation for comments
Jacob,

The discussion of using source routing in an internet env. has been going on
here and there for a long time.  I used to joke with friends that my
religion on internet routing is "source routing". (I also have religions
on other network issues: the religions on congestion control, on protocol
layering, etc.)

I'd like to know more about what thought you have behind the proposal.  Are
you proposing for a short term fix, or for some long term goal?
One should realize that employing source routing may imply fundamental
changes to the IP network architecture.  Besides that the whole current
routing architecture will be changed, source-routing on every single
datagram may also cause unbearable overhead.  I believe the changes will
eventually come; the question is when and in what form.

One comment on your last sentence: the source routing idea in your msg is
NOT very similar to MAC Layer 802.5 bridge routing proposal. In the latter,
MAC Layer bridges have no topology info at all; every single host (in fact,
its data link layer) is responsible to find out routes itself.

Lixia
-------
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Tue 17 Nov 87 11:24:09-EST
From:      Radia Perlman <radia@XX.LCS.MIT.EDU>
To:        YAKOV@ibm.com
Cc:        tcp-ip@SRI-NIC.ARPA, .@XX.LCS.MIT.EDU
Subject:   Re: Solicitation for comments
Source routing as Jacob Rekhter suggests (i.e. having the first gateway
put the entire route in the header, which it computes based on
a complete map of the network) should not be compared to the
"source routing" advocated by 802.5.  In the 802.5 scheme the
route is not calculated by the gateways, but instead the burden
of discovering and maintaining routes is placed on the end stations (maybe
you guys use the word "hosts" -- I'm from a different culture).
Discovery of a route in 802.5 is done by having the source end station
emit a sort of virus packet that proliferates
and travels over all the exponential possible
routes throughout the network, each copy recording the route it has taken.
Then the destination end station returns all the copies it receives
to the source end station, which can then enjoy the task of selecting
the "best route" based on any algorithm it likes.
With anything but a very small and very sparsely connected network,
the exponential overhead inherent in the route discovery process will
make the 802.5 proposal impractical.  I believe the January issue
of IEEE Network Magazine will be a special issue on bridges, if people
want more information on the subject.

Anyway, that's not a criticism of Jacob Rekhter's scheme, just of his
comment that his proposal was "similar to 802.5 bridges".

There are lots of advantages to having the first gateway specify
the route.  The main disadvantages are:
   1) the header gets larger of course -- the networking community has
   already been accused of offering a "headergram" rather than a "datagram"
    service.
   2) the scheme gets more complex (though not impossible) when the
   network gets large enough to introduce an extra level of hierarchy.
   (So that the source gateway does not have a complete map of the network).


Radia Perlman (Radia@XX.LCS.MIT.EDU)
-------
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1987 11:38-EST
From:      CLYNN@G.BBN.COM
To:        mogul@DECWRL.DEC.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP maximum segment size determination
Jeff,
	If you want a low (as in zero) gateway overhead, no change(1)
to gateway code, non-TCP specific, works with non-symmetric routes,
easy to phase into use (e.g., where you really need it), backward
compatible, way to do MTU probing, read on.
	In this scheme, every packet is a "probe" (no cost to
originating system to invoke).
	The gateways do fragmentation, as they are required to do.
I would suggest that the size of the first fragment be the MTU of the
next hop - the suggested fragmentation algorithm has this property,
and the last time the subject was discussed on this list, no vendors
replied saying that they had implemented an algotithm which didn't
have the property (but it isn't really required anyway).
	If all the fragments arrive at the destination and get
reassembled(2), all is well and you didn't really need to probe.
In the no-problem case, your additional cost is zero - seems good.
	If not all the fragments made it, some will be left in the IP
reassembly queue and timeout.  This is where the ICMP Time Exceeded
message is used (as opposed to the spec which uses words like "may"
and "need not").  Chances are pretty good (engineering over
mathematics) that the first fragment made it and can be included in
the message - it has the minimum-maximum MTU encoded in the IP Length.
If "fragment zero" is not there, it should be easy to use a fragment
with "the largest size"; this might require a little extra code in the
hosts, but it only costs cycles when needed, and is in the hosts and not
the gateways.
	The ICMP message is returned to the originating host; the
route that it takes does not matter - symmetric or asymmetric.  The
datagram may get lost(1), but then any IP based technique has the same
problem.  If the problem is persistent, one should get through.
	The originating host receives the message and the ICMP
routines use the very strong hint about the path MTU to update
whatever table it uses to record such information (this may require
some additional code in the hosts) before passing the message on to
the higher level protocol involved.  One can use any desired "filtering"
algorithm to set thresholds for when to decide it is appropriate to
change the MTU vs letting higher level reliability mechanisms deal with
the problem.
	All of the mechanisms used in this technique are allowed by the
current specifications, so phase-in and backward compatibility should not
be a problem.  It isn't perfect, but seems like an engineering compromise
that has several advantages over other schemes.

Notes:
1.  I would suggest that control traffic, e.g., ICMP be given a little
    priority in gateways when deciding which packets to drop.  Dropping
    control traffic doesn't sound like a good idea in general.
2.  An IP entity can "force" a probe by forcing a reassembly timeout.
    It can construct, for example, a "large" ICMP echo request setting the
    more fragments bit (but never sending the "last" fragment) (and probably
    a low TTL).  It would get the path MTU and, by definition, timeout
    and be returned.
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17-Nov-87 12:03:06 EST
From:      NIC@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   REMINDER OF WEEKDAY ARPANET TESTING!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
#########################################################################
*************************************************************************

                           !!! REMINDER !!!

*TOMORROW*, 18 November, between the hours of 13:00 and 16:00 EDT the
entire ARPANET will be cutover to the new End-to-End protocol (PSN
7.0) for operational verification.  At the end of this test period,
the network will be returned to the old End-to-End protocol.

Hosts experiencing problems are asked to call the the ARPANET
Monitoring Center at (617) 873-3571/3070 or (800) 492-4992.

**************************************************************************
##########################################################################
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

There will be a follow-up meeting on November 20, 10:30 am to discuss
the status of the ARPANET beta testing of the new End-to-End protocol
at the Washington Building, Room 201, 7600 Old Springhouse Road,
McLean, VA. 
-------

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 12:39 EST
From:      David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
To:        KENSICKI <clyde!motown!vilya!rhk@rutgers.edu>, tcp-ip@SRI-NIC.ARPA
Subject:   smtp on Symbolics lisp machines
    Date: 12 Nov 87 15:32:22 GMT
    From: clyde!motown!vilya!rhk@rutgers.edu  (KENSICKI)


    Does anyone have any expierence running tcp on Symbolics 3640's
    and 3675's ?
    We've installed an ethernet in our building and are using tcp
    to transfer files from unix (Wollygong tcp on a 3b2-400) to the
    Symbolics. We also have a AT&T 6300 using tcp from FTP Software.

    The problem is that while ftp works fine we can't get smtp to
    work. It seems that the Symbolics doesn't follow the format of
    smtp and usr a CR NL at the end of a line.

    We added a Sun 2 as a reference machine to clear up finger pointing
    at Wollygong. With this group of machines smtp works fine between
    the Sun, the 3b2, and the pc. To add to the confusion the smtp on
    the pc works to the Symbolics as well as to the others?

    Any thoughts would be appreciated.

As a reference, we send mail (such as this message) and receive mail
(such as your message) from all sorts of the Internet hosts using SMTP
using LispMs at our end.  You don't say if SMTP works between the Sun
and the Symbolics.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 13:42 EST
From:      Eric S. Crawley <Crawley@ALDERAAN.SCRC.Symbolics.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ARP hello packets
I know this has been discussed on this list before, but I don't know if
a consensus was reached.

Are there any implementations out there that broadcast an ARP "hello" at
boot time?  A "hello" is an ARP reply packet that contains the hardware
and protocol address of the machine being booted so that other machines
can record its address resolution for future use.  If anyone has done
this, what values are put in the target protocol and hardware address
fields of the packet?  Do any implementations send such "hello"s before
they send a broadcast for some specific service (eg. time)?

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 14:07:03 EST
From:      Ross Callon <rcallon@PARK-STREET.BBN.COM>
To:        yakov@IBM.COM
Cc:        tcp-ip@SRI-NIC.ARPA, rcallon@PARK-STREET.BBN.COM
Subject:   re: Source Routing
Jacob;

The possibility of having the first gateway compute a complete source
route and add the route to the packet is an interesting one, which
has been discussed for quite a while now.  The biggest problem with
it is the computation involved with changing the IP header (at the
first gateway) and parsing the header (at other gateways).  This
problem is a result of the way that the IP header is defined (and is
at least as bad for the ISO IP), but could be solved by alternate
encodings.  The degree to which you care about processing depends
upon the processing power of the gateway, relative to the bandwidth
of its interfaces.  In particular, do your gateways have processing
power to spare?

Inserting a source route at the first gateway requires recomputing
the checksum, which kills the end-to-end nature of the checksum
computation (I personally don't care that much about this).  Also
note that the ISO IP, with 20 octet addresses (maximum size) and a
254 octet maximum header size, does not leave room for all that many
addresses in the source routing field (the exact number depends upon
the actual address size used, whether the segmentation part of the
header is there, and the presence of other options).

In the case of multiple-autonomous systems, assuming some future
inter-AS protocol, you probably don't want a gateway to have complete
knowledge of the internals of other ASs.  This implies that you would
not be able to produce a complete source route (as you suggested),
but still may use a similar idea with partial source routes (which
may specify gateways, or may specify AS numbers or something else).

One obvious question is why would you want to do this?  There are
several reasons that I can think of: (1) to avoid looping and other
routing problems; (2) to relax the requirement of SPF that different
gateways all have consistent databases; (3) to allow different
sources to have different routing policies; (4) to allow the source
to route different packets along different paths; or (5) for some
different encoding, to minimize the work required of intermediate
"transit" gateways along the path.  

I'm not convinced that avoiding looping is really the reason for
using this scheme.  Our experience is that, given well chosen
metrics, SPF routing really works pretty well.  The degree to which
the NSF network is having trouble with routing is due to the
particular routing algorithm that they are using, not due to any need
for a previously unthought-of approach to routing.  I think this is more
or less why there is the beginning of an effort in IETF to develop a
new (probably SPF-based) routing scheme that would be "public domain"
and well specified via future RFCs.

If you use source routing, you still must require that all gateways
have databases which are correct in the sense that any link that they
think is there really is.  Thus link failures would still have to be
reported very quickly.  However, it would be possible to report other
news (such as a new link coming up, or the change in "cost" of a
link) more slowly.  I'm still not sure that this is such a big deal
because (1) I think that "costs" on operational links should not be
allowed to change rapidly in any case; and (2) when new links come
up, it should first be determined that the link is really stable up,
and then all nodes will probably want to hear about this quickly.  On
the other hand, there may be some minor benefit in not needing to
propagate most routing updates at quite so high a priority.

The idea of allowing sources to have different routing policies is 
an important one in inter-AS routing, but I don't see it as very
important in intra-AS routing.

We (at BBN) have plans to use a sort of source routing in the Arpanet
to allow multi-path routing for load splitting and congestion control
purposes.  Note that in order to do anything that resembles optimal
multipath routing, you are required to do either (1) source and
destination based routing (i.e., each node calcualtes and maintains a
separate route for every source-destination pair, rather than just
for every destination); or (2) source routing.  Since we build all of
the PSNs in the Arpanet, we are able to define a header encoding
which makes source routing very efficient (actually more efficient
than regular routing table lookups).

Similarly, Butterfly gateways do something that resembles partial
source routing in order to optimize the path lookup.  As an IP
datagram passes through an AS consisting of Butterfly gateways, the
first gateway encodes the datagram in a "gateway to gateway header"
which specifies the last gateway in the AS.  The transit gateways
only have to look at a very small exit gateway ID in the gateway to
gateway header in order to route the packet.  The exit gateway (the
last gateway in the AS to deal with the packet) then removes the
gateway to gateway header.  This approach minimizes the processing
required at intermediate gateways, and allows IP level routing to be
separated into two logically separate steps (i) determining the exit
gateway for a particular destination network or IP address; (2)
determining the route to that particular exit gateway.  If we were to
extend routing to deal with partitioned networks, only step (1) would
be effected.  This may potentially be useful for other purposes as well.  
For example, the exit gateway may be chosen based on load sharing or 
other criteria.

I think that if we are to use your suggestion and use source routing
(whether partial or complete), we would need to either redefine the
IP encoding, or do something similar and add a gateway to gateway
header with a more efficient encoding.  This latter approach would
allow the hosts to remain unaffected by the change.

Ross
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 09:45:27 +0200
From:      raanan michael <VSRAANAN%WEIZMANN.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Ethernet versions
ethernet , iee802.3 and trasceiver connector pin  assingment.

   pin number          ethernet function                iee 802.3 function
  ------------------------------------------------------------------------
      1                chassis ground                   collission shield
      2                collition presence +             collition presence +
      3                transmit +                       transmit +
      4                unused                           receive shield
      5                receive +                        receive +
      6                power return                     power return
      7                unused                           control out +
      8                unused                           control out shield
      9                collition presence               collition presence
     10                transmit -                       transmit -
     11                unused                           transmit shield
     12                receive -                        receive -
     13                power                            power
     14                unused                           power shield
     15                unused                           control out +
     shell             classis ground                   classis ground
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 20:52:16 EST
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        YAKOV@ibm.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Solicitation for comments
In the NSFnet at least, we are moving towards segmented or
hierarchical routing.  It is unlikely that any gateway will know the
whole route for a trans-continental packet.  We do not know any
routing technology that is currently up to handling the entire
Internet as a single-level metric.  Thus we expect each campus, each
regional, and backbones such as Arpanet and NSFnet backbone, to be
"autonomous systems".  They will exchange mostly reachability
information.  Your own system will know a reasoanble exit gateway for
each destination, but may not know the exact route that will be used
to get to the final gateway.  Thus a complete source route is not
going to work.  It may be that loose source routing might be useful,
to specify which AS's are to be traversed.  However I don't know of
anyone involved in setting up IP routing that is anxious to get
involved in this approach.  If the gateways that go between the AS's
can get their act together, there should be no need to do source
routing.  I see the primary disadvantage as being that the amount of
data needed to do a source route is going to be larger than that
required to do just the next hop.  I think source routing may in fact
be useful for specifying major routing policy decisions.  That is, if
a campus has a couple of major networks, one that is congested but
free and another that is pay, the user may be asked to specify that
he wants to pay by using a source route.  That would probably be a
loose source route with just one entry, the gateway between the campus
and the pay network.




-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 21:26:38 EST
From:      "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>
To:        clyde!motown!vilya!rhk@RUTGERS.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: smtp on Symbolics lisp machines
I would guess that they looked at what they were getting from a mis-configured
4.2 system when they designed their SMTP, and decided that that was right,
rather than the RFC.

4.2 systems require an extra argument in sendmail.cf to cause a TCP mailer
to use CR LF.  This is essentially undocumented, and many amateur surgeons
pruned the wrong mailer definition when adapting a distributed file, or
left it out of a homebrew file.  Our first parser only accepted CR LF,
and we got burned by having numerous support calls, each requiring that
we walk the customer through changing his sendmail.cf.  In the next release,
we accepted either form.  Berkeley has accepted either form since 4.2, but
the requirement for the extra argument makes me think that they started out
not conforming...

James B. VanBokkelen
FTP Software Inc.

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 21:34:32 EST
From:      "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>
To:        CF4A8X%IRISHMVS.BITNET@MITVMA.MIT.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Name Server for Ultrix 2.0
I just built Berkeley bind v4.7.2 (current, I think) on my 2.0 Ultrix, and
it runs just fine.  All I had to do was modify the makefiles a little so
that they would look at the distributed include directory first (which has
4.3 modifications in it), before the Ultrix /usr/include directory (which
still uses the 4.2 netdb.h on 2.0).  It was the first time I'd ever built
bind, and it took about 2 hours work (of course, I didn't have to set up
the configuration, we had been using 4.5 previously).

jbvb

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 21:46:33 EST
From:      "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SMTP on Symbolics LISPMs
Something I did not make clear in my first posting is that the defintion
of SMTP says that each command is terminated by a CR LF (or CR NL if you
prefer).   Anyone who sends text terminated by only LF is *wrong*.  However,
enough Berkeley-derived systems (Wollongong VMS is descended from Berkeley
4.1C) do so that most robust SMTP servers accept either.  If TWG has retained
the sendmail.cf, it may even be possible to re-configure it (and it may be
local mis-configuration in the first place).

jbvb

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Nov 87 22:38:02 EST
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        lekash@orville.nas.nasa.gov
Cc:        Mills@udel.edu, tcp-ip@sri-nic.arpa, ineng-interest@isi.edu
Subject:   Re:  Life after source quench
Over the weekend we found a bug in bind 4.7 that would lead to
uncontrolled streams of requests to name servers.  Indeed the same bug
exists as far back as 4.4, but may not have quite the same drastic
effect in earlier releases.  The nature of the bug is that when bind
sends a reply, it does not always have the bit turned on that declares
it to be a response.  To see why this has the effect, consider the
two-level server configuration supported by 4.7.  There are 3 primary
name servers at Rutgers.  All other name servers forward requests to
one or more of them.  Suppose a random server tries to do a lookup of
a name that for some reason can't be resolved.  It will forward the
request to one or more of the primary servers.  They will send
requests to the appropriate servers, one of which is presumably yours.
Once this times out (presumably because all of the servers for the
domain are dead or something), the primary server will send a message
back to the original one saying with no answer.  However if the
response bit is off, this will look like a request.  The original name
server will now send off requests to each of the 3 primary servers,
and the cycle will restart.  Note that one initial request has now led
to 3 new queries, one triggered by the answer from each of the primary
servers.  Unfortunately, bind does not detect when it is being asked
identical questions.  (It does detect duplicates, in the sense of a
query with the same query ID being issued several times.  But in this
case each new query will have a different ID.)  Thus we have an
explosion, which ultimately will be limited only by our name servers'
CPU and the transmission line.  The servers involved are a Sun 3, a
Sun 4, and a Pyramid, and we feed into NSFnet with a T1 line.  I
believe we are capable of saturating the NSFnet backbone.  I think
this explains the observed results.

We have fixed the bug in bind, and have not seen any storms such as
this since.

There was one additional problem.  The reason we were attacking your
server in the first place was because we had the wrong list of root
servers.  Unlike some earlier releases, bind 4.7 keeps track of
root servers dynamically.  It writes out the current state of its
cache every hour.  When the system is rebooted, it starts from the
most recent cache state, not from a cold start.  So if it once gets
a bad root name server, and if that server lists itself as a root
name server, this server will continue being used as a root
forever.  Furthermore, if the bad server is on NSFnet, it will have
better response than the real root servers, and so will be used 
preferentially.  So all it takes is for your server to get listed
once as a root server.  That is very easy to happen.  Bind's basic
algorithm is the following:
  send a request to an appropriate name server
  if there is an answer return it to the user and terminate
  put all data from the response into the cache, whether it is an answer,
	in the authority section, or additional data
  recompute the appropriate set of name servers to use
Because it puts all data from the authority and additional data sections
into the cache, all it needs is for one server to list you as a root
server in the authority section of a response. 

We regard this as a bug, and have fixed it.  We no longer accept root
name server information unless it is in the answer section of the
response.  Unless there is a serious bug in somebody's code, root NS
records will get into an answer section only if we ask explicitly who
the root NS records are.  We will only ask that question of an
existing root server.  Since we put that patch in, we have stopped
seeing random hosts showing up as root name servers.

While we have fixed these bugs, there are presumably many other sites
out there that still have them.  Both problems are present in all
versions of bind that we know.  I have posted these problems to the
mailing list of 4.7 beta-testers.  I have an annotated listing of all
of our patches for anyone that wants to put them into their own copy
of 4.7, or indeed an earlier release.

Please tell me if you see any other misbehaviors caused by our name
servers.
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 87 10:21:26 -0800
From:      kent@decwrl.dec.com
To:        slevy@umn-rei-uc.ARPA (Stuart Levy)
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Telephone Access Controllers (TACs) and SLIP...
Methinks we should solve this once and for all, one way or another.
Otherwise, we're doomed to resurrect the same problem set every six
months until eternity.

As I've said before, I believe in having fixed addresses attached to
dialup clients. Password protection seems adequate authentication.

The typical riposte comes from someone who wants to have lots of PCs
attached, and doesn't want to have to pass out authentication and
address information (and update it and manage it and so on). I
sympathize, and haven't yet been inspired to find a middle ground
(though I'm not convinced it's as big a problem as some would have me believe).

People in this building are using dial up SLIP from home computers. At
boot time, the home machine dials the IP server and logs it with a
login name derived from the home machine's host name. The server now
knows the client's name, and all is happy, with no real protocol added
to SLIP itself. This seems to work just fine for our situation.

Cheers,
chris
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Nov-87 08:19:09 EST
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: idle chatter about reference models


Mike,

    I'd say HMP belonged at the transport layer.  It can be reasonably
neatly dropped into a binary bsd kernel as a transport protocol, and
it has the usual transport functions (transport user addressing, sequence
numbers, etc).

    As for the four level ARM -- I recently argued to someone that we're
approaching five levels:

	     Application
	    [Presentation]
	      Transport
	     Internetwork
	       Network


The argument being that while we have no standard Presentation layer,
we are certainly using presentation schemes (XDR, Courier, ASN.1, multimedia
formats, etc.)

Craig

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 87 08:32:59 EST
From:      doug@icase.arpa (Doug Peterson)
To:        tcp-ip@sri-nic.arpa
Cc:        doug@work15
Subject:   nameserver on Suns
Has anyone out there had any experience with Sun's nameserver?

It would be useful to know things like:

	1. Can I set this up and try it WITHOUT affecting the way things	   are done presently? There's no reason that the user community
	   should suffer.

	2. What can I expect to happen when I start up the deamons?
	    (Whch daemons are necessary and sufficient?)

	3. How can I tell if things are working (or not)?

	4. Is it possible (advisable) to put up parts of this, or should
	   it be done all at once? I envision something like "rlogin host"
	   would query some designated nameserver for "host's" IP address.

	5. What else is necessary to get sendmail to query the nameserver?

Thanks in advance.

Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 865-4090


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 87 12:10:01 PST
From:      ron@manta.nosc.mil (Ron Broersma)
To:        BILLW@mathom.cisco.com, chris@gyre.umd.edu, dlw%opal.Berkeley.EDU@violet.berkeley.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  Telephone Access Controllers (TACs) and SLIP...
We have implemented such a service locally.  Our slip "server" (currently on
a vax running 4.3) listens on a bunch of tty ports allocated to this service
for slip requests.  As soon as it gets carrier on one of the ports, it accepts
various requests, one of which is "slip <userid> <password>".  Then it sends
back the IP address, netmask, and default gateway to be used by the caller.
The caller can then send IP packets out its RS-232 port, packaged with
slip.  This is the way many of our PCs talk via our Sytek LAN if they don't
have ethernet access.

The reason we bypass getty/login is for speed reasons.  In some cases the userid
and password are optional which allows very quick setup of the SLIP link.  It
doesn't have to be done this way, most would want to implement this scheme
by logging in through a login port and then issue a command to enter SLIP mode.

The way we generate IP addresses is to have a specific address per port on the
server.  All these ports are on the same subnet.  It doesn't really seem to
matter that the PCs accessing the net via SLIP don't have fixed IP addresses.
You only have to allocate one address per server port and you don't have to
worry about setting up a new IP address every time somebody gets a new PC (and
we already have over 3000 of 'em).  Routing is easy since we put them all on
a separate subnet.

It would be very nice if we could agree on a "SLIP link establishment protocol"
so we don't come up with multiple schemes for doing the same thing, all 
totally incompatible.  My scheme works but could be improved.  It solves the
general problem for us but should allow the case where the client has a fixed
IP address and/or hostname.

--Ron
ron@nosc.mil
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 87 09:14:59 EST
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        Kastenholz@mit-multics.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: RPC/NFS over IP Routers

Rutgers runs NFS file systems through I/P routers.  The ones we
are currently using are from cisco, but what I have to say should
be true for any manufacturer.   We bridge both Ethernet to Etherent
and Ethernet through T1 line to Ethernet.  The fileserver on the
far side of the T1 line from the rest of the network has it's own
local paging area and root and usr, but gets a lot of the users'
home directories from NFS mounts.

We limit our NFS configurations by the following parameters:
1.  No paging or root access through the gateway.  Every workstation
either has local disk, or is on the same Ethernet as a file server
providing these.

2.  The rsize/wsize parameters in the NFS mount need to be cranked down
a bit or else wierd (NFS Server not responding/OK) symptoms arrive.

-Ron
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 87 12:19:18 PST
From:      JQ Johnson <jqj@drizzle.uoregon.edu>
To:        tcp-ip@sri-nic.arpa
Cc:        raf@nihcu.BITNET
Subject:   lieing about the subnet mask
RAF@NIHCU.BITNET recently asked about multiple IP subnets on a single
wire and similar permutations of the homogeneous one subnet per wire IP
layout.

A number of people responded to him by mail suggesting that he lie to
some hosts about the subnet mask. To simplify the example, suppose that
we have 2 connected Ethernet cables configured as two subnets of a
class B net: subnet A, 128.223.8.0, whose hosts think the subnet mask
is 255.255.255.0 (8-8); subnet B, 128.223.16.0, whose hosts think the
subnet mask is 255.255.240.0 (4-12). Given most current subnetting
implementations, hosts must think the class B network is homogeneous.
Thus, hosts on A think that there are 15 8-bit subnets 128.223.16.0,
128.223.17.0 ...; hosts on B think that A is part of a 4-12 subnet.
Note that hosts on B *must* route to subnet 128.223.9.0 (if it exists)
through the same gateway as they route to subnet A [though redirects
may change the routes to individual hosts on 128.223.9.0]; thus the
physical topology should be hierarchical.  And the gateway's RIP code
needs to be hacked to advertise on A not just 128.223.16.0 but
128.223.16+x.0.

OK, so if the connection topology is hierarchical and we have control
over the gateway code, then the routing seems to work. But what happens
with broadcast addresses? Suppose a host on A sends to 128.223.8.255.
For the gateway to know this is a broadcast, its subnet mask must be
the same as the host's. Similarly for B -- a local broadcast to
128.223.31.255 on cable B needs to be interpreted as a local broadcast
by the gateway; if the gateway thinks it has 16 addresses on cable B
and that the subnet mask on B is 8-8, it will interpret this as a
letter bomb (aka directed broadcast) destined for subnet 128.223.31.0,
and may well rebroadcast it on the same cable!  That would lead to
meltdown.  Even if the gateway doesn't forward letter bombs, it needs
to be able to generate broadcasts on B itself.

So the gateways need to be smart and have different subnet
masks for the two subnets.  They can't fake it by considering the
larger subnet to be several small subnets; they must have the same
view as do the hosts on the subnet.

Note that it is impossible for hosts to send directed broadcasts -- a
host on A who wants to send a directed broadcast to B will send to
128.223.16.255 or something, which the gateway had better interpret as
a host address on B. So we've made directed broadcasts impossible; bfd
perhaps, but a violation of the RFCs. And I bet we can't run a stock
4.3BSD system as the gateway.  The KA9Q code probably works (?).

We'd better not allow any hosts on subnet B to have addresses of the
form 128.223.16+x.255 (x={0,...,14} either, since that looks like a
broadcast address from the viewpoint of a host on A.

What else breaks? I dunno. None of the above is particularly
disasterous, and a site trying it may get good enough performance and
connectivity to think it's working even if there are hidden serious
problems. However, it is complex enough that I'm worried that something
else which IS disasterous will come along. The apparently innocuous
suggestion has certainly increased the complexity of the protocol
substantially!  Am I being a nervous nellie?  Has anyone analyzed this
carefully?


-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 87 10:13:59 EST
From:      Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To:        hedrick@ATHOS.RUTGERS.EDU
Cc:        Mills@UDEL.EDU, lekash@orville.nas.nasa.gov, tcp-ip@SRI-NIC.ARPA, ineng-interest@VENERA.ISI.EDU
Subject:   Life after source quench
	Who says SRI-NIC knows who the root servers are. Below is the
contents of a NS lookup of the root servers directed to SRI-NIC. Note
that it lists itself, C.ISI.EDU (which is shutoff today), BRL-AOS.ARPA
and A.ISI.EDU.  However for additional records it only supplies an A
record for SRI-NIC and BRL-AOS. C.ISI.EDU and A.ISI.EDU are not
provided with A records.

		-Jeff

Begin enclosure:

E40-311B-2% bindtest -r 10.0.0.51
> n.
res_mkquery(0, ., 1, 2)
res_send()
HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags: 
        qdcount = 1, ancount = 0, nscount = 0, arcount = 0

QUESTIONS:
        ., type = NS, class = IN

got answer:
HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  qr aa
        qdcount = 1, ancount = 4, nscount = 0, arcount = 4

QUESTIONS:
        ., type = NS, class = IN

ANSWERS:
        .
        type = NS, class = IN, ttl = 604800, dlen = 14
        domain name = SRI-NIC.ARPA

        .
        type = NS, class = IN, ttl = 604800, dlen = 11
        domain name = C.ISI.EDU

        .
        type = NS, class = IN, ttl = 604800, dlen = 14
        domain name = BRL-AOS.ARPA

        .
        type = NS, class = IN, ttl = 604800, dlen = 11
        domain name = A.ISI.EDU

ADDITIONAL RECORDS:
        SRI-NIC.ARPA
        type = A, class = IN, ttl = 604800, dlen = 4
        internet address = 26.0.0.73

        SRI-NIC.ARPA
        type = A, class = IN, ttl = 604800, dlen = 4
        internet address = 10.0.0.51

        BRL-AOS.ARPA
        type = A, class = IN, ttl = 604800, dlen = 4
        internet address = 128.20.1.2

        BRL-AOS.ARPA
        type = A, class = IN, ttl = 604800, dlen = 4
        internet address = 192.5.25.82

> 

End Enclosure.
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 87 11:02:39 EST
From:      Mills@UDEL.EDU
To:        Craig Ruff <hao!scdpyr!cruff@husc6.harvard.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Life after source quench
Craig,

Thanks for the info. You might do all of us a great favor by landing the
issue on IBM's palm. That host is causing real pain on the NSFNET Backbone.
Specifically, it would be just peachy if it responded to ICMP source-quench
messages. Now, the only way we can deal with it is to further fine-tune the
selective-preemption algorithm to discriminate against those hosts of heavy
hand.

Dave

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Nov-87 12:19:53 EST
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP and various things other than ethernet....


     isn't any reason why ARP can be used, more or less as-is, for any
     hardware network having a broadcast concept...

.. or even any network with a distinguished, well known address, by which you
reach the server(s) that store the address information.  There is no
philosophical need to have the data base distributed to the level that each
host stores only that part of the data base that pertains to it.  However, it
definitely is convenient to have the host in charge of its own data.  

I just wanted to make the point that address FFFFFFFFFFFF is not magic, nor is
broadcast.

    Mike

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Nov 87 14:43:51 EST
From:      rick@seismo.CSS.GOV (Rick Adams)
To:        craig@nnsc.nsf.net, tcp-ip@sri-nic.arpa
Cc:        billw@mathom.cisco.com, dlw%opal.berkeley.edu@violet.berkeley.edu
Subject:   Re:  dial-up SLIP
This has been done with pretty good success in Japan using
Sun's and Unix.

I'll try and dig up the paper that discusses it (an old SIGCOMM newsletter?)

--rick
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Nov-87 17:49:40 EST
From:      rpw3@amdcad.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet versions

In article <8711141736.AA21062@topaz.rutgers.edu> Ron Natalie writes:
+---------------
| On the coax there is no differenece electrically between Version I
| Version II, and IEEE 802.3.
+---------------

Weeeelll... almost. There WAS a teensy change in the electrical spec on
the coax between Ethernet Version 1.0 (Sep'80) and Version 2.0 (Nov'82),
having to to with tightening the specs on the drive current (or at least
changing the way the A.C. versus D.C. components were specified). See
Section 7.3.2 "Coaxial Cable Signaling" in each version (p.61 in ver 1.0,
p.72 in ver 2.0). The net effect was to change the shape of the AC/DC schmoo
slightly. Very slightly.

There IS one significant change to that section in the 2.0 spec. The following
sentence is added:

	"The transceiver shall be able to produce its specified output
	current onto the coaxial cable with at least one other transceiver
	transmitting simultaneously."

That sentence made it official that receiver-based collision detection
shall be possible, by requiring that the current source in a transceiver's
transmitter not wimp out until the cable voltage was AT LEAST twice the
normal max peak voltage.

All practical "current sources" have a "maximum compliance voltage" above
which they quit being true current sources. (A "perfect" current source
would increase its voltage without limit, even to the point of arcing over
if you tried to disconnect it!) All of the current sources in the popular
Version 1.0 transceivers had plenty of compliance; the 2.0 spec just made
it official.

Why all the trouble? Well, if you are going to build a repeater, it's
important that you be able to creat "carrier" on the "other" side of
the repeater whenever you see carrier on "this" side (or a "jam" on the
other side whenever you see "collision" on this side). But in the case
of several transceivers transmitting at once, the current sources will
saturate and all the A.C. signal will disappear in the large D.C. offset.
It is important that this not happen at a voltage lower than the repeater
could reliably detect as a collision, when it itself was not transmitting.

Furthermore, I've been told that the tightening of the A.C. versus D.C specs
I mentioned above helped solve a possible ambiguity: In the case where a
repeater is at one end of a maximally-loaded cable and there is a collision
between two wimpy transmitters at the far end, the tightened spec plus the
tightened "voltage compliance" guaranteed that the repeater would see it as
a collision, and not interpret it as a single nearby macho transmitter.

Again, it's no big deal. All (?) of the 1.0 vendors' transceivers worked
(and work) just fine on a mixed 1.0/2.0/IEEE_802.3 cable. It just needed
to be said explicitly in the spec.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18-Nov-87 22:14:47 EST
From:      fedor@NISC.NYSER.NET (Mark Fedor)
To:        comp.protocols.tcp-ip
Subject:   Strange returned mail.



	I just received about 7 messages like the one that follows.
	I'm clueless as to why I got them.  I never tried
	to send to this place.  Is this another one of those
	unsolved network mysteries?

	Any answers?  clues?

	Thanks.

	Mark

------- Forwarded Message

Return-Path: postmaster%odin.re.nta.uninett@TOR.NTA.NO
Received: by nisc.nyser.net (5.54/1.14)
	id AA08642; Fri, 13 Nov 87 12:13:14 EST
Date: Fri, 13 Nov 87 16:43:08 +0100
Posted-Date: Fri, 13 Nov 87 16:43:08 +0100
Message-Id: <8711131543.AA10354@tor.nta.no>
Received: by tor.nta.no (5.54/3.21)
	id AA10354; Fri, 13 Nov 87 16:43:08 +0100
To: fedor@nisc.nyser.net
From: UNINETT-ARPA Gateway <postmaster%odin.re.nta.uninett@TOR.NTA.NO>
Subject: EAN Mail Network -- failed mail
Status: RO

Mail Failure Diagnostics:
Rejected-Message-id: <8711060340.AA17823@nic.nyser.net>

Message Recipients:
   baard@vax.elab.unit.uninett: maximum time expired

------- End of Forwarded Message

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 03:36:00 EST
From:      LAWS@rsre.mod.UK.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

Mike,
 
I view EGP, GGP and HMP as Management protocols - for which await
the Management Addendum etc to the OSI model now nearing draft standard
status. The OSI model deals with issues for host-to-host open
interworking. 10 years ago network providers were seen to be large
public utilities that would resolve their internetworking problems
in their private club (=CCITT). The world and technology has moved on,
other (many) network providers are a reality. Hence the OSI model must
now enbrace the concepts of management in a more public way.
 
Your diagram might mislead the reader into thinking that internetworking
is not an issue in ISORM. The network service is the Global Network
Service and contains all conforming interconnected ISORM subnets.
 
I do not consider it a sensible question to ask which layer a specific
management protocol is in. Rather it stands off to one side as an 
application (maybe using the full stack of protocols for some part of
its job - access to a directory service?) while supporting a layer
in providing its service. 
 
ISORM may be applied recursively, direct or indirect. In my own work
I have used the X25 VC service as a point-to-point link to connect
an IP gateway to a host. The usage as an on-demand point-to-point
link has considerable economic and time savings when that usage is
infrequent.
 
John

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Nov 87 00:36
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@NSS.Cs.Ucl.AC.UK>
To:        "Michael J. O'Connor" <@NSS.Cs.Ucl.AC.UK:oconnor@sccgate.scc.com>
Cc:        tcp-ip <@NSS.Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: Idle chatter about reference models
Mike,
 
I view EGP, GGP and HMP as Management protocols - for which await
the Management Addendum etc to the OSI model now nearing draft standard
status. The OSI model deals with issues for host-to-host open
interworking. 10 years ago network providers were seen to be large
public utilities that would resolve their internetworking problems
in their private club (=CCITT). The world and technology has moved on,
other (many) network providers are a reality. Hence the OSI model must
now enbrace the concepts of management in a more public way.
 
Your diagram might mislead the reader into thinking that internetworking
is not an issue in ISORM. The network service is the Global Network
Service and contains all conforming interconnected ISORM subnets.
 
I do not consider it a sensible question to ask which layer a specific
management protocol is in. Rather it stands off to one side as an 
application (maybe using the full stack of protocols for some part of
its job - access to a directory service?) while supporting a layer
in providing its service. 
 
ISORM may be applied recursively, direct or indirect. In my own work
I have used the X25 VC service as a point-to-point link to connect
an IP gateway to a host. The usage as an on-demand point-to-point
link has considerable economic and time savings when that usage is
infrequent.
 
John
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 08:38:28 EST
From:      tom@tsdiag.UUCP
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Standard for Printers


THIS IS A FORWARDED MESSAGE Follows is the *REAL* header:
From: n2dsy@hou2d.UUCP (G.BEATTIE)
Organization: AT&T Bell Laboratories, Holmdel
Date: 12 Nov 87 21:09:05 GMT

I have been looking around for something similar to the
ANSI X3.64 Terminal Protocol Specification for printers
or printing terminals.   I guess that in some "ideal"
world we would have something analogous to the Virtual
Terminal Protocol for printers, but I am willing and
seeking suggestions regarding printer standards for
simple and medium-complexity printers.
Please don't tell me about Centronics interfaces -
that's hardware cabling.  What I'm interested in is
carriage control, carriage size, forward and backward
vertical and horizontal tabs, etc...

Any thoughts ?

Thanks,
            J. Gordon Beattie, Jr.

Unix:       ihnp4!hou2d!n2dsy		Voice: (201) 387-8896
Amateur:    n2dsy @ kd6th/3100201	Home:  (201) 615-4168 (FAX x4669)



-- 
Thomas A. Moulton, W2VY          Life is too short to be mad about things.
Home: (201) 779-W2VY             Packet: w2vy@kd6th  Voice: 145.190 (r)
Work: (201) 492-4880 x3226       FAX:  (201) 493-9167
Concurrent Computer Corp.        uucp: ...!ihnp4!hotps!ka2qhd!w2vy

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Nov 87 11:28 MST
From:      ALMA_GRIJALVA <ALMA@rvax.ccit.arizona.edu>
To:        TCP-IP@sri-nic.arpa
Subject:   RE: Re: TCP-IP in the Public Domain?
	The complete address for SRI is:

	Stanford Research Inst. - Net. Info. Center
	Room EJ291
	333 Ravenwood Avenue
	Menlo Park, CA  94025

	Tele#  415-859-5539

	alg.
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 09:33:33 EST
From:      kozel@SPAM.ISTC.SRI.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Slang Glossary


(This note really pertains to AWKing cisco gateway output)

In an earlier note you mentioned some AWK filters you have to
parse the cisco statistics dumps; could these be made available or
mailed to me?  We want to do the same thing; your effort would
certainly save some time.

thanks,

Ed Kozel
SRI International

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 10:28:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

The inter-gateway routing algorithms really do sit above the
Internet Layer and thus occupy the same space as the Transport
Layer - though their function is not specifically transport -
that is one reason that I have always been a little uncomfortable
with the ISO model with its apparently rigid specification of
functionality at each layer.

Vint

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1987 10:28-EST
From:      CERF@A.ISI.EDU
To:        oconnor@SCCGATE.SCC.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Idle chatter about reference models
The inter-gateway routing algorithms really do sit above the
Internet Layer and thus occupy the same space as the Transport
Layer - though their function is not specifically transport -
that is one reason that I have always been a little uncomfortable
with the ISO model with its apparently rigid specification of
functionality at each layer.

Vint
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 11:05:32 EST
From:      tucker%vger@GSWD-VMS.GOULD.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   4.3BSD TCP problem

We are having trouble using Berkeley 4.3 TCP over very slow network
connections (9600 baud).  Sometimes connections just get stuck.  Both
hosts are running the same Berkeley software.  This happens even if
the hosts are connected directly to each other by the slow network
link.

Below is a trace of the packets being sent back and forth.  This continues
forever.  The connection is in the following state:

local host connection says it is in:    CLOSE_WAIT
remote host says the connection is in:  FIN_WAIT_2

here are the packets that bounce back and forth:

sent: 45 0 0 29 6 fa 0 0 1e 6 79 4c a 1e 4 3b a 1e 4 13 2 2 3 f4 4 69 e2 2 4 4b 9c 50 50 10 10 0 f6 4c 0 0 0 ... (41 bytes)

recv: 45 0 0 28 6 fe 0 0 1e 6 79 49 a 1e 4 13 a 1e 4 3b 3 f4 2 2 4 4b 9c 51 4 69 e2 3 50 10 10 0 f6 4b 0 0 ... (40 bytes)

it just keeps going on forever (at least an hour)

Does anyone have any idea what is happening?  I would appreciate any
comments!  Thanks.

Tim Tucker
Gould CSD
tucker@gswd-vms.gould.com.

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 11:34:44 EST
From:      mqh@batcomputer.UUCP
To:        comp.protocols.tcp-ip
Subject:   FIN problem in Berkeley 4.3?

Hello,

We're running a Gould here with Berkeley networking code.  It would appear
that when a TCP connection is closed, and the FIN is retransmitted for some 
reason, it's sequence number is one too low.  The sequence number is correct
on the first transmission.  

I've looked into "tcp_output.c", and it is marked as "7.2.1.1 ... 3/28/87".
The code looks correct by casual inspection, at least.

Can anyone shed some light on the problem before I spend time trying to 
debug this in UNIX? 
-- 
Mike Hojnowski (Hojo)		{ihnp4,rochester}!cornell!batcomputer!mqh
ICBM 042N 29  076W 27		mqh@batcomputer.tn.cornell.edu
"With friends like that, who needs enemas?"  - Max Headroom

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Thursday 19 Nov 87 12:36 PM CT
From:      Jay Ford (U of Iowa) <JNFORDPB%UIAMVS.BITNET@wiscvm.wisc.edu>
To:        TCP/IP mailing list <TCP-IP@SRI-NIC.ARPA>
Subject:   help
This  is  a  request  for  network  configuration  suggestions.    Any
responses should be sent to me rather than to the list.

Questions

   How have other sites approached and/or solved the problems  associated
   with establishing and administering large campus networks?

   Is the topology outlined below feasible without having static,
   manually-entered routes for the entire campus?

   Will an ARP (or any) ethernet-level  broadcast  from  a  host  on  one
   ethernet  make  it  through  a  gateway to a host on another ethernet?
   Will the ARP reply make it back to the broadcaster?  Is  it  necessary
   to  have  something  along  the  lines of proxy-ARP to make this work?
   Does existing software support proxy-ARP?

   Does anyone have suggestions addressing problems at  any  level  which
   would alleviate some of the routing complexity?


Notes

   We  are  new  at  this,   and   very   well   might   have   incorrect
   interpretations  of  the  problems  we face. By the same reasoning, we
   certainly  are  not  aware  of  all  the  possible  solutions  to  our
   problems.  Any help would be appreciated.  Thank you.


Background

   The University of Iowa is in the  process  of  establishing  a  campus
   network  consisting  of  departmental  LANs  hung  off  of a broadband
   backbone.  The departmental nets use  various  technologies  including
   Ethernet/IEEE   802.3,  proprietary  token  rings,  and  fiber.   Some
   departments have multi-level networks (see figure below).

   Access to the broadband backbone is provided through ethernet  bridges
   (Bridge  IB/1  boxes),  with each department having one IB/1. The IB/1
   is a  MAC-level  bridge,  so  that  a  host  on  a  baseband  ethernet
   connected  to  an  IB/1  in  one  department appears to be on the same
   physical cable as a host on a baseband ethernet connected to  an  IB/1
   in another department.

   We have a mixture of machines and OSs, including VAXes running  4.2  &
   4.3  BSD,  VAXes running VMS, Encores running UMAX 4.2, Apollos, Suns,
   PCs, Primes, and IBMs running MVS; we also have a  handful  of  Encore
   Annex terminal servers.

   The U of Iowa has been granted a class B Internet number  of  128.255.
   We will soon activate a connection to MIDnet -> NSFnet -> world.


Topology

   The current network topology (with only two departments connected) is:

                                      ||                      Annex1 ---|
                                      ||   +------+                     |
                                      ||---| IB/1 |-----(ethernet1)-----|
                                      ||   +------+                     |
                                      ||                     Encore1 ---|
                                      ||
     |--- Encore2                 (broadband)
     |                                ||
     |--- Alliant                     ||
     |                     +------+   ||
     |-----(ethernet2)-----| IB/1 |---||
     |                     +------+   ||
     |--- VMSVax1                     ||   +---------+
     |                                ||---| Proteon |----> (MIDnet)
     |--- Apollo1                     ||   +---------+
             |
            ---
          /     \
        /         \
       (Apollo-ring)
        \         /
          \     /                    |--- BSDVax1
            ---                      |
             |                       |--- BSDVax2
          Apollo2 ----(ethernet3)----|
                                     |--- BSDVax3

   We would like to assign a subnet number to each physical network.
   For example:
      network     internet subnet
      -------     ---------------
     ethernet1      128.255.32
     ethernet2      128.255.22
     ethernet3      128.255.20
     Apollo ring    128.255.21


Problems

   The presence of independently administered networks within the  campus
   lends  itself to a subnetting scheme, with each department receiving a
   block of subnet  numbers  from  which  to  allocate  numbers  for  the
   networks  under  the  control  of the department.  We have encountered
   some routing problems which may be attributable to the coexistence  of
   IP  implementations  which  do  support  subnetting and those which do
   not.

   The broadband bridging makes ethernet1 and ethernet2 appear to be  one
   physical  network,  so we end up with one network having more than one
   subnet number.  This seems to cause  problems  with  routing  for  the
   hosts  which understand subnetting.  They think the hosts on the other
   subnet should be on a different physical network and expect to have  a
   gateway  to  get  there.   Since there is no gateway, they don't see a
   path to the other subnet.

   Disabling subnetting (by changing the netmask to  255.255.0.0  in  the
   subnetting  hosts) makes everybody think that the entire campus is one
   big  physical  (class  B)  network.  This  solves  the  problem   just
   described,  but it defeats the subnet-based routing required to access
   the networks which are actually subnetted,  such  as  Apollo-ring  and
   ethernet3.

   One proposed solution is to place a router between the  IB/1  and  the
   networks  within  each  department.   This has the advantage of making
   the broadband a separate subnet and providing the gateways  (arguably)
   needed  for  subnet-based  routing  as described above.  Disadvantages
   include the decrease in throughput (compared to just the bridge),  the
   added  cost  of  the router (or an additional ethernet interface for a
   host acting as a router), and the restriction on the  protocols  which
   may  then  cross  the broadband.  Furthermore, I am not convinced that
   such a configuration would solve all our problems without  introducing
   new ones.



Jay Ford
Weeg Computing Center
University of Iowa
Iowa City, IA  52242
(319) 335-5555

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 13:28:00 EST
From:      ALMA@RVAX.CCIT.ARIZONA.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   RE: Re: TCP-IP in the Public Domain?


	The complete address for SRI is:

	Stanford Research Inst. - Net. Info. Center
	Room EJ291
	333 Ravenwood Avenue
	Menlo Park, CA  94025

	Tele#  415-859-5539

	alg.

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 13:51:12 EST
From:      hedrick@ATHOS.RUTGERS.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Terminal server efficiency

Our tests also showed that a small window can significantly increase
the CPU time on hosts that are talking to a terminal server.  Thus I
regard small windows as a significant problem.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 14:14:48 EST
From:      hubcap@gatech.UUCP
To:        comp.protocols.tcp-ip
Subject:   perpetual connection


I wonder what's going on here?

I am not sure how long this has been going on, but I have noticed the 
following connection between my machine and utah-arpa-gw.arpa for the 
last few days: (edited output of "netstat -a" follows...)
----------------------------------------------------------------------------
Active connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
                         .
                         .
                         .
tcp        0      0  hubcap.clemson.e.2462  utah-arpa-gw.arp.telne FIN_WAIT_2
                         .
                         .
                         .
----------------------------------------------------------------------------

Note: sometimes the state is "ESTABLISHED", other times, FIN_WAIT_2...

I was curious at first when I saw it, but there's lots of users here, and
its none of my business where they telnet to... then I noticed that this
connection was still present immediately after a reboot.

So, to make a long story short, this connection has been here constantly 
for at least a week (probably longer).

Does anyone want to hazard a guess as to what the deal might be?

thanks...

Mike Marshall      hubcap@hubcap.clemson.edu        ...!hubcap!hubcap

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 15:02:59 EST
From:      terrell@musky2.UUCP
To:        comp.protocols.tcp-ip,comp.sys.mac
Subject:   Does CMU TCP/IP work with MacIP?


We are trying to get CMU's TCP/IP package to work with MacIP via
ethernet with the Kinetics FastPath box.  So far, all I have succeded
in doing is causing the name server to die (ODD ADDRESS EXCEPTION) on
the VAX end (where the CMU package is running).  To begin with, are
the two compatible at all?  This is the first time we have experimented
with networking, so no one here is very familiar with it.  Any further
info anyone might have on using either package would also be helpful.

Please send responses by E-mail if possible.

Thanks,

Roger


-- 

Roger Terrell
Muskingum College			...cbosgd!musky2!terrell (UUCP)
New Concord, OH  43762

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 19:20:28 EST
From:      hinden@PARK-STREET.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

Mike,

I enjoyed you reference to HMP being in the "Massachusetts" layer.  It
might be more accurate to say that it is in the Massachusetts "stack" :-).

I do think it is correct that is should be shown as a transport layer
protocol.

EGP, GGP, and other similar internet protocols provide services
normally thought of as in the transport [, presentation ?] and
application layers.  The output of these protocols are used to provide
routing data for the internet layer.  I don't think that this puts
them in the internet layer.

Bob

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 19:27:05 EST
From:      craig@NNSC.NSF.NET.UUCP
To:        comp.protocols.tcp-ip
Subject:   dial-up SLIP


At CSNET we're experimenting with an idea which is close to this.

The basic idea is that when an IP packet hits our gateway destined
for a remote machine  we make a phone call, establish the link, and
keep it running as long as there is continued traffic.  When the
traffic stops, we shut down the line.

There are lots of nasty little problems in this scheme:
    
    - The TCP SYN takes a huge hit for establishing the phone call.
    So the initial RTT estimate will be much too high.

    - Topology.  That SYN probably can't take multiple hops in which
    the phone gets dialed.  (We're using a star topology with gateway
    in the center).

    - How to maintain line quality.  We know how variable long-distance
    connectivity is.

Interestingly, keeping track of when the line is busy probably isn't a
problem (we already had to handle that problem in X25Net).

Also note that this system is designed to support more than IP.  We want to
be able to use more than IP over the interface (line control packets, ISO IP,
XNS, etc).  So we had to put leaders in.

Finally, address mapping is fixed.  Each address is assigned, and we
do a deterministic IP address to phone # mapping to do the phone call.
We then log in at the remote end, and start up the line protocol.

Craig

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 19:48:16 EST
From:      cetron@CS.UTAH.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: perpetual connection




	I just check out cisco box (utah-arpa-gw) and it had two idle 
incoming sessions from hubcap.clemson.edu showing idle for 3 days+ and
originating at hubcap.  It appears like somebody is telnetting to our
gateway, and then into some other machine.... This may be because with
the egp/ggp problems, the can't reach the 128.110.xx.xx addresses any
other way. 

	Given the load on our cisco, and assuming there is a legitimate
user at clemson trying to telnet into our 128.110 net, I would think that
a static route (oh how horrible :-) ) would be better then tying up band-
width in the gateway.  

	Any comments from the net at large?

-ed cetron
cetron@cs.utah.edu

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19-Nov-87 23:22:46 EST
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Terminal server efficiency

If the window is smaller than the MSS, the MSS doesn't matter much - you'll
never see a packet bigger than the window.  I have observed the 164-byte
window feature in Bridge, and the fact that at least one of their products
only sends 82 bytes (I hesitate to guess why..) in a packet, no matter how
much output is pending.  This is a box that serves as a milking machine,
attached to a host via async lines.

I think window (or MSS, whichever is the limiting factor) is an important
consideration.  I have found that it affects throughput a lot, even in
telnet output situations.

jbvb

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 00:08:38 EST
From:      haverty@CCV.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

To throw mny two cents in...

I think HMP isn't "in the stack" at all, in the sense that it is NOT part
of a user data communications activity.  HMP is an application top level
protocol, between an entity at one end, i.e., the monitoring/management
operation, and an entity at the other end, i.e., the piece of code down within
some computer somewhere that is watching the activity within that computer
and interacting with the management site.  IN other words, the participants
in HMP are just like any other network users such as FTP or a data query
and retrieval system; it just happens to be the case that their activity is
associated with the operational management of a communications system.  Consider
for example if an HMP-like protocol were used to monitor the CPU-load and
disk-activity of a distributed collection of Unix systems, i.e., like
a constantly running remote "dpy" or "ps". In this case it's pretty clear that
the protocol between the players is an application in itself; HMP differs only
in that it is looking at the operation of components of a data communications
system.

Jack

PS to Dave Mills -- I do "read the mail" on the list all the time, just
a little slow in diving in.

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 03:32:00 EST
From:      LAWS@rsre.mod.UK.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

Vint,
 
I have a different view about the ISO model. Its apparent rigid
specification of functionality is only on issues that were seen
to be needed to have open systems - any vendor host to any vendor
host via any network provider. That said there is in fact enough
protocol choice in the layers that communities of interest are
selecting 'protocol stacks' to limit the number of protocols
required in a single host.
 
When networks were seen by the standards makers as being just the
public utility of CCITT there was no need to make ISO standards for
how to build or manage the network. CCITT would do that. It is now
accepted that other network providers will exist in great number (well
at least in the UK and US). Hence public standards must be stated for
the management of this internet. Note: the assumption is still that
a single vendor will provide the subnet and hence we do not require
public standards for that internal issue.
 
I agree its probably the case that my view is not the common one
stated by ISO experts. But look at the selling problem they had. If
you and I are to have choice in our vendors and still communicate
then standards are required. The scale on which this has/had to be 
done is very large relative to run-of-the-mill standards. (By-the-by
I happen to think the OSI work has been done in double quick time;
checkout the timescale for standards on slings and hooks.) Just as
in politics, large market, complex issues, limited time = keep the
message simple.
 
Now there are two sorts of OSI experts - those who really are and
often have dirty hands and scars from past experience, and those
who have read the 'books' from their armchair. The first may cut
corners to put the message across in a few minutes but know its 
more complex. The second only know what is in the 'books'.
 
My experience of standards committees UK BSI and ISO is that most
members working on OSI are the first. And just so that there is no
mis-understanding between us I do see you as being dead centre (center
- I'm bilingual) in the first. (That goes for Mike Padlipsky as well
- who if on form is composing a refutation of all I've said.)
 
(To all you other readers - this makes a change to reading how the
Internet is being RIPped apart.)
 
Does the US State Dept read this list? Will my A-2 VISA be revoked?
 
John

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 87 06:52:13 -0500
From:      Jeffrey C Honig <jch@devvax.TN.CORNELL.EDU>
To:        mqh@tcgould.tn.cornell.edu (Mike Hojnowski)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: FIN problem in Berkeley 4.3?
>We're running a Gould here with Berkeley networking code.  It would appear
>that when a TCP connection is closed, and the FIN is retransmitted for some 
>reason, it's sequence number is one too low.  The sequence number is correct
>on the first transmission.  

>I've looked into "tcp_output.c", and it is marked as "7.2.1.1 ... 3/28/87".
>The code looks correct by casual inspection, at least.

>Can anyone shed some light on the problem before I spend time trying to 
>debug this in UNIX? 

Applying the following fix (in Mike Karel's form) fixed many symptoms of
this problem on a uVAX running 4.3.

Jeff
----------------
>From cpw Tue Sep  1 09:00:12 1987
>To: tcp-ip@sri-nic.arpa
>Subject: Help with broken TCP

>What follows is a TCP scenario observed on our local ethernet.  The ftp
>application (A) has just pushed out the last data block to (B) and is
>closing the connection.  The first FIN from (A) is lost.  An ACK from (B)
>for the last data block arrives. Then there begins a conversation of FIN(A)
>then ACK(B) with longer and longer time intervals between each set of
>FIN(A)/ACK(B) as if the ACK is being dropped and a retransmit timer is
>backing off, firing and a FIN being sent.  Notice that the sequence number
>set in the retransmitted FIN packets is one less than that set in the lost
>FIN packet.  Are both peers broken or just the sender of the FINs?

>This is a tcpdump.  I added an * to indicate the lost packet.  (In case
>your curious, the packet is lost because of an inability to handle back
>to back packets on the part of B)

>15:31:36.86  A > B: S -1063845887:-1063845887(0) win 4096 <mss 1024>
>15:31:36.86  B > A: S 253698321:253698321(0) ack -1063845886 win 384 <mss 1024>
>15:31:36.86  A > B: . ack 1 win 4096
>15:31:37.12  A > B: P 1:146(145) ack 1 win 4096
>15:31:37.12  A >* B: F 146:146(0) ack 1 win 4096
>15:31:37.38  B > A: . ack 146 win 384
>15:31:39.12  A > B: F 145:145(0) ack 1 win 4096
>15:31:39.14  B > A: . ack 146 win 384
>15:31:41.12  A > B: F 145:145(0) ack 1 win 4096 urg 1
>15:31:41.14  B > A: . ack 146 win 384
>15:31:45.12  A > B: F 145:145(0) ack 1 win 4096 urg 1
>15:31:45.14  B > A: . ack 146 win 384
>15:31:53.12  A > B: F 145:145(0) ack 1 win 4096 urg 1
 
>and so on...

>Phil Wood  (cpw@lanl.gov)

--------

>From cpw Tue Sep  1 14:28:46 1987
>To: tcp-ip@sri-nic.arpa
>Subject: Re: Help with broken TCP
>Status: RO

>4.3BSD network bug (#9, tcp_output) had a fix for an undetected data
>loss during connection closing.  This may well have fixed the data loss
>due to lost data segments, but, apparently it will cause the symptom
>I reported if the data segment with FIN is lost.  If the test:

>	if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && len == 0)
	
>succeeds the #9 code decremented tp->sndnxt by one.  Instead, I set
>tp->snd_nxt = tp->snd_una, and the symptom went away.   I'm not saying
>this is a fix, but it may point more to the problem.

>Phil Wood  (cpw@lanl.gov)

Here is a partial diff of the fix I have to tcp_output.c.
*** tcp_output.c.orig   Fri Apr 24 12:29:11 1987
--- tcp_output.c        Wed Sep  2 12:29:09 1987
*** 231,237 ****
         * If resending a FIN, be sure not to use a new sequence number.
         */
!       if (flags & TH_FIN && tp->t_flags & TF_SENTFIN &&
!           tp->snd_nxt != tp->snd_una)
                tp->snd_nxt--;
        ti->ti_seq = htonl(tp->snd_nxt);
        ti->ti_ack = htonl(tp->rcv_nxt);
--- 237,246 ----
         * If resending a FIN, be sure not to use a new sequence number.
         */
!       if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && len == 0)
!               tp->snd_nxt = tp->snd_una;
        ti->ti_seq = htonl(tp->snd_nxt);
        ti->ti_ack = htonl(tp->rcv_nxt);
***************

-------------------

>From: Mike Karels <karels%okeeffe@berkeley.edu>
>To: "C. Philip Wood" <cpw%sneezy@lanl.gov>
>Cc: tcp-ip@sri-nic.arpa
>Subject: Re: Help with broken TCP 
>Date: Tue, 01 Sep 87 15:33:38 PDT

>Right you are!  I knew that we had such a problem at one time, but didn't
>think it had made it out of Berkeley.  Your fix is fine; our current version
>does:
>	if (flags & TH_FIN && tp->t_flags & TF_SENTFIN &&
>	    tp->snd_nxt == tp->snd_max)
>		tp->snd_nxt--;

>which should be equivalent.

>		Mike
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 87 00:32
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@NSS.Cs.Ucl.AC.UK>
To:        CERF <@NSS.Cs.Ucl.AC.UK:CERF@a.isi.edu>
Cc:        tcp-ip <@NSS.Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa>, oconnor <@NSS.Cs.Ucl.AC.UK:oconnor@sccgate.scc.com>
Subject:   Re: Idle chatter about reference models
Vint,
 
I have a different view about the ISO model. Its apparent rigid
specification of functionality is only on issues that were seen
to be needed to have open systems - any vendor host to any vendor
host via any network provider. That said there is in fact enough
protocol choice in the layers that communities of interest are
selecting 'protocol stacks' to limit the number of protocols
required in a single host.
 
When networks were seen by the standards makers as being just the
public utility of CCITT there was no need to make ISO standards for
how to build or manage the network. CCITT would do that. It is now
accepted that other network providers will exist in great number (well
at least in the UK and US). Hence public standards must be stated for
the management of this internet. Note: the assumption is still that
a single vendor will provide the subnet and hence we do not require
public standards for that internal issue.
 
I agree its probably the case that my view is not the common one
stated by ISO experts. But look at the selling problem they had. If
you and I are to have choice in our vendors and still communicate
then standards are required. The scale on which this has/had to be 
done is very large relative to run-of-the-mill standards. (By-the-by
I happen to think the OSI work has been done in double quick time;
checkout the timescale for standards on slings and hooks.) Just as
in politics, large market, complex issues, limited time = keep the
message simple.
 
Now there are two sorts of OSI experts - those who really are and
often have dirty hands and scars from past experience, and those
who have read the 'books' from their armchair. The first may cut
corners to put the message across in a few minutes but know its 
more complex. The second only know what is in the 'books'.
 
My experience of standards committees UK BSI and ISO is that most
members working on OSI are the first. And just so that there is no
mis-understanding between us I do see you as being dead centre (center
- I'm bilingual) in the first. (That goes for Mike Padlipsky as well
- who if on form is composing a refutation of all I've said.)
 
(To all you other readers - this makes a change to reading how the
Internet is being RIPped apart.)
 
Does the US State Dept read this list? Will my A-2 VISA be revoked?
 
John
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 05:49:31 EST
From:      raj@limbo.uci.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet versions

I got this from the little booklet that comes with our ST-500 transceivers
that we bought from Cabletron.  (Cute, each one comes with a really complete
book telling all sorts of things about transceivers and such.)

We always make sure our transceiver cables have pin 1 connected to ground.
(Our Computing Facility used to connect pin 4 to ground to agree with 802.3
but then they couldn't be used on V2.0 so we always get pin 1 as ground now.)
We've used the same transceiver cables on V1.0, V2.0, and 802.3.  We have
mixtures of all versions on the same ethernet with no problems although we're
now trying to always go with 802.3 in the future.

Hope all of this helps.


		V1.0			V2.0			IEEE 802.3
-----------------------------------------------------------------------
Transceiver	(3) 22 AWG pairs	(4) 20 AWG pairs	(4) 20 AWG
cable		(1) 20 AWG inner	Inner & outer		pairs
		& outer shield		shield common		Inner & outer
		common at		at backshell		shield isolated
		backshell and		and pin 1		from each other
		pin 1						Outer shield at
								backshell,
								inside at pin 4
								Indented male
								connector for
								better
								electrical
								connection.

Transceiver	Full step		Half step		Half step
		No heartbeat		Heartbeat		Heartbeat

(SQE)
  Grounding	Pin 1			Pin 1			Pin 1, 4, 11 &
								14
								Ground indents
								on male
								connector.
								Jabber latching


Repeater	No requirements		No requirements		Redundant
								collision
								protection
								using Jam
								sequence,
								Segments
								excessive
								collision
								segment from
								network.


Vendors		Xerox, U-B,		DEC			U-B, 3COM, DEC,
		Gould, Harrris,		Cabletron		HP, Xerox,
		Cabletron					Micom-Interlan,
								Intergraph,
								Cabletron

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 07:46:13 EST
From:      gnu@hoptoad.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: dial-up SLIP

UC Davis was doing a summer project with dialup slip.  Their software
is available on ucdavis.ucdavis.edu in the "pub/dialslip" directory, as
I recall (don't you hate it how NOBODY gives a full and correct path
for stuff available by anonymous ftp?).  I haven't tried any of it yet.

	John

Here's the README from ucdavis:

This  directory contains the  first distribution of  software used at UC 
Davis  for dialin  SLIP connections  for the  UCD Network.  The complete 
system  is a combination of patches for  4.3bsd and the CMU/IP software, 
plus  new software for the dialin capability. The software comes in five 
tar files. Here is a description of what is in each tar file. 

1. tiocgetu.tar 

This  file contains  patches and  a new  function for  the 4.3bsd  IO. A 
problem  existed with  4.3 in  the linkage  of a  SLIP interface and the 
actual  device. The problem was  this: The normal procedure  to set up a 
SLIP  was  to  ifconfig  the  interface  to  the desired parameters then 
slattach  the device to this interface, BUT  the slattach just grabs the 
first  available interface which may or may not be the one that you just 
ifconfig'ed.  This  really  becomes  a  problem  when multiple SLIPs are 
comming  and going randomly. To solve this problem, a patch was added to 
slattach  to return the interface to which the device was connected. The 
returned  interface  can  then  be  ifconfig'ed  AFTER slattach has been 
connected  to  it.  This  makes  sure  that  the  associated  device and 
interface  are coordinated. To make  things even easier, there  is a new 
function  included in this tar that does the the whole process, slattach 
and ifconfig, in one call. 

2. dialslip.tar 

This  file contains  the software  necessary to  manage the  dialin SLIP 
connections.  The procedure  for establishing  a SLIP  connection is  to 
logon  to the 4.3 computer and enter the slip command. After the command 
has  been issued, the  line becomes a  SLIP connection. Disconnection is 
accomplished  when the serial connection is lost (no carrier detect) and 
the  line is then reset  to a normal login  line. Address assignment and 
security  is provided by a  file that associates an  IP address with the 
usercode.  A connection for a given IP address can only be made from the 
usercode to which that address is assigned in the configuration file. Of 
course the computer dialing in must also be configured for this address. 
The  software also maintains a  file of current connections  that can be 
displayed to see wht SLIP connections are currently logged in. This file 
is  also used  by the  system to  make sure  that the  IP address is not 
already connected before making a new connection. If a person logs in on 
the same usercode twice at the same time, only the first SLIP connection 
will succeed. NOTE: the patches in tiocgetu.tar must be installed before 
the software in this tar will work. 

3. cmuslip.tar 

These  are patches to the CMU/IP software that do two things. One, makes 
the com port on the pc setable from the CUSTOM program, and two, fixes a 
bug  that  would  briefly  drop  DTR  on  the  com  port  during  a SLIP 
connection. (for us that caused immediate disconnection :-}) 

4. sterm.tar 

This  is the CMU/IP terminal program with a script capability added. The 
script  can be setup to allow connection to the network by automatically 
sending  the sequence needed to dial the modem, logon, and send commands 
to connect to SLIP. The script can also wait for given strings to return 
to  allow testing, timing out, and  branching depending on what response 
is returned. 

5. cmumakes.tar 

This  file contains a new set of MAKE files for the CMU/IP software that 
are better (or at least different) than the standard ones. This tar also 
contains  a new tarread program that allows extraction so subsets of the 
files in a tar file. 


The  abbreviated IP packet  software working but  still has a  couple of 
bugs  we want  to get  out before  releasing it.  It should  be ready in 
another  week or so, but we wanted to make this available for those that 
want to get started. 


                                Russell Hobby               
                         Data Communications Manager 
     U. C. Davis                 
     Computing Services       BITNET:    RDHOBBY@UCDAVIS 
     Davis Ca 95616           UUCP:      ...!ucbvax!ucdavis!rdhobby 
     (916) 752-0236           INTERNET:  rdhobby@ucdavis.edu
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
Love your country but never trust its government.
		      -- from a hand-painted road sign in central Pennsylvania

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 07:54:12 EST
From:      gnu@hoptoad.UUCP
To:        comp.protocols.tcp-ip
Subject:   Instructions for creating a SLIP link

{I wrote these as an addendum to Mark Weiser's instructions for installing
slip into a binary Sun kernel, since he forgot to mention anything but
the kernel modification.  Mark's SLIP is available on mimsy.umd.edu.}

The SIOCIFDETACH definition above should use a number that is not already
in use; more recent Sun releases have already used ioctl (i, 23), so
just pick a number beyond the last one they used.  Also, make sure that
both /usr/include/sys/ioctl.h and /usr/sys/h/ioctl.h are updated.
They may be links or symbolic links, or may be separate files.

The code I use has a fix from Chris Torek folded in, which improves the
handling of when to start and stop the serial port.  It also has the
"sldetach" routine added to the end of the source, though I believe
it is not called from the right place(s), or is not right, since
you still end up burning an interface every time you lose a SLIP
connection.

The above description assumes you know how to configure a Sun or BSD
kernel.  If you don't, look in the system installation manual, it gives
detailed instructions on this.  You will have to make the changes
specified above by Mark, (except the "pseudo-device" line), then do the
kernel configuration process as documented in the manual, inserting the
"pseudo-device" line into your custom config file.  Run "/etc/config"
then "make" then move the new kernel into the root directory, as e.g.
"/vmunix.new".  You will also have to allocate a bunch more "character
lists (clists)" which are buffers for the serial ports -- you are
driving these ports heavier than usual.  Easiest way to do this is by
patching your new kernel with adb before booting it.  Do something
like:

	adb -w /vmunix.new << FOO
	nclist?D				-- display old value
	nclist?W 0t500				-- change to decimal 500
	FOO

Shut down the system with /etc/fasthalt, then boot it from the new
kernel (b /vmunix.new).  If it comes up and doesn't crash, things are
in pretty good shape.

Now to set up the slip link, compile "slattach" on both ends, then make
sure the serial line between the machines is working (e.g. using "tip"
on both ends, you should be able to type back and forth to each
other).  You will need to assign a network number (or subnet number, if
your machines are using subnets) for the serial link itself; it is
treated as a network with two hosts on it.  Update /etc/networks on
both systems with this number, and create new names for your two hosts
(typically the original hostname plus a suffix like "-slip", e.g.
"hoptoad-slip") in /etc/hosts, which have addresses on this new
network.  For example:

/etc/networks:
sun-ether	192.9.200	sunether ethernet localnet
sliplink	192.33.33
srinet		128.18

/etc/hosts:
# The Ethernet at one end
192.9.200.1	hoptoad hop toad loghost mailhost
192.9.200.2	polliwog polli wog
192.9.200.3	tadpole tad pole
# The SLIP link
192.33.33.1	polli-slip
192.33.33.2	ws1-slip
# The Ethernet at the other end
128.18.523	fs1
128.18.533	ws1
128.18.534	ws2
128.18.535	ws3

After updating these files at both ends, if you use the Bellow Pages,
remake the database with (cd /usr/etc/yp; make hosts networks).

Then run "slttach" on both ends, specifying the tty line, YOUR machine's
name on the SLIP network, the other guy's name on the SLIP network,
and the baud rate, e.g.:

	polliwog# slattach ttyb polli-slip ws1-slip 19200

	ws1# 	  slattach tty04 ws1-slip polli-slip 19200

You don't have to do these at the same instant.  At this point you
probably have an IP connection going; you should be able to see it
by doing a "netstat -i".

Next, try it with "ping".  Watch the modem lights if you can, while it
pings.  On polliwog you would ping "ws1-slip".  On ws1 you would ping
"polli-slip".  If that works, you can try an rlogin, telnet, or ftp.
If it doesn't work, you should be able to see the packets go out over
the modem "SD" (send data) light, but nothing will probably be coming
back in on RD.  That means the other end is not answering, so look
there -- try netstat -i, ping from that end, etc.  Be sure you specified
the right parameters on both ends.

You can pass packets now, but hven't figured out routing.  If you are
running "routed" on both machines, routed should figure out the routing
for you.  Within a minute or two of when the link comes up, a "netstat -r"
should show a route to the remote Ethernet via the "sl0" interface on your
machine.  If you aren't running routed, you'll need to do "route add"
commands.

If one end is on the Arpa Internet, there are further complications.
If any of your network numbers aren't known to the core gateways, other
hosts will not be able to route packets to you.  The main Internet
gateways *do not* automagically notice new networks and figure out the
routes, like Berkeley "routed" does.  Somebody with the authority to
tell them, has to tell them that you exist.  If your SLIP network and
your remote Ethernet, if any, are both subnets, then the normal Internet
routing will get your packets back to your subnet, and you just have to
make sure that the gateways inside your subnet know how to get to you.
If all your gateways run "routed" this should happen automatically.
You may want to add a "default route" on your remote Ethernet hosts
which routes packets for any random network through the host on the
Arpanet end of the SLIP link; this way you won't have to run a routing
daemon to be able to talk to any network on the Internet.

If the link goes down, you will probably have to reboot both systems
to get them back in sync.  The slip drivers are not robust enough, and
can crash the system if you try to re-establish a link after you had
one running.  I think it'd be great if you fixed this...I don't know
enough about what is going on to do so.

I have tried running NFS over a SLIP link with Telebit 18,000 baud
modems.  It hung or crashed my systems until I allocated a bunch more
"clists" (character queues for serial ports), as described under kernel
configuration above.  I did get NFS to work over the SLIP link though.
It was not very fast, it didn't feel much like a disk, but if you are
careful what you touch, it can be better than FTP and rcp for moving
things around.  I recommend unmounting things when not in use, lest
people stumble on them and create immense amounts of traffic
inadvertently.  For example, most peoples' systems run a "find" command
that scans the whole file system once a night.  I recommend mounting
file systems "intr" and with small blocks (512 bytes) and long timeouts;
see the "mount" command man page.

Good luck!  This has been typed at about a month's remove from the last
time I did it, so there may be errors in the procedures.  If so, please
send me email (gnu@toad.com, or hoptoad!gnu).  Feel free to pass it on
to other people.  Mark owns the code and allows it to be distributed;
and this description, by me, is in the public domain.  Also, let me know
if you successfully set up a SLIP link with these instructions -- or,
even better, figure out how to let dialin users set up and tear down SLIP
links on demand.

	John Gilmore
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
Love your country but never trust its government.
		      -- from a hand-painted road sign in central Pennsylvania

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 08:48:29 EST
From:      mac@MONK.PROTEON.COM (Michael A. Curtis)
To:        comp.protocols.tcp-ip
Subject:   in.routed dying

Doug,

	I was going through my old messages and came across this one
from you.  Are you still having problems with routed dying in your Sun
machines?


Mike Curtis
Proteon, Inc.

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 87 12:25:00 PST
From:      "Keith McCloghrie" <kzm@twg.arpa>
To:        "ddp+" <ddp+@andrew.cmu.edu>
Cc:        <tcp-ip@sri-nic.arpa>,<kzm@twg.arpa>
Subject:   Re: new BOF
Drew,

You say :

> I am conducting a BOF at the upcoming TCP/IP conference in Arlington VA
> called "Standard socket level interface for PC's".  

Are you specifically entitling the BOF such that discussion of interfaces
other than socket-style, are out of order ?

There have been some alternative suggestions which I think are worthy of
discussion (eg. TLI, a standard driver interface).

Keith McCloghrie
The Wollongong Group.

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 10:03:14 EST
From:      radia@XX.LCS.MIT.EDU (Radia Perlman)
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

The Network Layer in ISO already has lots of sublayers, with
catchy names like "Subnetwork Independent Convergence Protocol".
With hierarchical routing, there's really a Network Layer sublayer
dealing with each level of hierarchy.  When you (according to
ARPA terminology, I think) interconnect networks into an internetwork,
I'd say you're just forming another layer of hierarchy on your network.
That extra layer does involve adding a protocol layer onto what used
to be your Network Layer.  But it certainly doesn't go into
the Transport Layer.  It just makes your Network Layer fatter (makes
a Network Layer that used to have k sublayers now have k+1 sublayers.)

In general I agree that trying to take the ISO Reference Model too
seriously leads to nonproductive metaphysical discussions, but I don't
think hierarchical routing at the ISO Network layer breaks the model.

Radia
-------

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 13:01:21 EST
From:      brad@cayman.UUCP (Brad Parker)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Lawrence Livermore IGP project?

References:


Does anyone have any information on the Lawrence Livermore Lab
Intelligent Gateway Processor (IGP) project?

I have an abstract called "Gateway Technology as a Tool for Interoperability
in the DAITC Information Network" and I'd like to get more information on
this.

Thanks.

ps: when I was a kid we called it the "rad-lab"! I guess LLNL sounds better...

-brad

Brad Parker
Cayman Systems
harvard!cayman!brad
-- 

Brad Parker
Cayman Systems			"Mama's little baby likes violent sex..."
harvard!cayman!brad			   - from a song I heard on the radio.

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 13:33:20 EST
From:      mckee@MITRE.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Networks & vendor upgrades/fixes

In your note to nowicki@sun.com you described the difficulty of
installing a new release and concluded with:

>All of which is why many organizations which are setting up large networks
>want homogenous hardware, rigid version control, and source code.  Perhaps
>the manufacturers should put on their thinking caps...

I would like to understand the underlying rationale for your
recommendations concerning source code, rigid version control, and
homogenous hardware.  I offer my speculations below and would like 
you to confirm/revise.

Source Code: So that an organization can fix/improve the code
themselves, or by a third party, and not have to depend on the original
vendor.  Does your recommendation change if software maintenance is in
effect?

Rigid Version Control: This has more to do with the organization's
network than with vendors.  The organization doesn't want two different
versions of the same process to be in use. 

Homogenous Hardware: This one troubles me - I would like to think that
through the use of standard protocols an organization could achieve
interoperability among different hardware suites.  What is your view of
the matter?

Regards - Craig

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 15:00:29 EST
From:      geof@imagen.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   BSD 4.3 Sends data after FIN?

I have a bug report from France (so it's not as clear as I'd like) that
looks like 4.3 is sending data past a FIN.  There is some error condition
being exercised relating to a zero window, and the connection is terminated.
A FIN appears with data in the packet.  It is acked.  Later, another
packet is received with the same length (I don't know whether it is the
same data), with the updated sequence number, and still with a FIN.  Thus
the data is logically after the first FIN.

Can someone check this out?

- Geof

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 15:04:09 EST
From:      BOARD@BITNIC.BITNET (BITNET Board of Trustees)
To:        comp.protocols.tcp-ip
Subject:   BITNET-Internet Gateway

The City University of New York, Princeton University, Cornell University, and
Massachusetts Institute of Technology have each committed to provide gateway
service for electronic mail between the BITNET network and the Internet.

Current gateway services provided by the University of Wisconsin (WISCVM) will
end on December 15, 1987.  Prior to that date, at least two of the above
announced gateways will be in operation in parallel with WISCVM - there will
be no interruption in gateway services.

Prior to a regionalization plan and significant coordination with the
Internet, the most expeditious approach is to name the first few gateways the
same, namely, INTERBIT.  That would mean that any gateway-destined mail that
landed at any INTERBIT node would be appropriately handled.  This change will
be reflected in the December DOMAIN NAMES file which is used for MAILER
generation; users need not do anything - mail will go automatically to the
closest gateway.  This is a transition measure necessitated by the time frame,
by the complexity of more desirable solutions, and by the need to coordinate
more with the Internet.

Plans are to regionalize gateway service between the networks in order to
balance traffic flow and increase reliability.  Several other institutions are
seriously considering functioning as gateways.  An analysis of topologically
best locations for such gateways will be conducted under the auspices of the
BITNET Board of Trustees' Technical Committee; and the BITNET Network
Information Center will coordinate regionalization plans and associated
software modifications.

(Please note reference to Internet, rather than ARPANet, and Internet's
inclusion of ARPANet, NSFNet, NYSERNET and the other regional networks.)


BITNET Board of Trustees

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 15:13:59 EST
From:      geof@imagen.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   BSD 4.3 Terminates zero window connection

A customer has reported that BSD4.3, if it is presented with a zero window,
tries ONCE to push data through the window.  If it receives no response,
it closes the connection.  There is a language problem between me the
customer and the manuals, so maybe I don't understand what they are
saying.  Does this match 4.3 behavior?

- Geof

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 15:25:00 EST
From:      kzm@TWG.ARPA ("Keith McCloghrie")
To:        comp.protocols.tcp-ip
Subject:   Re: new BOF

Drew,

You say :

> I am conducting a BOF at the upcoming TCP/IP conference in Arlington VA
> called "Standard socket level interface for PC's".  

Are you specifically entitling the BOF such that discussion of interfaces
other than socket-style, are out of order ?

There have been some alternative suggestions which I think are worthy of
discussion (eg. TLI, a standard driver interface).

Keith McCloghrie
The Wollongong Group.

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 16:34:03 EST
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   RE: Re: TCP-IP in the Public Domain?

I would like to correct Alma's previous message regarding the complete
address for the Network Information Center at SRI International. Our address
is:

DDN Network Information Center
SRI International
Room EJ291
333 Ravenswood Avenue
Menlo Park, Ca.  94025

Our telephone numbers are:
(800) 235-3155
(415) 859-3695

Nan/NIC
-------

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 87 16:04:09 EDT
From:      BITNET Board of Trustees <BOARD%BITNIC.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   BITNET-Internet Gateway
The City University of New York, Princeton University, Cornell University, and
Massachusetts Institute of Technology have each committed to provide gateway
service for electronic mail between the BITNET network and the Internet.

Current gateway services provided by the University of Wisconsin (WISCVM) will
end on December 15, 1987.  Prior to that date, at least two of the above
announced gateways will be in operation in parallel with WISCVM - there will
be no interruption in gateway services.

Prior to a regionalization plan and significant coordination with the
Internet, the most expeditious approach is to name the first few gateways the
same, namely, INTERBIT.  That would mean that any gateway-destined mail that
landed at any INTERBIT node would be appropriately handled.  This change will
be reflected in the December DOMAIN NAMES file which is used for MAILER
generation; users need not do anything - mail will go automatically to the
closest gateway.  This is a transition measure necessitated by the time frame,
by the complexity of more desirable solutions, and by the need to coordinate
more with the Internet.

Plans are to regionalize gateway service between the networks in order to
balance traffic flow and increase reliability.  Several other institutions are
seriously considering functioning as gateways.  An analysis of topologically
best locations for such gateways will be conducted under the auspices of the
BITNET Board of Trustees' Technical Committee; and the BITNET Network
Information Center will coordinate regionalization plans and associated
software modifications.

(Please note reference to Internet, rather than ARPANet, and Internet's
inclusion of ARPANet, NSFNet, NYSERNET and the other regional networks.)


BITNET Board of Trustees
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 17:33:10 EST
From:      andrew@mitisft.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: dial-up SLIP

in article <8711192329.AA03145@ucbvax.Berkeley.EDU>, craig@NNSC.NSF.NET (Craig Partridge) says:
> 
> 
> At CSNET we're experimenting with an idea which is close to this.
> 
> The basic idea is that when an IP packet hits our gateway destined
> for a remote machine  we make a phone call, establish the link, and
> keep it running as long as there is continued traffic.  When the
> traffic stops, we shut down the line.
> 

	We've had dial-up SLIP running for over a year internally
here at Convergent, initially on a more-or-less straight 4.3 port
and currently on a Streams port.

	It works, basically, by having a deamon which is woken up
when the routing code chooses a "dialed" (more generally, switched)
route.  It then calls into a bunch of UUCP code to establish the
connection, and logs in to an account which runs the daemon in
"server mode".  The "client" then informs the "server" of who he is
(ascii), his numeric address, and what he thinks the server's numeric
address is. The server checks his host and authentication files, they
synchronize and slattach, and the deferred packets are sent.
After that its peer-peer, until a timeout occurs with active TCP
or carrier loss.

	I still consider this to be in the experimental phase, primarily
in the routing area.  Currently the system uses the "gateway" model;
no net number is assigned to the link itself, an each system sort of
thinks it has an interface on the nets connected to the remote.

	The inital connection protocol is pretty crude -- just an exchange
of cute little text messages.  Eventually I'd like to add some simple
error checking, though the problems there have been minimal so far.
We use it over our PBX to comminiacte between biuldings here regularly,
at 19200 baud.

Andrew Knutsen
(408) 435-3623
I'm also planning on testing with the new high speed modems.

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 17:33:44 EST
From:      stevens@hsi.UUCP (Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   tn3270 and IBM's TCP/IP for VM/CMS

We're a VAX 4.3 BSD site with an existing TCP/IP LAN between three
VAX'es and a bunch of PCs.  We're about to get an IBM 9370 that will
run VM and are interested in IBM's TCP/IP for VM product.  It looks
like we could use the 4.3 BSD tn3270 software for something like an
rlogin access to VM from a VAX, depending on the IBM software.  The
tn3270 README file refers to it being originally developed at Univ.  of
Wisconsin and IBM selling it to commercial sites, but reference is also
made to other, non-compatible TCP/IP implementations for IBM
mainframes.  Does anyone know if the current IBM product (which has
been available only since July 87) is really compatible with tn3270 ??

The IBM Product Sheet that I have also refers to a C language interface
to allow program access directly to the TCP and UDP protocol boundary.
Does anyone have any experience with this ??  I'd assume a program
under VM using this could communicate with a program on the VAX that
was using a BSD socket ??

Finally, the Product Sheet lists the one-time license charges (from $4k
to $16k, depending on processor group) but then indicates that the
source code for this can be obtained for another $350.  This low charge
makes me think the code was developed elsewhere.

	Richard Stevens
	Health Systems International, New Haven, CT
	   { uunet | ihnp4 } ! hsi ! stevens

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 20:08:00 EST
From:      LAWS@rsre.mod.UK.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models


---- Start of forwarded message.

To:      haverty%com.bbn.ccv@NSS
Cc:      "Michael J. O'Connor" <oconnor%com.scc.sccgate@NSS>,haverty%com.bbn.ccv@NSSRobert Hinden <hinden%com.bbn.park-street@NSS>
         tcp-ip%arpa.sri-nic@NSS,,
From:    John Laws (on UK.MOD.RSRE) <LAWS@RSRE>
Date:    Fri, 20 Nov 87 17:04    
Message-Id: <20 NOV 1987 17:04:24 LAWS@RSRE>
Subject: Re: Idle chatter about reference models

Jack,
 
It must be clear from my previous msgs that you and I are as one on this. 
 
I defer to your clearer statement of where HMP is.
 
John

---- End of forwarded message.

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Nov 87 17:08
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK>
To:        haverty <@relay.MOD.UK:haverty@ccv.bbn.com>
Cc:        oconnor <@relay.MOD.UK:oconnor@sccgate.scc.com>, hinden <@relay.MOD.UK:hinden@park-street.bbn.com>, tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: Idle chatter about reference models

---- Start of forwarded message.

To:      haverty%com.bbn.ccv@NSS
Cc:      "Michael J. O'Connor" <oconnor%com.scc.sccgate@NSS>,haverty%com.bbn.ccv@NSSRobert Hinden <hinden%com.bbn.park-street@NSS>
         tcp-ip%arpa.sri-nic@NSS,,
From:    John Laws (on UK.MOD.RSRE) <LAWS@RSRE>
Date:    Fri, 20 Nov 87 17:04    
Message-Id: <20 NOV 1987 17:04:24 LAWS@RSRE>
Subject: Re: Idle chatter about reference models

Jack,
 
It must be clear from my previous msgs that you and I are as one on this. 
 
I defer to your clearer statement of where HMP is.
 
John

---- End of forwarded message.
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 21:34:23 EST
From:      terry@deepthot.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: INFO

In article <8711200139.AA05593@ucbvax.Berkeley.EDU> IO71241@MAINE.BITNET.UUCP writes:
>PLEASE SEND ME INFO ON TCP/IP PROTOCOL

Please send same to me, and any Amiga-specific things on networking too?
                         Thanx,
                            Terry

email: terry@deepthot.UUCP
       terry@deepthot.UWO.CDN
       terry@deepthot.UWO.NETNORTH

post:  Terry Cudney
       4 - 746 Richmond Street,
       LONDON, Ontario
       Canada  N6A 3H3

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 22:43:18 EST
From:      ron@vsedev.VSE.COM (Ron Flax)
To:        comp.protocols.tcp-ip
Subject:   Connecting remote Ethernets?

We need to find the best (best=least expensive & has reasonable
performance...) way to connect two, possibly several, remote Ethernets.

	1)	What hardware is available that can be used 
		to extend the TCP/IP based Ethernet over a 56kbps
		leased line?

	2)	Or possibly a faster/slower telephone circuit?

--
ron@vsedev.vse.com	(Ron Flax)
uucp:	..!uunet!vsedev!ron
inet:	vsedev!ron@uunet.uu.net

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 22:46:56 EST
From:      JNFORDPB@UIAMVS.BITNET (Jay Ford, U of Iowa)
To:        comp.protocols.tcp-ip
Subject:   help

This  is  a  request  for  network  configuration  suggestions.    Any
responses should be sent to me rather than to the list.

Questions

   How have other sites approached and/or solved the problems  associated
   with establishing and administering large campus networks?

   Is the topology outlined below feasible without having static,
   manually-entered routes for the entire campus?

   Will an ARP (or any) ethernet-level  broadcast  from  a  host  on  one
   ethernet  make  it  through  a  gateway to a host on another ethernet?
   Will the ARP reply make it back to the broadcaster?  Is  it  necessary
   to  have  something  along  the  lines of proxy-ARP to make this work?
   Does existing software support proxy-ARP?

   Does anyone have suggestions addressing problems at  any  level  which
   would alleviate some of the routing complexity?


Notes

   We  are  new  at  this,   and   very   well   might   have   incorrect
   interpretations  of  the  problems  we face. By the same reasoning, we
   certainly  are  not  aware  of  all  the  possible  solutions  to  our
   problems.  Any help would be appreciated.  Thank you.


Background

   The University of Iowa is in the  process  of  establishing  a  campus
   network  consisting  of  departmental  LANs  hung  off  of a broadband
   backbone.  The departmental nets use  various  technologies  including
   Ethernet/IEEE   802.3,  proprietary  token  rings,  and  fiber.   Some
   departments have multi-level networks (see figure below).

   Access to the broadband backbone is provided through ethernet  bridges
   (Bridge  IB/1  boxes),  with each department having one IB/1. The IB/1
   is a  MAC-level  bridge,  so  that  a  host  on  a  baseband  ethernet
   connected  to  an  IB/1  in  one  department appears to be on the same
   physical cable as a host on a baseband ethernet connected to  an  IB/1
   in another department.

   We have a mixture of machines and OSs, including VAXes running  4.2  &
   4.3  BSD,  VAXes running VMS, Encores running UMAX 4.2, Apollos, Suns,
   PCs, Primes, and IBMs running MVS; we also have a  handful  of  Encore
   Annex terminal servers.

   The U of Iowa has been granted a class B Internet number  of  128.255.
   We will soon activate a connection to MIDnet -> NSFnet -> world.


Topology

   The current network topology (with only two departments connected) is:

                                      ||                      Annex1 ---|
                                      ||   +------+                     |
                                      ||---| IB/1 |-----(ethernet1)-----|
                                      ||   +------+                     |
                                      ||                     Encore1 ---|
                                      ||
     |--- Encore2                 (broadband)
     |                                ||
     |--- Alliant                     ||
     |                     +------+   ||
     |-----(ethernet2)-----| IB/1 |---||
     |                     +------+   ||
     |--- VMSVax1                     ||   +---------+
     |                                ||---| Proteon |----> (MIDnet)
     |--- Apollo1                     ||   +---------+
             |
            ---
          /     \
        /         \
       (Apollo-ring)
        \         /
          \     /                    |--- BSDVax1
            ---                      |
             |                       |--- BSDVax2
          Apollo2 ----(ethernet3)----|
                                     |--- BSDVax3

   We would like to assign a subnet number to each physical network.
   For example:
      network     internet subnet
      -------     ---------------
     ethernet1      128.255.32
     ethernet2      128.255.22
     ethernet3      128.255.20
     Apollo ring    128.255.21


Problems

   The presence of independently administered networks within the  campus
   lends  itself to a subnetting scheme, with each department receiving a
   block of subnet  numbers  from  which  to  allocate  numbers  for  the
   networks  under  the  control  of the department.  We have encountered
   some routing problems which may be attributable to the coexistence  of
   IP  implementations  which  do  support  subnetting and those which do
   not.

   The broadband bridging makes ethernet1 and ethernet2 appear to be  one
   physical  network,  so we end up with one network having more than one
   subnet number.  This seems to cause  problems  with  routing  for  the
   hosts  which understand subnetting.  They think the hosts on the other
   subnet should be on a different physical network and expect to have  a
   gateway  to  get  there.   Since there is no gateway, they don't see a
   path to the other subnet.

   Disabling subnetting (by changing the netmask to  255.255.0.0  in  the
   subnetting  hosts) makes everybody think that the entire campus is one
   big  physical  (class  B)  network.  This  solves  the  problem   just
   described,  but it defeats the subnet-based routing required to access
   the networks which are actually subnetted,  such  as  Apollo-ring  and
   ethernet3.

   One proposed solution is to place a router between the  IB/1  and  the
   networks  within  each  department.   This has the advantage of making
   the broadband a separate subnet and providing the gateways  (arguably)
   needed  for  subnet-based  routing  as described above.  Disadvantages
   include the decrease in throughput (compared to just the bridge),  the
   added  cost  of  the router (or an additional ethernet interface for a
   host acting as a router), and the restriction on the  protocols  which
   may  then  cross  the broadband.  Furthermore, I am not convinced that
   such a configuration would solve all our problems without  introducing
   new ones.



Jay Ford
Weeg Computing Center
University of Iowa
Iowa City, IA  52242
(319) 335-5555

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20-Nov-87 23:03:52 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Networks & vendor upgrades/fixes


    ...
    I offer my speculations below and would like you to confirm/revise.

    Source Code: So that an organization can fix/improve the code
    themselves, or by a third party, and not have to depend on the original
    vendor.  Does your recommendation change if software maintenance is in
    effect?

Depends on the situation.  A university I know of has a couple hundred PCs off
line waiting for software maintainers at one of two vendors to solve a TCP
problem.  Everybody is acting in good faith, and both sides are partly at
fault.  One vendor has delivered what they think is a fix, but it took 4
months.  The other vendor had a new release, and that had to be tested to
see if the problem went away, etc, etc.

There are dozens of Unix vendors who are shipping 4.2's buggy, non-standard
TFTP.  How long will it be till they supply nameservers?  Consider the vendors
who spent years getting subnets working.  Some of these long-standing problems
may be helped by a host version of the "how to be a good gateway RFC" (1009?),
and the Non-Interoperability questionaire which is supposed to get some
attention at the conference in December, but I can't predict anything.

    Rigid Version Control: This has more to do with the organization's
    network than with vendors.  The organization doesn't want two different
    versions of the same process to be in use. 

Correct.  There is also an element of "we don't want anyone to modify it".
Identifying which version is in use is simply one more step in identifying
a problem, whether or not it has been encountered before.

    Homogenous Hardware: This one troubles me - I would like to think that
    through the use of standard protocols an organization could achieve
    interoperability ...

It is generally true that via TCP/IP, two different hosts can communicate.
Significant TCP bugs are getting pretty rare, although interpretations
for things like urgent differ.  Except for the Unix XPWD incompatibility,
FTP does pretty well.  SMTP has one widespread problem, discussed last week.
Most Telnets interoperate well, until you start playing with options, or
wondering why you are receiving parity (excuse my hobbyhorse).

However, this is fairly nuts-and-bolts compared to what you can do between
homogeneous systems.  There are a number of essentially Unix-Unix protocols
that add functionality to the basic ARPA suite, but they aren't well
documented, and non-Unix implementations are extremely rare.  Network
printing, to take a prosaic example.

Furthermore, most organizations have finite numbers of maintainers.  For
any number of maintainers, it appears that the tinkerers employed by
the vendors can tinker at least as fast as the maintainers can
learn/code/upgrade.  The more vendors, the more high-level people you
need, and high-level techies are the non-technical manager's nightmare.
Whole sectors of the software industry are founded on the absolute un-
willingness of many companies to employ permanently any techies more
qualified than a computer operator, or application program maintainer.
DEC has been moving VMS in their direction for years but few vendors
have even begun on "Unix for the masses", and that represents more than
half (vigorous hand-waving) of all TCP/IP hosts.

Anyone who's ever hacked on sendmail.cf knows what a vale of tears a
complex software system whose implementer is unavailable can be.  So,
the managers have mostly learned to keep things simple, generic where
possible, but ultimately maintainable.  The net I described in my first
posting is still useable, so the maintainers and their managers are
sticking to the problems they can solve, and relying on the influx of
new, uniform machines to eventually eliminate the off-maintenance bad
actors.  I'm not saying I prefer this, but it looks pretty likely.

    Regards - Craig

jbvb

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Nov-87 00:34:19 EST
From:      kermit@BRL.ARPA (Chuck Kennedy)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet versions

Here are the appropriate references for anyone that's interested:

The Ethernet: A Local Area Network: Data Link Layer and Physical Layer
Specifications, DEC, Intel, and Xerox Corporations, 1980.

The Ethernet: A Local Area Network: Data Link Layer and Physical Layer
Specifications, Version 2.0, DEC, Intel, and Xerox Corporations, 1982.

Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access
Method and Physical Layer Specifications (Standard 802.3-1985/International
Standard 8802/3), The Institute of Electrical and Electronics Engineers,
Inc., 1985.

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Nov-87 03:06:48 EST
From:      guru@wuccrc.UUCP (Guru Parulkar)
To:        comp.protocols.tcp-ip
Subject:   A couple of simple questions.


In the last few weeks, there has been a number of messages about PSN
version 7 release and a new end-to-end ARPAnet protocol. However, I
haven't seen any reference or RFC announcement which describes this 
protocol. Maybe, I missed it. Could somebody tell me if there is any
reference on that. Or is this protocol BBN's proprietrary. 

One question that I wanted to ask for a while is about the "connection 
oriented" nature of ARPAnet's link level (or PSN - PSN protocol). I 
believe this protocol is essentially a connection oriented which
means we have a situation where a connection less internet protocol
IP sits on the top of a connection oriented protocol. Is it possible
that in this situation the overhead of connection management does not
have good "payoffs" at IP level or layers above that ? I remember Dr. 
Dave Mills saying something on similar lines in one of his classes at
Delaware.  (Maybe, I misunderstood what he was trying to convey.)
I need to understand this issue better, and I would appreciate if
somebody could help me with this.

Thanks!

-guru parulkar               wuccrc!guru@uunet.uu.net or
Dept of CS                   parulkar@udel.edu
Washington Univ St. Louis

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Nov-87 05:13:16 EST
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: Institution-wide whois

I agree that most sites should maintain current whois database
information.  I think that the whois database structure is perhaps
past due, and a more appropriate form is needed.  For the host
information, perhaps a new record type could be added, such
as ADMIN.  This would tell you something about the organization
behind a domain. Ie:

	MIT.EDU
	Massachusetts Institute of Technology
	77 Massachusetts Avenue
	Cambridge, MA 02139
	(617) 253-1000

(as the ADMIN info)

	Nameservers: W20NS.MIT.EDU (18....) BITSY.MIT.EDU (18....) ...

(via NS queries for MIT.EDU)

And...
	LCS.MIT.EDU
	M.I.T. Laboratory for Computer Science
	5 Cambridge Centre (NE-43)
	Cambridge, MA 02139
	(617) 253-6001

(more ADMIN info)

	Nameservers: XX.LCS.MIT.EDU (10....)

(NS records)

and information for hosts could also be specified, where the ADMIN
record would tell you who the responsible person for a host is,
including phone number, address, and mailbox.  These wouldn't be
necessary for all hosts, maybe just gateways and nameservers...

For the user information, each host in the desired subdomain (or the
host itself, if it were named) could be 'fingered' for the desired
information about a user.

Ideas, comments?

-Philip

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Nov-87 20:15:24 EST
From:      lyndon@ncc.UUCP (Lyndon Nerenberg)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   KA9Q NET.EXE software


There are a couple of sites that have the code available. Ours is
one of them. To retrieve the distribution, add one of the following
lines to your L.sys/Systems file:

ncc Any ACU 2400 14034250342 "" \r ogin:--ogin: nuucp
ncc Any ACU 1200 14034250342 "" BREAK ogin:-BREAK-ogin: nuucp

Next, say 'uucp ncc!~/pub/ka9q_all.tar.Z /usr/spool/uucppublic' and
wait for it to transfer.

*********** PLEASE NOTE ************

This is NOT the LATEST version of the code!!!! The version currently
on line is 870829.0.  I should have the new version in a few days, so
you might want to hang off. I will post again in a few days when it's
online.

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Nov-87 21:07:28 EST
From:      gnu@hoptoad.uucp (John Gilmore)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP maximum segment size determination

JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") wrote:
> If gateway gurus saw their way clear to do so, they might help some fraction
> of the world by arranging that IP fragments aren't transmitted consecutively
> (if there is other traffic to handle) or by inserting a little time delay
> if the Ether or other non-serial media is idle.

It's hard to believe that in this age of utterly cheap dense RAM,
otherwise sane people are proposing inserting artificial delays between
Ethernet packets because a lowball vendor wouldn't put, say, TWO
buffers on their card!

The free market has a clear solution to this problem...

[I admit I'm prejudiced, since I worked on Suns, which currently seem
to have the highest Ethernet thruput, but they were built out of
standard Ethernet chips and DRAMs available to everyone.  You too can
handle infinite back to back packets, if you just design with that in
mind as Sun did.]
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
Love your country but never trust its government.
		      -- from a hand-painted road sign in central Pennsylvania

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Nov-87 23:15:52 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  A couple of simple questions.

Guru,

Yes, ARPANET is now and has been a connection-oriented network, but with
dynamics and route-binding mechanisms usually friendly to frisky datagram
service. Sometimes, like in the recent case of an X.25 access problem
which resulted in destructive virtual-circuit thrashing, the more liberal
of us buzzards may grumble a bit or two, but not because virtual circuits,
route binding or flow mechanisms are inherently bad. Sometimes, however,
the choice of resource allocation and binding strategies in ARPANET (and
public packet nets) suggest the designers had in mind a few number
of large flows between hosts attached to the network, rather than a large
number of small flows between gateways, which seems to be what the ARPANET
is evolving to.

Andy Malis described the new End-End Protocol in RFC-979.

Dave

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Nov-87 23:35:17 EST
From:      karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD 4.3 Terminates zero window connection

Re:

> A customer has reported that BSD4.3, if it is presented with a zero window,
> tries ONCE to push data through the window.  If it receives no response,
> it closes the connection.  There is a language problem between me the
> customer and the manuals, so maybe I don't understand what they are
> saying.  Does this match 4.3 behavior?
> 
> - Geof

This is not true in general, and I don't know of any bugs in this area
that cause connections to close when the window closes.  There was a bug
in 4.2 that could cause connections to close if the window was retracted
after data had been sent into it; I believe that this is fixed in 4.3BSD
as well, although I didn't take the time to set up a situation in which
to test that.

		Mike

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Nov-87 23:35:58 EST
From:      karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD 4.3 Sends data after FIN?

This was a bug in 4.3 alpha or beta, I forget which; it's not in
the released version of 4.3.

		Mike

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21-Nov-87 23:44:55 EST
From:      hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks & vendor upgrades/fixes

> Source Code: So that an organization can fix/improve the code
> themselves, or by a third party, and not have to depend on the original
> vendor.  Does your recommendation change if software maintenance is in
> effect?

We have yet to see an organization that fixes things fast enough to
cope with our situation.  When a problem shows up, it shows up in
spades.  Like suddenly we are using the whole bandwidth of a T1 line
sending bogus name requests.  Now and then we'll call an organization
and have them say "oh yes, we know about this.  What is your UUCP
phone number?"  But otherwise, it is "fixed in the next release" or
at best fixed in a few days.  That are situations where we would have
to disable a crucial function during the interim.  So I consider it
crucial to have source for as much as possible.

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 00:00:28 EST
From:      hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: help

The author describes a configuration having a mix of vendors, administrators,
and network technologies, and asks how to make a level-2 bridge work within
it.  My recommendation would be:
 1) not to do it.  I think it is a big mistake to let level 2 technology
	cross administrative boundaries.  Personally I prefer level 3
	technology everywhere, but there are good arguments on both sides.
	But I see nothing in favor of leve 2 technology connecting networks
	where different people are going to be responsible for diagnosing
	problems.  Since this issue has come up so many times, I now have
	a canned response which I will  mail to the original poster
	under separate cover (to avoid boring the rest of you).  We believe
	that the next generation of gateways (based on 68020 processors
	instead of 68000), which should be available in December or January
	from at least cisco and Proteon, will have throughput close to that
	of a bridge.  The primary performance limitation will then be
	on long back-to-back strings of packets.  That will be resolved
	by new Ethernet controllers, which should also be available shortly.
	Even in the current generation, throughput with gateways is enough
	for most networks.  From your description, I believe you would
	see no performance problems from using routers instead of
	bridges.
 2) if you must do it, I would set the subnet mask to 255.255.255.0
	on those machines were you can have multiple subnets on one
	interface.  All BSD-based systems allow this, and I think 
	many others as well.  On a BSD system, you say
		route add x.y.z.0 youraddress 0
	for each subnet that you want to add as being local.  For systems
	where this is not possible, I would set the subnet mask to
	255.255.0.0.  If you have any such systems, then any actual level
	3 gateways that may be present in your configuration (Apollo?)
	will have to be able to do proxy ARP.

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 02:24:13 EST
From:      tamir@CS.UCLA.EDU
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   dialup SLIP using split speed modems ?

Has anybody tried running SLIP over a dialup line using a
split speed (9600 / 300 baud) modem such as the US Robotics HST9600 ?

How well can this be expected to work compared with
full duplex 9600 baud (both directions) modems or with
half duplex 9600 baud modems ?

			   Yuval Tamir

Internet: tamir@cs.ucla.edu
    UUCP: ...!{ihnp4,ucbvax,sdcrdcf,trwspp,randvax,ism780}!ucla-cs!tamir

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 10:09:13 EST
From:      Lixia@XX.LCS.MIT.EDU (Lixia Zhang)
To:        comp.protocols.tcp-ip
Subject:   Re: A couple of simple questions.


	I'll leave the version-7 description to BBN people, and only say a
few words about your second question (about the PSN-PSN protocol, or
IMP-IMP protocol as it used to be called).
	It is a link layer protocol providing reliable datagram deliveries
(i.e. every packet will be delivered, but possibly out-of-order).  It has
nothing to do with connection concept at the network layer.  ARAPNET runs a
DATAGRAM protocol internally, but provides a virtual-circuit interface to
the host by a reliable network end-to-end (i.e. between entry-exit IMPs)
protocol.
	Therefore some of your words are still correct -- unreliable IP
runs on top of the reliable ARPANET, and indeed causes high overhead in
many cases.  ARPANET opens an end-to-end connection to deliver data between
two hosts (which can be IP gateways), and blocks the interface to the host
whenever the PSN(IMP) runs out of the resources (buffers, control table
entries, whatever).  And that is why packets always get lost at the
gateways: the IP gateway has no mechanism to stop incoming packets, so it
has to drop them when they can't be forwarded.

Lixia
-------

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 12:29:42 EST
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Networks & vendor upgrades/fixes


Source code: I'd like to add that the critical need for source code,
besides functional fixes, is security. It's one area where it's nearly
impossible to find a vendor who provides what you need. Unfortunately
needs are very often a customized affair, and security bugs often an
outright emergency. It's can also be a moving target, something no one
thought of yesterday suddenly, after one irate phone call, becomes
first priority. Software "maintenance" is utterly the wrong concept
for this sort of situation.

	-Barry Shein, Boston University

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 15:13:43 EST
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   A couple of simple questions.


Hi, my wife and I and a friend (Diane Rahe who is a hardware engineer
in my group at Prime) are going out to dinner (probably in Chinatown)
sometime between 6 and 7.  Would you be interested? Just send me mail.
I cannot be reached by phone.

Yakim Martillo

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 16:04:31 EST
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Networks & vendor upgrades/fixes

Distributing source code seems to be inconsistent with the desire to enforce
version controls.  The availability of source code seems to be an attraction
to the "tinkerer" much like a flame is to a moth--one's version control be-
comes a historical artifact when the "tinkerer" gets access to the code.

If the source is distributed on a media other than electronic as "documentat-
tion", it is extremely useful and it is relatively easy to maintain version
control of the software.

Merton Campbell Crockett

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 16:24:03 EST
From:      mshiels@orchid.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS Compatibility Demo


One thing to test in all NETBIOS on TCP/IP implementations is the ability
to do the following.  IBM TOKEN RING NETBIOS allows it but alot of vendors
of clone NETBIOSs don't seem to handle this well.

Make an open/listen call and then post a receive on this session. (before
any connections are made!).  

Just thought I'd poass along some of the problems I have run into.

-- 
  Michael A. Shiels (MaS Network Software)
  mshiels@orchid.waterloo.EDU
UUCP: ...path...!watmath!orchid!mshiels

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 16:36:19 EST
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Networks & vendor upgrades/fixes


>Distributing source code seems to be inconsistent with the desire to enforce
>version controls.  The availability of source code seems to be an attraction
>to the "tinkerer" much like a flame is to a moth--one's version control be-
>comes a historical artifact when the "tinkerer" gets access to the code.
>
>If the source is distributed on a media other than electronic as "documentat-
>tion", it is extremely useful and it is relatively easy to maintain version
>control of the software.
>
>Merton Campbell Crockett

There are certainly better ways to do version control than to withold
the sources. I've heard this argument for years and I still don't
believe that the solution is OCO distributions, I don't even believe
this is ever the real reason (vague fears of losing the technology are
probably the real reason, either de facto [falling into a competitor's
hands] or de jure [a court deciding you gave away the store], some of
these fears have no rational basis, some do, but the conservative
choice is obvious (even if it loses sales?!))

For example, one could simply demand, as with all warrantees, that
software will not be maintained if monkeyed with (tho patches could be
supplied everyone and they can do what they like with them.) To settle
disputes it would be easy enough to provide a simple checksum program
on the source. Whatever, but witholding the source has to be the worst
possible solution to this (undisputed) problem. One thing I hate is
vendors who won't even sell any source support (that is, you don't get
the source patches for minor releases, so either you live with the
bugs, obsolete your sources or guess how to fix the problem.)

Vendors could also get more aggressive about these problems instead of
sitting around getting into trouble (I have no doubt they do with
large customers who get the sources, tinker, then demand support
anyhow, money talks...)

Usually when I get a source release I pays my money and that's that, a
tape shows up, even if I already have maintenance on the software. I
could see being asked to sign something which clearly states the new
responsibilities now that you have sources. Heck, to trade options on
the CBOE you have to sign a form acknowledging your lack of good sense.

Seriously, how do you know they haven't mucked with the rest of the
O/S, binary patched your sw, etc. Same problem.

Microfiched source is not the answer either, unless you get some sort
of satisfaction at merely looking at the buggy code that's bringing
your system to its knees. Blechh.

	-Barry Shein, Boston University

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 17:35:01 EST
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Apologies and Arcnet


Before I receive hundreds of letters about my faux pas with the
mailer, I am aware of the mistake and apologize for it.

Since I am mailing out this letter, I may as well may it somewhat useful.
I noticed arcnet being discussed here.  Now my friends at Clearpoint
use arcnet networking cards with vme bus interfaces for some sort of
distributed memory testing.  After seeing arcnet mentioned in this
newsgroup, I have become curious.  

Where does arcnet come from?

Who uses it and why (instead of some other networking scheme)?

What are the achievable data rates?

Where can I get literature on arcnet?

Yakim Martillo

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22-Nov-87 23:09:11 EST
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks & vendor upgrades/fixes

I feel it is bogus for a vendor to NOT offer source to those customers
who have the local expertise to make use of it, and are willing to pay
for the extra cost of its distribution. However, many if not most end
users either do not want to do their own software maintenance or don't
have a local support staff, and would rather pay the vendor for a turn
key solution and phone line customer support. Within each organization,
this is usually an economic rather than technical issue.

Unix certainly represents the only real attempt to free the end user
from vendor dependence on a particular operating system or machine
architecture.  It is far from perfect, but it does run on different
machines from PCs to Crays, and goes farther than any other vendor
implementation in providing an application and system interface that
is offered by a wide range of computer vendors on widely different
hardware.

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 00:32:47 EST
From:      sy.Ken@CU20B.COLUMBIA.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: A couple of simple questions.


  Hi, my wife and I and a friend (Diane Rahe who is a hardware engineer
  in my group at Prime) are going out to dinner (probably in Chinatown)
  sometime between 6 and 7.  Would you be interested?...

You're going to need a reservation for several thousand at least...
-------

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Nov 87 10:10:11 -0500
From:      Andy Malis <malis@CC5.BBN.COM>
To:        wucs1!wuccrc!guru@UUNET.UU.NET, Lixia Zhang <Lixia@XX.LCS.MIT.EDU>, Mills@LOUIE.UDEL.EDU, martillo@ATHENA.MIT.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: A couple of simple questions.
I would like to add a few comments to the "simple questions"
messages, in the order that I received them.

    From: Guru Parulkar <wucs1!wuccrc!guru@UUNET.UU.NET>

    In the last few weeks, there has been a number of messages
    about PSN version 7 release and a new end-to-end ARPAnet
    protocol. ... 

As Dave Mills has already pointed out (thanks, Dave) I wrote RFC
979 in March of '86 to describe the external functionality of the
new EE in PSN 7.0.  It's still accurate for PSN 7.0, but please
read anything in there concerning future PSN releases with a
grain of salt.  This was written some time ago, and plans have a
way of changing, as I'm sure you're all aware.

    One question that I wanted to ask for a while is about the
    "connection oriented" nature of ARPAnet's link level (or PSN
    - PSN protocol). ...

You are absolutely correct - IP datagrams are being sent over
internal connections between endpoint PSNs (and, in the case of
IP over X.25, the connections go all the way back to the hosts).
There are a number of reasons that this is done (including
history - the predecessor to TCP, NCP, depended upon this
reliable service from the subnet), but the most important is that
imposing per-connection restrictions on the host traffic is
currently the only way the PSNs have to protect themselves and
the network (without dropping packets) from being completely
overwhelmed by offered load.  Whether the PSNs SHOULD drop
packets or not when supporting TCP/IP-based applications is
another question altogether (and one I would rather not get into
right now).

As an aside, there are many non-TCP/IP based applications that
run on BBNCC PSN networks, and these require the reliable
connection-based service provided by the PSN.

Even the per-connection restrictions aren't enough to allow the
PSNs to push back, when necessary, on source hosts.  Because of
this, we have been working on congestion control for the PSNs.
Only after congestion control has been deployed can we start
thinking about implementing some sort of non-connection-based
service for the ARPANET and other TCP/IP nets.

    From: Mills@LOUIE.UDEL.EDU

    Sometimes, however, the choice of resource allocation and
    binding strategies in ARPANET (and public packet nets)
    suggest the designers had in mind a few number of large flows
    between hosts attached to the network, rather than a large
    number of small flows between gateways, which seems to be
    what the ARPANET is evolving to. 

You are mostly correct.  In the "good old days" of small IMPs,
when we only had on the order of 64 connection blocks on an IMP,
we really hadn't designed for the sort of traffic that you now
see on the ARPANET between gateways.  However, we tried to adjust
our algorithms somewhat to make the new EE more general for the
different sorts of applications we see now see running on PSN
networks.

As a result, the new EE can support up to 2000 simultaneous
connections on a C/300 (which are becoming more common on the
ARPANET) and 512 on a C/30 (which has less memory and CPU
horsepower).

    From: Lixia Zhang <Lixia@XX.LCS.MIT.EDU>

    ARPANET runs a DATAGRAM protocol internally, but provides a
    virtual-circuit interface to the host by a reliable network
    end-to-end (i.e.  between entry-exit IMPs) protocol.

You are correct, except for one small point - your use of the
word DATAGRAM may suggest to some that PSNs may be willing to
drop packets if necessary.  This is not the case - the only time
packets are lost in the subnet is if a PSN crashes or, because of
network congestion, a PSN cannot accept a packet from its
neighbor in 32 transmission attempts from the neighbor.  The old
EE could not recover from such packet lossages.  The new EE has
source retransmissions, and can recover from such internal packet
loss.

    Therefore some of your words are still correct -- unreliable
    IP runs on top of the reliable ARPANET, and indeed causes
    high overhead in many cases.  

We've also worked hard on the new EE to reduce this necessary
overhead.  For example, we've cut down on the packet header size
and can send the data for the first message over a connection
as a part of the connection open request.

    From: martillo@ATHENA.MIT.EDU

    Hi, my wife and I and a friend ...  are going out to dinner
    (probably in Chinatown) sometime between 6 and 7.  Would you
    be interested? 

Sounds good.  I'm partial to Carl's Pogoda and the Golden Palace.

Regards,
Andy

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 07:33:26 EST
From:      COINS@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   QUESTION


ANYONE

     I'M RUNNING PWB UNIX ON A PDP1170.  DOES ANYONE HAVE DATA
ENTRY TERMINAL OPTIONS TO/FOR TELNET UP ON ANY VERSION OFUNIX?
IF SO PLEASE DROP ME A NOTE.
THKS
RON SMITH
-------

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 11:01:27 EST
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: A couple of simple questions.

I would like to add a few comments to the "simple questions"
messages, in the order that I received them.

    From: Guru Parulkar <wucs1!wuccrc!guru@UUNET.UU.NET>

    In the last few weeks, there has been a number of messages
    about PSN version 7 release and a new end-to-end ARPAnet
    protocol. ... 

As Dave Mills has already pointed out (thanks, Dave) I wrote RFC
979 in March of '86 to describe the external functionality of the
new EE in PSN 7.0.  It's still accurate for PSN 7.0, but please
read anything in there concerning future PSN releases with a
grain of salt.  This was written some time ago, and plans have a
way of changing, as I'm sure you're all aware.

    One question that I wanted to ask for a while is about the
    "connection oriented" nature of ARPAnet's link level (or PSN
    - PSN protocol). ...

You are absolutely correct - IP datagrams are being sent over
internal connections between endpoint PSNs (and, in the case of
IP over X.25, the connections go all the way back to the hosts).
There are a number of reasons that this is done (including
history - the predecessor to TCP, NCP, depended upon this
reliable service from the subnet), but the most important is that
imposing per-connection restrictions on the host traffic is
currently the only way the PSNs have to protect themselves and
the network (without dropping packets) from being completely
overwhelmed by offered load.  Whether the PSNs SHOULD drop
packets or not when supporting TCP/IP-based applications is
another question altogether (and one I would rather not get into
right now).

As an aside, there are many non-TCP/IP based applications that
run on BBNCC PSN networks, and these require the reliable
connection-based service provided by the PSN.

Even the per-connection restrictions aren't enough to allow the
PSNs to push back, when necessary, on source hosts.  Because of
this, we have been working on congestion control for the PSNs.
Only after congestion control has been deployed can we start
thinking about implementing some sort of non-connection-based
service for the ARPANET and other TCP/IP nets.

    From: Mills@LOUIE.UDEL.EDU

    Sometimes, however, the choice of resource allocation and
    binding strategies in ARPANET (and public packet nets)
    suggest the designers had in mind a few number of large flows
    between hosts attached to the network, rather than a large
    number of small flows between gateways, which seems to be
    what the ARPANET is evolving to. 

You are mostly correct.  In the "good old days" of small IMPs,
when we only had on the order of 64 connection blocks on an IMP,
we really hadn't designed for the sort of traffic that you now
see on the ARPANET between gateways.  However, we tried to adjust
our algorithms somewhat to make the new EE more general for the
different sorts of applications we see now see running on PSN
networks.

As a result, the new EE can support up to 2000 simultaneous
connections on a C/300 (which are becoming more common on the
ARPANET) and 512 on a C/30 (which has less memory and CPU
horsepower).

    From: Lixia Zhang <Lixia@XX.LCS.MIT.EDU>

    ARPANET runs a DATAGRAM protocol internally, but provides a
    virtual-circuit interface to the host by a reliable network
    end-to-end (i.e.  between entry-exit IMPs) protocol.

You are correct, except for one small point - your use of the
word DATAGRAM may suggest to some that PSNs may be willing to
drop packets if necessary.  This is not the case - the only time
packets are lost in the subnet is if a PSN crashes or, because of
network congestion, a PSN cannot accept a packet from its
neighbor in 32 transmission attempts from the neighbor.  The old
EE could not recover from such packet lossages.  The new EE has
source retransmissions, and can recover from such internal packet
loss.

    Therefore some of your words are still correct -- unreliable
    IP runs on top of the reliable ARPANET, and indeed causes
    high overhead in many cases.  

We've also worked hard on the new EE to reduce this necessary
overhead.  For example, we've cut down on the packet header size
and can send the data for the first message over a connection
as a part of the connection open request.

    From: martillo@ATHENA.MIT.EDU

    Hi, my wife and I and a friend ...  are going out to dinner
    (probably in Chinatown) sometime between 6 and 7.  Would you
    be interested? 

Sounds good.  I'm partial to Carl's Pogoda and the Golden Palace.

Regards,
Andy

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 11:10:08 EST
From:      alan@cunixc.columbia.edu (Alan Crosswell)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 and IBM's TCP/IP for VM/CMS

In article <723@hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>....  Does anyone know if the current IBM product (which has
>been available only since July 87) is really compatible with tn3270 ??

Yes.  In fact, the PC implementation is quite good and includes a nice
utility for selecting your favorite 3270 to PC keyboard mapping.  It
also does colors the same way the Yale ASCII IUP (Series-1 stuff which
is these days done by 7171's) does.  It doesn't do 3279, but assigns a
different color to each combination of attributes like hilight,
protected, etc.  Nobody has done 3279 (yet) since it wasn't until
VM/SP 5 that the "Logical Device Facility" was extended to support the
so-called 3279 extended data streams.

>The IBM Product Sheet that I have also refers to a C language interface
>to allow program access directly to the TCP and UDP protocol boundary.
>Does anyone have any experience with this ??  I'd assume a program
>under VM using this could communicate with a program on the VAX that
>was using a BSD socket ??

They provide a means to roll your own TCP/IP programs.  The C library
is simply a stub interface to the VS Pascal library.  You get source,
so you can use it as a model for your own program (since everyone
knows you can't write a program just from the docs :-).  Vace
Kundakci, the Academic Systems Manager here, has written (and
modified) several clients and servers for things like LPD, Imagen
spooling, FINGER, SMTP/SEND interactive messaging, etc.  Join the
IBMTCP-L list distributed by CUNY.  Send mail to LISTSERV@CUNYVM with
this as the body: "SUBSCRIBE IBMTCP-L My Name".

>Finally, the Product Sheet lists the one-time license charges (from $4k
>to $16k, depending on processor group) but then indicates that the
>source code for this can be obtained for another $350.  This low charge
>makes me think the code was developed elsewhere.
>

You are partially right.  The PC stuff is based on MIT PCIP with
additional work done by joint studies with CMU and Maryland.  The VM
stuff is based on Wiscnet, which was an IBM-funded project at
Wisconsin.  Parts of the VM stuff have been adapted from Wiscnet.
Other parts have been totally rewritten (SMTP for example).  The
"product" is provided (and supported) by a group within IBM's Research
Division at Yorktown Heights -- not one of the usual product divisions
-- in conjunction with IBM's ACIS (Academic Information Systems)
Independent Business Unit.  ACIS is the group that runs the Advanced
Education Program, AEP, which many schools are beneficiaries of.

>	Richard Stevens
>	Health Systems International, New Haven, CT
>	   { uunet | ihnp4 } ! hsi ! stevens

Alan Crosswell
Columbia University

PS: We (have) run Wiscnet, PCIP, TCP/IP for VM and the PC (using both
the DACU and the new LAN Channel Station) but have no experience with
the 9370.  Don't let them sell you a 9370 just to be a network
front-end for a larger VM machine -- get a LAN Channel Station
instead.  It's just a tweaked AT with a channel cable!

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 11:11:44 EST
From:      jleddy@VAX.BBN.COM (John Leddy)
To:        comp.protocols.tcp-ip
Subject:   SATNET MTU

Folks,

My name is John Leddy and I work at BBN on the SATNET project.  I noticed
several messages questioning the maximum packet size on the SATNET.
 
To clear things up, the SATNET has a maximum packet size of 256 bytes but
because of a 6 byte gateway to gateway header the maximum IP packet size is 
250 bytes.

John Leddy
jleddy@vax.bbn.com

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Nov 87 11:11:44 EST
From:      John Leddy <jleddy@VAX.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        jleddy@VAX.BBN.COM
Subject:   SATNET MTU
Folks,

My name is John Leddy and I work at BBN on the SATNET project.  I noticed
several messages questioning the maximum packet size on the SATNET.
 
To clear things up, the SATNET has a maximum packet size of 256 bytes but
because of a 6 byte gateway to gateway header the maximum IP packet size is 
250 bytes.

John Leddy
jleddy@vax.bbn.com
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 12:19:05 EST
From:      lamaster@pioneer.arpa (Hugh LaMaster)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminal server efficiency

In article <8711191851.AA13481@athos.rutgers.edu> hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) writes:

>regard small windows as a significant problem.

Does anyone know how the Encore Annex behaves?





  Hugh LaMaster, m/s 233-9,  UUCP {topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

(Disclaimer: "All opinions solely the author's responsibility")

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 12:34:37 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  A couple of simple questions.

Andy,

Did someone say Chinese? If you an Mr. Martillo can wait until the INARC
Workshop at BBN on 17-18 December, we can bring the whole gang.

Our advertising department couldn't pass that one up.

Dave

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 14:57:46 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  SATNET MTU

John,

Eeek. What is in that six-octet gateway-gateway header? Is this for the
b'rflies? Please tell me it aint so. In fact, it would be a wonderful thing
to explain in detail how the buttergates manage their intergateway routing
and what expectations it places on the underlying networks. Is the six octets
required in every network through which a butter flutters?

Dave

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 17:05:27 EST
From:      Vince.Fuller@C.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   [Dale.Moore@PS1.CS.CMU.EDU: ]

Some people might be interested in the latest status of our VMS TCP/IP package.

	Vince Fuller, CMU-CSD
                ---------------

Return-Path: <Dale.Moore@PS1.CS.CMU.EDU>
Received: from PS1.CS.CMU.EDU by C.CS.CMU.EDU with TCP; Mon 23 Nov 87 16:59:10-EST
Date: 23 Nov 1987 17:00:19 EST
From: Dale.Moore@PS1.CS.CMU.EDU
To: cmu-tek-tcp@C.CS.CMU.EDU
Subject: 

I thought that some of you might appreciate hearing what is going on
here at CMU-TEK IP/TCP world headquarters.  I figured I'd take some
time and write you all a note.  A Christmas Card sort'of.

The current release of the software is V6.2.   If you don't have
it, you probably want to get it.  V6.2 has some unique problems of its
own, but it is in a bit better health than the old V6.0.  To get the
V6.2 of the software, please send snail mail to

	CMU-TEK IP/TCP Requests
	4910 Forbes Av.
	Computation Center
	Carnegie Mellon University
	Pittsburgh PA  15213     USA

Last week, we had over 450 sites liscensed for this software.
We do not keep track of how many machines at each site.
Many of the requests we receive come from Europe, New Zeland and
Australia.  Perhaps someday, we'll have to see if we can get
some travel out of this.

We personally get many requests for help.  Some of it quite difficult
and some easy.  Since this is not a real product, almost everyone
is absolutely delighted with any help we can find the time to give them.
The best collection of information and help is a mailing list we've set
up called "CMU-TEK-TCP-Requests@C.CS.CMU.EDU".  Actually that's the
address you use to get added/removed from the list.  The actual
mailing is something else, but too many folks send mail to the mailing
list, when they really want added to it.  Since we can't spend to
much time hand holding with the users,  the other folks who are on the
mailing list can often add their own insight to your views and problems.

Some folks expect us at CMU to do extensive answer/question sessions.
We get phone calls that go like "We got our first VAX last week and we
couldn't get your stuff to work and my boss told me to call you." and
"Ok, push down the Control button. Got it pushed down? Now type C."
Some consultants earn over $300 per day.  Good ones are probably
worth it.  If you need more than just a little help, I recommend that
you purchase a supported IP/TCP, or get some professional help.

Currently, there are three of us at the CMU-TEK IP/TCP world headquarters.
Two of us are working on the software.  Actually, we are only working on it
part time.  I know of no plans of increasing the amount of technical support
that CMU is giving this software.  We have other responsibilities and
commitments that we must take care of here. 

We have a clerical and administrative staff of one, really one half.
He has other responsibilities also.  We will probably this to one full
time position, to better respond to the increasing load.

Vince Fuller, one of the two member technical staff, will soon be leaving
CMU for the better weather of California.  Vince has done a wonderful
job with all the work to the ACP and lately NAMSRV.
Whether Vince will find time, at his new position, to continue to do
development and maintenance remains to be seen.  We will miss him and
wish him the best at his new job.

We hope to get the V6.3 release into beta test sometime in the next few
months.  If you have
	- excellent communication and technical skills,
	- are on the Arpa/Internet, 
	- have a liscense for Bliss-32, 
	- have a variety of Vax hardware, 
	- are already running V6.2 of the software, and
	- are running VMS V4.6.
we might appreciate it if you'd be a beta test site.  If you only have
5 of the 6 above we still might appreciate it.  Please don't
volunteer because you want the latest greatest version with the
whizziest functions.  Do it because you want to help us get something
out that has many fewer problems that the last release.
This time we hope to do a more extensive beta - testing in order to
avoid some of the problems that we had on the last release.

Some of the things that we are working to put into the V6.3 beta release
are
	- a telnet server that is part of the ACP.  This will reduce
	traffic and improve performance.
	- many fixes to Namsrv.
	- FTP's ability to handle arbitrary RMS file formats.  To my
	knowledge, no other IP/TCP product for VMS does this!
	- User manuals for the various user utilities.
	- More documentation on how to configure your machine.

We have done this software for our own use.  It is not our
intention of supporting it as a commercial product.  Many have asked
us about implementing other network mediums besides the DEC ethernet
interface, such as Serial Line and X.25.  Our  access to such testing
is limited.  We hope, that by distributing the sources, if others need
such functionality that they'll add it.  And if they add it, they'll
return the improvements.  If they return the improvements to us, we'll
try to give the improvements to the rest of you.

I'd like to thank the very few of you who have had the time to return your
bug fixes and improvements.  We all appreciate it.

The software is popular.  It is becoming more popular.  We are
working on improving it, but we are limited in the amount of time
that we can spend on it.  Some external funding that we were hoping
for did not work out.  I think that even though this may not be the
best supported IP/TCP for VMS, it certainly is the best per dollar.


Dale Moore
Research Systems Programmer
Computer Science Department
Carnegie Mellon University

-------

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 18:17:50 EST
From:      feldman@tymix.UUCP (Steve Feldman)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting remote Ethernets?

I too would like information about connecting Ethernets.  Specifically,
we have two buildings with Ethernets in our campus, with fiber optic
cables between the them.  If we're lucky, we might get a dedicated
fiber pair, otherwise we should be able to get at least a 56Kb link.
(We're not allowed to run Ethernet or any other cables.  We're stuck
with what they gave us.)

I believe I've read here that Cisco and Bridge make IP routers which
might do what I want.  Please mail me any information you might have on
these and any other vendors.  I'd also like to hear of experiences with
these routers, positive and negative.

Thanks for your time,
	Steve Feldman
	Tymnet McDonnell Douglas
	uucp: sun!oliveb!tymix!feldman
	arpa: feldman%tymix.tymnet@office-1.arpa

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 19:21:36 EST
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re:  Telephone Access Controllers (TACs) and SLIP...


    Rather than having the dialled-into system pick an address for its
    caller, how about if the caller asks for a particular IP address and
    authenticates itself with, say, a password?  That same calling host
    would always ask for the same address.  The name-address association
    could be permanent, only the connections would be temporary.

This makes routing a big problem (although routing protocols are already
dynamic in nature, it isn't clear that they are \that/ dynamic, and are
quite likely to have problems with the huge number of routes that may
suddenly appear).

You would also then have the requirment that each and every PC have
its own (sub)net number, which results in quite an address assignment
problem if you have (as someone mentioned) 3000+ PCs.

A compromise might be to have each SLIP server serve a number of
IP addresses on a particular subnet, and then when a PC dials in,
it can pick its own address from that pool...

It is NOT clear to me that SLIP will primarilly be used by dialin users,
and for hardwired connections to PCs, things are a lot easier.

Bill Westfield
cisco Systems.
-------

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 1987 2344-PST (Monday)
From:      Glenn Trewitt <trewitt@miasma.stanford.edu>
To:        Dan Lynch <LYNCH@a.isi.edu>
Cc:        tcp-ip@sri-nic.arpa, netman@amadeus.stanford.edu, gwmon@sh.cs.net, Glenn Trewitt <trewitt@miasma.stanford.edu>
Subject:   Re: Network Management
[Sorry about the long note, but I've been waiting to hear a statement
from the NetMan vendors subgroup to hear just what it is that's going
on.  Now I've heard, so now I have something to comment on.]

Fascinating.  All of this talk about what CMIP privides.

When listening to the two main proponents of CMIP in the Network
Management meetings (up until the last one, of course, which I did not
attend), I have heard a lot of statements about what "CMIP Provides".
Yet the proposals about what CMIP is to do are constantly changing.

At the last meeting in Tokyo, where CMIP was to be voted up from its
current "Draft Proposal" status, it was rejected.  My understanding is
that this was the second time it was rejected, and that there is
considerable dissent about just what CMIP will do, and how will it do
it.

Nowhere else but at the NetMan meetings have I heard such definite
statements about what CMIP "is" and "does" and "provides".  In talking
to some people at Sydney University, I heard estimates of 3-4 years
until the ISO monitoring effort produces anything concrete.  Surely
they aren't TCP/IP lackeys?  I do know them to be very practical,
however.

While I understand the vendors' concerns, I don't agree with the way
these concerns color their outlook on ISO migration and short- to
medium-term managment solutions.

The only thing that ISO management offers that is not included in
monitoring proposals such as HEMS or SGMP is an overall architectural
definition.  This architecture defines the framework that monitoring
protocols (such as CMIP or HEMP) operate within.  There is no reason
that HEMS can't fit into the ISO framework.  Many hours were spent
discussing how that could be done.  Some members of the committee
refused to accept the notion that HEMS could conform to the
architecture, even though the protocol looks quite different than CMIP.
Or, I should say, "what CMIP currently looks like".

Architecture aside, the two protocols provide similar services (HEMS
offers some not in CMIS).  Both will require two major implementation
efforts, and each of these efforts will require far more effort than
the implementation of HEMS, and probably even more than CMIP.

1)  Servers for extracting data from protocol implementations (kernel
data structures, etc).  Interfaces between protocol modules and the
server will be at a very low level and likely will be peculiar to the
OS primitives available.  There is far more dependency upon environment
here than upon the querying mechanism (HEMP or CMIP).

2)  Application programs for manipulating this virtual data base.
These include programs to keep track of what's going on in the network,
systems to produce coherent summaries of network activity from many
points of view, specialized "assistants" to help ferret out problems,
and finally, programs to do high-level control operations, rather than
mucking around down in the dirt.  None of these applications depends in
the slightest upon the underlying monitoring protocol, except at the
very lowest subroutine call level.

This is all a lot of work, and it completely overshadows the cost of
implementing either of these protocols, much less migrating from one to
the other.

But there is one difference between the two systems.  HEMS is specified
now, and CMIS isn't.  Plus, CMIS may not be recognizable as CMIS by the
time it is nailed down.  Defining a network management on the basis of
a protocol that changes several times a year simply means that the
Network Management WG will end up defining yet another protocol,
something that was NOT in its original charter.


Please note that I have not touched upon the technical merits (or lack
thereof) of either system.  As one of the authors of HEMS, I am quite
biased about which one I prefer.  I do, however, feel that the
decisions that Craig and I made in designing HEMS have been validated
by Craig's implementation experience.  This is something that can't be
said of CMIS, which is strictly a paper design right now.

If anybody is interested in a discussion of the technical aspects of
the two systems, I would be happy to oblige.


Another issue I would like to see explored is the apparent domination
of the Network Management WG by the "vendors", to the exclusion of the
"non-vendors".  My impression is that there is a lot of writing going
on right now, none of which I am seeing discussed in the open forums
available for it (such as netman@amadeus or gwmon@sh.cs.net).  I
never heard a word about the meeting, except second hand, by accident.
What I did hear is that it specifically excluded non-vendors.  Now, I
suppose that it's fine for vendors to share their concerns with each
other, but it seems like a rather dramatic change of course happened at
that meeting.  Several of the people in attendance had never attended a
NetMan meeting before, and several people (including myself) who had
attended the meetings from the beginning were excluded.

Since when have vendors been in charge of (pre-)defining Internet
standards?

	- Glenn Trewitt

P.S.  I'll probably regret this in the morning.  :-)
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 21:30:10 EST
From:      chapman@lll-lcc.aRpA (Carol Chapman)
To:        comp.dcom.lans,comp.os.vms,comp.protocols.tcp-ip
Subject:   networking

I  am looking for advice, suggestions, etc. on how to implement the
following:

I have a C program which is sitting on a VAX that runs VMS.  The
program expects a user to sit by 2 terminals, one of which is actually
a SUN workstation, and the other is a Tektronix graphics terminal.
The user logs onto the VAX via the Tektronix terminal and starts up
the program.  While the user is working merrily away on the one
terminal, my code will occasionally send a character array over a
network to the SUN (which is running UNIX).  The SUN receives this
array which contains the name of an image file stored on that SUN.
The SUN displays that image on its screen.  This process keeps
repeating with the VAX sending arrays and the SUN displaying the
corresponding images (a client-server situation).
** END  OF "I-DON'T-THINK-IT'S-AS-EASY-AS-IT-SOUNDS" SITUATION **

I have never done any network programming before, so I would love to
hear from people who have written code using sockets, which is what I
believe is needed for this situation.  We have Wollongong's flavor of
TCP/IP on the VAX.

I don't normally read this newsgroup, so please send replies directly
to me (chapman@lll-lcc.arpa, or if .arpa is no longer working then
it's chapman@lll-lcc.llnl.gov).

Thank you!!

carol chapman

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23-Nov-87 21:59:34 EST
From:      leiner@riacs.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models


Vint,

I thought ISO viewed the management protocols (including gateway
routing algorithms) as kind of a blob sitting off to the side of the
"stack".  Did I get it wrong (again)?

Barry

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 00:10:44 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 and IBM's TCP/IP for VM/CMS

As far as I know, their stuff has WISCNET ancestry, and functions with
Greg Minshall's Unix TN3270 (and IBM's PC version, and ours).  One thing
to note is that TN3270 burns up a lot of a Unix box.  Our PC code on an XT
is considerably faster than TN3270 was on a Sun with one user, when I saw
Greg using it last spring.  I assume IBM's is, too.  Of course, Greg may
have fixed this.

The alternative, Spartacus's translation of full-screen 3270 to VT100 escape
sequences, is easy on the Unix box, but hard on the mainframe.  You pay your
penny, and you take your choices.  You might want to look at both, if
possible.

James B. VanBokkelen
FTP Software Inc.

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 00:16:35 EST
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Network Management

To facilitate information spread on some current network management
protocol developments, I am forwarding this set of "minutes" of a recent
meeting.

Dan

***********
Vendors Position Statement on TCP/IP 

Network Management Standards

Working Document - 11/20/87



	A lot of email has been exchanged recently, speculating on
the TCP/IP network vendors intentions with respect to Network
Management standards.  It is time for the vendors themselves to
explain their position on this topic.



	On 11/4/87, a group of vendors actively involved with the
effort of the Network Management Working Group of the IETF
met for the purpose of:



1)	assessing the current status of the network management
standards efforts with respect to the goals that they had agreed
to in May 1987.



2)	discussing plans to implement the proposed standards and
incorporate them in vendor products.



3)	discussing plans to demonstrate interoperability of network
	management among vendor products.



	The participants to the meeting included the following
vendors:



				Bridge Communications

				CMC

				Data General

				Excelan

				Hewlett-Packard

				Sun Microsystems

				Sytek

				3Com

				Ungermann-Bass



	These participants represent a substantial and
representative subset of the TCP/IP vendor community at large
and are collectively referred to as "the vendors" in the rest of
this document.



	In the course of the discussion on the agenda items listed
above, a consensus was reached on five major points:



1)	The vendors cannot endorse or implement the recently
circulated RFCs describing the HEMS system in their current
form for the following reasons:

	-	The HEMS approach does not satisfy a key goal of the
Network 	Management Working Group goals statement [1] which
is to provide a "clear migration path to OSI network
management."

	-	The services definition RFC [2] authored by Lee Lebarre is
a major element in the strategy of providing a clear migration
path to OSI and protecting major network management
application investments.  The ability to deliver these services
is a key requirement for choosing a management protocol.  The
HEMP/Query protocols do not provide this capability while CMIP
does.

	-	While the HEMS project provides significant insight into
the 	technical issues of TCP/IP network management, it has not
been driven by the same charter as the vendors adopted for the
Network Management Group [1].  The requirements for delivering
early implementations of HEMS for the gateway monitoring
needs of the NSFNet have made discussions and compromises
very difficult, and have prevented the HEMS developers from
taking into account the vendors key technical concerns and
strategic requirement.



2)	The vendors continue to treat the Network Management
Working Group Goals and Scope document [1] as their common
objective statement.  In particular, they recognize that the
transition from TCP/IP to OSI is inevitable.



3)	The vendors agree that the Service Definition RFC BBBB [1]
and the 	HEMS definition of the Management Information can be
used as a solid 	working base on which to build a network
managment system for TCP/IP environments.



4)	The vendors favor a network management standard approach
based 	upon the CMIP/TCP/IP stack which meets the overall
objective of easing the migration to the OSI environment.  In
particular, it preserves the vendors investment in network
management applications and makes the management of hybrid
(TCP/IP and OSI) networks significantly easier.  They intend to
submit concrete proposals to substantiate this approach to the
IETF.  Alternatively, the vendors would also agree to consider
enhancements to HEMP that preserve the integrity of the
Management Services interface as defined by RFC BBBB.



5)	The vendors remain committed to completing the
development of TCP/IP network management standards in an
aggressive time frame and take as a goal to demonstrate
interoperability of network management in the fall of 1988.



	In summary, a strong consensus has emerged in the vendor
community in favor of a CMIS-based approach.  While the quality
of the work produced for HEMS is not in question, the vendors
are driven by different motivations.  They are ultimately
responsible for investing considerable development resources to
engineer the network management products that will truly
create the standard.  In network management as well as other
areas, the vendors must make choices that maximaze their
return on investment of development resources over time.  They
intend to work within the Network Management Working Group
structure of the IETF to pursue these goals.



References:



[1]	TCP/IP Network Management Working Group:  Goals and
Scope - 	Revision 3 - 6/18/87



[2]	RFC BBBB:  Management Services for TCP/IP Network
Management, 

	Lee Labarre - 10/87

-------

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 01:07:13 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re:  Networks & vendor upgrades/fixes

In my own judgement, a vendor might be justified in restricting distribution
of the source code for "version control" only under the following
circumstances:

1. Vendor support personnel have access to source code themselves, and the
skills and tools to use it.  These people don't have to answer the phone,
but you need to be able to get a call back in a day or two, at most.

2. These vendor support personnel work in an environment in which most
or all customer problems can be conveniently duplicated.

The 2nd condition rules out restrictions on most network source code, since
not even IBM can maintain a current copy of *every* vendor's TCP/IP hardware
and software, and thus there are many problems that can't be duplicated at
the vendor's site.  Maybe TCP/IP sites are exceptional, but the large TCP
users we've sold source to have been quite well equipped with competent
personnel, and I've found working with them to be quite productive.  We
have had to teach some of our OEMs quite a bit, but they weren't users when
they started out.

James B. VanBokkelen
FTP Software Inc.

PS: I've realized that I'm talking from sort of a vendor/management
perspective.  If this bothers a mostly (?) engineering list, tell me
and I'll shut up except for technical issues.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 01:43:36 EST
From:      hassler@wrtfac.UUCP (Barry D. Hassler)
To:        comp.protocols.tcp-ip
Subject:   Re: Lawrence Livermore IGP project?

Brad,

        The Intelligent Gateway Processor is a generic  term  for  software
originally developed at LLNL, and now commercially marketed by Control Data
Corporation's Professional Services Division as ASCENT.

        The software comprising this system  was  developed  as  a  generic
front-end  to  heterogeneous systems for scientists at the Lab. It consists
of two major pieces of software, the Network Access Machine,  and  a  menu-
oriented  user  interface.  Without  going into a great deal of detail, NAM
uses an interpretive language to initiate and manage "connections"  over  a
wide  variety  of  "communication methods": direct RS-232, TCP/IP networks,
X.25, dial-up phones, etc. This software strictly resides  on  a  UNIX  (or
perversion  thereof)  host, and requires no additional hardware or software
on the attached hosts.

        Basically,  the  software  is  used  to  insulate  users  from  the
complexities   of  various  network  configurations,  intermediate  devices
(dataswitches,  network  interface  units  for  broadband  LANs,   protocol
converts,  etc) and connection procedures in large, heterogeneous computing
environments. Additionally, it has the capability for handling portions of,
or  entire,  sessions  with  a  host  on  behalf  of  a  user. In a current
commercial implementation, we use this technology to support connections to
DEC  VAXES, CDC Cybers, NAS 5000 & 7000s, and Data General Workcenters over
TCP/IP and X.25 networks from users coming into the IGP  via  dial-up,  DDN
telnet, broadband LANS, and Fiber-Optic muxes.

        The IGP is being used currently by various DoD agencies, mostly the
Air  Force,  Department  of Energy, and the Defense Logistics Agency, among
others.

        Over  the  past  several  years  there  have  been  several  papers
published or presented concerning this technology. Although I don't have my
copies here at home, I'd be happy to supply a list of  references  to  them
and  where  you  can  get  copies  if interested.  I just recently (Friday)
completed the latest such paper (which is why I'm finally getting to my  EM
now) entitled "Connectivity and Beyond." I feel (somewhat biased naturally)
this paper gives a good overview of the reasons for  this  technology,  and
how  it   works  in  heterogeneous environments. As soon as it has complete
being cleared for public dissemination  (since  it  references  a  military
project), I will be happy to provide copies of it.

Barry D. Hassler                             ARPA/DDN: hassler@lognet2.arpa
System Software Analyst

Control Data Corporation 
Professional Services Division  
Integrated Information Services

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 02:44:00 EST
From:      trewitt@MIASMA.STANFORD.EDU (Glenn Trewitt)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Management

[Sorry about the long note, but I've been waiting to hear a statement
from the NetMan vendors subgroup to hear just what it is that's going
on.  Now I've heard, so now I have something to comment on.]

Fascinating.  All of this talk about what CMIP privides.

When listening to the two main proponents of CMIP in the Network
Management meetings (up until the last one, of course, which I did not
attend), I have heard a lot of statements about what "CMIP Provides".
Yet the proposals about what CMIP is to do are constantly changing.

At the last meeting in Tokyo, where CMIP was to be voted up from its
current "Draft Proposal" status, it was rejected.  My understanding is
that this was the second time it was rejected, and that there is
considerable dissent about just what CMIP will do, and how will it do
it.

Nowhere else but at the NetMan meetings have I heard such definite
statements about what CMIP "is" and "does" and "provides".  In talking
to some people at Sydney University, I heard estimates of 3-4 years
until the ISO monitoring effort produces anything concrete.  Surely
they aren't TCP/IP lackeys?  I do know them to be very practical,
however.

While I understand the vendors' concerns, I don't agree with the way
these concerns color their outlook on ISO migration and short- to
medium-term managment solutions.

The only thing that ISO management offers that is not included in
monitoring proposals such as HEMS or SGMP is an overall architectural
definition.  This architecture defines the framework that monitoring
protocols (such as CMIP or HEMP) operate within.  There is no reason
that HEMS can't fit into the ISO framework.  Many hours were spent
discussing how that could be done.  Some members of the committee
refused to accept the notion that HEMS could conform to the
architecture, even though the protocol looks quite different than CMIP.
Or, I should say, "what CMIP currently looks like".

Architecture aside, the two protocols provide similar services (HEMS
offers some not in CMIS).  Both will require two major implementation
efforts, and each of these efforts will require far more effort than
the implementation of HEMS, and probably even more than CMIP.

1)  Servers for extracting data from protocol implementations (kernel
data structures, etc).  Interfaces between protocol modules and the
server will be at a very low level and likely will be peculiar to the
OS primitives available.  There is far more dependency upon environment
here than upon the querying mechanism (HEMP or CMIP).

2)  Application programs for manipulating this virtual data base.
These include programs to keep track of what's going on in the network,
systems to produce coherent summaries of network activity from many
points of view, specialized "assistants" to help ferret out problems,
and finally, programs to do high-level control operations, rather than
mucking around down in the dirt.  None of these applications depends in
the slightest upon the underlying monitoring protocol, except at the
very lowest subroutine call level.

This is all a lot of work, and it completely overshadows the cost of
implementing either of these protocols, much less migrating from one to
the other.

But there is one difference between the two systems.  HEMS is specified
now, and CMIS isn't.  Plus, CMIS may not be recognizable as CMIS by the
time it is nailed down.  Defining a network management on the basis of
a protocol that changes several times a year simply means that the
Network Management WG will end up defining yet another protocol,
something that was NOT in its original charter.


Please note that I have not touched upon the technical merits (or lack
thereof) of either system.  As one of the authors of HEMS, I am quite
biased about which one I prefer.  I do, however, feel that the
decisions that Craig and I made in designing HEMS have been validated
by Craig's implementation experience.  This is something that can't be
said of CMIS, which is strictly a paper design right now.

If anybody is interested in a discussion of the technical aspects of
the two systems, I would be happy to oblige.


Another issue I would like to see explored is the apparent domination
of the Network Management WG by the "vendors", to the exclusion of the
"non-vendors".  My impression is that there is a lot of writing going
on right now, none of which I am seeing discussed in the open forums
available for it (such as netman@amadeus or gwmon@sh.cs.net).  I
never heard a word about the meeting, except second hand, by accident.
What I did hear is that it specifically excluded non-vendors.  Now, I
suppose that it's fine for vendors to share their concerns with each
other, but it seems like a rather dramatic change of course happened at
that meeting.  Several of the people in attendance had never attended a
NetMan meeting before, and several people (including myself) who had
attended the meetings from the beginning were excluded.

Since when have vendors been in charge of (pre-)defining Internet
standards?

	- Glenn Trewitt

P.S.  I'll probably regret this in the morning.  :-)

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 04:23:00 EST
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

Barry,

ISO does put the management protocols off to the side with comb-like
projections into the various layers - rather like DECNET in that
regard. The gateway routing protocols all showed up just above IP
in the DoD Internet. At other layers, there was network management,
too, but not integrated into a common architecture. There were network
level management systems (e.g. ARPANET NOC), Internet management
systems (INOC, HMP - host monitoring protocol, GGP/IGP,EGP, etc.).

It still isn't entirely clear to me how integrated you can get and
still deal with separation of administrative control, etc.

Vint

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 1987 04:23-EST
From:      CERF@A.ISI.EDU
To:        leiner@ICARUS.RIACS.EDU
Cc:        oconnor@SCCGATE.SCC.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Idle chatter about reference models
Barry,

ISO does put the management protocols off to the side with comb-like
projections into the various layers - rather like DECNET in that
regard. The gateway routing protocols all showed up just above IP
in the DoD Internet. At other layers, there was network management,
too, but not integrated into a common architecture. There were network
level management systems (e.g. ARPANET NOC), Internet management
systems (INOC, HMP - host monitoring protocol, GGP/IGP,EGP, etc.).

It still isn't entirely clear to me how integrated you can get and
still deal with separation of administrative control, etc.

Vint
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 87 07:25:00 PST Tue, 24 Nov 87 07:25:00 PST
From:      "tcp-ip-RELAY%SRI-NIC.ARPA"  <@MIT-Multics.ARPA,@UBC.MAILNET,@SFU,@UM.CC.UMICH.EDU:tcp-ip-RELAY@SRI-NIC.ARPA>
To:        Tcp-ip-dist: userID=DUM1@SFU.BITNET, My_Hangout@SFU.BITNET, Userid=Q73X@UBC.Mailnet, userID=TCP@SFU.BITNET, ubc-tcp-ip@UBCMTSG.BITNET;, CERF@A.ISI.EDU, oconnor@SCCGATE.SCC.COM, tcp-ip@SRI-NIC.ARPA userID=DUM1@SFU.MAILNET, CERF@A.ISI.EDU, oconnor@SCCGATE.SCC.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Idle chatter about reference models, Re: Idle chatter about reference models
Vint,

Couldn't GGP and EGP be viewed as application (or management or
somesuch) protocols that just happen to have transport functionality
built into them?  Using  such a view in Mike's diagram,
GGP/EGP might be vertical rectangles that spanned several of the
corresponding layers in the ISO model.

My own favorite is to view them as management protocols
of the IP layer (that happen to provide their own transport).
After all, their purpose is to update an IP MIB (that's ISOese
for routing table).

Phill

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 87 09:47:40 PST Tue, 24 Nov 87 09:47:40 PST
From:      "tcp-ip-RELAY%SRI-NIC.ARPA"  <@MIT-Multics.ARPA,@UBC.MAILNET,@SFU,@UM.CC.UMICH.EDU:tcp-ip-RELAY@SRI-NIC.ARPA>
To:        Tcp-ip-dist: userID=DUM1@SFU.BITNET, My_Hangout@SFU.BITNET, Userid=Q73X@UBC.Mailnet, userID=TCP@SFU.BITNET, tcp-ip@UBCMTSG.BITNET;, LAWS%rsre.mod.uk@NSS.CS.UCL.AC.UK, CERF@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA, oconnor@SCCGATE.SCC.COM userID=DUM1@SFU.MAILNET, LAWS%rsre.mod.uk@NSS.CS.UCL.AC.UK, CERF@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA, oconnor@SCCGATE.SCC.COM
Subject:   Re: Idle chatter about reference models, Re: Idle chatter about reference models
Sorry to have kept you waiting; I have been off form as it happens, and
off to the Left Coast to boot.

Rather than succumb to the temptation of trying to see how many epicycles
the ISORM has these days (though I must confess I had been convinced at
one point in time that the party line was that each layer could/did have
a management sublayer--but never found out if that also applied to each
sublayer, so wasn't sure if L3 was four or six epicycles deep), let's
go back to the initiating question.  As I recall, it was something like
where things like GGP, EGP, and HMP went in  the layering.  Although I
have a great deal of sympathy for those who didn't bite and in essence
placed such things orthogonal to the layering, I would like to observe
that there's an alternative for those who find that view unsatisfying:
If you believe that the layers are Applications/Process, Host-Host, and
Network (Interface)--i.e., the old simple as I, II, III ARM I've always
espoused--then the answer ought to be easy to derive for any of the
three (or other, like protocols).  If they have to do with doing things
in common for the users' processes to get the bits to go from Host to
Host, then they're L II is one approach.  If they're clearly not part
of the interface to the proximate comm subnet processor and also fairly
clearly not directly germane to the Applications/Process Layer, then
they're L II is the other approach.  (Note to the original question-
raiser: you're of course welcome to use my Form, but it works better
if you use my Content too.)  (Note to John Laws: as you well know, my
main problem with the ISORMites is that they seem to me to be attempting
to substitute Form for Content almost all the time.)

Hope that's not too characteristically cryptic; if it is, I'll cop
a plea based on an imminent cold on top of the jetlag.

   cheers, map
-------
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 10:25:00 EST
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

Vint,

Couldn't GGP and EGP be viewed as application (or management or
somesuch) protocols that just happen to have transport functionality
built into them?  Using  such a view in Mike's diagram,
GGP/EGP might be vertical rectangles that spanned several of the
corresponding layers in the ISO model.

My own favorite is to view them as management protocols
of the IP layer (that happen to provide their own transport).  
After all, their purpose is to update an IP MIB (that's ISOese
for routing table).

Phill

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 11:38:23 EST
From:      cetron@CS.UTAH.EDU (Edward J Cetron)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP maximum segment size determination

In article <3370@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>standard Ethernet chips and DRAMs available to everyone.  You too can
>handle infinite back to back packets, if you just design with that in
>mind as Sun did.]

	Is this the same sun that, when it receives two or more back to
back rarp packets, simply discards all but the last??? I guess the hardware
can catch the packets, the software just can't keep up....

-ed cetron
cetron@cs.utah.edu

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 12:47:41 EST
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

Sorry to have kept you waiting; I have been off form as it happens, and
off to the Left Coast to boot.

Rather than succumb to the temptation of trying to see how many epicycles
the ISORM has these days (though I must confess I had been convinced at
one point in time that the party line was that each layer could/did have
a management sublayer--but never found out if that also applied to each
sublayer, so wasn't sure if L3 was four or six epicycles deep), let's
go back to the initiating question.  As I recall, it was something like
where things like GGP, EGP, and HMP went in  the layering.  Although I
have a great deal of sympathy for those who didn't bite and in essence
placed such things orthogonal to the layering, I would like to observe
that there's an alternative for those who find that view unsatisfying:
If you believe that the layers are Applications/Process, Host-Host, and
Network (Interface)--i.e., the old simple as I, II, III ARM I've always
espoused--then the answer ought to be easy to derive for any of the
three (or other, like protocols).  If they have to do with doing things
in common for the users' processes to get the bits to go from Host to
Host, then they're L II is one approach.  If they're clearly not part
of the interface to the proximate comm subnet processor and also fairly
clearly not directly germane to the Applications/Process Layer, then
they're L II is the other approach.  (Note to the original question-
raiser: you're of course welcome to use my Form, but it works better
if you use my Content too.)  (Note to John Laws: as you well know, my
main problem with the ISORMites is that they seem to me to be attempting
to substitute Form for Content almost all the time.)

Hope that's not too characteristically cryptic; if it is, I'll cop
a plea based on an imminent cold on top of the jetlag.

   cheers, map
-------

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 13:15:18 EST
From:      tcp-ip-RELAY@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   (none)

,    tcp-ip@SRI-NIC.ARPA,    ARPANETMGR@DDN1.ARPA,    BOWERS@A.ISI.EDU,    SCCMGR@DDN1.ARPA,    SNIVELY@DDN1.ARPAARPANET-BBOARDS
Date: Tue, 24 Nov 87 10:15:18 PST
To: userID=DUM1@SFU.MAILNET,    tcp-ip@SRI-NIC.ARPA,    ARPANETMGR@DDN1.ARPA,    BOWERS@A.ISI.EDU,    SCCMGR@DDN1.ARPA,    SNIVE
Subject: Status of ARPANET Upgrade

As a result of a meeting held on 20 November to discuss the status of the
new ARPANET End-to-End protocol (PSN 7.0), it was determined that the
protocol requires more testing.
 
The tentative schedule is to cut over to the new End-to-End on
Saturday, 5 December.  Should no problems arise, the new End-to-End
will remain running throughout the week.
 
Hosts experiencing problems during this test period are asked to call
the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992.
 
 

-------

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 13:15:19 EST
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   Status of ARPANET Upgrade

As a result of a meeting held on 20 November to discuss the status of the
new ARPANET End-to-End protocol (PSN 7.0), it was determined that the
protocol requires more testing.

The tentative schedule is to cut over to the new End-to-End on
Saturday, 5 December.  Should no problems arise, the new End-to-End
will remain running throughout the week. 

Hosts experiencing problems during this test period are asked to call 
the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992.



-------

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 13:34:09 EST
From:      socha@drivax.UUCP (Henri J. Socha (7-x6628))
To:        comp.protocols.tcp-ip
Subject:   Re: Apologies and Arcnet

Answering your questions even as I read them:

In article <8711222235.AA13789@ARES.MIT.EDU> martillo@ATHENA.MIT.EDU writes:
>I noticed arcnet being discussed here.  Now my friends at Clearpoint
>use arcnet networking cards with vme bus interfaces for some sort of
>distributed memory testing.  After seeing arcnet mentioned in this
>newsgroup, I have become curious.  
>
>Where does arcnet come from?
 It was developed at Datapoint Corp. of San Antinio Texas in 1976 by
 members of the Advanced Product Development (R&D) group I was a memeber.
 Datapoint (and people in this group) also architected the "Intel 8008",
 the first dBase type of programme (that I know of), the 2nd PC (IBM's 5100
 was first), one of the first glass TTYs, etc.  (But enough of this.)

 The ARCnet hardware and protocol was designed by one Engineer
 with the help of two techs. and about 3 other people who discussed it
 and gave advice/suggestions.  The limitations of board (TTL MSI) space
 generated some of its idiocyncracies for example the DID is transmitted
 twice on the wire.

 The changes to Datapoint's DOS similar to what happens/happened when you
 go from PC-DOS 2.x to 3.x was done by one individual.  This DOS used a similar
 similar system to the NET USE of PC-DOS call MOUNT.
 By the way, remember that we are talking about a networking OS in 1976!

>Who uses it and why (instead of some other networking scheme)?

 It was first used inhouse to connect multiple Datapoint machines together so
 that production/purchasing/etc. could access common databases and allow more
 that 10 DataShare users access to one database.
 
 The only other network known (by us in R&D) was
 Ethernet (the original 3MegaBaud XEROX one).  It was decided (demanded)
 that a system be used where assured transmission within a maximum time
 be used.  The concept of CSMA/CD (Ethernet, etc.) still is revolting to me.

 ARC has very simple installation using what I call a connected star 
 configuration.  And is VERY robust in that most anything that happens to 
 the cable (connections/disconnections/wiring changes) can be done on a live
 system with reconfiguration handled automatically by the hardware.
 I.E. as long as your node doesn't need something now disconnected, your node
 does not even know that the break occured.

 The robustness, its reasonable speed, etc. have put it in I hear over 400,000
 installations (said so in some magazine in an article about OTHER networks!)
 I know of users in the
 * Business industry (Datapoint customers like the local city government with
   all departments on an ARCnet of many nodes.)
 * factory floor (large German manufacturer)
 * Actually anywhere you see nets, you'll see ARCnet.

 Remember, It was one of the first high speed commercial PC machine nets.
 And is still up there performance-wise against all newcommers in this market.
 (OK, not 50MegaBaud Hyperchannel but we're talking PCs here!)

>What are the achievable data rates?

 Ask anyone about effective rates and you get down to issues of OS
 performance as well (how well/much can the OS handle).  But let me mention
 some interesting facts even if not quite what you requested.
 * The system is defined as 2.5MBaud but because it uses an isocronous(sp?)
   transmission scheme (resync on each character in a message) to send
   8 data bits you must send 11 baud (3 sync bits preceed each data bit)
   therefore the effective data rate is about 1.8MegaBit per second.
 * When one person was testing some (bad?) hardware on a live network
   while many REAL users were using it, the response time degraded.
   The network of course still operated correctly but was loaded down
   by over 400 (256 byte) messages per second.
 * A live ARC system (at Datapoint again) had over 200 nodes on it (max is 255).
   About 150+ were active on the net and the message rate was about 200
   per second. (And yes, I saw this myself.)  Response time was good enough
   that all engineering nodes in R&D were diskless (not even diskettes).
   And, many/most other nodes were diskless too.  Dedicated files servers
   were used but the OS, a newer one written in '80 called RMS, considered
   any node a requestor or server so you could go to the Server and use it
   like any other machine.  They were just used as Servers so that all of
   memory could be a disk cache (fully dynamic, run an App. and cache shrinks).

   Response time?  OK, not as good as a local disk but good enough that it was
   not an issue.  In fact, in one test a copy from file server to file server
   by a user machine was slightly faster than a local copy!  Why? the caching!
   The file server could pre-read and post-write whole tracks to/from the disk
   optimally servicing requests from the network. Meanwhile the programme in
   the local machine was being handed BIG buffers of data that it just "wrote"
   back out over the net back to a file server.

>Where can I get literature on arcnet?

 Try:  Standard Micro Systems (they make the chip and sell a PC board)
	Datapoint (of course)  (They may have an 800 number)
	Radio Shack (UGH!)  Does sell some ARC hardware.
	Novell puts its LAN on ARCnet (and one of the fastest implementations)

>Yakim Martillo
			Shalom  v'litraot  Yakim

-- 
UUCP:...!amdahl!drivax!socha                                      WAT Iron'75
"Everything should be made as simple as possible but not simpler."  A. Einstein

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 14:08:30 EST
From:      tcp-ip-RELAY@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   (none)

,    lynch@A.ISI.EDU,    trewitt%miasma.stanford.edu@PARK-STREET.BBN.COM,    rcallon@PARK-STREET.BBN.COM,    tcp-ip@SRI-NIC.ARP
Date: Tue, 24 Nov 87 11:08:30 PST
To: userID=DUM1@SFU.MAILNET,    lynch@A.ISI.EDU,    trewitt%miasma.stanford.edu@PARK-STREET.BBN.COM,    rcallon@PARK-STREET.BBN.
Subject: re: Network Management

 
The goal of a protocol which can be implemented in a reasonably
short time frame (one of the goals of HEMS) seems inconsistent with
the goal of being consistent with ISO network management protocols.
If you want to be consistent with the ISO protocols, then you should
wait until they are done.  If you want something now (or within 6
months), then you are going to have to use something that is
available now (or can be developed in 6 months).
 
I don't understand why it is useful to have something which is sort
of vaguely like what we think CMIP is going to look like when it is
done.  Either you are compatible with an ISO standard or you're not.
Being sort of close doesn't seem to buy all that much.  (This assumes
that it is not possible to get "close enough" to interoperate with
the eventual ISO International Standard without changes, which I
think is a fairly safe assumption).
 
I think it would be easier to implement HEMS (or SGMP or HMP), and
accept that we will need to change at some time in the future, than
to argue at great length as to how to define a protocol which
resembles CMIP as much as possible, which will still need to be
implemented and then changed at some time in the future.
 
There is a lot of talk about being protocol consistent, but
relatively little about other aspects of building a network
management system.  A network management system which want to manage
multiple vendor's equipment in an Internet is going to have to speak
more than one network management protocol whether you like it or
not.  If the slowness of ISO doesn't assure this, then the large
amount of existing equipment and/or IBM is going to assure it
instead.  What is more difficult is to deal with incompatible data
sets returned from different devices, inconsistencies in the way
that the database is stored in different network management systems,
etc.  Thus if you are worried about the eventual transition from
TCP/IP to ISO, you should, for example, be worried about the
differences between the set of network management metrics defined by
HEMS and that being worked on for gateways in ANSI X3S33, and you
should think about what you intend to do with either set of data
when you get it into your system.
 
[Note:  My reference to the slowness of ISO should NOT in any way
be interpreted as a complaint.  The process of developing an
international standard is of necessity a very slow and laborious
process.  The complexity of network management make the CMIP
development even harder.  However, we have to accept that this
process is not likely to speed up.]
 
Ross

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 14:08:31 EST
From:      rcallon@PARK-STREET.BBN.COM (Ross Callon)
To:        comp.protocols.tcp-ip
Subject:   re: Network Management


The goal of a protocol which can be implemented in a reasonably
short time frame (one of the goals of HEMS) seems inconsistent with
the goal of being consistent with ISO network management protocols.
If you want to be consistent with the ISO protocols, then you should
wait until they are done.  If you want something now (or within 6
months), then you are going to have to use something that is
available now (or can be developed in 6 months).

I don't understand why it is useful to have something which is sort
of vaguely like what we think CMIP is going to look like when it is
done.  Either you are compatible with an ISO standard or you're not.
Being sort of close doesn't seem to buy all that much.  (This assumes
that it is not possible to get "close enough" to interoperate with
the eventual ISO International Standard without changes, which I
think is a fairly safe assumption).

I think it would be easier to implement HEMS (or SGMP or HMP), and
accept that we will need to change at some time in the future, than
to argue at great length as to how to define a protocol which
resembles CMIP as much as possible, which will still need to be
implemented and then changed at some time in the future.  

There is a lot of talk about being protocol consistent, but
relatively little about other aspects of building a network
management system.  A network management system which want to manage
multiple vendor's equipment in an Internet is going to have to speak
more than one network management protocol whether you like it or
not.  If the slowness of ISO doesn't assure this, then the large
amount of existing equipment and/or IBM is going to assure it
instead.  What is more difficult is to deal with incompatible data
sets returned from different devices, inconsistencies in the way
that the database is stored in different network management systems,
etc.  Thus if you are worried about the eventual transition from
TCP/IP to ISO, you should, for example, be worried about the
differences between the set of network management metrics defined by
HEMS and that being worked on for gateways in ANSI X3S33, and you
should think about what you intend to do with either set of data
when you get it into your system.

[Note:  My reference to the slowness of ISO should NOT in any way 
be interpreted as a complaint.  The process of developing an
international standard is of necessity a very slow and laborious
process.  The complexity of network management make the CMIP
development even harder.  However, we have to accept that this
process is not likely to speed up.]

Ross

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 87 14:08:31 EST
From:      Ross Callon <rcallon@PARK-STREET.BBN.COM>
To:        lynch@A.ISI.EDU, trewitt%miasma.stanford.edu@PARK-STREET.BBN.COM
Cc:        rcallon@PARK-STREET.BBN.COM, tcp-ip@SRI-NIC.ARPA, gwmon@SH.CS.NET, netman@AMADEUS.STANFORD.EDU
Subject:   re: Network Management

The goal of a protocol which can be implemented in a reasonably
short time frame (one of the goals of HEMS) seems inconsistent with
the goal of being consistent with ISO network management protocols.
If you want to be consistent with the ISO protocols, then you should
wait until they are done.  If you want something now (or within 6
months), then you are going to have to use something that is
available now (or can be developed in 6 months).

I don't understand why it is useful to have something which is sort
of vaguely like what we think CMIP is going to look like when it is
done.  Either you are compatible with an ISO standard or you're not.
Being sort of close doesn't seem to buy all that much.  (This assumes
that it is not possible to get "close enough" to interoperate with
the eventual ISO International Standard without changes, which I
think is a fairly safe assumption).

I think it would be easier to implement HEMS (or SGMP or HMP), and
accept that we will need to change at some time in the future, than
to argue at great length as to how to define a protocol which
resembles CMIP as much as possible, which will still need to be
implemented and then changed at some time in the future.  

There is a lot of talk about being protocol consistent, but
relatively little about other aspects of building a network
management system.  A network management system which want to manage
multiple vendor's equipment in an Internet is going to have to speak
more than one network management protocol whether you like it or
not.  If the slowness of ISO doesn't assure this, then the large
amount of existing equipment and/or IBM is going to assure it
instead.  What is more difficult is to deal with incompatible data
sets returned from different devices, inconsistencies in the way
that the database is stored in different network management systems,
etc.  Thus if you are worried about the eventual transition from
TCP/IP to ISO, you should, for example, be worried about the
differences between the set of network management metrics defined by
HEMS and that being worked on for gateways in ANSI X3S33, and you
should think about what you intend to do with either set of data
when you get it into your system.

[Note:  My reference to the slowness of ISO should NOT in any way 
be interpreted as a complaint.  The process of developing an
international standard is of necessity a very slow and laborious
process.  The complexity of network management make the CMIP
development even harder.  However, we have to accept that this
process is not likely to speed up.]

Ross
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 14:41:06 EST
From:      tcp-ip-RELAY@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   (none)

,    LAWS%rsre.mod.uk@NSS.CS.UCL.AC.UK,    CERF@A.ISI.EDU,    tcp-ip@SRI-NIC.ARPA,    oconnor@SCCGATE.SCC.COM
Date: Tue, 24 Nov 87 11:41:06 PST
To: userID=DUM1@SFU.MAILNET,    LAWS%rsre.mod.uk@NSS.CS.UCL.AC.UK,    CERF@A.ISI.EDU,    tcp-ip@SRI-NIC.ARPA,    oconnor@SCCGATE
Subject: Re: Idle chatter about reference models

Ooops.  More off form than I'd realized [/realised]:  Belatedly occurred to
me that the Layer, Layer, Who's Got the Layer context is a good one for
remembering that even if the ISORMites still think you've got to traverse
every layer every time, I never did (and they might not any more, if one
thinks things like "MAP" [which, of course, should be "MAPS" to begin with,
since it's a Suite, not just A protocol] are ISORMitic, since it blithely
skips a layer or two on its way).  So I'd refine my answer to the original
question to include something like "They sure seem to me to be operating
at L II WHEN THEY'RE OPERATING."  That might somehow subsume the notion
that a few people had that they're not really "in" the "stack"--or
perhaps subvert it, if not subsume it.  (And I guess it's also
worth pointing out that is assumes HMP, which I haven't looked at,
doesn't muddy the waters and operate over TCP connections, which
would almost make it have to be L III by my insistently non-rigorous
definitions.)
   fuzzy cheers, map
p.s. So as not to generate a new Glossary call, for the benefit of
those who haven't been around long enough, "ISORM" = ISO Reference
Model; ISORMite = follower of the ISORM who I feel is of dubious
worth (as opp. to ISORMist, which is one I feel to be sound in other
respects but wrong about the RM issue).  (The reason why I don't
use "OSI" is that I feel it begs the question; i.e., they may say
they're doing Open System Interconnection in their name, but are
they in their RM ... or their standard protocols?  Besides, I like the
sound of ISORM.)
-------

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 14:41:07 EST
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Idle chatter about reference models

Ooops.  More off form than I'd realized [/realised]:  Belatedly occurred to
me that the Layer, Layer, Who's Got the Layer context is a good one for
remembering that even if the ISORMites still think you've got to traverse
every layer every time, I never did (and they might not any more, if one
thinks things like "MAP" [which, of course, should be "MAPS" to begin with,
since it's a Suite, not just A protocol] are ISORMitic, since it blithely
skips a layer or two on its way).  So I'd refine my answer to the original
question to include something like "They sure seem to me to be operating
at L II WHEN THEY'RE OPERATING."  That might somehow subsume the notion
that a few people had that they're not really "in" the "stack"--or
perhaps subvert it, if not subsume it.  (And I guess it's also
worth pointing out that is assumes HMP, which I haven't looked at,
doesn't muddy the waters and operate over TCP connections, which
would almost make it have to be L III by my insistently non-rigorous
definitions.)
   fuzzy cheers, map
p.s. So as not to generate a new Glossary call, for the benefit of
those who haven't been around long enough, "ISORM" = ISO Reference
Model; ISORMite = follower of the ISORM who I feel is of dubious
worth (as opp. to ISORMist, which is one I feel to be sound in other
respects but wrong about the RM issue).  (The reason why I don't
use "OSI" is that I feel it begs the question; i.e., they may say
they're doing Open System Interconnection in their name, but are
they in their RM ... or their standard protocols?  Besides, I like the
sound of ISORM.)
te: 2ybo

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 14:54:24 EST
From:      tcp-ip-RELAY@SRI-NIC.ARPA ("tcp-ip-RELAY%SRI-NIC.ARPA")
To:        comp.protocols.tcp-ip
Subject:   (none)

,    nsfnet@NNSC.NSF.NET,    tcp-ip@SRI-NIC.ARPA,    steve@note.nsf.gov
Date: Tue, 24 Nov 87 11:54:24 PST
To: userID=DUM1@SFU.MAILNET,    nsfnet@NNSC.NSF.NET,    tcp-ip@SRI-NIC.ARPA,    steve@NOTE.NSF.GOV
Subject: Award

The National Science Foundation today announced a five-year, $14
million grant to MERIT, Inc., for the upgrading, operation and
management of the NSFNET transcontinental backbone network.
(MERIT currently operates the Merit Computer Network, Michigan's
statewide higher education network.)
 
In addition to the NSF support, the state of Michigan will
contribute $5 million to the effort, International Business
Machines Corp. will contribute hardware and software worth more
than $10 million, and MCI Communications Corp. will provide
communications lines and support services.
 
The agreement provides for communication on the backbone at 1.544
mb/s ("T1"), a Network Operations Center staffed around the
clock, and comprehensive information services, including an
Information Center and a Technical Support Staff.
 
NSF has agreements with other Federal agencies that operate networks
to support scientific research.  The upgraded NSF backbone is expected
to play a major role in the emerging Interagency Research Internet.
 

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Nov 87 14:54:24 EST
From:      steve@note.nsf.gov
To:        nsfnet@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA
Cc:        steve@note.nsf.gov
Subject:   Award
The National Science Foundation today announced a five-year, $14
million grant to MERIT, Inc., for the upgrading, operation and
management of the NSFNET transcontinental backbone network.
(MERIT currently operates the Merit Computer Network, Michigan's
statewide higher education network.)

In addition to the NSF support, the state of Michigan will
contribute $5 million to the effort, International Business
Machines Corp. will contribute hardware and software worth more
than $10 million, and MCI Communications Corp. will provide
communications lines and support services.

The agreement provides for communication on the backbone at 1.544
mb/s ("T1"), a Network Operations Center staffed around the
clock, and comprehensive information services, including an
Information Center and a Technical Support Staff.

NSF has agreements with other Federal agencies that operate networks
to support scientific research.  The upgraded NSF backbone is expected
to play a major role in the emerging Interagency Research Internet.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 15:28:08 EST
From:      asjoshi@phoenix.Princeton.EDU (Amit S. Joshi)
To:        comp.protocols.tcp-ip
Subject:   Turbo C TCP/IP

Hello,

This is to apologize to the people whom I promised to send the Turbo C version.
I was about to send it when I realized that my 3 Com board seems to have 
undergone  a crash. It no longer talks to some machines. It seems to work fine 
with some however. I don't know if the problem is with the ported version but
to preclude any grief to anybody I am NOT mailing the code unless somebody is 
willing to risk his/her board.

Once again I'm sorry.


-- 
Amit Joshi         |  BITNET :  Q3696@PUCC.BITNET
                   |  USENET :  ...{seismo, rutgers}!princeton!phoenix!asjoshi
"There's a pleasure in being mad ...which none but madmen know!" St.Dryden

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 16:05:11 EST
From:      socha@drivax.UUCP (Henri J. Socha (7-x6628))
To:        comp.protocols.tcp-ip
Subject:   Re: Apologies and Arcnet

OOPS, I made a typo in the previous message (and an important one)
please 'n' if you 'n'd the ARCnet discussion.

In article <2756@drivax.UUCP> socha@drivax.UUCP (Henri J. Socha (7-x6628)) writes:

> I know of users in the
> * Business industry (Datapoint customers like the local city government with
>   all departments on an ARCnet of many nodes.)
  **** That was:  The local city govt. uses a Datapoint ARCnet system
	and they are very happy with it (including the programmers) last time
	I talked with them.

> * The system is defined as 2.5MBaud but because it uses an isocronous(sp?)
>   transmission scheme (resync on each character in a message) to send
>   8 data bits you must send 11 baud (3 sync bits preceed each data bit)
 **** OOPS that's 3 re-sync bits per BYTE!
>   therefore the effective data rate is about 1.8MegaBit per second.
			(2.5 *  8/11)

-- 
UUCP:...!amdahl!drivax!socha                                      WAT Iron'75
"Everything should be made as simple as possible but not simpler."  A. Einstein

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 17:44:16 EST
From:      tcp-ip-RELAY@SRI-NIC.ARPA ("tcp-ip-RELAY%SRI-NIC.ARPA")
To:        comp.protocols.tcp-ip
Subject:   (none)

,    trewitt@miasma.stanford.edu,    LYNCH@a.isi.edu,    tcp-ip@sri-nic.arpa,    netman@amadeus.stanford.edu,    gwmon@sh.cs.net
Date: Tue, 24 Nov 87 14:44:16 PST
To: userID=DUM1@SFU.MAILNET,    trewitt@MIASMA.STANFORD.EDU,    LYNCH@A.ISI.EDU,    tcp-ip@SRI-NIC.ARPA,    netman@AMADEUS.STANF
Subject: Re: Network Management

My concern is rather the opposite of the others that I have heard.  I
am concerned that participants in the closed Netman meeting have made
a decision which, although plausible, will have no effect other than
excluding them from the IP community.  It is clear that HEMS and SGMP
will be implemented by the major gateway vendors, and on Unix.  (I
wish we could pick one or the other, but I have a feeling we will end
up with both HEMS and SGMP everywhere.)  This will happen by January.
The hope had been that we could avoid completely separate IP and ISO
implementations by the work of the Netman group.  If this has really
failed, the result will be separate IP and ISO work, not CMIS over IP.
Experience is very clear that a few months delay in this business is
fatal.  It is probably not too late to make extensions to HEMS if
necessary to allow the Netman group to meet its goals.  In my view it
is too late to come up with another protocol.  I am hoping that all of
the participants in Netman can somehow be persuaded to try again.  I
think we need to find a way to make things proceed according to the
original gameplan.
 
In this context it is important to avoid seeing the issue as somehow
"the vendors" against the IP community.  Not all vendors were present
at the meeting.  Indeed the purveyors of the major gateway
implementations were noticable by their absence.  So I'd like to see
us avoid using "the vendors" as if there were one such entity, and
they all adopted the same position.  I am in fact avoiding assigning
any term to those who participated in the meeting in question, since I
am unable to find any term that is not emotionally loaded.
 

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 17:44:17 EST
From:      hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Management

My concern is rather the opposite of the others that I have heard.  I
am concerned that participants in the closed Netman meeting have made
a decision which, although plausible, will have no effect other than
excluding them from the IP community.  It is clear that HEMS and SGMP
will be implemented by the major gateway vendors, and on Unix.  (I
wish we could pick one or the other, but I have a feeling we will end
up with both HEMS and SGMP everywhere.)  This will happen by January.
The hope had been that we could avoid completely separate IP and ISO
implementations by the work of the Netman group.  If this has really
failed, the result will be separate IP and ISO work, not CMIS over IP.
Experience is very clear that a few months delay in this business is
fatal.  It is probably not too late to make extensions to HEMS if
necessary to allow the Netman group to meet its goals.  In my view it
is too late to come up with another protocol.  I am hoping that all of
the participants in Netman can somehow be persuaded to try again.  I
think we need to find a way to make things proceed according to the
original gameplan.

In this context it is important to avoid seeing the issue as somehow
"the vendors" against the IP community.  Not all vendors were present
at the meeting.  Indeed the purveyors of the major gateway
implementations were noticable by their absence.  So I'd like to see
us avoid using "the vendors" as if there were one such entity, and
they all adopted the same position.  I am in fact avoiding assigning
any term to those who participated in the meeting in question, since I
am unable to find any term that is not emotionally loaded.

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 18:20:57 EST
From:      andrea@hp-sdd.HP.COM (Andrea K. Frankel)
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Standard for Printers

In article <135@tsdiag.UUCP> tom@tsdiag.UUCP writes:
>
>THIS IS A FORWARDED MESSAGE Follows is the *REAL* header:
>From: n2dsy@hou2d.UUCP (G.BEATTIE)
>
>I have been looking around for something similar to the
>ANSI X3.64 Terminal Protocol Specification for printers
>or printing terminals.   I guess that in some "ideal"
>world we would have something analogous to the Virtual
>Terminal Protocol for printers, but I am willing and
>seeking suggestions regarding printer standards for
>simple and medium-complexity printers.

ECMA has a task group working on printer formats; their current
proposal is called a "Standard Page Description Language" which
can be translated to actual PDL's such as Postscript or printer
languages such as PCL.  Presumably a "standard PDL" could be 
implemented directly in a printer in the future.

The ISO committee TC97/SC18 (and the corresponding ANSC X3V1)
are also working in this area.  

You can contact ANSI in New York to get a contact for X3V1
committee work; that should give you an in to the other groups
as well.

Andrea Frankel, Hewlett-Packard (San Diego Division) (619) 592-4664
                "...like a song that's born to soar the sky"
______________________________________________________________________________
UUCP     : ...hplabs!hp-sdd!andrea from 
	   {ihnp4|cbosgd|allegra|decvax|gatech|sun|tektronix}
           or ...hp-sdd!andrea from {hp-pcd|hpfcla|hpda|noscvax|gould9|sdcsvax}
Internet : andrea%hp-sdd@ {nosc.mil | sdcsvax.ucsd.edu | hplabs.HP.com}
CSNET    : andrea%hp-sdd@hplabs.csnet
USnail   : 16399 W. Bernardo Drive, San Diego CA 92127-1899 USA

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Nov 87 00:39:00 PST
From:      "tcp-ip-RELAY%SRI-NIC.ARPA"   <@um.cc.umich.edu,@SFU:@UM.CC.UMICH.EDU:tcp-ip-RELAY@SRI-NIC.ARPA>
To:        Tcp-ip-dist:userID=DUM1%SFU.BITNET@umix.cc.umich.edu, My_Hangout%SFU.BITNET@umix.cc.umich.edu, Userid=Q73X%UBC.Mailnet@umix.cc.umich.edu, userID=TCP%SFU.BITNET@umix.cc.umich.edu, tcp-ip%UBCMTSG.B@umix.cc.umich.edu
,    tcp-ip@sri-nic.arpa
Date: Wed, 25 Nov 87 00:39:00 PST
To: userID=DUM1@SFU.MAILNET,    tcp-ip@SRI-NIC.ARPA
Subject: TCP/IP software

Greetings,
 
I need to get ahold of some information, and this seems like the best place to
look for it.  I'm looking for:
 
(1) TCP/IP software for PC's:  I know of MICOM/Interlan, Excelan, FTP
    Software and WIN/PC, and have been in contact with each of them.  I've
    heard tell of flavors from CMU, MIT (I believe FTP Software's is based on
    MIT's), Stanford, UMD, and even IBM.  Are there any others to add to this
    list?  Any good/bad points to watch for on any of them?  What addresses/
    contacts should I use to get ahold of people at the universities about
    their software?  Do any of the above have the capability to gateway IP
    packets from Tolkien ring to Easternet (external of something like
    Netware)?  For that matter, do any of the above have Token ring drivers?
 
(2) TCP/IP software for PS/2's:  Does it exist or does anyone make an Ethernet
    card for the PS/2 compatible with PC cards on the driver level?  Anyone
    have any word yet on networking under OS/2?
 
(3) Does anyone know what (if any) PC Ethernet cards from different vendor are
    compatible with each other (eg, maybe NI5010 vs 3C501)?
 
Please respond personally, and I'll summarize to the list.  To any and all,
thanks in advance for any information that I'm sure will save me hours of time
giving phone...
 
L. Stuart Vance
Network Systems Specialist
UT System Office of Telecommunication Services
 
THEnet:   UTCHPC::S.VANCE               BITNET:  S.VANCE@UTCHPC
Internet: S.VANCE@CHPC.BRC.UTEXAS.EDU   Ma Bell: (512) 471-2416
------
-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 22:11:18 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Network Management


Charles,  Thank you for clearly stating your views.  I agree that any
path is going to take a lot of work.  It would be best if we all
could get on with the "work" to be done.  The characterization of
the vendors who are favoring the CMIS approach is best described as
"end system vendors" as opposed to "gateway vendors".  They see their
customers as drowning in network "administration" details in addition 
to netowrk "management" details.  A few years back you (and I) were
running timesharing systems and we did that with a ton of software
and human procedures that were tightly integrated (evefn if by dint
of hard work and numerous kludges that remained invisible to our
customers).  The joy of networking has stripped managers of that tight
integration of administrative tools.  Dealing with routing protocol
misbehaviour is only the tip of the iceberg (even if that tip will 
still sink the largest ship someday).  So, end users need to have their 
entire "computing facilities" managed.  I think that is what this group of
vendors is wrestling with.  

I hope all parties can find a way to combine efforts for the benefit of
all users.  After all, satisfied users are the lifeblood of us all.

Dan
-------

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24-Nov-87 23:01:08 EST
From:      robert@pyr.gatech.EDU (Robert Viduya)
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Standard for Printers

> From: n2dsy@hou2d.UUCP (G.BEATTIE)
> 
> I have been looking around for something similar to the
> ANSI X3.64 Terminal Protocol Specification for printers
> or printing terminals.

The ANSI X3.64 (or it's international equivalent ISO 6429) standard is
general enough to be applied to printers.  Neither standard ties itself
to just CRTs.  Using both ANSI X3.4 (ISO 646) and ANSI X3.64 (ISO 6429)
should give you enough functions for ordinary printing terminals.
You'll have to trim them a bit, obviously (insert/delete-line/char would
be a bit difficult to implement), but the standards don't require you to
implement everything.

			robert
-- 
Robert Viduya						  robert@pyr.gatech.edu
Office of Computing Services
Georgia Institute of Technology					 (404) 894-4660
Atlanta, Georgia	30332

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 01:09:02 EST
From:      tcp-ip-RELAY@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   (none)

,    tcp-ip@SRI-NIC.ARPA
Date: Tue, 24 Nov 87 22:09:02 PST
To: userID=DUM1@SFU.MAILNET,    tcp-ip@SRI-NIC.ARPA
Subject: TN3270 speeds

Greg pointed out to me that what I saw was actually running on an RT, not
a Sun, and that a Sun is faster, but still not as fast as a PC.  Yakov
confirmed this re: the IBM PC TN3270 (DOS coders can write directly to
the display, and curses costs a lot).
 
jbvb
 

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 01:09:03 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   TN3270 speeds

Greg pointed out to me that what I saw was actually running on an RT, not
a Sun, and that a Sun is faster, but still not as fast as a PC.  Yakov
confirmed this re: the IBM PC TN3270 (DOS coders can write directly to
the display, and curses costs a lot).

jbvb

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 03:39:00 EST
From:      xxss520@CHPC.BRC.UTEXAS.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   TCP/IP software

Greetings,

I need to get ahold of some information, and this seems like the best place to
look for it.  I'm looking for:

(1) TCP/IP software for PC's:  I know of MICOM/Interlan, Excelan, FTP
    Software and WIN/PC, and have been in contact with each of them.  I've
    heard tell of flavors from CMU, MIT (I believe FTP Software's is based on
    MIT's), Stanford, UMD, and even IBM.  Are there any others to add to this
    list?  Any good/bad points to watch for on any of them?  What addresses/
    contacts should I use to get ahold of people at the universities about
    their software?  Do any of the above have the capability to gateway IP
    packets from Tolkien ring to Easternet (external of something like
    Netware)?  For that matter, do any of the above have Token ring drivers?

(2) TCP/IP software for PS/2's:  Does it exist or does anyone make an Ethernet
    card for the PS/2 compatible with PC cards on the driver level?  Anyone
    have any word yet on networking under OS/2?

(3) Does anyone know what (if any) PC Ethernet cards from different vendor are
    compatible with each other (eg, maybe NI5010 vs 3C501)?

Please respond personally, and I'll summarize to the list.  To any and all,
thanks in advance for any information that I'm sure will save me hours of time
giving phone...

L. Stuart Vance
Network Systems Specialist
UT System Office of Telecommunication Services

THEnet:   UTCHPC::S.VANCE		  BITNET:  S.VANCE@UTCHPC
Internet: S.VANCE@CHPC.BRC.UTEXAS.EDU	  Ma Bell: (512) 471-2416
------

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 87 03:39:00 CDT
From:      "L. Stuart Vance" <xxss520@chpc.brc.utexas.edu>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   TCP/IP software
Greetings,

I need to get ahold of some information, and this seems like the best place to
look for it.  I'm looking for:

(1) TCP/IP software for PC's:  I know of MICOM/Interlan, Excelan, FTP
    Software and WIN/PC, and have been in contact with each of them.  I've
    heard tell of flavors from CMU, MIT (I believe FTP Software's is based on
    MIT's), Stanford, UMD, and even IBM.  Are there any others to add to this
    list?  Any good/bad points to watch for on any of them?  What addresses/
    contacts should I use to get ahold of people at the universities about
    their software?  Do any of the above have the capability to gateway IP
    packets from Tolkien ring to Easternet (external of something like
    Netware)?  For that matter, do any of the above have Token ring drivers?

(2) TCP/IP software for PS/2's:  Does it exist or does anyone make an Ethernet
    card for the PS/2 compatible with PC cards on the driver level?  Anyone
    have any word yet on networking under OS/2?

(3) Does anyone know what (if any) PC Ethernet cards from different vendor are
    compatible with each other (eg, maybe NI5010 vs 3C501)?

Please respond personally, and I'll summarize to the list.  To any and all,
thanks in advance for any information that I'm sure will save me hours of time
giving phone...

L. Stuart Vance
Network Systems Specialist
UT System Office of Telecommunication Services

THEnet:   UTCHPC::S.VANCE		  BITNET:  S.VANCE@UTCHPC
Internet: S.VANCE@CHPC.BRC.UTEXAS.EDU	  Ma Bell: (512) 471-2416
------
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 06:43:13 EST
From:      kent@xanth.UUCP (Kent Paul Dolan)
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Standard for Printers

Gorden,

I don't know how much of a standard you want, but if you are looking
for something that works well in practice, look into the method used
by Commmodore in their Amiga line of computers.  They have chosen or
designed a device neutral language for printing commands that all
adhering programs use to "talk printer".  Then, for each printer type,
the vendor designs a printer driver that reads this device neutral
format printer code and converts it to the commands for that specific
printer.  The device neutral language seems quite powerful, and it
covers both character mode and (for raster printers) graphics mode
commands.  

The details are in:

	Amiga Rom Kernal Reference Manual, Libraries and Devices,
	Commodore Business Machines, Inc., Addison Wesley Publishing
	Company, Inc., ISBN 0-201-11078-4, US$34.95.

See especially the table of commands beginning on page e-38 and the
one on e-41.

The "standard" seems to be a mix of ANSII x3.64 and DEC usages, plus
some stuff home brewed by Commodore.

As I say, it works VERY well, and I wish more micro manufacturers
would adopt it, because it uncouples applications programs from the
printer drivers, making all programs usable with (almost) all
printers.  I know it has allowed a mix of Daisy Wheel, 9 pin raster,
24 pin raster, laser, and ink-jet printers for the Amiga with no
change to applications programs.

Kent, the man from xanth.

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 07:03:46 EST
From:      tcp-ip-RELAY@SRI-NIC.ARPA ("tcp-ip-RELAY%SRI-NIC.ARPA")
To:        comp.protocols.tcp-ip
Subject:   (none)

,    tcp-ip@sri-nic.arpa
Date: Wed, 25 Nov 87 02:55:15 PST
To: userID=DUM1@SFU.MAILNET,    tcp-ip@SRI-NIC.ARPA
Subject: Turbo C TCP/IP

Hello,
 
This is to apologize to the people whom I promised to send the Turbo C version.
I was about to send it when I realized that my 3 Com board seems to have
undergone  a crash. It no longer talks to some machines. It seems to work fine
with some however. I don't know if the problem is with the ported version but
to preclude any grief to anybody I am NOT mailing the code unless somebody is
willing to risk his/her board.
 
Once again I'm sorry.
 
 
--
Amit Joshi         |  BITNET :  Q3696@PUCC.BITNET
                   |  USENET :  ...{seismo, rutgers}!princeton!phoenix!asjoshi
"There's a pleasure in being mad ...which none but madmen know!" St.Dryden

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 08:09:05 EST
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP maximum segment size determination

>It's hard to believe that in this age of utterly cheap dense RAM,
>otherwise sane people are proposing inserting artificial delays between
>Ethernet packets because a lowball vendor wouldn't put, say, TWO
>buffers on their card!
>
>[I admit I'm prejudiced, since I worked on Suns, which currently seem
>to have the highest Ethernet thruput, but they were built out of
>standard Ethernet chips and DRAMs available to everyone.  You too can
>handle infinite back to back packets, if you just design with that in
>mind as Sun did.]
>

	But whhhat about all those old, old Suns, the ones without back to
	back capacity.  What about the tens of thousands of NI5010's or
	3C501's.  People bought them, have them, are working with them
	daily even though no double buffering is available.  Its not just
	a querstion of being a lowball vendor,  reality is the fact that
	old outmode hardware is out there and used!  Software must be
	cognizent that it will not always run in ideal situations.  In
	fact, I define good softwarre as that which can perform adaquately
	under less than ideal environmental situations.

						Larry Backman
						Micom - Interlan

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 12:24:12 EST
From:      gp@lll-lcc.aRpA (George Pavel)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Lawrence Livermore IGP project?

in article <408@cayman.UUCP>, brad@cayman.UUCP (Brad Parker) says:
> Does anyone have any information on the Lawrence Livermore Lab
> Intelligent Gateway Processor (IGP) project?
> 
> Brad Parker
> Cayman Systems

This software is now being marketed commercially by Control Data Corp (CDC).
Non-commercial inquiries should probably be addressed to the Technology
Information Systems (TIS) Program at LLNL.  I don't know the specific person to
contact, but a message to postmaster@lll-tis.arpa or root@lll-tis.arpa will
probably get you some information.

George Pavel  (I am not involved with the TIS Project)
Lawrence Livermore National Laboratory
P.O. Box 808  L-68			Internet: gp@lll-lcc.arpa
Livermore, CA 94550			      gp@lll-lcc.llnl.gov after 12/1/87
(415)422-4262				UUCP: ihnp4!lll-lcc!gp

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 15:53:12 EST
From:      ccruss@deneb.ucdavis.edu.UUCP
To:        comp.protocols.tcp-ip
Subject:   SLIP software available

Yes,  we have a SLIP server implementation  now ready. The reason I have 
not  posted it sooner is  because we have been  working with the Sun NFS 
people  on the method of establishing a  dialin slip connection and have 
been   refitting   some   of   their   suggestions   into  our  version.  

The software allows PCs to make dialup SLIP connections to the campus IP 
network. We are also have worked out a method of abbreviated serial line 
IP  (ASLIP) packeting that makes dialup  IP networks more efficient. The 
ASLIP software is new to this version and Sun has not seen it yet. 

Here  is how  the system  works. The  user logs  on to  the host that is 
acting  as the gateway, a  4.3 bsd system. He  then types in the command 
"slip"  and he becomes  a host on  the network. He  can then use all the 
programs that come with the CMU/MIT PC/IP or Phil Karn's system. To make 
connecting  to the network  a little easier,  we have written  a program 
that  will do the complete  login automatically. The program  has a user 
configurable  script file that  specifies a sequence  of strings to send 
out  the serial line and  responses to wait for  coming back. It has its 
own  simple language with branching depending on if the correct response 
came  back. The net result is that after the script has been set up, the 
user types in one command on the PC to connect to the network. 

Unlike  some PC/IPs, our system  assumes that each PC  (or actually each 
user)  has its own, permanent IP address.  Security is provided by logon 
security  on the gateway  host. The IP  address of the  PC is associated 
with  the usercode on the gateway host.  The network connection for that 
PC's  IP address  can only  be started  from a  user logged  in with the 
correct  usercode. The system also makes sure that the IP address is not 
already connected before making a new connection. 

The  way we have  set up IP  address for the  PCs is to  have a separate 
subnet  that contains all the PCs. This  way the gateway host needs only 
to  advertise that  it is  a route  to that  subnet and  all the PCs are 
covered.  In  essence  the  gateway  host  is  the  network for all SLIP 
connections on that subnet. 

The  abbreviated  packets  work  on  the  assumption that the connecting 
computer  is an endnode and will not be  doing any routing. In this case 
many  of the  fields in  the IP  packet are  unnecessary. ASLIP uses the 
minimum header size based on this assumption. With ASLIP the header size 
is  either 8 or  4 bytes, much  smaller than the  standard 40 bytes. The 
host  that is acting as the ASLIP  gateway rebuilds the outgoing packets 
to  legal IP packets before sending them out the network and abbreviates 
the  incoming packets from the network. The same server software handles 
both  SLIP and ASLIP. It only goes into  ASLIP mode once it has received 
an ASLIP packet from the PC, thus if only SLIP packets are sent, it will 
stay  in  regular  SLIP  mode.  I  will  post  more details on the ASLIP 
protocol later. 

Also  there have  been some  terminal server  vendors interested in this 
project.  It should not be  much work to turn  a terminal server into an 
ASLIP  or SLIP server and that would make it cheaper than using a VAX as 
the  gateway. Plus there would  not be as much  maintenance and downtime 
with a simple server box. 

The  software is available via anonymous FTP  from ucdavis.edu and is in 
the  directory  dist/slip/.  This  includes  all  software  to  run  the 
SLIP/ASLIP  server on  a 4.3  bsd system,  and the  modifications to CMU 
PC/IP software to implement ASLIP and the auto-login program, plus fix a 
couple bugs.  See the README file in this directory for a discription of
what the various tar files give you.

The  next thing we  want to add  to the system  is BOOTP so  that the PC 
software  does not have to be configured  for IP address, but rather get 
it from the server. 

                                Russell Hobby               
                         Data Communications Manager 
     U. C. Davis                 
     Computing Services       BITNET:    RDHOBBY@UCDAVIS 
     Davis Ca 95616           UUCP:      ...!ucbvax!ucdavis!rdhobby 
     (916) 752-0236           INTERNET:  rdhobby@ucdavis.edu

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 16:10:00 EST
From:      stanonik@NPRDC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   pop

Are there any pop (post office protocol) implementations
for VAXs and SUNs?

Thanks,

Ron Stanonik
stanonik@nprdc.arpa

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 17:17:24 EST
From:      alan@cunixc.columbia.edu (Alan Crosswell)
To:        comp.protocols.tcp-ip
Subject:   Wanted: BSD UNIX HMP (RFC869) implementation

Does anybody have a Berkeley UNIX implementation of a RFC869 Host Monitoring
Protocol (HMP) client that I could have?  I believe that the "HMP"
that you get with the IBM "PCIP" (5798-FAL) is the same as RFC869 HMP.
Anybody who knows for sure please correct me if I'm wrong.

Thanks.

Alan Crosswell
Columbia University
alan@columbia.edu

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25-Nov-87 18:09:37 EST
From:      gross@gateway.mitre.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   re: Network Management


> I don't understand why it is useful to have something which is sort
> of vaguely like what we think CMIP is going to look like when it is
> done.  Either you are compatible with an ISO standard or you're not.
> Being sort of close doesn't seem to buy all that much.  

Ross,

I have been informed in private that these days it is a wise
business decision to at least give the appearance of conforming to
OSI standards.  Utilizing TCP and IP is fine because it is already
here, but for something that needs to implemented from scratch, I've 
been told that many vendors feel contrained to an OSI solution.

The argument about avoiding development costs by not implementing 
twice may not be as important as soothing nervous customers about 
multi-vendor OSI interoperability.  If vendors were only concerned 
with not implementing twice, they might have taken a harder look at 
the Simple Gateway Monitoring Protocol (SGMP) effort.  

SGMP is yet a third network management consortium effort that started about 
the same time as (and has drawn from) HEMS and Netman.  At the Boulder IETF 
meeting, a very impressive real-time demo was given of a PC based SGMP 
package (with whizbang color graphics) monitoring a real state-wide 
regional network.  My understanding is that C source code is available 
for tested, interoperable implementations under BSD Unix, MS-DOS and two 
other platforms.  SGMP has been documented in a recent RFC and I think 
there are plans for it be discussed at the upcoming Interoperability 
conference.  For vendors whose goal is to minimize development costs,
perhaps SGMP deserves a closer look.

Phill Gross

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 87 21:42:00 EST
From:      "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        enger
Subject:   Unbuffered Ethernet boards for PCs
Gentlemen wrote recently of their concern that unbuffered Ethernet adapter
cards for PCs were dropping packets.  Atleast for TCP based traffic, some
relief may be coming.  Messrs. Jacobsen and Karels have been testing an
improved TCP that may help to some extent by keeping the window small (due to
the recurring losses). 

Should this not prove sufficient, I vote for sending the unbuffered cards to 
the Smithsonian. :-)

Hope everyone had a nice Thanksgiving Day,
Bob

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Nov-87 13:32:19 EST
From:      zwang@CS.UCL.AC.UK ("Zheng.Wang")
To:        comp.protocols.tcp-ip
Subject:   Network faults

I am doing some research on network faults now.
Help wanted from network experts:

1) According to your experience, which components
   are more likely to be the trouble-makers in the
   networks?

2) Where can I find reports or case studies about
   network failures in the past years?

Thanks in advance

Zheng

zwang@cs.ucl.ac.uk

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26-Nov-87 17:44:40 EST
From:      anido@otc.oz (Gary Anido)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   FDDI interfaces and bridges


We are interested in implementing an FDDI ring. The ring is intended 
primarily as a research vehicle to which we would be looking to connect 
Ethernet and Token-ring LANs. While I am aware that there is at least
one FDDI chipset available (from AMD according to the Sept 17 issue of
Electronic Design) I am unaware of any board-level implementations
and software. I would therefore be grateful if those with knowledge
of FDDI-Ethernet, FDDI-Token Ring etc, implementations and software
could share that information with me. This naturally includes anyone
who has actually designed an FDDI interface based on the AMD (or other?)
chipset.  Replies should be sent to me, and I will summarise and 
release to the net.

			        Gary  Anido 
			    Systems Development
   				|||| OTC ||

UUCP:	 {uunet,mcvax}!otc.oz!anido	    ACSnet:anido@otc.oz
Postal Address: Systems Development         Phone :(02) 2874849 
                OTC                         Intl  :+612 2874849 
                GPO Box 7000                Fax   :(02) 2874990 
                Sydney NSW
                AUSTRALIA 2001            

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Nov 87 18:32:19 GMT
From:      "Zheng.Wang" <zwang@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Cc:        zwang@Cs.Ucl.AC.UK
Subject:   Network faults
I am doing some research on network faults now.
Help wanted from network experts:

1) According to your experience, which components
   are more likely to be the trouble-makers in the
   networks?

2) Where can I find reports or case studies about
   network failures in the past years?

Thanks in advance

Zheng

zwang@cs.ucl.ac.uk
-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Nov-87 10:57:36 EST
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: Network Management



	Date: Wed, 25 Nov 87 18:09:37 EST
	From: gross@gateway.mitre.org (Phill Gross)
	Message-Id: <8711252309.AA05871@gateway.mitre.org>
	Subject: re: Network Management


	> I don't understand why it is useful to have something which is sort
	> of vaguely like what we think CMIP is going to look like when it is
	> done.  Either you are compatible with an ISO standard or you're not.
	> Being sort of close doesn't seem to buy all that much.  

	Ross,

	I have been informed in private that these days it is a wise
	business decision to at least give the appearance of conforming to
	OSI standards.  Utilizing TCP and IP is fine because it is already
	here, but for something that needs to implemented from scratch, I've 
	been told that many vendors feel contrained to an OSI solution.

	The argument about avoiding development costs by not implementing 
	twice may not be as important as soothing nervous customers about 
	multi-vendor OSI interoperability.  If vendors were only concerned 
	with not implementing twice, they might have taken a harder look at 
	the Simple Gateway Monitoring Protocol (SGMP) effort.  

As a customer of network products, I'm not interested in the "appearance" of
a product in anyway;  just what it does.  It seems that products developed
to "soothe" customers and as useful as those developed to actually solve my
problems.

I was kinda glad that the vendors I buy products from weren't listed as being
part of the group that made this decision.  If I can't buy it, I'll have to
build it myself.  The vendor that builds it for me gets my business.  The
appearence of ISO compatibility is not something that I'd go out and build.

Just wanted to give you another "customer's" perspective.

Louis A. Mamakos
University of Maryland
Computer Science Center

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Nov-87 11:29:07 EST
From:      ron@MANTA.NOSC.MIL (Ron Broersma)
To:        comp.protocols.tcp-ip
Subject:   Re:  pop

>	Are there any pop (post office protocol) implementations
>	for VAXs and SUNs?

We have a full implementation of pop2 service here running on both VAXen
and SUNs.  If there is interest, I'll stick it in a public FTP directory
so you can grab it.

--Ron
ron@nosc.mil

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27-Nov-87 19:03:47 EST
From:      lekash@ORVILLE.NAS.NASA.GOV (John Lekashman)
To:        comp.protocols.tcp-ip
Subject:   pop

Hi.
I'll express interest in a pop2 implementation.  We're
busy considering how best to send all mail here
to frob@nas.nasa.gov, and that might be a useful way.

					john

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Nov-87 00:28:48 EST
From:      mrose@GREMLIN.NRTC.NORTHROP.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: pop

You might also consider looking at the POP implementation (client and
server) in MH.  It was done at roughly the same time as the POP2 
specification, but for reasons not worth going into, never got issued as an
official rfc.  The Stanford mailsystem for the PC uses this POP to great
advantage.

/mtr

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Nov-87 11:42:59 EST
From:      zwang@CS.UCL.AC.UK ("Zheng.Wang")
To:        comp.protocols.tcp-ip
Subject:   tcp-ip archives

Help wanted:

Where can I find the tcp-ip archives for the recent years?


Zheng.

zwang@uk.ac.ucl.cs

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Nov-87 12:57:27 EST
From:      smiller@umn-cs.cs.umn.edu (Steven M. Miller)
To:        comp.protocols.tcp-ip
Subject:   Authentication Protocols


I heard brief mentions of existing authentication protocols a while
back on this list.  I tried to contact the authors of the messages
that mentioned the Visa and Kerberos protocols but didn't get any response.

If anyone can give me pointers to documentation on these protocols it would
be greatly appreciated.

(p.s    If you know of any other protocols please point me to them too)
(p.p.s. I already have the Sun paper from Summer '86 Usenix)

smiller@umn-cs.cs.umn.edu
steve@cs-gw.d.umn.edu


-- 



			-Steve Miller, U of MN

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Nov 87 16:42:59 GMT
From:      "Zheng.Wang" <zwang@Cs.Ucl.AC.UK>
To:        postmaster@sri-nic.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   tcp-ip archives
Help wanted:

Where can I find the tcp-ip archives for the recent years?


Zheng.

zwang@uk.ac.ucl.cs
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28-Nov-87 23:44:06 EST
From:      hrs@homxb.UUCP
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Standard for Printers

In article <1039@hp-sdd.HP.COM>, andrea@hp-sdd.HP.COM (Andrea K. Frankel) writes:
> In article <135@tsdiag.UUCP> tom@tsdiag.UUCP writes:
> >
> >THIS IS A FORWARDED MESSAGE Follows is the *REAL* header:
> >From: n2dsy@hou2d.UUCP (G.BEATTIE)
> >
> >I have been looking around for something similar to the
> >ANSI X3.64 Terminal Protocol Specification for printers
> >or printing terminals.   I guess that in some "ideal"
> >world we would have something analogous to the Virtual
> >Terminal Protocol for printers, but I am willing and
> >seeking suggestions regarding printer standards for
> >simple and medium-complexity printers.
> 
> ECMA has a task group working on printer formats; their current
> proposal is called a "Standard Page Description Language" which
> can be translated to actual PDL's such as Postscript or printer
> languages such as PCL.  Presumably a "standard PDL" could be 
> implemented directly in a printer in the future.
> 
> The ISO committee TC97/SC18 (and the corresponding ANSC X3V1)
> are also working in this area.  
> 
> You can contact ANSI in New York to get a contact for X3V1
> committee work; that should give you an in to the other groups
> as well.
> 
> Andrea Frankel, Hewlett-Packard (San Diego Division) (619) 592-4664
>                 "...like a song that's born to soar the sky"
> ______________________________________________________________________________
> UUCP     : ...hplabs!hp-sdd!andrea from 
> 	   {ihnp4|cbosgd|allegra|decvax|gatech|sun|tektronix}
>            or ...hp-sdd!andrea from {hp-pcd|hpfcla|hpda|noscvax|gould9|sdcsvax}
> Internet : andrea%hp-sdd@ {nosc.mil | sdcsvax.ucsd.edu | hplabs.HP.com}
> CSNET    : andrea%hp-sdd@hplabs.csnet
> USnail   : 16399 W. Bernardo Drive, San Diego CA 92127-1899 USA


ANSI X3V1, Text, Office, and Publishing Systems has jurisdiction in the
US over printer driver standard, and is the US counterpart of ISO JTC1/SC18.

Postscript, (Xerox) Interpress, and DDL are al being proposed
as sources for the Standard Page Description Language.  As a "de facto
standard" Postscript is likely to be influential, although it currently
is seen as having some drawbracks in the large size of its files.
The standard will have binary (ASN.1) and SGML versions as well as cleartext
versions.

X3V1 will meet December 7-11 in OakRidge, TN.

Interested people are invited to participate.  If you want more information,
call or send email.

Herman Silbiger ...!ihnp4!homxb!hrs  201 949 3193
Chair, X3V1.3

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Nov-87 14:26:56 EST
From:      estrin@OBERON.USC.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Authentication Protocols

Sorry for the delay in getting back to those who asked for
documentation on our Visa protocol. I was stalling to send you the
most up to date description and as usual things have taken longer; in
part because it is a jointly authored document and requires coordination..

If you want a copy of an old Visa document, let me know. Otherwise
I saved all the requests and should be sending something out shortly.

Deborah Estrin

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Nov-87 16:13:00 EST
From:      enger%gburg.DECnet@BLUTO.SCC.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   The Adopt-A-Mailbridge foster parent program.

Gentlepersons:
 
CONTEL  Federal  Systems  became  the  first  foster  parent  in  the Adopt-A-
Mailbridge campaign.   This  campaign  is  an  outgrowth  of the suggestion to
upgrade the EGP core gateways which was  made at the recent IETF meeting.  The
EGP upgrade appears to have  been  very successful, reducing delays and packet
loss by up to two orders of magnitude while the network load increased. 
 
The Adopt-A-Mailbridge program, as I've  coined  it, encourages members of the
Internet community to improve service  for  all  by making a temporary loan of
equipment to upgrade a mailbridge  gateway.   Contel loaned an 11/73 processor
to DCEC-MILNET-GW.ARPA. 
 
This note lists the  results  of  some  informal  ping testing of the upgraded
DCEC-MILNET-GW.ARPA (10.7.0.20), in comparison to  concurrent tests of some of
the other mailbridge gateways,  and  against  a  few  tests of 10.7.0.20 taken
before the upgrade.  I do not have  access to a net-26 host with which I could
have performed throughput testing, so ping echo results are all I can provide. 
 
When comparing the performance of  the  upgraded DCEC to the other mailbridges
keep in mind that more PSN  hops  must  be  traversed  on net-10 to get to the
other mailbridges.  The host that I performed the testing from is connected to
PSN DCEC20, as is DCEC-Milnet-GW.arpa. 
 
The "testing" consisted of pinging the net-10 interface address of the various
mailbridge gateways and recording the  average  echo delay.  Most measurements
are based on receiving  approximately  100  replies.    One measurement of the
original DCEC  mailbridge  received  only  47  replies.    For  the purpose of
removing the net-10 delay involved in opening a connection to the distant end,
each test was preceded by  a  separate  ping session of sufficient duration to
see a few responses come back. 
 
Comparing the longest average delay  measured  from DCEC mailbridge (347ms) to
the shortest average from  any  of  the  others  (682ms), the improvement is a
factor of 2. 
 
Comparing the average of  all  the  upgraded  DCEC  measurements (279), to the
average  of  the  average  measurements   from  all  the  others  (1034),  the
improvement is a factor of 3.7. 
 
It would be useful  if  the  effects  of  the  extra  net-10 PSN hops could be
removed.  Perhaps a conservative way to take a swag at this is to subtract off
the afternoon net-10 average end to  end  delay (422ms) from the average delay
figure for the remote mailbridges.   This yields a corrected (??) delay figure
for the remote mailbridges of 612ms, and an improvement factor of 2.2. 
 
My only data for the old DCEC was taken on the weekday test of the new PSN end
to end software.  Four measurements were taken.  The longest of these received
129 packets, and lost 31%.    It  had  an  average  delay of 14479ms. I am not
considering this measurement.    The  average  of  the remaining three average
delay measurements is 803ms.  Based on  this, the upgraded DCEC running on the
old end to end is 2.88 times quicker. 
 
While the improvement is not as dramatic  as that seen on the Arpanet EGP core
gateways, it is still significant.    I  think  we should try to locate Foster
Parents for the rest of the mailbridges.  Steve Atlas also reminds me that the
EGP core gateways on the Milnet  are  still "un-sponsored".  Finally, I wonder
if the EGP core gateways would  benefit  from  an even faster processor?  Does
anyone know if we can drop  in  an  11/83  cpu  as easily as we dropped in the
11/73s?  Has anyone got one to loan out? 
 
 
I hope all of you had a nice Thanksgiving Day,
 
Bob Enger
Contel Federal Systems
enger@bluto.scc.com
 
 

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 87 16:13:00 EST
From:      "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com>
To:        "abauman" <abauman@DDN1.ARPA>
Cc:        gross@gateway.mitre.org,petry@trantor.umd.edu, satlas@bbn.com,tcp-ip@sri-nic.arpa, enger
Subject:   The Adopt-A-Mailbridge foster parent program.
Gentlepersons:

CONTEL  Federal  Systems  became  the  first  foster  parent  in  the Adopt-A-
Mailbridge campaign.   This  campaign  is  an  outgrowth  of the suggestion to
upgrade the EGP core gateways which was  made at the recent IETF meeting.  The
EGP upgrade appears to have  been  very successful, reducing delays and packet
loss by up to two orders of magnitude while the network load increased. 
 
The Adopt-A-Mailbridge program, as I've  coined  it, encourages members of the
Internet community to improve service  for  all  by making a temporary loan of
equipment to upgrade a mailbridge  gateway.   Contel loaned an 11/73 processor
to DCEC-MILNET-GW.ARPA. 
 
This note lists the  results  of  some  informal  ping testing of the upgraded
DCEC-MILNET-GW.ARPA (10.7.0.20), in comparison to  concurrent tests of some of
the other mailbridge gateways,  and  against  a  few  tests of 10.7.0.20 taken
before the upgrade.  I do not have  access to a net-26 host with which I could
have performed throughput testing, so ping echo results are all I can provide. 

When comparing the performance of  the  upgraded DCEC to the other mailbridges
keep in mind that more PSN  hops  must  be  traversed  on net-10 to get to the
other mailbridges.  The host that I performed the testing from is connected to
PSN DCEC20, as is DCEC-Milnet-GW.arpa. 
 
The "testing" consisted of pinging the net-10 interface address of the various
mailbridge gateways and recording the  average  echo delay.  Most measurements
are based on receiving  approximately  100  replies.    One measurement of the
original DCEC  mailbridge  received  only  47  replies.    For  the purpose of
removing the net-10 delay involved in opening a connection to the distant end,
each test was preceded by  a  separate  ping session of sufficient duration to
see a few responses come back. 
 
Comparing the longest average delay  measured  from DCEC mailbridge (347ms) to
the shortest average from  any  of  the  others  (682ms), the improvement is a
factor of 2. 

Comparing the average of  all  the  upgraded  DCEC  measurements (279), to the
average  of  the  average  measurements   from  all  the  others  (1034),  the
improvement is a factor of 3.7. 
 
It would be useful  if  the  effects  of  the  extra  net-10 PSN hops could be
removed.  Perhaps a conservative way to take a swag at this is to subtract off
the afternoon net-10 average end to  end  delay (422ms) from the average delay
figure for the remote mailbridges.   This yields a corrected (??) delay figure
for the remote mailbridges of 612ms, and an improvement factor of 2.2. 
 
My only data for the old DCEC was taken on the weekday test of the new PSN end
to end software.  Four measurements were taken.  The longest of these received
129 packets, and lost 31%.    It  had  an  average  delay of 14479ms. I am not
considering this measurement.    The  average  of  the remaining three average
delay measurements is 803ms.  Based on  this, the upgraded DCEC running on the
old end to end is 2.88 times quicker. 

While the improvement is not as dramatic  as that seen on the Arpanet EGP core
gateways, it is still significant.    I  think  we should try to locate Foster
Parents for the rest of the mailbridges.  Steve Atlas also reminds me that the
EGP core gateways on the Milnet  are  still "un-sponsored".  Finally, I wonder
if the EGP core gateways would  benefit  from  an even faster processor?  Does
anyone know if we can drop  in  an  11/83  cpu  as easily as we dropped in the
11/73s?  Has anyone got one to loan out? 
 
 
I hope all of you had a nice Thanksgiving Day,
 
Bob Enger
Contel Federal Systems
enger@bluto.scc.com
 


-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Nov-87 20:17:58 EST
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Using kboxes as an etherbridge


	We're in the process of planning an IP link to a campus-wide
ethernet.  Our first step will be to get a LADC line run from our building
to the other side of the street; initially we will run 9600 bps slip, with
plans to upgrade to an 56 kbps Ungermann-Bass etherbridge, or something
similar when we can scrape up the funds (about $15k for the two ends, I'm
told).  I had an idea which might save us a lot of money, with greater
bandwidth to boot.

	I figure it's about 2000 feet from here to there, as the crow
flies.  Since phone lines aren't as direct as crows, I really don't know
how long it will be, but I hope under 4000 feet.  You can run AppleTalk
(using Farallon PhoneNet hardware) over that much regular twisted pair
phone wire, or so they claim.  It seems to me, a cheap way to get an
etherbridge going would be to get two Kinetics KFPS boxes (with appropriate
software downloaded), hook the AppleTalk sides up to the ends of the LADC
circuit, and plug into the local ethernets on each end; a 230 kbps
etherbridge for under $5000 total hardware cost (a $2000 kbox, $300 xciver,
and $50 PhoneNet connector at each end, not counting the wire).  You even
have the added advantage that the AppleTalk only uses one pair of the
4-wire LADC, leaving the other pair for whatever you want to do with it.

	Any chance this will work?
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Nov-87 21:31:49 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  The Adopt-A-Mailbridge foster parent program.

Bob,

I love your foster-gateway program. Turns out 11/83s would require special
memory boards and backplanes, so would probably not make good orphans.

Dave

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29-Nov-87 22:13:01 EST
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Fragments and Interface Speeds


    >It's hard to believe that in this age of utterly cheap dense RAM,
    >otherwise sane people are proposing inserting artificial delays between
    >Ethernet packets because a lowball vendor wouldn't put, say, TWO
    >buffers on their card!
    >
    >[I admit I'm prejudiced, since I worked on Suns, which currently seem
    >to have the highest Ethernet thruput, but they were built out of
    >standard Ethernet chips and DRAMs available to everyone.  You too can
    >handle infinite back to back packets, if you just design with that in
    >mind as Sun did.]
    >

    	But whhhat about all those old, old Suns, the ones without back to
    	back capacity.  What about the tens of thousands of NI5010's or
    	3C501's.  People bought them, have them, are working with them
    	daily even though no double buffering is available.  Its not just
    	a querstion of being a lowball vendor,  reality is the fact that
    	old outmode hardware is out there and used! ...

    						Larry Backman

One point that may not be well known is that it is not just the single-
buffered PC interfaces that drop packets.  I have observed a DEQNA dropping
packets that arrived too close together (or when it had a resource crunch,
or something), sent from a PC.  There is also considerable variation in
the performance of different device drivers for the same interface.  I've
observed a VMS TCP/IP sending packets (with DEC's driver) much closer together
than Ultrix manages to.

Another point is that even the newest PC interface cards apparently can't
always handle back-to-back packets (I haven't yet met the LAN controller
chip that is as good as its salesmen imply).  Presumably other controllers
based on similar chips will have some susceptibility to overrun, also.

So, don't just dismiss the problem: The closer two IP fragments are, the
more likely it is that any arbitrary receiver will drop the second, requiring
a high-level retransmit.  Fragments are expensive to deal with in most
environments, and almost everyone does their best to avoid them entirely.
The exceptions I know of (NFS, routing protocols on big networks) that
send fragments deliberately are very much special cases.  I wasn't asking
that the gateway people go to enormous lengths to insert delays, just to
do so when convenient, in order to make the best of an already bad situation.

jbvb

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Nov-87 00:40:03 EST
From:      tyers@trlluna.trl.oz (P Tyers)
To:        misc.wanted,comp.protocols.tcp-ip
Subject:   Connexions - Magazine (defunct ??)

Can anyone assist me?

Around May of this year I picked up a reference to a new journal from
a net group (since forgotten hence the shotgun approach)
		Connexions - the Interoperability Report
		Editor - Ole J Jacobson
		Publisher	Advanced Computing Environments
				21370 Vai Avenue
				Cupertino

Our library has attempted to order it but all Australian agents deny its
existance and searches on Lockheed Dialog et al also don't find it.

Does it still exist? Did it ever get off the ground?
Can anyone give me a fuller citation. Ideally a fax/telex number and/or
the name of an Australian agent who can be persuaded of its existance.
Thanx in advance
-- 
P Tyers,	           JANET tyers%trlluna.oz@uk.ac.ucl.cs
ACSnet 	tyers@trlluna.oz   UUCP {uunet,hplabs,ukc}!munnari!trlluna.oz!tyers
CSnet	tyers@trlluna.oz   ARPAnet tyers%trlluna.oz@uunet.uu.net
MAIL: Telecom Australia (Research), P.O. Box 249, Clayton, VICTORIA 3168,AUST
D
D
Dp58

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Nov-87 11:40:18 EST
From:      DSTEVENS@VAXC.STEVENS-TECH.EDU (David L. Stevens)
To:        comp.protocols.tcp-ip
Subject:   Question on mail headers


 I thought that RFC822 didn't allow multiple TO:, SUBJECT:, DATE: lines in the
 header section of a mail message.   For the last few weeks we've been getting
 messages that have this,  anyone know why???

 dave stevens
 Senior Systems Programmer
 Stevens Institute of Technology

 Internet:	DSTEVENS@VAXC.STEVENS-TECH.EDU
 Bitnet:	DSTEVENS@SITVXA

 "I was thinking of Socrates when he said "I drank what ?""
					-Real Genius
------------

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Nov-87 12:12:52 EST
From:      jlunny@NSWC-G.ARPA
To:        comp.protocols.tcp-ip
Subject:   Authentication Protocols

i am interested in an old document on your VISA protocol.  All i need
for now is general info on VISA.  thanks

john lunny
NSWC

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Nov-87 12:41:19 EST
From:      bill@trotter.usma.edu (Bill Gunshannon)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP-IP on top of NETBIOS


A short time ago someone posted a message saying they had made Phil Karn's
TCP-IP run on top of NETBIOS.  I would like to get in touch with the person
who accomplished this as I have an interface using NETBIOS that I would
like to try and run TCP-IP on.

Any assistance would be greatly appreciated.

bill gunshannon


UUCP: {philabs}\		 	US SNAIL: Martin Marietta Data Systems 
      {phri   } >!trotter.usma.edu!bill           USMA, Bldg 600, Room 26 
      {sunybcs}/			          West Point, NY  10996	     
RADIO:         KB3YV		        PHONE: WORK    (914)446-7747
AX.25:         KB3YV @ K3RLI	        PHONE: HOME    (914)565-5256

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30-Nov-87 13:18:11 EST
From:      MRC@PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on mail headers

David Stevens -

     I reviewed RFC 822 briefly.  The BNF suggests that a multiple "Date:" line
shouldn't happen, but I could find no restriction on multiple "To:" or "Subject:"
lines.  If there is something in RFC 822 that you believe imposes such a
restriction, please cite the reference by paragraph and page number.

     I would think that a reasonable RFC 822 implementation would simply ignore
extraneous Date: and Subject: lines.  Multiple To: lines are easy; just append
the new data to the old data.

-- Mark --
-------

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Dec-87 02:14:55 EST
From:      MRC@PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   NFS over ARPANET

I might note that a certain PDP-10 operating system at MIT had a working NFS
over the ARPANET over 10 (15?) years ago.  It was called MLDEV, and supported
all the same operations as the local disk including disk-to-memory mapping.

Someday, perhaps in the 90's, Unix will evolve to the point that we can once
again enjoy the level of functionality we had in the 70's.  :-(
-------

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Dec-87 04:37:30 EST
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Fwd: NFS over arpanet?

It has been joked about for a while now, but it had to happen sooner or 
later....

Drew

X-Digest-From: William LeFebvre <Sun-Spots-Request@rice.edu>
X-Digest-Subject:  Sun-Spots Digest, v5n64
X-Digest-To: Sun-Spots@rice.edu
Message-Id:  <1987.11.25.15.11.24.758.14837@rice.edu>
Date:    Fri, 13 Nov 87 15:28:12 PST
From:    ho@tis-w.arpa (Hilarie K. Orman)
Subject: NFS over arpanet?

I would like to hear from anyone who has tried to use NFS between Arpanet
sites.  I am advised that it would be painfully slow and awkward, but I
would like to try.  However, I cannot get "mount" to complete between the
two test sites, so I cannot even begin to experience the pain.  I have
been in daily communication with Sun Support for two weeks about the
following experiment between two arpanet machines:

Both sites have NFS mounts running on their LAN's, so we know that the
basic capability is there.  The sites can rlogin to each, run FTP and
Telnet, so we know the arpanet connectivity and addressing are OK.
However, the command

	/etc/mount machine1:/glkspl /mnt

results in an RPC timeout message after 20 seconds.  Using the options
"timeo=20000,rsize=512,wsize=512" doesn't alter anything at all, despite
what you might think from reading the documentation.  I think these
options are only in effect after mount completes successfully, and the 20
second timeout is an unalterable parameter.

I cannot see any evidence that machine1 ever sees the mount request.  Does
anyone know how to check this?  Is rpcinfo definitive?  Any help would be
appreciated.  Also any interest other sites might have in this capability
should be expressed, since Sun's official opinion is "not supported".

END OF DOCUMENT