The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 81 1:51:19-EDT (Thu)
From:      Michael Muuss <mike@brl>
Subject:   TCP/IP Digest, V1 #1
TCP/IP Digest            Thursday, 8 Oct 1981      Volume 1 : Issue 1

Today's Topics:
                         A new Discussion Group
      Gateway Connection Policy -- TCP and IP Protocol Definitions
       Comments on TCP4 from BBN -- SRI Networks Development Group
              EDN-UNIX TCP/IP Notes -- 3Com TCP/IP Troubles
      NALCON Conversion Meeting -- BRL TCP/IP Environment (Planned)
       BBN VMUNIX (4.1BSD) TCP/IP -- BBNCC C/30 Features & Futures
          UTexas TCP4 (BBN) Mods -- 3Com TCP/IP:  A Happy User
  Internet Gateway & Computer List -- TCP/IP Implementation Status Overview
            Are PDP-11's Dead? -- 3Com TCP/IP:  More comments
                    BBN TCP/IP for VAX:  Manual Page
----------------------------------------------------------------------

From: Michael Muuss <Mike @ BRL>
Subject: A New Discussion Group

Greetings Earthlings!
	This is the first issue of a new digest which purports to discuss
TCP and IP, the "DoD Standard Networking Protocols for the Eighties". 
Comments will probably center around UNIX implementations, but any
technical networking or implementation discussions too specific for
HUMAN-NETS is fair game here.  Please send submissions to "TCP-IP @ BRL",
requests to "TCP-REQUEST @ BRL" or "TCP-IP-REQUEST @ BRL".

	This is sort of a spur-of-the-moment thing;  it started with our
trying to find out about TCP/IP iplementations, and wound up with dozens
of letters asking for a report of what I found.  This list may die
stillborn, or it may flurish.  Only time will tell!
				Cheers,
				 -Mike

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

Date: 1 Oct 1981 1022-PDT
Sender: WESTINE at USC-ISIF
From: Postel@isif

1)  The question about connection policy should be directed to
DCA or your site's ARPANET sponsor.  But my guess at an answer
is "For a site with a host on the ARPANET (properly authorized)
there should be no additional policy issues in connecting a local
network to the ARPA Internet when the purpose and use of the local
net is the same as for the existing host."

2)  The question about IP and TCP is correctly addressed to me.
 RFCs 791, 792, and 793 define IP and TCP.  The ARPANET already
supports these protocols.  Many TOPS20s, Unix-es (including VAX)
and MIT-Multics, and UCLAs IBM system, already have these protocols
in use.  Work is in progress to replace all TIPs with TACs that
use IP and TCP.  There are about 10 internet gateways in service
already.  ARPA has set a goal for the complete switchover to IP
and TCP by January 1983.

--jon.

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

Date:  2 Oct 1981 0520-PDT
From: DEDWARDS at USC-ISI

BBN (of course) has a TCP 4 up and running written in C.  Its slow
and large (mainly due to the fact that it is entirely outside
the kernelrunning as a user pgm with only a device driver in the
kernel.  Jack Haverty (JHAVERTY at BBN) or Mike Wingfield
(wingfield at BBN-UNIX or BBN-RSM) can say lots more.

Howard Weiss

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

Date:  2 Oct 1981 0702-PDT
From: NRL at USC-ISIE

	For you information the below message was
received by us in late September 1981; you may find in useful.

Regards,
Doug Shannon - ARPAnet mailbox - NRL@ISIE

			- - - - - - - - -

The Networks Development group at SRI can offer assistance in the
development or operations support of one or more of ollowing:

 - modernizing the NALCON sites UNIX from Version 6 to Version 7 (the
   current release from BTL);
 - 96-bit leader NCP software required to address all hosts on the ARPANET; 
 - DoD standard TCP/IP network software with Version 7 UNIX and 
   associated user software such as TCP-FTP, MTP (Mail Transfer Protocol),
   TELNET, etc.;
 - TCP/NCP mail gateway software to facilitate transition from NCP to TCP;
 - a VDH Front-End which would remove the overhead associated with
   the Very Distant Host protocol off of UNIX; 
 - other areas related to UNIX and network systems.

The Networks Development group at SRI specializes in the development 
of local and long-haul network software, hardware, and protocols.
There are currently 8 UNIX systems in operation at SRI, most of which are 
attached to our local area network and/or the ARPANET.

If you would like to discuss your needs and how we can assist you in any of
the mentioned areas, please contact me at:

Geoff Goodfellow
333 Ravenswood Ave.
Menlo Park, CA. 94025
(415) 859-3098
ARPANET: Geoff@SRI-CSL

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

Date:  2 Oct 1981 13:38:33 EDT
From: Edward A. Cain <cain@EDN-UNIX>

Our TCP/IP is an extension of the one on the 11/70 at BBN, in case you
have already heard from them. It runs on V6 here, and on V7 at BBN.
Both machines support two interprocess communication mods to UNIX in
order to allow the tcp/ip to work: (a) Rand "ports", with supporting
"await" and "capacity" system calls, or (b) shared memory. The user-to-
tcp interface can employ either of these techniques.

Our extensions to that work include: (a) handling GGP or ICMP packets,
and (b) reassembly of fragments within IP.

You're welcome to the sources, manual pages, and UNIX hacks needed to
make them work -- if you are using an 11/70. If you have some other
machine like the C/70 or a vax, better get in touch with someone at
BBN. Their active work on tcp/ip has centered around those 2 machines
over the past couple of years. Jack Haverty is one point of contact
(haverty at bbn-unix).

I recall an SRI status report on the 3-com stuff just last week. Seems
the 3-com tcp/ip is full of bugs, and 3-com is under no obligation to
fix things under the license agreement. However, SRI (one of 3-com's
customers) has been able to get some fixes out of 3-com. Sounds kind of
risky.

Ed Cain

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

Date: Fri, 2 Oct 81 16:31-PDT
From: Greg at NPRDC

Indeed, we all are [Converting to TCP/IP] in a year or so.  Geoff@SRI-CSL
has offered to help the NALCON sites convert; maybe we can all get
together and reduce our mutual costs.  We're trying to set up a meeting
to talk about it, probabally in the DC area; would you be interested in it?

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

Date:      2 Oct 81 20:45:01-EDT (Fri)
From:      Michael Muuss <mike@bmd70>
To:        Greg at NPRDC

We will probably be building an extensive local network which will
initially include such varried systems as a CDC 7600 (SCOPE), CDC 173 (NOS),
40 MIPS HEP (UNIX, probably!), zillions of 11/70s and 11/34s, PE 3240s, C/70s,
etc, and using Hyperchannels, PCL-11Bs, DQ-11s, UMC-11s, .... for
communications.  In my opinion, only a "standard" protocol like TCP
will permit a plan like this to succeed (!).

			Networking forever!
			     -Mike

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

Date:  5 Oct 1981  9:24:30 EDT (Monday)
From: Rob Gurwitz <gurwitz at BBN-RSM>

Jack Haverty passed your inquiry about TCP/IP along to me.  In addition to the
experimental TCP/IP that was done for the 11's (which you may or may not
already have), we have been developing a version for the VAX running Berkeley
4.1BSD UNIX.  This software is a full implementation of the protocols and is 
completely independent of any of the old U of I NCP code (including the RMI).
It allows access at the TCP, IP, or local network access levels.  The software
is currently running and under test at several sites, including Berkeley.  When
it is generally released (probably around the first of the year), it will be
available through Berkeley and will be included as part of a future 4.xbsd
distribution.  The configuration currently supports ARPANET 1822 local net
protocol and a driver for the ACC LH/DH-11 IMP i/f, but work is also going on
to develop other local net drivers (i.e., ETHERNET) for it.

Rob Gurwitz

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

Date:      2 Oct 81 18:48:08-EDT (Fri)
From:      Michael Muuss <mike@bmd70>
To:        Paul Santos <Santos@bbne>
Subject:   C/30 Features & Futures

Just out of curiosity, I have some questions about our nice shiney new C/30.

1)  How difficult is it to change a DISTANT host interface to a LOCAL
host interface.  It it a switch, a board, or a big deal?  Could you
estimate the cost of doing this?  Our liason's crystal ball must have
been a little cloudy...

2)  Just for kicks, is it possible for a C/30 to support either (a) more
than 4 modem lines, and/or (b) run the trunk lines at more than 50Kb?

3)  Is there any provision for more than one trunk to connect between two
C/30's to improve transmission between them?

	We are doing a lot of planning here on networking, and are
strongly considering using TCP/IP.  What can you tell me about (or point
me to) how BBN plans to proceed with TCP, and how will this affect
the ArpaNet?

				Cheers,
				 -Mike
------------------------------

Date:  4 Oct 1981 16:10:25 EDT (Sunday)
From: Paul Santos <santos at BBN-UNIX>
To: Michael Muuss <mike.bmd70 at BRL>

Mike,

I have forwarded your message to Nancy Mimno, who is the primary point
of contact for ARPANET users.  I believe the answers are in brief:
1) Easy, 2)(a) in progress, 2)(b) already exists, and 3) has been
thought of but not currently planned.  As for TCP/IP, it is a host
isssue, and does not directly affect the subnetwork;  however, DCA
and ARPA (and DoD in general) are pushing on TCP and plan to outlaw
NCP someday.

Paul

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

Date:  5 Oct 1981 at 0945-CDT
From: roya at UTEXAS-11 (roya)

	I have been working on TCP/IP BBN version 4 in our PWB-UNIX
System. There were and are some problems that I'm trying to fix in
it.  Let me know if I can be any help to you.

						Roya
------------------------------

Date: 7 Oct 1981 11:38:55-PDT
From: menlo70!sytek!zehntel!billn at Berkeley

We have been running it [3Com] for a short time between two 70's hooked up via
an able da-11.  With unloaded systems we get about 60kb during file
transfer.  With one heavily loaded system and one lightly loaded one
we get about 45kb.  We run 2.?bsd and had a few problems, not many,
during installation.  Our problems were due to the fact that, as the
previous msg said, it IS big.  They have tried v. hard to make it a 
"drop in" product, and have done a good job, but the 2.?bsd systems
are just too huge, as normally run, to avoid some hacking during
installation.  (3com is now more experienced in 2.?bsd-ese than they
were...)  It seems relatively bug free and robust.  Our general users have
not been unleashed on it yet -- that'l be the really telling blow.
/b

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

Date:  5 Oct 1981 1358-PDT
From: POSTEL at USC-ISIF
To:   mike.bmd70 at BRL

< INC-PROJECT, IN-HOST-TABLE.NLS.25, >, 27-May-81 16:52 JBP ;;;;
ADDRESSES
   The internet addresses in this memo are stated as four 8-bit fields 
   with the value of each field given in decimal.
GATEWAYS
   Name             Addresses
   ---------------  --- --- --- ---  --- --- --- ---
   DCEC-EDN/ARPA     21   0   0   2   10   3   0  20
   MIT-LCS/ARPA      18   8   0   4   10   0   0  77
   BBN-RCC/ARPA       3   2   0   5   10   2   0   5
   BBN-SAT/ARPA       4   0   0  61   10   3   0  40
   NDRE-SAT/ARPA      4   0   0  38   10   3   0  41
   COMSAT-SAT/COMSAT  4   0   0  39   29   0   2   2
   UCL-SAT/UCL        4   0   0  60   11   3   0  42
   UCL-SAT/NULL       4   0   0  60   35   7   0   0
   UCL-UCL/RSRE      11   3   2  42   25   6   0   0
   RSRE-NULL/PPSN    35   6   0   0   25   6   0   0
   RSRE-NULL/PPSN    35   6   0   0   25  13   0   0
   SRI-PR1/ARPA       2   0   0  11   10   3   0  51
   SRI-PR2/ARPA       6   0   0  11   10   1   0  51
   BBN-BBNPR/ARPA     1   0   0  11    3   0   0  62
   Bragg-BraggPR/ARPA 9   0   0  11   10   0   0  38
COMPUTERS
   Name            Address
   --------------- --- --- --- ---
   ALTA-COMA         3   1   0  50
   BBN-UNIX         10   0   0  63
   BBN-VAX          10   2   0  82
   BBNA             10   3   0   5
   BBNB             10   0   0  49
   BBNC             10   3   0  49
   BBND             10   1   0  49
   BBNE             10   0   0   5
   BBNF              3   2   0  51
   BBNG             10   1   0   5
   EDN-HOST1        21   1   0   1
   EDN-HOST3        21   0   0   3
   EDN-UNIX         10   3   0  20
   ISIB             10   3   0  52
   ISIC             10   2   0  22
   ISID             10   0   0  27
   ISIE             10   1   0  52
   ISIF             10   2   0  52
   MIT-DevMultics   10   4   0  31
   MIT-Multics      10   0   0   6
   UCLA-CCN 3033    10   1   0   1

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

Date:  5 Oct 1981 1544-PDT
From: POSTEL at USC-ISIF

BBN C/70 UNIX

   Date:  14 May 1981 
   From:  Jack Haverty <haverty@BBN-UNIX>

   The C/70 processor is a BBN-designed system using C as its native 
   mode.  It supports Version 7 of UNIX, and provides for user processes
   with 20-bit address spaces.  The TCP/IP for this machine is in 
   development; the BBN VAX-11/780 UNIX implementation will be ported to
   the C/70 UNIX system.  This work is expected to be complete in summer
   '81.

BBN GATEWAYS

   Date:  8 May 1981
   From:  Ginny Strazisar <Strazisar@BBNA>

   This is a status report on the implementation of the Internet 
   Protocol in these gateways:

      the ARPANET/SATNET gateway at BBN (10.3.0.40),
      the ARPANET/SATNET gateway at NDRE (10.3.0.41),
      the Comsat DCN Net/SATNET gateway at COMSAT (4.0.0.39),
      the SATNET/UCL Net/RSRE Net gateway at UCL (4.0.0.60),
      the PR Net/RCC Net gateway at BBN (3.0.0.62),
      the PR Net/ARPANET gateways at SRI (10.3.0.51, 10.1.0.51),
      and the PR Net/ARPANET gateway at Ft. Bragg (10.0.0.38).

   The gateways forward packets with internet header formats as 
   specified in the DoD Standard Internet Protocol, January, 1980.  The 
   gateways implement this Internet Protocol with the following 
   exceptions:

   1.  The type of service field is ignored, i.e., the gateways use the 
   same type of service in each network regardless of the value of the 
   internet type of service field.

   2.  No options are implemented.  Packets containing options are 
   forwarded by the gateways, subject to the specified constraints, 
   i.e., correct checksum, correct length, non-zero time to live field, 
   but the gateways do not process any options.  Packets with options 
   are not fragmented.  If a packet is too large to be sent through the 
   next network on the route to its destination and it contains options,
   then the packet is discarded.

BBN H316 and C/30 TAC

   Date:  14 May 1981
   From:  Bob Hinden <Hinden@BBNE>

   The Terminal Access Controller (TAC) is user Telnet host that 
   supports TCP/IP and NCP host to host protocols.  It runs in 32K H-316
   and 64K C/30 computers.  It supports up to 63 terminal ports.  It 
   connects to a network via an 1822 host interface.

   The TAC's TCP/IP is intended to conform with the IEN-128 and IEN-129 
   specifications with the following exceptions: 1) IP options are 
   accepted but ignored. 2) TCP options are not accepted. 3) Precedence,
   Security, etc. are ignored.

   The TAC also supports Packet core, TAC Monitoring, Internet Control, 
   and a subset of the Gateway-Gateway protocols.

   For more information on the TAC's design, see IEN-166.

   Currently, TAC's TCP/IP has been tested with several other 
   implementations. This includes TOPS20 (BBND, BBNC, BBNA, ISID), 
   Multics (MIT-Multics), IBM (UCLA), 11/70 Unix (BBN-Unix,EDN-Unix), 
   and VAX Unix (BBN-VAX). All major features have been implemented 
   except IP reassembly and TCP Urgent handling.  These will be done in 
   the near future.

BBN HP-3000

   Date:  14 May 1981
   From:  Jack Sax <sax@BBN-UNIX>

   The HP3000 TCP code is in its final testing stages.  The code 
   includes under the MPE IV operating system as a special high priority
   process.  It is not a part of the operating system kernel because MPE
   IV has no kernel.  The protocol process includes TCP, IP, 1822 and a 
   new protocol called HDH which allows 1822 messages to be sent over 
   HDLC links.  The protocol process has about 8k bytes of code and at 
   least 20k bytes of data depending on the number of buffers allocated.

   The TCP code is believed to support all features except rubber EOL.  
   The IP code currently supports fragment reassembly but not 
   fragmentation.  In addition provisions have been made to allow the IP
   layer to accept and act on routing and source quench messages.  These
   features will be added sometime this summer.  Security and precedence
   are currently ignored.

   In addition to the TCP the HP3000 has user and server TELNET as well 
   as user FTP.  A server FTP may be added later.

   A complete description of the implementation software can be found in
   IEN167.

BBN PDP 11/70 UNIX

   Date:  14 May 1981
   From:  Jack Haverty <haverty@BBN-UNIX>

   This TCP implementation was written in C.  It runs as a user process 
   in version 6 UNIX, with modifications added by BBN for network 
   access.  It does not perform reassembly, or rubber eol, and has no 
   separate IP user interface.  It supports user and server Telnet.

   This implementation was done under contract to DCEC.  It is installed
   currently on several PDP-11/70s and PDP-11/44s. Contact Ed Cain at 
   DCEC <cain@EDN-UNIX> for details of further development.

BBN TENEX & TOPS20

   Date:  13 May 1981
   From:  Charles Lynn <CLynn@BBNA>

   TCP4 and IP4 are available for use with the TENEX operating system 
   running on a Digital KA10 processor with BBN pager.  TCP4 and IP4 are
   also available as part of TOPS20 Release 3A and Release 4 for the 
   Digital KL10 and KL20 processors.

   Above the IP layer, there are two Internet protocols within the 
   monitor itself (TCP4 and GGP).  In addition up to eight (actually a 
   monitor assembly parameter) protocols may be implemented by user-mode
   programs via the "Internet User Queue" interface. The GGP or 
   Gateway-Gateway Protocol is used to receive advice from Internet 
   Gateways in order to control message flow.  The GGP code is in the 
   process of being changed.

   TCP4 is the other monitor-supplied protocol and it has two types of 
   connections -- normal data connections and "TCP Virtual Terminal" 
   (TVT) connections.  The former are used for bulk data transfers while
   the latter provide terminal access for remote terminals.

   Note that TVTs use the standard ("New") TELNET protocol.  This is 
   identical to that used on the ARPANET with NCP and in fact, is 
   largely implemented by the same code.

   At the IP level, fragmentation and reassembly are not currently 
   supported.  The Autodin II Security related option can be parsed, but
   no code for doing preemption of resources has been writen. Certain 
   other security-related options are implemented.

   User and Server FTP processes above the TCP layer are under active 
   development.

