The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 83 14:33:46 EDT
From:      Farber <farber%udel-eecis1.udeecis@udel-ee>
To:        pam%purdue.arpa@udel-ee
Cc:        tcp-ip%sri-nic.arpa@udel-ee
Subject:   Re:  TCP/IP for VMS
I just got an announcement from Compion urbana Ill 217 384 8500
of a tcp-ip for the vms vax

Dave
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      16 August 1983 17:48 EDT
From:      Turkewitz @ DDN1
To:        TCP-IP @ SRI-NIC
Cc:        Turkewitz @ DDN1
Subject:   Thank you, TCP
Date: August 16, 1983
Text: 
Dear TCP designers and implementors,
     This mailing list must undoubtably be a forum for many TCP
discussions, complaints, and bugs.  You have probably all heard
more than your share about how much slower TCP is than NCP.  This,
however, is not one of those messages.  This is a simple thank-you.
     I have been working on a TCP/IP connection from Germany over
a satellite link back to the United States.  Unfortunately, the
line has been pretty flakey, and we have had frequent outages.
To my amazement, however, I have found out that when we reestablish
connection, I can pick up right where I left off!  We had one
outage that was about 25 minutes long.  I was in the middle of
composing an electronic mail message at the time the line went down.
When it came back up, I was still in the middle of composing the
message (not even an interrupt!), and the characters that I had
typed between the time that the line went down and the time that I
noticed it was down suddenly echoed to me when the line came back up!
     An associate tells me that this is due to the reliability of
TCP.
     Thank you TCP & all involved.
          --Ken Turkewitz

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #13
TCP/IP Digest           Thursday, 25 Aug 1983      Volume 2 : Issue 13

Today's Topics:
      Administrivia && Connecting IBM Mainframes to Foreign Devices
      TCP/IP from IBM && Looking for TCP/IP to SNA Protocol Gateway
              BBN TCP has Retransmit-overtaking-Persist Bug
                  Comments on the Parsing of HOSTS.TXT
                2 more implementations of TCP/IP for VMS
                Seeking Portable TCP/IP in Pascal or ADA
                     Information on Omninet hardware
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From:	 Mike Muuss <Mike@BRL>
Subject: Administrivia

This is the first digest in quite some time, caused by overwork, and
slow rate of submissions.  There are quite a few interesting topics
still left to be discussed, though!

One important item which I would like to bring to your attention:

For some time now, the NIC has published a much smaller mailing list, on
a direct re-transmission basis, which carries the (perhaps unfortunate)
name <TCP-IP @ SRI-NIC>.  A great deal of mail directed to that list
would be profitably displayed in this Digest as well.

The most interesting transmissions to the NIC list I have requested
permission from the authors to reprint, and (so far) have always been
granted permission.  However, this is a tremendous administrative burden
on me, and it is no longer my desire to continue with this strategy.
Furthermore, a great many people have urged me to automaticly publish
all traffic on that list in this digest, as they wish to "keep informed",
a request which seems quite justified.

Based on a fair quantity of writing with various people, and a good deal
of contemplation, I have decided to begin printing excerpts from the
NIC TCP-IP (direct) mailing list in the TCP-IP Digest, so that readers
of the Digest can stay informed.  Please be aware of the fact that messages
which get sent to the NIC list *might* be published in the TCP-IP Digest.

I will, of course, attempt to be discrete, and will not reprint messages
which "obviously" should not receive wider distribution than they already
got.  Good examples are crassly commercial comments, and random flaming.
But, I feel compelled to broadcast solid, technical discussion out to the
widest possible audience, to attempt to increase the understanding and
acceptance of TCP/IP, and to sensitize computer people to the demands
and benefits of inter-operable networks.  The subscribers to the NIC list
have been notified of this new policy.

Please direct your comments on this topic to TCP-IP-REQUEST @ BRL,
and I will summarize the response.

		Best,
		 -Mike Muuss, Moderator

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

Date: Thursday, 30 Jun 1983 09:29-PDT
To: tcp-ip@brl, local-nets@mc
Subject: Connecting IBM mainframes to foreign devices
From: imagen!cpr%Shasta@su-score

There are currently two basic routes to go to connect your IBM mainframe
to special devices: the 4300-series DACU, and the Auscom general
channel-to-Qbus.  ACC also makes an IBM channel attachment for Ethernet
which emulates a 327x cluster controller, with individual Ethernet
stations corresponding to 3278 tubes or 328x printers.  I haven't been
able to find out more from ACC, and it sounds like a special-purpose
solution, so I won't go into it.

For the 4300 series mainframes, IBM is trying very hard to support OEMs
and customers with special device-connection requirements, using what
they call a DACU (Device Attachment Control Unit), which is basically a
fast buffer between a block multiplexor channel on a 4300 and a true
Unibus, with an IBM PC (personal computer) as the controlling device.
The cost (no OEM pricing yet) is $13,500, without the PC (which only
requires a minimal configuration, of a cost around $2500).  The
contact, Bill Denson (Information Systems Group, Atlanta,
404-238-4710), is extremely helpful and informative.  Seems that IBM
has finally realized there's money in attaching foreign devices to
their mainframes.

Auscom is a company in Austin, Texas, whose sole business for years
has been making IBM channel attachment devices.  The kernel of their
interface is a 3-quad-board Qbus set, which they sell alone for about
$8k, or packaged in an LSI-11 system with software to drive a whole
slew of devices, for about $20k.  (Don't believe the prices; talk to
them.)  The contact is Linda Lewis, 512-836-8080.  I'm quite impressed
with them; they appear to be the only company making this their entire
business, and their customer list is top-notch.  For example, they have
a standard channel-to-Ethernet (with simple DoD IP-based protocol),
emulating an IBM tape drive or line printer, etc.  (They use Interlan
Ethernet Qbus interfaces.)

--Chris Ryland, IMAGEN Corporation

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

