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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Sun Nov  1 22:16:27 1981
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #5

>From tcp-ip@brl Sun Nov  1 21:56:45 1981
TCP/IP Digest          Sunday, 1 November 1981     Volume 1 : Issue 5

Today's Topics:
                   Solicitation for More Contributions
                       More on BBN TCP for TOPS-20
                Z8000 based TCP and IP Front End Machine
----------------------------------------------------------------------

From:     Mike Muuss
Reply-to: tcp-ip@brl
Subject:  More Contributions?

Nearly a week has passed since the last issue, so I am publishing the
three letters that have arrived in the interim .  Considering the size of
the mailing list, I can hardly immagine that we have heard from
everybody who is working on networking implementations.  C'mon!  Lets
hear from everybody.
					Cheers,
					-Mike

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

Date: 27 Oct 1981 1810-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: List maintainence

You can announce [Rutgers]<TCP>MAIL.TXT as an archive point if you like.

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

Date: 26 Oct 1981 0013-PST
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: Re:   TCP-IP Digest, Vol 1 #4

     I'd like to answer a few confusions about my position
regarding the TOPS-20 implementation of TCP available from BBN.
I am not, nor have I ever been, opposed to the TCP protocol.  I
was very impressed with the work done at the DoD Protocol
Standards conference a year ago.  I've been urging the managers
of the Stanford local network effort to adopt TCP/IP as the local
network protocol for the past two years now.  It is the software
that is presently available for TOPS-20 that I find distasteful.

     I have had some preliminary discussions with various people
at DEC about this issue, and I have determined that they are
addressing at least some of the objections.  If the product DEC
releases is less than what we would like, it is because of their
rush to meet the deadline.  It's a safe assumption that there is
no way that DEC can possibly have a rewritten TCP implementation
for TOPS-20 out in the field by the deadline date.  I believe
that DEC is doing its best.  DEC's customers are probably best
off encouraging the current project but being firm in stating
that we must have a rewrite which addresses the performance
problems of BBN's TCP.

     So far as the comments on how to "help/force people [to]
implement TCP/IP" go:
 (1) There are those of us who would feel that not being able to
reach our systems from a TIP is a feature, and not a problem at
all!  Entirely too many high school kids abuse the network from
TIPs.
 (2) "Getting the mail through" can be accomplished by other
means than implementing TCP.
 (3) Services only accessible via TCP/IP are a good reason for
implementing TCP/IP.  The example given was not a good one, but I
can see other valuable resources being TCP/IP only.  I hope by
the time such resources exist there will be a better
implementation of TCP/IP available.
 (4) The last point is patently ridiculous.  US mail existed
before electronic mail, and is still a commonly used method for
communication between Investigators and their Sponsors.

     The whole tone of "forcing" is itself inane.  The intent of
my message was to discuss getting things moving towards solving
the software situation, not to create an anti-TCP/IP lobby.  The
present TCP/IP software for TOPS-20 is unpalatable for most
sites; if "forced" to implement TCP/IP on our systems we will
probably have to write the software ourselves.  Of course that
would keep us from completing the projects our Network Sponsors
are supporting us to do...

-- Mark --

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

Date: Mon, 26 Oct 1981 2236-EST
From: steve at MITRE
Subject: Z8000 TCP and IP

Mike,
        I have been watching your digest with great interest.  We
have produced a micro-based  TCP/IP  here  at  MITRE  which  your
readers may find useful.

        We have been involved in a series of projects whose focus
was  to  make  network  access  (both  local  and  long  haul) as
straightforward as using common computer peripherals.   The  idea
was that just as hardware controllers handle the particulars of a
disk cylinder centerline or an end of tape sensor,  some  of  the
new  microprocessors, in our case the Zilog Z8000, should make it
possible to construct a "network controller" to handle  the  par-
ticulars  of packet ordering and flow control.  To a large extent
we have succeeded with a TCP/IP network controller supported by a
Z8000 microprocessor box.  The box is currently interfaced to our
UNIX system via a UMC-Z80.  It is accessed from the  users  point
of view as a set of I/O like management calls (open, close, read,
write, and special) which are transported via  a  network  access
protocol to the outboard box.

        The box has 64K bytes of Ram, 32K bytes of Rom,  a  Z8002
micro,  and  a  serial Usart (880K BPS max).  All of the software
was written in C using a locally brewed version of the portable C
compiler.   The  interesting  aspect of the box is that it inter-
faces as easily to a local network (in our case a  the  MITRE  RF
cable  backbone) as it does to the ARPA network.  Other than dif-
ferent round trip delays, host user-level software sees  no  dis-
tinction  between  the two networks.  The long haul metamorphosis
involves a new device driver in the Z8000 and the addition of  an
ACC  1822 hardware interface (yes, ACC makes one).  The resulting
set of building blocks allows us to interface a host, a  terminal
concentrator  version  and  other units to a local net and have a
gateway to the arpanet.

        While  a custom protocol would be faster, we believe that