BBN UNIX

   Date:  1 May 1981
   From:  Mike Wingfield <Wingfield@BBND>

   1. Hardware - PDP-11 running UNIX version 7, with BBN IPC additions.

   2. Software - written in C, requiring 22K instruction space, 15K data
   space.  Supports 10 connections.

   3. Status - TCP has been essentially completed since March, 1979, and
   no additional work has been done on it since then.

   4. Unimplemented protocol features

      A. TCP
         Does not support Rubber EOL
         Ignores options except S/P/T
         Discards out-of-order segments

      B. IP
         Does not support fragmentation or reassembly.
         Ignores options

   5. Documentation - "TCP/PSIP Development Report", and "TCP Software 
   Documentation", both BBN reports.

BBN VAX

   Date:  7 May 1981
   From:  Rob Gurwitz <Gurwitz@BBN-UNIX>

   The VAX TCP/IP implementation is written in C for Berkeley/VMUNIX.  
   It is described in detail in IEN168.  It is currently operational 
   experimentally and is undergoing further development.

   The implementation is believed to conform to the specification with 
   the following exceptions:

   1) All internet options are currently ignored.

   2) Security, precedence, etc. are ignored.

   The TCP/IP is implemented within the kernel.  It supports all aspects
   of the protocol, and provides a separate user interface at the IP 
   level.

   Continuing development includes implementation of handling internet 
   routing messages, hosts on multiple networks, and performance 
   improvement.  Tools are available on the VAX for monitoring and 
   recording net traffic.

COMSAT

   Date:  30 Apr 1980
   From:  Dave Mills <Mills@ISIE>
   

   1. The TCP/IP implementation here runs in an LSI-11 with a homegrown 
   operating system compatible in most respects to RT-11. Besides the 
   TCP/IP levels the system includes many of the common high-level 
   protocols used in the ARPANET community, such as TELNET, FTP and 
   XNET.

   2. Connections have been verified with the following other 
   implementations:

      TOPS-20 (BBNF, ISID, ISIE and ISIF)
      Unix (BBN, NPL and EDN)
      Multics (MIT-Multics)
      IBM 3033 (CCN)
      Packet Radio TIU (UCL, RSRE)
      and the several hosts on the COMSAT local net (DCNET) running the 
      the same software.

   3. The TCP implementation is believed to conform to the specification
   in all aspects except:

      a. It does not implement the rubber-EOL mechanism. All buffers 
      appear a single octed in length.

      b. It does not implement the urgent mechanism.

   4. The IP implementation is believed to conform to the specification 
   in all respects except:

      a. Fragmentation and reassembly is not implemented.

      b. All options, including security, timestamping, etc., are 
      ignored by the IP layer. Timestamping is handled by the protocol 
      and user layers. Other options can be specified by the protocol 
      and user layers and checked by the protocol layer.

   Our plans for the remainder of the FY80 and FY81 years are to upgrade
   the implementation to conform to the full specification in all 
   practicable respects and, especially, to evaluate overall performance
   in systems involving both high-performance and limited-performance 
   hosts and nets.

DTI VAX

   Date:  15 May 1981
   From:  Gary Grossman <grg@DTI)>

   Digital Technology Incorporated (DTI) IP/TCP for VAX/VMS

   The following describes the IP and TCP implemenation that DTI plans 
   to begin marketing in 4th Quarter 1981 as part of its VAX/VMS network
   software package.

   Hardware:  VAX-11/780 or /750.

   Operating System:  DEC standard VAX/VMS Release 2.0 and above.

   Implementation Language:   Mostly C, with some MACRO.

   Protocol Features Supported:

      IP:

         Fragementation/Reassembly:  Does not fragment, but does 
         reassemble.

         Options:  Security option is both generated and interpreted.

         Packet identifier:  Can be specified by user, but will generate
         a unique identifier if user does not supply one.

         Reassembly timeout:  Fixed value.  If buffers fill up, oldest 
         fragment is discarded first.

         Gateway functions:  All necessary GGP functions will be 
         implemented. (GGP functions are not implemented in current NFE 
         IP.)

         Type of Service:  As for Gateway functions.

         Support of protocols other than TCP:  Yes, simultaneously with 
         TCP.

      TCP:

         Precedence and security fields:  Both generated and 
         interpreted.

         TCP options:  All defined options are implemented.

         Urgent:  Implemented as per specification.

         EOL:  As per specification.

         Buffer size:  Option implemented; user may specify buffer size 
         within limits.

         Retransimission:  Timeouts employ exponential backoff until a 
         limit is reached, at which time user is signalled. Transmits 
         empty packets into a zero window.

         Initial sequence number:  Derived from 32-bit system clock with
         10 us. resolution.

         Window strategy:  Window size is larger than the actual buffer 
         space available by the size of the maximum size internal 
         buffer.

         ACK generation:  ACK is sent as soon as data has been placed in
         sequence into user buffer.

   Code size:

      IP (Includes BBN 1822 interface code, about 30%):

         Object code:            14K bytes.
         Buffer and table space: 24K bytes.
         Source:                  7K lines of C code with commentary.

      TCP:

         Object code:            27K bytes.
         Buffer and table space: 46K bytes.
         Source:                 15K lines of C code with commentary.

   Fixed table space:  See above.

   Connections supported:  Maximum of 64.

   User level protocols available:  TELNET, FTP, and MTP will be 
   available. (The NFE version uses AUTODIN II protocols.)

MIT MULTICS

   Date:  13 May 1981
   From:  Dave Clark <Clark@MIT-Multics>

   Multics TCP/IP is implemented in PL/1 for the HISI 68/80. It has been
   in experimental operation for about 18 months; it can be distributed 
   informally as soon as certain modifications to the system are 
   released by Honeywell.  The TCP and IP package are currently being 
   tuned for performance, especially high throughput data transfer.

   It is believed that the implementation fully conforms to the DOD 
   standard.  It also supports most relevant features of GGP, including 
   redirect packets. The IP layer is a gateway, and supports 
   fragmantation as well as reassembly.

   Higher level services include user and server telnet, and a full 
   function MTP mail forwarding package.

   The TCP and IP contain good logging and debugging facilities, which 
   have proved useful in the checkout of other implementations. Please 
   contact us for further information.

SRI LSI-11

   Date:  15 May 1981
   From:  Jim Mathis <mathis.tscb@Sri-Unix>

   The IP/TCP implementation for the Packet Radio terminal interface 
   unit is intended to run on an LSI-11 under the MOS real-time 
   operating system.  The TCP is written in MACRO-11 assembler language.
   The IP is currently written in assembler language; but is being 
   converted into C. There are no plans to convert the TCP from 
   assembler into C.

   The TCP implements the full specification, although the current user 
   interface lacks a mechanism to communicate URGENT pointer information
   between the TCP and the higher-level software.  The code for 
   rubber-EOL has been removed in anticipation of a change to the 
   specification.  The TCP appears to be functionally compatible with 
   all other major implementations.  In particular, it is used on a 
   daily basis to provide communications between users on the Ft. Bragg 
   PRNET and ISID on the ARPANET.

   The IP implementation is reasonably complete, providing fragmentation
   and reassembly; routing to the first gateway; and a complete 
   host-side GGP process.  Currently the source quench message is 
   ignored. No IP options are generated and all received options are 
   ignored.

   A measurement collection mechanism is currently under development to 
   collect TCP and IP statistics and deliver them to a measurement host 
   for data reduction.

    

