----MESSAGE-BEGIN---- <1981100721511900> Date: 8 Oct 81 1:51:19-EDT (Thu) From: Michael Muuss Subject: TCP/IP Digest, V1 #1 TCP/IP Digest Thursday, 8 Oct 1981 Volume 1 : Issue 1 Today's Topics: A new Discussion Group Gateway Connection Policy -- TCP and IP Protocol Definitions Comments on TCP4 from BBN -- SRI Networks Development Group EDN-UNIX TCP/IP Notes -- 3Com TCP/IP Troubles NALCON Conversion Meeting -- BRL TCP/IP Environment (Planned) BBN VMUNIX (4.1BSD) TCP/IP -- BBNCC C/30 Features & Futures UTexas TCP4 (BBN) Mods -- 3Com TCP/IP: A Happy User Internet Gateway & Computer List -- TCP/IP Implementation Status Overview Are PDP-11's Dead? -- 3Com TCP/IP: More comments BBN TCP/IP for VAX: Manual Page ---------------------------------------------------------------------- From: Michael Muuss Subject: A New Discussion Group Greetings Earthlings! This is the first issue of a new digest which purports to discuss TCP and IP, the "DoD Standard Networking Protocols for the Eighties". Comments will probably center around UNIX implementations, but any technical networking or implementation discussions too specific for HUMAN-NETS is fair game here. Please send submissions to "TCP-IP @ BRL", requests to "TCP-REQUEST @ BRL" or "TCP-IP-REQUEST @ BRL". This is sort of a spur-of-the-moment thing; it started with our trying to find out about TCP/IP iplementations, and wound up with dozens of letters asking for a report of what I found. This list may die stillborn, or it may flurish. Only time will tell! Cheers, -Mike ------------------------------ Date: 1 Oct 1981 1022-PDT Sender: WESTINE at USC-ISIF From: Postel@isif 1) The question about connection policy should be directed to DCA or your site's ARPANET sponsor. But my guess at an answer is "For a site with a host on the ARPANET (properly authorized) there should be no additional policy issues in connecting a local network to the ARPA Internet when the purpose and use of the local net is the same as for the existing host." 2) The question about IP and TCP is correctly addressed to me. RFCs 791, 792, and 793 define IP and TCP. The ARPANET already supports these protocols. Many TOPS20s, Unix-es (including VAX) and MIT-Multics, and UCLAs IBM system, already have these protocols in use. Work is in progress to replace all TIPs with TACs that use IP and TCP. There are about 10 internet gateways in service already. ARPA has set a goal for the complete switchover to IP and TCP by January 1983. --jon. ------------------------------ Date: 2 Oct 1981 0520-PDT From: DEDWARDS at USC-ISI BBN (of course) has a TCP 4 up and running written in C. Its slow and large (mainly due to the fact that it is entirely outside the kernelrunning as a user pgm with only a device driver in the kernel. Jack Haverty (JHAVERTY at BBN) or Mike Wingfield (wingfield at BBN-UNIX or BBN-RSM) can say lots more. Howard Weiss ------------------------------ Date: 2 Oct 1981 0702-PDT From: NRL at USC-ISIE For you information the below message was received by us in late September 1981; you may find in useful. Regards, Doug Shannon - ARPAnet mailbox - NRL@ISIE - - - - - - - - - The Networks Development group at SRI can offer assistance in the development or operations support of one or more of ollowing: - modernizing the NALCON sites UNIX from Version 6 to Version 7 (the current release from BTL); - 96-bit leader NCP software required to address all hosts on the ARPANET; - DoD standard TCP/IP network software with Version 7 UNIX and associated user software such as TCP-FTP, MTP (Mail Transfer Protocol), TELNET, etc.; - TCP/NCP mail gateway software to facilitate transition from NCP to TCP; - a VDH Front-End which would remove the overhead associated with the Very Distant Host protocol off of UNIX; - other areas related to UNIX and network systems. The Networks Development group at SRI specializes in the development of local and long-haul network software, hardware, and protocols. There are currently 8 UNIX systems in operation at SRI, most of which are attached to our local area network and/or the ARPANET. If you would like to discuss your needs and how we can assist you in any of the mentioned areas, please contact me at: Geoff Goodfellow 333 Ravenswood Ave. Menlo Park, CA. 94025 (415) 859-3098 ARPANET: Geoff@SRI-CSL ------------------------------ Date: 2 Oct 1981 13:38:33 EDT From: Edward A. Cain Our TCP/IP is an extension of the one on the 11/70 at BBN, in case you have already heard from them. It runs on V6 here, and on V7 at BBN. Both machines support two interprocess communication mods to UNIX in order to allow the tcp/ip to work: (a) Rand "ports", with supporting "await" and "capacity" system calls, or (b) shared memory. The user-to- tcp interface can employ either of these techniques. Our extensions to that work include: (a) handling GGP or ICMP packets, and (b) reassembly of fragments within IP. You're welcome to the sources, manual pages, and UNIX hacks needed to make them work -- if you are using an 11/70. If you have some other machine like the C/70 or a vax, better get in touch with someone at BBN. Their active work on tcp/ip has centered around those 2 machines over the past couple of years. Jack Haverty is one point of contact (haverty at bbn-unix). I recall an SRI status report on the 3-com stuff just last week. Seems the 3-com tcp/ip is full of bugs, and 3-com is under no obligation to fix things under the license agreement. However, SRI (one of 3-com's customers) has been able to get some fixes out of 3-com. Sounds kind of risky. Ed Cain ------------------------------ Date: Fri, 2 Oct 81 16:31-PDT From: Greg at NPRDC Indeed, we all are [Converting to TCP/IP] in a year or so. Geoff@SRI-CSL has offered to help the NALCON sites convert; maybe we can all get together and reduce our mutual costs. We're trying to set up a meeting to talk about it, probabally in the DC area; would you be interested in it? ------------------------------ Date: 2 Oct 81 20:45:01-EDT (Fri) From: Michael Muuss To: Greg at NPRDC We will probably be building an extensive local network which will initially include such varried systems as a CDC 7600 (SCOPE), CDC 173 (NOS), 40 MIPS HEP (UNIX, probably!), zillions of 11/70s and 11/34s, PE 3240s, C/70s, etc, and using Hyperchannels, PCL-11Bs, DQ-11s, UMC-11s, .... for communications. In my opinion, only a "standard" protocol like TCP will permit a plan like this to succeed (!). Networking forever! -Mike ------------------------------ Date: 5 Oct 1981 9:24:30 EDT (Monday) From: Rob Gurwitz Jack Haverty passed your inquiry about TCP/IP along to me. In addition to the experimental TCP/IP that was done for the 11's (which you may or may not already have), we have been developing a version for the VAX running Berkeley 4.1BSD UNIX. This software is a full implementation of the protocols and is completely independent of any of the old U of I NCP code (including the RMI). It allows access at the TCP, IP, or local network access levels. The software is currently running and under test at several sites, including Berkeley. When it is generally released (probably around the first of the year), it will be available through Berkeley and will be included as part of a future 4.xbsd distribution. The configuration currently supports ARPANET 1822 local net protocol and a driver for the ACC LH/DH-11 IMP i/f, but work is also going on to develop other local net drivers (i.e., ETHERNET) for it. Rob Gurwitz ------------------------------ Date: 2 Oct 81 18:48:08-EDT (Fri) From: Michael Muuss To: Paul Santos Subject: C/30 Features & Futures Just out of curiosity, I have some questions about our nice shiney new C/30. 1) How difficult is it to change a DISTANT host interface to a LOCAL host interface. It it a switch, a board, or a big deal? Could you estimate the cost of doing this? Our liason's crystal ball must have been a little cloudy... 2) Just for kicks, is it possible for a C/30 to support either (a) more than 4 modem lines, and/or (b) run the trunk lines at more than 50Kb? 3) Is there any provision for more than one trunk to connect between two C/30's to improve transmission between them? We are doing a lot of planning here on networking, and are strongly considering using TCP/IP. What can you tell me about (or point me to) how BBN plans to proceed with TCP, and how will this affect the ArpaNet? Cheers, -Mike ------------------------------ Date: 4 Oct 1981 16:10:25 EDT (Sunday) From: Paul Santos To: Michael Muuss Mike, I have forwarded your message to Nancy Mimno, who is the primary point of contact for ARPANET users. I believe the answers are in brief: 1) Easy, 2)(a) in progress, 2)(b) already exists, and 3) has been thought of but not currently planned. As for TCP/IP, it is a host isssue, and does not directly affect the subnetwork; however, DCA and ARPA (and DoD in general) are pushing on TCP and plan to outlaw NCP someday. Paul ------------------------------ Date: 5 Oct 1981 at 0945-CDT From: roya at UTEXAS-11 (roya) I have been working on TCP/IP BBN version 4 in our PWB-UNIX System. There were and are some problems that I'm trying to fix in it. Let me know if I can be any help to you. Roya ------------------------------ Date: 7 Oct 1981 11:38:55-PDT From: menlo70!sytek!zehntel!billn at Berkeley We have been running it [3Com] for a short time between two 70's hooked up via an able da-11. With unloaded systems we get about 60kb during file transfer. With one heavily loaded system and one lightly loaded one we get about 45kb. We run 2.?bsd and had a few problems, not many, during installation. Our problems were due to the fact that, as the previous msg said, it IS big. They have tried v. hard to make it a "drop in" product, and have done a good job, but the 2.?bsd systems are just too huge, as normally run, to avoid some hacking during installation. (3com is now more experienced in 2.?bsd-ese than they were...) It seems relatively bug free and robust. Our general users have not been unleashed on it yet -- that'l be the really telling blow. /b ------------------------------ Date: 5 Oct 1981 1358-PDT From: POSTEL at USC-ISIF To: mike.bmd70 at BRL < INC-PROJECT, IN-HOST-TABLE.NLS.25, >, 27-May-81 16:52 JBP ;;;; ADDRESSES The internet addresses in this memo are stated as four 8-bit fields with the value of each field given in decimal. GATEWAYS Name Addresses --------------- --- --- --- --- --- --- --- --- DCEC-EDN/ARPA 21 0 0 2 10 3 0 20 MIT-LCS/ARPA 18 8 0 4 10 0 0 77 BBN-RCC/ARPA 3 2 0 5 10 2 0 5 BBN-SAT/ARPA 4 0 0 61 10 3 0 40 NDRE-SAT/ARPA 4 0 0 38 10 3 0 41 COMSAT-SAT/COMSAT 4 0 0 39 29 0 2 2 UCL-SAT/UCL 4 0 0 60 11 3 0 42 UCL-SAT/NULL 4 0 0 60 35 7 0 0 UCL-UCL/RSRE 11 3 2 42 25 6 0 0 RSRE-NULL/PPSN 35 6 0 0 25 6 0 0 RSRE-NULL/PPSN 35 6 0 0 25 13 0 0 SRI-PR1/ARPA 2 0 0 11 10 3 0 51 SRI-PR2/ARPA 6 0 0 11 10 1 0 51 BBN-BBNPR/ARPA 1 0 0 11 3 0 0 62 Bragg-BraggPR/ARPA 9 0 0 11 10 0 0 38 COMPUTERS Name Address --------------- --- --- --- --- ALTA-COMA 3 1 0 50 BBN-UNIX 10 0 0 63 BBN-VAX 10 2 0 82 BBNA 10 3 0 5 BBNB 10 0 0 49 BBNC 10 3 0 49 BBND 10 1 0 49 BBNE 10 0 0 5 BBNF 3 2 0 51 BBNG 10 1 0 5 EDN-HOST1 21 1 0 1 EDN-HOST3 21 0 0 3 EDN-UNIX 10 3 0 20 ISIB 10 3 0 52 ISIC 10 2 0 22 ISID 10 0 0 27 ISIE 10 1 0 52 ISIF 10 2 0 52 MIT-DevMultics 10 4 0 31 MIT-Multics 10 0 0 6 UCLA-CCN 3033 10 1 0 1 ------------------------------ Date: 5 Oct 1981 1544-PDT From: POSTEL at USC-ISIF BBN C/70 UNIX Date: 14 May 1981 From: Jack Haverty The C/70 processor is a BBN-designed system using C as its native mode. It supports Version 7 of UNIX, and provides for user processes with 20-bit address spaces. The TCP/IP for this machine is in development; the BBN VAX-11/780 UNIX implementation will be ported to the C/70 UNIX system. This work is expected to be complete in summer '81. BBN GATEWAYS Date: 8 May 1981 From: Ginny Strazisar This is a status report on the implementation of the Internet Protocol in these gateways: the ARPANET/SATNET gateway at BBN (10.3.0.40), the ARPANET/SATNET gateway at NDRE (10.3.0.41), the Comsat DCN Net/SATNET gateway at COMSAT (4.0.0.39), the SATNET/UCL Net/RSRE Net gateway at UCL (4.0.0.60), the PR Net/RCC Net gateway at BBN (3.0.0.62), the PR Net/ARPANET gateways at SRI (10.3.0.51, 10.1.0.51), and the PR Net/ARPANET gateway at Ft. Bragg (10.0.0.38). The gateways forward packets with internet header formats as specified in the DoD Standard Internet Protocol, January, 1980. The gateways implement this Internet Protocol with the following exceptions: 1. The type of service field is ignored, i.e., the gateways use the same type of service in each network regardless of the value of the internet type of service field. 2. No options are implemented. Packets containing options are forwarded by the gateways, subject to the specified constraints, i.e., correct checksum, correct length, non-zero time to live field, but the gateways do not process any options. Packets with options are not fragmented. If a packet is too large to be sent through the next network on the route to its destination and it contains options, then the packet is discarded. BBN H316 and C/30 TAC Date: 14 May 1981 From: Bob Hinden The Terminal Access Controller (TAC) is user Telnet host that supports TCP/IP and NCP host to host protocols. It runs in 32K H-316 and 64K C/30 computers. It supports up to 63 terminal ports. It connects to a network via an 1822 host interface. The TAC's TCP/IP is intended to conform with the IEN-128 and IEN-129 specifications with the following exceptions: 1) IP options are accepted but ignored. 2) TCP options are not accepted. 3) Precedence, Security, etc. are ignored. The TAC also supports Packet core, TAC Monitoring, Internet Control, and a subset of the Gateway-Gateway protocols. For more information on the TAC's design, see IEN-166. Currently, TAC's TCP/IP has been tested with several other implementations. This includes TOPS20 (BBND, BBNC, BBNA, ISID), Multics (MIT-Multics), IBM (UCLA), 11/70 Unix (BBN-Unix,EDN-Unix), and VAX Unix (BBN-VAX). All major features have been implemented except IP reassembly and TCP Urgent handling. These will be done in the near future. BBN HP-3000 Date: 14 May 1981 From: Jack Sax The HP3000 TCP code is in its final testing stages. The code includes under the MPE IV operating system as a special high priority process. It is not a part of the operating system kernel because MPE IV has no kernel. The protocol process includes TCP, IP, 1822 and a new protocol called HDH which allows 1822 messages to be sent over HDLC links. The protocol process has about 8k bytes of code and at least 20k bytes of data depending on the number of buffers allocated. The TCP code is believed to support all features except rubber EOL. The IP code currently supports fragment reassembly but not fragmentation. In addition provisions have been made to allow the IP layer to accept and act on routing and source quench messages. These features will be added sometime this summer. Security and precedence are currently ignored. In addition to the TCP the HP3000 has user and server TELNET as well as user FTP. A server FTP may be added later. A complete description of the implementation software can be found in IEN167. BBN PDP 11/70 UNIX Date: 14 May 1981 From: Jack Haverty This TCP implementation was written in C. It runs as a user process in version 6 UNIX, with modifications added by BBN for network access. It does not perform reassembly, or rubber eol, and has no separate IP user interface. It supports user and server Telnet. This implementation was done under contract to DCEC. It is installed currently on several PDP-11/70s and PDP-11/44s. Contact Ed Cain at DCEC for details of further development. BBN TENEX & TOPS20 Date: 13 May 1981 From: Charles Lynn TCP4 and IP4 are available for use with the TENEX operating system running on a Digital KA10 processor with BBN pager. TCP4 and IP4 are also available as part of TOPS20 Release 3A and Release 4 for the Digital KL10 and KL20 processors. Above the IP layer, there are two Internet protocols within the monitor itself (TCP4 and GGP). In addition up to eight (actually a monitor assembly parameter) protocols may be implemented by user-mode programs via the "Internet User Queue" interface. The GGP or Gateway-Gateway Protocol is used to receive advice from Internet Gateways in order to control message flow. The GGP code is in the process of being changed. TCP4 is the other monitor-supplied protocol and it has two types of connections -- normal data connections and "TCP Virtual Terminal" (TVT) connections. The former are used for bulk data transfers while the latter provide terminal access for remote terminals. Note that TVTs use the standard ("New") TELNET protocol. This is identical to that used on the ARPANET with NCP and in fact, is largely implemented by the same code. At the IP level, fragmentation and reassembly are not currently supported. The Autodin II Security related option can be parsed, but no code for doing preemption of resources has been writen. Certain other security-related options are implemented. User and Server FTP processes above the TCP layer are under active development. BBN UNIX Date: 1 May 1981 From: Mike Wingfield 1. Hardware - PDP-11 running UNIX version 7, with BBN IPC additions. 2. Software - written in C, requiring 22K instruction space, 15K data space. Supports 10 connections. 3. Status - TCP has been essentially completed since March, 1979, and no additional work has been done on it since then. 4. Unimplemented protocol features A. TCP Does not support Rubber EOL Ignores options except S/P/T Discards out-of-order segments B. IP Does not support fragmentation or reassembly. Ignores options 5. Documentation - "TCP/PSIP Development Report", and "TCP Software Documentation", both BBN reports. BBN VAX Date: 7 May 1981 From: Rob Gurwitz The VAX TCP/IP implementation is written in C for Berkeley/VMUNIX. It is described in detail in IEN168. It is currently operational experimentally and is undergoing further development. The implementation is believed to conform to the specification with the following exceptions: 1) All internet options are currently ignored. 2) Security, precedence, etc. are ignored. The TCP/IP is implemented within the kernel. It supports all aspects of the protocol, and provides a separate user interface at the IP level. Continuing development includes implementation of handling internet routing messages, hosts on multiple networks, and performance improvement. Tools are available on the VAX for monitoring and recording net traffic. COMSAT Date: 30 Apr 1980 From: Dave Mills 1. The TCP/IP implementation here runs in an LSI-11 with a homegrown operating system compatible in most respects to RT-11. Besides the TCP/IP levels the system includes many of the common high-level protocols used in the ARPANET community, such as TELNET, FTP and XNET. 2. Connections have been verified with the following other implementations: TOPS-20 (BBNF, ISID, ISIE and ISIF) Unix (BBN, NPL and EDN) Multics (MIT-Multics) IBM 3033 (CCN) Packet Radio TIU (UCL, RSRE) and the several hosts on the COMSAT local net (DCNET) running the the same software. 3. The TCP implementation is believed to conform to the specification in all aspects except: a. It does not implement the rubber-EOL mechanism. All buffers appear a single octed in length. b. It does not implement the urgent mechanism. 4. The IP implementation is believed to conform to the specification in all respects except: a. Fragmentation and reassembly is not implemented. b. All options, including security, timestamping, etc., are ignored by the IP layer. Timestamping is handled by the protocol and user layers. Other options can be specified by the protocol and user layers and checked by the protocol layer. Our plans for the remainder of the FY80 and FY81 years are to upgrade the implementation to conform to the full specification in all practicable respects and, especially, to evaluate overall performance in systems involving both high-performance and limited-performance hosts and nets. DTI VAX Date: 15 May 1981 From: Gary Grossman Digital Technology Incorporated (DTI) IP/TCP for VAX/VMS The following describes the IP and TCP implemenation that DTI plans to begin marketing in 4th Quarter 1981 as part of its VAX/VMS network software package. Hardware: VAX-11/780 or /750. Operating System: DEC standard VAX/VMS Release 2.0 and above. Implementation Language: Mostly C, with some MACRO. Protocol Features Supported: IP: Fragementation/Reassembly: Does not fragment, but does reassemble. Options: Security option is both generated and interpreted. Packet identifier: Can be specified by user, but will generate a unique identifier if user does not supply one. Reassembly timeout: Fixed value. If buffers fill up, oldest fragment is discarded first. Gateway functions: All necessary GGP functions will be implemented. (GGP functions are not implemented in current NFE IP.) Type of Service: As for Gateway functions. Support of protocols other than TCP: Yes, simultaneously with TCP. TCP: Precedence and security fields: Both generated and interpreted. TCP options: All defined options are implemented. Urgent: Implemented as per specification. EOL: As per specification. Buffer size: Option implemented; user may specify buffer size within limits. Retransimission: Timeouts employ exponential backoff until a limit is reached, at which time user is signalled. Transmits empty packets into a zero window. Initial sequence number: Derived from 32-bit system clock with 10 us. resolution. Window strategy: Window size is larger than the actual buffer space available by the size of the maximum size internal buffer. ACK generation: ACK is sent as soon as data has been placed in sequence into user buffer. Code size: IP (Includes BBN 1822 interface code, about 30%): Object code: 14K bytes. Buffer and table space: 24K bytes. Source: 7K lines of C code with commentary. TCP: Object code: 27K bytes. Buffer and table space: 46K bytes. Source: 15K lines of C code with commentary. Fixed table space: See above. Connections supported: Maximum of 64. User level protocols available: TELNET, FTP, and MTP will be available. (The NFE version uses AUTODIN II protocols.) MIT MULTICS Date: 13 May 1981 From: Dave Clark Multics TCP/IP is implemented in PL/1 for the HISI 68/80. It has been in experimental operation for about 18 months; it can be distributed informally as soon as certain modifications to the system are released by Honeywell. The TCP and IP package are currently being tuned for performance, especially high throughput data transfer. It is believed that the implementation fully conforms to the DOD standard. It also supports most relevant features of GGP, including redirect packets. The IP layer is a gateway, and supports fragmantation as well as reassembly. Higher level services include user and server telnet, and a full function MTP mail forwarding package. The TCP and IP contain good logging and debugging facilities, which have proved useful in the checkout of other implementations. Please contact us for further information. SRI LSI-11 Date: 15 May 1981 From: Jim Mathis The IP/TCP implementation for the Packet Radio terminal interface unit is intended to run on an LSI-11 under the MOS real-time operating system. The TCP is written in MACRO-11 assembler language. The IP is currently written in assembler language; but is being converted into C. There are no plans to convert the TCP from assembler into C. The TCP implements the full specification, although the current user interface lacks a mechanism to communicate URGENT pointer information between the TCP and the higher-level software. The code for rubber-EOL has been removed in anticipation of a change to the specification. The TCP appears to be functionally compatible with all other major implementations. In particular, it is used on a daily basis to provide communications between users on the Ft. Bragg PRNET and ISID on the ARPANET. The IP implementation is reasonably complete, providing fragmentation and reassembly; routing to the first gateway; and a complete host-side GGP process. Currently the source quench message is ignored. No IP options are generated and all received options are ignored. A measurement collection mechanism is currently under development to collect TCP and IP statistics and deliver them to a measurement host for data reduction. UCLA IBM Date: 13 May 1981 From: Bob Braden Implementation Status -- IP/TCP for IBM 360/370 under OS/MVT. May 12, 1981 1. Hardware IBM 360 or 370, with a "Santa Barbara" interface to the IMP. 2. Operating System OS/MVS with ACF/VTAM. An OS/MVT version is also available. The UCLA NCP operates as a user job, with its own internal multiprogramming and resource management mechanisms. 3. Implementation Language BAL (IBM's macro assembly language) 4. Protocol features supported: A. IP PROTOCOL: (1) Fragmentation/reassembly: performs reassembly. Does not fragment, assuming that higher-level protocol (TCP) will create suitable size segments during packetizing. (2) Options: all internet options accepted but ignored. None are sent (in particular, no error options). (3) Identifier selection: uses globally-unique identifiers for transmitted segments, independent of destination. (4) Reassembly timeout: fixed value (30-60 seconds), independent of time-to-live field. Packets are discarded if time-to-live field is zero. (5) Gateway functions: Unable to select an alternate route (gateway) if the original route fails. Does accept GGP, and acts on Redirect, Destination Unreachable, and Echo packets. Source Quench is ignored. (6) Type of Service: default Type of Service set, may cause either Subtype 0 or Subtype 3 (Uncontrolled) packets to be sent. B. TCP PROTOCOL: (1) Precedence, security fields: not set or tested. (2) TCP Options: no options generated. All options received but only Buffer Size is acted upon. (3) Urgent: may be sent and received by user process. (4) EOL: may be sent by user process, but received EOL's are not passed to user process. (5) Buffer Size: will transmit according to specified buffer size. Uses circular buffer for received data, so never specifies a buffer size to remote TCP. (6) Retransmission: successive retransmissions use exponential backoff. Base time is 2 times observed weighted-average round-trip time. Round-trip time is measured by initial packet transmission to complete acknowledgment. Retransmits slowly into zero window. (7) Initial Sequence Number: derived from system clock. (8) Window strategy: uses conservative strategy, never adver- tising a receive window larger than the space available in the circular buffer. (9) ACK generation: always sends in response to receipt of a non-empty packet. As user process removes bytes from buffer, optimizing algorithm determines when to generate to inform sender of larger window. 5. Code Size (addition to existing NCP code) Resident Control Process: 4K bytes. Internet Protocol Layer: 10K bytes. (transient) TCP Protocol Layer: 10K bytes. (transient) 6. Fixed Table Space The limited fixed table space is included in the code (above). 7. Connections Supported: Only practical limitation is amount of memory available in NCP region for buffers and per-connection control blocks; requirements are: For each connection, the internet and TCP layers require control blocks totalling 256 bytes. (*) Receive: Segment reassembly buffer= max segment size - min internet header length + 16= 572 bytes per buffer. (*) Send: 128 bytes per unacknowledged segment. Note: the actual data being sent is not counted here, as it occupies buffer space belonging to the appropriate user-level protocol module. (*)Note: there is a pool of these objects, shared among all active connections. The pool grows and shrinks dynamically with the number of connections; it is probably reasonable to expect an average of one segment reassembly buffer and one unacknowledged segment (total of 700 bytes) per TCP connection. In addition to this TCP-specific memory, there is the memory to support the user-level protocol. For example, a server-Telnet session to TSO requires control blocks and buffers totalling about 1800 bytes; this is identical for TCP and for the ARPANET Host-Host ("NCP") protocol. 8. User-Level Protocols Available User and Server Telnet 9. Philosophical Remarks This implementation of the Internet and TCP protocols is designed to meet the following general objectives: (a) operate within the existing NCP system job, sharing code and control-block formats wherever possible; (b) be compatible at the system-call level with the existing user-level protocol modules; (c) implement the Internet protocol as a distinct layer, with interfaces designed to expedite the implementation of other higher-level internet protocols in addition to TCP; (d) require minimum NCP resources when internet protocol is not in use. ------------------------------ Date: 5 Oct 81 20:09:53-EDT (Mon) From: Michael Muuss To: Rob Gurwitz Rob - Thanks very much for the information about the 4.1 BSD TCP/IP implementation. Sounds like a very nice job! What is the feasibility of moving it to a PDP-11 UNIX system? There are some of us who can not afford to subscribe to the Berkeley "PDP-11s are dead" philosophy... Can you feed me any handy dribbles of documentation or overview information? Cheers, -Mike ------------------------------ Date: 3 Oct 1981 00:13:28-PDT From: ESVAX.clemc at Berkeley To: csvax.unix-wizards at Berkeley The 3Com version for the 11 is fairly good. It is like the old U of I NCP in that it is not all kernel resident (like the BBN Version). It IS large. Tektronix has been using it will 2.8 BSD for a few months but they have had lots of trouble. It has been a conbination of sparse comments in the 3Com code, 2.8 BSD and trying to Talk TCP to a CDC Cyber on the other end. They are using Network System's Corp "HYPERchannel" gear for the physical medium, which is very fast but the 11/70 can not keep up with it (niether can the cyber when running TCP). Both BBN and 3Com have used Psuedo TTY's for the Virtual Terminal Protocol. This has both advantages and disadvantages. 3Com wants to make their code portable to other UNIX versions. They are working on/have made to work a version that runs on an 11/34 with overlays. As far as I know, BBN has punted the 11's. Clem ------------------------------ Date: 6 Oct 1981 11:32:45 EDT (Tuesday) From: Rob Gurwitz To: Michael Muuss There is a note describing the internals of the TCP/IP for the VAX available from the ARPANET NIC as IEN 168. In addition, I have manual pages for the lowest level TCP/IP/local net i/f, if you want them. The TELNET and FTP are ports of software that has been around for awhile, so manual pages for them are probably generally available (you probably already have them if you're running NCP on an 11). MTP mail is new, but we have no manual pages ready yet. Rob. ------------------------------ Date: 7 Oct 1981 9:21:34 EDT (Wednesday) From: Rob Gurwitz To: Michael Muuss Here is the manual page for low level TCP access. I hope it's useful. Feel free to include info about the implementation in your summary. Rob. NET(5) UNIX Programmer's Manual NET(5) NAME tcp, ip, rawnet - internet networking software SYNOPSIS open ("/dev/net/net", ncon); struct con *ncon; struct lhost { /* net library format internet address */ unsigned char l_hoi; /* host on imp */ unsigned char l_net; /* network */ n_short l_imp; /* imp */ }; /* c_mode field definitions */ struct con { /* user connection structure */ unsigned char c_mode; /* mode 0-passive 1-active (see flags) */ unsigned char c_sbufs; /* # send buffers to use */ unsigned char c_rbufs; /* # rcv buffers to use */ unsigned char c_prec; /* precedence */ #define c_lo c_prec /* low raw link or proto # */ unsigned char c_sec; /* security level */ #define c_hi c_sec /* hi raw link or proto # */ unsigned char c_compt; /* compartment */ unsigned char c_timeo; /* tcp open timeout */ unsigned char c_x; /* (unused) */ unsigned short c_lport; /* local port */ unsigned short c_fport; /* foreign port */ struct lhost c_con; /* foreign socket */ }; struct netstate { /* network status structure */ unsigned char n_lolink; /* low link no. in range (IP, RAW) */ unsigned char n_hilink; /* high link no. in range (IP, RAW) */ unsigned char n_snd; /* # send bufs allocated */ unsigned char n_rcv; /* # receive bufs allocated */ unsigned char n_ssize; /* # bufs on send buffer */ unsigned char n_rsize; /* # bufs on receive buffer */ unsigned char n_state; /* state of this connection */ unsigned char n_flags; /* misc. flags (see below) */ unsigned short n_lport; /* local port */ unsigned short n_fport; /* foreign port */ struct lhost n_con; /* foreign socket */ }; #define CONACT 1 /* active connection */ #define CONTCP 2 /* open a tcp connection */ #define CONIP 4 /* open a raw ip connection */ #define CONRAW 8 /* open a raw local net connection */ #define CONDEBUG 128 /* turn on debugging info */ /* net ioctl definitions */ #define NETGETS 1 /* get status */ #define NETSETD 2 /* set debugging info */ #define NETSETU 3 /* set urgent mode */ #define NETRSETU 4 /* reset urgent mode */ #define NETSETE 5 /* set EOL mode */ #define NETRSETE 6 /* reset EOL mode */ #define NETCLOSE 7 /* initiate tcp close */ #define NETABO /* initiate tcp abort */ #define SIGURG 16 /* urgent signal */ #ifndef KERNEL /* n_flags field definitions */ #define UEOL 0001 /* EOL sent */ #define UURG 0002 /* urgent data sent */ #define UDEBUG 0004 /* turn ongging info recording */ #define ULOCK 0010 /* receive buffer locked */ #define UTCP 0020 /* this is a TCP connection */ #define UIP 0040 /* this is a raw IP connection */ #define URAW 0100 /* this is a raw 1822 connection */ #define ULISTEN 0200 /* awaiting a connection */ /* n_state field definitions */ #define UCLOSED 0000 /* connection closed */ #define UCLSERR 0001 /* error -- connection closing */ #define UABORT 0002 /* connection aborted */ #define UINTIMO 0004 /* open failed -- init timeout */ #define URXTIMO 0010 /* retransmit too long timeout */ #define URESET 0020 /* connection aborted due to reset */ #define UOPERR 0040 /* open failed -- not enough buffers */ #define UURGENT 0100 /* urgent data received */ #define UNETDWN 0200 /* connection aborted due to net */ #endif KERNEL DESCRIPTION The special file /dev/net/net is used to access ARPANET type packet-switched networks via the DoD standard host-host Internetworking Protocols, TCP (Transmission Control Protocol), and IP (Internet Protocol). It also allows communication over the local network(s) to which the system is connected with "raw" packets, enabling user software to do its own communications processing. Access to the network at this level is the most direct form of use. It is assumed that most users will use higher level protocol programs, like ftp(1) and telnet(1) to communicate over the network. (This description assumes the reader is familiar with ARPANET type communications protocols.) ESTABLISHING CONNECTIONS To establish a connection via TCP or IP, or to communicate with raw packets, the open(2) call is given, with the usual mode argument replaced by a pointer to a connection structure, defined in /usr/include/con.h. The c_mode field of this structure specifies what type of connection is desired (TCP, IP, or RAW), and whether or not the connection is to be active (specifying a specific foreign host address), or passive (with no foreign address, implying that the connection will be established when any foreign process tries to communicate with the opener). The c_sbufs and c_rbufs fields specify buffer allocations for the send and receive sides of the connection, respectively. If either value is zero, the default allocation will be used for that direction (currently 1K bytes). The user can request up to 4K bytes each for send and receive directions by varying these parameters between 1 and 4. The c_prec, c_sec, and c_compt fields specify values of precedence, security level, and compartmentalization for TCP connections. (N.B. This feature is currently not implemented). For IP and RAW connections, the c_hi and c_lo fields specify a range of IP protocol numbers or local net dispatch numbers (e.g., ARPANET link numbers) to watch for. Messages falling into this range are queued for the user. The end of the range is used in sending messages. Low must be less than or equal to high, and numbers in the range must not be in use in any other connection. The c_timeo parameter specifies a length of time in seconds to wait for connection establishment before aborting (this does not apply to passive opens). If the field is zero, the default of 30 seconds is used. The remaining fields specify local, and foreign ports for TCP, and the foreign host address in net long format (see libn(3)). The local port may be zero, in which case TCP assigns a unique port number to the connection. The foreign port and host address may only be zero for a passive open. READING AND WRITING If the open succeeds, a file descriptor is returned which may be used in subsequent reads and writes (see, read(2), write(2)). Reads and writes work as usual with a few exceptions. A read may return with error condition ENETSTAT, which indicates that some exceptional condition has been detected. In this case, a 16 bit value is returned to the read buffer, which give the status of the connection that caused the return. Further status may be determined with ioctl(2). (see, NETWORK STATUS). If the condition is non-fatal, the read may be re-issued. Reads may return less data than requested if a TCP EOL was detected. Reads will block if there is no data for the user. Writes block if the amount of send buffer resources for the connection is exceeded. IP and RAW reads return the appropriate protocol leaders along with any data received. Only one IP or RAW message may be received or sent per call. In addition to normal TCP reads and writes, the user may wish to indicate EOL and URGENT data on writes and receive notification of URGENT data sent by the foreign peer. EOL and URGENT are enabled by issueing the NETSETE or NETSETU ioctl calls. Once set, EOL is sent at the last byte of each subsequent write. Similarly, the URGENT pointer is set to start at the first byte of the next write, and ends with the first byte sent after URGENT mode is disabled. These modes are disabled by the NETRSETE and NETRSETU ioctl calls. URGENT data is indicated by signal SIGURG when the first byte is received. This signal is normally ignored. (A status flag is also set in the presence of urgent data.) CLOSING CONNECTIONS Normally, the close(2) call is used to close a TCP, IP, or RAW connection. In each case, it indicates that the user will send or receive no more data. For TCP connections, close initiates the connection closing protocol, though it returns immediately. Thus, the internal connection structures persist until the connection has reached the CLOSED state. For IP and RAW connections, the close is immediate and deletes all internal structures. In addition to close for TCP connections, there is an ioctl call, NETCLOSE, which indicates that the local connection will send no more data, but is still able to receive data from the foreign peer. In this case, subsequent writes are illegal and will terminate with errors, but subsequent reads will work until the connection is closed by the foreign peer. NETWORK STATUS There are several ioctl(2) calls available for receiving network status information or initiating certain modes or functions. Most of these calls have been described above. The status call, NETGETS, takes a status buffer pointer, which points to a netstate structure, illustrated above, which is filled in by the call. To summarize, the various ioctl calls are: NETGETS Return network status information to the structure pointed at by third argument of ioctl. NETSETD Reset the debugging log to the file name pointed at by the third argument. The file must already exist. If the argument is zero, turn off debug logging (see, DEBUGGING). NETSETU Set urgent mode starting at next byte written (TCP only). NETRSETU Reset urgent mode, urgent pointer ends at last byte written (TCP only). NETSETE Set EOL mode, send EOL at last byte of each subsequent write (TCP only). NETRSETE Terminate EOL mode (TCP only). NETCLOSE Start TCP connection close. User can continue to receive data (TCP only). NETABORT Abort TCP connection. Foreign peer is reset and no more data may be sent or received (TCP only). DEBUGGING The network software enables certain trace information to be recorded for TCP connections. This information is logged in a single debugging log file. To enable this feature, the CONDEBUG bit in the c_mode field of the open connection parameter structure must be set. The default debugging log is /etc/net/tcpdebug. This may be changed or the feature may be disabled system wide with the NETSETD ioctl call. Only the super-user may do this. The format of the debugging information is several bytes of binary data per TCP transaction. The log may be printed in readable form with trpt(1). DIAGNOSTICS The following system error codes may be returned by network system calls: ENETSTAT (35) Network status available (not a fatal error, see READS AND WRITES). ENETDWN (36) Open failed because network connection is unavailable. ENETCON (37) Open failed because there were too many connections. ENETBUF (38) No more network buffer space. ENETERR (39) Fatal error from network protocol processor. ENETRNG (40) IP or RAW open failed because the protocol or dispatch number was out of range or already in use. TCP open failed because the user tried to open an already existing connection (i.e., one with the identical foreign host address and local and foreign ports). FILES /dev/net/net /etc/net/tcpdebug SEE ALSO ftp(1), telnet(1), trpt(1), read(2), write(2), open(2), close(2), ioctl(2), libn(3) R.F. Gurwitz, VAX-UNIX Networking Support Project Implementation Description, DARPA Information Processing Techniques Office, IEN 168, January, 1981. J. Postel (ed.), DoD Standard Internet Protocol, DARPA Information Processing Techniques Office, IEN 128, January, 1980. J. Postel (ed.), DoD Standard Transmission Control Protocol, DARPA Information Processing Techniques Office, IEN 129, January, 1980. ------------------------------ End of TCP-IP Digest ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [anews.Aucbvax.4398] <1981101316500600> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Tue Oct 13 21:50:06 1981 Subject: Re: Please add to your list... X-Google-Info: Converted from the original A-News header >From tcp-ip@brl Tue Oct 13 21:38:19 1981 Geoff (et.al.) - Greetings, and welcome to the TCP/IP Digest mailing list. Please send submissions to "TCP-IP @ BRL", and address any requests to "TCP-IP-REQUEST @ BRL". Enjoy! -Mike Muuss U.S. Army Ballistic Research Laboratory PS: If you desire a copy of Vol 1, #1 (the only issue to date), send a note to TCP-IP-REQUEST@BRL. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [anews.Aucbvax.4403] <1981101320392200> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Wed Oct 14 01:39:22 1981 Subject: TCP-IP Digest, Vol 1 #2 X-Google-Info: Converted from the original A-News header >From tcp-ip@brl Wed Oct 14 01:20:57 1981 TCP/IP Digest Wednesday, 14 Oct 1981 Volume 1 : Issue 2 Today's Topics: Administrative Trivia NCP-to-TCP Transition Deadline!! Performance of 3Com "UNET" UNIX TCP/IP Software Behind the sceens at 3Com & Stanford PUP Final word on BBN PDP-11 TCP/IP Implementation RFCs and IENs -- How to get to NIC Gateway questions ---------------------------------------------------------------------- From: Michael Muuss Subject: TCP-IP Digest, Plans, etc. At this point, everybody who has requested to be added to the TCP-IP discussion list has been added. In addition, Jon Postel had a list for distributing notices about Internetworking changes. At his suggestion, I have incorporated that list into the Digest list. If you are reading this, and don't want to see any more of these Digests, please sent a note to TCP-IP-REQUEST@BRL. The scope of the Digest will probably exceed the rather specific "TCP-IP Digest" title, but that is OK by me. I see this as a forum for discussing implementation and design problems relating to large scale networks, and internetworking. Anything too practical for HUMAN-NETS is fair game here (at least for now). But I would hope that discussion will focus on IP and TCP, because this is where much of the real action seems to be. At the present, I expect to be able to issue one digest per week, with each issue being (hopefully) 15000 to 30000 characters long, depending on submissions. No more mamouth 55K digests (OOPS!). If the interest picks up, I can see being able to do as many as 3 per week. More than that, and I will have to get help, but it will be no problem. Already, some people have mentioned that mailing stuff to "TCP-IP@BRL" might be hard to remember or type. I will be glad to set up as many aliases for the list as seem useful. Everybody: please suggest some mnemonic, short aliases! I am keeping an archive here on BRL (0/29), and hope to announce the method by which they can be retrieved, sometime soon. (However, we can't permit anonymous login, so it will probably be strange). If other sites wish to keep an online copy that can be FTP'ed, please let me know, and I will summarize for the list. Cheers! -Mike ------------------------------ From: POSTEL at USC-ISIF Subject: NCP-to-TCP Transition It is really very important for everyone to notice the deadline for completing the cutover to IP/TCP and the elimination of NCP from use in the ARPANET. The deadline is: 1 January 1983. That is 14 and a half months from now. Really not much more than a year. --jon. ------------------------------ From: croft at SRI-UNIX Subject: UNET at SRI The SRI Telecommunications Sciences Center has been running the 3COM UNET software (release 1.5) on two 11/44's for the past few months and we have been quite pleased. This is contrary to the false rumor circulated in the last TCP/IP digest (V1N1). Both machines run a standard V7; installation was very smooth and straightforward, requiring no hacking of the kernel. We chose the 3COM software over BBN's "free" V6 TCP for just this reason. One of 11/44's is on the ARPANET as SRI-PRMH (packet radio measurement host). A locally written device driver for UNET provides TCP/NCP multiplexing of the single 1822 interface. The other 11/44 is currently being used in a packet radio experimental network at Fort Sill, Oklahoma. The device driver in the latter case speaks CAP5 protocol over an 1822 interface to the radio. Throughput of the ARPANET version seems to be quite good (compared to the V6 BBN): 20K bits/second on an FTP to ourselves with the packets looping all the way out the 1822 and back in again. Of course UNET is doing twice as much work here as normal and one would expect perhaps 40K bps if two UNETs were FTPing thru the same IMP. Although UNET is certainly the fastest PDP11 TCP around, it still has the thruput constraints inherent in any TCP. (See the excellent article by Bunch and Day of DTI: "Control Structure Overhead in TCP"). 3COM claims 100K bps max thruput for their TCP on DEC hardware. I think a previous digest entry mentioned 50 to 60K average thruput on DA11 hardware (DA's are about 8Mbps devices). My beef is that with simpler protocols one should be able to do much better. As an example I mention the UNIX network at Purdue University EE department. It uses 1M bps DMC and DMR link hardware and achieves 400K end to end process usable bandwidth. Perhaps TCP's on a fast local network should support some simpler subset of the protocol as an option to allow improved thruput. --Bill Croft (croft@sri-unix) ------------------------------ From: Bill Nowicki Subject: Re: Re: TCP/IP for UNIX I know Bob Metcalfe, Ron Crane, Bruce Borden, and Greg Shaw either directly or indirectly; these are the main movers behind 3COM. Bob invented Ethernet at Xerox, with Ron designing some of their controllers. Bruce and Greg are Unix wizards, so between them there is a lot of expertise. 3COM has been targetting their marketing to small systems (11s and even Onyxes), and since we (Stanford) have mostly Vaxes and 20s, we are pressured into going with BBN's implementation because it was Arpa-sponsored. By the way, we are currently using the PUP Internetwork architecture at Stanford, which Metcalfe had a hand in designing. It was quite a step for him to adopt the DOD Internetwork architecture for the sake of standardization. A welcome change from the "not invented here" syndrome. -- Bill ------------------------------ From: Michael A. Wingfield Subject: TCP/IP Mike, I have a report which documents the [BBN] unix tcp/ip which I can send you. If you want it, send me your mailing address. We have not done any work on the software for about 2 years, so it is probably the same as your 115 tape. We have no plans to do anything else to the 11/70 version of tcp/ip. Thanks, Mike ------------------------------ From: Zellich at OFFICE-3 (Rich Zellich) Subject: Please add me... ...to the TCP-IP distribution. Are you aware of all the stuff on TCP and IP in the IEN documents maintained by the NIC (similar to the RFC's, but relating to the Internetwork Experiment funded primarily by DARPA and taking place primarily on the ARPANET)? I suggest that at least some mention of the IEN's be made in an early issue/message for anyone who is interested but may not yet know about them. I don't know of any general distribution list for notice of new IEN's (I'm on distribution for the IN Experiment group, though not participating), so many people may not yet be aware of them. Cheers, Rich ------------------------------ [ Here is a repeat of a letter from the V1#1 which describes some RFCs availible at SRI-NIC. -MJM ] From: Postel at USC-ISIF RFCs 791, 792, and 793 define IP and TCP. The ARPANET already supports these protocols. Many TOPS20s, Unix-es (including VAX) and MIT-Multics, and UCLAs IBM system, already have these protocols in use. Work is in progress to replace all TIPs with TACs that use IP and TCP. There are about 10 internet gateways in service already. ARPA has set a goal for the complete switchover to IP and TCP by January 1983. ------------------------------ From: James.Gosling at CMU-10A (C410JG40) The mail standards are documented in RFCs (Requests For Comment) from the network information center at ISI. To get a copy of an RFC just ftp to NIC, log in as user "anonymous", password "guest" and retrieve the file RFCnnn.TXT . nnn is the RFC number, some useful ones are: RFC733 Mail message format standard RFC754/RFC799 Discussions of internet addressing RFC759 Internet mail transfer protocol RFC780 Mail transfer protocol James. ------------------------------ From: lou at UCLA-Security (Lou Nelson) Subject: New List I would very much like to be on the TCP/IP mailing list. I think a good first entry would be the report you compiled that everyone wanted to see. If it is not available, perhaps you could do a short summary if it's not too much work. I'm getting a VAX up at Aerospace Corp. that will run UNIX in December and currently the only good prospect for getting it on the net is the BBN TCP/IP that Berkeley is pounding on as a final debugging measure. I don't understand the way (which sites) I get to an NCP host from the TCP VAX yet. Pointers to any RFC or other document that explains that will be appreciated. Regards, Lou Nelson [ Please reply to TCP-IP@BRL, so all can benefit from any answers -MJM ] ------------------------------ End of TCP-IP Digest ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1981101322473000> Mail-from: ARPANET host BRL rcvd at 14-Oct-81 0217-PDT Date: 14 Oct 81 2:47:30-EDT (Wed) From: Mike Muuss To: tcp-ip at Brl Subject: TCP-IP Digest, Vol 1 #2 TCP/IP Digest Wednesday, 14 Oct 1981 Volume 1 : Issue 2 Today's Topics: Administrative Trivia NCP-to-TCP Transition Deadline!! Performance of 3Com "UNET" UNIX TCP/IP Software Behind the sceens at 3Com & Stanford PUP Final word on BBN PDP-11 TCP/IP Implementation RFCs and IENs -- How to get to NIC Gateway questions ---------------------------------------------------------------------- From: Michael Muuss Subject: TCP-IP Digest, Plans, etc. At this point, everybody who has requested to be added to the TCP-IP discussion list has been added. In addition, Jon Postel had a list for distributing notices about Internetworking changes. At his suggestion, I have incorporated that list into the Digest list. If you are reading this, and don't want to see any more of these Digests, please sent a note to TCP-IP-REQUEST@BRL. The scope of the Digest will probably exceed the rather specific "TCP-IP Digest" title, but that is OK by me. I see this as a forum for discussing implementation and design problems relating to large scale networks, and internetworking. Anything too practical for HUMAN-NETS is fair game here (at least for now). But I would hope that discussion will focus on IP and TCP, because this is where much of the real action seems to be. At the present, I expect to be able to issue one digest per week, with each issue being (hopefully) 15000 to 30000 characters long, depending on submissions. No more mamouth 55K digests (OOPS!). If the interest picks up, I can see being able to do as many as 3 per week. More than that, and I will have to get help, but it will be no problem. Already, some people have mentioned that mailing stuff to "TCP-IP@BRL" might be hard to remember or type. I will be glad to set up as many aliases for the list as seem useful. Everybody: please suggest some mnemonic, short aliases! I am keeping an archive here on BRL (0/29), and hope to announce the method by which they can be retrieved, sometime soon. (However, we can't permit anonymous login, so it will probably be strange). If other sites wish to keep an online copy that can be FTP'ed, please let me know, and I will summarize for the list. Cheers! -Mike ------------------------------ From: POSTEL at USC-ISIF Subject: NCP-to-TCP Transition It is really very important for everyone to notice the deadline for completing the cutover to IP/TCP and the elimination of NCP from use in the ARPANET. The deadline is: 1 January 1983. That is 14 and a half months from now. Really not much more than a year. --jon. ------------------------------ From: croft at SRI-UNIX Subject: UNET at SRI The SRI Telecommunications Sciences Center has been running the 3COM UNET software (release 1.5) on two 11/44's for the past few months and we have been quite pleased. This is contrary to the false rumor circulated in the last TCP/IP digest (V1N1). Both machines run a standard V7; installation was very smooth and straightforward, requiring no hacking of the kernel. We chose the 3COM software over BBN's "free" V6 TCP for just this reason. One of 11/44's is on the ARPANET as SRI-PRMH (packet radio measurement host). A locally written device driver for UNET provides TCP/NCP multiplexing of the single 1822 interface. The other 11/44 is currently being used in a packet radio experimental network at Fort Sill, Oklahoma. The device driver in the latter case speaks CAP5 protocol over an 1822 interface to the radio. Throughput of the ARPANET version seems to be quite good (compared to the V6 BBN): 20K bits/second on an FTP to ourselves with the packets looping all the way out the 1822 and back in again. Of course UNET is doing twice as much work here as normal and one would expect perhaps 40K bps if two UNETs were FTPing thru the same IMP. Although UNET is certainly the fastest PDP11 TCP around, it still has the thruput constraints inherent in any TCP. (See the excellent article by Bunch and Day of DTI: "Control Structure Overhead in TCP"). 3COM claims 100K bps max thruput for their TCP on DEC hardware. I think a previous digest entry mentioned 50 to 60K average thruput on DA11 hardware (DA's are about 8Mbps devices). My beef is that with simpler protocols one should be able to do much better. As an example I mention the UNIX network at Purdue University EE department. It uses 1M bps DMC and DMR link hardware and achieves 400K end to end process usable bandwidth. Perhaps TCP's on a fast local network should support some simpler subset of the protocol as an option to allow improved thruput. --Bill Croft (croft@sri-unix) ------------------------------ From: Bill Nowicki Subject: Re: Re: TCP/IP for UNIX I know Bob Metcalfe, Ron Crane, Bruce Borden, and Greg Shaw either directly or indirectly; these are the main movers behind 3COM. Bob invented Ethernet at Xerox, with Ron designing some of their controllers. Bruce and Greg are Unix wizards, so between them there is a lot of expertise. 3COM has been targetting their marketing to small systems (11s and even Onyxes), and since we (Stanford) have mostly Vaxes and 20s, we are pressured into going with BBN's implementation because it was Arpa-sponsored. By the way, we are currently using the PUP Internetwork architecture at Stanford, which Metcalfe had a hand in designing. It was quite a step for him to adopt the DOD Internetwork architecture for the sake of standardization. A welcome change from the "not invented here" syndrome. -- Bill ------------------------------ From: Michael A. Wingfield Subject: TCP/IP Mike, I have a report which documents the [BBN] unix tcp/ip which I can send you. If you want it, send me your mailing address. We have not done any work on the software for about 2 years, so it is probably the same as your 115 tape. We have no plans to do anything else to the 11/70 version of tcp/ip. Thanks, Mike ------------------------------ From: Zellich at OFFICE-3 (Rich Zellich) Subject: Please add me... ...to the TCP-IP distribution. Are you aware of all the stuff on TCP and IP in the IEN documents maintained by the NIC (similar to the RFC's, but relating to the Internetwork Experiment funded primarily by DARPA and taking place primarily on the ARPANET)? I suggest that at least some mention of the IEN's be made in an early issue/message for anyone who is interested but may not yet know about them. I don't know of any general distribution list for notice of new IEN's (I'm on distribution for the IN Experiment group, though not participating), so many people may not yet be aware of them. Cheers, Rich ------------------------------ [ Here is a repeat of a letter from the V1#1 which describes some RFCs availible at SRI-NIC. -MJM ] From: Postel at USC-ISIF RFCs 791, 792, and 793 define IP and TCP. The ARPANET already supports these protocols. Many TOPS20s, Unix-es (including VAX) and MIT-Multics, and UCLAs IBM system, already have these protocols in use. Work is in progress to replace all TIPs with TACs that use IP and TCP. There are about 10 internet gateways in service already. ARPA has set a goal for the complete switchover to IP and TCP by January 1983. ------------------------------ From: James.Gosling at CMU-10A (C410JG40) The mail standards are documented in RFCs (Requests For Comment) from the network information center at ISI. To get a copy of an RFC just ftp to NIC, log in as user "anonymous", password "guest" and retrieve the file RFCnnn.TXT . nnn is the RFC number, some useful ones are: RFC733 Mail message format standard RFC754/RFC799 Discussions of internet addressing RFC759 Internet mail transfer protocol RFC780 Mail transfer protocol James. ------------------------------ From: lou at UCLA-Security (Lou Nelson) Subject: New List I would very much like to be on the TCP/IP mailing list. I think a good first entry would be the report you compiled that everyone wanted to see. If it is not available, perhaps you could do a short summary if it's not too much work. I'm getting a VAX up at Aerospace Corp. that will run UNIX in December and currently the only good prospect for getting it on the net is the BBN TCP/IP that Berkeley is pounding on as a final debugging measure. I don't understand the way (which sites) I get to an NCP host from the TCP VAX yet. Pointers to any RFC or other document that explains that will be appreciated. Regards, Lou Nelson [ Please reply to TCP-IP@BRL, so all can benefit from any answers -MJM ] ------------------------------ End of TCP-IP Digest ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [anews.Aucbvax.4417] <1981101416050500> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Wed Oct 14 21:05:05 1981 Subject: TCP-IP Digest, Vol 1 #1 X-Google-Info: Converted from the original A-News header >From tcp-ip@brl Wed Oct 14 20:35:46 1981 TCP/IP Digest Thursday, 8 Oct 1981 Volume 1 : Issue 1 Today's Topics: A new Discussion Group Gateway Connection Policy -- TCP and IP Protocol Definitions Comments on TCP4 from BBN -- SRI Networks Development Group EDN-UNIX TCP/IP Notes -- 3Com TCP/IP Troubles NALCON Conversion Meeting -- BRL TCP/IP Environment (Planned) BBN VMUNIX (4.1BSD) TCP/IP -- BBNCC C/30 Features & Futures UTexas TCP4 (BBN) Mods -- 3Com TCP/IP: A Happy User Internet Gateway & Computer List -- TCP/IP Implementation Status Overview Are PDP-11's Dead? -- 3Com TCP/IP: More comments BBN TCP/IP for VAX: Manual Page ---------------------------------------------------------------------- From: Michael Muuss Subject: A New Discussion Group Greetings Earthlings! This is the first issue of a new digest which purports to discuss TCP and IP, the "DoD Standard Networking Protocols for the Eighties". Comments will probably center around UNIX implementations, but any technical networking or implementation discussions too specific for HUMAN-NETS is fair game here. Please send submissions to "TCP-IP @ BRL", requests to "TCP-REQUEST @ BRL" or "TCP-IP-REQUEST @ BRL". This is sort of a spur-of-the-moment thing; it started with our trying to find out about TCP/IP iplementations, and wound up with dozens of letters asking for a report of what I found. This list may die stillborn, or it may flurish. Only time will tell! Cheers, -Mike ------------------------------ Date: 1 Oct 1981 1022-PDT Sender: WESTINE at USC-ISIF From: Postel@isif 1) The question about connection policy should be directed to DCA or your site's ARPANET sponsor. But my guess at an answer is "For a site with a host on the ARPANET (properly authorized) there should be no additional policy issues in connecting a local network to the ARPA Internet when the purpose and use of the local net is the same as for the existing host." 2) The question about IP and TCP is correctly addressed to me. RFCs 791, 792, and 793 define IP and TCP. The ARPANET already supports these protocols. Many TOPS20s, Unix-es (including VAX) and MIT-Multics, and UCLAs IBM system, already have these protocols in use. Work is in progress to replace all TIPs with TACs that use IP and TCP. There are about 10 internet gateways in service already. ARPA has set a goal for the complete switchover to IP and TCP by January 1983. --jon. ------------------------------ Date: 2 Oct 1981 0520-PDT From: DEDWARDS at USC-ISI BBN (of course) has a TCP 4 up and running written in C. Its slow and large (mainly due to the fact that it is entirely outside the kernelrunning as a user pgm with only a device driver in the kernel. Jack Haverty (JHAVERTY at BBN) or Mike Wingfield (wingfield at BBN-UNIX or BBN-RSM) can say lots more. Howard Weiss ------------------------------ Date: 2 Oct 1981 0702-PDT From: NRL at USC-ISIE For you information the below message was received by us in late September 1981; you may find in useful. Regards, Doug Shannon - ARPAnet mailbox - NRL@ISIE - - - - - - - - - The Networks Development group at SRI can offer assistance in the development or operations support of one or more of the following: - modernizing the NALCON sites UNIX from Version 6 to Version 7 (the current release from BTL); - 96-bit leader NCP software required to address all hosts on the ARPANET; - DoD standard TCP/IP network software with Version 7 UNIX and associated user software such as TCP-FTP, MTP (Mail Transfer Protocol), TELNET, etc.; - TCP/NCP mail gateway software to facilitate transition from NCP to TCP; - a VDH Front-End which would remove the overhead associated with the Very Distant Host protocol off of UNIX; - other areas related to UNIX and network systems. The Networks Development group at SRI specializes in the development of local and long-haul network software, hardware, and protocols. There are currently 8 UNIX systems in operation at SRI, most of which are attached to our local area network and/or the ARPANET. If you would like to discuss your needs and how we can assist you in any of the mentioned areas, please contact me at: Geoff Goodfellow 333 Ravenswood Ave. Menlo Park, CA. 94025 (415) 859-3098 ARPANET: Geoff@SRI-CSL ------------------------------ Date: 2 Oct 1981 13:38:33 EDT From: Edward A. Cain Our TCP/IP is an extension of the one on the 11/70 at BBN, in case you have already heard from them. It runs on V6 here, and on V7 at BBN. Both machines support two interprocess communication mods to UNIX in order to allow the tcp/ip to work: (a) Rand "ports", with supporting "await" and "capacity" system calls, or (b) shared memory. The user-to- tcp interface can employ either of these techniques. Our extensions to that work include: (a) handling GGP or ICMP packets, and (b) reassembly of fragments within IP. You're welcome to the sources, manual pages, and UNIX hacks needed to make them work -- if you are using an 11/70. If you have some other machine like the C/70 or a vax, better get in touch with someone at BBN. Their active work on tcp/ip has centered around those 2 machines over the past couple of years. Jack Haverty is one point of contact (haverty at bbn-unix). I recall an SRI status report on the 3-com stuff just last week. Seems the 3-com tcp/ip is full of bugs, and 3-com is under no obligation to fix things under the license agreement. However, SRI (one of 3-com's customers) has been able to get some fixes out of 3-com. Sounds kind of risky. Ed Cain ------------------------------ Date: Fri, 2 Oct 81 16:31-PDT From: Greg at NPRDC Indeed, we all are [Converting to TCP/IP] in a year or so. Geoff@SRI-CSL has offered to help the NALCON sites convert; maybe we can all get together and reduce our mutual costs. We're trying to set up a meeting to talk about it, probabally in the DC area; would you be interested in it? ------------------------------ Date: 2 Oct 81 20:45:01-EDT (Fri) From: Michael Muuss To: Greg at NPRDC We will probably be building an extensive local network which will initially include such varried systems as a CDC 7600 (SCOPE), CDC 173 (NOS), 40 MIPS HEP (UNIX, probably!), zillions of 11/70s and 11/34s, PE 3240s, C/70s, etc, and using Hyperchannels, PCL-11Bs, DQ-11s, UMC-11s, .... for communications. In my opinion, only a "standard" protocol like TCP will permit a plan like this to succeed (!). Networking forever! -Mike ------------------------------ Date: 5 Oct 1981 9:24:30 EDT (Monday) From: Rob Gurwitz Jack Haverty passed your inquiry about TCP/IP along to me. In addition to the experimental TCP/IP that was done for the 11's (which you may or may not already have), we have been developing a version for the VAX running Berkeley 4.1BSD UNIX. This software is a full implementation of the protocols and is completely independent of any of the old U of I NCP code (including the RMI). It allows access at the TCP, IP, or local network access levels. The software is currently running and under test at several sites, including Berkeley. When it is generally released (probably around the first of the year), it will be available through Berkeley and will be included as part of a future 4.xbsd distribution. The configuration currently supports ARPANET 1822 local net protocol and a driver for the ACC LH/DH-11 IMP i/f, but work is also going on to develop other local net drivers (i.e., ETHERNET) for it. Rob Gurwitz ------------------------------ Date: 2 Oct 81 18:48:08-EDT (Fri) From: Michael Muuss To: Paul Santos Subject: C/30 Features & Futures Just out of curiosity, I have some questions about our nice shiney new C/30. 1) How difficult is it to change a DISTANT host interface to a LOCAL host interface. It it a switch, a board, or a big deal? Could you estimate the cost of doing this? Our liason's crystal ball must have been a little cloudy... 2) Just for kicks, is it possible for a C/30 to support either (a) more than 4 modem lines, and/or (b) run the trunk lines at more than 50Kb? 3) Is there any provision for more than one trunk to connect between two C/30's to improve transmission between them? We are doing a lot of planning here on networking, and are strongly considering using TCP/IP. What can you tell me about (or point me to) how BBN plans to proceed with TCP, and how will this affect the ArpaNet? Cheers, -Mike ------------------------------ Date: 4 Oct 1981 16:10:25 EDT (Sunday) From: Paul Santos To: Michael Muuss Mike, I have forwarded your message to Nancy Mimno, who is the primary point of contact for ARPANET users. I believe the answers are in brief: 1) Easy, 2)(a) in progress, 2)(b) already exists, and 3) has been thought of but not currently planned. As for TCP/IP, it is a host isssue, and does not directly affect the subnetwork; however, DCA and ARPA (and DoD in general) are pushing on TCP and plan to outlaw NCP someday. Paul ------------------------------ Date: 5 Oct 1981 at 0945-CDT From: roya at UTEXAS-11 (roya) I have been working on TCP/IP BBN version 4 in our PWB-UNIX System. There were and are some problems that I'm trying to fix in it. Let me know if I can be any help to you. Roya ------------------------------ Date: 7 Oct 1981 11:38:55-PDT From: menlo70!sytek!zehntel!billn at Berkeley We have been running it [3Com] for a short time between two 70's hooked up via an able da-11. With unloaded systems we get about 60kb during file transfer. With one heavily loaded system and one lightly loaded one we get about 45kb. We run 2.?bsd and had a few problems, not many, during installation. Our problems were due to the fact that, as the previous msg said, it IS big. They have tried v. hard to make it a "drop in" product, and have done a good job, but the 2.?bsd systems are just too huge, as normally run, to avoid some hacking during installation. (3com is now more experienced in 2.?bsd-ese than they were...) It seems relatively bug free and robust. Our general users have not been unleashed on it yet -- that'l be the really telling blow. /b ------------------------------ Date: 5 Oct 1981 1358-PDT From: POSTEL at USC-ISIF To: mike.bmd70 at BRL < INC-PROJECT, IN-HOST-TABLE.NLS.25, >, 27-May-81 16:52 JBP ;;;; ADDRESSES The internet addresses in this memo are stated as four 8-bit fields with the value of each field given in decimal. GATEWAYS Name Addresses --------------- --- --- --- --- --- --- --- --- DCEC-EDN/ARPA 21 0 0 2 10 3 0 20 MIT-LCS/ARPA 18 8 0 4 10 0 0 77 BBN-RCC/ARPA 3 2 0 5 10 2 0 5 BBN-SAT/ARPA 4 0 0 61 10 3 0 40 NDRE-SAT/ARPA 4 0 0 38 10 3 0 41 COMSAT-SAT/COMSAT 4 0 0 39 29 0 2 2 UCL-SAT/UCL 4 0 0 60 11 3 0 42 UCL-SAT/NULL 4 0 0 60 35 7 0 0 UCL-UCL/RSRE 11 3 2 42 25 6 0 0 RSRE-NULL/PPSN 35 6 0 0 25 6 0 0 RSRE-NULL/PPSN 35 6 0 0 25 13 0 0 SRI-PR1/ARPA 2 0 0 11 10 3 0 51 SRI-PR2/ARPA 6 0 0 11 10 1 0 51 BBN-BBNPR/ARPA 1 0 0 11 3 0 0 62 Bragg-BraggPR/ARPA 9 0 0 11 10 0 0 38 COMPUTERS Name Address --------------- --- --- --- --- ALTA-COMA 3 1 0 50 BBN-UNIX 10 0 0 63 BBN-VAX 10 2 0 82 BBNA 10 3 0 5 BBNB 10 0 0 49 BBNC 10 3 0 49 BBND 10 1 0 49 BBNE 10 0 0 5 BBNF 3 2 0 51 BBNG 10 1 0 5 EDN-HOST1 21 1 0 1 EDN-HOST3 21 0 0 3 EDN-UNIX 10 3 0 20 ISIB 10 3 0 52 ISIC 10 2 0 22 ISID 10 0 0 27 ISIE 10 1 0 52 ISIF 10 2 0 52 MIT-DevMultics 10 4 0 31 MIT-Multics 10 0 0 6 UCLA-CCN 3033 10 1 0 1 ------------------------------ Date: 5 Oct 1981 1544-PDT From: POSTEL at USC-ISIF BBN C/70 UNIX Date: 14 May 1981 From: Jack Haverty The C/70 processor is a BBN-designed system using C as its native mode. It supports Version 7 of UNIX, and provides for user processes with 20-bit address spaces. The TCP/IP for this machine is in development; the BBN VAX-11/780 UNIX implementation will be ported to the C/70 UNIX system. This work is expected to be complete in summer '81. BBN GATEWAYS Date: 8 May 1981 From: Ginny Strazisar This is a status report on the implementation of the Internet Protocol in these gateways: the ARPANET/SATNET gateway at BBN (10.3.0.40), the ARPANET/SATNET gateway at NDRE (10.3.0.41), the Comsat DCN Net/SATNET gateway at COMSAT (4.0.0.39), the SATNET/UCL Net/RSRE Net gateway at UCL (4.0.0.60), the PR Net/RCC Net gateway at BBN (3.0.0.62), the PR Net/ARPANET gateways at SRI (10.3.0.51, 10.1.0.51), and the PR Net/ARPANET gateway at Ft. Bragg (10.0.0.38). The gateways forward packets with internet header formats as specified in the DoD Standard Internet Protocol, January, 1980. The gateways implement this Internet Protocol with the following exceptions: 1. The type of service field is ignored, i.e., the gateways use the same type of service in each network regardless of the value of the internet type of service field. 2. No options are implemented. Packets containing options are forwarded by the gateways, subject to the specified constraints, i.e., correct checksum, correct length, non-zero time to live field, but the gateways do not process any options. Packets with options are not fragmented. If a packet is too large to be sent through the next network on the route to its destination and it contains options, then the packet is discarded. BBN H316 and C/30 TAC Date: 14 May 1981 From: Bob Hinden The Terminal Access Controller (TAC) is user Telnet host that supports TCP/IP and NCP host to host protocols. It runs in 32K H-316 and 64K C/30 computers. It supports up to 63 terminal ports. It connects to a network via an 1822 host interface. The TAC's TCP/IP is intended to conform with the IEN-128 and IEN-129 specifications with the following exceptions: 1) IP options are accepted but ignored. 2) TCP options are not accepted. 3) Precedence, Security, etc. are ignored. The TAC also supports Packet core, TAC Monitoring, Internet Control, and a subset of the Gateway-Gateway protocols. For more information on the TAC's design, see IEN-166. Currently, TAC's TCP/IP has been tested with several other implementations. This includes TOPS20 (BBND, BBNC, BBNA, ISID), Multics (MIT-Multics), IBM (UCLA), 11/70 Unix (BBN-Unix,EDN-Unix), and VAX Unix (BBN-VAX). All major features have been implemented except IP reassembly and TCP Urgent handling. These will be done in the near future. BBN HP-3000 Date: 14 May 1981 From: Jack Sax The HP3000 TCP code is in its final testing stages. The code includes under the MPE IV operating system as a special high priority process. It is not a part of the operating system kernel because MPE IV has no kernel. The protocol process includes TCP, IP, 1822 and a new protocol called HDH which allows 1822 messages to be sent over HDLC links. The protocol process has about 8k bytes of code and at least 20k bytes of data depending on the number of buffers allocated. The TCP code is believed to support all features except rubber EOL. The IP code currently supports fragment reassembly but not fragmentation. In addition provisions have been made to allow the IP layer to accept and act on routing and source quench messages. These features will be added sometime this summer. Security and precedence are currently ignored. In addition to the TCP the HP3000 has user and server TELNET as well as user FTP. A server FTP may be added later. A complete description of the implementation software can be found in IEN167. BBN PDP 11/70 UNIX Date: 14 May 1981 From: Jack Haverty This TCP implementation was written in C. It runs as a user process in version 6 UNIX, with modifications added by BBN for network access. It does not perform reassembly, or rubber eol, and has no separate IP user interface. It supports user and server Telnet. This implementation was done under contract to DCEC. It is installed currently on several PDP-11/70s and PDP-11/44s. Contact Ed Cain at DCEC for details of further development. BBN TENEX & TOPS20 Date: 13 May 1981 From: Charles Lynn TCP4 and IP4 are available for use with the TENEX operating system running on a Digital KA10 processor with BBN pager. TCP4 and IP4 are also available as part of TOPS20 Release 3A and Release 4 for the Digital KL10 and KL20 processors. Above the IP layer, there are two Internet protocols within the monitor itself (TCP4 and GGP). In addition up to eight (actually a monitor assembly parameter) protocols may be implemented by user-mode programs via the "Internet User Queue" interface. The GGP or Gateway-Gateway Protocol is used to receive advice from Internet Gateways in order to control message flow. The GGP code is in the process of being changed. TCP4 is the other monitor-supplied protocol and it has two types of connections -- normal data connections and "TCP Virtual Terminal" (TVT) connections. The former are used for bulk data transfers while the latter provide terminal access for remote terminals. Note that TVTs use the standard ("New") TELNET protocol. This is identical to that used on the ARPANET with NCP and in fact, is largely implemented by the same code. At the IP level, fragmentation and reassembly are not currently supported. The Autodin II Security related option can be parsed, but no code for doing preemption of resources has been writen. Certain other security-related options are implemented. User and Server FTP processes above the TCP layer are under active development. BBN UNIX Date: 1 May 1981 From: Mike Wingfield 1. Hardware - PDP-11 running UNIX version 7, with BBN IPC additions. 2. Software - written in C, requiring 22K instruction space, 15K data space. Supports 10 connections. 3. Status - TCP has been essentially completed since March, 1979, and no additional work has been done on it since then. 4. Unimplemented protocol features A. TCP Does not support Rubber EOL Ignores options except S/P/T Discards out-of-order segments B. IP Does not support fragmentation or reassembly. Ignores options 5. Documentation - "TCP/PSIP Development Report", and "TCP Software Documentation", both BBN reports. BBN VAX Date: 7 May 1981 From: Rob Gurwitz The VAX TCP/IP implementation is written in C for Berkeley/VMUNIX. It is described in detail in IEN168. It is currently operational experimentally and is undergoing further development. The implementation is believed to conform to the specification with the following exceptions: 1) All internet options are currently ignored. 2) Security, precedence, etc. are ignored. The TCP/IP is implemented within the kernel. It supports all aspects of the protocol, and provides a separate user interface at the IP level. Continuing development includes implementation of handling internet routing messages, hosts on multiple networks, and performance improvement. Tools are available on the VAX for monitoring and recording net traffic. COMSAT Date: 30 Apr 1980 From: Dave Mills 1. The TCP/IP implementation here runs in an LSI-11 with a homegrown operating system compatible in most respects to RT-11. Besides the TCP/IP levels the system includes many of the common high-level protocols used in the ARPANET community, such as TELNET, FTP and XNET. 2. Connections have been verified with the following other implementations: TOPS-20 (BBNF, ISID, ISIE and ISIF) Unix (BBN, NPL and EDN) Multics (MIT-Multics) IBM 3033 (CCN) Packet Radio TIU (UCL, RSRE) and the several hosts on the COMSAT local net (DCNET) running the the same software. 3. The TCP implementation is believed to conform to the specification in all aspects except: a. It does not implement the rubber-EOL mechanism. All buffers appear a single octed in length. b. It does not implement the urgent mechanism. 4. The IP implementation is believed to conform to the specification in all respects except: a. Fragmentation and reassembly is not implemented. b. All options, including security, timestamping, etc., are ignored by the IP layer. Timestamping is handled by the protocol and user layers. Other options can be specified by the protocol and user layers and checked by the protocol layer. Our plans for the remainder of the FY80 and FY81 years are to upgrade the implementation to conform to the full specification in all practicable respects and, especially, to evaluate overall performance in systems involving both high-performance and limited-performance hosts and nets. DTI VAX Date: 15 May 1981 From: Gary Grossman Digital Technology Incorporated (DTI) IP/TCP for VAX/VMS The following describes the IP and TCP implemenation that DTI plans to begin marketing in 4th Quarter 1981 as part of its VAX/VMS network software package. Hardware: VAX-11/780 or /750. Operating System: DEC standard VAX/VMS Release 2.0 and above. Implementation Language: Mostly C, with some MACRO. Protocol Features Supported: IP: Fragementation/Reassembly: Does not fragment, but does reassemble. Options: Security option is both generated and interpreted. Packet identifier: Can be specified by user, but will generate a unique identifier if user does not supply one. Reassembly timeout: Fixed value. If buffers fill up, oldest fragment is discarded first. Gateway functions: All necessary GGP functions will be implemented. (GGP functions are not implemented in current NFE IP.) Type of Service: As for Gateway functions. Support of protocols other than TCP: Yes, simultaneously with TCP. TCP: Precedence and security fields: Both generated and interpreted. TCP options: All defined options are implemented. Urgent: Implemented as per specification. EOL: As per specification. Buffer size: Option implemented; user may specify buffer size within limits. Retransimission: Timeouts employ exponential backoff until a limit is reached, at which time user is signalled. Transmits empty packets into a zero window. Initial sequence number: Derived from 32-bit system clock with 10 us. resolution. Window strategy: Window size is larger than the actual buffer space available by the size of the maximum size internal buffer. ACK generation: ACK is sent as soon as data has been placed in sequence into user buffer. Code size: IP (Includes BBN 1822 interface code, about 30%): Object code: 14K bytes. Buffer and table space: 24K bytes. Source: 7K lines of C code with commentary. TCP: Object code: 27K bytes. Buffer and table space: 46K bytes. Source: 15K lines of C code with commentary. Fixed table space: See above. Connections supported: Maximum of 64. User level protocols available: TELNET, FTP, and MTP will be available. (The NFE version uses AUTODIN II protocols.) MIT MULTICS Date: 13 May 1981 From: Dave Clark Multics TCP/IP is implemented in PL/1 for the HISI 68/80. It has been in experimental operation for about 18 months; it can be distributed informally as soon as certain modifications to the system are released by Honeywell. The TCP and IP package are currently being tuned for performance, especially high throughput data transfer. It is believed that the implementation fully conforms to the DOD standard. It also supports most relevant features of GGP, including redirect packets. The IP layer is a gateway, and supports fragmantation as well as reassembly. Higher level services include user and server telnet, and a full function MTP mail forwarding package. The TCP and IP contain good logging and debugging facilities, which have proved useful in the checkout of other implementations. Please contact us for further information. SRI LSI-11 Date: 15 May 1981 From: Jim Mathis The IP/TCP implementation for the Packet Radio terminal interface unit is intended to run on an LSI-11 under the MOS real-time operating system. The TCP is written in MACRO-11 assembler language. The IP is currently written in assembler language; but is being converted into C. There are no plans to convert the TCP from assembler into C. The TCP implements the full specification, although the current user interface lacks a mechanism to communicate URGENT pointer information between the TCP and the higher-level software. The code for rubber-EOL has been removed in anticipation of a change to the specification. The TCP appears to be functionally compatible with all other major implementations. In particular, it is used on a daily basis to provide communications between users on the Ft. Bragg PRNET and ISID on the ARPANET. The IP implementation is reasonably complete, providing fragmentation and reassembly; routing to the first gateway; and a complete host-side GGP process. Currently the source quench message is ignored. No IP options are generated and all received options are ignored. A measurement collection mechanism is currently under development to collect TCP and IP statistics and deliver them to a measurement host for data reduction. UCLA IBM Date: 13 May 1981 From: Bob Braden Implementation Status -- IP/TCP for IBM 360/370 under OS/MVT. May 12, 1981 1. Hardware IBM 360 or 370, with a "Santa Barbara" interface to the IMP. 2. Operating System OS/MVS with ACF/VTAM. An OS/MVT version is also available. The UCLA NCP operates as a user job, with its own internal multiprogramming and resource management mechanisms. 3. Implementation Language BAL (IBM's macro assembly language) 4. Protocol features supported: A. IP PROTOCOL: (1) Fragmentation/reassembly: performs reassembly. Does not fragment, assuming that higher-level protocol (TCP) will create suitable size segments during packetizing. (2) Options: all internet options accepted but ignored. None are sent (in particular, no error options). (3) Identifier selection: uses globally-unique identifiers for transmitted segments, independent of destination. (4) Reassembly timeout: fixed value (30-60 seconds), independent of time-to-live field. Packets are discarded if time-to-live field is zero. (5) Gateway functions: Unable to select an alternate route (gateway) if the original route fails. Does accept GGP, and acts on Redirect, Destination Unreachable, and Echo packets. Source Quench is ignored. (6) Type of Service: default Type of Service set, may cause either Subtype 0 or Subtype 3 (Uncontrolled) packets to be sent. B. TCP PROTOCOL: (1) Precedence, security fields: not set or tested. (2) TCP Options: no options generated. All options received but only Buffer Size is acted upon. (3) Urgent: may be sent and received by user process. (4) EOL: may be sent by user process, but received EOL's are not passed to user process. (5) Buffer Size: will transmit according to specified buffer size. Uses circular buffer for received data, so never specifies a buffer size to remote TCP. (6) Retransmission: successive retransmissions use exponential backoff. Base time is 2 times observed weighted-average round-trip time. Round-trip time is measured by initial packet transmission to complete acknowledgment. Retransmits slowly into zero window. (7) Initial Sequence Number: derived from system clock. (8) Window strategy: uses conservative strategy, never adver- tising a receive window larger than the space available in the circular buffer. (9) ACK generation: always sends in response to receipt of a non-empty packet. As user process removes bytes from buffer, optimizing algorithm determines when to generate to inform sender of larger window. 5. Code Size (addition to existing NCP code) Resident Control Process: 4K bytes. Internet Protocol Layer: 10K bytes. (transient) TCP Protocol Layer: 10K bytes. (transient) 6. Fixed Table Space The limited fixed table space is included in the code (above). 7. Connections Supported: Only practical limitation is amount of memory available in NCP region for buffers and per-connection control blocks; requirements are: For each connection, the internet and TCP layers require control blocks totalling 256 bytes. (*) Receive: Segment reassembly buffer= max segment size - min internet header length + 16= 572 bytes per buffer. (*) Send: 128 bytes per unacknowledged segment. Note: the actual data being sent is not counted here, as it occupies buffer space belonging to the appropriate user-level protocol module. (*)Note: there is a pool of these objects, shared among all active connections. The pool grows and shrinks dynamically with the number of connections; it is probably reasonable to expect an average of one segment reassembly buffer and one unacknowledged segment (total of 700 bytes) per TCP connection. In addition to this TCP-specific memory, there is the memory to support the user-level protocol. For example, a server-Telnet session to TSO requires control blocks and buffers totalling about 1800 bytes; this is identical for TCP and for the ARPANET Host-Host ("NCP") protocol. 8. User-Level Protocols Available User and Server Telnet 9. Philosophical Remarks This implementation of the Internet and TCP protocols is designed to meet the following general objectives: (a) operate within the existing NCP system job, sharing code and control-block formats wherever possible; (b) be compatible at the system-call level with the existing user-level protocol modules; (c) implement the Internet protocol as a distinct layer, with interfaces designed to expedite the implementation of other higher-level internet protocols in addition to TCP; (d) require minimum NCP resources when internet protocol is not in use. ------------------------------ Date: 5 Oct 81 20:09:53-EDT (Mon) From: Michael Muuss To: Rob Gurwitz Rob - Thanks very much for the information about the 4.1 BSD TCP/IP implementation. Sounds like a very nice job! What is the feasibility of moving it to a PDP-11 UNIX system? There are some of us who can not afford to subscribe to the Berkeley "PDP-11s are dead" philosophy... Can you feed me any handy dribbles of documentation or overview information? Cheers, -Mike ------------------------------ Date: 3 Oct 1981 00:13:28-PDT From: ESVAX.clemc at Berkeley To: csvax.unix-wizards at Berkeley The 3Com version for the 11 is fairly good. It is like the old U of I NCP in that it is not all kernel resident (like the BBN Version). It IS large. Tektronix has been using it will 2.8 BSD for a few months but they have had lots of trouble. It has been a conbination of sparse comments in the 3Com code, 2.8 BSD and trying to Talk TCP to a CDC Cyber on the other end. They are using Network System's Corp "HYPERchannel" gear for the physical medium, which is very fast but the 11/70 can not keep up with it (niether can the cyber when running TCP). Both BBN and 3Com have used Psuedo TTY's for the Virtual Terminal Protocol. This has both advantages and disadvantages. 3Com wants to make their code portable to other UNIX versions. They are working on/have made to work a version that runs on an 11/34 with overlays. As far as I know, BBN has punted the 11's. Clem ------------------------------ Date: 6 Oct 1981 11:32:45 EDT (Tuesday) From: Rob Gurwitz To: Michael Muuss There is a note describing the internals of the TCP/IP for the VAX available from the ARPANET NIC as IEN 168. In addition, I have manual pages for the lowest level TCP/IP/local net i/f, if you want them. The TELNET and FTP are ports of software that has been around for awhile, so manual pages for them are probably generally available (you probably already have them if you're running NCP on an 11). MTP mail is new, but we have no manual pages ready yet. Rob. ------------------------------ Date: 7 Oct 1981 9:21:34 EDT (Wednesday) From: Rob Gurwitz To: Michael Muuss Here is the manual page for low level TCP access. I hope it's useful. Feel free to include info about the implementation in your summary. Rob. NET(5) UNIX Programmer's Manual NET(5) NAME tcp, ip, rawnet - internet networking software SYNOPSIS open ("/dev/net/net", ncon); struct con *ncon; struct lhost { /* net library format internet address */ unsigned char l_hoi; /* host on imp */ unsigned char l_net; /* network */ n_short l_imp; /* imp */ }; /* c_mode field definitions */ struct con { /* user connection structure */ unsigned char c_mode; /* mode 0-passive 1-active (see flags) */ unsigned char c_sbufs; /* # send buffers to use */ unsigned char c_rbufs; /* # rcv buffers to use */ unsigned char c_prec; /* precedence */ #define c_lo c_prec /* low raw link or proto # */ unsigned char c_sec; /* security level */ #define c_hi c_sec /* hi raw link or proto # */ unsigned char c_compt; /* compartment */ unsigned char c_timeo; /* tcp open timeout */ unsigned char c_x; /* (unused) */ unsigned short c_lport; /* local port */ unsigned short c_fport; /* foreign port */ struct lhost c_con; /* foreign socket */ }; struct netstate { /* network status structure */ unsigned char n_lolink; /* low link no. in range (IP, RAW) */ unsigned char n_hilink; /* high link no. in range (IP, RAW) */ unsigned char n_snd; /* # send bufs allocated */ unsigned char n_rcv; /* # receive bufs allocated */ unsigned char n_ssize; /* # bufs on send buffer */ unsigned char n_rsize; /* # bufs on receive buffer */ unsigned char n_state; /* state of this connection */ unsigned char n_flags; /* misc. flags (see below) */ unsigned short n_lport; /* local port */ unsigned short n_fport; /* foreign port */ struct lhost n_con; /* foreign socket */ }; #define CONACT 1 /* active connection */ #define CONTCP 2 /* open a tcp connection */ #define CONIP 4 /* open a raw ip connection */ #define CONRAW 8 /* open a raw local net connection */ #define CONDEBUG 128 /* turn on debugging info */ /* net ioctl definitions */ #define NETGETS 1 /* get status */ #define NETSETD 2 /* set debugging info */ #define NETSETU 3 /* set urgent mode */ #define NETRSETU 4 /* reset urgent mode */ #define NETSETE 5 /* set EOL mode */ #define NETRSETE 6 /* reset EOL mode */ #define NETCLOSE 7 /* initiate tcp close */ #define NETABORT 8 /* initiate tcp abort */ #define SIGURG 16 /* urgent signal */ #ifndef KERNEL /* n_flags field definitions */ #define UEOL 0001 /* EOL sent */ #define UURG 0002 /* urgent data sent */ #define UDEBUG 0004 /* turn on debugging info recording */ #define ULOCK 0010 /* receive buffer locked */ #define UTCP 0020 /* this is a TCP connection */ #define UIP 0040 /* this is a raw IP connection */ #define URAW 0100 /* this is a raw 1822 connection */ #define ULISTEN 0200 /* awaiting a connection */ /* n_state field definitions */ #define UCLOSED 0000 /* connection closed */ #define UCLSERR 0001 /* error -- connection closing */ #define UABORT 0002 /* connection aborted */ #define UINTIMO 0004 /* open failed -- init timeout */ #define URXTIMO 0010 /* retransmit too long timeout */ #define URESET 0020 /* connection aborted due to reset */ #define UOPERR 0040 /* open failed -- not enough buffers */ #define UURGENT 0100 /* urgent data received */ #define UNETDWN 0200 /* connection aborted due to net */ #endif KERNEL DESCRIPTION The special file /dev/net/net is used to access ARPANET type packet-switched networks via the DoD standard host-host Internetworking Protocols, TCP (Transmission Control Protocol), and IP (Internet Protocol). It also allows communication over the local network(s) to which the system is connected with "raw" packets, enabling user software to do its own communications processing. Access to the network at this level is the most direct form of use. It is assumed that most users will use higher level protocol programs, like ftp(1) and telnet(1) to communicate over the network. (This description assumes the reader is familiar with ARPANET type communications protocols.) ESTABLISHING CONNECTIONS To establish a connection via TCP or IP, or to communicate with raw packets, the open(2) call is given, with the usual mode argument replaced by a pointer to a connection structure, defined in /usr/include/con.h. The c_mode field of this structure specifies what type of connection is desired (TCP, IP, or RAW), and whether or not the connection is to be active (specifying a specific foreign host address), or passive (with no foreign address, implying that the connection will be established when any foreign process tries to communicate with the opener). The c_sbufs and c_rbufs fields specify buffer allocations for the send and receive sides of the connection, respectively. If either value is zero, the default allocation will be used for that direction (currently 1K bytes). The user can request up to 4K bytes each for send and receive directions by varying these parameters between 1 and 4. The c_prec, c_sec, and c_compt fields specify values of precedence, security level, and compartmentalization for TCP connections. (N.B. This feature is currently not implemented). For IP and RAW connections, the c_hi and c_lo fields specify a range of IP protocol numbers or local net dispatch numbers (e.g., ARPANET link numbers) to watch for. Messages falling into this range are queued for the user. The low end of the range is used in sending messages. Low must be less than or equal to high, and numbers in the range must not be in use in any other connection. The c_timeo parameter specifies a length of time in seconds to wait for connection establishment before aborting (this does not apply to passive opens). If the field is zero, the default of 30 seconds is used. The remaining fields specify local, and foreign ports for TCP, and the foreign host address in net long format (see libn(3)). The local port may be zero, in which case TCP assigns a unique port number to the connection. The foreign port and host address may only be zero for a passive open. READING AND WRITING If the open succeeds, a file descriptor is returned which may be used in subsequent reads and writes (see, read(2), write(2)). Reads and writes work as usual with a few exceptions. A read may return with error condition ENETSTAT, which indicates that some exceptional condition has been detected. In this case, a 16 bit value is returned to the read buffer, which give the status of the connection that caused the return. Further status may be determined with ioctl(2). (see, NETWORK STATUS). If the condition is non-fatal, the read may be re-issued. Reads may return less data than requested if a TCP EOL was detected. Reads will block if there is no data for the user. Writes block if the amount of send buffer resources for the connection is exceeded. IP and RAW reads return the appropriate protocol leaders along with any data received. Only one IP or RAW message may be received or sent per call. In addition to normal TCP reads and writes, the user may wish to indicate EOL and URGENT data on writes and receive notification of URGENT data sent by the foreign peer. EOL and URGENT are enabled by issueing the NETSETE or NETSETU ioctl calls. Once set, EOL is sent at the last byte of each subsequent write. Similarly, the URGENT pointer is set to start at the first byte of the next write, and ends with the first byte sent after URGENT mode is disabled. These modes are disabled by the NETRSETE and NETRSETU ioctl calls. URGENT data is indicated by signal SIGURG when the first byte is received. This signal is normally ignored. (A status flag is also set in the presence of urgent data.) CLOSING CONNECTIONS Normally, the close(2) call is used to close a TCP, IP, or RAW connection. In each case, it indicates that the user will send or receive no more data. For TCP connections, close initiates the connection closing protocol, though it returns immediately. Thus, the internal connection structures persist until the connection has reached the CLOSED state. For IP and RAW connections, the close is immediate and deletes all internal structures. In addition to close for TCP connections, there is an ioctl call, NETCLOSE, which indicates that the local connection will send no more data, but is still able to receive data from the foreign peer. In this case, subsequent writes are illegal and will terminate with errors, but subsequent reads will work until the connection is closed by the foreign peer. NETWORK STATUS There are several ioctl(2) calls available for receiving network status information or initiating certain modes or functions. Most of these calls have been described above. The status call, NETGETS, takes a status buffer pointer, which points to a netstate structure, illustrated above, which is filled in by the call. To summarize, the various ioctl calls are: NETGETS Return network status information to the structure pointed at by third argument of ioctl. NETSETD Reset the debugging log to the file name pointed at by the third argument. The file must already exist. If the argument is zero, turn off debug logging (see, DEBUGGING). NETSETU Set urgent mode starting at next byte written (TCP only). NETRSETU Reset urgent mode, urgent pointer ends at last byte written (TCP only). NETSETE Set EOL mode, send EOL at last byte of each subsequent write (TCP only). NETRSETE Terminate EOL mode (TCP only). NETCLOSE Start TCP connection close. User can continue to receive data (TCP only). NETABORT Abort TCP connection. Foreign peer is reset and no more data may be sent or received (TCP only). DEBUGGING The network software enables certain trace information to be recorded for TCP connections. This information is logged in a single debugging log file. To enable this feature, the CONDEBUG bit in the c_mode field of the open connection parameter structure must be set. The default debugging log is /etc/net/tcpdebug. This may be changed or the feature may be disabled system wide with the NETSETD ioctl call. Only the super-user may do this. The format of the debugging information is several bytes of binary data per TCP transaction. The log may be printed in readable form with trpt(1). DIAGNOSTICS The following system error codes may be returned by network system calls: ENETSTAT (35) Network status available (not a fatal error, see READS AND WRITES). ENETDWN (36) Open failed because network connection is unavailable. ENETCON (37) Open failed because there were too many connections. ENETBUF (38) No more network buffer space. ENETERR (39) Fatal error from network protocol processor. ENETRNG (40) IP or RAW open failed because the protocol or dispatch number was out of range or already in use. TCP open failed because the user tried to open an already existing connection (i.e., one with the identical foreign host address and local and foreign ports). FILES /dev/net/net /etc/net/tcpdebug SEE ALSO ftp(1), telnet(1), trpt(1), read(2), write(2), open(2), close(2), ioctl(2), libn(3) R.F. Gurwitz, VAX-UNIX Networking Support Project Implementation Description, DARPA Information Processing Techniques Office, IEN 168, January, 1981. J. Postel (ed.), DoD Standard Internet Protocol, DARPA Information Processing Techniques Office, IEN 128, January, 1980. J. Postel (ed.), DoD Standard Transmission Control Protocol, DARPA Information Processing Techniques Office, IEN 129, January, 1980. ------------------------------ End of TCP-IP Digest ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1981101916521300> Mail-from: ARPANET host BRL rcvd at 19-Oct-81 2325-PDT Date: 19 Oct 81 20:52:13-EDT (Mon) From: Mike Muuss Reply-to: tcp-ip at Brl Subject: TCP-IP Digest, Vol 1 #3 TCP/IP Digest Monday, 19 Oct 1981 Volume 1 : Issue 3 Today's Topics: Acronyms -- Protocol Documents TCP Transition Notes -- Simple Mail Transfer Protocol Problems with TOPS-20 TCP Implementation? Throughput Considerations of TCP TCP/IP: Suitable for MicroPs? ---------------------------------------------------------------------- From: Zellich at OFFICE-3 (Rich Zellich) Subject: Acronyms Apparently there are enough non-net-hackers on the list that I should explain the acronyms I used in my message in V1#2. TCP - Transmission Control Protocol (see RFC's 791, 792, & 793 for details on TCP and IP) IP - Internet [control] Protocol RFC - Request For Comment; Technical notes requesting comment from the ARPANET public (also the only place to find those protocols which have been adopted as DCA standards or ad hoc standards). The RFC's are numbered and are available from the directory on the SRI-NIC host. Suggested course of action is to first FTP RFC-INDEX.TXT to see what is available. IEN - Internet Experiment Note; Similar to RFC's, and available from the same place via FTP, but applicable specifically to the DCA/DARPA sponsored Internet Experiment work (where TCP & IP originally came from). Suggested course of action is to first FTP IEN-INDEX.TXT to see what is available. FTP - File Transfer Protocol; a network protocol/service whereby users can transfer files between/among hosts. If you're not up on the use of FTP, see your friendly local ARPANET Liaison. NIC - Network Information Center; The friendly people who maintain the online information databases such as RFC's, IEN's, lists of ARPANET Hosts, Liaisons, and Users, etc. In addition to supporting the net "standard" ANONYMOUS login with password GUEST to obtain the files kept in , they also have a nifty online query system available to anyone who can connect to SRI-NIC via TIP or TELNET. To use it, first connect to the SRI-NIC host, then login as NIC (no password is necessary) and follow the instructions. The NIC/Query system can locate users, hosts, liaisons, and provides much other ARPANET information. [To find out how to use a TIP or the host TELNET service, see your friendly local ARPANET Liaison.] DARPA - Defense Advanced Research Projects Agency; the friendly folks who originally brought you the ARPANET (for whom it is named) and who are now funding internet research using the ARPANET as part of their laboratory. DCA - Defense Communications Agency; The not-quite-as friendly folks who run the ARPANET for the Dept. of Defense (actually, also very friendly, but they have the Gov't Accounting Office (GAO) and every other busybody in the country breathing down their necks about what all that money is being spent for, so they're inclined to be a bit serious about the uses we make of the net). Cheers, Rich ------------------------------ From: POSTEL at USC-ISIF Subject: Protocol Documents To: TCP-IP-Digest at BRL In recent years the ARPA Network Research Program has had as one concern the interconnection of networks. In the course of this research a family of protocols suitable for an internetwork environment has emerged. The major internet protocol documents have been issued as RFCs. The situation has evolved to the point that it is appropriate for the internet family of protocols to replace the old ARPANET protocols. To this end an Internet Protocol Handbook will be prepared by the Network Information Center. This Internet Protocol Handbook will closely parallel the old ARPANET Protocol Handbook, and will primarily be a collection of existing RFCs. Until this new Protocol Handbook is available, people interested in the internet protocols, especially implementers, may desire to make their own temporary notebooks of the relevant protocol documents. To aid this, the following is suggested as a table of contents for such a collection. Any suggestions for additions should be sent to Jon Postel (Postel@ISIF). RFCs are public access document files and may be copied from the Network Information Center online Library at SRI-NIC via FTP using the FTP user name ANONYMOUS and password GUEST. The RFCs have pathnames of the form "RFCnnn.TXT", where "nnn" is replaced by the document number. Table of Contents Network Level Internet Protocol (IP) RFC 791 Internet Control Message Protocol (ICMP) RFC 792 Host Level User Datagram Protocol (UDP) RFC 768 Transmission Control Protocol (TCP) RFC 793 Application Level Trivial File Transfer Protocol (TFTP) RFC 783 Telnet Protocol (TELNET) RFC 764 File Transfer Protocol (FTP) RFC 765 Simple Mail Transfer Protocol (SMTP) RFC xxx Appendices Assigned Numbers RFC 790 Service Mappings RFC 795 Address Mappings RFC 796 Document File Format Standards RFC 678 Mail Header Format Standards RFC 733 Note: The RFC on the simple mail protocol will be issued soon. ------------------------------ From: DUCKETT at USC-ISIE Subject: TCP-IP Digest Dear Mike: I found your first two Digest issues of considerable interest. If you have questions concerning policy on the TCP transition, I suggest you ask me or Capt. Glynn Parker (DCACode252@ISIA) who manages the ARPANET for DCA. Jon Postel is responsible for the transition planning and is working on documentation to aid users in preparation for the mixed NCP/TCP mode of operation which we can expect during calendar 1982. Already we have a community of TCP-only users who are at Ft. Bragg, North Carolina entering the ARPANET via a gateway to the Ft. Bragg packet radio network. There are likewise a number of European researchers in the UK, Norway, and soon Germany who will likewise access the ARPANET using TCP/IP through SATNET/ARPANET gateways. Jon Postel will be spelling this out in more detail, but one crucial step towards the transition is the implementation of a Simple Mail Transfer Protocol (SMTP) which can run above either TCP or NCP. This mail transport mechanism achieves the same function as the MAIL or MLFL commands of FTP, but with greater efficiency and, most important, handles clearly the problem of forwarding mail from NCP to TCP environments and back. To allow mail to go thru during the NCP/TCP transition, everyone must have a functioning SMTP running on either NCP or TCP. Without this, it won't be possible to handle mail forwarding transparently. There is a kludge available to handle the recalcitrant FTP mailer, but is is very inconvenient for users. Jon Postel will be documenting all this in more detail. Dave Clark at MIT (DClark@MIT-Multics) is the internet systems Architect and is responsible for long-range planning. A number of capabilities are still sought for the internet system including handling packetized voice and dealing with partitioning of networks. Dave will probably want to share some of his thoughts in your digest as well. I'd like to comment on TCP performance on local nets. Mitre has done some work in this area, achieving on the order of 200-350 kb/s for full TCP/IP operation. The protocol is not in and of itself inefficient on a local net. In fact, the short delay on the net is generally helpful. Suggest you discuss this with Steve Holmgren at MITRE Corporation (Steve@MITRE). Steve has also done work on front ends for UNIX. This may be relevant to your specific interests as well. Digital Technology Inc. (DTI) has also done work on front ends--Gary Grossman (grg@DTI) can answer questions. The most noticeable performance factors seem to be software checksumming (takes CPU cycles) and careful window flow control/retransmission timeouts. Dave Clark has worked on the latter in some depth. Small, efficient TCP's can be and have been built. A big challenge is dealing with the wide range of delays and bandwidths presented by the internet environment. I believe TCP/IP to be the most thoroughly tested and widely implemented multinetwork protocol ever built. It is a crucial component of future DoD command and control systems. People participating in this transition of the ARPANET into the internet environment are participating in an event as exciting as the construction of the ARPANET and I am very proud to be a part of it. Cordially, Vint Cerf (bd) ------------------------------ From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: TOPS-20 TCP Implementation It has been mentioned on several occasions that there is a TOPS-20 (and Tenex) TCP implementation from BBN; and some people have treated it as a foregone conclusion that TCP work on TOPS-20 is "done". I would like to comment on this, and state why I believe the 1983 deadline for NCP to TCP conversion will not be met. I have worked with BBN's TCP at the user program level; specifically I have implemented user TELNET for TCP as part of a general multiple-network TELNET for TOPS-20. Briefly, the TOPS-20 TCP implementation in its present form is unacceptable to Stanford and many other TOPS-20 sites. It is sad that so many bright people at BBN have had to maintain this dog instead of working on a complete rewrite. There are several reasons as to why we feel the present BBN implementation of TCP is unacceptable: (1) Performance problems. Reports have varied, but the general concensus seems to be that the TCP process consumes between 40% to 60% of the CPU. We simply cannot sacrifice that much of an already-loaded CPU to implement a network; in fact, we find that NCP's overhead on our system is at times excessive. Last spring Dan Lynch mentioned that he was going to try to get some more specific performance figures of TCP at ISI; I don't know whether he has or not. (2) User code implementation details. TOPS-20 TCP's interface to user processes is completely non-standard from the way any other network (or device) works on TOPS-20. In TELNET, there are two major paths for network I/O; one is for TCP, the other is for every other network (9 at last count). This wouldn't be so objectionable if the TCP path were simpler; it isn't. TOPS-20 TCP's system calls not only do not use the filesystem and associated buffer management, they also require the user program to implement its own buffer management. The actual details of how to write an efficient user mode data stream driver for TOPS-20 TCP are complex; the obvious straightforward algorithm is incredibly slow. The cause of this is well-known; TCP on TOPS-20 was originally implemented as a user-mode process written in BCPL which did user-mode system call trapping; due to the complexities of simulating the filesystem under these conditions impromptu pseudo-system calls were written for the user process to use. This was fine as a temporary testbed, but the user process interface should have been redesigned. Instead, TCP's implementation in the TOPS-20 kernel was essentially converting the BCPL code to assembly code and inserting it in the kernel. At a gathering of ARPANET users last spring at the DECUS symposium, DEC indicated its plans to redesign the TCP user interface. That solves that objection, but it wasn't at all clear (on DEC's part -- it was quite clear on the users' part) that they were going to improve TCP's internal performance. My understanding is that this project still is not completed. I do not see how an acceptable implementation of TCP for TOPS-20 could possibly be ready in time for the 1983 deadline. I also do not see how ARPA/DCA/whomever intends to enforce the non-use of NCP. The NCP/TCP conversion is of far greater complexity than conversion from 32-bit to 96-bit leaders; the latter was done by myself on WAITS (SU-AI's operating system) and Dave Moon on ITS (MIT's operating system) in a matter of a few days in 1978. Also, the 32-bit/96-bit conversion was to some extent a change in the "hardware" implementation and required next to no change in the actual protocol code. It will be technically difficult to enforce the non-use of NCP unless the IMPs are somehow modified to intercept and disallow NCP messages; NCP is at a higher level than the IMPs think. The worst that I envision could happen if a host does not go to TCP is that a user on a TIP won't be able to contact that host; with the present problems with high-school kids on TIPs some of us would consider that a benefit! I hope that due consideration is being given to this problem. There are a lot of PDP-10's on the ARPANET right now, and they aren't about to vanish in a corner. To my knowledge, there is no project at all to implement TCP on WAITS, ITS, or TOPS-10; and the Tenex/TOPS-20 implementation has significant problems for a site which wants to implement it. Some people feel that a "network front end" is the right long-term solution for this problem; but we can't just go and build a network front end in 14 months. -- Mark -- ------------------------------ From: nowicki@Diablo at Sumex-Aim Subject: Throughput There was a brief mention of throughput in the last TCP digest. For what it's worth, we are getting about 120Kbits/second through our PUP FTP running between Vaxes on 3Mbit Ethernet. This is bits in the file divided by wall clock time in seconds, so it is not very precise (but accurate for large files). All the protocols are done in user programs, nothing in the kernel, with a window size of one (ACK per packet). With fancy buffer management in the kernel and larger windows, TCP should give much better performance. We'll see. -- Bill ------------------------------ From: Robert Elton Maas Subject: TCP/IP Digest, V1 #1 I've reviewed much of Internet Protocol and found it to be very lacking. I have consequently rejected it for use in making networks of personal computers/workstations for the general public to all link up with. I have sent numerous gripes to Jon Postel and other authors of parts of the IP but they just beg the questions. One document in that group is however interesting/useful, the RFC about connectionless data transfer. I'd like to see more work in that direction. ------------------------------ From: Robert Elton Maas Subject: Internet Protocol Losses? My major complaint is with mailbox addressing. The assumption of IP is that every node is on some official network, that such nodes are known in exhaustion to that network bureaucracy so that in particular node-id numbers can be assigned to each node. Nodes join the Internet not individually but by being officially registered with a network that has joined. I don't want that kind of personal-computer network. I want nodes to be able to join a network just by getting software and starting to send messages to well-known nodes and getting replies from them and from nodes they are referred to (introduced to). A node shouldn't have to apply for membership, and a network shouldn't have to maintain a list of all legal members, and every node on a network shouln't have to have a table that gives for each node-id number the next-hop for forwarding to that node (I envision several million nodes on one network, most nodes being merely 32k or 48k microcomputers with small floppy disks, no way such a small machine can list all other nodes). PCNET uses latitude and longitude, with phone number, for identifying a node. Any node can look on a USGS or aircraft map to get its coordinates. Forwarding a message can be done directly by the phone number or indirectly by the latitude and longitude. IP doesn't have enough bits in the allowed node-address to support this method. (PCNET needs at the very least: Longitude, 360 degrees * 60 minutes/degree = 21600 (appx 2^15) Latitude, +/- 90 degrees (180 deg) * 60 m/d =10800 (appx 2^14) Phone number, XxX-XXX-XXXX = 2*10^9 = (appx 2^31) Total 60 bits. There's redundancy in lat/long vs. telephone area code, but to take advantage of that requires a gigantic table of locations of telephone area codes and prefixes. I think IP allows only 32 bits for node-number-on-network, right?) Another gripe is the extreme amount of overhead in each packet. If you're doing packet switching thru internets, maybe that overhead is needed. But it's totally inappropriate for two nodes talking directly to each other thru modems. PCNET gets by with 6 bytes of packet overhead instead of IP's 64 (2 bytes of CRC, 1 byte of sequence numbering mod 8, and 1 byte of process-number and flags for directing the packet to up to 127 user channels, and 2 guard-bytes between packets to reframe the UART and signal the break between packets) which supports very rapid interactive turnaround even on slow modems. END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [anews.Aucbvax.4552] <1981101917254200> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Mon Oct 19 22:25:42 1981 Subject: TCP-IP Digest, Vol 1 #3 X-Google-Info: Converted from the original A-News header >From tcp-ip@brl Mon Oct 19 21:38:29 1981 TCP/IP Digest Monday, 19 Oct 1981 Volume 1 : Issue 3 Today's Topics: Acronyms -- Protocol Documents TCP Transition Notes -- Simple Mail Transfer Protocol Problems with TOPS-20 TCP Implementation? Throughput Considerations of TCP TCP/IP: Suitable for MicroPs? ---------------------------------------------------------------------- From: Zellich at OFFICE-3 (Rich Zellich) Subject: Acronyms Apparently there are enough non-net-hackers on the list that I should explain the acronyms I used in my message in V1#2. TCP - Transmission Control Protocol (see RFC's 791, 792, & 793 for details on TCP and IP) IP - Internet [control] Protocol RFC - Request For Comment; Technical notes requesting comment from the ARPANET public (also the only place to find those protocols which have been adopted as DCA standards or ad hoc standards). The RFC's are numbered and are available from the directory on the SRI-NIC host. Suggested course of action is to first FTP RFC-INDEX.TXT to see what is available. IEN - Internet Experiment Note; Similar to RFC's, and available from the same place via FTP, but applicable specifically to the DCA/DARPA sponsored Internet Experiment work (where TCP & IP originally came from). Suggested course of action is to first FTP IEN-INDEX.TXT to see what is available. FTP - File Transfer Protocol; a network protocol/service whereby users can transfer files between/among hosts. If you're not up on the use of FTP, see your friendly local ARPANET Liaison. NIC - Network Information Center; The friendly people who maintain the online information databases such as RFC's, IEN's, lists of ARPANET Hosts, Liaisons, and Users, etc. In addition to supporting the net "standard" ANONYMOUS login with password GUEST to obtain the files kept in , they also have a nifty online query system available to anyone who can connect to SRI-NIC via TIP or TELNET. To use it, first connect to the SRI-NIC host, then login as NIC (no password is necessary) and follow the instructions. The NIC/Query system can locate users, hosts, liaisons, and provides much other ARPANET information. [To find out how to use a TIP or the host TELNET service, see your friendly local ARPANET Liaison.] DARPA - Defense Advanced Research Projects Agency; the friendly folks who originally brought you the ARPANET (for whom it is named) and who are now funding internet research using the ARPANET as part of their laboratory. DCA - Defense Communications Agency; The not-quite-as friendly folks who run the ARPANET for the Dept. of Defense (actually, also very friendly, but they have the Gov't Accounting Office (GAO) and every other busybody in the country breathing down their necks about what all that money is being spent for, so they're inclined to be a bit serious about the uses we make of the net). Cheers, Rich ------------------------------ From: POSTEL at USC-ISIF Subject: Protocol Documents To: TCP-IP-Digest at BRL In recent years the ARPA Network Research Program has had as one concern the interconnection of networks. In the course of this research a family of protocols suitable for an internetwork environment has emerged. The major internet protocol documents have been issued as RFCs. The situation has evolved to the point that it is appropriate for the internet family of protocols to replace the old ARPANET protocols. To this end an Internet Protocol Handbook will be prepared by the Network Information Center. This Internet Protocol Handbook will closely parallel the old ARPANET Protocol Handbook, and will primarily be a collection of existing RFCs. Until this new Protocol Handbook is available, people interested in the internet protocols, especially implementers, may desire to make their own temporary notebooks of the relevant protocol documents. To aid this, the following is suggested as a table of contents for such a collection. Any suggestions for additions should be sent to Jon Postel (Postel@ISIF). RFCs are public access document files and may be copied from the Network Information Center online Library at SRI-NIC via FTP using the FTP user name ANONYMOUS and password GUEST. The RFCs have pathnames of the form "RFCnnn.TXT", where "nnn" is replaced by the document number. Table of Contents Network Level Internet Protocol (IP) RFC 791 Internet Control Message Protocol (ICMP) RFC 792 Host Level User Datagram Protocol (UDP) RFC 768 Transmission Control Protocol (TCP) RFC 793 Application Level Trivial File Transfer Protocol (TFTP) RFC 783 Telnet Protocol (TELNET) RFC 764 File Transfer Protocol (FTP) RFC 765 Simple Mail Transfer Protocol (SMTP) RFC xxx Appendices Assigned Numbers RFC 790 Service Mappings RFC 795 Address Mappings RFC 796 Document File Format Standards RFC 678 Mail Header Format Standards RFC 733 Note: The RFC on the simple mail protocol will be issued soon. ------------------------------ From: DUCKETT at USC-ISIE Subject: TCP-IP Digest Dear Mike: I found your first two Digest issues of considerable interest. If you have questions concerning policy on the TCP transition, I suggest you ask me or Capt. Glynn Parker (DCACode252@ISIA) who manages the ARPANET for DCA. Jon Postel is responsible for the transition planning and is working on documentation to aid users in preparation for the mixed NCP/TCP mode of operation which we can expect during calendar 1982. Already we have a community of TCP-only users who are at Ft. Bragg, North Carolina entering the ARPANET via a gateway to the Ft. Bragg packet radio network. There are likewise a number of European researchers in the UK, Norway, and soon Germany who will likewise access the ARPANET using TCP/IP through SATNET/ARPANET gateways. Jon Postel will be spelling this out in more detail, but one crucial step towards the transition is the implementation of a Simple Mail Transfer Protocol (SMTP) which can run above either TCP or NCP. This mail transport mechanism achieves the same function as the MAIL or MLFL commands of FTP, but with greater efficiency and, most important, handles clearly the problem of forwarding mail from NCP to TCP environments and back. To allow mail to go thru during the NCP/TCP transition, everyone must have a functioning SMTP running on either NCP or TCP. Without this, it won't be possible to handle mail forwarding transparently. There is a kludge available to handle the recalcitrant FTP mailer, but is is very inconvenient for users. Jon Postel will be documenting all this in more detail. Dave Clark at MIT (DClark@MIT-Multics) is the internet systems Architect and is responsible for long-range planning. A number of capabilities are still sought for the internet system including handling packetized voice and dealing with partitioning of networks. Dave will probably want to share some of his thoughts in your digest as well. I'd like to comment on TCP performance on local nets. Mitre has done some work in this area, achieving on the order of 200-350 kb/s for full TCP/IP operation. The protocol is not in and of itself inefficient on a local net. In fact, the short delay on the net is generally helpful. Suggest you discuss this with Steve Holmgren at MITRE Corporation (Steve@MITRE). Steve has also done work on front ends for UNIX. This may be relevant to your specific interests as well. Digital Technology Inc. (DTI) has also done work on front ends--Gary Grossman (grg@DTI) can answer questions. The most noticeable performance factors seem to be software checksumming (takes CPU cycles) and careful window flow control/retransmission timeouts. Dave Clark has worked on the latter in some depth. Small, efficient TCP's can be and have been built. A big challenge is dealing with the wide range of delays and bandwidths presented by the internet environment. I believe TCP/IP to be the most thoroughly tested and widely implemented multinetwork protocol ever built. It is a crucial component of future DoD command and control systems. People participating in this transition of the ARPANET into the internet environment are participating in an event as exciting as the construction of the ARPANET and I am very proud to be a part of it. Cordially, Vint Cerf (bd) ------------------------------ From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: TOPS-20 TCP Implementation It has been mentioned on several occasions that there is a TOPS-20 (and Tenex) TCP implementation from BBN; and some people have treated it as a foregone conclusion that TCP work on TOPS-20 is "done". I would like to comment on this, and state why I believe the 1983 deadline for NCP to TCP conversion will not be met. I have worked with BBN's TCP at the user program level; specifically I have implemented user TELNET for TCP as part of a general multiple-network TELNET for TOPS-20. Briefly, the TOPS-20 TCP implementation in its present form is unacceptable to Stanford and many other TOPS-20 sites. It is sad that so many bright people at BBN have had to maintain this dog instead of working on a complete rewrite. There are several reasons as to why we feel the present BBN implementation of TCP is unacceptable: (1) Performance problems. Reports have varied, but the general concensus seems to be that the TCP process consumes between 40% to 60% of the CPU. We simply cannot sacrifice that much of an already-loaded CPU to implement a network; in fact, we find that NCP's overhead on our system is at times excessive. Last spring Dan Lynch mentioned that he was going to try to get some more specific performance figures of TCP at ISI; I don't know whether he has or not. (2) User code implementation details. TOPS-20 TCP's interface to user processes is completely non-standard from the way any other network (or device) works on TOPS-20. In TELNET, there are two major paths for network I/O; one is for TCP, the other is for every other network (9 at last count). This wouldn't be so objectionable if the TCP path were simpler; it isn't. TOPS-20 TCP's system calls not only do not use the filesystem and associated buffer management, they also require the user program to implement its own buffer management. The actual details of how to write an efficient user mode data stream driver for TOPS-20 TCP are complex; the obvious straightforward algorithm is incredibly slow. The cause of this is well-known; TCP on TOPS-20 was originally implemented as a user-mode process written in BCPL which did user-mode system call trapping; due to the complexities of simulating the filesystem under these conditions impromptu pseudo-system calls were written for the user process to use. This was fine as a temporary testbed, but the user process interface should have been redesigned. Instead, TCP's implementation in the TOPS-20 kernel was essentially converting the BCPL code to assembly code and inserting it in the kernel. At a gathering of ARPANET users last spring at the DECUS symposium, DEC indicated its plans to redesign the TCP user interface. That solves that objection, but it wasn't at all clear (on DEC's part -- it was quite clear on the users' part) that they were going to improve TCP's internal performance. My understanding is that this project still is not completed. I do not see how an acceptable implementation of TCP for TOPS-20 could possibly be ready in time for the 1983 deadline. I also do not see how ARPA/DCA/whomever intends to enforce the non-use of NCP. The NCP/TCP conversion is of far greater complexity than conversion from 32-bit to 96-bit leaders; the latter was done by myself on WAITS (SU-AI's operating system) and Dave Moon on ITS (MIT's operating system) in a matter of a few days in 1978. Also, the 32-bit/96-bit conversion was to some extent a change in the "hardware" implementation and required next to no change in the actual protocol code. It will be technically difficult to enforce the non-use of NCP unless the IMPs are somehow modified to intercept and disallow NCP messages; NCP is at a higher level than the IMPs think. The worst that I envision could happen if a host does not go to TCP is that a user on a TIP won't be able to contact that host; with the present problems with high-school kids on TIPs some of us would consider that a benefit! I hope that due consideration is being given to this problem. There are a lot of PDP-10's on the ARPANET right now, and they aren't about to vanish in a corner. To my knowledge, there is no project at all to implement TCP on WAITS, ITS, or TOPS-10; and the Tenex/TOPS-20 implementation has significant problems for a site which wants to implement it. Some people feel that a "network front end" is the right long-term solution for this problem; but we can't just go and build a network front end in 14 months. -- Mark -- ------------------------------ From: nowicki@Diablo at Sumex-Aim Subject: Throughput There was a brief mention of throughput in the last TCP digest. For what it's worth, we are getting about 120Kbits/second through our PUP FTP running between Vaxes on 3Mbit Ethernet. This is bits in the file divided by wall clock time in seconds, so it is not very precise (but accurate for large files). All the protocols are done in user programs, nothing in the kernel, with a window size of one (ACK per packet). With fancy buffer management in the kernel and larger windows, TCP should give much better performance. We'll see. -- Bill ------------------------------ From: Robert Elton Maas Subject: TCP/IP Digest, V1 #1 I've reviewed much of Internet Protocol and found it to be very lacking. I have consequently rejected it for use in making networks of personal computers/workstations for the general public to all link up with. I have sent numerous gripes to Jon Postel and other authors of parts of the IP but they just beg the questions. One document in that group is however interesting/useful, the RFC about connectionless data transfer. I'd like to see more work in that direction. ------------------------------ From: Robert Elton Maas Subject: Internet Protocol Losses? My major complaint is with mailbox addressing. The assumption of IP is that every node is on some official network, that such nodes are known in exhaustion to that network bureaucracy so that in particular node-id numbers can be assigned to each node. Nodes join the Internet not individually but by being officially registered with a network that has joined. I don't want that kind of personal-computer network. I want nodes to be able to join a network just by getting software and starting to send messages to well-known nodes and getting replies from them and from nodes they are referred to (introduced to). A node shouldn't have to apply for membership, and a network shouldn't have to maintain a list of all legal members, and every node on a network shouln't have to have a table that gives for each node-id number the next-hop for forwarding to that node (I envision several million nodes on one network, most nodes being merely 32k or 48k microcomputers with small floppy disks, no way such a small machine can list all other nodes). PCNET uses latitude and longitude, with phone number, for identifying a node. Any node can look on a USGS or aircraft map to get its coordinates. Forwarding a message can be done directly by the phone number or indirectly by the latitude and longitude. IP doesn't have enough bits in the allowed node-address to support this method. (PCNET needs at the very least: Longitude, 360 degrees * 60 minutes/degree = 21600 (appx 2^15) Latitude, +/- 90 degrees (180 deg) * 60 m/d =10800 (appx 2^14) Phone number, XxX-XXX-XXXX = 2*10^9 = (appx 2^31) Total 60 bits. There's redundancy in lat/long vs. telephone area code, but to take advantage of that requires a gigantic table of locations of telephone area codes and prefixes. I think IP allows only 32 bits for node-number-on-network, right?) Another gripe is the extreme amount of overhead in each packet. If you're doing packet switching thru internets, maybe that overhead is needed. But it's totally inappropriate for two nodes talking directly to each other thru modems. PCNET gets by with 6 bytes of packet overhead instead of IP's 64 (2 bytes of CRC, 1 byte of sequence numbering mod 8, and 1 byte of process-number and flags for directing the packet to up to 127 user channels, and 2 guard-bytes between packets to reframe the UART and signal the break between packets) which supports very rapid interactive turnaround even on slow modems. END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1981102519224800> Mail-from: ARPANET host BRL rcvd at 25-Oct-81 2322-PST Date: 25 Oct 81 23:22:48-EDT (Sun) From: Mike Muuss To: tcp-ip at Brl Subject: TCP-IP Digest, Vol 1 #4 TCP/IP Digest Sunday, 25 Oct 1981 Volume 1 : Issue 4 Today's Topics: Mail Reflectors and An Online Archive of the Digest PARC Universal Packet (PUP) More on TOPS-20 TCP/IP Lossage How to Force the Transition from NCP to TCP/IP Correction of Address for CERF InterNet Mail, Hostname Tables, and Routing FYI: HDH Anouncement ---------------------------------------------------------------------- From: Mike Muuss Reply-to: tcp-ip@BRL Subject: Administrative Notes For those of you who have trouble remembering where the list originates from, I have (with the graceous help of JSol) added mail reflectors for TCP-IP and TCP-IP-REQUEST on both AI and MC. People wishing to get back issues can now FTP them from Utah-20 (see letter below), or they can write to TCP-IP-REQUEST. Again, I regret our inability to allow anonymous logins. If there is a high demand for back issues, other archive sites may be set up. ------------------------------ From: Jay Lepreau Subject: Online Archive We are keeping an online archive, of at least recent stuff. Will probably archive it (to tape) after it gets old, whatever that means (probably a function of disk space and interest and list content). Anyway, people are welcome to ftp it from here-- it's tcp-ip.txt, in chronological order, MM format. ------------------------------ From: nowicki@Diablo at Sumex-Aim Subject: PUP PUP stands for Parc Universal Packet. It is the network architecture used in the Xerox internet for several years, which has several hundred computers on various kinds of networks throughout the world. A good overview is in April 1980 IEEE Transactions on Communication. To summarize its features, it is a datagram-based very simple family of protocols, from which IP borrows many of its ideas. Because it was one of the first working "network architectures," there are some unresolvable problems, like limited address space. Stanford did Unix implementations of PUP because we got all sorts of equipment from Xerox that used it. Ethernet has always supported multiple "network-level" protocols, so there is no problem encapsulating IP at the same time. Does that clear up some confusion? -- Bill ------------------------------ From: Chris Ryland Subject: Re: TCP-IP Digest, Vol 1 #3 If anyone is interested in more detail concerning the problems with TOPS-20 TCP/IP, I wrote a long-winded document about said topic. It needs some polishing up to reflect feedback from the people who did the work, but if there's enough interest (how do we gauge it?) I'll make it available. Mark Crispin hit on some of the high points, but if you're a TOPS-20 type and are worried about what TCP is going to mean to you if DEC continues its current course, then it should be useful. I can only second Mark's prediction that this current BBN/DEC TOPS-20 implementation is going to be basically useless because of its poor performance. There is some hope that there is something grossly wrong with it that can be tuned away, but we're grasping at straws. Does anyone at ISI involved in looking at this implementation have any new data? ------------------------------ Subject: Suggestions to make the NCP ==> TCP Transition happen. From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff at SRI-CSL Here are some suggestions to help/force people implement TCP/IP by "the deadline", Jan 1, '83: 1) Removal of NCP from TIPS -- When your out of town and away from your host, and can't login to read your mail, you'll want to have it implemented. 2) When your Principle Investigator (i.e. high level bureaucrat) can't send mail to other hosts which only support TCP or login remotely from a TIP, you'll want to have TCP/IP implemented. 3) I believe it is DARPA's intention to put AS MANY services as possible onto the Internet (i.e. only accessable via TCP/IP) that users will REALLY WANT to implement the Internet Protocols in order to have access to them. It might be nice for a "Directory Of Services" (like the VAN-Gateway for example) to be published to show availalbe Internet services. [I guess this would be the current ARPANET RESOURCES HANDBOOK covering the entire Internet as opposed to just ARPANET Resources, and perhaps becoming the INTERNET RESOURCES HANDBOOK?] and lastly (this one is my favorite), 4) Have such hosts as the various ISI-* systems, where most of the Network Sponsors have their mailboxs who provide many a funded $$$ to us all, de-install NCP on the transition date. Therefore, causing anyone who has *NOT* impelemented Internet by that time, be unable to communicate with their Sponsor, and hence, they won't get funded. ------------------------------ Subject: RECENT CORRESPONDENCE From: CERF at USC-ISI MIKE, RECENTLY I SENT YOU A NOTE WHICH YOU PUBLISHED AS PART OF YOUR NEWSLETTER. WHEN I SAW THE NOTE, I REALIZED THERE MIGHT BE SOME CONFUSION CAUSED BY THE FACT THAT IT WAS SENT FROM MY SECRETARY'S MAILBOX (DUCKETT@ISIE) AND NOT FROM MINE (CERF@ISIA). JUST WANTED TO ALERT YOU TO THIS (AND YOUR READERS). THE ODDLY FORMATTED MESSAGE BEFORE YOU COMES FROM AN APPLE COMPUTER WITH SMALL DISPLAY SCREEN (15 USABLE LINES) AND 40 CHARACTERS ACROSS AND UPPER CASE ONLY. THE ONLY SAVING GRACE IS THAT THE COLOR GRAPHICS AND SHOOTING GALLERY GAMES LOOK GOOD IN COLOR... VINT CERF DARPA/IPTO ------------------------------ From: ihnss!cbosg!cbosgd!mark at Berkeley To: cbosg!ihnss!ucbvax!tcp-ip@Berkeley Subject: Re: REM's gripes about internet mail I found REM's comments interesting but not very well based in reality. First note that the internet mail standard is essentially "user.host@network" where user, host, and network are character strings. There is no assumption that the "host@network" pair can be mapped into a pair of integers from some table somewhere, unless you actually intend to send packets and simulate things like telnet. Of course, for sending mail you don't need this. PCnet is not the only network that provides el-cheapo service at el-cheapo prices (e.g. over dialup telephone lines). The UUCP net has been around for some years and does this (with no internal numbering of hosts) and the new CSNET PhoneNet is the same idea. Only the network has to be able to translate "host" into enough information to route the message there, not the whole internet. This requires ONE SITE on each network to keep an up to date list of sites and routes. Other sites have the option of sending the mail to the smart site to forward. The alternative to this is what UUCP does now: you explicitly route messages through all the hosts that forward the message, e.g. decvax!duke!unc!smb@Berkeley gets forwarded through the three UUCP sites decvax, duke, and unc to user smb. The advantages to this are (1) to add a site, all you have to do is inform its neighbor(s) that it exists, and (2) the software doesn't have to worry about routing. The disadvantages are (1) it's a pain for people to manually route stuff, and, more importantly, (2) your address varies depending on the place the mail is sent from. Thus the current custom of specifying a UUCP address relative to a well known host such as ucbvax or duke. Not very pleasant. If a net like PCnet wants to avoid keeping tables anywhere, all that's necessary is to put info such as phone number and other connection info in the host field. (I don't recall a limit on how long these names can be, although most implementations will probably assume one, so some large upper limit ought to be documented.) This makes even UUCP look luxurious - you get to refer to a site by NAME! REM's latitude/longditude/telno scheme seems kind of useless to me - within one square minute can often be found a large number of computers. Often they are on a switch front end, so even the phone number is the same. Maybe this will work for personal home computers, but if everybody in a large office building has their own personal computer... In any case, it seems that such conventions ought to be up to the individual network to specify, so long as they fit the user.host@network syntax. Mark Horton Mark@Berkeley -------------------------------- From: NIC at SRI-NIC Subject: ANEWS-9 There is a new alternative host interface for the ARPANET C/30 IMPs called HDH (HDLC Host). This interface method is similar to the existing VDH (Very Distant Host) interface in that it provides for reliable transmission of messages between the host and its IMP over a communication circuit of arbitrary length. As with VDH, the HDH interface can be used with communication circuits that range in speed from 9.6KB to 56KB. HDH is superior to the VDH interface in that it uses as a reliable transmission protocol the HDLC protocol which is the link level control procedure of the CCITT international standard X.25. HDLC is supported by a much wider range of vendor equipment than the special ARPANET VDH protocol. It is also technically superior to VDH in that it provides for a window of up to seven outstanding frames instead of the two allowed by VDH, thus increasing the potential throughput. The HDH interface is also capable of accepting a full-length ARPANET host/IMP message in a single frame, where VDH always requires fragmentation into buffer-sized frames. END OF TCP-IP DIGEST ******************** ----MESSAGE-END----