Date: Mon 8 Aug 83 17:57:04-PDT
From: Suzanne Johnson <JOHNSON@SUMEX-AIM.ARPA>
Subject: IBM TCP/IP
To: tcp-ip@BRL.ARPA

My understanding is that although trial versions of IBM TCP/IP are becoming
available, IBM has not worked out any method for making a product out of
this software.  That means that they are not planning a way for a site to
arrange for support service other than through (I believe) an expensive
contract situation with their Federal Systems Division.

It is therefore important that if you are interested in this software, that
you have your local IBM rep call the IBM Special Products Group in Chicago
and say that they have a customer site interested in a supported version
of the software.  If the SPG gets 10 or so of these calls, they begin to
believe that they need to establish a product related way to handle the
software.

If only tcp/ip were a bit better known outside of DoD related communities,
it might occur to some of the organizations which are implementing internal
LANs, and scratching their heads over what protocol to use, that tcp/ip is
a natural to consider in this respect.  Especially since many LAN's contain
many of the mainframe/os combinations currently supported by tcp/ip
implementations.

Suzanne Johnson

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

Date:  10 August 1983 09:30 edt
From:  Vinograd.Multics@mit-multics
Subject:  TCP/IP-SNA Gateway
To:  TCP-IP@brl

I am looking for any information on a TCP/IP to SNA gateway. What I have
in mind is the ability to telnet/FTP to any host on an SNA net, given a
physical connection to one host on the SNA net. The reverse access from
the SNA net is equally important.

SMTP support would be useful, but is not a requirement.

Any pointers or rumors of such a capability would be most helpful.

Thanks - Dave

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

Date:  6 Jul 1983 10:53:51 EDT (Wednesday)
From: Dennis Rockwell <drockwel@bbn-vax>
Subject: retransmit overtaking persist bug
To: tcp-ip@brl-vgr, tcp-ip@nic, bbn-tcp@bbn-vax

There is a bug in the BBN TCP timer code which causes connections
with large delays to hang.  The symptom is that the sender will
continually send single-octet packets which are one octet past
the receiver's advertised window.  The cause is that the persist
timer (used for probing closed windows) was fixed, which the
retransmit timer is adaptive (variable).  When the persist timer
goes off, it resets the retransmit timer.  Thus, when the retransmit
timer exceeds the persist timer, you hang.

The fix is to replace the token T_PERS in tcp_procs.c (about line 250)
with tp->t_xmtime*2.  This is the only instance of T_PERS except for
its definition (which you can delete if you wish).  This guarantees
that the persist timer is always greater than the retransmit timer.

If you know of any system running the BBN software that doesn't receive
one of these mailing lists, please inform either them or me.

Sorry to send this out to such a wide audience, but this bug will
bite more systems as the Internet grows.

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

Date:     12 Aug 83 15:43:01 BST (Fri)
From:     Steve Kille <steve@ucl-cs>
To:       tcp-ip@brl.arpa
cc:       robert@ucl-cs
Subject:  Parsing of hosts.txt

We have found a problem which some sites are having with the UCL-CS
hosts.txt entry.  It appeared in the BBN UNIX software, but
this may well not be the only guilty system.


1. Some SMTP sites check the name of a caller against the callers address,
thus if you use a multi-homed host for mail under a single name
it is useful to put all the addresses in the NIC hosts table.

2. UCL has the facility to route mail over SATNET or IPSS so we use
two addresses for UCL-CS (128.16.9.3 the main address and 14.0.0.9)

3. BBN software for SMTP compiles a mail host table from the NIC
tables, it sorts any multiple addreses against the host name.  Thus

HOST : 128.16.9.3, 14.0.0.9 : UCL-CS,UCL :: LOGICAL-HOST : IP,TCP/SMTP :

becomes

UCL-CS,UCL : 14.0.0.9 : 128.16.9.3,

Thats OK, but the mailer only ever uses the first address.
The whole point of arranging the addresses in the original
table was to cause mailers to try the first address first.

4. Unless some activity at UCL has opened the IPSS tunnel all
attempts to reach 14.0.0.9 will fail; because of time zone
differences this is quite likely.

Thus it looks as though UCL is hardly ever up, and when I
complain to people about their mailer, they complain ours is
never up.

There seems to be an assumption, valid or otherwise, that all
Internet paths are either up or down, but never
UNI-DIRECTIONAL!

Robert Cole + Steve Kille


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

Date: Wednesday, 27 Jul 1983 09:35-PDT
To: tcp-ip@BRL-BMD.ARPA
Subject: Re:  TCP/IP for VMS
From: Chris Kent <decwrl!kent%Shasta@su-score>

Kashtan's stuff works and seems to be available from the Wollongong
Group. It's full 4.1c networking code.

The people at Rice that did the Phoenix Unix under VMS emulator are
also reported to have the Berkeley TCP/IP running under their system,
but I don't know details.

Cheers,
chris

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

Date:  6 Aug 1983 1121-PDT
From: LYONS@usc-isi
Subject: TCP-IP IN HOL
To:   TCP-IP@brl
cc:   LYONS@usc-isi, LYONS@dca-ems

I AM INTERESTED IN KNOWING OF HIGH ORDER LANGUAGE IMPLEMENTATIONS
OF TCP AND IP WHICH ARE PORTABLE, ESPECIALLY IMPLEMENTATIONS
IN PASCAL OR ADA.  DO YOU KNOW OF ANY?

REGARDS,    BOB LYONS/DCEC

[ I believe that the CSNET TCP/IP implementation for the IBM was written
  mostly in PASCAL.  There is also a commercial version in PASCAL, for
  Cybers and other mainframes, mentioned in earlier Digests.  -Mike ]

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

[ This message is reprinted with permission. -Mike ]

Date: Wed 27 Jul 83 10:17:39-PDT
From: Chris Ryland <g.Ryland@SU-SCORE.ARPA>
Subject: Re: request for Omninet vs VAXes info
To: local-nets@MIT-MC.ARPA

