----MESSAGE-BEGIN---- [anews.Aucbvax.5448] <1981121113333000> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Fri Dec 11 18:33:30 1981 Subject: TCP-IP Digest, Vol 1 #8 X-Google-Info: Converted from the original A-News header >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 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 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 , 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1981121113531500> Mail-from: ARPANET host BRL rcvd at 11-Dec-81 1911-PST Date: 11 Dec 81 18:53:15-EST (Fri) From: Mike Muuss To: list: Subject: TCP-IP Digest, Vol 1 #8 Bcc: 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 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 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 , 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1981122316552400> Mail-from: ARPANET host BRL rcvd at 23-Dec-81 2342-PST Date: 23 Dec 81 21:55:24-EST (Wed) From: Mike Muuss To: list: Subject: TCP-IP Digest, Vol 1 #9 Bcc: 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 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 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [anews.Aucbvax.5534] <1981122317400100> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Wed Dec 23 22:40:01 1981 Subject: TCP-IP Digest, Vol 1 #9 X-Google-Info: Converted from the original A-News header >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 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 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 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 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 ******************** ----MESSAGE-END----