the longer term interoperability of TCP/IP  will  be  well  worth
some short term overhead.  The performance even with TCP/IP isn't
that bad in that we have measured two user processes talking  via
TCP/IP  over  the  cable  at 350K BPS.  We have measured rates as
high at 450K BPS when user I/O buffer sizes are set at  8K  bytes
per  I/O.   The  Internet  Protocol  contains our lowest level of
addressing.  This allows us to address local units  in  the  same
way  we address remote units two or three networks away.  We have
been experimenting with a version  of  TCP/IP  which  allows  the
optional  specification of some TCP and IP mechanisms.  The basic
conclusion is that cable signalling rates are so  fast  that  the
effect of 300 bit TCP/IP headers has negligible impact on perfor-
mance.

        Our  work  this  year involves constructing a new version
10M BPS controller with  multi-microprocessor  capabilities.   We
believe  the  resulting  effective  TCP/IP  communications  rates
should be well above 1M BPS  and  that  the  multi-microprocessor
capabilities  should make for an interesting distributed process-
ing base.

        There  a  couple  of  reports available if people are in-
terested.

        Regards
        Steve Holmgren

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

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 81 23:18:56-EDT (Sun)
From:      Mike Muuss <tcp-ip@brl>
To:        tcp-ip at Brl
Subject:   TCP-IP Digest, Vol 1 #5
TCP/IP Digest          Sunday, 1 November 1981     Volume 1 : Issue 5

Today's Topics:
                   Solicitation for More Contributions
                       More on BBN TCP for TOPS-20
                Z8000 based TCP and IP Front End Machine
----------------------------------------------------------------------

From:     Mike Muuss
Reply-to: tcp-ip@brl
Subject:  More Contributions?

Nearly a week has passed since the last issue, so I am publishing the
three letters that have arrived in the interim .  Considering the size of
the mailing list, I can hardly immagine that we have heard from
everybody who is working on networking implementations.  C'mon!  Lets
hear from everybody.
					Cheers,
					-Mike

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

Date: 27 Oct 1981 1810-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: List maintainence

You can announce [Rutgers]<TCP>MAIL.TXT as an archive point if you like.

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

Date: 26 Oct 1981 0013-PST
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: Re:   TCP-IP Digest, Vol 1 #4

     I'd like to answer a few confusions about my position
regarding the TOPS-20 implementation of TCP available from BBN.
I am not, nor have I ever been, opposed to the TCP protocol.  I
was very impressed with the work done at the DoD Protocol
Standards conference a year ago.  I've been urging the managers
of the Stanford local network effort to adopt TCP/IP as the local
network protocol for the past two years now.  It is the software
that is presently available for TOPS-20 that I find distasteful.

     I have had some preliminary discussions with various people
at DEC about this issue, and I have determined that they are
addressing at least some of the objections.  If the product DEC
releases is less than what we would like, it is because of their
rush to meet the deadline.  It's a safe assumption that there is
no way that DEC can possibly have a rewritten TCP implementation
for TOPS-20 out in the field by the deadline date.  I believe
that DEC is doing its best.  DEC's customers are probably best
off encouraging the current project but being firm in stating
that we must have a rewrite which addresses the performance
problems of BBN's TCP.

     So far as the comments on how to "help/force people [to]
implement TCP/IP" go:
 (1) There are those of us who would feel that not being able to
reach our systems from a TIP is a feature, and not a problem at
all!  Entirely too many high school kids abuse the network from
TIPs.
 (2) "Getting the mail through" can be accomplished by other
means than implementing TCP.
 (3) Services only accessible via TCP/IP are a good reason for
implementing TCP/IP.  The example given was not a good one, but I
can see other valuable resources being TCP/IP only.  I hope by
the time such resources exist there will be a better
implementation of TCP/IP available.
 (4) The last point is patently ridiculous.  US mail existed
before electronic mail, and is still a commonly used method for
communication between Investigators and their Sponsors.

     The whole tone of "forcing" is itself inane.  The intent of
my message was to discuss getting things moving towards solving
the software situation, not to create an anti-TCP/IP lobby.  The
present TCP/IP software for TOPS-20 is unpalatable for most
sites; if "forced" to implement TCP/IP on our systems we will
probably have to write the software ourselves.  Of course that
would keep us from completing the projects our Network Sponsors
are supporting us to do...

-- Mark --

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

Date: Mon, 26 Oct 1981 2236-EST
From: steve at MITRE
Subject: Z8000 TCP and IP

Mike,
        I have been watching your digest with great interest.  We
have produced a micro-based  TCP/IP  here  at  MITRE  which  your
readers may find useful.

        We have been involved in a series of projects whose focus
was  to  make  network  access  (both  local  and  long  haul) as
straightforward as using common computer peripherals.   The  idea
was that just as hardware controllers handle the particulars of a
disk cylinder centerline or an end of tape sensor,  some  of  the
new  microprocessors, in our case the Zilog Z8000, should make it
possible to construct a "network controller" to handle  the  par-
ticulars  of packet ordering and flow control.  To a large extent
we have succeeded with a TCP/IP network controller supported by a
Z8000 microprocessor box.  The box is currently interfaced to our
UNIX system via a UMC-Z80.  It is accessed from the  users  point
of view as a set of I/O like management calls (open, close, read,
write, and special) which are transported via  a  network  access
protocol to the outboard box.

        The box has 64K bytes of Ram, 32K bytes of Rom,  a  Z8002