I've been looking into Omninet lately for other reasons, and, as far as
I can tell, there isn't much activity with interconnection to VAXes, or,
for that matter, with other networks.  Omninet DOES have an XNS packet
encapsulation protocol, which they and Xerox agreed to (it's published
in the Omninet protocol handbook).  There is, I believe, a Unibus
Omninet board just announced or to be announced, though I can't find the
information right now.  With that, I suppose you could write a VMS
driver for Omninet.

For people's information, Omninet seems to be the dominant "cheapo" LAN
for the micro world right now (they claim over 20,000 networks, of average
size 4 (stations)).  It's a 1mb twisted-pair RS422 network, using two
proprietary chips (they sell) and a Motorola 6801 (with their custom code
burned in) to accomplish the link-level, and little of the transport level.
Thus, for the IBM PC, their board is very simple, and low-cost (about $300,
I believe), as well as reasonably efficient, as they DMA from the network
to waiting buffers in the CPU.

It's really a wonderful network from the point of view of cabling: the
"transceivers" cost $10, and can be wired by anyone with a screwdriver.

1mb isn't bad for a small cluster of workstations.  There are some limitations
on the number and type of connections a given workstation can have open: only
one "remote disk" connection at a time is allowed, and only three more other
connections of non-remote-disk type are allowed simultaneously.

/Chris Ryland

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

END OF TCP-IP DIGEST
********************
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #14
TCP/IP Digest             Friday, 26 Aug 1983      Volume 2 : Issue 14

Today's Topics:
                    Thank you to TCP -- A testimonial
            Questions about TCP/IP for Various UNIX Versions
                  4.2 BSD IEN142 Time Server Available
               4.2 BSD UNIX Protocol Violation Discussion
               Further Details on the MILNET/ARPANET Split
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: 16 August 1983 17:48 EDT
From: Turkewitz@ddn1
Subject: Thank you, TCP
To: TCP-IP@brl

Dear TCP designers and implementors,

     This mailing list must undoubtably be a forum for many TCP
discussions, complaints, and bugs.  You have probably all heard
more than your share about how much slower TCP is than NCP.  This,
however, is not one of those messages.  This is a simple thank-you.

     I have been working on a TCP/IP connection from Germany over
a satellite link back to the United States.  Unfortunately, the
line has been pretty flakey, and we have had frequent outages.
To my amazement, however, I have found out that when we reestablish
connection, I can pick up right where I left off!  We had one
outage that was about 25 minutes long.  I was in the middle of
composing an electronic mail message at the time the line went down.
When it came back up, I was still in the middle of composing the
message (not even an interrupt!), and the characters that I had
typed between the time that the line went down and the time that I
noticed it was down suddenly echoed to me when the line came back up!

     An associate tells me that this is due to the reliability of TCP.

     Thank you TCP & all involved.
          --Ken Turkewitz

[ Some hosts must have *enormous* values for the retransmit timeouts!  -Mike ]

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

Date: 21 Jul 1983 0906-PDT
From: MUEHLEN@sri-csl
Subject: UNIX networking
To: tcp-ip@brl
cc: muehlen@sri-csl

We want to start with networking different UNIX Systems (berkeley, bell,
xenix, munix) in a local area network (ethernet). Who has done this work
and which hardware and software can be recommended? Is there any survey
available?  Is anybody using UNET or 3COM or Net/One ?

Many thanks -Heinz

[ 4.2 BSD comes with a TCP/IP that is quite good.  Presently, Bell System V
  does *not* support TCP/IP, but Bell Labs is working on it, under contract
  to U.S. Army DARCOM.  UNET software is also being used by some people, and
  their latest version is reported to be useable.  -Mike ]

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

Date: Friday, 15 Jul 1983 14:24-PDT
To: tcp-ip@Brl
Subject: IEN142 time server/user for Berkeley VAX Unix
From: Chris Kent <decwrl!kent%Shasta@sumex-aim>

Just wanted to let the community know that I've written a network time
user/server pair for 4.1cBSD Unix. I have submitted it to Berkeley for
inclusion in 4.2, but who knows when they'll finally ship? So if people
need it, I'll be happy to send it out.

You'll have better luck mailing to me as <cak@purdue>.

Cheers,
chris

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

[ The following 2 messages concern a discussion of an extention to IP which
  is used by 4.2 BSD UNIX on Ethernets.  Bill Shannon's comments on this
  appeared in the UNIX-WIZARDS mailing list, and I enclose them here to
  show some of the felings in the UNIX community.  -Mike ]

Date:	Saturday, 20 Aug 1983 16:17-PDT
To:	tcp-ip@brl
Subject: 4.2 Berkeley Unix protocol violation
From:	imagen!cpr%Shasta@su-score

I've brought this up elsewhere (Unix-Wizards), but I thought I might
mention it to the TCP/IP world directly.  I'm concerned about the Berkeley
4.2 Unix TCP/IP Ethernet implementation, because this version of Unix
uses a private encapsulation protocol for IP packets on 10Mbit Ether, in
violation of the as-yet-unofficial encapsulation protocol.

In detail, the problem is that this TCP implementation uses a non-standard
(i.e., an extension of RFC 820) type of IP packet encapsulation in certain
circumstances, in an attempt at efficiency improvement (due to Unix internal
structures).  This happens with no warning, and with no negotation
whatsoever with the foreign host.  To the foreign host, it simply appears
that the connection is hung at the point the private encapsulation is first
used.

This ``feature'' can be turned off, if you have sources, or are willing to
patch the kernel binary image, but this seems like a big mistake on
Berkeley's part.  Those people trying to supply a product speaking TCP/IP on
Ethernet to the 4.2 Unix world are thus forced to either support this
extension, or else force the site to turn it off on all their 4.2 machines.

