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 December 1981 (4 messages, 9652 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1981/12.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Fri Dec 11 18:33:30 1981
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #8

>From tcp-ip@brl Fri Dec 11 18:15:56 1981
TCP/IP Digest            Friday, 11 Dec 1981       Volume 1 : Issue 8

Today's Topics:
                     TCP/IP for CDC CYBER Mainframes
            Mail Between NCP and TCP Hosts -- RFC801 Excerpts
          Relating ArpaNet Protocols to the ISO Reference Model
        TCP/IP Conversion Timetable & Documents  --  RFC801 again
                      Tidbit about UK INDRA Project
----------------------------------------------------------------------

Subject: TCP/IP for CDC CYBER Mainframes
From: SITNIK at OFFICE-8

Tektronix has implemented TCP/IP on their CDC CYBER mainframe.
The project is being directed by Tim Fallon, (415) 627-5471.  Tim
doesn't mind being contacted and in fact, would like to
distribute TCP to anyone who is interested with the understanding
that there is no committment of future support by Tektronix.  He
is currently exploring the distribution issue with the Tektronix
legal department.

The Tektronix implementation of TCP/IP runs at a System Control
Point (SCP) under the NOS operating system.  Interface with the
user is through SCP macro calls.  Interface to the network is via
a Hyperchannel device drive which runs in a peripheral processor.

Tim is not aware of anyone working on a NOS/BE version of TCP.

Rich Sitnik

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

From: csk at UCLA-Security (Charley Kline)
Subject: mail among tcp/ncp hosts

A while ago, the following question was asked and I didn't see an
answer to it in this digest.  Can someone answer it.  Thanks.

As TCP/IP becomes the standard, many hosts are coming online with
only TCP/IP protocols.  Can someone explain where and how one uses
mail gateways to get mail to/from hosts which are using NCP
protocols with those using TCP/IP protocols while the transition
is taking place?

--charley

[ I believe that the plan for transition is well detailed in RFC801,
  which is availible for FTP from the NIC using account "anonymous",
  and your name for the password.  File is <netinfo>rfc801.txt
  I have included pieces here for everybody to see.   -Mike ]

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

Subject:  RFC801 Excerpts about NCP <-> TCP Mail and File Transfer

Network Working Group                                          J. Postel
Request for Comments: 801                                            ISI

      For FTP, there will be provided one or more relay hosts.  An FTP
      relay host will implement both the NCP and TCP environments, both
      user and server Telnet, and both user and server FTP in both
      environments.  Users requiring FTP service between hosts in
      different environments will first connect via Telnet to an FTP
      relay host, then use FTP to move the file from the file donor host
      to the FTP relay host, and finally use FTP to move the file from
      the FTP relay host to the file acceptor host.  (See Appendix B.)

      For Mail, hosts will implement the new Simple Mail Transfer
      Protocol (SMTP) described in RFC 788.  The SMTP procedure provides
      for relaying mail among several protocol environments.  For
      TCP-only hosts, using SMTP will be sufficient.  For NCP-only hosts
      that have not been modified to use SMTP, the special syntax
      "user.host@forwarder" may be used to relay mail via one or more
      special forwarding host.  Several mail relay hosts will relay mail
      via SMTP procedures between the NCP and TCP environments, and at
      least one special forwarding host will be provided.

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

From:      Michael Muuss <mike@brl>
Subject:   Relating ArpaNet Protocols to the ISO Reference Model

Whilst reading a copy of "FY80 Final Report:  Cable Bus Applications
in Command Centers" from the Mitre Corporation which was kindly provided
to me by Steve Holmgren <Steve@Mitre>, I discovered a most interesting
comparison between the TCP/IP based ArpaNet, and the ISO Reference Model.
Included is basically the following picture:

    ISO Reference Model	|    ArpaNet Environment
------------------------|-------------------------------------
	Application	|
------------------------|
	Presentation	|	Virtual Terminal Protocol
------------------------|
	Session		|-------------------------------------
------------------------|
	Transport	|	Transmission Control Protocol/
------------------------|	     InterNet Protocol
	Network		|-------------------------------------
------------------------|
	Data-Link Cntrl	|	Variety of Low-Level Network
------------------------|	     Access Mechanisms
	Physical	|
------------------------|-------------------------------------

Also there is the following descriptive text:

"At the lower protocol levels there is no natural intersection of the
DARPA-like architectures with the ISO Reference Model (RM), but
above layer four in the RM and the end-to-end transport layer in
the DARPA model an eventual mergins of models is possible.

TCP contains some session layer mechanisms and our Virtual Terminal
Protocol (VTP) contains both session and presentation functions, but
the splitting out of these functions in the VTP model is possible and
would not significantly change the protocol itself.  Naturally, a VTP
that fits within the open systems architecture would need to utilize
certain data transformation services of the presentation layer and data
transfer controlling services of the session layer.  This could be done
by using appropriately constructed presentation and session protocols."
[pp 17-19]

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

From:      Michael Muuss <mike@brl>
Subject:   TCP-IP Conversion Timetable & Documents, from RFC801

RFC 801                                                    November 1981
                                                 NCP/TCP Transition Plan

Milestones							When
----------							----

   First Internet Service                                        already

      A few hosts are TCP-capable and use TCP-based services.

   First TCP-only Host                                           already

      The first TCP-only host begins use of TCP-based services.

   Telnet and FTP Relay Service                                  already

      Special relay accounts are available to qualified users with a
      demonstrated need for the Telnet or FTP relay service.

   Ad Hoc Mail Relay Service                                     already

      An ad hoc mail relay service using the prototype MTP (RFC 780) is
      implemented and mail is relayed from the TCP-only hosts to
      NCP-only hosts, but not vice versa.  This service will be replaced
      by the SMTP service.

   Last NCP Conversion Begins                                     Jan 82

      The last NCP-only host begins conversion to TCP.

   Mail Relay Service                                             Jan 82

      The SMTP (RFC 788) mail service begins to operate and at least one
      mail relay host is operational, and at least one special forwarder
      is operational to provide NCP-only host to TCP-only host mail
      connectivity.

   Normal Internet Service                                        Jul 82

      Most hosts are TCP-capable and use TCP-based services.

   Last NCP Conversion Completed                                  Nov 82

      The last NCP-only host completes conversion to TCP.

   Full Internet Service                                          Jan 83

      All hosts are TCP-capable and use TCP-based services.  NCP is
      removed from service, relay services end, all services are
      TCP-based.

Documents
---------

   The following RFCs document the protocols to be implemented in the
   new IP/TCP environment:

      IP                                                         RFC 791
      ICMP                                                       RFC 792
      TCP                                                        RFC 793
      Telnet                                                     RFC 764
      FTP                                                        RFC 765
      SMTP                                                       RFC 788
      Name Server                                                IEN 116
      Assigned Numbers                                           RFC 790

   These and associated documents are to be published in a notebook, and
   other information useful to implementers is to be gathered.  These
   documents will be made available on the following schedule:

      Internet Protocol Handbook                                  Jan 82

      Implementers Hints                                          Jan 82

      SDC IP/TCP Specifications                                   Jan 82

      Expanded Host Table                                         Jan 82

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

From: PKIRSTEIN at USC-ISI
Subject: Re: TCP-IP Digest, Vol 1 #6

In response to your message sent       18 Nov 81 5:39:59-EDT (Wed)

Mike,

There is a lot of things one can say about the INDRA project.  What level, and
what length interests you.  The project has been going in some form for
eight years, and we are deeply involved in providing services for UK groups
to have terminal, file   and mail connectiviity with US groups who are
both on ARPANET or TElENET in the US, and on SRCNET or PSS in the UK. Thus
the project is like CSNET, but also as a considerable research congent.

We are active in various Internet and satelite projects as well.

Peter Kirstein

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

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 81 18:53:15-EST (Fri)
From:      Mike Muuss <tcp-ip@brl>
To:        list:
Subject:   TCP-IP Digest, Vol 1 #8
TCP/IP Digest            Friday, 11 Dec 1981       Volume 1 : Issue 8

Today's Topics:
                     TCP/IP for CDC CYBER Mainframes
            Mail Between NCP and TCP Hosts -- RFC801 Excerpts
          Relating ArpaNet Protocols to the ISO Reference Model
        TCP/IP Conversion Timetable & Documents  --  RFC801 again
                      Tidbit about UK INDRA Project
----------------------------------------------------------------------

Subject: TCP/IP for CDC CYBER Mainframes
From: SITNIK at OFFICE-8

Tektronix has implemented TCP/IP on their CDC CYBER mainframe.
The project is being directed by Tim Fallon, (415) 627-5471.  Tim
doesn't mind being contacted and in fact, would like to
distribute TCP to anyone who is interested with the understanding
that there is no committment of future support by Tektronix.  He
is currently exploring the distribution issue with the Tektronix
legal department.

The Tektronix implementation of TCP/IP runs at a System Control
Point (SCP) under the NOS operating system.  Interface with the
user is through SCP macro calls.  Interface to the network is via
a Hyperchannel device drive which runs in a peripheral processor.

Tim is not aware of anyone working on a NOS/BE version of TCP.

Rich Sitnik

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

From: csk at UCLA-Security (Charley Kline)
Subject: mail among tcp/ncp hosts

A while ago, the following question was asked and I didn't see an
answer to it in this digest.  Can someone answer it.  Thanks.

As TCP/IP becomes the standard, many hosts are coming online with
only TCP/IP protocols.  Can someone explain where and how one uses
mail gateways to get mail to/from hosts which are using NCP
protocols with those using TCP/IP protocols while the transition
is taking place?

--charley

[ I believe that the plan for transition is well detailed in RFC801,
  which is availible for FTP from the NIC using account "anonymous",
  and your name for the password.  File is <netinfo>rfc801.txt
  I have included pieces here for everybody to see.   -Mike ]

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

Subject:  RFC801 Excerpts about NCP <-> TCP Mail and File Transfer

Network Working Group                                          J. Postel
Request for Comments: 801                                            ISI

      For FTP, there will be provided one or more relay hosts.  An FTP
      relay host will implement both the NCP and TCP environments, both
      user and server Telnet, and both user and server FTP in both
      environments.  Users requiring FTP service between hosts in
      different environments will first connect via Telnet to an FTP
      relay host, then use FTP to move the file from the file donor host
      to the FTP relay host, and finally use FTP to move the file from
      the FTP relay host to the file acceptor host.  (See Appendix B.)

      For Mail, hosts will implement the new Simple Mail Transfer
      Protocol (SMTP) described in RFC 788.  The SMTP procedure provides
      for relaying mail among several protocol environments.  For
      TCP-only hosts, using SMTP will be sufficient.  For NCP-only hosts
      that have not been modified to use SMTP, the special syntax
      "user.host@forwarder" may be used to relay mail via one or more
      special forwarding host.  Several mail relay hosts will relay mail
      via SMTP procedures between the NCP and TCP environments, and at
      least one special forwarding host will be provided.

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

From:      Michael Muuss <mike@brl>
Subject:   Relating ArpaNet Protocols to the ISO Reference Model

Whilst reading a copy of "FY80 Final Report:  Cable Bus Applications
in Command Centers" from the Mitre Corporation which was kindly provided
to me by Steve Holmgren <Steve@Mitre>, I discovered a most interesting
comparison between the TCP/IP based ArpaNet, and the ISO Reference Model.
Included is basically the following picture:

    ISO Reference Model	|    ArpaNet Environment
------------------------|-------------------------------------
	Application	|
------------------------|
	Presentation	|	Virtual Terminal Protocol
------------------------|
	Session		|-------------------------------------
------------------------|
	Transport	|	Transmission Control Protocol/
------------------------|	     InterNet Protocol
	Network		|-------------------------------------
------------------------|
	Data-Link Cntrl	|	Variety of Low-Level Network
------------------------|	     Access Mechanisms
	Physical	|
------------------------|-------------------------------------

Also there is the following descriptive text:

"At the lower protocol levels there is no natural intersection of the
DARPA-like architectures with the ISO Reference Model (RM), but
above layer four in the RM and the end-to-end transport layer in
the DARPA model an eventual mergins of models is possible.

TCP contains some session layer mechanisms and our Virtual Terminal
Protocol (VTP) contains both session and presentation functions, but
the splitting out of these functions in the VTP model is possible and
would not significantly change the protocol itself.  Naturally, a VTP
that fits within the open systems architecture would need to utilize
certain data transformation services of the presentation layer and data
transfer controlling services of the session layer.  This could be done
by using appropriately constructed presentation and session protocols."
[pp 17-19]

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

From:      Michael Muuss <mike@brl>
Subject:   TCP-IP Conversion Timetable & Documents, from RFC801

RFC 801                                                    November 1981
                                                 NCP/TCP Transition Plan

Milestones							When
----------							----

   First Internet Service                                        already

      A few hosts are TCP-capable and use TCP-based services.

   First TCP-only Host                                           already

      The first TCP-only host begins use of TCP-based services.

   Telnet and FTP Relay Service                                  already

      Special relay accounts are available to qualified users with a
      demonstrated need for the Telnet or FTP relay service.

   Ad Hoc Mail Relay Service                                     already

      An ad hoc mail relay service using the prototype MTP (RFC 780) is
      implemented and mail is relayed from the TCP-only hosts to
      NCP-only hosts, but not vice versa.  This service will be replaced
      by the SMTP service.

   Last NCP Conversion Begins                                     Jan 82

      The last NCP-only host begins conversion to TCP.

   Mail Relay Service                                             Jan 82

      The SMTP (RFC 788) mail service begins to operate and at least one
      mail relay host is operational, and at least one special forwarder
      is operational to provide NCP-only host to TCP-only host mail
      connectivity.

   Normal Internet Service                                        Jul 82

      Most hosts are TCP-capable and use TCP-based services.

   Last NCP Conversion Completed                                  Nov 82

      The last NCP-only host completes conversion to TCP.

   Full Internet Service                                          Jan 83

      All hosts are TCP-capable and use TCP-based services.  NCP is
      removed from service, relay services end, all services are
      TCP-based.

Documents
---------

   The following RFCs document the protocols to be implemented in the
   new IP/TCP environment:

      IP                                                         RFC 791
      ICMP                                                       RFC 792
      TCP                                                        RFC 793
      Telnet                                                     RFC 764
      FTP                                                        RFC 765
      SMTP                                                       RFC 788
      Name Server                                                IEN 116
      Assigned Numbers                                           RFC 790

   These and associated documents are to be published in a notebook, and
   other information useful to implementers is to be gathered.  These
   documents will be made available on the following schedule:

      Internet Protocol Handbook                                  Jan 82

      Implementers Hints                                          Jan 82

      SDC IP/TCP Specifications                                   Jan 82

      Expanded Host Table                                         Jan 82

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

From: PKIRSTEIN at USC-ISI
Subject: Re: TCP-IP Digest, Vol 1 #6

In response to your message sent       18 Nov 81 5:39:59-EDT (Wed)

Mike,

There is a lot of things one can say about the INDRA project.  What level, and
what length interests you.  The project has been going in some form for
eight years, and we are deeply involved in providing services for UK groups
to have terminal, file   and mail connectiviity with US groups who are
both on ARPANET or TElENET in the US, and on SRCNET or PSS in the UK. Thus
the project is like CSNET, but also as a considerable research congent.

We are active in various Internet and satelite projects as well.

Peter Kirstein

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

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 81 21:55:24-EST (Wed)
From:      Mike Muuss <tcp-ip@brl>
To:        list:
Subject:   TCP-IP Digest, Vol 1 #9
TCP/IP Digest           Wednesday, 23 Dec 1981     Volume 1 : Issue 9

Today's Topics:
            ComputerWorld TCP Article && Packet Radio IP Woes
    TCP-IP Implementations for TOPS-10?  && BBN VAX TCP/IP Status Report
    TCP/IP Pronet Device Drivers for 4.1BSD && November Internet Report:
    Summary, VAX & C70 TCP, HP3000, TAC Operational, SATNET, GATEWAYs
                 TOPS-20 TCP/IP Performance Measurements
----------------------------------------------------------------------

From: Raleigh F Romine <romine@SRC-Unix>
Subject: ComputerWorld TCP Article

Mike,
	The 14 Dec issue of ComputerWorld has an interesting
article on the ARPAnet TCP/IP cutover and it's commercial 
impact.  It might be of interest to TCP-IP Digest readers.

Raleigh

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

From: WOHL at CMU-20C
Subject: Why use user.host@forwarder ?

The proposed syntax of mailboxes for NCP to TCP forwarders
(see rfc801 pg 15) is user.host@forwader.   Since tops-20
user names can have dots in them this new syntax would make
the parsing of mailboxes ambigous.   The mailbox foo.xx@cmuc
could mean user foo on xx via cmuc or user foo.xx on cmuc.

The choice to overload the use of the dot would prevent
the many tops-20 sites from acting as relay hosts.
Why move away from the rfc733 idea that dot is part of a
username?
	Aaron

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

From: John C. Gilmore <GNU at MIT-AI>

Please add me to the list "tcp-ip".  I'm doing packet radio Internet
design and are having (what seems the usual) problems with Internet --
the addresses are too short (24 bits within network, requiring central
authority passing them out).

What we're plainning on, at the moment, is using those 24 bits to encode the
latitude and longitude to within a 1 degree-per-side rectangle, and add new
required "Option" fields containing the real addresses.  Is there a better 
approach short of junking Internet?

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

From: STECKEL at HARV-10
Subject: TCP-IP Implementations for TOPS-10

Sirs -
 As the entire staff of HARV-10, an ARPAnet site running a DEC PDP-10
under the TOPS-10 monitor, I am wondering if any other TOPS-10 site is
considering writing the conversion code.  If not, I would like to know
what document describes the exact method for sending an IP message via
the "1822" interface (BBN report describing IMP-HOST messages).
 regards,
 Geoff Steckel (STECKEL@HARV-10)

[ The connection is mentioned in passing in RFC790, which states that all
  InterNet messages are to be sent on Link 155 decimal, which is currently
  not used for ArpaNet Host-Host Protocol.  For the rest, RFCs 791, 792,
  and 793 should do the trick.  -Mike]

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

From: Rob Gurwitz <gurwitz at BBN-RSM>

Mike,
I'm sending you this update on the progress of our BBN VAX TCP/IP in hopes
of clearing up some misconceptions that might have formed in the community
about it.  Specifically, I want to clarify notions about "the BBN TCP/IP"
(we've done many implementations at various times), about Berkeley's role
in the implementation, and about general availability of the software.
Rob

*********

BBN has developed an implementation of TCP/IP for DEC's VAX(TM) family of
processors, that runs under the Berkeley 4.1BSD version of UNIX(TM).  The
development effort was funded by DARPA.  

BBN has been involved in the development of TCP/IP from its earliest stages,  
and was responsible for some of the first experimental implementations 
for TOPS20 and PDP-11s running UNIX.  The VAX TCP/IP, along with TCPs for 
the HP 3000 and the BBN C/30 Terminal Access Controller, is one of several 
"second generation" implementations being produced at BBN, and is intended 
for production use.  The VAX TCP/IP implementation has also been ported to
the BBNCC C/70, which runs UNIX Version 7.

Some important features of the BBN VAX TCP/IP are that it runs in the UNIX 
kernel for enhanced performance, it is a complete implementation of the TCP 
and IP protocols, and provides facilities for direct user access to the IP 
and underlying network protocols.  

Performance measurements indicate BBN VAX TCP/IP data throughput to be in
excess of 120K bits/second over an ARPANET interface.  Work is currently
underway in cooperation with the Berkeley Computer Science Research Group
to enhance BBN VAX TCP/IP performance over high speed local area networks.
Preliminary studies have measured throughputs in excess of 1.25M
bits/second with a prototype ETHERNET.  

In addition to the TCP/IP software for the VAX, BBN has developed 
implementations of the TELNET Virtual Terminal Protocol, File Transfer Protocol
(FTP), and Mail Transfer Protocol (MTP), for use with TCP.  The BBN VAX TCP/IP 
will support a variety of high speed local area network interfaces, as well 
as ARPANET interfaces.  The software is in beta-test at several sites
around the country, and will be generally available direct from BBN in 
Spring, 1982, or through Berkeley in their next software distribution.

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

From: tjt at mit-vax at mit-xx
Subject: pronet device drivers

We (MIT Laboratory for Computer Science) are working on such a driver
to work with the BBN TCP/IP that runs under 4.1BSD in loose
collobaration with Rob Gurwitz of BBN (they also have some Pronet
boards).  We hope to get something usable within a week or so, but
also expect to have some minor difficulty scheduling debugging time
on our machine (hence 1-2 weeks rather than 1-2 days).

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

From: Mike Muuss <tcp-ip@BRL>

One of the folks at Utah forwarded me the "November Internet Report"
and suggested that I extract portions of general interest and send
them to the whole list.  Undoubtably, some of you will have seen this
before, so you can just ignore the next 150 lines.

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

From: Dave Clark (DClark @MIT-Multics)
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, TCP/IP Summary

TCP/IP continues to get more visibility, including a recent
Computerworld story that reported some of the good performance
results from the VAX software. Attention in the performance
area is really important.

The performance results that the TOPS-20 study produced are
typical of other such investigations. One always hopes that
there is one really awful place where a fix will have a
wonderful result, but such is never the case. The time just
gets used up everywhere. The TOPS-20 study also identified a
problem that, in my opinion, will be the most important
performance issue: the sending of unnecessary packets.  Most
implementations have processing times that relate to number of
packets, and not to the number of bits sent. This being so,
sending half as many packets for the same data cuts the
processing time in half. There are few other places where one
can get this kind of improvement in one move. I have a chapter
of my implementor's guide that discusses how to send fewer
packets. Anyone wanting a early draft (cost: your comments
back) should let me know.

Now that the SMTP specification is out, people should think
about getting it implemented, if they have not already done
so. The mail aspect of conversion to TCP has many parts to it,
and we must make steady progress here to avoid missing
deadlines.

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

From:   Bob Hinden
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, BBN COMMUNICATIONS SYSTEMS DIVISION

VAX and C70 TCP

   Testing, bug fixing, and performance analysis continued on
   the VAX TCP.  The software was sent to Berkeley, CMU, ISI,
   Purdue (CSNET), Stanford, and MIT LCS.  BBN-VAX is running
   multi-homed on the ARPANET and the RCCNET. Things seem to
   be working fine, and we are providing good service to users
   on both nets.  Work is continuing on defining and enhancing
   the raw IP and local net user interfaces.  We will be
   merging in the Berkeley performance improvements for high
   speed local net use in the near future.

   On the C70 front, we have a TCP running on a NCP/TCP host.
   The software is performing well enough to put into
   production.  We are still working on tuning the TCP for the
   C70's smaller buffer complement, with good success.  We
   expect to be providing TCP service to the BBN Unix Cost
   Center C70s (at least 8 machines), including NCP/TCP mail
   forwarding, in the coming month.

HP3000

   We are currently working on a raw datagram user interface.
   The interface will be implemented with user intrinsics
   similar to the TCP intrinsics previously implemented.  Once
   the Interface has been implemented and tested, we will
   build an Internet name server.  Watch this space next month
   for an invitation to try our Internet name server.

TAC

   The first operational TAC in the Arpanet was installed at
   CCA. After a few problems the first day, it now seems quite
   stable. It has been up since November 24.

SATNET

   We installed a C/30 Satellite IMP at COMSAT Laboratories in
   Clarksburg, Maryland, the first time ever that a C/30 has
   served as a Satellite IMP in SATNET.  Connectivity between
   Clarksburg and the other Satellite IMPs on SATNET through
   the INTELSAT IV-A satellite remains untested, though, since
   the COMSAT Unattended Earth Terminal is non-functional with
   SATNET.  We have established the convention that C/30
   Satellite IMP version numbers begin with a 4 instead of a
   3, as shown in the MONITOR reports when typing ^P.

GATEWAY

   Development is continuing on the macro-11 gateways.  After
   GGP routing has been fully debugged, the new gateway should
   be ready for installation at the first site, the RCC
   gateway.

   The TIU and macro-11 gateway have been successfully tested
   as hosts on a V2LNI ring net.  The TIU was able to pass
   internet traffic through the V2LNI net to BBN-VAX on the
   DIV-5 net via the macro-11 gateway.

   The gateway VDH loader has become operational at NDRE.  The
   only way to load the NDRE gateway is via SATNET using the
   VDH loader.

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

From:   Charles Lynn
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, BBN INFORMATION SCIENCES DIVISION

Most of our efforts during November have been directed at
TOPS-20 TCP/IP performance.  In our timing experiments, we are
employing techniques such as PC sampling, control stack
sampling, and packet tracing.

PC-sampling of the TCP/IP process has produced discouragingly
flat histograms;  the highest frequency was about six percent
(checksumming).

A control stack sampling facility was then developed to
provide time breakdowns by logical function.  This reveals
that most of the time is spent processing incoming packets.
The data indicates several areas where further specific
monitoring might be useful:  free storage management, buffer
header usage (reuse vs allocating & deallocating both memory
and locks each time), and improvements in the decision-making
control structure for incoming packets, to be sure that the
most common cases are examined earliest.

Packet traces have revealed circumstances under which the TCP
is forced to process unnecessary ACKs and retransmissions.
For example, if the receiving user is using multiple buffers,
extra ACKs are sent which show an (insignificantly) larger
window before the transmitter has processed the previous ACK
(of data).  If 3 buffers are being used, filling the first
generates an ACK for the data and passes the buffer to the
user (leaving a window of two buffers).  The user then
processes the data and requests that the buffer be refilled
(increasing the window to three buffers).  Another ACK for the
old data with the increased window is sent to the transmitter
which has to process an "extra" packet.

In another situation, a receiver that sends an ACK before it
has processed all of its received packets interacts adversely
with the retransmitter, which does not retransmit a packet
until the previous one has been ACKed.  If the transmitter is
generating data faster than the net is processing it (or is
PUSHing) there may be several packets in the retransmission
queue.  When a packet is lost (but packets after it get
through) a timeout will cause the packet to be retransmitted.
Before the ACK for the retransmitted packet can arrive, the
following packet may timeout (but is not retransmitted because
the ACK for the prior has not yet arrived).  While the ACK for
the lost packet is traveling to the sender, the receiver is
processing the following packet which did get through.  When
the sender gets the ACK, it then retransmits the (second)
timedout packet.  Several unnecessary retransmissions may
follow until the other end can catch up.

We are also investigating another problem area that could add
significantly to the cpu-utilization of the TCP/IP:  use of
1822 interfaces that transfer all 36 bits of the PDP-10 word
to/from the net, necessitating a (possibly) expensive
bit-shuffle in behalf of the 8-bit-oriented TCP.  We are
presently performing experiments to determine the precise
cpu-cost of this bit-rearranging, and will publish the results
when available.  If this cost proves significant AND
replacement of the interface with an AN10/20 is not possible
AND the interface can be modified to perform 32-bit transfers
(true of both flavors of BBN 1822), we will provide the
software modifications needed to converse with the modified
interface.

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

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Wed Dec 23 22:40:01 1981
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #9

>From tcp-ip@brl Wed Dec 23 22:21:05 1981
TCP/IP Digest           Wednesday, 23 Dec 1981     Volume 1 : Issue 9

Today's Topics:
            ComputerWorld TCP Article && Packet Radio IP Woes
    TCP-IP Implementations for TOPS-10?  && BBN VAX TCP/IP Status Report
    TCP/IP Pronet Device Drivers for 4.1BSD && November Internet Report:
    Summary, VAX & C70 TCP, HP3000, TAC Operational, SATNET, GATEWAYs
                 TOPS-20 TCP/IP Performance Measurements
----------------------------------------------------------------------

From: Raleigh F Romine <romine@SRC-Unix>
Subject: ComputerWorld TCP Article

Mike,
	The 14 Dec issue of ComputerWorld has an interesting
article on the ARPAnet TCP/IP cutover and it's commercial 
impact.  It might be of interest to TCP-IP Digest readers.

Raleigh

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

From: WOHL at CMU-20C
Subject: Why use user.host@forwarder ?

The proposed syntax of mailboxes for NCP to TCP forwarders
(see rfc801 pg 15) is user.host@forwader.   Since tops-20
user names can have dots in them this new syntax would make
the parsing of mailboxes ambigous.   The mailbox foo.xx@cmuc
could mean user foo on xx via cmuc or user foo.xx on cmuc.

The choice to overload the use of the dot would prevent
the many tops-20 sites from acting as relay hosts.
Why move away from the rfc733 idea that dot is part of a
username?
	Aaron

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

From: John C. Gilmore <GNU at MIT-AI>

Please add me to the list "tcp-ip".  I'm doing packet radio Internet
design and are having (what seems the usual) problems with Internet --
the addresses are too short (24 bits within network, requiring central
authority passing them out).

What we're plainning on, at the moment, is using those 24 bits to encode the
latitude and longitude to within a 1 degree-per-side rectangle, and add new
required "Option" fields containing the real addresses.  Is there a better 
approach short of junking Internet?

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

From: STECKEL at HARV-10
Subject: TCP-IP Implementations for TOPS-10

Sirs -
 As the entire staff of HARV-10, an ARPAnet site running a DEC PDP-10
under the TOPS-10 monitor, I am wondering if any other TOPS-10 site is
considering writing the conversion code.  If not, I would like to know
what document describes the exact method for sending an IP message via
the "1822" interface (BBN report describing IMP-HOST messages).
 regards,
 Geoff Steckel (STECKEL@HARV-10)

[ The connection is mentioned in passing in RFC790, which states that all
  InterNet messages are to be sent on Link 155 decimal, which is currently
  not used for ArpaNet Host-Host Protocol.  For the rest, RFCs 791, 792,
  and 793 should do the trick.  -Mike]

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

From: Rob Gurwitz <gurwitz at BBN-RSM>

Mike,
I'm sending you this update on the progress of our BBN VAX TCP/IP in hopes
of clearing up some misconceptions that might have formed in the community
about it.  Specifically, I want to clarify notions about "the BBN TCP/IP"
(we've done many implementations at various times), about Berkeley's role
in the implementation, and about general availability of the software.
Rob

*********

BBN has developed an implementation of TCP/IP for DEC's VAX(TM) family of
processors, that runs under the Berkeley 4.1BSD version of UNIX(TM).  The
development effort was funded by DARPA.  

BBN has been involved in the development of TCP/IP from its earliest stages,  
and was responsible for some of the first experimental implementations 
for TOPS20 and PDP-11s running UNIX.  The VAX TCP/IP, along with TCPs for 
the HP 3000 and the BBN C/30 Terminal Access Controller, is one of several 
"second generation" implementations being produced at BBN, and is intended 
for production use.  The VAX TCP/IP implementation has also been ported to
the BBNCC C/70, which runs UNIX Version 7.

Some important features of the BBN VAX TCP/IP are that it runs in the UNIX 
kernel for enhanced performance, it is a complete implementation of the TCP 
and IP protocols, and provides facilities for direct user access to the IP 
and underlying network protocols.  

Performance measurements indicate BBN VAX TCP/IP data throughput to be in
excess of 120K bits/second over an ARPANET interface.  Work is currently
underway in cooperation with the Berkeley Computer Science Research Group
to enhance BBN VAX TCP/IP performance over high speed local area networks.
Preliminary studies have measured throughputs in excess of 1.25M
bits/second with a prototype ETHERNET.  

In addition to the TCP/IP software for the VAX, BBN has developed 
implementations of the TELNET Virtual Terminal Protocol, File Transfer Protocol
(FTP), and Mail Transfer Protocol (MTP), for use with TCP.  The BBN VAX TCP/IP 
will support a variety of high speed local area network interfaces, as well 
as ARPANET interfaces.  The software is in beta-test at several sites
around the country, and will be generally available direct from BBN in 
Spring, 1982, or through Berkeley in their next software distribution.

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

From: tjt at mit-vax at mit-xx
Subject: pronet device drivers

We (MIT Laboratory for Computer Science) are working on such a driver
to work with the BBN TCP/IP that runs under 4.1BSD in loose
collobaration with Rob Gurwitz of BBN (they also have some Pronet
boards).  We hope to get something usable within a week or so, but
also expect to have some minor difficulty scheduling debugging time
on our machine (hence 1-2 weeks rather than 1-2 days).

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

From: Mike Muuss <tcp-ip@BRL>

One of the folks at Utah forwarded me the "November Internet Report"
and suggested that I extract portions of general interest and send
them to the whole list.  Undoubtably, some of you will have seen this
before, so you can just ignore the next 150 lines.

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

From: Dave Clark (DClark @MIT-Multics)
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, TCP/IP Summary

TCP/IP continues to get more visibility, including a recent
Computerworld story that reported some of the good performance
results from the VAX software. Attention in the performance
area is really important.

The performance results that the TOPS-20 study produced are
typical of other such investigations. One always hopes that
there is one really awful place where a fix will have a
wonderful result, but such is never the case. The time just
gets used up everywhere. The TOPS-20 study also identified a
problem that, in my opinion, will be the most important
performance issue: the sending of unnecessary packets.  Most
implementations have processing times that relate to number of
packets, and not to the number of bits sent. This being so,
sending half as many packets for the same data cuts the
processing time in half. There are few other places where one
can get this kind of improvement in one move. I have a chapter
of my implementor's guide that discusses how to send fewer
packets. Anyone wanting a early draft (cost: your comments
back) should let me know.

Now that the SMTP specification is out, people should think
about getting it implemented, if they have not already done
so. The mail aspect of conversion to TCP has many parts to it,
and we must make steady progress here to avoid missing
deadlines.

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

From:   Bob Hinden
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, BBN COMMUNICATIONS SYSTEMS DIVISION

VAX and C70 TCP

   Testing, bug fixing, and performance analysis continued on
   the VAX TCP.  The software was sent to Berkeley, CMU, ISI,
   Purdue (CSNET), Stanford, and MIT LCS.  BBN-VAX is running
   multi-homed on the ARPANET and the RCCNET. Things seem to
   be working fine, and we are providing good service to users
   on both nets.  Work is continuing on defining and enhancing
   the raw IP and local net user interfaces.  We will be
   merging in the Berkeley performance improvements for high
   speed local net use in the near future.

   On the C70 front, we have a TCP running on a NCP/TCP host.
   The software is performing well enough to put into
   production.  We are still working on tuning the TCP for the
   C70's smaller buffer complement, with good success.  We
   expect to be providing TCP service to the BBN Unix Cost
   Center C70s (at least 8 machines), including NCP/TCP mail
   forwarding, in the coming month.

HP3000

   We are currently working on a raw datagram user interface.
   The interface will be implemented with user intrinsics
   similar to the TCP intrinsics previously implemented.  Once
   the Interface has been implemented and tested, we will
   build an Internet name server.  Watch this space next month
   for an invitation to try our Internet name server.

TAC

   The first operational TAC in the Arpanet was installed at
   CCA. After a few problems the first day, it now seems quite
   stable. It has been up since November 24.

SATNET

   We installed a C/30 Satellite IMP at COMSAT Laboratories in
   Clarksburg, Maryland, the first time ever that a C/30 has
   served as a Satellite IMP in SATNET.  Connectivity between
   Clarksburg and the other Satellite IMPs on SATNET through
   the INTELSAT IV-A satellite remains untested, though, since
   the COMSAT Unattended Earth Terminal is non-functional with
   SATNET.  We have established the convention that C/30
   Satellite IMP version numbers begin with a 4 instead of a
   3, as shown in the MONITOR reports when typing ^P.

GATEWAY

   Development is continuing on the macro-11 gateways.  After
   GGP routing has been fully debugged, the new gateway should
   be ready for installation at the first site, the RCC
   gateway.

   The TIU and macro-11 gateway have been successfully tested
   as hosts on a V2LNI ring net.  The TIU was able to pass
   internet traffic through the V2LNI net to BBN-VAX on the
   DIV-5 net via the macro-11 gateway.

   The gateway VDH loader has become operational at NDRE.  The
   only way to load the NDRE gateway is via SATNET using the
   VDH loader.

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

From:   Charles Lynn
Sender: WESTINE at USC-ISIF
Subject: November Internet Report, BBN INFORMATION SCIENCES DIVISION

Most of our efforts during November have been directed at
TOPS-20 TCP/IP performance.  In our timing experiments, we are
employing techniques such as PC sampling, control stack
sampling, and packet tracing.

PC-sampling of the TCP/IP process has produced discouragingly
flat histograms;  the highest frequency was about six percent
(checksumming).

A control stack sampling facility was then developed to
provide time breakdowns by logical function.  This reveals
that most of the time is spent processing incoming packets.
The data indicates several areas where further specific
monitoring might be useful:  free storage management, buffer
header usage (reuse vs allocating & deallocating both memory
and locks each time), and improvements in the decision-making
control structure for incoming packets, to be sure that the
most common cases are examined earliest.

Packet traces have revealed circumstances under which the TCP
is forced to process unnecessary ACKs and retransmissions.
For example, if the receiving user is using multiple buffers,
extra ACKs are sent which show an (insignificantly) larger
window before the transmitter has processed the previous ACK
(of data).  If 3 buffers are being used, filling the first
generates an ACK for the data and passes the buffer to the
user (leaving a window of two buffers).  The user then
processes the data and requests that the buffer be refilled
(increasing the window to three buffers).  Another ACK for the
old data with the increased window is sent to the transmitter
which has to process an "extra" packet.

In another situation, a receiver that sends an ACK before it
has processed all of its received packets interacts adversely
with the retransmitter, which does not retransmit a packet
until the previous one has been ACKed.  If the transmitter is
generating data faster than the net is processing it (or is
PUSHing) there may be several packets in the retransmission
queue.  When a packet is lost (but packets after it get
through) a timeout will cause the packet to be retransmitted.
Before the ACK for the retransmitted packet can arrive, the
following packet may timeout (but is not retransmitted because
the ACK for the prior has not yet arrived).  While the ACK for
the lost packet is traveling to the sender, the receiver is
processing the following packet which did get through.  When
the sender gets the ACK, it then retransmits the (second)
timedout packet.  Several unnecessary retransmissions may
follow until the other end can catch up.

We are also investigating another problem area that could add
significantly to the cpu-utilization of the TCP/IP:  use of
1822 interfaces that transfer all 36 bits of the PDP-10 word
to/from the net, necessitating a (possibly) expensive
bit-shuffle in behalf of the 8-bit-oriented TCP.  We are
presently performing experiments to determine the precise
cpu-cost of this bit-rearranging, and will publish the results
when available.  If this cost proves significant AND
replacement of the interface with an AN10/20 is not possible
AND the interface can be modified to perform 32-bit transfers
(true of both flavors of BBN 1822), we will provide the
software modifications needed to converse with the modified
interface.

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

END OF DOCUMENT