UCLA  IBM

   Date:  13 May 1981
   From:  Bob Braden <Braden@ISIA>

   Implementation Status -- IP/TCP for IBM 360/370 under OS/MVT. May 12,
   1981

   1. Hardware

      IBM 360 or 370, with a "Santa Barbara" interface to the IMP.

   2. Operating System

      OS/MVS with ACF/VTAM.  An OS/MVT version is also available.

      The UCLA NCP operates as a user job, with its own internal 
      multiprogramming and resource management mechanisms.

   3. Implementation Language

      BAL (IBM's macro assembly language)

   4. Protocol features supported:

      A. IP PROTOCOL:

         (1) Fragmentation/reassembly: performs reassembly.  Does not 
         fragment, assuming that higher-level protocol (TCP) will create
         suitable size segments during packetizing.

         (2) Options: all internet options accepted but ignored.  None 
         are sent (in particular, no error options).

         (3) Identifier selection: uses globally-unique identifiers for 
         transmitted segments, independent of destination.

         (4) Reassembly timeout:  fixed value (30-60 seconds), 
         independent of time-to-live field.  Packets are discarded if 
         time-to-live field is zero.

         (5) Gateway functions:  Unable to select an alternate route 
         (gateway) if the original route fails.  Does accept GGP, and 
         acts on Redirect, Destination Unreachable, and Echo packets.  
         Source Quench is ignored.

         (6) Type of Service: default Type of Service set, may cause 
         either Subtype 0 or Subtype 3 (Uncontrolled) packets to be 
         sent.

      B. TCP PROTOCOL:

         (1) Precedence, security fields: not set or tested.

         (2) TCP Options: no options generated.  All options received 
         but only Buffer Size is acted upon.

         (3) Urgent: may be sent and received by user process.

         (4) EOL: may be sent by user process, but received EOL's are 
         not passed to user process.

         (5) Buffer Size: will transmit according to specified buffer 
         size.  Uses circular buffer for received data, so never 
         specifies a buffer size to remote TCP.

         (6) Retransmission: successive retransmissions use exponential 
         backoff.  Base time is 2 times observed weighted-average 
         round-trip time.  Round-trip time is measured by initial packet
         transmission to complete acknowledgment. Retransmits slowly 
         into zero window.

         (7) Initial Sequence Number: derived from system clock.

         (8) Window strategy: uses conservative strategy, never adver- 
         tising a receive window larger than the space available in the 
         circular buffer.

         (9) ACK generation: always sends <ACK> in response to receipt 
         of a non-empty packet.  As user process removes bytes from 
         buffer,  optimizing algorithm determines when to generate <ACK>
         to inform sender of larger window.

   5. Code Size (addition to existing NCP code)

      Resident Control Process:          4K bytes.

      Internet Protocol Layer:          10K bytes. (transient)

      TCP Protocol Layer:               10K bytes. (transient)

   6. Fixed Table Space

      The limited fixed table space is included in the code (above).

   7. Connections Supported:

      Only practical limitation is amount of memory available in NCP 
      region for buffers and per-connection control blocks; requirements
      are:

         For each connection, the internet and TCP layers require 
         control blocks totalling 256 bytes.

      (*) Receive:

         Segment reassembly buffer=
         max segment size - min internet header length + 16= 572 bytes 
         per buffer.

      (*) Send:

         128 bytes per unacknowledged segment.

         Note: the actual data being sent is not counted here, as it 
         occupies buffer space belonging to the appropriate user-level 
         protocol module.

            (*)Note: there is a pool of these objects, shared among all 
            active connections.  The pool grows and shrinks dynamically 
            with the number of connections; it is probably reasonable to
            expect an average of one segment reassembly buffer and one 
            unacknowledged segment (total of 700 bytes) per TCP 
            connection.

      In addition to this TCP-specific memory, there is the memory to 
      support the user-level protocol.  For example, a server-Telnet 
      session to TSO requires control blocks and buffers totalling about
      1800 bytes; this is identical for TCP and for the ARPANET 
      Host-Host ("NCP") protocol.

   8. User-Level Protocols Available

      User and Server Telnet

   9. Philosophical Remarks

      This implementation of the Internet and TCP protocols is designed 
      to meet the following general objectives:

         (a) operate within the existing NCP system job, sharing code 
         and control-block formats wherever possible;

         (b) be compatible at the system-call level with the existing 
         user-level protocol modules;

         (c) implement the Internet protocol as a distinct layer, with 
         interfaces designed to expedite the implementation of other 
         higher-level internet protocols in addition to TCP;

         (d) require minimum NCP resources when internet protocol is not
         in use.

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

Date:      5 Oct 81 20:09:53-EDT (Mon)
From:      Michael Muuss <mike@bmd70>
To:        Rob Gurwitz <gurwitz@bbn-rsm>

Rob -
	Thanks very much for the information about the 4.1 BSD TCP/IP
implementation.  Sounds like a very nice job!  What is the feasibility
of moving it to a PDP-11 UNIX system?  There are some of us who can not
afford to subscribe to the Berkeley "PDP-11s are dead" philosophy...

	Can you feed me any handy dribbles of documentation or overview
information?
				Cheers,
				 -Mike
------------------------------

Date: 3 Oct 1981 00:13:28-PDT
From: ESVAX.clemc at Berkeley
To: csvax.unix-wizards at Berkeley

The 3Com version for the 11 is fairly good.  It is like the old
U of I NCP in that it is not all kernel resident (like the BBN Version).
It IS large.  Tektronix has been using it will 2.8 BSD for a few months
but they have had lots of trouble.  It has been a conbination of sparse
comments in the 3Com code, 2.8 BSD and trying to Talk TCP to a CDC Cyber
on the other end.  They are using Network System's Corp "HYPERchannel"
gear for the physical medium, which is very fast but the 11/70 can not
keep up with it (niether can the cyber when running TCP).

Both BBN and 3Com have used Psuedo TTY's for the Virtual Terminal Protocol.
This has both advantages and disadvantages.   3Com wants to make their
code portable to other UNIX versions.  They are working on/have made to work
a version that runs on an 11/34 with overlays. As far as I know, BBN has
punted the 11's.

Clem

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

Date:  6 Oct 1981 11:32:45 EDT (Tuesday)
From: Rob Gurwitz <gurwitz at BBN-RSM>
To: Michael Muuss <mike.bmd70 at BRL>

There is a note describing the internals of the TCP/IP for the VAX available
from the ARPANET NIC as IEN 168.  In addition, I have manual pages for
the lowest level TCP/IP/local net i/f, if you want them.  The TELNET
and FTP are ports of software that has been around for awhile, so manual
pages for them are probably generally available (you probably already
have them if you're running NCP on an 11).  MTP mail is new, but we have
no manual pages ready yet.

Rob.

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

Date:  7 Oct 1981  9:21:34 EDT (Wednesday)
From: Rob Gurwitz <gurwitz at BBN-RSM>
To: Michael Muuss <mike.bmd70 at BRL>

Here is the manual page for low level TCP access.  I hope it's useful.
Feel free to include info about the implementation in your 
summary.
			Rob.

NET(5)              UNIX Programmer's Manual              NET(5)



NAME
     tcp, ip, rawnet - internet networking software

SYNOPSIS
     open ("/dev/net/net", ncon);

     struct con *ncon;

     struct lhost {                  /* net library format internet address */
            unsigned char l_hoi;            /* host on imp */
            unsigned char l_net;            /* network */
            n_short l_imp;                  /* imp */
     };
                                        /* c_mode field definitions */
     struct con {                    /* user connection structure */
            unsigned char c_mode;           /* mode 0-passive 1-active (see flags) */
            unsigned char c_sbufs;          /* # send buffers to use */
            unsigned char c_rbufs;          /* # rcv buffers to use */
            unsigned char c_prec;           /* precedence */
     #define c_lo c_prec                     /* low raw link or proto # */
            unsigned char c_sec;            /* security level */
     #define c_hi c_sec                      /* hi raw link or proto # */
            unsigned char c_compt;          /* compartment */
            unsigned char c_timeo;          /* tcp open timeout */
            unsigned char c_x;              /* (unused) */
            unsigned short c_lport;         /* local port */
            unsigned short c_fport;         /* foreign port */
            struct lhost c_con;             /* foreign socket */
     };

     struct netstate {               /* network status structure */
            unsigned char n_lolink;         /* low link no. in range (IP, RAW) */
            unsigned char n_hilink;         /* high link no. in range (IP, RAW) */
            unsigned char n_snd;            /* # send bufs allocated */
            unsigned char n_rcv;            /* # receive bufs allocated */
            unsigned char n_ssize;          /* # bufs on send buffer */
            unsigned char n_rsize;          /* # bufs on receive buffer */
            unsigned char n_state;          /* state of this connection */
            unsigned char n_flags;          /* misc. flags (see below) */
            unsigned short n_lport;         /* local port */
            unsigned short n_fport;         /* foreign port */
            struct lhost n_con;             /* foreign socket */
     };

     #define CONACT  1                       /* active connection */
     #define CONTCP  2                       /* open a tcp connection */
     #define CONIP   4                       /* open a raw ip connection */
     #define CONRAW  8                       /* open a raw local net connection */
     #define CONDEBUG 128               /* turn on debugging info */

                                        /* net ioctl definitions */
     #define NETGETS 1                       /* get status */
     #define NETSETD 2                       /* set debugging info */
     #define NETSETU 3                       /* set urgent mode */
     #define NETRSETU 4                      /* reset urgent mode */
     #define NETSETE 5                       /* set EOL mode */
     #define NETRSETE 6                      /* reset EOL mode */
     #define NETCLOSE 7                      /* initiate tcp close */
     #define NETABO           /* initiate tcp abort */

     #define SIGURG 16               /* urgent signal */

     #ifndef KERNEL                           /* n_flags field definitions */

     #define UEOL    0001                    /* EOL sent */
     #define UURG    0002                    /* urgent data sent */
     #define UDEBUG  0004                    /* turn ongging info recording */
     #define ULOCK   0010                    /* receive buffer locked */
     #define UTCP    0020                    /* this is a TCP connection */
     #define UIP     0040                    /* this is a raw IP connection */
     #define URAW    0100                    /* this is a raw 1822 connection */
     #define ULISTEN 0200                    /* awaiting a connection */

                                        /* n_state field definitions */
     #define UCLOSED 0000                    /* connection closed */
     #define UCLSERR 0001                    /* error -- connection closing */
     #define UABORT  0002                    /* connection aborted */
     #define UINTIMO 0004                    /* open failed -- init timeout */
     #define URXTIMO 0010                    /* retransmit too long timeout */
     #define URESET  0020                    /* connection aborted due to reset */
     #define UOPERR  0040                    /* open failed -- not enough buffers */
     #define UURGENT 0100                    /* urgent data received */
     #define UNETDWN 0200                    /* connection aborted due to net */

     #endif KERNEL

DESCRIPTION
     The special file /dev/net/net is used to access ARPANET type
     packet-switched  networks  via  the  DoD  standard host-host
     Internetworking   Protocols,   TCP   (Transmission   Control
     Protocol),  and  IP  (Internet  Protocol).   It  also allows
     communication over the local network(s) to which the  system
     is  connected  with "raw" packets, enabling user software to
     do its own communications processing.  Access to the network
     at this level is the most direct form of use.  It is assumed
     that most users will use  higher  level  protocol  programs,
     like  ftp(1)  and telnet(1) to communicate over the network.
     (This  description  assumes  the  reader  is  familiar  with
     ARPANET type communications protocols.)

ESTABLISHING CONNECTIONS
     To establish a connection via TCP or IP, or  to  communicate
     with  raw packets, the open(2) call is given, with the usual
     mode  argument  replaced  by  a  pointer  to  a   connection
     structure,  defined  in /usr/include/con.h. The c_mode field
     of this structure  specifies  what  type  of  connection  is
     desired (TCP, IP, or RAW), and whether or not the connection
     is  to  be  active  (specifying  a  specific  foreign   host
     address), or passive (with no foreign address, implying that
     the connection will be established when any foreign  process
     tries to communicate with the opener).

     The c_sbufs and c_rbufs fields  specify  buffer  allocations
     for   the   send   and  receive  sides  of  the  connection,
     respectively.   If  either  value  is  zero,   the   default
     allocation  will  be  used  for that direction (currently 1K
     bytes).  The user can request up to 4K bytes each  for  send
     and receive directions by varying these parameters between 1
     and 4.

     The c_prec, c_sec, and  c_compt  fields  specify  values  of
     precedence, security level, and compartmentalization for TCP
     connections.   (N.B.   This   feature   is   currently   not
     implemented).  For IP and RAW connections, the c_hi and c_lo
     fields specify a range of IP protocol numbers or  local  net
     dispatch  numbers (e.g., ARPANET link numbers) to watch for.
     Messages falling into this range are queued  for  the  user.
     The  end of the range is used in sending messages.  Low
     must be less than or equal to high, and numbers in the range
     must not be in use in any other connection.

     The c_timeo parameter specifies a length of time in  seconds
     to  wait  for connection establishment before aborting (this
     does not apply to passive opens).  If the field is zero, the
     default of 30 seconds is used.

     The remaining fields specify local, and  foreign  ports  for
     TCP,  and  the  foreign host address in net long format (see
     libn(3)). The local port may be  zero,  in  which  case  TCP
     assigns a unique port number to the connection.  The foreign
     port and host address may only be zero for a passive open.

READING AND WRITING
     If the open succeeds, a file descriptor  is  returned  which
     may  be  used  in subsequent reads and writes (see, read(2),
     write(2)). Reads  and  writes  work  as  usual  with  a  few
     exceptions.    A   read  may  return  with  error  condition
     ENETSTAT, which indicates that  some  exceptional  condition
     has been detected.  In this case, a 16 bit value is returned
     to the read buffer, which give the status of the  connection
     that  caused  the  return.  Further status may be determined
     with ioctl(2). (see, NETWORK STATUS).  If the  condition  is
     non-fatal, the read may be re-issued.  Reads may return less
     data than requested if a TCP EOL was detected.   Reads  will
     block if there is no data for the user.  Writes block if the
     amount of  send  buffer  resources  for  the  connection  is
     exceeded.   IP and RAW reads return the appropriate protocol
     leaders along with any data received.  Only one  IP  or  RAW
     message may be received or sent per call.

     In addition to normal TCP reads and  writes,  the  user  may
     wish  to  indicate EOL and URGENT data on writes and receive
     notification of URGENT data sent by the foreign  peer.   EOL
     and  URGENT  are  enabled by issueing the NETSETE or NETSETU
     ioctl calls.  Once set, EOL is sent at the last byte of each
     subsequent  write.   Similarly, the URGENT pointer is set to
     start at the first byte of the next write, and ends with the
     first  byte sent after URGENT mode is disabled.  These modes
     are disabled by  the  NETRSETE  and  NETRSETU  ioctl  calls.
     URGENT  data  is  indicated  by signal SIGURG when the first
     byte is received.  This  signal  is  normally  ignored.   (A
     status flag is also set in the presence of urgent data.)

CLOSING CONNECTIONS
     Normally, the close(2) call is used to close a TCP,  IP,  or
     RAW  connection.   In  each case, it indicates that the user
     will send or receive no more  data.   For  TCP  connections,
     close  initiates  the connection closing protocol, though it
     returns  immediately.    Thus,   the   internal   connection
     structures  persist  until  the  connection  has reached the
     CLOSED state.  For IP and  RAW  connections,  the  close  is
     immediate and deletes all internal structures.

     In addition to close for TCP connections, there is an  ioctl
     call,  NETCLOSE,  which  indicates that the local connection
     will send no more data, but is still able  to  receive  data
     from  the foreign peer.  In this case, subsequent writes are
     illegal and will terminate with errors, but subsequent reads
     will  work  until  the  connection  is closed by the foreign
     peer.

NETWORK STATUS
     There are several ioctl(2)  calls  available  for  receiving
     network  status  information  or initiating certain modes or
     functions.  Most of these calls have been  described  above.
     The  status  call,  NETGETS,  takes a status buffer pointer,
     which points to a  netstate  structure,  illustrated  above,
     which is filled in by the call.

     To summarize, the various ioctl calls are:

     NETGETS   Return network status information to the structure
               pointed at by third argument of ioctl.

     NETSETD   Reset the debugging log to the file  name  pointed
               at  by  the third argument.  The file must already
               exist.  If the argument is zero,  turn  off  debug
               logging (see, DEBUGGING).

     NETSETU   Set urgent mode starting at next byte written (TCP
               only).

     NETRSETU  Reset urgent mode, urgent  pointer  ends  at  last
               byte written (TCP only).

     NETSETE   Set EOL mode,  send  EOL  at  last  byte  of  each
               subsequent write (TCP only).

     NETRSETE  Terminate EOL mode (TCP only).

     NETCLOSE  Start TCP connection close.  User can continue  to
               receive data (TCP only).

     NETABORT  Abort TCP connection.  Foreign peer is  reset  and
               no more data may be sent or received (TCP only).

DEBUGGING
     The network software enables certain trace information to be
     recorded for TCP connections.  This information is logged in
     a single debugging log file.  To enable  this  feature,  the
     CONDEBUG  bit  in  the  c_mode  field of the open connection
     parameter structure must be set.  The default debugging  log
     is /etc/net/tcpdebug. This may be changed or the feature may
     be disabled system wide with the NETSETD ioctl  call.   Only
     the  super-user  may  do  this.  The format of the debugging
     information  is  several  bytes  of  binary  data  per   TCP
     transaction.   The  log may be printed in readable form with
     trpt(1).

DIAGNOSTICS
     The following system error codes may be returned by  network
     system calls:

     ENETSTAT  (35) Network status available (not a fatal  error,
               see READS AND WRITES).

     ENETDWN   (36) Open failed  because  network  connection  is
               unavailable.

     ENETCON   (37) Open  failed  because  there  were  too  many
               connections.

     ENETBUF   (38) No more network buffer space.

     ENETERR   (39) Fatal error from network protocol processor.

     ENETRNG   (40) IP or RAW open failed because the protocol or
               dispatch  number  was  out  of range or already in
               use.  TCP open failed because the  user  tried  to
               open  an  already  existing  connection (i.e., one
               with the identical foreign host address and  local
               and foreign ports).

FILES
     /dev/net/net
     /etc/net/tcpdebug

SEE ALSO
     ftp(1),  telnet(1),  trpt(1),  read(2),  write(2),  open(2),
     close(2), ioctl(2), libn(3)

     R.F.   Gurwitz,   VAX-UNIX   Networking   Support    Project
     Implementation  Description,  DARPA  Information  Processing
     Techniques Office, IEN 168, January, 1981.

     J. Postel  (ed.),  DoD  Standard  Internet  Protocol,  DARPA
     Information  Processing Techniques Office, IEN 128, January,
     1980.

     J. Postel (ed.), DoD Standard Transmission Control Protocol,
     DARPA  Information  Processing  Techniques  Office, IEN 129,
     January, 1980.

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

End of TCP-IP Digest
********************


-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue Oct 13 21:50:06 1981
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   Re:  Please add to your list...

>From tcp-ip@brl Tue Oct 13 21:38:19 1981
Geoff (et.al.) -

Greetings, and welcome to the TCP/IP Digest mailing list.
Please send submissions to "TCP-IP @ BRL", and address
any requests to "TCP-IP-REQUEST @ BRL".

		Enjoy!
		-Mike Muuss
		U.S. Army Ballistic Research Laboratory

PS:  If you desire a copy of Vol 1, #1 (the only issue to date),
     send a note to TCP-IP-REQUEST@BRL.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Wed Oct 14 01:39:22 1981
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #2

>From tcp-ip@brl Wed Oct 14 01:20:57 1981
TCP/IP Digest          Wednesday, 14 Oct 1981      Volume 1 : Issue 2

Today's Topics:
                          Administrative Trivia
                    NCP-to-TCP Transition Deadline!!
             Performance of 3Com "UNET" UNIX TCP/IP Software
                Behind the sceens at 3Com & Stanford PUP
             Final word on BBN PDP-11 TCP/IP Implementation
                  RFCs and IENs  --  How to get to NIC
                            Gateway questions
----------------------------------------------------------------------

From:      Michael Muuss <mike@bmd70>
Subject:   TCP-IP Digest, Plans, etc.

	At this point, everybody who has requested to be added to the
TCP-IP discussion list has been added.  In addition, Jon Postel had a
list for distributing notices about Internetworking changes.  At his
suggestion, I have incorporated that list into the Digest list.  If you
are reading this, and don't want to see any more of these Digests,
please sent a note to TCP-IP-REQUEST@BRL.

	The scope of the Digest will probably exceed the rather specific
"TCP-IP Digest" title, but that is OK by me.  I see this as a forum for
discussing implementation and design problems relating to large scale
networks, and internetworking.  Anything too practical for HUMAN-NETS
is fair game here (at least for now).  But I would hope that discussion
will focus on IP and TCP, because this is where much of the real action
seems to be.

	At the present, I expect to be able to issue one digest per week,
with each issue being (hopefully) 15000 to 30000 characters long,
depending on submissions.  No more mamouth 55K digests (OOPS!).  If the
interest picks up, I can see being able to do as many as 3 per week.
More than that, and I will have to get help, but it will be no problem.

	Already, some people have mentioned that mailing stuff to
"TCP-IP@BRL" might be hard to remember or type.  I will be glad to set
up as many aliases for the list as seem useful.  Everybody:  please
suggest some mnemonic, short aliases!

	I am keeping an archive here on BRL (0/29), and hope to announce
the method by which they can be retrieved, sometime soon.  (However,
we can't permit anonymous login, so it will probably be strange).  If
other sites wish to keep an online copy that can be FTP'ed, please let
me know, and I will summarize for the list.

				Cheers!
				-Mike

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

From: POSTEL at USC-ISIF
Subject: NCP-to-TCP Transition

It is really very important for everyone to notice the deadline for
completing the cutover to IP/TCP and the elimination of NCP from use
in the ARPANET.

The deadline is:  1 January 1983.

That is 14 and a half months from now.  Really not much more than a year.

--jon.

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

From: croft at SRI-UNIX
Subject: UNET at SRI

The SRI Telecommunications Sciences Center has been running the 3COM
UNET software (release 1.5) on two 11/44's for the past few months
and we have been quite pleased.  This is contrary to the false rumor
circulated in the last TCP/IP digest (V1N1).  Both machines run a standard
V7;  installation was very smooth and straightforward, requiring no
hacking of the kernel.  We chose the 3COM software over BBN's "free"
V6 TCP for just this reason.  One of 11/44's is on the ARPANET as
SRI-PRMH (packet radio measurement host).  A locally written device
driver for UNET provides TCP/NCP multiplexing of the single 1822
interface.  The other 11/44 is currently being used in a packet radio
experimental network at Fort Sill, Oklahoma.  The device driver in the
latter case speaks CAP5 protocol over an 1822 interface to the radio.

Throughput of the ARPANET version seems to be quite good (compared to
the V6 BBN):  20K bits/second on an FTP to ourselves with the packets
looping all the way out the 1822 and back in again.  Of course UNET
is doing twice as much work here as normal and one would expect
perhaps 40K bps if two UNETs were FTPing thru the same IMP.

Although UNET is certainly the fastest PDP11 TCP around, it still has
the thruput constraints inherent in any TCP.  (See the excellent
article by Bunch and Day of DTI: "Control Structure Overhead in
TCP").  3COM claims 100K bps max thruput for their TCP on DEC hardware.
I think a previous digest entry mentioned 50 to 60K average thruput on
DA11 hardware (DA's are about 8Mbps devices).  My beef is that with
simpler protocols one should be able to do much better.  As an example
I mention the UNIX network at Purdue University EE department.  
It uses 1M bps DMC and DMR link hardware and achieves 400K end to
end process usable bandwidth.  Perhaps TCP's on a fast local network
should support some simpler subset of the protocol as an option to
allow improved thruput.

	--Bill Croft (croft@sri-unix)

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

From: Bill Nowicki <CSD.NOWICKI at SU-SCORE>
Subject: Re:   Re:  TCP/IP for UNIX

I know Bob Metcalfe, Ron Crane, Bruce Borden, and Greg Shaw either directly
or indirectly; these are the main movers behind 3COM.  Bob invented Ethernet
at Xerox, with Ron designing some of their controllers.  Bruce and Greg are
Unix wizards, so between them there is a lot of expertise.  3COM has been
targetting their marketing to small systems (11s and even Onyxes), and since 
we (Stanford) have mostly Vaxes and 20s, we are pressured into going with
BBN's implementation because it was Arpa-sponsored.

By the way, we are currently using the PUP Internetwork architecture at
Stanford, which Metcalfe had a hand in designing.  It was quite a step
for him to adopt the DOD Internetwork architecture for the sake of
standardization.  A welcome change from the "not invented here"
syndrome.
	-- Bill

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

From: Michael A. Wingfield <wingfiel at BBN-RSM>
Subject: TCP/IP

Mike,
I have a report which documents the [BBN] unix tcp/ip which I can 
send you.  If you want it, send me your mailing address.

We have not done any work on the software for about 2 years,
so it is probably the same as your 115 tape.  We have no
plans to do anything else to the 11/70 version of tcp/ip.

Thanks,
Mike

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

From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Please add me...

 ...to the TCP-IP distribution.  Are you aware of all the stuff on TCP
and IP in the IEN documents maintained by the NIC (similar to the RFC's,
but relating to the Internetwork Experiment funded primarily by DARPA and
taking place primarily on the ARPANET)?  I suggest that at least some mention
of the IEN's be made in an early issue/message for anyone who is interested
but may not yet know about them.  I don't know of any general distribution
list for notice of new IEN's (I'm on distribution for the IN Experiment group,
though not participating), so many people may not yet be aware of them.

Cheers,
Rich <ZELLICH at OFFICE-3>


------------------------------
[ Here is a repeat of a letter from the V1#1 which describes some RFCs
  availible at SRI-NIC.  -MJM ]

From:  Postel at USC-ISIF

 RFCs 791, 792, and 793 define IP and TCP.  The ARPANET already
supports these protocols.  Many TOPS20s, Unix-es (including VAX)
and MIT-Multics, and UCLAs IBM system, already have these protocols
in use.  Work is in progress to replace all TIPs with TACs that
use IP and TCP.  There are about 10 internet gateways in service
already.  ARPA has set a goal for the complete switchover to IP
and TCP by January 1983.

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

From: James.Gosling at CMU-10A (C410JG40)

The mail standards are documented in RFCs (Requests For Comment) from
the network information center at ISI.  To get a copy of an RFC just ftp
to NIC, log in as user "anonymous", password "guest" and retrieve the file
<NETINFO>RFCnnn.TXT .  nnn is the RFC number, some useful ones are:

	RFC733	Mail message format standard
	RFC754/RFC799	Discussions of internet addressing
	RFC759	Internet mail transfer protocol
	RFC780	Mail transfer protocol

					James.

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

From: lou at UCLA-Security (Lou Nelson)
Subject: New List

I would very much like to be on the TCP/IP mailing list.
I think a good first entry would be the report you compiled
that everyone wanted to see. If it is not available, perhaps
you could do a short summary if it's not too much work.
I'm getting a VAX up at Aerospace Corp. that will run UNIX
in December and currently the only good prospect for getting
it on the net is the BBN TCP/IP that Berkeley is pounding on
as a final debugging measure. I don't understand the way
(which sites) I get to an NCP host from the TCP VAX yet.
Pointers to any RFC or other document that explains that will
be appreciated.

Regards,
Lou Nelson

[ Please reply to TCP-IP@BRL, so all can benefit from any answers  -MJM ]

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

End of TCP-IP Digest
********************

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 81 2:47:30-EDT (Wed)
From:      Mike Muuss <tcp-ip@brl>
To:        tcp-ip at Brl
Subject:   TCP-IP Digest, Vol 1 #2
TCP/IP Digest          Wednesday, 14 Oct 1981      Volume 1 : Issue 2

Today's Topics:
                          Administrative Trivia
                    NCP-to-TCP Transition Deadline!!
             Performance of 3Com "UNET" UNIX TCP/IP Software
                Behind the sceens at 3Com & Stanford PUP
             Final word on BBN PDP-11 TCP/IP Implementation
                  RFCs and IENs  --  How to get to NIC
                            Gateway questions
----------------------------------------------------------------------

From:      Michael Muuss <mike@bmd70>
Subject:   TCP-IP Digest, Plans, etc.

	At this point, everybody who has requested to be added to the
TCP-IP discussion list has been added.  In addition, Jon Postel had a
list for distributing notices about Internetworking changes.  At his
suggestion, I have incorporated that list into the Digest list.  If you
are reading this, and don't want to see any more of these Digests,
please sent a note to TCP-IP-REQUEST@BRL.

	The scope of the Digest will probably exceed the rather specific
"TCP-IP Digest" title, but that is OK by me.  I see this as a forum for
discussing implementation and design problems relating to large scale
networks, and internetworking.  Anything too practical for HUMAN-NETS
is fair game here (at least for now).  But I would hope that discussion
will focus on IP and TCP, because this is where much of the real action
seems to be.

	At the present, I expect to be able to issue one digest per week,
with each issue being (hopefully) 15000 to 30000 characters long,
depending on submissions.  No more mamouth 55K digests (OOPS!).  If the
interest picks up, I can see being able to do as many as 3 per week.
More than that, and I will have to get help, but it will be no problem.

	Already, some people have mentioned that mailing stuff to
"TCP-IP@BRL" might be hard to remember or type.  I will be glad to set
up as many aliases for the list as seem useful.  Everybody:  please
suggest some mnemonic, short aliases!

	I am keeping an archive here on BRL (0/29), and hope to announce
the method by which they can be retrieved, sometime soon.  (However,
we can't permit anonymous login, so it will probably be strange).  If
other sites wish to keep an online copy that can be FTP'ed, please let
me know, and I will summarize for the list.

				Cheers!
				-Mike

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

From: POSTEL at USC-ISIF
Subject: NCP-to-TCP Transition

It is really very important for everyone to notice the deadline for
completing the cutover to IP/TCP and the elimination of NCP from use
in the ARPANET.

The deadline is:  1 January 1983.

That is 14 and a half months from now.  Really not much more than a year.

--jon.

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

From: croft at SRI-UNIX
Subject: UNET at SRI

The SRI Telecommunications Sciences Center has been running the 3COM
UNET software (release 1.5) on two 11/44's for the past few months
and we have been quite pleased.  This is contrary to the false rumor
circulated in the last TCP/IP digest (V1N1).  Both machines run a standard
V7;  installation was very smooth and straightforward, requiring no
hacking of the kernel.  We chose the 3COM software over BBN's "free"
V6 TCP for just this reason.  One of 11/44's is on the ARPANET as
SRI-PRMH (packet radio measurement host).  A locally written device
driver for UNET provides TCP/NCP multiplexing of the single 1822
interface.  The other 11/44 is currently being used in a packet radio
experimental network at Fort Sill, Oklahoma.  The device driver in the
latter case speaks CAP5 protocol over an 1822 interface to the radio.

Throughput of the ARPANET version seems to be quite good (compared to
the V6 BBN):  20K bits/second on an FTP to ourselves with the packets
looping all the way out the 1822 and back in again.  Of course UNET
is doing twice as much work here as normal and one would expect
perhaps 40K bps if two UNETs were FTPing thru the same IMP.

Although UNET is certainly the fastest PDP11 TCP around, it still has
the thruput constraints inherent in any TCP.  (See the excellent
article by Bunch and Day of DTI: "Control Structure Overhead in
TCP").  3COM claims 100K bps max thruput for their TCP on DEC hardware.
I think a previous digest entry mentioned 50 to 60K average thruput on
DA11 hardware (DA's are about 8Mbps devices).  My beef is that with
simpler protocols one should be able to do much better.  As an example
I mention the UNIX network at Purdue University EE department.  
It uses 1M bps DMC and DMR link hardware and achieves 400K end to
end process usable bandwidth.  Perhaps TCP's on a fast local network
should support some simpler subset of the protocol as an option to
allow improved thruput.

	--Bill Croft (croft@sri-unix)

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

From: Bill Nowicki <CSD.NOWICKI at SU-SCORE>
Subject: Re:   Re:  TCP/IP for UNIX

I know Bob Metcalfe, Ron Crane, Bruce Borden, and Greg Shaw either directly
or indirectly; these are the main movers behind 3COM.  Bob invented Ethernet
at Xerox, with Ron designing some of their controllers.  Bruce and Greg are
Unix wizards, so between them there is a lot of expertise.  3COM has been
targetting their marketing to small systems (11s and even Onyxes), and since 
we (Stanford) have mostly Vaxes and 20s, we are pressured into going with
BBN's implementation because it was Arpa-sponsored.

By the way, we are currently using the PUP Internetwork architecture at
Stanford, which Metcalfe had a hand in designing.  It was quite a step
for him to adopt the DOD Internetwork architecture for the sake of
standardization.  A welcome change from the "not invented here"
syndrome.
	-- Bill

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

From: Michael A. Wingfield <wingfiel at BBN-RSM>
Subject: TCP/IP

Mike,
I have a report which documents the [BBN] unix tcp/ip which I can 
send you.  If you want it, send me your mailing address.

We have not done any work on the software for about 2 years,
so it is probably the same as your 115 tape.  We have no
plans to do anything else to the 11/70 version of tcp/ip.

Thanks,
Mike

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

From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Please add me...

 ...to the TCP-IP distribution.  Are you aware of all the stuff on TCP
and IP in the IEN documents maintained by the NIC (similar to the RFC's,
but relating to the Internetwork Experiment funded primarily by DARPA and
taking place primarily on the ARPANET)?  I suggest that at least some mention
of the IEN's be made in an early issue/message for anyone who is interested
but may not yet know about them.  I don't know of any general distribution
list for notice of new IEN's (I'm on distribution for the IN Experiment group,
though not participating), so many people may not yet be aware of them.

Cheers,
Rich <ZELLICH at OFFICE-3>


------------------------------
[ Here is a repeat of a letter from the V1#1 which describes some RFCs
  availible at SRI-NIC.  -MJM ]

From:  Postel at USC-ISIF

 RFCs 791, 792, and 793 define IP and TCP.  The ARPANET already
supports these protocols.  Many TOPS20s, Unix-es (including VAX)
and MIT-Multics, and UCLAs IBM system, already have these protocols
in use.  Work is in progress to replace all TIPs with TACs that
use IP and TCP.  There are about 10 internet gateways in service
already.  ARPA has set a goal for the complete switchover to IP
and TCP by January 1983.

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

From: James.Gosling at CMU-10A (C410JG40)

The mail standards are documented in RFCs (Requests For Comment) from
the network information center at ISI.  To get a copy of an RFC just ftp
to NIC, log in as user "anonymous", password "guest" and retrieve the file
<NETINFO>RFCnnn.TXT .  nnn is the RFC number, some useful ones are:

	RFC733	Mail message format standard
	RFC754/RFC799	Discussions of internet addressing
	RFC759	Internet mail transfer protocol
	RFC780	Mail transfer protocol

					James.

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

From: lou at UCLA-Security (Lou Nelson)
Subject: New List

I would very much like to be on the TCP/IP mailing list.
I think a good first entry would be the report you compiled
that everyone wanted to see. If it is not available, perhaps
you could do a short summary if it's not too much work.
I'm getting a VAX up at Aerospace Corp. that will run UNIX
in December and currently the only good prospect for getting
it on the net is the BBN TCP/IP that Berkeley is pounding on
as a final debugging measure. I don't understand the way
(which sites) I get to an NCP host from the TCP VAX yet.
Pointers to any RFC or other document that explains that will
be appreciated.

Regards,
Lou Nelson

[ Please reply to TCP-IP@BRL, so all can benefit from any answers  -MJM ]

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

End of TCP-IP Digest
********************

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed Oct 14 21:05:05 1981
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #1

>From tcp-ip@brl Wed Oct 14 20:35:46 1981
TCP/IP Digest            Thursday, 8 Oct 1981      Volume 1 : Issue 1

Today's Topics:
                         A new Discussion Group
      Gateway Connection Policy -- TCP and IP Protocol Definitions
       Comments on TCP4 from BBN -- SRI Networks Development Group
              EDN-UNIX TCP/IP Notes -- 3Com TCP/IP Troubles
      NALCON Conversion Meeting -- BRL TCP/IP Environment (Planned)
       BBN VMUNIX (4.1BSD) TCP/IP -- BBNCC C/30 Features & Futures
          UTexas TCP4 (BBN) Mods -- 3Com TCP/IP:  A Happy User
  Internet Gateway & Computer List -- TCP/IP Implementation Status Overview
            Are PDP-11's Dead? -- 3Com TCP/IP:  More comments
                    BBN TCP/IP for VAX:  Manual Page
----------------------------------------------------------------------

From: Michael Muuss <Mike @ BRL>
Subject: A New Discussion Group

Greetings Earthlings!
	This is the first issue of a new digest which purports to discuss
TCP and IP, the "DoD Standard Networking Protocols for the Eighties". 
Comments will probably center around UNIX implementations, but any
technical networking or implementation discussions too specific for
HUMAN-NETS is fair game here.  Please send submissions to "TCP-IP @ BRL",
requests to "TCP-REQUEST @ BRL" or "TCP-IP-REQUEST @ BRL".

	This is sort of a spur-of-the-moment thing;  it started with our
trying to find out about TCP/IP iplementations, and wound up with dozens
of letters asking for a report of what I found.  This list may die
stillborn, or it may flurish.  Only time will tell!
				Cheers,
				 -Mike

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

Date: 1 Oct 1981 1022-PDT
Sender: WESTINE at USC-ISIF
From: Postel@isif

1)  The question about connection policy should be directed to
DCA or your site's ARPANET sponsor.  But my guess at an answer
is "For a site with a host on the ARPANET (properly authorized)
there should be no additional policy issues in connecting a local
network to the ARPA Internet when the purpose and use of the local
net is the same as for the existing host."

2)  The question about IP and TCP is correctly addressed to me.
 RFCs 791, 792, and 793 define IP and TCP.  The ARPANET already
supports these protocols.  Many TOPS20s, Unix-es (including VAX)
and MIT-Multics, and UCLAs IBM system, already have these protocols
in use.  Work is in progress to replace all TIPs with TACs that
use IP and TCP.  There are about 10 internet gateways in service
already.  ARPA has set a goal for the complete switchover to IP
and TCP by January 1983.

--jon.

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

Date:  2 Oct 1981 0520-PDT
From: DEDWARDS at USC-ISI

BBN (of course) has a TCP 4 up and running written in C.  Its slow
and large (mainly due to the fact that it is entirely outside
the kernelrunning as a user pgm with only a device driver in the
kernel.  Jack Haverty (JHAVERTY at BBN) or Mike Wingfield
(wingfield at BBN-UNIX or BBN-RSM) can say lots more.

Howard Weiss

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

Date:  2 Oct 1981 0702-PDT
From: NRL at USC-ISIE

	For you information the below message was
received by us in late September 1981; you may find in useful.

Regards,
Doug Shannon - ARPAnet mailbox - NRL@ISIE

			- - - - - - - - -

The Networks Development group at SRI can offer assistance in the
development or operations support of one or more of the following:

 - modernizing the NALCON sites UNIX from Version 6 to Version 7 (the
   current release from BTL);
 - 96-bit leader NCP software required to address all hosts on the ARPANET; 
 - DoD standard TCP/IP network software with Version 7 UNIX and 
   associated user software such as TCP-FTP, MTP (Mail Transfer Protocol),
   TELNET, etc.;
 - TCP/NCP mail gateway software to facilitate transition from NCP to TCP;
 - a VDH Front-End which would remove the overhead associated with
   the Very Distant Host protocol off of UNIX; 
 - other areas related to UNIX and network systems.

The Networks Development group at SRI specializes in the development 
of local and long-haul network software, hardware, and protocols.
There are currently 8 UNIX systems in operation at SRI, most of which are 
attached to our local area network and/or the ARPANET.

If you would like to discuss your needs and how we can assist you in any of
the mentioned areas, please contact me at:

Geoff Goodfellow
333 Ravenswood Ave.
Menlo Park, CA. 94025
(415) 859-3098
ARPANET: Geoff@SRI-CSL

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

Date:  2 Oct 1981 13:38:33 EDT
From: Edward A. Cain <cain@EDN-UNIX>

Our TCP/IP is an extension of the one on the 11/70 at BBN, in case you
have already heard from them. It runs on V6 here, and on V7 at BBN.
Both machines support two interprocess communication mods to UNIX in
order to allow the tcp/ip to work: (a) Rand "ports", with supporting
"await" and "capacity" system calls, or (b) shared memory. The user-to-
tcp interface can employ either of these techniques.

Our extensions to that work include: (a) handling GGP or ICMP packets,
and (b) reassembly of fragments within IP.

You're welcome to the sources, manual pages, and UNIX hacks needed to
make them work -- if you are using an 11/70. If you have some other
machine like the C/70 or a vax, better get in touch with someone at
BBN. Their active work on tcp/ip has centered around those 2 machines
over the past couple of years. Jack Haverty is one point of contact
(haverty at bbn-unix).

I recall an SRI status report on the 3-com stuff just last week. Seems
the 3-com tcp/ip is full of bugs, and 3-com is under no obligation to
fix things under the license agreement. However, SRI (one of 3-com's
customers) has been able to get some fixes out of 3-com. Sounds kind of
risky.

Ed Cain

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

Date: Fri, 2 Oct 81 16:31-PDT
From: Greg at NPRDC

Indeed, we all are [Converting to TCP/IP] in a year or so.  Geoff@SRI-CSL
has offered to help the NALCON sites convert; maybe we can all get
together and reduce our mutual costs.  We're trying to set up a meeting
to talk about it, probabally in the DC area; would you be interested in it?

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

Date:      2 Oct 81 20:45:01-EDT (Fri)
From:      Michael Muuss <mike@bmd70>
To:        Greg at NPRDC

We will probably be building an extensive local network which will
initially include such varried systems as a CDC 7600 (SCOPE), CDC 173 (NOS),
40 MIPS HEP (UNIX, probably!), zillions of 11/70s and 11/34s, PE 3240s, C/70s,
etc, and using Hyperchannels, PCL-11Bs, DQ-11s, UMC-11s, .... for
communications.  In my opinion, only a "standard" protocol like TCP
will permit a plan like this to succeed (!).

			Networking forever!
			     -Mike

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

Date:  5 Oct 1981  9:24:30 EDT (Monday)
From: Rob Gurwitz <gurwitz at BBN-RSM>

Jack Haverty passed your inquiry about TCP/IP along to me.  In addition to the
experimental TCP/IP that was done for the 11's (which you may or may not
already have), we have been developing a version for the VAX running Berkeley
4.1BSD UNIX.  This software is a full implementation of the protocols and is 
completely independent of any of the old U of I NCP code (including the RMI).
It allows access at the TCP, IP, or local network access levels.  The software
is currently running and under test at several sites, including Berkeley.  When
it is generally released (probably around the first of the year), it will be
available through Berkeley and will be included as part of a future 4.xbsd
distribution.  The configuration currently supports ARPANET 1822 local net
protocol and a driver for the ACC LH/DH-11 IMP i/f, but work is also going on
to develop other local net drivers (i.e., ETHERNET) for it.

Rob Gurwitz

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

Date:      2 Oct 81 18:48:08-EDT (Fri)
From:      Michael Muuss <mike@bmd70>
To:        Paul Santos <Santos@bbne>
Subject:   C/30 Features & Futures

Just out of curiosity, I have some questions about our nice shiney new C/30.

1)  How difficult is it to change a DISTANT host interface to a LOCAL
host interface.  It it a switch, a board, or a big deal?  Could you
estimate the cost of doing this?  Our liason's crystal ball must have
been a little cloudy...

2)  Just for kicks, is it possible for a C/30 to support either (a) more
than 4 modem lines, and/or (b) run the trunk lines at more than 50Kb?

3)  Is there any provision for more than one trunk to connect between two
C/30's to improve transmission between them?

	We are doing a lot of planning here on networking, and are
strongly considering using TCP/IP.  What can you tell me about (or point
me to) how BBN plans to proceed with TCP, and how will this affect
the ArpaNet?

				Cheers,
				 -Mike
------------------------------

Date:  4 Oct 1981 16:10:25 EDT (Sunday)
From: Paul Santos <santos at BBN-UNIX>
To: Michael Muuss <mike.bmd70 at BRL>

Mike,

I have forwarded your message to Nancy Mimno, who is the primary point
of contact for ARPANET users.  I believe the answers are in brief:
1) Easy, 2)(a) in progress, 2)(b) already exists, and 3) has been
thought of but not currently planned.  As for TCP/IP, it is a host
isssue, and does not directly affect the subnetwork;  however, DCA
and ARPA (and DoD in general) are pushing on TCP and plan to outlaw
NCP someday.