Is there an ``official position'' on this type of encapsulation ``violation''
(admittedly by extension)?  (Postel?  Clark?)

/Chris Ryland, IMAGEN

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

Date: 9 Aug 83 12:54:15-PDT (Tue)
To: Unix-Wizards @ Brl-Vgr
From: sun!shannon @ Ucb-Vax
Subject: Re: 4.2 TCP/IP/Ethernet trailers

Philisophically, I don't believe there is anything wrong with the
4.2 TCP/IP Ethernet code, it simply imposes another software layer
(the local net encapsulation) between IP and the Ethernet.
Practically, I think it is rather unfortunate since it destroys
compatibility with the "obvious" implementations of IP on Ethernet.
Having some way of negotiating for the use of trailers sounds nice
but it also sounds like another software layer which won't be
present in the "obvious" implementations.  The same sort of problem
exists with ARP.  Perhaps what is needed is a "standard" for how
to implement IP on Ethernet.

In the Sun 4.2 system we've made it easy to turn off trailers in the
driver, however ARP is mandatory.  We may provide a way to "wire down"
ARP translations (however the ARP translation table is by nature a
cache and therefore small) and I guess it would also be possible
to enable trailers based on the destination address.  As we start
talking to other TCP/IP/Ethernet implementations I suspect we will
have to address these problems more directly.

					Bill Shannon
					sun!shannon
					Sun Microsystems, Inc.

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

Date: 14 Jul 1983 1742-PDT
From: NIC@sri-nic
Subject: DDN Newsletter No. 28
To: DDN-NEWS-LIST1: ;

                FURTHER DETAILS ON THE MILNET/ARPANET SPLIT

Testing the Logical Split

The logical  split  of  the existing  ARPANET  into  the  Experimental
ARPANET and the MILNET  is a major  change which requires  substantual
testing to insure it will be accomplished as an orderly process.

ALL HOSTS AND USERS will be impacted. The ARPANET will change from one
network into two, and communications with hosts on the other net  will
require a knowledge of internet procedures.  MILNET  hosts will use  a
new network number (Network  26).  (Details of procuring  updated host
tables from the Network Information Center will be covered in a forth-
coming newsletter.)

The MILNET and the ARPANET will remain connected via five mail bridges
(internet gateways augmented  with a load-splitting  mechanism and  an
access control filter). The load-splitting mechanism works as follows.
Each bridge will contain  a table assigning  the "default" bridge  for
each host to use in sending traffic  to the other network.  If a  host
sends a  message  via the  wrong  bridge  and its  default  bridge  is
operational, the host will receive an ICMP redirect message telling it
which alternate gateway (i.e., default bridge) to use.  This mechanism
allows the five gateways to  balance the internet traffic.  After  the
initial default  assignment, if  one of  the bridges  is found  to  be
carrying  a  disproportionate  share  of  the  load,  then  the   host
assignment table will  be modified.  No changes to  host software  are
required.  As  long  as a  host  supports  ICMP,  the  host-to-gateway
protocol, it can  make full  use of  the bridges  without knowing  its
default bridge assignment in advance.

A schedule has been developed for  testing prior to the actual  split.
The goals of this testing are to:

     o Verify the mail bridge load-splitting mechanism and
       access control filter.

     o Test host TCP/IP and ICMP implementations.

     o Test the entire system networkwide.

Initial testing will use the testbed environment already available  at
BBN.  BBN has a local  ARPANET-clone network, the BBNNET (Network  8),
which is connected to the ARPANET via a gateway.  During daytime hours
the BBNNET passes about 50% as much traffic as does the ARPANET,  with
the existing gateway passing about 1,000,000 packets during an average
day, with about 80,000 packets per hour passing through it during peak
hours.  This represents  a significantly heavier  load than will  pass
through any  of  the five  mail  bridges, therefore  the  BBNNET  will
provide a realistic test environment.

The testing schedule is:

15 June:  Two additional gateways between the ARPANET and the BBNNET
          are installed.

30 June:  The gateway load-splitting mechanism is operational.

15 June to 15 August:  Gateway load-splitting and routing between
          the ARPANET and the BBNNET are verified.

To aid users in verifying  their capabilities to communicate with  the
MILNET, the  first MILNET  host to  receive net  number 26  will be  a
public news host  implemented  on a C/70,  which will allow  anonymous
logins and  will  contain  information  of  general  interest  to  the
ARPANET/MILNET community.

In addition, to assist TAC users, a TACNEWS service will be  provided.
By typing "@n" to the TAC, a TAC user will automatically be  connected
to the public news host wherever  it may exist without having to  know
its actual internet address.

Following are some of the major milestones of the Split.

1 July - 1 September:  The mail bridges between ARPANET and MILNET
          are installed.

15 July:  The C70 public news host is installed as the first host in
          the  MILNET COI.  Also, a  second MILNET interface will be 
          added to SRI-NIC.  Host managers  and  technical personnel
          should now  try to connect to the  C/70 news host  via the
          mail bridges in order to test their  ICMP implementations.

28 July - 2 August:  Network technical liaison meetings in:
          Los Angeles and San Francisco, Cambridge and Washington DC

1 September - 1 October:  The NIC  maintains the old  (ARPANET-only)
          and  the new  (ARPANET/MILNET)  host tables  in  parallel.
          During  this period  MILNET hosts may  voluntarily  change
          to Network No. 26 provided their changeover is coordinated
          with the NIC to permit timely update of the official  host
          tables.  Two full day  tests will occur, during which  the
          network will enforce the split, and hosts must use the new
          host tables.

4 October:  The logical split occurs.  Network IMPs will enforce the
          proper COI for each host, and network addressing   will be
          updated to reflect the split.

1 Febuary 1984:  Access control filters  are implemented in the mail
          bridges.  Although  this capability has  existed  for some
          time, its implementation is deferred to reduce the problems
          associated with the logical split on 4 October.

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