micro,  and  a  serial Usart (880K BPS max).  All of the software
was written in C using a locally brewed version of the portable C
compiler.   The  interesting  aspect of the box is that it inter-
faces as easily to a local network (in our case a  the  MITRE  RF
cable  backbone) as it does to the ARPA network.  Other than dif-
ferent round trip delays, host user-level software sees  no  dis-
tinction  between  the two networks.  The long haul metamorphosis
involves a new device driver in the Z8000 and the addition of  an
ACC  1822 hardware interface (yes, ACC makes one).  The resulting
set of building blocks allows us to interface a host, a  terminal
concentrator  version  and  other units to a local net and have a
gateway to the arpanet.

        While  a custom protocol would be faster, we believe that
the longer term interoperability of TCP/IP  will  be  well  worth
some short term overhead.  The performance even with TCP/IP isn't
that bad in that we have measured two user processes talking  via
TCP/IP  over  the  cable  at 350K BPS.  We have measured rates as
high at 450K BPS when user I/O buffer sizes are set at  8K  bytes
per  I/O.   The  Internet  Protocol  contains our lowest level of
addressing.  This allows us to address local units  in  the  same
way  we address remote units two or three networks away.  We have
been experimenting with a version  of  TCP/IP  which  allows  the
optional  specification of some TCP and IP mechanisms.  The basic
conclusion is that cable signalling rates are so  fast  that  the
effect of 300 bit TCP/IP headers has negligible impact on perfor-
mance.

        Our  work  this  year involves constructing a new version
10M BPS controller with  multi-microprocessor  capabilities.   We
believe  the  resulting  effective  TCP/IP  communications  rates
should be well above 1M BPS  and  that  the  multi-microprocessor
capabilities  should make for an interesting distributed process-
ing base.

        There  a  couple  of  reports available if people are in-
terested.

        Regards
        Steve Holmgren

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

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Wed Nov 18 05:50:19 1981
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #6

>From tcp-ip@brl Wed Nov 18 05:33:31 1981
TCP/IP Digest           Wednesday, 11 Nov 1981     Volume 1 : Issue 6

Today's Topics:
                       Administrivia:  Long Delay
                  Disabling NCPs -- Directory Service?
               TOPS-20 TCP Defenses? -- TCP/IP for Cybers?
                  Unix/ArpaNet TCP Problems & Solutions
                       TCP/IP Performance on VAXen
                 Berkeley Enhanced TCP/IP for 4BSD UNIX
----------------------------------------------------------------------

From:  Mike Muuss
Subject:  Administrivia

Hello again folks!  Sorry about the long delay between this digest and
the previous one -- I was in Denver on travel, and could not get to a
terminal.  I hope to send out future digests as soon as enough material
has been accumulated.
					Cheers,
					 -Mike

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

From: POSTEL at USC-ISIF
Subject: Disabling NCPs

There has been some talk of "forcing" the move to TCP by various 
administrative and policy measures.  There was also a claim that
there was no technical way to force the abandonment of NCP.  It
should be pointed out that a quite simple modification to the IMP
program would enable the IMPs to filter out and discard all NCP
traffic.  As far as i know, there has been no decision to do this,
but you should be aware that it is technical feasible.

--jon.

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

From: Harris A. Meyers <Meyers at SRI-KL>
Subject: Request

A useful fuction for this list to perform might be to produce a directory of
who has IP/TCP available for what machines and operating systems.
In particular I am looking for a version to run on IBM's VM/CMS.

harris

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

Subject: Re: TOPS 20 TCP/IP
From: mike at RAND-UNIX

I have often heard criticisms of TOPS 20 TCP/IP implementation, but
never a defense.  Does anyone from BBN or ARPA care to defend their
implementation or do they agree with the criticisms?

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

From: roya at UTEXAS-11 
Subject: Is there TCP/IP for Cyber machines?

	Do any of you know any sites that might have or is planning to
	implement TCP/IP for CDC Cyber machines like 175 with NOS like
	operating system?
Roya

[ Tektronix Labs (Clem Cole et.al.) have already implemented
  TCP and IP in RatFor for their Cyber, running under NOS.   -Mike ]

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

From: greg at NPRDC
Subject: Future contributions

Now that all the special interest groups have spoken, can we get back to
the original subject?  In case you've forgotten, it was "Unix/ARPAnet TCP
problems and solutions."  Although I'm interested in the various problems/
possibilities of using TCP on other operating systems or other ethers, at
a minimum, our mutual interest is getting our machines running TCP before
the deadline.  (Probabally this list goes a little farther than that; to
those people, I appologize.  But we are the ones with the deadline fast
approaching.)  Maybe we can discuss theoretical issues later, but I am
more interested in the practical issues -- namely, who has TCP up?  How
is it connected to the ARPAnet (or even another ether, if the problems/
solutions are similar)?  What problems were encountered?  How fast is it?
How does it compare in simplicity/performance/transparancy/completeness/
functionality/limitations/etc. with the other possibilities?  So far, we
have heard of two real choices (assuming that we're not going to have to
buy any additional hardware): BBN and 3COM.  Who's got them up?  How
connected?  (I am VDH, so solutions that don't have a VDH driver are
uninteresting.)  Speak up; now's your chance to brag, and you can do the
rest of us a real service.

[ Actually, I had hoped that this digest could serve as a forum for
  technical discussion of networking for ALL systems, but clearly the
  transition to TCP for current ArpaNet Hosts is the primary motivator.
  I hope that this list will not restrict itself just to UNIX, though.
      -Mike]

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