Paul

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

Date:  5 Oct 1981 at 0945-CDT
From: roya at UTEXAS-11 (roya)

	I have been working on TCP/IP BBN version 4 in our PWB-UNIX
System. There were and are some problems that I'm trying to fix in
it.  Let me know if I can be any help to you.

						Roya
------------------------------

Date: 7 Oct 1981 11:38:55-PDT
From: menlo70!sytek!zehntel!billn at Berkeley

We have been running it [3Com] for a short time between two 70's hooked up via
an able da-11.  With unloaded systems we get about 60kb during file
transfer.  With one heavily loaded system and one lightly loaded one
we get about 45kb.  We run 2.?bsd and had a few problems, not many,
during installation.  Our problems were due to the fact that, as the
previous msg said, it IS big.  They have tried v. hard to make it a 
"drop in" product, and have done a good job, but the 2.?bsd systems
are just too huge, as normally run, to avoid some hacking during
installation.  (3com is now more experienced in 2.?bsd-ese than they
were...)  It seems relatively bug free and robust.  Our general users have
not been unleashed on it yet -- that'l be the really telling blow.
/b

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

Date:  5 Oct 1981 1358-PDT
From: POSTEL at USC-ISIF
To:   mike.bmd70 at BRL

< INC-PROJECT, IN-HOST-TABLE.NLS.25, >, 27-May-81 16:52 JBP ;;;;
ADDRESSES
   The internet addresses in this memo are stated as four 8-bit fields 
   with the value of each field given in decimal.