END OF TCP-IP DIGEST
********************
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Aug 83 5:32:03 EDT
From:      Mike Muuss (TCP-IP Digest) <tcp-ip@brl-vgr>
To:        TCP-IP@sri-nic
Cc:        tcp-ip-request@brl-vgr
Subject:   NOTE: Automatic Feed to the Digest
Based on a fair quantity of writing with various people, and a good deal
of contemplation, I have decided to begin printing excerpts from the
NIC TCP-IP (direct) mailing list in the TCP-IP Digest, so that readers
of the Digest can stay informed.  Please be aware of the fact that messages
which get sent to the NIC list *might* be published in the TCP-IP Digest.

I will, of course, attempt to be discrete, and will not reprint messages
which "obviously" should not receive wider distribution than they already
got.  Good examples are crassly commercial comments, and random flaming.
But, I feel compelled to broadcast solid, technical discussion out to the
widest possible audience, to attempt to increase the understanding and
acceptance of TCP/IP, and to sensitize computer people to the demands
and benefits of inter-operable networks.  I trust that you will understand.

Please send comments on this decision to TCP-IP-REQUEST @ BRL (not NIC).
			Best,
			 -Mike Muuss
			  TCP/IP Digest Moderator
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Aug-83 05:53:36 EDT
From:      TCP-IP%brl@brl-bmd.UUCP (TCP-IP@brl)
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 2 #13


TCP/IP Digest           Thursday, 25 Aug 1983      Volume 2 : Issue 13

Today's Topics:
      Administrivia && Connecting IBM Mainframes to Foreign Devices
      TCP/IP from IBM && Looking for TCP/IP to SNA Protocol Gateway
              BBN TCP has Retransmit-overtaking-Persist Bug
                  Comments on the Parsing of HOSTS.TXT
                2 more implementations of TCP/IP for VMS
                Seeking Portable TCP/IP in Pascal or ADA
                     Information on Omninet hardware
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From:	 Mike Muuss <Mike@BRL>
Subject: Administrivia

This is the first digest in quite some time, caused by overwork, and
slow rate of submissions.  There are quite a few interesting topics
still left to be discussed, though!

One important item which I would like to bring to your attention:

For some time now, the NIC has published a much smaller mailing list, on
a direct re-transmission basis, which carries the (perhaps unfortunate)
name <TCP-IP @ SRI-NIC>.  A great deal of mail directed to that list
would be profitably displayed in this Digest as well.

The most interesting transmissions to the NIC list I have requested
permission from the authors to reprint, and (so far) have always been
granted permission.  However, this is a tremendous administrative burden
on me, and it is no longer my desire to continue with this strategy.
Furthermore, a great many people have urged me to automaticly publish
all traffic on that list in this digest, as they wish to "keep informed",
a request which seems quite justified.

Based on a fair quantity of writing with various people, and a good deal
of contemplation, I have decided to begin printing excerpts from the
NIC TCP-IP (direct) mailing list in the TCP-IP Digest, so that readers
of the Digest can stay informed.  Please be aware of the fact that messages
which get sent to the NIC list *might* be published in the TCP-IP Digest.

I will, of course, attempt to be discrete, and will not reprint messages
which "obviously" should not receive wider distribution than they already
got.  Good examples are crassly commercial comments, and random flaming.
But, I feel compelled to broadcast solid, technical discussion out to the
widest possible audience, to attempt to increase the understanding and
acceptance of TCP/IP, and to sensitize computer people to the demands
and benefits of inter-operable networks.  The subscribers to the NIC list
have been notified of this new policy.

Please direct your comments on this topic to TCP-IP-REQUEST @ BRL,
and I will summarize the response.

		Best,
		 -Mike Muuss, Moderator

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

Date: Thursday, 30 Jun 1983 09:29-PDT
To: tcp-ip@brl, local-nets@mc
Subject: Connecting IBM mainframes to foreign devices
From: imagen!cpr%Shasta@su-score

There are currently two basic routes to go to connect your IBM mainframe
to special devices: the 4300-series DACU, and the Auscom general
channel-to-Qbus.  ACC also makes an IBM channel attachment for Ethernet
which emulates a 327x cluster controller, with individual Ethernet
stations corresponding to 3278 tubes or 328x printers.  I haven't been
able to find out more from ACC, and it sounds like a special-purpose
solution, so I won't go into it.

For the 4300 series mainframes, IBM is trying very hard to support OEMs
and customers with special device-connection requirements, using what
they call a DACU (Device Attachment Control Unit), which is basically a
fast buffer between a block multiplexor channel on a 4300 and a true
Unibus, with an IBM PC (personal computer) as the controlling device.
The cost (no OEM pricing yet) is $13,500, without the PC (which only
requires a minimal configuration, of a cost around $2500).  The
contact, Bill Denson (Information Systems Group, Atlanta,
404-238-4710), is extremely helpful and informative.  Seems that IBM
has finally realized there's money in attaching foreign devices to
their mainframes.

Auscom is a company in Austin, Texas, whose sole business for years
has been making IBM channel attachment devices.  The kernel of their
interface is a 3-quad-board Qbus set, which they sell alone for about
$8k, or packaged in an LSI-11 system with software to drive a whole
slew of devices, for about $20k.  (Don't believe the prices; talk to
them.)  The contact is Linda Lewis, 512-836-8080.  I'm quite impressed
with them; they appear to be the only company making this their entire
business, and their customer list is top-notch.  For example, they have
a standard channel-to-Ethernet (with simple DoD IP-based protocol),
emulating an IBM tape drive or line printer, etc.  (They use Interlan
Ethernet Qbus interfaces.)

--Chris Ryland, IMAGEN Corporation

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

Date: Mon 8 Aug 83 17:57:04-PDT
From: Suzanne Johnson <JOHNSON@SUMEX-AIM.ARPA>
Subject: IBM TCP/IP
To: tcp-ip@BRL.ARPA

