----MESSAGE-BEGIN---- <1982100107140100> Mail-from: ARPANET host DTI-VMS rcvd at 1-Oct-82 1416-PDT 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 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 much. 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100108230000> Mail-From: MILLER created at 1-Oct-82 15:23:22 Date: 1 Oct 1982 1523-PDT From: Henry W. Miller Subject: TCP-IP Update To: tcp-ip at SRI-NIC cc: Miller at SRI-NIC 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: [SRI-NIC]TCP-QUESTIONNAIRE.TXT 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. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100112243500> Mail-from: ARPANET host EDN-UNIX rcvd at 1-Oct-82 1405-PDT Date: 1 Oct 1982 16:24:35 EDT From: Edward A. Cain Subject: additions to V6 UNIX TCP To: tcp-ip@sri-nic Cc: cain 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. Ed ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100305400000> Mail-from: ARPANET host SU-SCORE rcvd at 3-Oct-82 1243-PDT Date: 3 Oct 1982 1240-PDT From: Mark Crispin Subject: Status of TCP/IP for TOPS-20 sites Sender: ADMIN.MRC at SU-SCORE To: TOPS-20 at SU-SCORE, TCP-IP at SRI-NIC Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) 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 TCP/IP. 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 -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100312370000> Mail-from: ARPANET host OFFICE-1 rcvd at 3-Oct-82 1942-PDT Date: 3 Oct 1982 1937-PDT From: Lieberman at OFFICE-1 Subject: DIgest vs piece mail To: tcp-ip at NIC cc: miller at NIC 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. Robert ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100323510300> Mail-from: ARPANET host LBL-UNIX rcvd at 4-Oct-82 0657-PDT 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 Implementation-People@SRI-NIC or Implementation-News@SRI-NIC or 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. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100401290000> Mail-from: ARPANET host SRI-TSC rcvd at 4-Oct-82 0832-PDT Date: 4 Oct 1982 at 0829-PDT To: Henry W Miller cc: tcp-ip at Sri-Nic Subject: Re: Duplicate messages, etc In-reply-to: Your message of 3 Oct 1982 1639-PDT. From: holly at SRI-TSC 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. Holly ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100404170000> Mail-from: ARPANET host USC-ISI rcvd at 4-Oct-82 1119-PDT Date: 4 Oct 1982 1117-PDT Sender: J33PAC at USC-ISI Subject: Re: Duplicate messages, etc From: J33PAC at USC-ISI To: Miller at SRI-NIC Cc: tcp-ip at SRI-NIC Message-ID: <[USC-ISI] 4-Oct-82 11:17:52.J33PAC> In-Reply-To: Your message of 3 Oct 1982 1639-PDT IN RESPONSE TO YOUR QUESTION REGARDING UPDATES, MY PERSONAL OPINION (AND THERE AREN'T ALL THAT MANY OTHER REGULAR USERS OF THIS MAILBOX) IS THAT I'D PREFER A COMPACT FORM THAT CAN BE RETRIEVED FROM THE NIC, RATHER THAN AN AGONIZING BLOW-BY-BLOW OF EVERYONE'S DETAILED PROBLEMS. ALOHA FROM HAWAII, PAUL VAN ZWALENBURG CINCPAC ARPANET TAC LIAISON ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100404250000> Mail-from: ARPANET host NALCON rcvd at 4-Oct-82 0528-PDT Date: 4 Oct 1982 at 0825-EDT From: avrunin@nalcon In-reply-to: Your message of 3 Oct 1982 1639-PDT Subject: Duplicate messages, etc To: Henry cc: tcp-ip at SRI-NIC,Miller at SRI-NIC 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100406270000> Date: 4 Oct 1982 1327-PDT From: Henry W. Miller Subject: Re: Duplicate messages, etc To: avrunin at NALCON, Henry at NALCON cc: tcp-ip, Miller In-Reply-To: Your message of 4-Oct-82 0528-PDT Larry, 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. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100406420000> Date: 4 Oct 1982 1342-PDT From: Henry W. Miller Subject: Re: Duplicate messages, etc To: holly at SRI-TSC cc: tcp-ip, Miller In-Reply-To: Your message of 4-Oct-82 0832-PDT Holly, 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. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100406500000> Date: 4 Oct 1982 1350-PDT From: Henry W. Miller Subject: Re: Duplicate messages, etc To: J33PAC at USC-ISI cc: tcp-ip, Miller In-Reply-To: Your message of 4-Oct-82 1117-PDT Paul, 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. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100504465800> Mail-from: ARPANET host NBS-VMS rcvd at 5-Oct-82 0448-PDT 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100602380500> Mail-from: ARPANET host OKC-UNIX rcvd at 6-Oct-82 0542-PDT Date: 6 Oct 1982 7:38:05 EST (Wednesday) From: Don Jennings Subject: Re: Policy changes In-Reply-to: Your message of 5 Oct 1982 15:43 PDT To: Henry W. Miller Cc: tcp-ip at SRI-NIC Please keep my name on both lists for the TCP distributions. Thanks, Don Jennings (don@okc-unix) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982100705570000> Mail-from: ARPANET host MIT-MULTICS rcvd at 7-Oct-82 0658-PDT Return-Path: Date: 7 October 1982 09:57 edt From: JSLove at MIT-MULTICS (J. Spencer Love) Subject: Request for spec refinement Sender: JSLove.PDO at MIT-MULTICS To: TCP-IP at SRI-NIC cc: JSLove.PDO at MIT-MULTICS 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 possibilities: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982101316220000> Mail-from: ARPANET host SRI-CSL rcvd at 14-Oct-82 1134-PDT Date: 13 Oct 1982 at 2322-PDT From: Bill Croft To: ucbtcp11 at SRI-TSC Subject: distribution announcement Sender: croft at SRI-TSC Redistributed-To: tcp-ip at NIC, tcp-ip at BRL Redistributed-By: GEOFF at SRI-CSL Redistributed-Date: 14 Oct 1982 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 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982103005320000> Mail-from: ARPANET host SU-SCORE rcvd at 30-Oct-82 1843-PDT Mail-from: SU-NET host Shasta rcvd at 30-Oct-82 1233-PDT Date: Saturday, 30 Oct 1982 12:32-PDT To: admin.mrc at Score Subject: information request From: Forest Baskett Remailed-date: 30 Oct 1982 1841-PDT Remailed-from: Mark Crispin Remailed-Sender: ADMIN.MRC at SU-SCORE Remailed-to: TCP-IP at SRI-NIC 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? Forest ----MESSAGE-END----