The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1982)
DOCUMENT: TCP-IP Distribution List for October 1982 (17 messages, 8915 bytes)
NOTICE: recognises the rights of all third-party works.


Date:      Fri, 01 Oct 82 12:14:01 CDT
From:      schur at DTI-VMS
Subject:   ftp and tcp protocol problems
We would like to solicite the opinions of TCP-IP implementors on
the some protocol issues.

During the implementation of ftp we have noticed the following
problem with the interaction of the ftp and tcp protocols:

	1. When a data transfer is started a connection is
		opened between the user ftp port and the
		server ftp port - 1.

	2. In many cases the data connection must be closed
		to indicate EOF. At this point, the connection
		will start closing and eventually go into
		the TIME-WAIT state (for an arbitrary period
		of two minutes, as the protocol indicates).

	3. If ftp wishes to open the data connection again during
		this TIME-WAIT period, it will not be allowed to
		do so, since it would be using the same local
		and foreign ports, and foreign internet address.
		The TCP protocol requires that we be able to receive
		packets for the connection in the TIME-WAIT state,
		so we can't reopen a new connection until it has
		completely closed.

This scenario causes an unacceptable delay when using ftp for multiple
transfers requiring opening and closing of the data connection. Is there
some fix for this at this time, or planned in the future? If not, it
appears that the only course we have is to violate the protocol to
allow opening of the new connection before the previous one has completed
the TIME-WAIT timeout.

John Schur
<schur at dti-vms>

Addendum from Jim Reno:

	I don't think the delay on the part of TCP is unreasonable. Rather,
the problem should be approached from the FTP side. The way FTP is currently
set up the handling of the data connection causes problems in more ways than
one. In particular, the user side is required to parse the server replies and
look for specific values (226,426) in making the decision of whether or not
to close the connection. I would much prefer a different handling that
simplified the protocol and avoided the above timeout problem.
	Although the stream mode is the simplest to implement, I think it
should be gotten rid of in favor of block mode. Note that at its simplest
block mode is merely stream mode with a prepended header indicating length.
In this case the implementation is almost as simple as stream mode, except
more  powerful, in that the end of file marker is now explicit. The only
penalty is a few bytes of header (3) per block. If the blocks are of a
reasonable size, as they should be for file transfer, this won't matter
	In this case the data connection could be opened whenever the first
transfer starts, and ALWAYS left open, until the session terminates or
the user sends a REIN command. Not only does this avoid the timeout
problem, but it avoids the parsing problem as well.
	This brings up another point about the reply code strategy. I
am still a bit fuzzy on a few points:
	1. Are we allowed to use ONLY the EXACT codes listed in RFC765, or
are we allowed to create different ones according to the meanings given
to the various digits? It strikes me that the most flexible approach, as
well as the easiest to implement, is the latter. User FTP programs should
not keep lists of reply codes that they compare against. Instead, they should
merely check the first digit, and possibly the second. This then allows a
tailoring of the replies from a given server to fit the situation at hand,
as long as they are within the specified guidelines, and yet user FTPs
should still be able to parse them successfully. The server implementer
thus never has to use a reply that was intended for something else to fit
say, a site-specific command (via SITE) or a site-specific situation.
	2. Multi-line replies. I think there is a better way to handle
multi-line replies that yet remains within the protocol, and will be parsed
more easily by user FTP. Instead of using initial XXX- and final XXX 
lines to bracket a multi-line reply, I would simply prefix EVERY server
reply with a code. All replies of a group but the last would have an
initial digit of 1, indicating that the user should expect another reply.
The final reply would have the appropriate success/failure digit.
Alternately, rather than using 1, you might create a new first digit of
6 to handle this case and avoid confusion.
	This scheme has the advantage that it is interruptable. If the
server needs to produce an asynchronous reply, such as from a STAT or
ABORT, during some multi-line reply, it can safely send it in the middle.
The user process might 'misinterpret' this as the end of the multi-line
reply, but that should be ok, as the last code from the multi-line reply
would come along and be considered as the end of the asynchronous action
(depending on how the user ftp is written). In any case a simple user ftp
only need keep track of how many commands he has sent and how many
completion replies recieved.

Jim Reno
<reno at dti-vms>
Date:      1 Oct 1982 1523-PDT
From:      Henry W. Miller <Miller at SRI-NIC>
To:        tcp-ip at SRI-NIC
Cc:        Miller at SRI-NIC
Subject:   TCP-IP Update
Dear Group,

	The response I have received so far has been fantastic.