My understanding is that although trial versions of IBM TCP/IP are becoming
available, IBM has not worked out any method for making a product out of
this software.  That means that they are not planning a way for a site to
arrange for support service other than through (I believe) an expensive
contract situation with their Federal Systems Division.

It is therefore important that if you are interested in this software, that
you have your local IBM rep call the IBM Special Products Group in Chicago
and say that they have a customer site interested in a supported version
of the software.  If the SPG gets 10 or so of these calls, they begin to
believe that they need to establish a product related way to handle the
software.

If only tcp/ip were a bit better known outside of DoD related communities,
it might occur to some of the organizations which are implementing internal
LANs, and scratching their heads over what protocol to use, that tcp/ip is
a natural to consider in this respect.  Especially since many LAN's contain
many of the mainframe/os combinations currently supported by tcp/ip
implementations.

Suzanne Johnson

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

Date:  10 August 1983 09:30 edt
From:  Vinograd.Multics@mit-multics
Subject:  TCP/IP-SNA Gateway
To:  TCP-IP@brl

I am looking for any information on a TCP/IP to SNA gateway. What I have
in mind is the ability to telnet/FTP to any host on an SNA net, given a
physical connection to one host on the SNA net. The reverse access from
the SNA net is equally important.

SMTP support would be useful, but is not a requirement.

Any pointers or rumors of such a capability would be most helpful.

Thanks - Dave

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

Date:  6 Jul 1983 10:53:51 EDT (Wednesday)
From: Dennis Rockwell <drockwel@bbn-vax>
Subject: retransmit overtaking persist bug
To: tcp-ip@brl-vgr, tcp-ip@nic, bbn-tcp@bbn-vax

There is a bug in the BBN TCP timer code which causes connections
with large delays to hang.  The symptom is that the sender will
continually send single-octet packets which are one octet past
the receiver's advertised window.  The cause is that the persist
timer (used for probing closed windows) was fixed, which the
retransmit timer is adaptive (variable).  When the persist timer
goes off, it resets the retransmit timer.  Thus, when the retransmit
timer exceeds the persist timer, you hang.

The fix is to replace the token T_PERS in tcp_procs.c (about line 250)
with tp->t_xmtime*2.  This is the only instance of T_PERS except for
its definition (which you can delete if you wish).  This guarantees
that the persist timer is always greater than the retransmit timer.

If you know of any system running the BBN software that doesn't receive
one of these mailing lists, please inform either them or me.

Sorry to send this out to such a wide audience, but this bug will
bite more systems as the Internet grows.

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

Date:     12 Aug 83 15:43:01 BST (Fri)
From:     Steve Kille <steve@ucl-cs>
To:       tcp-ip@brl.arpa
cc:       robert@ucl-cs
Subject:  Parsing of hosts.txt

We have found a problem which some sites are having with the UCL-CS
hosts.txt entry.  It appeared in the BBN UNIX software, but
this may well not be the only guilty system.


1. Some SMTP sites check the name of a caller against the callers address,
thus if you use a multi-homed host for mail under a single name
it is useful to put all the addresses in the NIC hosts table.

2. UCL has the facility to route mail over SATNET or IPSS so we use
two addresses for UCL-CS (128.16.9.3 the main address and 14.0.0.9)

3. BBN software for SMTP compiles a mail host table from the NIC
tables, it sorts any multiple addreses against the host name.  Thus

HOST : 128.16.9.3, 14.0.0.9 : UCL-CS,UCL :: LOGICAL-HOST : IP,TCP/SMTP :

becomes

UCL-CS,UCL : 14.0.0.9 : 128.16.9.3,

Thats OK, but the mailer only ever uses the first address.
The whole point of arranging the addresses in the original
table was to cause mailers to try the first address first.

4. Unless some activity at UCL has opened the IPSS tunnel all
attempts to reach 14.0.0.9 will fail; because of time zone
differences this is quite likely.

Thus it looks as though UCL is hardly ever up, and when I
complain to people about their mailer, they complain ours is
never up.

There seems to be an assumption, valid or otherwise, that all
Internet paths are either up or down, but never
UNI-DIRECTIONAL!

Robert Cole + Steve Kille


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

Date: Wednesday, 27 Jul 1983 09:35-PDT
To: tcp-ip@BRL-BMD.ARPA
Subject: Re:  TCP/IP for VMS
From: Chris Kent <decwrl!kent%Shasta@su-score>

Kashtan's stuff works and seems to be available from the Wollongong
Group. It's full 4.1c networking code.

The people at Rice that did the Phoenix Unix under VMS emulator are
also reported to have the Berkeley TCP/IP running under their system,
but I don't know details.

Cheers,
chris

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

Date:  6 Aug 1983 1121-PDT
From: LYONS@usc-isi
Subject: TCP-IP IN HOL
To:   TCP-IP@brl
cc:   LYONS@usc-isi, LYONS@dca-ems

I AM INTERESTED IN KNOWING OF HIGH ORDER LANGUAGE IMPLEMENTATIONS
OF TCP AND IP WHICH ARE PORTABLE, ESPECIALLY IMPLEMENTATIONS
IN PASCAL OR ADA.  DO YOU KNOW OF ANY?

REGARDS,    BOB LYONS/DCEC

[ I believe that the CSNET TCP/IP implementation for the IBM was written
  mostly in PASCAL.  There is also a commercial version in PASCAL, for
  Cybers and other mainframes, mentioned in earlier Digests.  -Mike ]

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

[ This message is reprinted with permission. -Mike ]

Date: Wed 27 Jul 83 10:17:39-PDT
From: Chris Ryland <g.Ryland@SU-SCORE.ARPA>
Subject: Re: request for Omninet vs VAXes info
To: local-nets@MIT-MC.ARPA