GATEWAYS
   Name             Addresses
   ---------------  --- --- --- ---  --- --- --- ---
   DCEC-EDN/ARPA     21   0   0   2   10   3   0  20
   MIT-LCS/ARPA      18   8   0   4   10   0   0  77
   BBN-RCC/ARPA       3   2   0   5   10   2   0   5
   BBN-SAT/ARPA       4   0   0  61   10   3   0  40
   NDRE-SAT/ARPA      4   0   0  38   10   3   0  41
   COMSAT-SAT/COMSAT  4   0   0  39   29   0   2   2
   UCL-SAT/UCL        4   0   0  60   11   3   0  42
   UCL-SAT/NULL       4   0   0  60   35   7   0   0
   UCL-UCL/RSRE      11   3   2  42   25   6   0   0
   RSRE-NULL/PPSN    35   6   0   0   25   6   0   0
   RSRE-NULL/PPSN    35   6   0   0   25  13   0   0
   SRI-PR1/ARPA       2   0   0  11   10   3   0  51
   SRI-PR2/ARPA       6   0   0  11   10   1   0  51
   BBN-BBNPR/ARPA     1   0   0  11    3   0   0  62
   Bragg-BraggPR/ARPA 9   0   0  11   10   0   0  38
COMPUTERS
   Name            Address
   --------------- --- --- --- ---
   ALTA-COMA         3   1   0  50
   BBN-UNIX         10   0   0  63
   BBN-VAX          10   2   0  82
   BBNA             10   3   0   5
   BBNB             10   0   0  49
   BBNC             10   3   0  49
   BBND             10   1   0  49
   BBNE             10   0   0   5
   BBNF              3   2   0  51
   BBNG             10   1   0   5
   EDN-HOST1        21   1   0   1
   EDN-HOST3        21   0   0   3
   EDN-UNIX         10   3   0  20
   ISIB             10   3   0  52
   ISIC             10   2   0  22
   ISID             10   0   0  27
   ISIE             10   1   0  52
   ISIF             10   2   0  52
   MIT-DevMultics   10   4   0  31
   MIT-Multics      10   0   0   6
   UCLA-CCN 3033    10   1   0   1

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

Date:  5 Oct 1981 1544-PDT
From: POSTEL at USC-ISIF

BBN C/70 UNIX

   Date:  14 May 1981 
   From:  Jack Haverty <haverty@BBN-UNIX>

   The C/70 processor is a BBN-designed system using C as its native 
   mode.  It supports Version 7 of UNIX, and provides for user processes
   with 20-bit address spaces.  The TCP/IP for this machine is in 
   development; the BBN VAX-11/780 UNIX implementation will be ported to
   the C/70 UNIX system.  This work is expected to be complete in summer
   '81.

BBN GATEWAYS

   Date:  8 May 1981
   From:  Ginny Strazisar <Strazisar@BBNA>

   This is a status report on the implementation of the Internet 
   Protocol in these gateways:

      the ARPANET/SATNET gateway at BBN (10.3.0.40),
      the ARPANET/SATNET gateway at NDRE (10.3.0.41),
      the Comsat DCN Net/SATNET gateway at COMSAT (4.0.0.39),
      the SATNET/UCL Net/RSRE Net gateway at UCL (4.0.0.60),
      the PR Net/RCC Net gateway at BBN (3.0.0.62),
      the PR Net/ARPANET gateways at SRI (10.3.0.51, 10.1.0.51),
      and the PR Net/ARPANET gateway at Ft. Bragg (10.0.0.38).

   The gateways forward packets with internet header formats as 
   specified in the DoD Standard Internet Protocol, January, 1980.  The 
   gateways implement this Internet Protocol with the following 
   exceptions:

   1.  The type of service field is ignored, i.e., the gateways use the 
   same type of service in each network regardless of the value of the 
   internet type of service field.

   2.  No options are implemented.  Packets containing options are 
   forwarded by the gateways, subject to the specified constraints, 
   i.e., correct checksum, correct length, non-zero time to live field, 
   but the gateways do not process any options.  Packets with options 
   are not fragmented.  If a packet is too large to be sent through the 
   next network on the route to its destination and it contains options,
   then the packet is discarded.

BBN H316 and C/30 TAC

   Date:  14 May 1981
   From:  Bob Hinden <Hinden@BBNE>

   The Terminal Access Controller (TAC) is user Telnet host that 
   supports TCP/IP and NCP host to host protocols.  It runs in 32K H-316
   and 64K C/30 computers.  It supports up to 63 terminal ports.  It 
   connects to a network via an 1822 host interface.

   The TAC's TCP/IP is intended to conform with the IEN-128 and IEN-129 
   specifications with the following exceptions: 1) IP options are 
   accepted but ignored. 2) TCP options are not accepted. 3) Precedence,
   Security, etc. are ignored.

   The TAC also supports Packet core, TAC Monitoring, Internet Control, 
   and a subset of the Gateway-Gateway protocols.

   For more information on the TAC's design, see IEN-166.

   Currently, TAC's TCP/IP has been tested with several other 
   implementations. This includes TOPS20 (BBND, BBNC, BBNA, ISID), 
   Multics (MIT-Multics), IBM (UCLA), 11/70 Unix (BBN-Unix,EDN-Unix), 
   and VAX Unix (BBN-VAX). All major features have been implemented 
   except IP reassembly and TCP Urgent handling.  These will be done in 
   the near future.

BBN HP-3000

   Date:  14 May 1981
   From:  Jack Sax <sax@BBN-UNIX>

   The HP3000 TCP code is in its final testing stages.  The code 
   includes under the MPE IV operating system as a special high priority
   process.  It is not a part of the operating system kernel because MPE
   IV has no kernel.  The protocol process includes TCP, IP, 1822 and a 
   new protocol called HDH which allows 1822 messages to be sent over 
   HDLC links.  The protocol process has about 8k bytes of code and at 
   least 20k bytes of data depending on the number of buffers allocated.

   The TCP code is believed to support all features except rubber EOL.  
   The IP code currently supports fragment reassembly but not 
   fragmentation.  In addition provisions have been made to allow the IP
   layer to accept and act on routing and source quench messages.  These
   features will be added sometime this summer.  Security and precedence
   are currently ignored.

   In addition to the TCP the HP3000 has user and server TELNET as well 
   as user FTP.  A server FTP may be added later.

   A complete description of the implementation software can be found in
   IEN167.

BBN PDP 11/70 UNIX

   Date:  14 May 1981
   From:  Jack Haverty <haverty@BBN-UNIX>

   This TCP implementation was written in C.  It runs as a user process 
   in version 6 UNIX, with modifications added by BBN for network 
   access.  It does not perform reassembly, or rubber eol, and has no 
   separate IP user interface.  It supports user and server Telnet.

   This implementation was done under contract to DCEC.  It is installed
   currently on several PDP-11/70s and PDP-11/44s. Contact Ed Cain at 
   DCEC <cain@EDN-UNIX> for details of further development.

BBN TENEX & TOPS20

   Date:  13 May 1981
   From:  Charles Lynn <CLynn@BBNA>

   TCP4 and IP4 are available for use with the TENEX operating system 
   running on a Digital KA10 processor with BBN pager.  TCP4 and IP4 are
   also available as part of TOPS20 Release 3A and Release 4 for the 
   Digital KL10 and KL20 processors.

   Above the IP layer, there are two Internet protocols within the 
   monitor itself (TCP4 and GGP).  In addition up to eight (actually a 
   monitor assembly parameter) protocols may be implemented by user-mode
   programs via the "Internet User Queue" interface. The GGP or 
   Gateway-Gateway Protocol is used to receive advice from Internet 
   Gateways in order to control message flow.  The GGP code is in the 
   process of being changed.

   TCP4 is the other monitor-supplied protocol and it has two types of 
   connections -- normal data connections and "TCP Virtual Terminal" 
   (TVT) connections.  The former are used for bulk data transfers while
   the latter provide terminal access for remote terminals.

   Note that TVTs use the standard ("New") TELNET protocol.  This is 
   identical to that used on the ARPANET with NCP and in fact, is 
   largely implemented by the same code.

   At the IP level, fragmentation and reassembly are not currently 
   supported.  The Autodin II Security related option can be parsed, but
   no code for doing preemption of resources has been writen. Certain 
   other security-related options are implemented.

   User and Server FTP processes above the TCP layer are under active 
   development.

BBN UNIX

   Date:  1 May 1981
   From:  Mike Wingfield <Wingfield@BBND>

   1. Hardware - PDP-11 running UNIX version 7, with BBN IPC additions.

   2. Software - written in C, requiring 22K instruction space, 15K data
   space.  Supports 10 connections.

   3. Status - TCP has been essentially completed since March, 1979, and
   no additional work has been done on it since then.

   4. Unimplemented protocol features

      A. TCP
         Does not support Rubber EOL
         Ignores options except S/P/T
         Discards out-of-order segments

      B. IP
         Does not support fragmentation or reassembly.
         Ignores options

   5. Documentation - "TCP/PSIP Development Report", and "TCP Software 
   Documentation", both BBN reports.

BBN VAX

   Date:  7 May 1981
   From:  Rob Gurwitz <Gurwitz@BBN-UNIX>

   The VAX TCP/IP implementation is written in C for Berkeley/VMUNIX.  
   It is described in detail in IEN168.  It is currently operational 
   experimentally and is undergoing further development.

   The implementation is believed to conform to the specification with 
   the following exceptions:

   1) All internet options are currently ignored.

   2) Security, precedence, etc. are ignored.

   The TCP/IP is implemented within the kernel.  It supports all aspects
   of the protocol, and provides a separate user interface at the IP 
   level.

   Continuing development includes implementation of handling internet 
   routing messages, hosts on multiple networks, and performance 
   improvement.  Tools are available on the VAX for monitoring and 
   recording net traffic.

COMSAT

   Date:  30 Apr 1980
   From:  Dave Mills <Mills@ISIE>
   

   1. The TCP/IP implementation here runs in an LSI-11 with a homegrown 
   operating system compatible in most respects to RT-11. Besides the 
   TCP/IP levels the system includes many of the common high-level 
   protocols used in the ARPANET community, such as TELNET, FTP and 
   XNET.

   2. Connections have been verified with the following other 
   implementations:

      TOPS-20 (BBNF, ISID, ISIE and ISIF)
      Unix (BBN, NPL and EDN)
      Multics (MIT-Multics)
      IBM 3033 (CCN)
      Packet Radio TIU (UCL, RSRE)
      and the several hosts on the COMSAT local net (DCNET) running the 
      the same software.

   3. The TCP implementation is believed to conform to the specification
   in all aspects except:

      a. It does not implement the rubber-EOL mechanism. All buffers 
      appear a single octed in length.

      b. It does not implement the urgent mechanism.

   4. The IP implementation is believed to conform to the specification 
   in all respects except:

      a. Fragmentation and reassembly is not implemented.

      b. All options, including security, timestamping, etc., are 
      ignored by the IP layer. Timestamping is handled by the protocol 
      and user layers. Other options can be specified by the protocol 
      and user layers and checked by the protocol layer.

   Our plans for the remainder of the FY80 and FY81 years are to upgrade
   the implementation to conform to the full specification in all 
   practicable respects and, especially, to evaluate overall performance
   in systems involving both high-performance and limited-performance 
   hosts and nets.

DTI VAX

   Date:  15 May 1981
   From:  Gary Grossman <grg@DTI)>

   Digital Technology Incorporated (DTI) IP/TCP for VAX/VMS

   The following describes the IP and TCP implemenation that DTI plans 
   to begin marketing in 4th Quarter 1981 as part of its VAX/VMS network
   software package.

   Hardware:  VAX-11/780 or /750.

   Operating System:  DEC standard VAX/VMS Release 2.0 and above.

   Implementation Language:   Mostly C, with some MACRO.

   Protocol Features Supported:

      IP:

         Fragementation/Reassembly:  Does not fragment, but does 
         reassemble.

         Options:  Security option is both generated and interpreted.

         Packet identifier:  Can be specified by user, but will generate
         a unique identifier if user does not supply one.

         Reassembly timeout:  Fixed value.  If buffers fill up, oldest 
         fragment is discarded first.

         Gateway functions:  All necessary GGP functions will be 
         implemented. (GGP functions are not implemented in current NFE 
         IP.)

         Type of Service:  As for Gateway functions.

         Support of protocols other than TCP:  Yes, simultaneously with 
         TCP.

      TCP:

         Precedence and security fields:  Both generated and 
         interpreted.

         TCP options:  All defined options are implemented.

         Urgent:  Implemented as per specification.

         EOL:  As per specification.

         Buffer size:  Option implemented; user may specify buffer size 
         within limits.

         Retransimission:  Timeouts employ exponential backoff until a 
         limit is reached, at which time user is signalled. Transmits 
         empty packets into a zero window.

         Initial sequence number:  Derived from 32-bit system clock with
         10 us. resolution.

         Window strategy:  Window size is larger than the actual buffer 
         space available by the size of the maximum size internal 
         buffer.

         ACK generation:  ACK is sent as soon as data has been placed in
         sequence into user buffer.

   Code size:

      IP (Includes BBN 1822 interface code, about 30%):

         Object code:            14K bytes.
         Buffer and table space: 24K bytes.
         Source:                  7K lines of C code with commentary.

      TCP:

         Object code:            27K bytes.
         Buffer and table space: 46K bytes.
         Source:                 15K lines of C code with commentary.

   Fixed table space:  See above.

   Connections supported:  Maximum of 64.

   User level protocols available:  TELNET, FTP, and MTP will be 
   available. (The NFE version uses AUTODIN II protocols.)

MIT MULTICS

   Date:  13 May 1981
   From:  Dave Clark <Clark@MIT-Multics>

   Multics TCP/IP is implemented in PL/1 for the HISI 68/80. It has been
   in experimental operation for about 18 months; it can be distributed 
   informally as soon as certain modifications to the system are 
   released by Honeywell.  The TCP and IP package are currently being 
   tuned for performance, especially high throughput data transfer.

   It is believed that the implementation fully conforms to the DOD 
   standard.  It also supports most relevant features of GGP, including 
   redirect packets. The IP layer is a gateway, and supports 
   fragmantation as well as reassembly.

   Higher level services include user and server telnet, and a full 
   function MTP mail forwarding package.

   The TCP and IP contain good logging and debugging facilities, which 
   have proved useful in the checkout of other implementations. Please 
   contact us for further information.

SRI LSI-11

   Date:  15 May 1981
   From:  Jim Mathis <mathis.tscb@Sri-Unix>

   The IP/TCP implementation for the Packet Radio terminal interface 
   unit is intended to run on an LSI-11 under the MOS real-time 
   operating system.  The TCP is written in MACRO-11 assembler language.
   The IP is currently written in assembler language; but is being 
   converted into C. There are no plans to convert the TCP from 
   assembler into C.

   The TCP implements the full specification, although the current user 
   interface lacks a mechanism to communicate URGENT pointer information
   between the TCP and the higher-level software.  The code for 
   rubber-EOL has been removed in anticipation of a change to the 
   specification.  The TCP appears to be functionally compatible with 
   all other major implementations.  In particular, it is used on a 
   daily basis to provide communications between users on the Ft. Bragg 
   PRNET and ISID on the ARPANET.

   The IP implementation is reasonably complete, providing fragmentation
   and reassembly; routing to the first gateway; and a complete 
   host-side GGP process.  Currently the source quench message is 
   ignored. No IP options are generated and all received options are 
   ignored.

   A measurement collection mechanism is currently under development to 
   collect TCP and IP statistics and deliver them to a measurement host 
   for data reduction.

    