Thank you one and all.  Now, for the administative details:

	Many of you have complained that you have received
multiple copies of the welcome message.  When I developed the
list, I sorted the text very carefully, and gleaned out
duplicates before ordering them by hosts.  The reason that
some of you received multiple copies is that the mailer got
itself into a loop, and kept re-processing the list.  We think
this problem has been fixed.  (We hope...)

	Secondly, by popular demand, I have implemented a
TCP-IP-REQUEST@SRI-NIC mailbox to automatically forward
requests to me.

	The third order of business is the matter of the
TCP-IP questionaire.  Many of you have not received this
yet.  An on-line copy can be obtained via FTP by ANONYMOUS
login, password GUEST.  File path is:


	Finally, if you system developed any interesting problems
during today's TCP-only test, please let us know.  We would like
to develop a journal of oddities that will be available on-line
at the NIC, and will be submitted to the TCP-DIGEST.

Date:      1 Oct 1982 16:24:35 EDT
From:      Edward A. Cain <cain@EDN-UNIX>
To:        tcp-ip@sri-nic
Cc:        cain
Subject:   additions to V6 UNIX TCP
Since the June tcp-ip.status file was distributed, we have changed the
V6 UNIX telnet/tcp/ip to provide for user-selected routes for the
source route IP option on telnet connections (strict or loose), and 
to allow class B/C addresses.

Date:      3 Oct 1982 1240-PDT
From:      Mark Crispin
To:        TOPS-20 at SU-SCORE, TCP-IP at SRI-NIC
Subject:   Status of TCP/IP for TOPS-20 sites
     BBN has had a TCP/IP implementation available for some time for
TOPS-20; unfortunately the design of the system calls is somewhat
poor.  DEC, in the person of Kevin Paetzold, is working on a redesign
of the system call interface be more natural, that is, to go through
the filesystem as a TCP: (I believe) device.

     TOPS-20 TELNET for TCP/IP under the BBN interface is done.  This
functionality is incorporated into my TELNET.  The DEC interface will
be supported once it is available.

     TOPS-20 FTP is supposedly being worked on at BBN and ISI.  I do
not know its status nor of what interface it will use.

     TOPS-20 electronic mail work is going on at ISI and Stanford (that
is, Joel Goldberger and myself).  Joel has interfaced XMAILR to the
development SMTP support package written by Paul Mockapetris at ISI.  I
am working on an XMAILR successor, MMAILR, which will use the DEC TCP/IP
interface.  Much of this work is waiting upon Kevin.

     Stanford SCORE is not planning on running the BBN interface, even
if it were to mean us going off the network for a short period of time.
This is because we have another network (Ethernet) already interfaced to
our system, which makes things sufficiently complicated with regard to
network terminals that I don't want to do a TCP merge more than once.
Also, there is the small but non-zero possibility that our gateway between
Internet and our Ethernet (SU-GOLDEN) may be operational by the end of
the year.  This gateway will perform protocol translation between Pup and

     I hope this gives some answers to what is going on in the TOPS-20
and particularly with my efforts.  All too much is waiting upon all too
few individuals.  We think that we still have a chance though.

-- Mark --
Date:      3 Oct 1982 1937-PDT
From:      Lieberman at OFFICE-1
To:        tcp-ip at NIC
Cc:        miller at NIC
Subject:   DIgest vs piece mail
I vote for both....
 Anyone not wishing piece by piece mail should have their