I've been looking into Omninet lately for other reasons, and, as far as
I can tell, there isn't much activity with interconnection to VAXes, or,
for that matter, with other networks.  Omninet DOES have an XNS packet
encapsulation protocol, which they and Xerox agreed to (it's published
in the Omninet protocol handbook).  There is, I believe, a Unibus
Omninet board just announced or to be announced, though I can't find the
information right now.  With that, I suppose you could write a VMS
driver for Omninet.

For people's information, Omninet seems to be the dominant "cheapo" LAN
for the micro world right now (they claim over 20,000 networks, of average
size 4 (stations)).  It's a 1mb twisted-pair RS422 network, using two
proprietary chips (they sell) and a Motorola 6801 (with their custom code
burned in) to accomplish the link-level, and little of the transport level.
Thus, for the IBM PC, their board is very simple, and low-cost (about $300,
I believe), as well as reasonably efficient, as they DMA from the network
to waiting buffers in the CPU.

It's really a wonderful network from the point of view of cabling: the
"transceivers" cost $10, and can be wired by anyone with a screwdriver.

1mb isn't bad for a small cluster of workstations.  There are some limitations
on the number and type of connections a given workstation can have open: only
one "remote disk" connection at a time is allowed, and only three more other
connections of non-remote-disk type are allowed simultaneously.

/Chris Ryland

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

END OF TCP-IP DIGEST
********************

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Aug-83 06:25:18 EDT
From:      TCP-IP%brl@brl-bmd.UUCP (TCP-IP@brl)
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 2 #14


TCP/IP Digest             Friday, 26 Aug 1983      Volume 2 : Issue 14

Today's Topics:
                    Thank you to TCP -- A testimonial
            Questions about TCP/IP for Various UNIX Versions
                  4.2 BSD IEN142 Time Server Available
               4.2 BSD UNIX Protocol Violation Discussion
               Further Details on the MILNET/ARPANET Split
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: 16 August 1983 17:48 EDT
From: Turkewitz@ddn1
Subject: Thank you, TCP
To: TCP-IP@brl

Dear TCP designers and implementors,

     This mailing list must undoubtably be a forum for many TCP
discussions, complaints, and bugs.  You have probably all heard
more than your share about how much slower TCP is than NCP.  This,
however, is not one of those messages.  This is a simple thank-you.

     I have been working on a TCP/IP connection from Germany over
a satellite link back to the United States.  Unfortunately, the
line has been pretty flakey, and we have had frequent outages.
To my amazement, however, I have found out that when we reestablish
connection, I can pick up right where I left off!  We had one
outage that was about 25 minutes long.  I was in the middle of
composing an electronic mail message at the time the line went down.
When it came back up, I was still in the middle of composing the
message (not even an interrupt!), and the characters that I had
typed between the time that the line went down and the time that I
noticed it was down suddenly echoed to me when the line came back up!

     An associate tells me that this is due to the reliability of TCP.

     Thank you TCP & all involved.
          --Ken Turkewitz

[ Some hosts must have *enormous* values for the retransmit timeouts!  -Mike ]

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

Date: 21 Jul 1983 0906-PDT
From: MUEHLEN@sri-csl
Subject: UNIX networking
To: tcp-ip@brl
cc: muehlen@sri-csl

We want to start with networking different UNIX Systems (berkeley, bell,
xenix, munix) in a local area network (ethernet). Who has done this work
and which hardware and software can be recommended? Is there any survey
available?  Is anybody using UNET or 3COM or Net/One ?

Many thanks -Heinz

[ 4.2 BSD comes with a TCP/IP that is quite good.  Presently, Bell System V
  does *not* support TCP/IP, but Bell Labs is working on it, under contract
  to U.S. Army DARCOM.  UNET software is also being used by some people, and
  their latest version is reported to be useable.  -Mike ]

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

Date: Friday, 15 Jul 1983 14:24-PDT
To: tcp-ip@Brl
Subject: IEN142 time server/user for Berkeley VAX Unix
From: Chris Kent <decwrl!kent%Shasta@sumex-aim>

Just wanted to let the community know that I've written a network time
user/server pair for 4.1cBSD Unix. I have submitted it to Berkeley for
inclusion in 4.2, but who knows when they'll finally ship? So if people
need it, I'll be happy to send it out.

You'll have better luck mailing to me as <cak@purdue>.

Cheers,
chris

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

[ The following 2 messages concern a discussion of an extention to IP which
  is used by 4.2 BSD UNIX on Ethernets.  Bill Shannon's comments on this
  appeared in the UNIX-WIZARDS mailing list, and I enclose them here to
  show some of the felings in the UNIX community.  -Mike ]

Date:	Saturday, 20 Aug 1983 16:17-PDT
To:	tcp-ip@brl
Subject: 4.2 Berkeley Unix protocol violation
From:	imagen!cpr%Shasta@su-score

I've brought this up elsewhere (Unix-Wizards), but I thought I might
mention it to the TCP/IP world directly.  I'm concerned about the Berkeley
4.2 Unix TCP/IP Ethernet implementation, because this version of Unix
uses a private encapsulation protocol for IP packets on 10Mbit Ether, in
violation of the as-yet-unofficial encapsulation protocol.

In detail, the problem is that this TCP implementation uses a non-standard
(i.e., an extension of RFC 820) type of IP packet encapsulation in certain
circumstances, in an attempt at efficiency improvement (due to Unix internal
structures).  This happens with no warning, and with no negotation
whatsoever with the foreign host.  To the foreign host, it simply appears
that the connection is hung at the point the private encapsulation is first
used.

This ``feature'' can be turned off, if you have sources, or are willing to
patch the kernel binary image, but this seems like a big mistake on
Berkeley's part.  Those people trying to supply a product speaking TCP/IP on
Ethernet to the 4.2 Unix world are thus forced to either support this
extension, or else force the site to turn it off on all their 4.2 machines.

Is there an ``official position'' on this type of encapsulation ``violation''
(admittedly by extension)?  (Postel?  Clark?)