Subject: TCP/IP Performance on VAX
From: CERF at USC-ISI

UC Berkeley has been developing a paging UNIX(TM) for the VAX
based on V7 UNIX (TM-Western Electric).  BBN has been developing
a TCP/IP for this VAX UNIX(TM) and UCB recently reported data
bandwidths of Mb/sec over a 3 Mb/s Ethernet running TCP/IP to
TCP/IP including checksumming.  This figure obtained on VAX
11/750 using 1 kilobyte packets.

A point of contact for the Berkeley + BBN VAX UNIX(TM) is Prof.
Robert Fabry (ARPAVAX.Fabry@Berkeley).

A point of contact at BBN is Gurwitz@BBN-RSM(Rob Gurwitz).

Vint Cerf (bd)

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

From: ARPAVAX .wnj at Berkeley
Subject: tcp-ip digest contribution
Cc: gurwitz@bbn-unix

Moderator: Here is a description of the work we are doing a
Berkeley with tcp-ip.  I hope it is in time for this weeks
digest.  We have enjoyed the past digests and hope that future
digests will be as interesting.

	Regards,
		Bill Joy

===== begin =====

	The Computer Systems Research Group at Berkeley is
enhancing the UNIX operating system with DARPA support.
We are improving UNIX memory management facilities, working
on extensions to UNIX to support better inter-process communication, and
incorporating support for both local and long haul networks.  In
particular, we expect to try using the INTERNET protocols on a number
of different commercially available local network interfaces.

	The basis for our INTERNET protocols is the TCP/IP
implementation done by Rob Gurwitz at BBN.  While this TCP has more
than adequate performance for use in the ARPANET context, we need
extremely good performance to be able to use the protocols as the basis
for construction of distributed UNIX applications between machines on a
local network.  In particular, we wish to insure that data can be
transferred rapidly between VAX machines on 10 Megabaud Ethernet
cables.  Our current file system organization uses 1024 byte records,
while a newer, high-performance file system will use 4096 byte
records.  We are therefore interested in the effective transmission of
records of these sizes.  We are also interested in low per-packet
overhead for distributed applications which exchange many messages.

	We have just finished about three weeks of tuning of the BBN TCP/IP
for our 3 Megabaud prototype Ethernet.  We had previously brought
TCP/IP up on the Ethernet and were interested in learning more about
the internals of TCP and discovering whether the protocol would be a
bottleneck when running on a local network.  The results we have
obtained suggest that this is not the case.

	As an experiment to investigate the performance of the resulting
TCP/IP implementation, we transmitted 4 Megabytes of data between two
user processes on different machines.  The transfer was partitioned
into 1024 byte records and encapsulated in 1068 byte Ethernet packets.
Sending the data from our 11/750 to our 11/780 through TCP/IP takes 28
seconds.  This includes all the time needed to set up and tear down the
connections, for an user-user throughput of 1.2 Megabaud.  During this
time the 11/750 is CPU saturated, but the 11/780 has about 30% idle
time.  The time spent in the system processing the data is spread out
among handling for the Ethernet (20%), IP packet processing (10%), TCP
processing (30%), checksumming (25%), and user system call handling
(15%), with no single part of the handling dominating the time in the
system.

	The TCP performance exceeds the throughput of the current
VAX/UNIX file system by a factor of 3, due to the small block size of
the UNIX file system.  It comes within a factor of 2 of our per-spindle
performance of a early prototype of a new file system organization we
are working on.  The relative speed of the TCP/IP protocol and the file
system suggests that we will be able to transfer volumes of data
regularly between machines without any special protocols.  The limited
bandwidth of our 3 Megabaud cable may be a bottleneck until we put in
one or more 10 Megabaud cables.

	Higher rates can be expected between VAX-11/780's, but we have
no direct measurements yet, as we have only one 780 with easily accessible
down time.  Improvements are yet possible within the bounds of the
TCP/IP protocol and the new Ethernet standard (which limits packets to
about 1500 bytes).  In particular, we may use IP fragmentation and
reassembly on the local network to allow the TCP and higher level
system code to process 4096 byte data records (which is a more natural
block size for the newer system we are working on, being a basic file
system data page size.)  This is convenient within the bounds of the
Ethernet standards only because IP supports fragmentation and
reassembly in a general way.  Simple techniques are also available
which would reduce the number of ACK's by a significant amount to
further speed the TCP.

	Using information gathered from UNIX kernel profiling we can