name eliminated from TCP-IP redistribution list.
Also, it is valuable to have all these wonderful tidbits in one place (file).
But I would not think Henry should be stuck editing/sorting/etc.
Just a simple collection of messges would do for now.
Date:      4 Oct 1982 06:51:03-PDT
From:      mo at LBL-UNIX (Mike O'Dell [system])
To:        tcp-ip at sri-nic
Subject:   ARPAnet future question
Not knowing where else to pose this:

What are the plans for the IMP program in the future?  The current
scheme of strict rfnm counting is somewhat at odds with the "pure datagram"
network IP is designed to sit atop.  On the other hand, the rfnm
counting does provide some low-level flow control within the subnet
itself.  Can anybody elaborate on the plans for the future?  Will
1822 stay like it is?  At some point, will we be able to use other
message id's for outgoing packets so we can do low-level error
processing before the TCP timers fire?  Will the network field in the
1822 header be initialized to 10 so it won't have to be wired into code?
Will the "logical addressing" proposal be incorporated?

Finally, one administrative issue.  Other than being direct redistribution,
I still don't understand how this list is to be different from Mike Muus's,
but if it is in fact different, it MUST have a different name.  From
the outside, it looks like Mike's list can reached at an additional host.
I would suggest something like





	NewSpeak-Speakers@SRI-NIC		(I sort of like this one!)

This still doesn't rectify my misunderstanding of the implied differences
in content, but I am quite willing to believe there are such.

Date:      4 Oct 1982 at 0829-PDT
From:      holly at SRI-TSC
To:        Henry W Miller <Miller@Sri-Nic>
Cc:        tcp-ip at Sri-Nic
Subject:   Re: Duplicate messages, etc
Henry, I like to get many small messages rather than trying to parse
1 huge message.  I like the system as you have set it up.


Date:      4 Oct 1982 1117-PDT
From:      J33PAC at USC-ISI
To:        Miller at SRI-NIC
Cc:        tcp-ip at SRI-NIC
Subject:   Re: Duplicate messages, etc



Date:      4 Oct 1982 at 0825-EDT
From:      avrunin@nalcon
To:        Henry
Cc:        tcp-ip at SRI-NIC,Miller at SRI-NIC
Subject:   Duplicate messages, etc
I would prefer to continue receiving information the way it is being
distributed.  I beleive it is the best way to keep us up to date as to
what is happening.

Larry Avrunin

Date:      4 Oct 1982 1327-PDT
From:      Henry W. Miller <Miller>
To:        avrunin at NALCON, Henry at NALCON
Cc:        tcp-ip, Miller
Subject:   Re: Duplicate messages, etc
	What I am going to do is maintain two lists:  one for
general announcements, and one for immediate distribution.
I think this is the best solution.

Date:      4 Oct 1982 1342-PDT
From:      Henry W. Miller <Miller>
To:        holly at SRI-TSC
Cc:        tcp-ip, Miller
Subject:   Re: Duplicate messages, etc
	What I am going to do is maintain two lists:  one for
general announcements, and one for immediate distribution.
I think this is the best solution.

Date:      4 Oct 1982 1350-PDT
From:      Henry W. Miller <Miller>
To:        J33PAC at USC-ISI
Cc:        tcp-ip, Miller
Subject:   Re: Duplicate messages, etc
	What I am going to do is maintain two lists:  one for
general announcements, and one for immediate distribution.
I think this is the best solution.

Date:      Tue, 05 Oct 82 08:46:58 EDT
From:      wheatley at NBS-VMS
Subject:   V6 Unix TCP/IP Needed
We would like to obtain V6 Unix TCP/IP arpanet software for PDP 11/45.
Can you give any leads as to where this would be available, either free
or for a price.

Marnie Wheatley  (wheatley@nbs-vms)
Date:      6 Oct 1982  7:38:05 EST (Wednesday)
From:      Don Jennings <don at OKC-UNIX>
To:        Henry W. Miller <Miller at SRI-NIC>
Cc:        tcp-ip at SRI-NIC
Subject:   Re: Policy changes
Please keep my name on both lists for the TCP distributions.

Don Jennings
Date:      7 October 1982 09:57 edt
From:      JSLove at MIT-MULTICS (J. Spencer Love)
To:        TCP-IP at SRI-NIC
Cc:        JSLove.PDO at MIT-MULTICS
Subject:   Request for spec refinement
The specification makes refernce to partially qualified LISTEN's, which
presumably means that either the foreign address or the foreign port are
unspecified, but not both.  When an attempt is made to open a
connection, the most specific match is chosen.  However, there are 4

   1)  address and port specified
   2)  address specified, port not specified
   3)  address not specified, port specified
   4)  address not specified, port not specified