UCLA  IBM

   Date:  13 May 1981
   From:  Bob Braden <Braden@ISIA>

   Implementation Status -- IP/TCP for IBM 360/370 under OS/MVT. May 12,
   1981

   1. Hardware

      IBM 360 or 370, with a "Santa Barbara" interface to the IMP.

   2. Operating System

      OS/MVS with ACF/VTAM.  An OS/MVT version is also available.

      The UCLA NCP operates as a user job, with its own internal 
      multiprogramming and resource management mechanisms.

   3. Implementation Language

      BAL (IBM's macro assembly language)

   4. Protocol features supported:

      A. IP PROTOCOL:

         (1) Fragmentation/reassembly: performs reassembly.  Does not 
         fragment, assuming that higher-level protocol (TCP) will create
         suitable size segments during packetizing.

         (2) Options: all internet options accepted but ignored.  None 
         are sent (in particular, no error options).

         (3) Identifier selection: uses globally-unique identifiers for 
         transmitted segments, independent of destination.

         (4) Reassembly timeout:  fixed value (30-60 seconds), 
         independent of time-to-live field.  Packets are discarded if 
         time-to-live field is zero.

         (5) Gateway functions:  Unable to select an alternate route 
         (gateway) if the original route fails.  Does accept GGP, and 
         acts on Redirect, Destination Unreachable, and Echo packets.  
         Source Quench is ignored.

         (6) Type of Service: default Type of Service set, may cause 
         either Subtype 0 or Subtype 3 (Uncontrolled) packets to be 
         sent.

      B. TCP PROTOCOL:

         (1) Precedence, security fields: not set or tested.

         (2) TCP Options: no options generated.  All options received 
         but only Buffer Size is acted upon.

         (3) Urgent: may be sent and received by user process.

         (4) EOL: may be sent by user process, but received EOL's are 
         not passed to user process.

         (5) Buffer Size: will transmit according to specified buffer 
         size.  Uses circular buffer for received data, so never 
         specifies a buffer size to remote TCP.

         (6) Retransmission: successive retransmissions use exponential 
         backoff.  Base time is 2 times observed weighted-average 
         round-trip time.  Round-trip time is measured by initial packet
         transmission to complete acknowledgment. Retransmits slowly 
         into zero window.

         (7) Initial Sequence Number: derived from system clock.

         (8) Window strategy: uses conservative strategy, never adver- 
         tising a receive window larger than the space available in the 
         circular buffer.

         (9) ACK generation: always sends <ACK> in response to receipt 
         of a non-empty packet.  As user process removes bytes from 
         buffer,  optimizing algorithm determines when to generate <ACK>
         to inform sender of larger window.

   5. Code Size (addition to existing NCP code)

      Resident Control Process:          4K bytes.

      Internet Protocol Layer:          10K bytes. (transient)

      TCP Protocol Layer:               10K bytes. (transient)

   6. Fixed Table Space

      The limited fixed table space is included in the code (above).

   7. Connections Supported:

      Only practical limitation is amount of memory available in NCP 
      region for buffers and per-connection control blocks; requirements
      are:

         For each connection, the internet and TCP layers require 
         control blocks totalling 256 bytes.

      (*) Receive:

         Segment reassembly buffer=
         max segment size - min internet header length + 16= 572 bytes 
         per buffer.

      (*) Send:

         128 bytes per unacknowledged segment.

         Note: the actual data being sent is not counted here, as it 
         occupies buffer space belonging to the appropriate user-level 
         protocol module.

            (*)Note: there is a pool of these objects, shared among all 
            active connections.  The pool grows and shrinks dynamically 
            with the number of connections; it is probably reasonable to
            expect an average of one segment reassembly buffer and one 
            unacknowledged segment (total of 700 bytes) per TCP 
            connection.

      In addition to this TCP-specific memory, there is the memory to 
      support the user-level protocol.  For example, a server-Telnet 
      session to TSO requires control blocks and buffers totalling about
      1800 bytes; this is identical for TCP and for the ARPANET 
      Host-Host ("NCP") protocol.

   8. User-Level Protocols Available

      User and Server Telnet

   9. Philosophical Remarks

      This implementation of the Internet and TCP protocols is designed 
      to meet the following general objectives:

         (a) operate within the existing NCP system job, sharing code 
         and control-block formats wherever possible;

         (b) be compatible at the system-call level with the existing 
         user-level protocol modules;

         (c) implement the Internet protocol as a distinct layer, with 
         interfaces designed to expedite the implementation of other 
         higher-level internet protocols in addition to TCP;

         (d) require minimum NCP resources when internet protocol is not
         in use.

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

Date:      5 Oct 81 20:09:53-EDT (Mon)
From:      Michael Muuss <mike@bmd70>
To:        Rob Gurwitz <gurwitz@bbn-rsm>

Rob -
	Thanks very much for the information about the 4.1 BSD TCP/IP
implementation.  Sounds like a very nice job!  What is the feasibility
of moving it to a PDP-11 UNIX system?  There are some of us who can not
afford to subscribe to the Berkeley "PDP-11s are dead" philosophy...

	Can you feed me any handy dribbles of documentation or overview
information?
				Cheers,
				 -Mike
------------------------------

Date: 3 Oct 1981 00:13:28-PDT
From: ESVAX.clemc at Berkeley
To: csvax.unix-wizards at Berkeley

The 3Com version for the 11 is fairly good.  It is like the old
U of I NCP in that it is not all kernel resident (like the BBN Version).
It IS large.  Tektronix has been using it will 2.8 BSD for a few months
but they have had lots of trouble.  It has been a conbination of sparse
comments in the 3Com code, 2.8 BSD and trying to Talk TCP to a CDC Cyber
on the other end.  They are using Network System's Corp "HYPERchannel"
gear for the physical medium, which is very fast but the 11/70 can not
keep up with it (niether can the cyber when running TCP).

Both BBN and 3Com have used Psuedo TTY's for the Virtual Terminal Protocol.
This has both advantages and disadvantages.   3Com wants to make their
code portable to other UNIX versions.  They are working on/have made to work
a version that runs on an 11/34 with overlays. As far as I know, BBN has
punted the 11's.

Clem

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

Date:  6 Oct 1981 11:32:45 EDT (Tuesday)
From: Rob Gurwitz <gurwitz at BBN-RSM>
To: Michael Muuss <mike.bmd70 at BRL>

There is a note describing the internals of the TCP/IP for the VAX available
from the ARPANET NIC as IEN 168.  In addition, I have manual pages for
the lowest level TCP/IP/local net i/f, if you want them.  The TELNET
and FTP are ports of software that has been around for awhile, so manual
pages for them are probably generally available (you probably already
have them if you're running NCP on an 11).  MTP mail is new, but we have
no manual pages ready yet.

Rob.

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

Date:  7 Oct 1981  9:21:34 EDT (Wednesday)
From: Rob Gurwitz <gurwitz at BBN-RSM>
To: Michael Muuss <mike.bmd70 at BRL>

Here is the manual page for low level TCP access.  I hope it's useful.
Feel free to include info about the implementation in your 
summary.
			Rob.

NET(5)              UNIX Programmer's Manual              NET(5)



NAME
     tcp, ip, rawnet - internet networking software

SYNOPSIS
     open ("/dev/net/net", ncon);

     struct con *ncon;

     struct lhost {                  /* net library format internet address */
            unsigned char l_hoi;            /* host on imp */
            unsigned char l_net;            /* network */
            n_short l_imp;                  /* imp */
     };
                                        /* c_mode field definitions */
     struct con {                    /* user connection structure */
            unsigned char c_mode;           /* mode 0-passive 1-active (see flags) */
            unsigned char c_sbufs;          /* # send buffers to use */
            unsigned char c_rbufs;          /* # rcv buffers to use */
            unsigned char c_prec;           /* precedence */
     #define c_lo c_prec                     /* low raw link or proto # */
            unsigned char c_sec;            /* security level */
     #define c_hi c_sec                      /* hi raw link or proto # */
            unsigned char c_compt;          /* compartment */
            unsigned char c_timeo;          /* tcp open timeout */
            unsigned char c_x;              /* (unused) */
            unsigned short c_lport;         /* local port */
            unsigned short c_fport;         /* foreign port */
            struct lhost c_con;             /* foreign socket */
     };

     struct netstate {               /* network status structure */
            unsigned char n_lolink;         /* low link no. in range (IP, RAW) */
            unsigned char n_hilink;         /* high link no. in range (IP, RAW) */
            unsigned char n_snd;            /* # send bufs allocated */
            unsigned char n_rcv;            /* # receive bufs allocated */
            unsigned char n_ssize;          /* # bufs on send buffer */
            unsigned char n_rsize;          /* # bufs on receive buffer */
            unsigned char n_state;          /* state of this connection */
            unsigned char n_flags;          /* misc. flags (see below) */
            unsigned short n_lport;         /* local port */
            unsigned short n_fport;         /* foreign port */
            struct lhost n_con;             /* foreign socket */
     };

     #define CONACT  1                       /* active connection */
     #define CONTCP  2                       /* open a tcp connection */
     #define CONIP   4                       /* open a raw ip connection */
     #define CONRAW  8                       /* open a raw local net connection */
     #define CONDEBUG 128               /* turn on debugging info */

                                        /* net ioctl definitions */
     #define NETGETS 1                       /* get status */
     #define NETSETD 2                       /* set debugging info */
     #define NETSETU 3                       /* set urgent mode */
     #define NETRSETU 4                      /* reset urgent mode */
     #define NETSETE 5                       /* set EOL mode */
     #define NETRSETE 6                      /* reset EOL mode */
     #define NETCLOSE 7                      /* initiate tcp close */
     #define NETABORT 8                      /* initiate tcp abort */

     #define SIGURG 16               /* urgent signal */

     #ifndef KERNEL                           /* n_flags field definitions */

     #define UEOL    0001                    /* EOL sent */
     #define UURG    0002                    /* urgent data sent */
     #define UDEBUG  0004                    /* turn on debugging info recording */
     #define ULOCK   0010                    /* receive buffer locked */
     #define UTCP    0020                    /* this is a TCP connection */
     #define UIP     0040                    /* this is a raw IP connection */
     #define URAW    0100                    /* this is a raw 1822 connection */
     #define ULISTEN 0200                    /* awaiting a connection */

                                        /* n_state field definitions */
     #define UCLOSED 0000                    /* connection closed */
     #define UCLSERR 0001                    /* error -- connection closing */
     #define UABORT  0002                    /* connection aborted */
     #define UINTIMO 0004                    /* open failed -- init timeout */
     #define URXTIMO 0010                    /* retransmit too long timeout */
     #define URESET  0020                    /* connection aborted due to reset */
     #define UOPERR  0040                    /* open failed -- not enough buffers */
     #define UURGENT 0100                    /* urgent data received */
     #define UNETDWN 0200                    /* connection aborted due to net */

     #endif KERNEL

DESCRIPTION
     The special file /dev/net/net is used to access ARPANET type
     packet-switched  networks  via  the  DoD  standard host-host
     Internetworking   Protocols,   TCP   (Transmission   Control
     Protocol),  and  IP  (Internet  Protocol).   It  also allows
     communication over the local network(s) to which the  system
     is  connected  with "raw" packets, enabling user software to
     do its own communications processing.  Access to the network
     at this level is the most direct form of use.  It is assumed
     that most users will use  higher  level  protocol  programs,
     like  ftp(1)  and telnet(1) to communicate over the network.
     (This  description  assumes  the  reader  is  familiar  with
     ARPANET type communications protocols.)

ESTABLISHING CONNECTIONS
     To establish a connection via TCP or IP, or  to  communicate
     with  raw packets, the open(2) call is given, with the usual
     mode  argument  replaced  by  a  pointer  to  a   connection
     structure,  defined  in /usr/include/con.h. The c_mode field
     of this structure  specifies  what  type  of  connection  is
     desired (TCP, IP, or RAW), and whether or not the connection
     is  to  be  active  (specifying  a  specific  foreign   host
     address), or passive (with no foreign address, implying that
     the connection will be established when any foreign  process
     tries to communicate with the opener).

     The c_sbufs and c_rbufs fields  specify  buffer  allocations
     for   the   send   and  receive  sides  of  the  connection,
     respectively.   If  either  value  is  zero,   the   default
     allocation  will  be  used  for that direction (currently 1K
     bytes).  The user can request up to 4K bytes each  for  send
     and receive directions by varying these parameters between 1
     and 4.

     The c_prec, c_sec, and  c_compt  fields  specify  values  of
     precedence, security level, and compartmentalization for TCP
     connections.   (N.B.   This   feature   is   currently   not
     implemented).  For IP and RAW connections, the c_hi and c_lo
     fields specify a range of IP protocol numbers or  local  net
     dispatch  numbers (e.g., ARPANET link numbers) to watch for.
     Messages falling into this range are queued  for  the  user.
     The  low  end of the range is used in sending messages.  Low
     must be less than or equal to high, and numbers in the range
     must not be in use in any other connection.

     The c_timeo parameter specifies a length of time in  seconds
     to  wait  for connection establishment before aborting (this
     does not apply to passive opens).  If the field is zero, the
     default of 30 seconds is used.

     The remaining fields specify local, and  foreign  ports  for
     TCP,  and  the  foreign host address in net long format (see
     libn(3)). The local port may be  zero,  in  which  case  TCP
     assigns a unique port number to the connection.  The foreign
     port and host address may only be zero for a passive open.

READING AND WRITING
     If the open succeeds, a file descriptor  is  returned  which
     may  be  used  in subsequent reads and writes (see, read(2),
     write(2)). Reads  and  writes  work  as  usual  with  a  few
     exceptions.    A   read  may  return  with  error  condition
     ENETSTAT, which indicates that  some  exceptional  condition
     has been detected.  In this case, a 16 bit value is returned
     to the read buffer, which give the status of the  connection
     that  caused  the  return.  Further status may be determined
     with ioctl(2). (see, NETWORK STATUS).  If the  condition  is
     non-fatal, the read may be re-issued.  Reads may return less
     data than requested if a TCP EOL was detected.   Reads  will
     block if there is no data for the user.  Writes block if the
     amount of  send  buffer  resources  for  the  connection  is
     exceeded.   IP and RAW reads return the appropriate protocol
     leaders along with any data received.  Only one  IP  or  RAW
     message may be received or sent per call.

     In addition to normal TCP reads and  writes,  the  user  may
     wish  to  indicate EOL and URGENT data on writes and receive
     notification of URGENT data sent by the foreign  peer.   EOL
     and  URGENT  are  enabled by issueing the NETSETE or NETSETU
     ioctl calls.  Once set, EOL is sent at the last byte of each
     subsequent  write.   Similarly, the URGENT pointer is set to
     start at the first byte of the next write, and ends with the
     first  byte sent after URGENT mode is disabled.  These modes
     are disabled by  the  NETRSETE  and  NETRSETU  ioctl  calls.
     URGENT  data  is  indicated  by signal SIGURG when the first
     byte is received.  This  signal  is  normally  ignored.   (A
     status flag is also set in the presence of urgent data.)

CLOSING CONNECTIONS
     Normally, the close(2) call is used to close a TCP,  IP,  or
     RAW  connection.   In  each case, it indicates that the user
     will send or receive no more  data.   For  TCP  connections,
     close  initiates  the connection closing protocol, though it
     returns  immediately.    Thus,   the   internal   connection
     structures  persist  until  the  connection  has reached the
     CLOSED state.  For IP and  RAW  connections,  the  close  is
     immediate and deletes all internal structures.

     In addition to close for TCP connections, there is an  ioctl
     call,  NETCLOSE,  which  indicates that the local connection
     will send no more data, but is still able  to  receive  data
     from  the foreign peer.  In this case, subsequent writes are
     illegal and will terminate with errors, but subsequent reads
     will  work  until  the  connection  is closed by the foreign
     peer.

NETWORK STATUS
     There are several ioctl(2)  calls  available  for  receiving
     network  status  information  or initiating certain modes or
     functions.  Most of these calls have been  described  above.
     The  status  call,  NETGETS,  takes a status buffer pointer,
     which points to a  netstate  structure,  illustrated  above,
     which is filled in by the call.

     To summarize, the various ioctl calls are:

     NETGETS   Return network status information to the structure
               pointed at by third argument of ioctl.

     NETSETD   Reset the debugging log to the file  name  pointed
               at  by  the third argument.  The file must already
               exist.  If the argument is zero,  turn  off  debug
               logging (see, DEBUGGING).

     NETSETU   Set urgent mode starting at next byte written (TCP
               only).

     NETRSETU  Reset urgent mode, urgent  pointer  ends  at  last
               byte written (TCP only).

     NETSETE   Set EOL mode,  send  EOL  at  last  byte  of  each
               subsequent write (TCP only).

     NETRSETE  Terminate EOL mode (TCP only).

     NETCLOSE  Start TCP connection close.  User can continue  to
               receive data (TCP only).

     NETABORT  Abort TCP connection.  Foreign peer is  reset  and
               no more data may be sent or received (TCP only).

DEBUGGING
     The network software enables certain trace information to be
     recorded for TCP connections.  This information is logged in
     a single debugging log file.  To enable  this  feature,  the
     CONDEBUG  bit  in  the  c_mode  field of the open connection
     parameter structure must be set.  The default debugging  log
     is /etc/net/tcpdebug. This may be changed or the feature may
     be disabled system wide with the NETSETD ioctl  call.   Only
     the  super-user  may  do  this.  The format of the debugging
     information  is  several  bytes  of  binary  data  per   TCP
     transaction.   The  log may be printed in readable form with
     trpt(1).

DIAGNOSTICS
     The following system error codes may be returned by  network
     system calls:

     ENETSTAT  (35) Network status available (not a fatal  error,
               see READS AND WRITES).

     ENETDWN   (36) Open failed  because  network  connection  is
               unavailable.

     ENETCON   (37) Open  failed  because  there  were  too  many
               connections.

     ENETBUF   (38) No more network buffer space.

     ENETERR   (39) Fatal error from network protocol processor.

     ENETRNG   (40) IP or RAW open failed because the protocol or
               dispatch  number  was  out  of range or already in
               use.  TCP open failed because the  user  tried  to
               open  an  already  existing  connection (i.e., one
               with the identical foreign host address and  local
               and foreign ports).

FILES
     /dev/net/net
     /etc/net/tcpdebug

SEE ALSO
     ftp(1),  telnet(1),  trpt(1),  read(2),  write(2),  open(2),
     close(2), ioctl(2), libn(3)

     R.F.   Gurwitz,   VAX-UNIX   Networking   Support    Project
     Implementation  Description,  DARPA  Information  Processing
     Techniques Office, IEN 168, January, 1981.

     J. Postel  (ed.),  DoD  Standard  Internet  Protocol,  DARPA
     Information  Processing Techniques Office, IEN 128, January,
     1980.

     J. Postel (ed.), DoD Standard Transmission Control Protocol,
     DARPA  Information  Processing  Techniques  Office, IEN 129,
     January, 1980.

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

End of TCP-IP Digest
********************

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 81 20:52:13-EDT (Mon)
From:      Mike Muuss <tcp-ip@brl>
Subject:   TCP-IP Digest, Vol 1 #3
TCP/IP Digest             Monday, 19 Oct 1981      Volume 1 : Issue 3

Today's Topics:
                     Acronyms -- Protocol Documents
          TCP Transition Notes -- Simple Mail Transfer Protocol
                Problems with TOPS-20 TCP Implementation?
                    Throughput Considerations of TCP
                     TCP/IP:  Suitable for MicroPs?

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

From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Acronyms

Apparently there are enough non-net-hackers on the list that I should
explain the acronyms I used in my message in V1#2.

TCP - Transmission Control Protocol
      (see RFC's 791, 792, & 793 for details on TCP and IP)
IP  - Internet [control] Protocol
RFC - Request For Comment; Technical notes requesting comment from the
      ARPANET public (also the only place to find those protocols which
      have been adopted as DCA standards or ad hoc standards).
      The RFC's are numbered and are available from the <NETINFO>
      directory on the SRI-NIC host.  Suggested course of action is to
      first FTP <NETINFO>RFC-INDEX.TXT to see what is available.
IEN - Internet Experiment Note; Similar to RFC's, and available from
      the same place via FTP, but applicable specifically to the DCA/DARPA
      sponsored Internet Experiment work (where TCP & IP originally came
      from).  Suggested course of action is to first FTP IEN-INDEX.TXT to
      see what is available.
FTP - File Transfer Protocol; a network protocol/service whereby users
      can transfer files between/among hosts.  If you're not up on the
      use of FTP, see your friendly local ARPANET Liaison.
NIC - Network Information Center; The friendly people who maintain the
      online information databases such as RFC's, IEN's, lists of ARPANET
      Hosts, Liaisons, and Users, etc.  In addition to supporting the
      net "standard" ANONYMOUS login with password GUEST to obtain the
      files kept in <NETINFO>, they also have a nifty online query system
      available to anyone who can connect to SRI-NIC via TIP or TELNET.
      To use it, first connect to the SRI-NIC host, then login as NIC (no
      password is necessary) and follow the instructions.  The NIC/Query
      system can locate users, hosts, liaisons, and provides much other
      ARPANET information.
      [To find out how to use a TIP or the host TELNET service, see
       your friendly local ARPANET Liaison.]
DARPA - Defense Advanced Research Projects Agency; the friendly folks who
      originally brought you the ARPANET (for whom it is named) and who
      are now funding internet research using the ARPANET as part of their
      laboratory.
DCA - Defense Communications Agency; The not-quite-as friendly folks
      who run the ARPANET for the Dept. of Defense (actually, also very
      friendly, but they have the Gov't Accounting Office (GAO) and every
      other busybody in the country breathing down their necks about what
      all that money is being spent for, so they're inclined to be a bit
      serious about the uses we make of the net).

Cheers,
Rich

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

From: POSTEL at USC-ISIF
Subject: Protocol Documents
To:   TCP-IP-Digest at BRL

In recent years the ARPA Network Research Program has had as one concern
the interconnection of networks.  In the course of this research a
family of protocols suitable for an internetwork environment has
emerged.  The major internet protocol documents have been issued as
RFCs.

The situation has evolved to the point that it is appropriate for the
internet family of protocols to replace the old ARPANET protocols.  To
this end an Internet Protocol Handbook will be prepared by the Network
Information Center.  This Internet Protocol Handbook will closely
parallel the old ARPANET Protocol Handbook, and will primarily be a
collection of existing RFCs.  Until this new Protocol Handbook is
available, people interested in the internet protocols, especially
implementers, may desire to make their own temporary notebooks of the
relevant protocol documents.  To aid this, the following is suggested as
a table of contents for such a collection.  Any suggestions for
additions should be sent to Jon Postel (Postel@ISIF).

RFCs are public access document files and may be copied from the Network
Information Center online Library at SRI-NIC via FTP using the FTP user
name ANONYMOUS and password GUEST.  The RFCs have pathnames of the form
"<NETINFO>RFCnnn.TXT", where "nnn" is replaced by the document number.




                           Table of Contents



Network Level

   Internet Protocol (IP)                                        RFC 791

   Internet Control Message Protocol (ICMP)                      RFC 792

Host Level

   User Datagram Protocol (UDP)                                  RFC 768

   Transmission Control Protocol (TCP)                           RFC 793

Application Level

   Trivial File Transfer Protocol (TFTP)                         RFC 783

   Telnet Protocol (TELNET)                                      RFC 764

   File Transfer Protocol (FTP)                                  RFC 765

   Simple Mail Transfer Protocol (SMTP)                          RFC xxx

Appendices

   Assigned Numbers                                              RFC 790

   Service Mappings                                              RFC 795

   Address Mappings                                              RFC 796

   Document File Format Standards                                RFC 678

   Mail Header Format Standards                                  RFC 733

Note:  The RFC on the simple mail protocol will be issued soon.

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

From: DUCKETT at USC-ISIE
Subject: TCP-IP Digest

Dear Mike:

I found your first two Digest issues of considerable interest.  If you 
have questions concerning policy on the TCP transition, I suggest you 
ask me or Capt. Glynn Parker (DCACode252@ISIA) who manages the ARPANET 
for DCA.

Jon Postel is responsible for the transition planning and is working on 
documentation to aid users in preparation for the mixed NCP/TCP mode of 
operation which we can expect during calendar 1982.  Already we have a 
community of TCP-only users who are at Ft. Bragg, North Carolina 
entering the ARPANET via a gateway to the Ft. Bragg packet radio 
network.  There are likewise a number of European researchers in the UK,
Norway, and soon Germany who will likewise access the ARPANET using 
TCP/IP through SATNET/ARPANET gateways.

Jon Postel will be spelling this out in more detail, but one crucial 
step towards the transition is the implementation of a Simple Mail 
Transfer Protocol (SMTP) which can run above either TCP or NCP.  This 
mail transport mechanism achieves the same function as the MAIL or MLFL 
commands of FTP, but with greater efficiency and, most important, 
handles clearly the problem of forwarding mail from NCP to TCP 
environments and back.  To allow mail to go thru during the NCP/TCP 
transition, everyone must have a functioning SMTP running on either NCP 
or TCP.  Without this, it won't be possible to handle mail forwarding 
transparently. There is a kludge available to handle the recalcitrant 
FTP mailer, but is is very inconvenient for users.  Jon Postel will be 
documenting all this in more detail.

Dave Clark at MIT (DClark@MIT-Multics) is the internet systems Architect
and is responsible for long-range planning.  A number of capabilities 
are still sought for the internet system including handling packetized 
voice and dealing with partitioning of networks.  Dave will probably 
want to share some of his thoughts in your digest as well.

I'd like to comment on TCP performance on local nets.  Mitre has done 
some work in this area, achieving on the order of 200-350 kb/s for full 
TCP/IP operation.  The protocol is not in and of itself inefficient on a
local net.  In fact, the short delay on the net is generally helpful.  
Suggest you discuss this with Steve Holmgren at MITRE Corporation 
(Steve@MITRE).  Steve has also done work on front ends for UNIX.  This 
may be relevant to your specific interests as well.  Digital Technology 
Inc. (DTI) has also done work on front ends--Gary Grossman (grg@DTI) can
answer questions.

The most noticeable performance factors seem to be software checksumming
(takes CPU cycles) and careful window flow control/retransmission 
timeouts.  Dave Clark has worked on the latter in some depth.  Small, 
efficient TCP's can be and have been built.  A big challenge is dealing 
with the wide range of delays and bandwidths presented by the internet 
environment.

I believe TCP/IP to be the most thoroughly tested and widely implemented
multinetwork protocol ever built.  It is a crucial component of future 
DoD command and control systems.  People participating in this 
transition of the ARPANET into the internet environment are 
participating in an event as exciting as the construction of the ARPANET
and I am very proud to be a part of it.

Cordially,

Vint Cerf (bd)

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

From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: TOPS-20 TCP Implementation

     It has been mentioned on several occasions that there is a
TOPS-20 (and Tenex) TCP implementation from BBN; and some people
have treated it as a foregone conclusion that TCP work on TOPS-20
is "done".  I would like to comment on this, and state why I
believe the 1983 deadline for NCP to TCP conversion will not be
met.  I have worked with BBN's TCP at the user program level;
specifically I have implemented user TELNET for TCP as part of a
general multiple-network TELNET for TOPS-20.

     Briefly, the TOPS-20 TCP implementation in its present form
is unacceptable to Stanford and many other TOPS-20 sites.  It is
sad that so many bright people at BBN have had to maintain this
dog instead of working on a complete rewrite.  There are several
reasons as to why we feel the present BBN implementation of TCP
is unacceptable:

 (1) Performance problems.  Reports have varied, but the general
concensus seems to be that the TCP process consumes between 40%
to 60% of the CPU.  We simply cannot sacrifice that much of an
already-loaded CPU to implement a network; in fact, we find that
NCP's overhead on our system is at times excessive.  Last spring
Dan Lynch mentioned that he was going to try to get some more
specific performance figures of TCP at ISI; I don't know whether
he has or not.

 (2) User code implementation details.  TOPS-20 TCP's interface
to user processes is completely non-standard from the way any
other network (or device) works on TOPS-20.  In TELNET, there are
two major paths for network I/O; one is for TCP, the other is for
every other network (9 at last count).  This wouldn't be so
objectionable if the TCP path were simpler; it isn't.  TOPS-20
TCP's system calls not only do not use the filesystem and
associated buffer management, they also require the user program
to implement its own buffer management.  The actual details of
how to write an efficient user mode data stream driver for
TOPS-20 TCP are complex; the obvious straightforward algorithm is
incredibly slow.

     The cause of this is well-known; TCP on TOPS-20 was
originally implemented as a user-mode process written in BCPL
which did user-mode system call trapping; due to the complexities
of simulating the filesystem under these conditions impromptu
pseudo-system calls were written for the user process to use.
This was fine as a temporary testbed, but the user process
interface should have been redesigned.  Instead, TCP's
implementation in the TOPS-20 kernel was essentially converting
the BCPL code to assembly code and inserting it in the kernel.

     At a gathering of ARPANET users last spring at the DECUS
symposium, DEC indicated its plans to redesign the TCP user
interface.  That solves that objection, but it wasn't at all
clear (on DEC's part -- it was quite clear on the users' part)
that they were going to improve TCP's internal performance.  My
understanding is that this project still is not completed.  I do
not see how an acceptable implementation of TCP for TOPS-20 could
possibly be ready in time for the 1983 deadline.

     I also do not see how ARPA/DCA/whomever intends to enforce
the non-use of NCP.  The NCP/TCP conversion is of far greater
complexity than conversion from 32-bit to 96-bit leaders; the
latter was done by myself on WAITS (SU-AI's operating system) and
Dave Moon on ITS (MIT's operating system) in a matter of a few
days in 1978.  Also, the 32-bit/96-bit conversion was to some
extent a change in the "hardware" implementation and required
next to no change in the actual protocol code.

     It will be technically difficult to enforce the non-use of
NCP unless the IMPs are somehow modified to intercept and
disallow NCP messages; NCP is at a higher level than the IMPs
think.  The worst that I envision could happen if a host does not
go to TCP is that a user on a TIP won't be able to contact that
host; with the present problems with high-school kids on TIPs
some of us would consider that a benefit!

     I hope that due consideration is being given to this
problem.  There are a lot of PDP-10's on the ARPANET right now,
and they aren't about to vanish in a corner.  To my knowledge,
there is no project at all to implement TCP on WAITS, ITS, or
TOPS-10; and the Tenex/TOPS-20 implementation has significant
problems for a site which wants to implement it.  Some people
feel that a "network front end" is the right long-term solution
for this problem; but we can't just go and build a network front
end in 14 months.

-- Mark --

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

From: nowicki@Diablo at Sumex-Aim
Subject: Throughput

There was a brief mention of throughput in the last TCP digest.
For what it's worth, we are getting about 120Kbits/second through
our PUP FTP running between Vaxes on 3Mbit Ethernet.  This is bits in
the file divided by wall clock time in seconds, so it is not very precise
(but accurate for large files).  All the protocols are done in user
programs, nothing in the kernel, with a window size of one (ACK per packet).
With fancy buffer management in the kernel and larger windows, TCP
should give much better performance.  We'll see.
	-- Bill

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

From: Robert Elton Maas <REM at MIT-MC>
Subject: TCP/IP Digest, V1 #1

I've reviewed much of Internet Protocol and found it to be very lacking.
I have consequently rejected it for use in making networks of personal
computers/workstations for the general public to all link up with.
I have sent numerous gripes to Jon Postel and other authors of
parts of the IP but they just beg the questions.

One document in that group is however interesting/useful, the
RFC about connectionless data transfer. I'd like to see more
work in that direction.

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

From: Robert Elton Maas <REM at MIT-MC>
Subject: Internet Protocol Losses?

My major complaint is with mailbox addressing.
The assumption of IP is that every node is on some official network,
that such nodes are known in exhaustion to that network bureaucracy
so that in particular node-id numbers can be assigned to each node.
Nodes join the Internet not individually but by being officially
registered with a network that has joined.
I don't want that kind of personal-computer network.  I want nodes
to be able to join a network just by getting software and starting
to send messages to well-known nodes and getting replies from them
and from nodes they are referred to (introduced to).  A node shouldn't
have to apply for membership, and a network shouldn't have to maintain
a list of all legal members, and every node on a network shouln't
have to have a table that gives for each node-id number the next-hop
for forwarding to that node (I envision several million nodes on
one network, most nodes being merely 32k or 48k microcomputers with
small floppy disks, no way such a small machine can list all other nodes).
PCNET uses latitude and longitude, with phone number, for identifying
a node.  Any node can look on a USGS or aircraft map to get its
coordinates.  Forwarding a message can be done directly by the phone
number or indirectly by the latitude and longitude.  IP doesn't
have enough bits in the allowed node-address to support this method.
(PCNET needs at the very least:
  Longitude, 360 degrees * 60 minutes/degree = 21600 (appx 2^15)
  Latitude, +/- 90 degrees (180 deg) * 60 m/d =10800 (appx 2^14)
  Phone number, XxX-XXX-XXXX = 2*10^9 = (appx 2^31)
 Total 60 bits.  There's redundancy in lat/long vs. telephone area
  code, but to take advantage of that requires a gigantic table
  of locations of telephone area codes and prefixes.  I think IP
  allows only 32 bits for node-number-on-network, right?)

Another gripe is the extreme amount of overhead in each packet.
If you're doing packet switching thru internets, maybe that overhead
is needed.  But it's totally inappropriate for two nodes talking
directly to each other thru modems. PCNET gets by with 6 bytes of
packet overhead instead of IP's 64 (2 bytes of CRC, 1 byte of sequence
numbering mod 8, and 1 byte of process-number and flags for directing the
packet to up to 127 user channels, and 2 guard-bytes between packets
to reframe the UART and signal the break between packets) which supports
very rapid interactive turnaround even on slow modems.

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

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon Oct 19 22:25:42 1981
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #3

>From tcp-ip@brl Mon Oct 19 21:38:29 1981
TCP/IP Digest             Monday, 19 Oct 1981      Volume 1 : Issue 3

Today's Topics:
                     Acronyms -- Protocol Documents
          TCP Transition Notes -- Simple Mail Transfer Protocol
                Problems with TOPS-20 TCP Implementation?
                    Throughput Considerations of TCP
                     TCP/IP:  Suitable for MicroPs?

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

From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Acronyms

Apparently there are enough non-net-hackers on the list that I should
explain the acronyms I used in my message in V1#2.

TCP - Transmission Control Protocol
      (see RFC's 791, 792, & 793 for details on TCP and IP)
IP  - Internet [control] Protocol
RFC - Request For Comment; Technical notes requesting comment from the
      ARPANET public (also the only place to find those protocols which
      have been adopted as DCA standards or ad hoc standards).
      The RFC's are numbered and are available from the <NETINFO>
      directory on the SRI-NIC host.  Suggested course of action is to
      first FTP <NETINFO>RFC-INDEX.TXT to see what is available.
IEN - Internet Experiment Note; Similar to RFC's, and available from
      the same place via FTP, but applicable specifically to the DCA/DARPA
      sponsored Internet Experiment work (where TCP & IP originally came
      from).  Suggested course of action is to first FTP IEN-INDEX.TXT to
      see what is available.
FTP - File Transfer Protocol; a network protocol/service whereby users
      can transfer files between/among hosts.  If you're not up on the
      use of FTP, see your friendly local ARPANET Liaison.
NIC - Network Information Center; The friendly people who maintain the
      online information databases such as RFC's, IEN's, lists of ARPANET
      Hosts, Liaisons, and Users, etc.  In addition to supporting the
      net "standard" ANONYMOUS login with password GUEST to obtain the
      files kept in <NETINFO>, they also have a nifty online query system
      available to anyone who can connect to SRI-NIC via TIP or TELNET.
      To use it, first connect to the SRI-NIC host, then login as NIC (no
      password is necessary) and follow the instructions.  The NIC/Query
      system can locate users, hosts, liaisons, and provides much other
      ARPANET information.
      [To find out how to use a TIP or the host TELNET service, see
       your friendly local ARPANET Liaison.]
DARPA - Defense Advanced Research Projects Agency; the friendly folks who
      originally brought you the ARPANET (for whom it is named) and who
      are now funding internet research using the ARPANET as part of their
      laboratory.
DCA - Defense Communications Agency; The not-quite-as friendly folks
      who run the ARPANET for the Dept. of Defense (actually, also very
      friendly, but they have the Gov't Accounting Office (GAO) and every
      other busybody in the country breathing down their necks about what
      all that money is being spent for, so they're inclined to be a bit
      serious about the uses we make of the net).

Cheers,
Rich

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

From: POSTEL at USC-ISIF
Subject: Protocol Documents
To:   TCP-IP-Digest at BRL

In recent years the ARPA Network Research Program has had as one concern
the interconnection of networks.  In the course of this research a
family of protocols suitable for an internetwork environment has
emerged.  The major internet protocol documents have been issued as
RFCs.

The situation has evolved to the point that it is appropriate for the
internet family of protocols to replace the old ARPANET protocols.  To
this end an Internet Protocol Handbook will be prepared by the Network
Information Center.  This Internet Protocol Handbook will closely
parallel the old ARPANET Protocol Handbook, and will primarily be a
collection of existing RFCs.  Until this new Protocol Handbook is
available, people interested in the internet protocols, especially
implementers, may desire to make their own temporary notebooks of the
relevant protocol documents.  To aid this, the following is suggested as
a table of contents for such a collection.  Any suggestions for
additions should be sent to Jon Postel (Postel@ISIF).

RFCs are public access document files and may be copied from the Network
Information Center online Library at SRI-NIC via FTP using the FTP user
name ANONYMOUS and password GUEST.  The RFCs have pathnames of the form
"<NETINFO>RFCnnn.TXT", where "nnn" is replaced by the document number.




                           Table of Contents



Network Level

   Internet Protocol (IP)                                        RFC 791

   Internet Control Message Protocol (ICMP)                      RFC 792

Host Level

   User Datagram Protocol (UDP)                                  RFC 768

   Transmission Control Protocol (TCP)                           RFC 793

Application Level

   Trivial File Transfer Protocol (TFTP)                         RFC 783

   Telnet Protocol (TELNET)                                      RFC 764

   File Transfer Protocol (FTP)                                  RFC 765

   Simple Mail Transfer Protocol (SMTP)                          RFC xxx

Appendices

   Assigned Numbers                                              RFC 790

   Service Mappings                                              RFC 795

   Address Mappings                                              RFC 796

   Document File Format Standards                                RFC 678

   Mail Header Format Standards                                  RFC 733

Note:  The RFC on the simple mail protocol will be issued soon.

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

From: DUCKETT at USC-ISIE
Subject: TCP-IP Digest

Dear Mike:

I found your first two Digest issues of considerable interest.  If you 
have questions concerning policy on the TCP transition, I suggest you 
ask me or Capt. Glynn Parker (DCACode252@ISIA) who manages the ARPANET 
for DCA.

Jon Postel is responsible for the transition planning and is working on 
documentation to aid users in preparation for the mixed NCP/TCP mode of 
operation which we can expect during calendar 1982.  Already we have a 
community of TCP-only users who are at Ft. Bragg, North Carolina 
entering the ARPANET via a gateway to the Ft. Bragg packet radio 
network.  There are likewise a number of European researchers in the UK,
Norway, and soon Germany who will likewise access the ARPANET using 
TCP/IP through SATNET/ARPANET gateways.

Jon Postel will be spelling this out in more detail, but one crucial 
step towards the transition is the implementation of a Simple Mail 
Transfer Protocol (SMTP) which can run above either TCP or NCP.  This 
mail transport mechanism achieves the same function as the MAIL or MLFL 
commands of FTP, but with greater efficiency and, most important, 
handles clearly the problem of forwarding mail from NCP to TCP 
environments and back.  To allow mail to go thru during the NCP/TCP 
transition, everyone must have a functioning SMTP running on either NCP 
or TCP.  Without this, it won't be possible to handle mail forwarding 
transparently. There is a kludge available to handle the recalcitrant 
FTP mailer, but is is very inconvenient for users.  Jon Postel will be 
documenting all this in more detail.

Dave Clark at MIT (DClark@MIT-Multics) is the internet systems Architect
and is responsible for long-range planning.  A number of capabilities 
are still sought for the internet system including handling packetized 
voice and dealing with partitioning of networks.  Dave will probably 
want to share some of his thoughts in your digest as well.

I'd like to comment on TCP performance on local nets.  Mitre has done 
some work in this area, achieving on the order of 200-350 kb/s for full 
TCP/IP operation.  The protocol is not in and of itself inefficient on a
local net.  In fact, the short delay on the net is generally helpful.  
Suggest you discuss this with Steve Holmgren at MITRE Corporation 
(Steve@MITRE).  Steve has also done work on front ends for UNIX.  This 
may be relevant to your specific interests as well.  Digital Technology 
Inc. (DTI) has also done work on front ends--Gary Grossman (grg@DTI) can
answer questions.

The most noticeable performance factors seem to be software checksumming
(takes CPU cycles) and careful window flow control/retransmission 
timeouts.  Dave Clark has worked on the latter in some depth.  Small, 
efficient TCP's can be and have been built.  A big challenge is dealing 
with the wide range of delays and bandwidths presented by the internet 
environment.

I believe TCP/IP to be the most thoroughly tested and widely implemented
multinetwork protocol ever built.  It is a crucial component of future 
DoD command and control systems.  People participating in this 
transition of the ARPANET into the internet environment are 
participating in an event as exciting as the construction of the ARPANET
and I am very proud to be a part of it.

Cordially,

Vint Cerf (bd)

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

From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: TOPS-20 TCP Implementation

     It has been mentioned on several occasions that there is a
TOPS-20 (and Tenex) TCP implementation from BBN; and some people
have treated it as a foregone conclusion that TCP work on TOPS-20
is "done".  I would like to comment on this, and state why I
believe the 1983 deadline for NCP to TCP conversion will not be
met.  I have worked with BBN's TCP at the user program level;
specifically I have implemented user TELNET for TCP as part of a
general multiple-network TELNET for TOPS-20.

     Briefly, the TOPS-20 TCP implementation in its present form
is unacceptable to Stanford and many other TOPS-20 sites.  It is
sad that so many bright people at BBN have had to maintain this
dog instead of working on a complete rewrite.  There are several
reasons as to why we feel the present BBN implementation of TCP
is unacceptable:

 (1) Performance problems.  Reports have varied, but the general
concensus seems to be that the TCP process consumes between 40%
to 60% of the CPU.  We simply cannot sacrifice that much of an
already-loaded CPU to implement a network; in fact, we find that
NCP's overhead on our system is at times excessive.  Last spring
Dan Lynch mentioned that he was going to try to get some more
specific performance figures of TCP at ISI; I don't know whether
he has or not.

 (2) User code implementation details.  TOPS-20 TCP's interface
to user processes is completely non-standard from the way any
other network (or device) works on TOPS-20.  In TELNET, there are
two major paths for network I/O; one is for TCP, the other is for
every other network (9 at last count).  This wouldn't be so
objectionable if the TCP path were simpler; it isn't.  TOPS-20
TCP's system calls not only do not use the filesystem and
associated buffer management, they also require the user program
to implement its own buffer management.  The actual details of
how to write an efficient user mode data stream driver for
TOPS-20 TCP are complex; the obvious straightforward algorithm is
incredibly slow.

     The cause of this is well-known; TCP on TOPS-20 was
originally implemented as a user-mode process written in BCPL
which did user-mode system call trapping; due to the complexities
of simulating the filesystem under these conditions impromptu
pseudo-system calls were written for the user process to use.
This was fine as a temporary testbed, but the user process
interface should have been redesigned.  Instead, TCP's
implementation in the TOPS-20 kernel was essentially converting
the BCPL code to assembly code and inserting it in the kernel.

     At a gathering of ARPANET users last spring at the DECUS
symposium, DEC indicated its plans to redesign the TCP user
interface.  That solves that objection, but it wasn't at all
clear (on DEC's part -- it was quite clear on the users' part)
that they were going to improve TCP's internal performance.  My
understanding is that this project still is not completed.  I do
not see how an acceptable implementation of TCP for TOPS-20 could
possibly be ready in time for the 1983 deadline.

     I also do not see how ARPA/DCA/whomever intends to enforce
the non-use of NCP.  The NCP/TCP conversion is of far greater
complexity than conversion from 32-bit to 96-bit leaders; the
latter was done by myself on WAITS (SU-AI's operating system) and
Dave Moon on ITS (MIT's operating system) in a matter of a few
days in 1978.  Also, the 32-bit/96-bit conversion was to some
extent a change in the "hardware" implementation and required
next to no change in the actual protocol code.

     It will be technically difficult to enforce the non-use of
NCP unless the IMPs are somehow modified to intercept and
disallow NCP messages; NCP is at a higher level than the IMPs
think.  The worst that I envision could happen if a host does not
go to TCP is that a user on a TIP won't be able to contact that
host; with the present problems with high-school kids on TIPs
some of us would consider that a benefit!

     I hope that due consideration is being given to this
problem.  There are a lot of PDP-10's on the ARPANET right now,
and they aren't about to vanish in a corner.  To my knowledge,
there is no project at all to implement TCP on WAITS, ITS, or
TOPS-10; and the Tenex/TOPS-20 implementation has significant
problems for a site which wants to implement it.  Some people
feel that a "network front end" is the right long-term solution
for this problem; but we can't just go and build a network front
end in 14 months.

-- Mark --

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

From: nowicki@Diablo at Sumex-Aim
Subject: Throughput

There was a brief mention of throughput in the last TCP digest.
For what it's worth, we are getting about 120Kbits/second through
our PUP FTP running between Vaxes on 3Mbit Ethernet.  This is bits in
the file divided by wall clock time in seconds, so it is not very precise
(but accurate for large files).  All the protocols are done in user
programs, nothing in the kernel, with a window size of one (ACK per packet).
With fancy buffer management in the kernel and larger windows, TCP
should give much better performance.  We'll see.
	-- Bill

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

From: Robert Elton Maas <REM at MIT-MC>
Subject: TCP/IP Digest, V1 #1

I've reviewed much of Internet Protocol and found it to be very lacking.
I have consequently rejected it for use in making networks of personal
computers/workstations for the general public to all link up with.
I have sent numerous gripes to Jon Postel and other authors of
parts of the IP but they just beg the questions.

One document in that group is however interesting/useful, the
RFC about connectionless data transfer. I'd like to see more
work in that direction.

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

From: Robert Elton Maas <REM at MIT-MC>
Subject: Internet Protocol Losses?

My major complaint is with mailbox addressing.
The assumption of IP is that every node is on some official network,
that such nodes are known in exhaustion to that network bureaucracy
so that in particular node-id numbers can be assigned to each node.
Nodes join the Internet not individually but by being officially
registered with a network that has joined.
I don't want that kind of personal-computer network.  I want nodes
to be able to join a network just by getting software and starting
to send messages to well-known nodes and getting replies from them
and from nodes they are referred to (introduced to).  A node shouldn't
have to apply for membership, and a network shouldn't have to maintain
a list of all legal members, and every node on a network shouln't
have to have a table that gives for each node-id number the next-hop
for forwarding to that node (I envision several million nodes on
one network, most nodes being merely 32k or 48k microcomputers with
small floppy disks, no way such a small machine can list all other nodes).
PCNET uses latitude and longitude, with phone number, for identifying
a node.  Any node can look on a USGS or aircraft map to get its
coordinates.  Forwarding a message can be done directly by the phone
number or indirectly by the latitude and longitude.  IP doesn't
have enough bits in the allowed node-address to support this method.
(PCNET needs at the very least:
  Longitude, 360 degrees * 60 minutes/degree = 21600 (appx 2^15)
  Latitude, +/- 90 degrees (180 deg) * 60 m/d =10800 (appx 2^14)
  Phone number, XxX-XXX-XXXX = 2*10^9 = (appx 2^31)
 Total 60 bits.  There's redundancy in lat/long vs. telephone area
  code, but to take advantage of that requires a gigantic table
  of locations of telephone area codes and prefixes.  I think IP
  allows only 32 bits for node-number-on-network, right?)

Another gripe is the extreme amount of overhead in each packet.
If you're doing packet switching thru internets, maybe that overhead
is needed.  But it's totally inappropriate for two nodes talking
directly to each other thru modems. PCNET gets by with 6 bytes of
packet overhead instead of IP's 64 (2 bytes of CRC, 1 byte of sequence
numbering mod 8, and 1 byte of process-number and flags for directing the
packet to up to 127 user channels, and 2 guard-bytes between packets
to reframe the UART and signal the break between packets) which supports
very rapid interactive turnaround even on slow modems.

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

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 81 23:22:48-EDT (Sun)
From:      Mike Muuss <tcp-ip@brl>
To:        tcp-ip at Brl
Subject:   TCP-IP Digest, Vol 1 #4
TCP/IP Digest             Sunday, 25 Oct 1981      Volume 1 : Issue 4

Today's Topics:
           Mail Reflectors and An Online Archive of the Digest
                       PARC Universal Packet (PUP)
                     More on TOPS-20 TCP/IP Lossage
             How to Force the Transition from NCP to TCP/IP
                     Correction of Address for CERF
               InterNet Mail, Hostname Tables, and Routing
                          FYI:  HDH Anouncement

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

From:     Mike Muuss
Reply-to: tcp-ip@BRL
Subject:  Administrative Notes

For those of you who have trouble remembering where the list originates from,
I have (with the graceous help of JSol) added mail reflectors for TCP-IP and
TCP-IP-REQUEST on both AI and MC.

People wishing to get back issues can now FTP them from Utah-20 (see letter
below), or they can write to TCP-IP-REQUEST.  Again, I regret our inability
to allow anonymous logins.  If there is a high demand for back issues, other
archive sites may be set up.

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

From: Jay Lepreau <Lepreau at UTAH-20>
Subject: Online Archive

We are keeping an online archive, of at least recent stuff.  Will probably
archive it (to tape) after it gets old, whatever that means (probably a
function of disk space and interest and list content).  Anyway, people are
welcome to ftp it from here-- it's <bboard>tcp-ip.txt, in chronological
order, MM format.

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

From: nowicki@Diablo at Sumex-Aim
Subject: PUP

PUP stands for Parc Universal Packet.  It is the network architecture
used in the Xerox internet for several years, which has several hundred
computers on various kinds of networks throughout the world.  A good
overview is in April 1980 IEEE Transactions on Communication.  To
summarize its features, it is a datagram-based very simple family of
protocols, from which IP borrows many of its ideas.  Because it was one
of the first working "network architectures," there are some
unresolvable problems, like limited address space.  Stanford did Unix
implementations of PUP because we got all sorts of equipment from Xerox
that used it.  Ethernet has always supported multiple "network-level"
protocols, so there is no problem encapsulating IP at the same time.

Does that clear up some confusion?

	-- Bill

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

From: Chris Ryland <RYLAND at SRI-KL>
Subject: Re:   TCP-IP Digest, Vol 1 #3

If anyone is interested in more detail concerning the problems with
TOPS-20 TCP/IP, I wrote a long-winded document about said topic.
It needs some polishing up to reflect feedback from the people who
did the work, but if there's enough interest (how do we gauge it?)
I'll make it available.

Mark Crispin hit on some of the high points, but if you're a TOPS-20
type and are worried about what TCP is going to mean to you if DEC
continues its current course, then it should be useful.

I can only second Mark's prediction that this current BBN/DEC TOPS-20
implementation is going to be basically useless because of its poor
performance.  There is some hope that there is something grossly wrong
with it that can be tuned away, but we're grasping at straws.  Does
anyone at ISI involved in looking at this implementation have any new
data?

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

Subject: Suggestions to make the NCP ==> TCP Transition happen.
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL

Here are some suggestions to help/force people implement TCP/IP
by "the deadline", Jan 1, '83:

1) Removal of NCP from TIPS -- When your out of town and away
from your host, and can't login to read your mail, you'll want to
have it implemented.

2) When your Principle Investigator (i.e.  high level bureaucrat)
can't send mail to other hosts which only support TCP or login
remotely from a TIP, you'll want to have TCP/IP implemented.

3) I believe it is DARPA's intention to put AS MANY services as
possible onto the Internet (i.e.  only accessable via TCP/IP)
that users will REALLY WANT to implement the Internet Protocols
in order to have access to them.  It might be nice for a
"Directory Of Services" (like the VAN-Gateway for example) to be
published to show availalbe Internet services.  [I guess this
would be the current ARPANET RESOURCES HANDBOOK covering the
entire Internet as opposed to just ARPANET Resources, and perhaps
becoming the INTERNET RESOURCES HANDBOOK?]

and lastly (this one is my favorite), 4) Have such hosts as the
various ISI-* systems, where most of the Network Sponsors have
their mailboxs who provide many a funded $$$ to us all,
de-install NCP on the transition date.  Therefore, causing anyone
who has *NOT* impelemented Internet by that time, be unable to
communicate with their Sponsor, and hence, they won't get funded.

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

Subject: RECENT CORRESPONDENCE
From: CERF at USC-ISI

MIKE,
RECENTLY I SENT YOU A NOTE WHICH
YOU PUBLISHED AS PART OF YOUR NEWSLETTER.

WHEN I SAW THE NOTE, I REALIZED THERE
MIGHT BE SOME CONFUSION CAUSED BY THE
FACT THAT IT WAS SENT FROM MY SECRETARY'S
MAILBOX (DUCKETT@ISIE) AND NOT FROM
MINE (CERF@ISIA). JUST WANTED TO
ALERT YOU TO THIS (AND YOUR READERS).

THE ODDLY FORMATTED MESSAGE BEFORE YOU
COMES FROM AN APPLE COMPUTER WITH
SMALL DISPLAY SCREEN (15 USABLE LINES)
AND 40 CHARACTERS ACROSS AND UPPER CASE
ONLY. THE ONLY SAVING GRACE IS THAT
THE COLOR GRAPHICS AND SHOOTING 
GALLERY GAMES LOOK GOOD IN COLOR...

VINT CERF
DARPA/IPTO

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

From: ihnss!cbosg!cbosgd!mark at Berkeley
To: cbosg!ihnss!ucbvax!tcp-ip@Berkeley
Subject: Re:  REM's gripes about internet mail

I found REM's comments interesting but not very well based in reality.
First note that the internet mail standard is essentially
	"user.host@network"
where user, host, and network are character strings.  There is no
assumption that the "host@network" pair can be mapped into a pair
of integers from some table somewhere, unless you actually intend
to send packets and simulate things like telnet.  Of course, for
sending mail you don't need this.

PCnet is not the only network that provides el-cheapo service at
el-cheapo prices (e.g. over dialup telephone lines).  The UUCP net
has been around for some years and does this (with no internal
numbering of hosts) and the new CSNET PhoneNet is the same idea.

Only the network has to be able to translate "host" into enough
information to route the message there, not the whole internet.  This
requires ONE SITE on each network to keep an up to date list of sites
and routes.  Other sites have the option of sending the mail to the
smart site to forward.  The alternative to this is what UUCP does now:
you explicitly route messages through all the hosts that forward the
message, e.g. decvax!duke!unc!smb@Berkeley gets forwarded through the
three UUCP sites decvax, duke, and unc to user smb.  The advantages to
this are (1) to add a site, all you have to do is inform its
neighbor(s) that it exists, and (2) the software doesn't have to worry
about routing.  The disadvantages are (1) it's a pain for people to
manually route stuff, and, more importantly, (2) your address varies
depending on the place the mail is sent from.  Thus the current custom
of specifying a UUCP address relative to a well known host such as
ucbvax or duke.  Not very pleasant.

If a net like PCnet wants to avoid keeping tables anywhere, all that's
necessary is to put info such as phone number and other connection info
in the host field.  (I don't recall a limit on how long these names
can be, although most implementations will probably assume one, so some
large upper limit ought to be documented.)  This makes even UUCP look
luxurious - you get to refer to a site by NAME! REM's latitude/longditude/telno
scheme seems kind of useless to me - within one square minute can often
be found a large number of computers.  Often they are on a switch front
end, so even the phone number is the same.  Maybe this will work for
personal home computers, but if everybody in a large office building has
their own personal computer...  In any case, it seems that such conventions
ought to be up to the individual network to specify, so long as they
fit the user.host@network syntax.

	Mark Horton
	Mark@Berkeley

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

From: NIC at SRI-NIC
Subject: ANEWS-9
 
There is a new alternative host interface for the ARPANET C/30 IMPs
called HDH (HDLC Host).  This interface method is similar to the
existing VDH (Very Distant Host) interface in that it provides for
reliable transmission of messages between the host and its IMP over a
communication circuit of arbitrary length.  As with VDH, the HDH
interface can be used with communication circuits that range in speed
from 9.6KB to 56KB. 
 
HDH is superior to the VDH interface in that it uses as a reliable
transmission protocol the HDLC protocol which is the link level control
procedure of the CCITT international standard X.25.  HDLC is supported
by a much wider range of vendor equipment than the special ARPANET VDH
protocol.  It is also technically superior to VDH in that it provides
for a window of up to seven outstanding frames instead of the two
allowed by VDH, thus increasing the potential throughput.  The HDH
interface is also capable of accepting a full-length ARPANET host/IMP
message in a single frame, where VDH always requires fragmentation into
buffer-sized frames.

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

END OF DOCUMENT