estimate the speed improvements possible given a 10 Megabaud cable.
(All of these projections will be for user-user throughput between
11/750's.)  Switching to 4096 byte segments in TCP transfers, while
fragmenting at the IP layer (to stay within the packet length
restriction of the Ethernet standard) we estimate an increased
throughput of 1.9 Megabaud.  This is with an interface which is
functionality equivalent to our current prototype Ethernets.  We plan
on changing UNIX soon so that user i/o buffers are naturally page aligned.
This would eliminate a copy of the data (when it is read) to raise the
throughput to about 2.25 Megabaud.  (This speedup only at the receiver
gives an end-end speedup because the receiving process otherwise has
more work to do.)  With checksum calculation support from the interface
hardware the user-user bandwidth would rise to about 3.5 Megabaud.
At this point the major overhead is the processing of the 4 interrupts
for the fragments of the 4k packets; a transmission medium which
allowed us to use 4k packets would let the bandwidth rise to about
6.6 Megabaud, user-user.   A final improvement would be to implement a
variant on the send system call which released the virtual memory when
the message was sent.  This would be very useful for servers and could
also be used by the standard i/o library.  This would reduce the
transmit overhead (which at this point should be greater than the
receive overhead) making the final throughput about 8 Megabaud.

	On 11/780's, these numbers typically scale up by 1.4 so that we
can project the throughput with the improvements described above to be
about 11.2 Megabaud, user-user.  While factors in the VAX architecture other
than the protocol might well dominate before this bandwidth is achieved,
this means that high data rates through the protocol can be achieved
with a relatively small percentage of the processor.

	We are working on IPC facilities for UNIX which will interface
to the INTERNET protocol family, and allow us to construct distributed
applications for UNIX without explicit dependence on the network layer
protocols.  The measurements reported here suggest that we do not need
to look for more efficient local network protocols, but will need
to support other protocols only for inter-operability with other
networks and systems.

	We will be working with Rob Gurwitz at BBN in the coming weeks,
combining our version of TCP/IP with his current version.  We look
forward to making a high-performance version of the protocol available
to the VAX/UNIX community at an early date.

	Regards,
		Bill Joy and Bob Fabry

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

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 81 5:39:59-EDT (Wed)
From:      Mike Muuss <tcp-ip@brl>
To:        list:
Subject:   TCP-IP Digest, Vol 1 #6
TCP/IP Digest           Wednesday, 11 Nov 1981     Volume 1 : Issue 6

Today's Topics:
                       Administrivia:  Long Delay
                  Disabling NCPs -- Directory Service?
               TOPS-20 TCP Defenses? -- TCP/IP for Cybers?
                  Unix/ArpaNet TCP Problems & Solutions
                       TCP/IP Performance on VAXen
                 Berkeley Enhanced TCP/IP for 4BSD UNIX
----------------------------------------------------------------------

From:  Mike Muuss
Subject:  Administrivia

Hello again folks!  Sorry about the long delay between this digest and
the previous one -- I was in Denver on travel, and could not get to a
terminal.  I hope to send out future digests as soon as enough material
has been accumulated.
					Cheers,
					 -Mike

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

From: POSTEL at USC-ISIF
Subject: Disabling NCPs

There has been some talk of "forcing" the move to TCP by various 
administrative and policy measures.  There was also a claim that
there was no technical way to force the abandonment of NCP.  It
should be pointed out that a quite simple modification to the IMP
program would enable the IMPs to filter out and discard all NCP
traffic.  As far as i know, there has been no decision to do this,
but you should be aware that it is technical feasible.

--jon.

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

From: Harris A. Meyers <Meyers at SRI-KL>
Subject: Request

A useful fuction for this list to perform might be to produce a directory of
who has IP/TCP available for what machines and operating systems.
In particular I am looking for a version to run on IBM's VM/CMS.

harris

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

Subject: Re: TOPS 20 TCP/IP
From: mike at RAND-UNIX

I have often heard criticisms of TOPS 20 TCP/IP implementation, but
never a defense.  Does anyone from BBN or ARPA care to defend their
implementation or do they agree with the criticisms?

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

From: roya at UTEXAS-11 
Subject: Is there TCP/IP for Cyber machines?

	Do any of you know any sites that might have or is planning to
	implement TCP/IP for CDC Cyber machines like 175 with NOS like
	operating system?
Roya

[ Tektronix Labs (Clem Cole et.al.) have already implemented
  TCP and IP in RatFor for their Cyber, running under NOS.   -Mike ]

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

From: greg at NPRDC
Subject: Future contributions

Now that all the special interest groups have spoken, can we get back to
the original subject?  In case you've forgotten, it was "Unix/ARPAnet TCP
problems and solutions."  Although I'm interested in the various problems/
possibilities of using TCP on other operating systems or other ethers, at
a minimum, our mutual interest is getting our machines running TCP before
the deadline.  (Probabally this list goes a little farther than that; to
those people, I appologize.  But we are the ones with the deadline fast
approaching.)  Maybe we can discuss theoretical issues later, but I am
more interested in the practical issues -- namely, who has TCP up?  How
is it connected to the ARPAnet (or even another ether, if the problems/
solutions are similar)?  What problems were encountered?  How fast is it?
How does it compare in simplicity/performance/transparancy/completeness/
functionality/limitations/etc. with the other possibilities?  So far, we
have heard of two real choices (assuming that we're not going to have to
buy any additional hardware): BBN and 3COM.  Who's got them up?  How
connected?  (I am VDH, so solutions that don't have a VDH driver are
uninteresting.)  Speak up; now's your chance to brag, and you can do the
rest of us a real service.

[ Actually, I had hoped that this digest could serve as a forum for
  technical discussion of networking for ALL systems, but clearly the
  transition to TCP for current ArpaNet Hosts is the primary motivator.
  I hope that this list will not restrict itself just to UNIX, though.
      -Mike]

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

Subject: TCP/IP Performance on VAX
From: CERF at USC-ISI

UC Berkeley has been developing a paging UNIX(TM) for the VAX
based on V7 UNIX (TM-Western Electric).  BBN has been developing
a TCP/IP for this VAX UNIX(TM) and UCB recently reported data
bandwidths of Mb/sec over a 3 Mb/s Ethernet running TCP/IP to
TCP/IP including checksumming.  This figure obtained on VAX
11/750 using 1 kilobyte packets.

A point of contact for the Berkeley + BBN VAX UNIX(TM) is Prof.
Robert Fabry (ARPAVAX.Fabry@Berkeley).

A point of contact at BBN is Gurwitz@BBN-RSM(Rob Gurwitz).

Vint Cerf (bd)

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

From: ARPAVAX .wnj at Berkeley
Subject: tcp-ip digest contribution
Cc: gurwitz@bbn-unix

Moderator: Here is a description of the work we are doing a
Berkeley with tcp-ip.  I hope it is in time for this weeks
digest.  We have enjoyed the past digests and hope that future
digests will be as interesting.

	Regards,
		Bill Joy

===== begin =====

	The Computer Systems Research Group at Berkeley is
enhancing the UNIX operating system with DARPA support.
We are improving UNIX memory management facilities, working
on extensions to UNIX to support better inter-process communication, and
incorporating support for both local and long haul networks.  In
particular, we expect to try using the INTERNET protocols on a number
of different commercially available local network interfaces.

	The basis for our INTERNET protocols is the TCP/IP
implementation done by Rob Gurwitz at BBN.  While this TCP has more
than adequate performance for use in the ARPANET context, we need
extremely good performance to be able to use the protocols as the basis
for construction of distributed UNIX applications between machines on a
local network.  In particular, we wish to insure that data can be
transferred rapidly between VAX machines on 10 Megabaud Ethernet
cables.  Our current file system organization uses 1024 byte records,
while a newer, high-performance file system will use 4096 byte
records.  We are therefore interested in the effective transmission of
records of these sizes.  We are also interested in low per-packet
overhead for distributed applications which exchange many messages.

	We have just finished about three weeks of tuning of the BBN TCP/IP
for our 3 Megabaud prototype Ethernet.  We had previously brought
TCP/IP up on the Ethernet and were interested in learning more about
the internals of TCP and discovering whether the protocol would be a
bottleneck when running on a local network.  The results we have
obtained suggest that this is not the case.

	As an experiment to investigate the performance of the resulting
TCP/IP implementation, we transmitted 4 Megabytes of data between two
user processes on different machines.  The transfer was partitioned
into 1024 byte records and encapsulated in 1068 byte Ethernet packets.
Sending the data from our 11/750 to our 11/780 through TCP/IP takes 28
seconds.  This includes all the time needed to set up and tear down the
connections, for an user-user throughput of 1.2 Megabaud.  During this
time the 11/750 is CPU saturated, but the 11/780 has about 30% idle
time.  The time spent in the system processing the data is spread out
among handling for the Ethernet (20%), IP packet processing (10%), TCP
processing (30%), checksumming (25%), and user system call handling
(15%), with no single part of the handling dominating the time in the
system.

	The TCP performance exceeds the throughput of the current
VAX/UNIX file system by a factor of 3, due to the small block size of
the UNIX file system.  It comes within a factor of 2 of our per-spindle
performance of a early prototype of a new file system organization we
are working on.  The relative speed of the TCP/IP protocol and the file
system suggests that we will be able to transfer volumes of data
regularly between machines without any special protocols.  The limited
bandwidth of our 3 Megabaud cable may be a bottleneck until we put in
one or more 10 Megabaud cables.

	Higher rates can be expected between VAX-11/780's, but we have
no direct measurements yet, as we have only one 780 with easily accessible
down time.  Improvements are yet possible within the bounds of the
TCP/IP protocol and the new Ethernet standard (which limits packets to
about 1500 bytes).  In particular, we may use IP fragmentation and
reassembly on the local network to allow the TCP and higher level
system code to process 4096 byte data records (which is a more natural
block size for the newer system we are working on, being a basic file
system data page size.)  This is convenient within the bounds of the
Ethernet standards only because IP supports fragmentation and
reassembly in a general way.  Simple techniques are also available
which would reduce the number of ACK's by a significant amount to
further speed the TCP.

	Using information gathered from UNIX kernel profiling we can
estimate the speed improvements possible given a 10 Megabaud cable.
(All of these projections will be for user-user throughput between
11/750's.)  Switching to 4096 byte segments in TCP transfers, while
fragmenting at the IP layer (to stay within the packet length
restriction of the Ethernet standard) we estimate an increased
throughput of 1.9 Megabaud.  This is with an interface which is
functionality equivalent to our current prototype Ethernets.  We plan
on changing UNIX soon so that user i/o buffers are naturally page aligned.
This would eliminate a copy of the data (when it is read) to raise the
throughput to about 2.25 Megabaud.  (This speedup only at the receiver
gives an end-end speedup because the receiving process otherwise has
more work to do.)  With checksum calculation support from the interface
hardware the user-user bandwidth would rise to about 3.5 Megabaud.
At this point the major overhead is the processing of the 4 interrupts
for the fragments of the 4k packets; a transmission medium which
allowed us to use 4k packets would let the bandwidth rise to about
6.6 Megabaud, user-user.   A final improvement would be to implement a
variant on the send system call which released the virtual memory when
the message was sent.  This would be very useful for servers and could
also be used by the standard i/o library.  This would reduce the
transmit overhead (which at this point should be greater than the
receive overhead) making the final throughput about 8 Megabaud.

	On 11/780's, these numbers typically scale up by 1.4 so that we
can project the throughput with the improvements described above to be
about 11.2 Megabaud, user-user.  While factors in the VAX architecture other
than the protocol might well dominate before this bandwidth is achieved,
this means that high data rates through the protocol can be achieved
with a relatively small percentage of the processor.

	We are working on IPC facilities for UNIX which will interface
to the INTERNET protocol family, and allow us to construct distributed
applications for UNIX without explicit dependence on the network layer
protocols.  The measurements reported here suggest that we do not need
to look for more efficient local network protocols, but will need
to support other protocols only for inter-operability with other
networks and systems.

	We will be working with Rob Gurwitz at BBN in the coming weeks,
combining our version of TCP/IP with his current version.  We look
forward to making a high-performance version of the protocol available
to the VAX/UNIX community at an early date.

	Regards,
		Bill Joy and Bob Fabry

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

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Sun Nov 29 11:19:56 1981
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #7

>From tcp-ip@brl Sun Nov 29 10:12:00 1981
TCP/IP Digest             Sunday, 29 Nov 1981      Volume 1 : Issue 7

Today's Topics:
                       Query:  TCP-IP for RSX-11M?
                        List of TCP-Capable Hosts
               UUCP Networking Concerns + Internet Issues
         General Networking Issues "Fair Game" in TCP-IP Digest
                       Query:  TCP-IP for NOS/BE?
----------------------------------------------------------------------

From: RCOLE at USC-ISIE
Subject: for TCP-IP digest

I would like to obtain information from anyone who has (or knows of)
a TCP-IP implementation for RSX11-M, the machine in question
is an 11/70. Any help gratefully received.

Reply to: Robert Cole, University College, London. RCOLE@ISIE

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

Subject: Re: TCP
From: CERF at USC-ISI
To: MCCUNE at USC-ISIC
Cc: tcp-ip at BRL

[TCP] TELNET is available on all ISI hosts; FTP is available on the
VAX and is being worked on for the TOPS-20 by BBN (Charles Lynn).

A list of TCP-capable hosts is in [ISIF]<internet-notebook>TCP-IP-STATUS.TXT.

TN runs on the TOPS-20 ("TelNet") and can be used to go from ISIC to
the VAX.

Vint
The file at ISIF is in need of updating - Jon Postel will be pulsing
the TCP implementers for new info, but you may find the current version
of some interst.

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

From: chico!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Subject: Re:  systems news articles

	From duke!dbl Wed Nov 18 14:01:41 1981
	Date-Sent: Wed Nov 18 13:57:35 1981
	To: unc!smb
	Subject: systems news articles

	MMDF- swd has done some looking into it as well, and thinks
	it's the way to go.  We've heard from farber and crocker at
	udel that we will probably be the next csnet site to go online,
	so we'll be getting the most up-to-date version of MMDF
	sometime this month (or maybe early December).

I'm rapidly coming to that conclusion as well, and the sooner I see
some manuals and some code, the happier I'll be.  I just read RFC754
and RFC799, and it's becoming apparent that the ARPAnuts are setting
standards which we'll have to adhere to if we're to talk to them.  And
the whole uucp addressing mess is getting out of hand -- and that says
nothing of changing topologies (what do we do with wolfvax's mail when
they hook in to MCNC instead) or the distinction users here have to
make between pnet mail and uucp mail.  Add in ARPA, CSnet, and maybe
Berknet among the duke machines, and you have a royal mess.  I'm
inclined to start a new net newsgroup to discuss mail, networking,
addressing, etc., from a UNIX/uucp point of view -- say, net.net
(fa.tcp-ip appears to be too specialized, though I'll route a copy of
this to the moderator).

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

Date: 19 Nov 1981 07:40:13-PST
From: cbosgd!mark at Berkeley
Subject: Re:  systems news articles

Having a newsgroup to discuss nets is different than discussing mail.
I propose net.net and net.mail.  I'm not sure net.net is needed -
does fa.tcp-ip subsume it?  There will probably soon be a net.csnet, too.

	Mark

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

From:      Mike Muuss <tcp-ip@brl>
To:        chico!duke!unc!smb at Ucb-C70
Subject:   Networking Discussions in TCP-IP Digest?

Steve -
	While the masthead "TCP-IP Digest" is really rather specialized,
I had intended the Digest as more of a discussion on IMPLEMENTATION
issues of networking (as opposed to Philosophical discussions as
get found in HUMAN-NETS).  The troubles with multiple networks, and
the variety of message formats (for mail), and routing problems in
general are all fair game for the TCP-IP digest.  You are welcome
to have this networking discussion in the TCP digest -- if the volume
becomes too great I would be willing to clone a new digest later on.

	BRL polls Duke via UUCP, so messages addressed to ...!duke!bmd70!tcp-ip
should make it to the digest (no need to go through Berkeley).  Give it
a try.  Our RMAIL is smart enough to prevent accidental gatewaying;  sorry.

					Cheers,
					 -Mike

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

Sender: DRDAR-MST at OFFICE-8
Subject: TCP/IP and the CYBERS
From: Richard Sitnik

     In a recent message Mike Muuss mentioned that there are
plans to install a version of TCP-IP on the CYBER.  Also, in
Issue 6 of the TCP-IP Digest Mike mentioned that Tektronix has
implemented TCP under NOS.

     I would like to find out more about plans regarding
TCP-IP.  In particular, do you know of anyone who is working on a
NOS/BE version?  I have spoken to Tektronix and their
implementation will only work with NOS and requires a HYPER
channel.  They are not aware of any NOS/BE efforts.  I will
prepare an item for the TCP-IP Digest detailing my discussion
with Tektronix.


RICH

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

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 81 11:27:29-EDT (Sun)
From:      Mike Muuss <tcp-ip@brl>
To:        list:
Subject:   TCP-IP Digest, Vol 1 #7
TCP/IP Digest             Sunday, 29 Nov 1981      Volume 1 : Issue 7

Today's Topics:
                       Query:  TCP-IP for RSX-11M?
                        List of TCP-Capable Hosts
               UUCP Networking Concerns + Internet Issues
         General Networking Issues "Fair Game" in TCP-IP Digest
                       Query:  TCP-IP for NOS/BE?
----------------------------------------------------------------------

From: RCOLE at USC-ISIE
Subject: for TCP-IP digest

I would like to obtain information from anyone who has (or knows of)
a TCP-IP implementation for RSX11-M, the machine in question
is an 11/70. Any help gratefully received.

Reply to: Robert Cole, University College, London. RCOLE@ISIE

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

Subject: Re: TCP
From: CERF at USC-ISI
To: MCCUNE at USC-ISIC
Cc: tcp-ip at BRL

[TCP] TELNET is available on all ISI hosts; FTP is available on the
VAX and is being worked on for the TOPS-20 by BBN (Charles Lynn).

A list of TCP-capable hosts is in [ISIF]<internet-notebook>TCP-IP-STATUS.TXT.

TN runs on the TOPS-20 ("TelNet") and can be used to go from ISIC to
the VAX.

Vint
The file at ISIF is in need of updating - Jon Postel will be pulsing
the TCP implementers for new info, but you may find the current version
of some interst.

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

From: chico!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Subject: Re:  systems news articles

	From duke!dbl Wed Nov 18 14:01:41 1981
	Date-Sent: Wed Nov 18 13:57:35 1981
	To: unc!smb
	Subject: systems news articles

	MMDF- swd has done some looking into it as well, and thinks
	it's the way to go.  We've heard from farber and crocker at
	udel that we will probably be the next csnet site to go online,
	so we'll be getting the most up-to-date version of MMDF
	sometime this month (or maybe early December).

I'm rapidly coming to that conclusion as well, and the sooner I see
some manuals and some code, the happier I'll be.  I just read RFC754
and RFC799, and it's becoming apparent that the ARPAnuts are setting
standards which we'll have to adhere to if we're to talk to them.  And
the whole uucp addressing mess is getting out of hand -- and that says
nothing of changing topologies (what do we do with wolfvax's mail when
they hook in to MCNC instead) or the distinction users here have to
make between pnet mail and uucp mail.  Add in ARPA, CSnet, and maybe
Berknet among the duke machines, and you have a royal mess.  I'm
inclined to start a new net newsgroup to discuss mail, networking,
addressing, etc., from a UNIX/uucp point of view -- say, net.net
(fa.tcp-ip appears to be too specialized, though I'll route a copy of
this to the moderator).

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

Date: 19 Nov 1981 07:40:13-PST
From: cbosgd!mark at Berkeley
Subject: Re:  systems news articles

Having a newsgroup to discuss nets is different than discussing mail.
I propose net.net and net.mail.  I'm not sure net.net is needed -
does fa.tcp-ip subsume it?  There will probably soon be a net.csnet, too.

	Mark

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

From:      Mike Muuss <tcp-ip@brl>
To:        chico!duke!unc!smb at Ucb-C70
Subject:   Networking Discussions in TCP-IP Digest?

Steve -
	While the masthead "TCP-IP Digest" is really rather specialized,
I had intended the Digest as more of a discussion on IMPLEMENTATION
issues of networking (as opposed to Philosophical discussions as
get found in HUMAN-NETS).  The troubles with multiple networks, and
the variety of message formats (for mail), and routing problems in
general are all fair game for the TCP-IP digest.  You are welcome
to have this networking discussion in the TCP digest -- if the volume
becomes too great I would be willing to clone a new digest later on.

	BRL polls Duke via UUCP, so messages addressed to ...!duke!bmd70!tcp-ip
should make it to the digest (no need to go through Berkeley).  Give it
a try.  Our RMAIL is smart enough to prevent accidental gatewaying;  sorry.

					Cheers,
					 -Mike

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

Sender: DRDAR-MST at OFFICE-8
Subject: TCP/IP and the CYBERS
From: Richard Sitnik

     In a recent message Mike Muuss mentioned that there are
plans to install a version of TCP-IP on the CYBER.  Also, in
Issue 6 of the TCP-IP Digest Mike mentioned that Tektronix has
implemented TCP under NOS.

     I would like to find out more about plans regarding
TCP-IP.  In particular, do you know of anyone who is working on a
NOS/BE version?  I have spoken to Tektronix and their
implementation will only work with NOS and requires a HYPER
channel.  They are not aware of any NOS/BE efforts.  I will
prepare an item for the TCP-IP Digest detailing my discussion
with Tektronix.


RICH

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

END OF DOCUMENT