If listening TCB's existed in all four states, the MIT-Multics
implementation will try and match them in the order given above.
(Previously, it was unable to connect to cases 2 and 3 at all, although
it permitted the LISTEN operation.  Today's installation fixes that.)

Should I swap the precedence of cases 2 and 3?  Should cases 2 and 3 be
invalid?  Is MIT-Multics's new behavior correct?  Is this a reasonable
place to send questions like this one?
				-- Spencer
Date:      13 Oct 1982 at 2322-PDT
From:      Bill Croft <croft@SRI-TSC>
To:        ucbtcp11 at SRI-TSC
Subject:   distribution announcement
Distribution of 2.8 BSD with TCP/IP.

Our port of the 4.1a BSD VAX networking code to the PDP11/44 or /70 is now
essentially complete.  We have been running the software on our SRI-PRMH
and SRI-WARF systems for about a month now with very good results.  The
local net drivers tested and running at this time are:  INTERLAN 10 megabit
ethernet, ACC LH-DH, and our locally built SRI1822.  Converting an existing
VAX network device driver to run with the 11 requires editing just a few
lines.  The DEC IMP11A driver has been converted but not yet tested.

I wish we had the time to make this distribution a really polished one, but
we don't.  We make the assumption that you already have installed 2.8 BSD
on your machine, and understand kernel configuration and debugging.  If you
brought up an early 2.8 distribution, I think you qualify.

To avoid licensing difficulties, we are restricting distribution to holders
of Berkeley UNIX licenses (x.x BSD).  Within a few months we hope that the
PDP11 group at Berkeley can take over and incorporate this distribution
into their next 2.82 release.  We are making this release available from
SRI due to the fast approaching ARPA TCP conversion deadline.  The tape we
can send you contains the new kernel, user level network code, and other
necessary tools (such as "cpp" from the VAX that understands long
identifier names).

Here is a copy of the entry recently submitted to SRI-NIC, for the
"tcp-ip-status.txt" document:

5. SRI UNIX 11/44,11/70  V7 (2.8 BSD)

   Date:  13 October 1982
   From:  Bill Croft <croft at sri-tsc>

   This TCP was ported from the Berkeley VAX 4.1a version.  IP, TCP, ICMP,
   UDP, and RAW layers are all kernel resident.  This means we can run
   faster than older PDP11 TCPs that require auxiliary daemons (such as
   BBN's V6 or 3COM's UNET).  Typical TCP interprocess thruput between a VAX
   750 running 4.1a BSD and the 11/44 running 2.8 BSD is 300000 baud;
   this was measured with INTERLAN 10 megabit ethernet hardware.

   For programmers, there is easy access to all layers of protocol, so
   that (e.g.) IP or UDP services can be written.  Service protocols
   available are all of those supplied with the VAX version:  FTP, TELNET,
   ECHO, rlogin, rsh, rexec, talk, routing daemons.

   1.  Hardware - currently requires an I/D machine, such as an 11/44
       or 11/70 with at least a half megabyte of memory.  The total kernel
       size (text, data, and buffers) is about 200K bytes;  so it won't
       fit if you have only 256K bytes.  Although this sounds like a lot
       of bytes, comparison with our older 2.8 BSD NCP-only system shows
       that the kernel has only grown by about 60K bytes.  This is very
       reasonable considering that the entire network is now resident
       versus the NCP case which used a hulking NCP daemon.

       A number of net interfaces are supported.  See the Berkeley VAX
       documentation.  The ones specifically ported to the 11 are:
       INTERLAN 10 megabit ethernet, ACC LH/DH, SRI 1822, DEC IMP11A.
       Porting a new VAX interface driver to the 11 involves changing
       less than 10 lines of code.

   2.  Software - ported from the 4.1a Berkeley VAX UNIX system.
       Manipulates I and D space mapping registers to reference more than
       65K bytes of instructions and data at a time.

   3.  Documentation - supplied on tape as manual pages.

   Contact for further information:  Dan Chernikoff, dan@sri-tsc, (415) 859
   4144.  We can mail a copy of our distribution tape.  Eventually the
   software will be incorporated in Berkeley's next PDP11 distribution
   (2.82 BSD).  This tape is supplied as-is to 2.8 BSD licenses, with no
   warrantees or support expressed or implied.  The terms of your original
   Berkeley license apply:  the software cannot be resold or redistributed.

To get the software, send a magnetic tape and a copy of your 2.8 or 4.x
license to:

	Dan Chernikoff
	SRI International
	333 Ravenswood Ave.
	Menlo Park, CA  94025

As far as updates and bug fixes go, this mailing list (ucbtcp11@sri-tsc)
can be used as a distribution point.  Send a note to dan@sri-tsc to
add or delete names from the list.

Date:      Saturday, 30 Oct 1982 12:32-PDT
From:      Forest Baskett <baskett at Shasta>
To:        admin.mrc at Score
Subject:   information request
I would like to run TCP/IP on my VMS VAX machine.  Then it could more
easily talk to my Unix VAX machine.  I have seen net notes that an
arpanet site called dti-vms has developed TCP/IP for VAX/VMS.  I don't
know what or where dti-vms is.  Can you help me?