/Chris Ryland, IMAGEN

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

Date: 9 Aug 83 12:54:15-PDT (Tue)
To: Unix-Wizards @ Brl-Vgr
From: sun!shannon @ Ucb-Vax
Subject: Re: 4.2 TCP/IP/Ethernet trailers

Philisophically, I don't believe there is anything wrong with the
4.2 TCP/IP Ethernet code, it simply imposes another software layer
(the local net encapsulation) between IP and the Ethernet.
Practically, I think it is rather unfortunate since it destroys
compatibility with the "obvious" implementations of IP on Ethernet.
Having some way of negotiating for the use of trailers sounds nice
but it also sounds like another software layer which won't be
present in the "obvious" implementations.  The same sort of problem
exists with ARP.  Perhaps what is needed is a "standard" for how
to implement IP on Ethernet.

In the Sun 4.2 system we've made it easy to turn off trailers in the
driver, however ARP is mandatory.  We may provide a way to "wire down"
ARP translations (however the ARP translation table is by nature a
cache and therefore small) and I guess it would also be possible
to enable trailers based on the destination address.  As we start
talking to other TCP/IP/Ethernet implementations I suspect we will
have to address these problems more directly.

					Bill Shannon
					sun!shannon
					Sun Microsystems, Inc.

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

Date: 14 Jul 1983 1742-PDT
From: NIC@sri-nic
Subject: DDN Newsletter No. 28
To: DDN-NEWS-LIST1: ;

                FURTHER DETAILS ON THE MILNET/ARPANET SPLIT

Testing the Logical Split

The logical  split  of  the existing  ARPANET  into  the  Experimental
ARPANET and the MILNET  is a major  change which requires  substantual
testing to insure it will be accomplished as an orderly process.

ALL HOSTS AND USERS will be impacted. The ARPANET will change from one
network into two, and communications with hosts on the other net  will
require a knowledge of internet procedures.  MILNET  hosts will use  a
new network number (Network  26).  (Details of procuring  updated host
tables from the Network Information Center will be covered in a forth-
coming newsletter.)

The MILNET and the ARPANET will remain connected via five mail bridges
(internet gateways augmented  with a load-splitting  mechanism and  an
access control filter). The load-splitting mechanism works as follows.
Each bridge will contain  a table assigning  the "default" bridge  for
each host to use in sending traffic  to the other network.  If a  host
sends a  message  via the  wrong  bridge  and its  default  bridge  is
operational, the host will receive an ICMP redirect message telling it
which alternate gateway (i.e., default bridge) to use.  This mechanism
allows the five gateways to  balance the internet traffic.  After  the
initial default  assignment, if  one of  the bridges  is found  to  be
carrying  a  disproportionate  share  of  the  load,  then  the   host
assignment table will  be modified.  No changes to  host software  are
required.  As  long  as a  host  supports  ICMP,  the  host-to-gateway
protocol, it can  make full  use of  the bridges  without knowing  its
default bridge assignment in advance.

A schedule has been developed for  testing prior to the actual  split.
The goals of this testing are to:

     o Verify the mail bridge load-splitting mechanism and
       access control filter.

     o Test host TCP/IP and ICMP implementations.

     o Test the entire system networkwide.

Initial testing will use the testbed environment already available  at
BBN.  BBN has a local  ARPANET-clone network, the BBNNET (Network  8),
which is connected to the ARPANET via a gateway.  During daytime hours
the BBNNET passes about 50% as much traffic as does the ARPANET,  with
the existing gateway passing about 1,000,000 packets during an average
day, with about 80,000 packets per hour passing through it during peak
hours.  This represents  a significantly heavier  load than will  pass
through any  of  the five  mail  bridges, therefore  the  BBNNET  will
provide a realistic test environment.

The testing schedule is:

15 June:  Two additional gateways between the ARPANET and the BBNNET
          are installed.

30 June:  The gateway load-splitting mechanism is operational.

15 June to 15 August:  Gateway load-splitting and routing between
          the ARPANET and the BBNNET are verified.

To aid users in verifying  their capabilities to communicate with  the
MILNET, the  first MILNET  host to  receive net  number 26  will be  a
public news host  implemented  on a C/70,  which will allow  anonymous
logins and  will  contain  information  of  general  interest  to  the
ARPANET/MILNET community.

In addition, to assist TAC users, a TACNEWS service will be  provided.
By typing "@n" to the TAC, a TAC user will automatically be  connected
to the public news host wherever  it may exist without having to  know
its actual internet address.

Following are some of the major milestones of the Split.

1 July - 1 September:  The mail bridges between ARPANET and MILNET
          are installed.

15 July:  The C70 public news host is installed as the first host in
          the  MILNET COI.  Also, a  second MILNET interface will be 
          added to SRI-NIC.  Host managers  and  technical personnel
          should now  try to connect to the  C/70 news host  via the
          mail bridges in order to test their  ICMP implementations.

28 July - 2 August:  Network technical liaison meetings in:
          Los Angeles and San Francisco, Cambridge and Washington DC

1 September - 1 October:  The NIC  maintains the old  (ARPANET-only)
          and  the new  (ARPANET/MILNET)  host tables  in  parallel.
          During  this period  MILNET hosts may  voluntarily  change
          to Network No. 26 provided their changeover is coordinated
          with the NIC to permit timely update of the official  host
          tables.  Two full day  tests will occur, during which  the
          network will enforce the split, and hosts must use the new
          host tables.

4 October:  The logical split occurs.  Network IMPs will enforce the
          proper COI for each host, and network addressing   will be
          updated to reflect the split.

1 Febuary 1984:  Access control filters  are implemented in the mail
          bridges.  Although  this capability has  existed  for some
          time, its implementation is deferred to reduce the problems
          associated with the logical split on 4 October.

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

END OF TCP-IP DIGEST
********************

END OF DOCUMENT