----MESSAGE-BEGIN---- [12172060287.46.JNC%40XX.LCS.MIT.EDU] <1986010207240800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: Drop from Mailing List Message-ID: <12172060287.46.JNC@XX.LCS.MIT.EDU> Date: Thu, 2-Jan-86 12:24:08 EST Article-I.D.: XX.12172060287.46.JNC Posted: Thu Jan 2 12:24:08 1986 Date-Received: Thu, 2-Jan-86 22:19:51 EST References: <8512271533.AA29624@a.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Once again, please send messages requested to be added or dropped from the TCP-IP mailing list to 'TCP-IP-REQUEST' at SRI-NIC. Do NOT send such messages to TCP-IP, since you are sending junk mail to thousands of people. I am currently mildly harassing people who do this, and may escalate to persecution if warranted. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601040526.AA04342%40ucbvax.berkeley.edu] <1986010319270300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mills@DCN6.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Heath clocks compared Message-ID: <8601040526.AA04342@ucbvax.berkeley.edu> Date: Sat, 4-Jan-86 00:27:03 EST Article-I.D.: ucbvax.8601040526.AA04342 Posted: Sat Jan 4 00:27:03 1986 Date-Received: Sat, 4-Jan-86 06:36:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Folks, I ran an experiment designed to compare the times across the network between two Heath GC-1000 WWV clocks, one near Washington, DC, and the other in Ann Arbor, Michigan. The experiment collected ICMP Timestamp messages from each site for a nine-hour overnight period when both clocks were synchronized to the 5-MHz WWV signal, at least most of the time. The collected data was then reduced and graphed. The results show the two clocks are in very close agreement and exhibit the same three-minute sawtooth-looking error function as I described earlier. The peak-peak amplitude of the error function is about 100 ms and the mean error is about 30 ms. relative to our WWVB reference clock. Not bad at all. The graphs themselves are in Sun rasterfile format and can be displayed using the screenload program for the Sun. The files are on dcn9.arpa called umi.bit (Ann Arbor) and dcn.bit (Washington) and are accessible with anonymous FTP. Thanks to Milo Medin (medin@orion.arpa) for polishing up our Sun-resident NTP server and rehosting under 4.3bsd. The server now runs in dcn9.arpa, orion.arpa ames.arpa and trantor.umd.edu, as well as assorted fuzzballs. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986010405012400> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Fri 3 Jan 86 21:18:38-PST Date: 04-Jan-86 05:01:24-UT From: mills@dcn6.arpa Subject: Heath clocks compared To: tcp-ip@sri-nic.arpa Folks, I ran an experiment designed to compare the times across the network between two Heath GC-1000 WWV clocks, one near Washington, DC, and the other in Ann Arbor, Michigan. The experiment collected ICMP Timestamp messages from each site for a nine-hour overnight period when both clocks were synchronized to the 5-MHz WWV signal, at least most of the time. The collected data was then reduced and graphed. The results show the two clocks are in very close agreement and exhibit the same three-minute sawtooth-looking error function as I described earlier. The peak-peak amplitude of the error function is about 100 ms and the mean error is about 30 ms. relative to our WWVB reference clock. Not bad at all. The graphs themselves are in Sun rasterfile format and can be displayed using the screenload program for the Sun. The files are on dcn9.arpa called umi.bit (Ann Arbor) and dcn.bit (Washington) and are accessible with anonymous FTP. Thanks to Milo Medin (medin@orion.arpa) for polishing up our Sun-resident NTP server and rehosting under 4.3bsd. The server now runs in dcn9.arpa, orion.arpa ames.arpa and trantor.umd.edu, as well as assorted fuzzballs. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860104205246.070305%40MIT-MULTICS.ARPA] <1986010410520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Swenson@MIT-MULTICS.ARPA ("Eric J. Swenson") Newsgroups: mod.protocols.tcp-ip Subject: Public Domain FTP/TELNET in C Message-ID: <860104205246.070305@MIT-MULTICS.ARPA> Date: Sat, 4-Jan-86 15:52:00 EST Article-I.D.: MIT-MULT.860104205246.070305 Posted: Sat Jan 4 15:52:00 1986 Date-Received: Sat, 4-Jan-86 20:48:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Do public domain versions of user/server FTP and user/server TELNET exist for Unix systems? Would someone point me in the right direction if this is not the correct place for this kind of a query? Thanks. Please reply by mail, since I do receive reliable copies of messages posted to this mailing list. Thanks in advance. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12173020502.53.ROODE%40SUMEX-AIM.ARPA] <1986010523184500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ROODE@SUMEX-AIM.ARPA (David Roode) Newsgroups: mod.protocols.tcp-ip Subject: non-Internet net name domains Message-ID: <12173020502.53.ROODE@SUMEX-AIM.ARPA> Date: Mon, 6-Jan-86 04:18:45 EST Article-I.D.: SUMEX-AI.12173020502.53.ROODE Posted: Mon Jan 6 04:18:45 1986 Date-Received: Tue, 7-Jan-86 01:38:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 79 Approved: tcp-ip@sri-nic.arpa An article in a recent CSNET-FORUM Digest concerns some practical issues for extending name domains to cover CSNET. CSNET consists of a small part which runs TCP/IP protocols and a much larger part which provides mail-only service using the switched telephone network and modems to reach a central relay machine. I'm concerned because of the references to permission from NIC to establish a domain which is apparently being denied. I can see a possibility for the establishment of a CSNET domain being the right thing to do, just as I can for another CSNET-like entity with which I am associated, but which is just in the formation stage. For that reason I hope passing this article along might encourage some input to this decision and these regulations. ------------------------------ Date: 10 Dec 85 11:18:03 EST (Tue) From: Craig Partridge To: Chris Johnson Subject: domains, subdomains ... etc ... Chris, Dick Edmiston forwarded your note on this subject to me. > ... I recently sent mail > to HOSTMASTER@SRI-NIC regarding domain names and was told that you and > they were currently working out a plan for domain names on CSNet. True? Yes this is correct. We are to meet with them in January to try to iron things out. They have told us they do not want to support a CSNET specific domain, such as .csnet or .cs.net. By implication this means that they'd like CSNET sites registered just like Internet sites (so your domain would be something like NU.EDU). This is perfectly feasible, even though your host is not on the Internet. The domain system stores mail routing information as well as network addresses, and we can set things up so that all mail to hosts in NU.EDU get forwarded (transparently) to the CSNET relay. In some ways, this would be rather nice. For example, your mail address would become JOHNSON@NU.EDU (or something close) everywhere... No more CSNET vs. ARPANET addresses. Oh yes, final authority on names rests with the NIC. Now for the kicker. For this to work, someone has to run a domain server on the Internet for NU.EDU. It is not clear that this is practical. Imagine the problems of trying to list all the hosts at all the PhoneNet sites and keeping those databases up to date. To make things worse, the NIC currently requires TWO independent servers so that if one goes down, your domain doesn't suddenly go off into the great black void. There are some compromise positions available, but it isn't clear that people like them. For example, we can set up your domain such that any mail addressed to anyhost in NU.EDU gets sent to you to sort out. This means you get to handle mail with invalid hostnames (like BAD.NU.EDU) at your end. It is not clear that this is desirable. We are currently working on the assumptions that (1) naming will be the way I describe above (you'll be NU.EDU, or whatever the NIC approves), and that (2) CSNET will try to provide domain server facilities for PhoneNet sites. Neither of these decisions is carved in stone. We'll know much more after the January meeting. I'm sorry if this all sounds a bit fuzzy. The conversion to domains throughout the Internet is going slower than anticipated. We have only recently gotten reliable domain server software and it still has misfeatures. None of the major mailers knows about domains yet, though there are beta releases of both MMDFII and Sendmail that are currently being tested. This all makes it very hard to talk with absolute certainty about the future state of mail software in the domain world. Let me know if I can be of further assistance. Craig Partridge CSNET Technical Staff ------------------------------ ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601062108.AA11808%40LL-XN.ARPA] <1986010611082100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: glenn@LL-XN.ARPA (Glenn Adams) Newsgroups: mod.protocols.tcp-ip Subject: Ethernet Type Field Assignments Message-ID: <8601062108.AA11808@LL-XN.ARPA> Date: Mon, 6-Jan-86 16:08:21 EST Article-I.D.: LL-XN.8601062108.AA11808 Posted: Mon Jan 6 16:08:21 1986 Date-Received: Wed, 8-Jan-86 01:58:20 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Could someone please refer me to any online or hardcopy document which specifies the 'Official' Ethernet Type Field assignments? P.S. I don't mean the excerpt of this data included in RFC900 (Assigned Numbers). Thanks much, Glenn Adams ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986010611355800> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Mon 6 Jan 86 19:39:23-PST Date: 6 Jan 1986 19:35:58 PST From: POSTEL@USC-ISIB.ARPA Subject: Assigned Numbers To: TCP-IP@SRI-NIC.ARPA The most recent version of "Assigned Numbers" is RFC 960 and is dated December 1985. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601070421.AA23463%40ucbvax.berkeley.edu] <1986010617355800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: POSTEL@USC-ISIB.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Assigned Numbers Message-ID: <8601070421.AA23463@ucbvax.berkeley.edu> Date: Mon, 6-Jan-86 22:35:58 EST Article-I.D.: ucbvax.8601070421.AA23463 Posted: Mon Jan 6 22:35:58 1986 Date-Received: Wed, 8-Jan-86 01:57:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa The most recent version of "Assigned Numbers" is RFC 960 and is dated December 1985. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601070620.AA10784%40amdcad.UUCP] <1986010620205300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ethernet Type Field Assignments Message-ID: <8601070620.AA10784@amdcad.UUCP> Date: Tue, 7-Jan-86 01:20:53 EST Article-I.D.: amdcad.8601070620.AA10784 Posted: Tue Jan 7 01:20:53 1986 Date-Received: Wed, 8-Jan-86 02:58:35 EST References: <8601062108.AA11808@LL-XN.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: AMD, Sunnyvale, California Lines: 5 Approved: tcp-ip@sri-nic.arpa Seems like that is going to be an awfully long list but I sure would like to see it if you get one. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601081902.AA16698%40mordred.Purdue.EDU] <1986010809022600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: albitz@PURDUE.EDU ("Paul M. Albitz") Newsgroups: mod.protocols.tcp-ip Subject: network address changes for Purdue CS dept. Message-ID: <8601081902.AA16698@mordred.Purdue.EDU> Date: Wed, 8-Jan-86 14:02:26 EST Article-I.D.: mordred.8601081902.AA16698 Posted: Wed Jan 8 14:02:26 1986 Date-Received: Thu, 9-Jan-86 03:31:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa On Thurs Jan 9 at 8pm EST the CS dept will be changing most of our host addresses as a step towards subnetting. Hosts.txt will have our new addresses sometime on Thursday. As a last resort, you can edit /etc/hosts by hand. Delete the 128.10.0.1 address for Purdue.edu and use 192.5.48.1 as it will not change. Paul Albitz ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986010813312400> Received: from ucbvax.berkeley.edu by SRI-NIC.ARPA with TCP; Wed 8 Jan 86 22:54:42-PST Received: by ucbvax.berkeley.edu (5.39/1.7) id AA27039; Wed, 8 Jan 86 22:52:58 PST Received: by ucdavis.UUCP (4.12/4.7) id AA17059; Wed, 8 Jan 86 21:33:07 pst Received: by clover.DAVIS.uucp/ucd.CSNET (4.12/4.7) id AA08511; Wed, 8 Jan 86 21:31:24 pst Date: Wed, 8 Jan 86 21:31:24 pst From: ucdavis!clover!apffel@ucbvax.berkeley.edu (Jim Apffel) Message-Id: <8601090531.AA08511@clover.DAVIS.uucp/ucd.CSNET> To: tcp-ip@sri-nic Subject: VMS TCP/IP for uVAX II Database Query: Are there any experts out there who know of cheap TCP/IP network software which will run on the DEC VAXStation II under uVMS using the DEC Ethernet interface? I know of two possible solutions: Wollongong (415) 962-7100 supplies a TCP/IP software package running on uVMS for ~$3,000. EXCELAN (408) 434-2300 supplies both an Ethernet board and TCP/IP software for <$3,000. Are there any other good alternatives? Please respond to: ucbvax!ucdavis!clover!apffel Thanks, Jim Apffel, Manager Computer Vision Research Lab Electrical and Computer Engineering Department 3026 Bainer Hall U.C. Davis Davis, CA 95616 Phone: (916) 752-6349 Message: (916) 753-8583 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601090531.AA08511%40clover.DAVIS.uucp.ucd.CSNET] <1986010819312400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: VMS TCP/IP for uVAX II Message-ID: <8601090531.AA08511@clover.DAVIS.uucp.ucd.CSNET> Date: Thu, 9-Jan-86 00:31:24 EST Article-I.D.: clover.8601090531.AA08511 Posted: Thu Jan 9 00:31:24 1986 Date-Received: Fri, 10-Jan-86 01:18:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa Database Query: Are there any experts out there who know of cheap TCP/IP network software which will run on the DEC VAXStation II under uVMS using the DEC Ethernet interface? I know of two possible solutions: Wollongong (415) 962-7100 supplies a TCP/IP software package running on uVMS for ~$3,000. EXCELAN (408) 434-2300 supplies both an Ethernet board and TCP/IP software for <$3,000. Are there any other good alternatives? Please respond to: ucbvax!ucdavis!clover!apffel Thanks, Jim Apffel, Manager Computer Vision Research Lab Electrical and Computer Engineering Department 3026 Bainer Hall U.C. Davis Davis, CA 95616 Phone: (916) 752-6349 Message: (916) 753-8583 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601091652.AA04239%40ucbvax.berkeley.edu] <1986010901290000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JOHNSON@NORTHEASTERN.CSNET (Chris Johnson) Newsgroups: mod.protocols.tcp-ip Subject: Hi! Happy New Year! Message-ID: <8601091652.AA04239@ucbvax.berkeley.edu> Date: Thu, 9-Jan-86 06:29:00 EST Article-I.D.: ucbvax.8601091652.AA04239 Posted: Thu Jan 9 06:29:00 1986 Date-Received: Fri, 10-Jan-86 01:52:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Hi! Happy New Year to all! Last year I asked for info on Wollongong and VMS and DG's version of tcp/ip for AOS/VS. Many replies where received and appreciated. Thank you. Another couple of questions if I may. 1) How is EXCELAN as far as reliability, usefulness, maintenance and bugs on VAX using VMS 4.2 or higher? 2) Does anybody know of a FULL implementation of tcp/ip, smtp, ftp telnet etc for DG's mv/8000, mv/10000, mv/20000 series using AOS/VS. It turns out that DG's isn't a full implementation and I don't want to be caught needing something. Thanks again to all. Chris Johnson Northeastern University johnson@northeastern (CSNet) johnson%northeastern@csnet-relay (ARPAnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986010903290000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 9 Jan 86 07:09:38-PST Received: from northeastern by csnet-relay.csnet id ad04116; 9 Jan 86 9:54 EST Date: Thu, 9 Jan 86 07:29 EDT From: Chris Johnson To: tcp-ip@sri-nic.arpa, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: Hi! Happy New Year! Hi! Happy New Year to all! Last year I asked for info on Wollongong and VMS and DG's version of tcp/ip for AOS/VS. Many replies where received and appreciated. Thank you. Another couple of questions if I may. 1) How is EXCELAN as far as reliability, usefulness, maintenance and bugs on VAX using VMS 4.2 or higher? 2) Does anybody know of a FULL implementation of tcp/ip, smtp, ftp telnet etc for DG's mv/8000, mv/10000, mv/20000 series using AOS/VS. It turns out that DG's isn't a full implementation and I don't want to be caught needing something. Thanks again to all. Chris Johnson Northeastern University johnson@northeastern (CSNet) johnson%northeastern@csnet-relay (ARPAnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986010909180000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Thu 9 Jan 86 17:33:39-PST Date: 9 Jan 86 17:18:00 PST From: Subject: ISO protocol discussions To: "tcp-ip" Reply-To: There doesn't seem to be an ARPANET newsgroup listed at the NIC for discussion of ISO protocols (especially MAP), so I'm posting this to tcp-ip. Is anyone working with ISO protocols and either in or would like to establish an informal discussion group? I'd like to see discussion about problems with the existing protocol specifications, implementation approaches, performance considerations, etc. This would be for people actually working with the protocols and not novice Q&A. Current areas include CLNS (IP), TP4, and Session. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986010910065200> Mail-From: VIVIAN created at 10-Jan-86 11:53:53 Return-Path: Received: from FORD-WDL1 by SRI-NIC.ARPA with TCP; Fri 10 Jan 86 08:50:03-PST Return-Path:<> Date: 9-Jan-86 18:06:52-PST From: jbn@FORD-WDL1 Subject: Re: retransmission timers in TCP To: narten@PURDUE.EDU Cc: jbn@FORD-WDL1, TCP-IP-REQUEST@SRI-NIC ReSent-Date: Fri 10 Jan 86 11:53:07-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip@SRI-NIC.ARPA ReSent-Message-ID: <12174184560.21.VIVIAN@SRI-NIC.ARPA> I had to go into 4.3BSD recently and fix a few bugs here, so I'll document how 4.3BSD does it, for the benefit of the community. John Nagle The algorithm in 4.3BSD works as follows: 1. Round trip times are computed for one packet at a time. Only packets containing data and which are not being retransmitted contribute to the round-trip time calculation. The timer starts when a data packet is transmitted and no other packet is being timed, and stops when an ACK covers the sequence number of the packet being timed. 2. There is a smoothed round-trip timer. Its value is initially 0 and is a smoothed running average of past round-trip times. It is updated at the completion of each successful timing, as described above. The formula is const = 0.1 srtt = srtt * (1-const) + lastrtt * const; This is actually computed in floating point. On the first round-trip, srtt is simply set to lastrtt. The result is then forced into the range 1 to 30 seconds. [It's possible to use the 0 value if there is no good round-trip before the first retransmit. This is a bug; see net.bugs.4bsd for a fix.] 3. The initial retransmit interval is 2*srtt. A backoff algorithm then applies. The standard algorithm is table-driven, and has a table of constants beginning 1.0, 1.2, etc. These are applied using the number of the retransmit as an index as multipliers to srtt. There is an alternate algorithm available by patching a flag, which uses srtt*(2^retransmitnumber) as the retransmit interval. [There's a bug here; there is a multiply by tcp-beta (=2.0) missing in one spot, and the time between the first and second retransmit is shorter than between the original and the first. Again, see net.bugs.4bsd for a fix.] We prefer the alternate algorithm, which backs off faster. Without the fixes, by the way, things are not good when the round-trip time on the net actually exceeds one second. JN ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986010910412700> Received: from SU-SIERRA.ARPA by SRI-NIC.ARPA with TCP; Thu 9 Jan 86 18:51:00-PST Date: Thu 9 Jan 86 18:41:27-PST From: Michael A. Haberler Subject: Data General AOS/VS TCP-IP To: tcp-ip@SRI-NIC.ARPA We have DG's TCP/IP since a year; also had the pleasure to beta-test it. It is derived from an early 4.2 version and runs as a separate user process; it is not integrated into the kernel and does not depend on the System III emulator for AOS/VS DG sells as well. The have pruned out all UDP code and quite a few features from FTP and Telnet as well. Server Telnet functionality is severely limited as it treats all virtual consoles as 'hardcopy' devices which means that one is restricted to line-mode editing. The Unix emulator commands also won't run with Telnet login. Therefore, Telnet login is practically unused. The DG people promised lots of improvements and fixes, but I've seen few so far. There is a native 4.2 for Eclipse machines as well which has nothing to do with the above mentioned product. - michael ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12173969123.7.HEDRICK%40RED.RUTGERS.EDU] <1986010914094100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: Hi! Happy New Year! Message-ID: <12173969123.7.HEDRICK@RED.RUTGERS.EDU> Date: Thu, 9-Jan-86 19:09:41 EST Article-I.D.: RED.12173969123.7.HEDRICK Posted: Thu Jan 9 19:09:41 1986 Date-Received: Fri, 10-Jan-86 07:33:11 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa DG has a 4.2 that runs under AOS. Presumably this would include full TCP. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601100220.AA14482%40ucbvax.berkeley.edu] <1986010915180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: art@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: ISO protocol discussions Message-ID: <8601100220.AA14482@ucbvax.berkeley.edu> Date: Thu, 9-Jan-86 20:18:00 EST Article-I.D.: ucbvax.8601100220.AA14482 Posted: Thu Jan 9 20:18:00 1986 Date-Received: Fri, 10-Jan-86 23:23:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa There doesn't seem to be an ARPANET newsgroup listed at the NIC for discussion of ISO protocols (especially MAP), so I'm posting this to tcp-ip. Is anyone working with ISO protocols and either in or would like to establish an informal discussion group? I'd like to see discussion about problems with the existing protocol specifications, implementation approaches, performance considerations, etc. This would be for people actually working with the protocols and not novice Q&A. Current areas include CLNS (IP), TP4, and Session. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601102145.AA02186%40ucbvax.berkeley.edu] <1986010916065200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jbn@FORD-WDL1.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: retransmission timers in TCP Message-ID: <8601102145.AA02186@ucbvax.berkeley.edu> Date: Thu, 9-Jan-86 21:06:52 EST Article-I.D.: ucbvax.8601102145.AA02186 Posted: Thu Jan 9 21:06:52 1986 Date-Received: Sat, 11-Jan-86 07:06:05 EST Sender: kayvan@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 46 Approved: tcp-ip@sri-nic.arpa I had to go into 4.3BSD recently and fix a few bugs here, so I'll document how 4.3BSD does it, for the benefit of the community. John Nagle The algorithm in 4.3BSD works as follows: 1. Round trip times are computed for one packet at a time. Only packets containing data and which are not being retransmitted contribute to the round-trip time calculation. The timer starts when a data packet is transmitted and no other packet is being timed, and stops when an ACK covers the sequence number of the packet being timed. 2. There is a smoothed round-trip timer. Its value is initially 0 and is a smoothed running average of past round-trip times. It is updated at the completion of each successful timing, as described above. The formula is const = 0.1 srtt = srtt * (1-const) + lastrtt * const; This is actually computed in floating point. On the first round-trip, srtt is simply set to lastrtt. The result is then forced into the range 1 to 30 seconds. [It's possible to use the 0 value if there is no good round-trip before the first retransmit. This is a bug; see net.bugs.4bsd for a fix.] 3. The initial retransmit interval is 2*srtt. A backoff algorithm then applies. The standard algorithm is table-driven, and has a table of constants beginning 1.0, 1.2, etc. These are applied using the number of the retransmit as an index as multipliers to srtt. There is an alternate algorithm available by patching a flag, which uses srtt*(2^retransmitnumber) as the retransmit interval. [There's a bug here; there is a multiply by tcp-beta (=2.0) missing in one spot, and the time between the first and second retransmit is shorter than between the original and the first. Again, see net.bugs.4bsd for a fix.] We prefer the alternate algorithm, which backs off faster. Without the fixes, by the way, things are not good when the round-trip time on the net actually exceeds one second. JN ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601100437.AA16370%40ucbvax.berkeley.edu] <1986010916412700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HABERLER@SU-SIERRA.ARPA (Michael A. Haberler) Newsgroups: mod.protocols.tcp-ip Subject: Data General AOS/VS TCP-IP Message-ID: <8601100437.AA16370@ucbvax.berkeley.edu> Date: Thu, 9-Jan-86 21:41:27 EST Article-I.D.: ucbvax.8601100437.AA16370 Posted: Thu Jan 9 21:41:27 1986 Date-Received: Fri, 10-Jan-86 23:25:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa We have DG's TCP/IP since a year; also had the pleasure to beta-test it. It is derived from an early 4.2 version and runs as a separate user process; it is not integrated into the kernel and does not depend on the System III emulator for AOS/VS DG sells as well. The have pruned out all UDP code and quite a few features from FTP and Telnet as well. Server Telnet functionality is severely limited as it treats all virtual consoles as 'hardcopy' devices which means that one is restricted to line-mode editing. The Unix emulator commands also won't run with Telnet login. Therefore, Telnet login is practically unused. The DG people promised lots of improvements and fixes, but I've seen few so far. There is a native 4.2 for Eclipse machines as well which has nothing to do with the above mentioned product. - michael ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601101033.AA14752%40ztivax.UUCP] <1986011000335800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Connecting two VAXes via DMR-11 with TCP/IP Message-ID: <8601101033.AA14752@ztivax.UUCP> Date: Fri, 10-Jan-86 05:33:58 EST Article-I.D.: ztivax.8601101033.AA14752 Posted: Fri Jan 10 05:33:58 1986 Date-Received: Sat, 11-Jan-86 02:43:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Help needed! We have connected two VAX 11/780 via DMR-11 with TCP/IP-Protocol. One of them is running ULTRIX-32 V1.0, the other one Berkeley 4.2 bsd. After changing ULTRIX 1.0 to 1.1 the connection doesn't run any longer, each call with telnet or rlogin times out. Now DEC sais, ULTRIX 1.1 needs Berkeley 4.3 to connect via DMR-11. Does anybody have similar experiences? Does anywhere a running connection ULTRIX 1.1 with Berkeley 4.3 exist? Is there a way to connect ULTRIX 1.1 with Berkeley 4.2? Does this type of connection run anywhere? Thanks in advance! Wilhelm Methfessel seismo!mcvax!unido!ztivax Siemens AG, Munich ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986011015231900> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 10 Jan 86 23:29:09-PST Date: 10 Jan 1986 23:23:19 PST From: POSTEL@USC-ISIB.ARPA Subject: domains and "nets" To: tcp-ip@SRI-NIC.ARPA Domain names are supposed to be administrative and not related to physical location, type of equipment, topology, or routing. That the initial step in establishing domain name was to say that all the existing hosts in the ARPA-Internet were in the .ARPA domain was probably a mistake. It is too easy for people to think that the ".ARPA" stands for the ARPANET rather than the ARPA administration. We probably should have called it ".TEMP" or ".OLD". It is very tempting for each communication world (such as, UUCP, CSNET, MAILNET, BITNET) to think of itself as a top level domain. And most such entities probably meet the general requirements, and would probably provide responsible management for the domain (maintaing the databases, etc.). But these entities really represent the managements of communication systems. It does not really seem appropriate to me to have my name depend on which communication system i am on, and it especially seems wrong that i would have as many different names as communication systems i subscribed to. For example, Berkeley participates in at least the ARPA world, the UUCP world, the BITNET world, and the CSNET world. It seems much more reasonable to pick names that are independent of the type of communication system, or protocols, or what ever technical details are involved. The general domain names of EDU (for Education), COM (for Commercial), etc, were chosen to be neutral. The idea is that a place like Berkeley can choose a name like BERKELEY.EDU and use that name in all the communication worlds it participates in. The details of the domain name database structure make this possible, and make possible the use of domain style names by hosts not directly on the ARPA-Internet. There is indeed some work involved, but not significantly more than is involved without the domain name system. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601110818.AA11813%40ucbvax.berkeley.edu] <1986011021231900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: POSTEL@USC-ISIB.ARPA Newsgroups: mod.protocols.tcp-ip Subject: domains and "nets" Message-ID: <8601110818.AA11813@ucbvax.berkeley.edu> Date: Sat, 11-Jan-86 02:23:19 EST Article-I.D.: ucbvax.8601110818.AA11813 Posted: Sat Jan 11 02:23:19 1986 Date-Received: Sun, 12-Jan-86 00:11:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 38 Approved: tcp-ip@sri-nic.arpa Domain names are supposed to be administrative and not related to physical location, type of equipment, topology, or routing. That the initial step in establishing domain name was to say that all the existing hosts in the ARPA-Internet were in the .ARPA domain was probably a mistake. It is too easy for people to think that the ".ARPA" stands for the ARPANET rather than the ARPA administration. We probably should have called it ".TEMP" or ".OLD". It is very tempting for each communication world (such as, UUCP, CSNET, MAILNET, BITNET) to think of itself as a top level domain. And most such entities probably meet the general requirements, and would probably provide responsible management for the domain (maintaing the databases, etc.). But these entities really represent the managements of communication systems. It does not really seem appropriate to me to have my name depend on which communication system i am on, and it especially seems wrong that i would have as many different names as communication systems i subscribed to. For example, Berkeley participates in at least the ARPA world, the UUCP world, the BITNET world, and the CSNET world. It seems much more reasonable to pick names that are independent of the type of communication system, or protocols, or what ever technical details are involved. The general domain names of EDU (for Education), COM (for Commercial), etc, were chosen to be neutral. The idea is that a place like Berkeley can choose a name like BERKELEY.EDU and use that name in all the communication worlds it participates in. The details of the domain name database structure make this possible, and make possible the use of domain style names by hosts not directly on the ARPA-Internet. There is indeed some work involved, but not significantly more than is involved without the domain name system. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601121945.AA19100%40topaz.rutgers.edu] <1986011209452800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: a couple of implementation issues Message-ID: <8601121945.AA19100@topaz.rutgers.edu> Date: Sun, 12-Jan-86 14:45:28 EST Article-I.D.: topaz.8601121945.AA19100 Posted: Sun Jan 12 14:45:28 1986 Date-Received: Mon, 13-Jan-86 04:49:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 149 Approved: tcp-ip@sri-nic.arpa I would like to describe Rutgers current network configuration, and then mention some of the problems we are looking into at the moment. I would like to see whether my ideas seem reasonable to this community, and whether others have any better approaches. The major issues will involve addressing in an environment that uses a mix of Ethernet-level and IP-level gateways, and how to set up a system with redundant IP gateways so that it will survive gateway failures. First, the configuration. We have 5 Ethernets currently in operation, with several others coming on line shortly. Four of them are connected by an IP gateway built using a design from Stanford. It is a 68000 multibus system (Forward Technology SUN board), with 3Com Ethernet interfaces. The software handles PUP, IP, and XNS. It is a full PUP gateway, handling PUP directories and routing protocols. IP support is more limited, including only ARP and ICMP echo. The IP support assumes that subnetting is in use, with 8-bit host addresses and 8-bit subnet addresses. It implements the "ARP hack", so that hosts can use it even if they don't know about subnets. Stanford estimates a capacity of about 250 packets per second. However recent tweaking of the code has probably increased this. (We haven't pushed it hard enough to see this limit yet. The only limit we have seen is that Sun 3's that use NFS through the gateway have to have some non-default parameter settings. This is a known problem with the 3Com Ethernet interface, which also affects some older Sun 2's.) [For those who may be interested in duplicating this, there are now commercial equivlents of this gateway. Proteon sells one that should be fairly similar, though with higher performance and more IP support. It should handle EGP. Len Bosack from Stanford has apparently started a company that will market a re-engineered version of the Stanford gateway. You might also check Bridge Communications and DEC.] For hosts in isolated buildings, we are installing a broadband cable system. We plan to use Applitek Ethernet bridges. That is, each building will have an Ethernet. The Ethernets will be connected via the broadband cable. The Applitek bridges work at the Ethernet level. That is, they watch every packet on the Ethernet. They dynamically build a list of all machines on the local Ethernet. When they see a packet addressed to a machine that is not on the local Ethernet, they forward it to the proper Ethernet via the broadband. (Actually, there is somewhat more control available if you need it.) They forward all broadcast packets to all Ethernets. We do not yet have throughput data on it, as the system is new and is still in test. It does seem to be able to handle Sun 3 NFS transmissions with default parameter settings on the Sun. The Applitek bridges are 68000-based systems, with a fair amount of hardware in them. I'm fairly sure there is more than one 68000 in there. It uses a modern Ethernet interface, with its own processor. The broadband communications use one 6MHz channel, and can handle 10Mbits/sec. (Yes, it is possible to get more bits in a channel than its bandwidth. This has always seemed to me to violate some basic principle, but sophisticated communications technology can get more bits/sec than Hz.) Our first setup, which will probably be put in operation this week, will connect two Ethernets, one of which is also on the gateway described in the previous paragraph. [If you are in the market for one of these, other vendors that I know of with similar products are Proteon and possibly Bridge Communications. Both of these products will use IP gateways between the local Ethernet and their long-haul network. This has both advantages and disadvantages. It allows some improvements in support of TCP/IP, but it also means that you can't handle DECnet and other protocols.] The first issue is how to set up IP addresses for the Ethernets to be connected via the Applitek bridges. Initially we figured that each Ethernet would be a subnet, just like those connected by the IP gateway. However on second thought, I believe that is a mistake. Consider the following situation. subnets 6 and 7 are connected via Applitek bridge subnets 4 and 6 are connected via IP gateway a host on subnet 6 wants to talk to a host on subnet 7. The conversation will have to go through the Applitek bridge. Recall that this operates at Ethernet level. That means that the source host will have to send an Ethernet packet with the final destination's Ethernet address in it. In order to find this address, it will have to issue an ARP. If the host on 6 knows about subnets, it will consider subnet 7 to be a separate network. It will not issue an ARP to try to find the host. Rather, it will expect to find a gateway in its gateway table (or use its default gateway). With all subnet implementations that I know, there is no way to tell a host to use a gateway to talk to subnet 4, but to issue ARP's and talk directly to subnet 7. Once you turn on subnetting, it will expect to find gateways for all subnets. Obviously we could change this behavior. But we are reluctant to adopt a network design that violates the subnetting RFC's, and requires us to make kernel changes to systems that use it. Thus we reluctantly conclude that all of the Ethernets that are connected by the Applitek bridge must be considered a single subnet. I don't much like this, because I think eventually we are going to end up using IP gateways. In order to install an IP gateway between two Ethernets that are currently connected by the Applitek bridges, we would have to remove the Applitek bridge from one of them, give it a different subnet number, change the addresses of all of its hosts, and then install the IP gateway. Does anyone see something I am missing? The second issue involves gateway reliability. This is not a problem that is immediately pressing. The gateway code from Stanford is the only piece of software I have used that has never crashed. But now and then we do take it down for development work, and we do get complaints from people who are suddenly disconnected. We have several Unix systems with more than one Ethernet interface. These hosts could act as gateways. While their performance as gateways would not be as good as a dedicated 68000 gateway, they would be fine as backup gateways. The question is, how do we set things up so that a connection will move from one gateway to an alternate when the first one goes down. 4.3 has some hint of the basic ability needed. When TCP is about to time out a connection, it first tries to compute a new route. However in order for this to help, two things must be true: - the system has to know that a gateway is in use. This means that we can't use the ARP hack. We have to install subnet support on all the hosts. - something has to change in the system's routing database, or it will choose the same bad route again. This seems to imply that all of the hosts must be running routed or EGP, and that the gateways must all support it. Initially I had hoped that all of the intelligence could be put into the gateways. However this seems to be incompatible with the current design of Unix. Here's how I would do it with TOPS-20: The gateways would know about each other. They would exchange EGP, so they know if the other is up. Dual-homed hosts would know that it is better to use the dedicated gateway if it is up. So any attempt to use a dual-homed host as a gateway would result in an ICMP redirect telling the sender to try the dedicated gateway, unless the dedicated gateway is down. Here is what a normal host would do: - its gateway table would list both the dedicated gateway and the dual-homed host. (If there were losts of gateways accessible to it, only 2 or 3 would need to be listed.) - when starting a connection, if the system didn't already have a route to the destination system, it would send the packet to a randomly chosen "prime" gateway. If it chose the wrong one (e.g. a dual-homed host, when the dedicatd gateway is up), it would be directed to the right one via ICMP redirect. - it periodically pings all gateways that it knows about. If one goes down, it is marked as such, and a new route is used in the future. Since we have a mix of Unix and TOPS-20 systems, it looks like we may have to do either - add routed support to TOPS-20 or - add EGP support to Unix and TOPS-20. (This assumes that it is practical to use EGP on every host. I have a suspicion that EGP was really only intended for use between gateways.) or - add code to Unix to mark gateways as down when connections using them time out. (It is not clear quite how we would find that they are up again.) - add code to Unix so that dual-homed gateways issue ICMP redirects if they are asked to forward a packet for which they know of a better gateway Does anybody have reason to prefer one of the other approach? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986011214280000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Sun 12 Jan 86 22:45:15-PST Date: 12 Jan 86 22:28:00 PST From: Subject: Bits, Bauds and Hz To: "tcp-ip" Reply-To: This is not really about tcp/ip, but the excerpt came off this newgroup and someone may find it interesting since most protocols usually get down to a real comm channel. > The broadband communications use one 6MHz channel, > and can handle 10Mbits/sec. (Yes, it is possible to get more bits in > a channel than its bandwidth. This has always seemed to me to violate > some basic principle, but sophisticated communications technology can > get more bits/sec than Hz.) Remember that these types of communication channels are really analog circuits. Whereas digital channels have basically only two variables (binary state and bit duration), analog channels have such variables as frequency, amplitude, phase change. Analog channels use these variables to carry more information in a given unit of time. 9600 4-wire modems still have to communicate over phone circuits which have a useful bandwidth somewhat over 3kHz. This is accomplished by sending 4 bits at a time, 2400 groups/second. The four bits are encoded as one of eight phase shifts (3 bits) and one of two amplitudes (4th bit). The time unit of a particular modulation state is named after Baudot and is called a "Baud", and the rate at which the modulation state changes is the "Baud Rate". Thus, most 9600 bit/second modems are not really "9600 Baud" modems. But, most 300/1200 bit/second modems use Frequency-Shift-Keying (FSK) where the binary state of the data directly controls which of two frequencies is being transmitted. In this case the bit/second rate is the same as the baud rate. Most broadband systems are based on CATV technology developed for video distribution. These systems use a range of frequencies broken into 6mHz bands. By modulating the carrier frequency within a 6 mHz band, each band can carry separate information. The 802.4 token bus protocol used in GM's MAP specifications uses two pairs of adjacent 6mHz channels, one pair for transmitting and the other for receiving. The channel is modulated with a technique called Duobinary AM-PSK which uses both amplitude and phase to convey information at a 10 mHz rate. Unless laboratory developments change things, fiber optics will be used digitally. A laser will generate monochromatic light which is either on or off. But Bell Labs has demonstrated that the light can be switched (and detected) many billions of times per second over useful distances. (24 telephone voice channels only use 1.544 Mbit/sec) ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601130724.AA11393%40ucbvax.berkeley.edu] <1986011220280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: art@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Bits, Bauds and Hz Message-ID: <8601130724.AA11393@ucbvax.berkeley.edu> Date: Mon, 13-Jan-86 01:28:00 EST Article-I.D.: ucbvax.8601130724.AA11393 Posted: Mon Jan 13 01:28:00 1986 Date-Received: Tue, 14-Jan-86 03:33:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 48 Approved: tcp-ip@sri-nic.arpa This is not really about tcp/ip, but the excerpt came off this newgroup and someone may find it interesting since most protocols usually get down to a real comm channel. > The broadband communications use one 6MHz channel, > and can handle 10Mbits/sec. (Yes, it is possible to get more bits in > a channel than its bandwidth. This has always seemed to me to violate > some basic principle, but sophisticated communications technology can > get more bits/sec than Hz.) Remember that these types of communication channels are really analog circuits. Whereas digital channels have basically only two variables (binary state and bit duration), analog channels have such variables as frequency, amplitude, phase change. Analog channels use these variables to carry more information in a given unit of time. 9600 4-wire modems still have to communicate over phone circuits which have a useful bandwidth somewhat over 3kHz. This is accomplished by sending 4 bits at a time, 2400 groups/second. The four bits are encoded as one of eight phase shifts (3 bits) and one of two amplitudes (4th bit). The time unit of a particular modulation state is named after Baudot and is called a "Baud", and the rate at which the modulation state changes is the "Baud Rate". Thus, most 9600 bit/second modems are not really "9600 Baud" modems. But, most 300/1200 bit/second modems use Frequency-Shift-Keying (FSK) where the binary state of the data directly controls which of two frequencies is being transmitted. In this case the bit/second rate is the same as the baud rate. Most broadband systems are based on CATV technology developed for video distribution. These systems use a range of frequencies broken into 6mHz bands. By modulating the carrier frequency within a 6 mHz band, each band can carry separate information. The 802.4 token bus protocol used in GM's MAP specifications uses two pairs of adjacent 6mHz channels, one pair for transmitting and the other for receiving. The channel is modulated with a technique called Duobinary AM-PSK which uses both amplitude and phase to convey information at a 10 mHz rate. Unless laboratory developments change things, fiber optics will be used digitally. A laser will generate monochromatic light which is either on or off. But Bell Labs has demonstrated that the light can be switched (and detected) many billions of times per second over useful distances. (24 telephone voice channels only use 1.544 Mbit/sec) ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986011306221300> Mail-From: VIVIAN created at 13-Jan-86 22:42:38 Return-Path: Received: from FORD-WDL1 by SRI-NIC.ARPA with TCP; Mon 13 Jan 86 14:23:29-PST Return-Path:<> Date: 13-Jan-86 14:22:13-PST From: jbn@FORD-WDL1 Subject: 4.3BSD TCP fixes To: TCP-IP-REQUEST@NIC ReSent-Date: Mon 13 Jan 86 22:41:29-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip@SRI-NIC.ARPA ReSent-Message-ID: <12175089023.15.VIVIAN@SRI-NIC.ARPA> In response to popular demand, I am sending out two fixes to 4.3BSD (beta release). Fix #1 affects interoperability with non-4.xBSD systems, apparently including TOPS-20 machines. Fix #2 reduces network congestion on long-haul nets. (Yes, yet another of Nagle's continuing attempts to get network congestion under control.) The effect of #2 is substantial; in some situations, an order of magnitude improvement in file transfer speeds will be observed. With these in, 4.3BSD TCP behaves quite well. In 4.3, all the right machinery is there, but there are a few easily-fixed bugs. These fixes are going out via several routes (net.bugs.4bsd, the Berkeley buglist, and to some key individuals) because they have a marked effect on interoperability and Internet performance. John Nagle =============================================================================== Index: sys/netinet/tcp_input.c 4.3BSD-beta Fix Description: TCP connections to some non-BSD systems open, but will not accept data from the remote system. The "advertised window", tcp_adv, was not initialized during connection synchronization. Also, one comparison on sequence numbers was made incorrectly, using a difference of unsigned values, which in C is always positive(!). John Nagle Repeat-By: Try to establish a TCP connection with a system which sets the high bit in the TCP sequence number. (A 4.3BSD system which has been up for more than 195 days will do this, or you can change the initial value of tcp_iss to some value with the high bit set.) Fix: tcp_input.c 327a328,329 > * Be careful with arithmetic here; differences of sequence > * numbers compare in unexpected ways. Hence the (int) cast. 329c331 < tp->rcv_wnd = MAX(sbspace(&so->so_rcv), tp->rcv_adv - tp->rcv_nxt); --- > tp->rcv_wnd = MAX(sbspace(&so->so_rcv),(int)(tp->rcv_adv-tp->rcv_nxt)); tcp_seq.h: 22a23 > * Note that our rcv_adv variable needs to be initialized too. 25c26 < (tp)->rcv_nxt = (tp)->irs + 1 --- > (tp)->rcv_adv = (tp)->rcv_nxt = (tp)->irs + 1 =============================================================================== Index: ucb/netinet/tcp_timer.c 4.3BSD-beta Fix Description: Excessive retransmissions on long-haul nets. Serious congestion in Internet gateways. File transfer speeds under 10% of expected values over 9600 baud point-to-point links. Angry network managers. The basic machinery is right but some of the special cases are wrong, resulting in bad host behavior on slow links. Several problems combine to result in very short retransmit intervals: 1) The smoothed round-trip time is zero until the first successful round-trip without retransmission. If there is a retransmission of the first packet, the zero value is actually used to compute the round-trip time, resulting in a minumum retransmission time. 2) The standard backoff algorithm not only backs off rather slowly, but due to an incorrect calculation, the first retransmit interval is 2.0*t_srtt, but the second is only 1.0*t_srtt, and not until retransmit #4 or so does the retransmit time get back up to 2*t_srtt. The supplied "experimental" backoff algorithm backs off at rate 2**n, which reduces retransmits under overload conditions. John Nagle Repeat-By: Connect two 4.3BSD systems via a 9600 baud DMR link. Try a big file transfer with ftp(I). Be prepared for a long wait. Fix: tcp_timer.c 112c112 < int tcpexprexmtbackoff = 0; --- > int tcpexprexmtbackoff = 1; /* use exponential backoff if 1 */ 154a155,169 > /* > * Calculate retransmit timer for non-first try. > * Start with the same value used for the first retransmit. > * Then use either the table tcp_backoff to scale this up > * based on the number of retransmits, or if the patchable > * flag tcpexprexmtbackoff is set, just multiply it by > * 2**number of retransmits. > * If t_srtt is zero when we get here, we have never > * had a successful round-trip and are already retransmitting, > * which indicates trouble, so we apply a larger initial guess > * for the round-trip time. This prevents serious network > * overload when talking to faraway hosts, especially when > * they aren't answering. > */ > if (tp->t_srtt == 0) tp->t_srtt = TCPTV_SRTTRTRAN; 156c171 < (int)tp->t_srtt, TCPTV_MIN, TCPTV_MAX); --- > (int)(tcp_beta * tp->t_srtt), TCPTV_MIN, TCPTV_MAX); tcp_timer.h: 60a61,62 > #define TCPTV_SRTTRTRAN ( 10*PR_SLOWHZ) /* base roundtrip time if retran > before 1st good roundtrip */ =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601132139.AA21152%40gyre.umd.edu] <1986011311395400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: mod.protocols.tcp-ip Subject: Re: retransmission timers in TCP Message-ID: <8601132139.AA21152@gyre.umd.edu> Date: Mon, 13-Jan-86 16:39:54 EST Article-I.D.: gyre.8601132139.AA21152 Posted: Mon Jan 13 16:39:54 1986 Date-Received: Wed, 15-Jan-86 00:56:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Speaking of 4.3BSD, I have heard that we were not the only beta test site to experience trouble talking to TOPS-20 machines. Does anyone have fixes for 4.3/TOPS-20 TCP/IP problems? (If so I sure hope you sent them on to Berkeley....) Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BMC.LCS.MIT.EDU%5D.782569.860113.JNC] <1986011312210300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-MC.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Wollongoing subnet support (sic) Message-ID: <[MC.LCS.MIT.EDU].782569.860113.JNC> Date: Mon, 13-Jan-86 17:21:03 EST Article-I.D.: <[MC.LCS.MIT.EDU].782569.860113.JNC> Posted: Mon Jan 13 17:21:03 1986 Date-Received: Tue, 14-Jan-86 04:18:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa I am visiting some network people at NASA Ames and they are discussing switching to using subnets for the IP installation. Apparently one of the main stumbling blocks is the fact that the Wollongoing software does not support subnets, and they are not getting much satisfaction from Wollongong on finding out if and when Wollongong will ever getting around to supporting subnets. As one of the people who originated the subnet change to the architecture, I was interested in finding out how it is doing, and in talking to manufacturers who are being slow in installing it. The experience they report (which was duplicated when I tried to contact someone at Wollongong) is that the people you get when you call up don't know anything (which you sort of expect), and, moreover, you can't get ahold of anyone who does know anything. I asked to speak to someone in engineering to ask about the subnet support issues, and got shunted to a software support person who wanted to know my license number and wouldn't talk to me because I wasn't the 'contact point' for the license number I ws prepared to give her. I gave up on her and called back and asked to speak to the VP of Engineering or some such person, and was informed that everyone was 'out to lunch'. Does anyone know if Wollongong is ever going to make any effort to keeping up with the changes in the IP spec? They certainly don't meet it now, and, from what I understand, don't seem to really care that they don't. In addition, they have one of the worst attitudes to people who call in that I have ever heard. I would recommend that people not deal with such an organization. Noel ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601141015.AA16064%40ucbvax.berkeley.edu] <1986011312221300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jbn@FORD-WDL1.ARPA Newsgroups: mod.protocols.tcp-ip Subject: 4.3BSD TCP fixes Message-ID: <8601141015.AA16064@ucbvax.berkeley.edu> Date: Mon, 13-Jan-86 17:22:13 EST Article-I.D.: ucbvax.8601141015.AA16064 Posted: Mon Jan 13 17:22:13 1986 Date-Received: Wed, 15-Jan-86 01:18:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 117 Approved: tcp-ip@sri-nic.arpa In response to popular demand, I am sending out two fixes to 4.3BSD (beta release). Fix #1 affects interoperability with non-4.xBSD systems, apparently including TOPS-20 machines. Fix #2 reduces network congestion on long-haul nets. (Yes, yet another of Nagle's continuing attempts to get network congestion under control.) The effect of #2 is substantial; in some situations, an order of magnitude improvement in file transfer speeds will be observed. With these in, 4.3BSD TCP behaves quite well. In 4.3, all the right machinery is there, but there are a few easily-fixed bugs. These fixes are going out via several routes (net.bugs.4bsd, the Berkeley buglist, and to some key individuals) because they have a marked effect on interoperability and Internet performance. John Nagle =============================================================================== Index: sys/netinet/tcp_input.c 4.3BSD-beta Fix Description: TCP connections to some non-BSD systems open, but will not accept data from the remote system. The "advertised window", tcp_adv, was not initialized during connection synchronization. Also, one comparison on sequence numbers was made incorrectly, using a difference of unsigned values, which in C is always positive(!). John Nagle Repeat-By: Try to establish a TCP connection with a system which sets the high bit in the TCP sequence number. (A 4.3BSD system which has been up for more than 195 days will do this, or you can change the initial value of tcp_iss to some value with the high bit set.) Fix: tcp_input.c 327a328,329 > * Be careful with arithmetic here; differences of sequence > * numbers compare in unexpected ways. Hence the (int) cast. 329c331 < tp->rcv_wnd = MAX(sbspace(&so->so_rcv), tp->rcv_adv - tp->rcv_nxt); --- > tp->rcv_wnd = MAX(sbspace(&so->so_rcv),(int)(tp->rcv_adv-tp->rcv_nxt)); tcp_seq.h: 22a23 > * Note that our rcv_adv variable needs to be initialized too. 25c26 < (tp)->rcv_nxt = (tp)->irs + 1 --- > (tp)->rcv_adv = (tp)->rcv_nxt = (tp)->irs + 1 =============================================================================== Index: ucb/netinet/tcp_timer.c 4.3BSD-beta Fix Description: Excessive retransmissions on long-haul nets. Serious congestion in Internet gateways. File transfer speeds under 10% of expected values over 9600 baud point-to-point links. Angry network managers. The basic machinery is right but some of the special cases are wrong, resulting in bad host behavior on slow links. Several problems combine to result in very short retransmit intervals: 1) The smoothed round-trip time is zero until the first successful round-trip without retransmission. If there is a retransmission of the first packet, the zero value is actually used to compute the round-trip time, resulting in a minumum retransmission time. 2) The standard backoff algorithm not only backs off rather slowly, but due to an incorrect calculation, the first retransmit interval is 2.0*t_srtt, but the second is only 1.0*t_srtt, and not until retransmit #4 or so does the retransmit time get back up to 2*t_srtt. The supplied "experimental" backoff algorithm backs off at rate 2**n, which reduces retransmits under overload conditions. John Nagle Repeat-By: Connect two 4.3BSD systems via a 9600 baud DMR link. Try a big file transfer with ftp(I). Be prepared for a long wait. Fix: tcp_timer.c 112c112 < int tcpexprexmtbackoff = 0; --- > int tcpexprexmtbackoff = 1; /* use exponential backoff if 1 */ 154a155,169 > /* > * Calculate retransmit timer for non-first try. > * Start with the same value used for the first retransmit. > * Then use either the table tcp_backoff to scale this up > * based on the number of retransmits, or if the patchable > * flag tcpexprexmtbackoff is set, just multiply it by > * 2**number of retransmits. > * If t_srtt is zero when we get here, we have never > * had a successful round-trip and are already retransmitting, > * which indicates trouble, so we apply a larger initial guess > * for the round-trip time. This prevents serious network > * overload when talking to faraway hosts, especially when > * they aren't answering. > */ > if (tp->t_srtt == 0) tp->t_srtt = TCPTV_SRTTRTRAN; 156c171 < (int)tp->t_srtt, TCPTV_MIN, TCPTV_MAX); --- > (int)(tcp_beta * tp->t_srtt), TCPTV_MIN, TCPTV_MAX); tcp_timer.h: 60a61,62 > #define TCPTV_SRTTRTRAN ( 10*PR_SLOWHZ) /* base roundtrip time if retran > before 1st good roundtrip */ =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601140024.AA04700%40ngp.UTEXAS.EDU] <1986011314245000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: rick@NGP.UTEXAS.EDU (Rick Watson) Newsgroups: mod.protocols.tcp-ip Subject: Re: Wollongoing subnet support (sic) Message-ID: <8601140024.AA04700@ngp.UTEXAS.EDU> Date: Mon, 13-Jan-86 19:24:50 EST Article-I.D.: ngp.8601140024.AA04700 Posted: Mon Jan 13 19:24:50 1986 Date-Received: Tue, 14-Jan-86 04:18:58 EST Sender: adrion@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa After MUCH telephoning to TWG, I finally talked to John Caughy (spelling?) who I think is the TCP/IP product Project Manager. (415/962-7177). He said that neither subnets or name servers will be in the March release, but that the September (86) release would be based on 4.3 BSD. I got the idea that they are not interested in doing much more development on TCP/IP and from their end, they saw little interest in subnets. They were not even interested in our doing the work for them. Disclaimer: The above is from brief notes I made during our phone conversation of a couple of months ago. Does anyone know of a GOOD TCP/IP (well supported, etc) product for VMS? Anyone interested in a public domain (or othersise) TCP/IP for VMS effort? Rick Watson University of Texas Computation Center arpa: rick@ngp.UTEXAS.EDU rick@ngp.ARPA uucp: ...seismo!ut-sally!ut-ngp!rick rick@ut-ngp.UUCP bitnet: ccaw001@utadnx phone: 512/471-3241 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12175030132.45.JNC%40XX.LCS.MIT.EDU] <1986011315175900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: Wollongoing subnet support (sic) Message-ID: <12175030132.45.JNC@XX.LCS.MIT.EDU> Date: Mon, 13-Jan-86 20:17:59 EST Article-I.D.: XX.12175030132.45.JNC Posted: Mon Jan 13 20:17:59 1986 Date-Received: Tue, 14-Jan-86 04:35:03 EST References: <8601140024.AA04700@ngp.UTEXAS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa I just finally managed to get a hold of someone at the VP level. He was fairly helpful, but apparently nothing will come out of the pipe quickly, unless enough customers ask loudly enough. He had never even heard of the subnet spec, and I had to give him the RFC numbers. Apparently part of the problem is that there isn't a good path to get info about changes like this to companies if they aren't on the Internet. Perhaps a path exists for getting the existing RFC announcements into a UUCP group, e.g. net.rfcs? That would help these people. (Also, the subnet stuff is only marked 'recommended' rather than 'required' both on RFC950 (the subnet spec) and in the Official IP Protocols list (RFC961). This seems like a poor idea since if a single implementation at a site is missing it it can be difficult to turn on subnetting. It's harder to beat on companies to add something if it's not marked 'required', too..) Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12175039385.10.GEOF%40XX.LCS.MIT.EDU] <1986011316084900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: GEOF@MIT-XX.ARPA (Geoffrey H. Cooper) Newsgroups: mod.protocols.tcp-ip Subject: TCP Send buffer constraints destroy datarate Message-ID: <12175039385.10.GEOF@XX.LCS.MIT.EDU> Date: Mon, 13-Jan-86 21:08:49 EST Article-I.D.: XX.12175039385.10.GEOF Posted: Mon Jan 13 21:08:49 1986 Date-Received: Wed, 15-Jan-86 00:49:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 50 Approved: tcp-ip@sri-nic.arpa The other day I was playing with Imagen's TCP with a collegue, and we discovered an interesting thing. If we decreased the printer box' offered window from 6KB to 2KB, the source-to-sink datarate transferring from a Vax 4.2 to the printer increased dramatically (from 30 Kbit/s to 300 Kbit/s). The reason for this behavior is apparently that the vax allocates only 2K of buffer space to an outgoing TCP connection. Thus it can only send 2K before receiving an Ack. In the printer box, ACKs are carefully delayed for 1/2 a second to increase piggybacking unless the window is opened. The window is opened when it is half consumed (i.e., after about 3KB of data is transferred). In the vax's case, this allows 2KB of data every 1/2 second, or 32Kbit/s. This was just the figure I had been getting. The general problem is that the window flow control reflects the receiver's buffer constraints, and there is no way for the sender's constraints to be tr)n{mitted across the connection. In the XNS Sequenced Packet Protocol, an ACK bit in a packet performs this function; it allows the sender to explicitly request an immediate acknowledgement for the last packet in the "send window." I've been trying to figure ways to fix the problem. One algorithm would be to send the ack after a dally or immediately if the connection's packet input queue is empty after processing an input packet. This would allow an entire string of packets to be received properly and would not tend to cause excessive ack's. It works well if the TCP process was dequeuing packets at a lower priority than the internet process was enqueuing them. This doesn't work in systems like mine which do not have separate processes with queues between them for TCP connections. In my case, the TCP module is upcalled with each packet as a pseudo-interrupt, and all processing takes place either during the upcall, during the client's downcall to get data, or during a timer interrupt. I can check the interface to see if additional packets have arrived, but it is not assured that they are from the right connection. Another possibility is to notice that an ack is being sent after a dally, and decrease the offered window. This would work (especially since the printer's only application is for bulk data input), but I am concerned about the lack of generality in the scheme. For one thing, there is no way to increase the offered window once it is decreased -- sounds like a perfect way to develop silly window syndrome. I'd like to see some other thought on this problem. How do other implementations of TCP deal with this situation? Do they set tight timers? Do they get trapped by it (be honest...)? Please respond to the list and sign all messages (otherwise I can't tell where they come from on usenet-news), my incoming mail is not working well. - Geof Cooper IMAGEN ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601140552.AA08518%40topaz.rutgers.edu] <1986011319522300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: more (possibly too many) thoughts on systems of gateawys Message-ID: <8601140552.AA08518@topaz.rutgers.edu> Date: Tue, 14-Jan-86 00:52:23 EST Article-I.D.: topaz.8601140552.AA08518 Posted: Tue Jan 14 00:52:23 1986 Date-Received: Wed, 15-Jan-86 00:54:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 232 Approved: tcp-ip@sri-nic.arpa Since my posting yesterday, I have given a bit more thought to the issue of keeping track of network topology. I got several responses acknowledging that the issue was an important and difficult one, but none proposing any real solutions. So it seemed worth putting a bit more thought into the issue. While I haven't come up with any startling innovations, I think I see a couple of approaches that would work. First, let me start by enumerating the possibilities that I have seen. We have several issues. The first is how hosts keep track of what gateways are up. The second is how hosts keep track of changes in gateway status. The third is how hosts know what gateways exist. Of course these are not orthogonal. Keeping track of what gateways are up: pinging - every host sends an echo request to every gateway that it knows about every 30 sec. or so. Most people consider this unacceptable because it generates too much network traffic. TOPS-20 does this, though with an interval of several minutes. I believe it must be done every 30 sec., because we have to be able to discover that a gateway is down in time to move to another one before connections start timing out or users start thinking that the system is down. gateway broadcast - every gateway sends a broadcast every 30 sec. For a network that supports broadcasts, this gives as good results as pinging, but the number of packets is far smaller. PUP and XNS gatewayinfo do this. So does Unix routed. The only disadvantage I can see is that it only works if the network supports broadcasts, and that it may not be so good for single-process systems (e.g. IBM PC). On an IBM PC, you can't just have a daemon sitting there keeping track of what networks are up. Telnet could have to wait a minute or two gathering gateway information before starting to make the connection. host broadcast - when a host wants to make a connection, it sends a broadcast asking for any gateways to a certain host to respond. This is effectively done now by ARP-hacking gateways. Since an ARP is needed anyway to initiate a connection, it adds no overhead. This strategy is appropriate for single- process systems. The only disadvantage I can think of is that it only works on media that support broadcast. Note that in a complex network, this stategy requires that the gateways have some other way to keep track of each other. They must arrange things so that only the preferred gateway will respond to an ARP. Keeping track of changes. These techniques would normally be combined with those above. timeouts - when a connection times out, one has a good suspicion that some part of the current route is down. What to do about it depends upon which of the above strategies one is using. If you are using pinging or gateway broadcast, strictly speaking you don't need to do anything about timeouts. 4.3 uses timeouts because 4.3 establishes a route when a connection is opened. Even if routed has figured out that the gateway involved is down, the connection will still try to use it. A timeout triggers the system to reexamine the route, using its latest gateway information. On TOPS-20, this is not needed, since the route is recomputed for each packet sent. If you are depending upon a host broadcast (e.g. ARP), a timeout should cause the current route (in this case ARP table entry) to be removed, so that the host sends another broadcast to look for a new route. Note that timeouts do not totally solve the problem of detecting down gateways, if we have traffic to some gateway (or for ARP-based schemes, host) that is not connection-oriented. That is, UDP-based protocols may not have a concept of timeout, or may find it hard to feed back information about timeouts to lower levels of the system. ICMP redirect - depending upon the design, the system may not know when a better route has become available. Again, TOPS-20 always will, because it recomputes routes each time, and continually pings all gateways. But 4.2 will not change routes during a connection. And a system that depends upon the ARP hack probably doesn't have enough information to do so either. So one can arrange for gateways to keep track of each other, and to issue an ICMP redirect if a better route becomes available. Note that this does not necessarily require the host to keep track of gateway information. If all of the gateways do the ARP hack, a host can process an ICMP redirect simply by removing the ARP table entry for the destination host involved. ARP table expiration - Unix expires entries in the ARP table after N minutes of non-use. This is primarily intended to keep down the number of entries in the ARP table. However in theory this could be used to keep routing up to date. If we expired entries even when they are in use, it would force a new ARP request. This would (we hope) come back with the latest routing, taking into account any gateways that have come up or gone down. The problem with doing this is that it would increase the number of ARP requests. If we only use it to discover better routes, we could afford to do it fairly infrequently, say once every 30 min. If we depend upon it to discover gateways that are down, we probably have to do it every 30 sec. This is likely to cause results that are about as bad as pinging. It would also interfere with performance, since our experience shows that waiting for an ARP causes a noticable pause in telnet. Doing this once every 30 min is not likely to cause a significant load. Suppose we have 256 hosts on a subnet, each talking to 4 other hosts at a time (this is probably a gross overestimate for any real network). That is 1000 ARP requests in 1800 sec. This is a packet rate of around 1 per second. That should be tolerable. However the requests are probably not going to be random. There may be a tendency for them to cluster, due to the fact that all of the systems will have been rebooted at the same time (the last power failure). Knowledge of network topology. builtin tables - this is fairly common, but with a large network it becomes a pain to update all the tables. gateway broadcasts - the gateway broadcast strategy mentioned above also solves this problem, since it allows the host to discover what gateways exist simply by monitoring broadcasts. host broadcasts - the host broadcast strategy mentioned above also solves this problem, since the host no longer has to know the network topology. When it needs to make a connection it broadcasts a request and the gateways have to figure out who should respond. To use changes in topology, this should be combined with ICMP redirects when a better route becomes available. try a random gateway - TOPS-20 keeps a table with a small number of "prime" gateways. When it wants to make a connection, and none of the currently known gateways is right for the job, it chooses a random prime gateway. This gateway is expected to know about all of the others, and to issue an ICMP redirect to the right one. However this only works if one knows which of the prime gateways are up. TOPS-20 uses pinging. Any other solution to the problem of knowing which gateway is up will also solve the problem of knowing what gateways there are, so this strategy is probably not terribly useful. Some choices are clear: - we probably don't want pinging to be the primary method of keeping track of the network. - ARPs are probably the only reasonable way for single-process machines to find out about the network, since they can't be expected to have daemons that keep track of topology. This implies that all gateways should be expected to support the "ARP hack", even when subnetting is general implemented. Now the question is whether we also want the gateways to broadcast, a la routed. My initial reaction is that if we can come up with a mechanism based on ARPs that will solve all of our problems, there is no need to run routed or its equivalent on each host. So first, let's look at a design based on ARPs, and no protocol like routed. - connections are initially established by issuing an ARP request. The gateways arrange to answer these in such a way as to give an optimal route. - when a connection times out, the ARP table entry for the host involved is removed. This forces a new ARP for the next packet to be sent. - when a better route becomes available, it would be helpful if the gateway currently being used issues an ICMP redirect. Because of the timing out of ARP table entries, this is not completely necessary. - if non-connection-oriented protocols are being used (so that timeouts are not possible), or if it is not practical for gateways to issue ICMP redirects when a better route becomes available, ARP table entries must expire after 30 minutes. This mechanism is obviously not sufficient for hosts with more than one Ethernet interface, since they have no way to choose which interface to use. ARP's don't help, since in general some other gateway will probably be able to find a route to any host on any subnet, so there will be responses to ARP requests on both interfaces. However a host with more than one interface is effectively a gateway. It should participate in whatever protocol is used among the gateways, probably EGP or routed. There are several reasons why one might prefer some other mechanism for hosts that are capable of running daemons: - if UDP-based protocols are in heavy use, it may be impractical to detect down gateways by depending upon timeouts. For Suns, the Network File System is critical, and that uses UDP. While NFS does have a concept of timeout, our experience shows that timeouts may indicate a number of conditions other than routing failures. It is not clear whether it would be appropriate to clear ARP table entries when there is an NFS timeout. - one may believe that it is not practical to implement ICMP redirect in the gateways when a better route becomes available, and that the overhead of expiring ARP entries is unacceptable. If one decides that another scheme is needed other than having the host broadcast requests, it seems clear that the best alternative is to have the gateway broadcast the fact that it is up. In that case, routed seems to make a lot of sense. It is widely implemented, and seems to do what needs to be done. In a Unix implementation, one also needs a way to force routes to be recomputed when there is a change in the gateway table. The method in 4.3 seems to depend upon timeouts. I suspect it might be better to have an IOCTL that routed could do to invalidate routes (either all routes whenever a topology change happens, or some slightly more selective method). Unfortunately, the problem I have to solve is not just picking the combination of strategies that I like the best. I also have to be able to live with existing TCP/IP implementations. Currently Rutgerse is using 4.2 (Sun, Pyramid, Celerity, Ultrix), TOPS-20, DG, Symbolics, Bridge, ... We only have source to some of these, and even where we do have source, it may not be desirable to do major network development work. If we are unable to change the host implementation, then the advice to a gateway designer is pretty much the obvious: 1) Do the best one can for hosts that will depend upon ARP's to discover routing. This means trying to coordinate gateways so that only the best one responds. 2) Enough systems use code based on 4.2, and routed is a reasonable enough way of doing things, that it probably makes sense for the gateways to implement routed. 3) One should probably try to get gateways to issue ICMP redirects whenever appropriate. However it is not clear which existing implementations this is going to help. Certainly it would help TOPS-20. Existing systems that use ARP are pretending that all all of the hosts are directly connected, so an ICMP redirect is going to be irrelevant to them. For Unix systems, ICMP redirect doesn't add much to what routed already provides (and indeed may even confuse it, if routed thinks it is managing the gateway tables). Circumstances where ICMP redirects could be generated are when a packet is sent to a gateway that knows it is not the best route. Len Bosack at Stanford suggests that gateways should have a command that says we are about to shut them down. In that case, they can start issuing ICMP redirects to an alternate. (However one has to be careful to avoid loops. If the alternate doesn't know you are shutting down, and it is a less prefered route, it may issue a redirect right back to you.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601140659.AA19188%40mouton.ARPA] <1986011320591200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: karn@MOUTON.ARPA (Phil R. Karn at mouton.ARPA) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP Send buffer constraints destroy datarate Message-ID: <8601140659.AA19188@mouton.ARPA> Date: Tue, 14-Jan-86 01:59:12 EST Article-I.D.: mouton.8601140659.AA19188 Posted: Tue Jan 14 01:59:12 1986 Date-Received: Wed, 15-Jan-86 01:18:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa Delaying acknowledgements with timers has always bothered me. Either the application will send something in reply almost immediately (e.g., Telnet echoing) or it will take so long that the acknowledgment timer will expire with nothing to send, increasing the effective round trip time and limiting throughput when the windows are small. In an upcall environment, it would seem better to just note the fact that an ack is owed and upcall the user, giving him a chance to send some data. Once the user returns, you immediately invoke the tcp output routine which sends the ack plus reply data, if any. This avoids having to set a short timer, which is often hard to do efficiently in an operating system environment. Of course, the user cannot be permitted to block. Another approach is to look at the incoming PSH bit. Since PSH from the remote TCP usually means "I think my client doesn't have any more data to send for a while", you could start the acknowledgement delay timer only if PSH is clear; otherwise you would immediately return an ACK. This would have the additional advantage of allowing you to acknowledge a burst of segments with a single response. Phil Karn ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860114072549.207020%40MIT-MULTICS.ARPA] <1986011321250000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Miyata@MIT-MULTICS.ARPA Newsgroups: mod.protocols.tcp-ip Subject: IBMPC-based implementations Message-ID: <860114072549.207020@MIT-MULTICS.ARPA> Date: Tue, 14-Jan-86 02:25:00 EST Article-I.D.: MIT-MULT.860114072549.207020 Posted: Tue Jan 14 02:25:00 1986 Date-Received: Wed, 15-Jan-86 01:19:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Anyone have any experience with TCP/IP implementations for IBM-PCs (and compatibles)? If there is sufficient response, I will summarize them for the distribution. Thanks, Gaylord ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601141400.AA00253%40gyre.umd.edu] <1986011404004200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: mod.protocols.tcp-ip Subject: Re: retransmission timers in TCP Message-ID: <8601141400.AA00253@gyre.umd.edu> Date: Tue, 14-Jan-86 09:00:42 EST Article-I.D.: gyre.8601141400.AA00253 Posted: Tue Jan 14 09:00:42 1986 Date-Received: Wed, 15-Jan-86 01:19:15 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa My thanks to John Nagle for an amazingly fast response. Our telnet to TOPS-20 troubles have terminated. Three times thanks. Ta ta... Tchris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986011406495100> Received: from FORD-WDL1 by SRI-NIC.ARPA with TCP; Tue 14 Jan 86 15:01:13-PST Return-Path:<> Date: 14-Jan-86 14:49:51-PST From: jbn@FORD-WDL1 Subject: Short course on DDN to be avoided To: TCP-IP@NIC Computerworld this week has an article about the DoD protocol standards. It contains such gems as ``DOD-issued protocol standards include the following: [Sections on IP, TCP, FTP, SMTP deleted. JN] * Telenet. A terminal-handling program, GTE Telenet Communications Corp.'s Telenet was designed primarily to handle simple asynchronous terminals but will also support synchronous terminal traffic.'' CW, 13JAN86, p. 19 The author of the article, William Stallings (some DC-area consultant) is suppposedly conducting a seminar on this at the University of Maryland on 4-6 June, 1986. Surely the U of Md can come up with somebody who actually knows the subject; this guy doesn't even know what the big words mean yet. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12175233258.45.JNC%40XX.LCS.MIT.EDU] <1986011409534700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: more (possibly too many) thoughts on systems of gateawys Message-ID: <12175233258.45.JNC@XX.LCS.MIT.EDU> Date: Tue, 14-Jan-86 14:53:47 EST Article-I.D.: XX.12175233258.45.JNC Posted: Tue Jan 14 14:53:47 1986 Date-Received: Wed, 15-Jan-86 08:28:13 EST References: <8601140552.AA08518@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Chuck: Some of the issues you raise (e.g. how do hosts find dead gateways) are already covered in the RFC's Dave Clark wrote for the Internet Implementor's Guide; the one you want is the one about fault isolation. The Gateway commitee is working on an RFC about Routing in the Host IP Layer which talks about the others (e.g. finding gateways, etc.) We want to insulate the hosts as much as possible from the details of routing since we are going to be changing that, so having routing tables sent to hosts is out. Remember also that whatever mechanisms we use have to also work on nets that do not support broadcast. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601140943.AA18154%40erix.UUCP] <1986011411335400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP-request Message-ID: <8601140943.AA18154@erix.UUCP> Date: Tue, 14-Jan-86 16:33:54 EST Article-I.D.: erix.8601140943.AA18154 Posted: Tue Jan 14 16:33:54 1986 Date-Received: Wed, 15-Jan-86 08:27:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Please post the following to the net: Hello out there, we have ordered an IBM DACU to be used as a Gateway between our ethernet LAN and IBM (VM/CMS). The DACU and the VM/CMS program package supports FTP, TELNET and SMTP. I have following questions: o Does anyone have any experience in using the DACU as a Gateway to UNIX. o We are also looking for a 3270 emulator to be used in combination with telnet. Thanks in advace, Jan Andersson janne@erix.UUCP Ericsson Telecom (...!seismo!enea!erix!janne) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601150017.AA28089%40ucbvax.berkeley.edu] <1986011412495100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jbn@FORD-WDL1.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Short course on DDN to be avoided Message-ID: <8601150017.AA28089@ucbvax.berkeley.edu> Date: Tue, 14-Jan-86 17:49:51 EST Article-I.D.: ucbvax.8601150017.AA28089 Posted: Tue Jan 14 17:49:51 1986 Date-Received: Thu, 16-Jan-86 00:44:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa Computerworld this week has an article about the DoD protocol standards. It contains such gems as ``DOD-issued protocol standards include the following: [Sections on IP, TCP, FTP, SMTP deleted. JN] * Telenet. A terminal-handling program, GTE Telenet Communications Corp.'s Telenet was designed primarily to handle simple asynchronous terminals but will also support synchronous terminal traffic.'' CW, 13JAN86, p. 19 The author of the article, William Stallings (some DC-area consultant) is suppposedly conducting a seminar on this at the University of Maryland on 4-6 June, 1986. Surely the U of Md can come up with somebody who actually knows the subject; this guy doesn't even know what the big words mean yet. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601150110.AA01229%40COMET.LCS.MIT.EDU] <1986011415100400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: lixia@COMET.LCS.MIT.EDU (Lixia Zhang) Newsgroups: mod.protocols.tcp-ip Subject: Re: Short course on DDN to be avoided Message-ID: <8601150110.AA01229@COMET.LCS.MIT.EDU> Date: Tue, 14-Jan-86 20:10:04 EST Article-I.D.: COMET.8601150110.AA01229 Posted: Tue Jan 14 20:10:04 1986 Date-Received: Thu, 16-Jan-86 00:57:28 EST Sender: adrion@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa John, I'm not so sure how CW made such a joke. I happened to be the reviewer of one of Stallings' books, "Data and Computer Communications", in which the author talked both "Telenet" and "Telnet" right (though the INDEX made a mess on the two words). Lixia ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601150343.AA05178%40vax135.UUCP] <1986011417433400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Moderated newsgroup Message-ID: <8601150343.AA05178@vax135.UUCP> Date: Tue, 14-Jan-86 22:43:34 EST Article-I.D.: vax135.8601150343.AA05178 Posted: Tue Jan 14 22:43:34 1986 Date-Received: Thu, 16-Jan-86 00:57:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 166 Approved: tcp-ip@sri-nic.arpa This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site mtsol.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: mtsol!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!hropus!riccb!ihopa!ihnp4!ucbvax!tcp-ip From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: a couple of implementation issues Message-ID: <8601121945.AA19100@topaz.rutgers.edu> Date: Sun, 12-Jan-86 14:45:28 EST Article-I.D.: topaz.8601121945.AA19100 Posted: Sun Jan 12 14:45:28 1986 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 149 Approved: tcp-ip@sri-nic.arpa I would like to describe Rutgers current network configuration, and then mention some of the problems we are looking into at the moment. I would like to see whether my ideas seem reasonable to this community, and whether others have any better approaches. The major issues will involve addressing in an environment that uses a mix of Ethernet-level and IP-level gateways, and how to set up a system with redundant IP gateways so that it will survive gateway failures. First, the configuration. We have 5 Ethernets currently in operation, with several others coming on line shortly. Four of them are connected by an IP gateway built using a design from Stanford. It is a 68000 multibus system (Forward Technology SUN board), with 3Com Ethernet interfaces. The software handles PUP, IP, and XNS. It is a full PUP gateway, handling PUP directories and routing protocols. IP support is more limited, including only ARP and ICMP echo. The IP support assumes that subnetting is in use, with 8-bit host addresses and 8-bit subnet addresses. It implements the "ARP hack", so that hosts can use it even if they don't know about subnets. Stanford estimates a capacity of about 250 packets per second. However recent tweaking of the code has probably increased this. (We haven't pushed it hard enough to see this limit yet. The only limit we have seen is that Sun 3's that use NFS through the gateway have to have some non-default parameter settings. This is a known problem with the 3Com Ethernet interface, which also affects some older Sun 2's.) [For those who may be interested in duplicating this, there are now commercial equivlents of this gateway. Proteon sells one that should be fairly similar, though with higher performance and more IP support. It should handle EGP. Len Bosack from Stanford has apparently started a company that will market a re-engineered version of the Stanford gateway. You might also check Bridge Communications and DEC.] For hosts in isolated buildings, we are installing a broadband cable system. We plan to use Applitek Ethernet bridges. That is, each building will have an Ethernet. The Ethernets will be connected via the broadband cable. The Applitek bridges work at the Ethernet level. That is, they watch every packet on the Ethernet. They dynamically build a list of all machines on the local Ethernet. When they see a packet addressed to a machine that is not on the local Ethernet, they forward it to the proper Ethernet via the broadband. (Actually, there is somewhat more control available if you need it.) They forward all broadcast packets to all Ethernets. We do not yet have throughput data on it, as the system is new and is still in test. It does seem to be able to handle Sun 3 NFS transmissions with default parameter settings on the Sun. The Applitek bridges are 68000-based systems, with a fair amount of hardware in them. I'm fairly sure there is more than one 68000 in there. It uses a modern Ethernet interface, with its own processor. The broadband communications use one 6MHz channel, and can handle 10Mbits/sec. (Yes, it is possible to get more bits in a channel than its bandwidth. This has always seemed to me to violate some basic principle, but sophisticated communications technology can get more bits/sec than Hz.) Our first setup, which will probably be put in operation this week, will connect two Ethernets, one of which is also on the gateway described in the previous paragraph. [If you are in the market for one of these, other vendors that I know of with similar products are Proteon and possibly Bridge Communications. Both of these products will use IP gateways between the local Ethernet and their long-haul network. This has both advantages and disadvantages. It allows some improvements in support of TCP/IP, but it also means that you can't handle DECnet and other protocols.] The first issue is how to set up IP addresses for the Ethernets to be connected via the Applitek bridges. Initially we figured that each Ethernet would be a subnet, just like those connected by the IP gateway. However on second thought, I believe that is a mistake. Consider the following situation. subnets 6 and 7 are connected via Applitek bridge subnets 4 and 6 are connected via IP gateway a host on subnet 6 wants to talk to a host on subnet 7. The conversation will have to go through the Applitek bridge. Recall that this operates at Ethernet level. That means that the source host will have to send an Ethernet packet with the final destination's Ethernet address in it. In order to find this address, it will have to issue an ARP. If the host on 6 knows about subnets, it will consider subnet 7 to be a separate network. It will not issue an ARP to try to find the host. Rather, it will expect to find a gateway in its gateway table (or use its default gateway). With all subnet implementations that I know, there is no way to tell a host to use a gateway to talk to subnet 4, but to issue ARP's and talk directly to subnet 7. Once you turn on subnetting, it will expect to find gateways for all subnets. Obviously we could change this behavior. But we are reluctant to adopt a network design that violates the subnetting RFC's, and requires us to make kernel changes to systems that use it. Thus we reluctantly conclude that all of the Ethernets that are connected by the Applitek bridge must be considered a single subnet. I don't much like this, because I think eventually we are going to end up using IP gateways. In order to install an IP gateway between two Ethernets that are currently connected by the Applitek bridges, we would have to remove the Applitek bridge from one of them, give it a different subnet number, change the addresses of all of its hosts, and then install the IP gateway. Does anyone see something I am missing? The second issue involves gateway reliability. This is not a problem that is immediately pressing. The gateway code from Stanford is the only piece of software I have used that has never crashed. But now and then we do take it down for development work, and we do get complaints from people who are suddenly disconnected. We have several Unix systems with more than one Ethernet interface. These hosts could act as gateways. While their performance as gateways would not be as good as a dedicated 68000 gateway, they would be fine as backup gateways. The question is, how do we set things up so that a connection will move from one gateway to an alternate when the first one goes down. 4.3 has some hint of the basic ability needed. When TCP is about to time out a connection, it first tries to compute a new route. However in order for this to help, two things must be true: - the system has to know that a gateway is in use. This means that we can't use the ARP hack. We have to install subnet support on all the hosts. - something has to change in the system's routing database, or it will choose the same bad route again. This seems to imply that all of the hosts must be running routed or EGP, and that the gateways must all support it. Initially I had hoped that all of the intelligence could be put into the gateways. However this seems to be incompatible with the current design of Unix. Here's how I would do it with TOPS-20: The gateways would know about each other. They would exchange EGP, so they know if the other is up. Dual-homed hosts would know that it is better to use the dedicated gateway if it is up. So any attempt to use a dual-homed host as a gateway would result in an ICMP redirect telling the sender to try the dedicated gateway, unless the dedicated gateway is down. Here is what a normal host would do: - its gateway table would list both the dedicated gateway and the dual-homed host. (If there were losts of gateways accessible to it, only 2 or 3 would need to be listed.) - when starting a connection, if the system didn't already have a route to the destination system, it would send the packet to a randomly chosen "prime" gateway. If it chose the wrong one (e.g. a dual-homed host, when the dedicatd gateway is up), it would be directed to the right one via ICMP redirect. - it periodically pings all gateways that it knows about. If one goes down, it is marked as such, and a new route is used in the future. Since we have a mix of Unix and TOPS-20 systems, it looks like we may have to do either - add routed support to TOPS-20 or - add EGP support to Unix and TOPS-20. (This assumes that it is practical to use EGP on every host. I have a suspicion that EGP was really only intended for use between gateways.) or - add code to Unix to mark gateways as down when connections using them time out. (It is not clear quite how we would find that they are up again.) - add code to Unix so that dual-homed gateways issue ICMP redirects if they are asked to forward a packet for which they know of a better gateway Does anybody have reason to prefer one of the other approach? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D14-Jan-86.23:25:31.CERF] <1986011418250000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CERF@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Bits, Bauds and Hz Message-ID: <[USC-ISI.ARPA]14-Jan-86.23:25:31.CERF> Date: Tue, 14-Jan-86 23:25:00 EST Article-I.D.: <[USC-ISI.ARPA]14-Jan-86.23:25:31.CERF> Posted: Tue Jan 14 23:25:00 1986 Date-Received: Thu, 16-Jan-86 00:58:27 EST References: Sender: adrion@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Art, about light pipes - recent reports indicate that it is feasible to modulate light by heterodyning as in radio carriers. This is an analog method (as opposed to baseband on/off signalling) which permits much better signal to noise ratios, longer distances between repeaters, and increased total bandwidth usable in a single mode fiber which might otherwise have to use wavelength multiplexing to achieve increased capacity with multiple channels each running in digital on/off mode. Vint P.S. as for 24 telephone channels on the 1.544 Mbps T1, there are commercial compression systems out (one made by Paul Baran!) which will put up to 96 voice channels on a single 1.544 mbps T1 link. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601151600.AA00720%40cmu-andrew] <1986011505591500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong%ANDREW@PT.CS.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: re: Bits, Bauds and Hz Message-ID: <8601151600.AA00720@cmu-andrew> Date: Wed, 15-Jan-86 10:59:15 EST Article-I.D.: cmu-andr.8601151600.AA00720 Posted: Wed Jan 15 10:59:15 1986 Date-Received: Thu, 16-Jan-86 01:41:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa General Interest ..... T1 is the lowest TDM digital transmission rate used by the phone companies for long line transmission. The standard bit rates are : DS1 : 1.544M (24 voice)@* DS2 : 6.312M (4 * DS1, 96 voice)@* DS3 : 44.736M (7 * DS2, 672 voice)@* DS4 : 274.176M (6 * DS3, 4032 voice) Most DS1 or T1 data are done with twisted pairs. Fibre is normally used only for DS4 or T4 data rate which is heavily used for (real long distance) inter-citiy traffics. Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601151658.AA26221%40sdcsvax.ucsd.edu] <1986011506584200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: retransmission timers in TCP Message-ID: <8601151658.AA26221@sdcsvax.ucsd.edu> Date: Wed, 15-Jan-86 11:58:42 EST Article-I.D.: sdcsvax.8601151658.AA26221 Posted: Wed Jan 15 11:58:42 1986 Date-Received: Thu, 16-Jan-86 01:43:00 EST References: <8601141400.AA00253@gyre.umd.edu> Sender: mayo@ucbvax.BERKELEY.EDU Organization: UCSD wombat breeding society Lines: 13 Approved: tcp-ip@sri-nic.arpa We're running 4.3BSD too, and we also have problems with TOPS-20 systems. Could you please send me a copy of the note you got from John Nagle so we can fix it here too? Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 (619) 452-6865 decvax\ brian@sdcsvax.ucsd.edu ihnp4 >--- sdcsvax --- brian ucbvax/ Kantor@Nosc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601151704.AA26368%40sdcsvax.ucsd.edu] <1986011507042000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: retransmission timers in TCP Message-ID: <8601151704.AA26368@sdcsvax.ucsd.edu> Date: Wed, 15-Jan-86 12:04:20 EST Article-I.D.: sdcsvax.8601151704.AA26368 Posted: Wed Jan 15 12:04:20 1986 Date-Received: Thu, 16-Jan-86 01:49:13 EST References: <8601132139.AA21152@gyre.umd.edu> Sender: mayo@ucbvax.BERKELEY.EDU Organization: UCSD wombat breeding society Lines: 4 Approved: tcp-ip@sri-nic.arpa Whoops! Cancel that; they just arrived in the mailing list! Thanks anyway! - Brian ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12175487749.31.OLE%40SRI-NIC.ARPA] <1986011509114500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen) Newsgroups: mod.protocols.tcp-ip Subject: Implementors step forward! Message-ID: <12175487749.31.OLE@SRI-NIC.ARPA> Date: Wed, 15-Jan-86 14:11:45 EST Article-I.D.: SRI-NIC.12175487749.31.OLE Posted: Wed Jan 15 14:11:45 1986 Date-Received: Fri, 17-Jan-86 00:15:31 EST Sender: dlw@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 71 Approved: tcp-ip@sri-nic.arpa To make our TCP/IP Implementations and Vendors Guide as complete and up-to-date as possible, may I ask again that you check the current file: [SRI-NIC.ARPA]TCP-IP-IMPLEMENTATIONS.TXT. If you have (or know of) any other implementations (hardware or software), please complete and return the attached form to me (OLE@SRI-NIC.ARPA) as soon as you can. Thanks for your cooperation! Ole J Jacobsen, DDN Network Information Center. ------------------------------cut here-------------------------------- TCP/IP IMPLEMENTATIONS TEMPLATE DDN Network Information Center SRI International Menlo Park, CA 94025 PRODUCT-OR-PACKAGE-NAME: DESCRIPTION: DOCUMENTATION: CPU: (If product is a *hardware* implementation write the processor on which it is based, otherwise "CPU" means computer on which software implementation will run) O/S (OPERATING SYSTEM): IMPLEMENTATION-LANGUAGE: DISTRIBUTOR: CONTACT: ORDERING-PROCEDURE: PROPRIETY-STATUS: ------------ NOTE: This registry in no way constitutes an endorsement of any product or software package by the NIC, SRI International, or the U.S. government. It is compiled for informational purposes only. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601152153.AA04554%40BORAX.LCS.MIT.EDU] <1986011511531000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: geof@MIT-BORAX.ARPA (Geoffrey H. Cooper) Newsgroups: mod.protocols.tcp-ip Subject: Re^2: TCP Send buffer constraints destroy datarate Message-ID: <8601152153.AA04554@BORAX.LCS.MIT.EDU> Date: Wed, 15-Jan-86 16:53:10 EST Article-I.D.: BORAX.8601152153.AA04554 Posted: Wed Jan 15 16:53:10 1986 Date-Received: Fri, 17-Jan-86 00:16:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa The idea of giving the application one chance to send data before transmitting the ack is a good one, but it doesn't solve my problem entirely. Under that scheme, TCP would always send an ack for every packet received, either containing client-level data or not. I need a scheme that allows the receiver to send the minimum number of acks that will allow the sender to send at full speed. The idea of using the push bit is also a good one, but I fear that it would have the same result. This is because some TCP's almost always set the push bit, and some other TCP's never forward data to the client unless they see a push bit (which is part explaination for the sender's behavior).{_ For example, I think that 4.2 unix sends a push bit for every write call, since it has no way of knowing whether there will be more client-level data or not. This translates the push bit always being on for most connections (even bulk data connections like FTP or sending to the printer). ' Any other ideas? - Geof (PS, please continue to post replies to the net. I still don't receive incoming mail well, and rely on a usenet news feed.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601152159.AA04727%40BORAX.LCS.MIT.EDU] <1986011511594700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: geof@MIT-BORAX.ARPA (Geoffrey H. Cooper) Newsgroups: mod.protocols.tcp-ip Subject: Getting info to non-arpanauts Message-ID: <8601152159.AA04727@BORAX.LCS.MIT.EDU> Date: Wed, 15-Jan-86 16:59:47 EST Article-I.D.: BORAX.8601152159.AA04727 Posted: Wed Jan 15 16:59:47 1986 Date-Received: Fri, 17-Jan-86 00:16:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Noel Chiappa expressed a concern about getting information to non-arpanet subscribers about current ideas from the mainstream tcp world. I think that his idea of using usenet is a great one. The TCP-IP list is carried on usenet as mod.protocols.tcp-ip. I don't know exactly how this forwarding is set up (since mod.... means that it is supposed to be a moderated list, and I didn't think that the arpanet one was moderated), but it would be a great boon to those of us who mostly (or entirely) rely on UUCP links if RFC's were automatically fed down the pipe. We might avoid sending very long ones (>60 pages or so) for evfficiency reasons. [Please respond to the list, since incoming mail is flakey for me theseedays] - Geof Cooper Imagen ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12175709705.59.HEDRICK%40RED.RUTGERS.EDU] <1986011605305900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: gateway speed Message-ID: <12175709705.59.HEDRICK@RED.RUTGERS.EDU> Date: Thu, 16-Jan-86 10:30:59 EST Article-I.D.: RED.12175709705.59.HEDRICK Posted: Thu Jan 16 10:30:59 1986 Date-Received: Fri, 17-Jan-86 01:20:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Bill Yeager at Sumex has asked me to correct a miss-statement in a previous note. I said that our 68000 gateway, constructed using plans from Stanford, could handle at least 250 packets per sec. Bill tells me the real number is 500+ per second. They routinely experience 300 packets per second in gateways connected to 3 networks. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986011608520000> Received: from STL-HOST1.ARPA by SRI-NIC.ARPA with TCP; Thu 16 Jan 86 12:52:11-PST Date: 16 Jan 1986 14:52-CST Sender: HARMAN@STL-HOST1.ARPA Subject: Re: Short course on DDN to be avoided From: HARMAN@STL-HOST1.ARPA To: jbn@FORD-WDL1.ARPA Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[STL-HOST1.ARPA]16-Jan-86 14:52:18.HARMAN> In-Reply-To: Request future traffic on this subject be routed to DELHD-MI at STL-HOST1. This will expedite delivery. Regards, Dick Harman ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601170037.AA16894%40ucbvax.berkeley.edu] <1986011610072600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: cassel@DEWEY.UDEL.EDU (Boots Cassel) Newsgroups: mod.protocols.tcp-ip Subject: Tech Report Message-ID: <8601170037.AA16894@ucbvax.berkeley.edu> Date: Thu, 16-Jan-86 15:07:26 EST Article-I.D.: ucbvax.8601170037.AA16894 Posted: Thu Jan 16 15:07:26 1986 Date-Received: Sat, 18-Jan-86 00:58:44 EST Sender: serge@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa University of Delaware Department of Computer and Information Sciences Technical Report 86-12 Local Area Broadcast Network Measurement: Traffic Characterization by Paul D. Amer Ram N. Kumar Rueybin Kao Jeffrey T. Phillips Lillian N. Cassel Abstract Eight weeks of traffic were monitored on an Ethernet with five major hosts and interconnections to another LAN and the ARPAnet. Over 104.7 million packets consisting of 10+ billion octets were observed. This paper characterizes the monitored traffic and concludes for our LAN that the overall arrival of packets on the Ethernet is not Poisson as often assumed in analytic studies, the bit error rate is low with periodic bursts caused by faulty hardware and software, the network load is, as expected, bursty in nature, the packet size distribution is not bimodal (as observed in other studies), most of the traffic is generated by network servers (terminal switches), and less than 10% of the traffic travels outside the local network. Key words and phrases: broadcast network, CSMA/CD, Ethernet, local area network, measurement center, performance evaluation, traffic characterization, workload characterization. The technical report is now available. Anyone who would like a copy of the tech report should send name and address to Boots Cassel cassel@dewey.udel.EDU or Department of Computer and Information Sciences University of Delaware Newark, DE 19716 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986011610072601> Received: from Dewey.UDEL.EDU by SRI-NIC.ARPA with TCP; Thu 16 Jan 86 14:19:14-PST Date: Thu, 16 Jan 86 15:07:26 EST From: Boots Cassel To: tcp-ip@dewey.udel.EDU, trlist@dewey.udel.EDU cc: cassel@dewey.udel.EDU, phillips@dewey.udel.EDU, rkao@dewey.udel.EDU, amer@dewey.udel.EDU, hokuf@dewey.udel.EDU Subject: Tech Report University of Delaware Department of Computer and Information Sciences Technical Report 86-12 Local Area Broadcast Network Measurement: Traffic Characterization by Paul D. Amer Ram N. Kumar Rueybin Kao Jeffrey T. Phillips Lillian N. Cassel Abstract Eight weeks of traffic were monitored on an Ethernet with five major hosts and interconnections to another LAN and the ARPAnet. Over 104.7 million packets consisting of 10+ billion octets were observed. This paper characterizes the monitored traffic and concludes for our LAN that the overall arrival of packets on the Ethernet is not Poisson as often assumed in analytic studies, the bit error rate is low with periodic bursts caused by faulty hardware and software, the network load is, as expected, bursty in nature, the packet size distribution is not bimodal (as observed in other studies), most of the traffic is generated by network servers (terminal switches), and less than 10% of the traffic travels outside the local network. Key words and phrases: broadcast network, CSMA/CD, Ethernet, local area network, measurement center, performance evaluation, traffic characterization, workload characterization. The technical report is now available. Anyone who would like a copy of the tech report should send name and address to Boots Cassel cassel@dewey.udel.EDU or Department of Computer and Information Sciences University of Delaware Newark, DE 19716 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601162028.AA21042%40tikal.Teltone] <1986011610281900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: IBMPC-based implementations Message-ID: <8601162028.AA21042@tikal.Teltone> Date: Thu, 16-Jan-86 15:28:19 EST Article-I.D.: tikal.8601162028.AA21042 Posted: Thu Jan 16 15:28:19 1986 Date-Received: Sat, 18-Jan-86 01:19:22 EST References: <860114072549.207020@MIT-MULTICS.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: Teltone Corp., Kirkland, WA Lines: 26 Approved: tcp-ip@sri-nic.arpa In article <860114072549.207020@MIT-MULTICS.ARPA> you write: >Anyone have any experience with TCP/IP implementations for IBM-PCs (and >compatibles)? If there is sufficient response, I will summarize them >for the distribution. > >Thanks, >Gaylord I have used the MIT PC/IP package with some degree of success. I have largely quit using it, however, in favor of serial protocols like Kermit because of various problems like: 1. Can't upload a file unless it already exists. 2. Can't upload a file unless it is accessible by everyone. 3. Occasional bit errors. What I would really like is rcp, rsh, and rlogin on a PC. Let me know if you find such. -- Thomas N. Anderson ...uw-beaver!teltone!tna Teltone Corporation, 10801 120th Ave NE, Kirkland, WA 98033 (206) 827-9626 "This Statement is False." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BSTL-HOST1.ARPA%5D16-Jan-86.14:52:18.HARMAN] <1986011610520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HARMAN@STL-HOST1.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Short course on DDN to be avoided Message-ID: <[STL-HOST1.ARPA]16-Jan-86.14:52:18.HARMAN> Date: Thu, 16-Jan-86 15:52:00 EST Article-I.D.: <[STL-HOST1.ARPA]16-Jan-86.14:52:18.HARMAN> Posted: Thu Jan 16 15:52:00 1986 Date-Received: Sat, 18-Jan-86 00:55:46 EST References: Sender: mayo@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa Request future traffic on this subject be routed to DELHD-MI at STL-HOST1. This will expedite delivery. Regards, Dick Harman ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12175783367.9.HAAS%40UTAH-20.ARPA] <1986011612153700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Haas@UTAH-20.ARPA (Walt) Newsgroups: mod.protocols.tcp-ip Subject: SYN with a window size of zero Message-ID: <12175783367.9.HAAS@UTAH-20.ARPA> Date: Thu, 16-Jan-86 17:15:37 EST Article-I.D.: UTAH-20.12175783367.9.HAAS Posted: Thu Jan 16 17:15:37 1986 Date-Received: Sat, 18-Jan-86 00:57:06 EST Sender: dlw@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa One of our TCP implementations (TOPS-20) opens a TCP connection with a segment that contains the usual SYN and a window size of zero. According to one interpretation of the spec there should be no legal response to such a segment since the normal response is SYN+ACK and the SYN in the response would take up sequence number space, which does not exist according to the sender of the first segment. According to another intepretation, the window size refers to data octets only, and the sequence number space taken by SYNs and FINs shouldn't count. Various implementations handle this in various ways - some apparantly assume that it's silly to send SYN with a window size of zero, and just go ahead and reply with SYN+ACK. One implementation appears to go into a tight loop in this situation. Does anybody have any references that would resolve the apparent ambiguity? It isn't clear to me how to apply the robustness principle to this case - one could imagine that an implementation could have an unusual situation where it needed to open a connection but didn't at the moment have any place to put a reply. Thanks in advance for any helpful comments -- Walt ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12175794440.27.DP4Q%40TE.CC.CMU.EDU] <1986011613162700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: DP4Q@TE.CC.CMU.EDU (Drew D. Perkins) Newsgroups: mod.protocols.tcp-ip Subject: Excelan tcp-ip on VMS Message-ID: <12175794440.27.DP4Q@TE.CC.CMU.EDU> Date: Thu, 16-Jan-86 18:16:27 EST Article-I.D.: TE.12175794440.27.DP4Q Posted: Thu Jan 16 18:16:27 1986 Date-Received: Sat, 18-Jan-86 01:19:58 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa We're thinking about getting a few of the Excelan TCP/IP boards/software for our 11/780's running VMS. I remember a few problems mentioned about their products before, but don't have that mail to refer back to now. What are peoples experiences with Excelan, and mostly with the current revision of their software EXOS 8043 3.2? Also, are there any archives of tcp-ip mail around? On another note, by this summer everyone at CMU will have the capability of having a dedicated 56k bps link from their homes back to CMU, if they live in one of the surrounding areas nearby. This service is going to be provided cheaply by the local telephone company. We'd like to be able use these links to extend our IP network from campus to users workstations at home. Is there any standard for IP communications over synchronous links? Does anyone know of a company that makes boards (preferable multibus) that have 8 or so syncronous links that go this speed? Hopefully the board should be capable of sending and receiving packets at a time in order for the gateway to handle the traffic. Something on the order of a Zilog SCC chip per link. Is anything like this being done anywhere else? Drew ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601162352.AA22028%40sdcsvax.ucsd.edu] <1986011613521000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Getting info to non-arpanauts Message-ID: <8601162352.AA22028@sdcsvax.ucsd.edu> Date: Thu, 16-Jan-86 18:52:10 EST Article-I.D.: sdcsvax.8601162352.AA22028 Posted: Thu Jan 16 18:52:10 1986 Date-Received: Sat, 18-Jan-86 01:20:33 EST References: <8601152159.AA04727@BORAX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: UCSD wombat breeding society Lines: 19 Approved: tcp-ip@sri-nic.arpa A year or two ago I posted copies of the IP, ICMP, TCP, UDP, TELNET, and FTP RFCs, as well as a few other ones like RFC822, to the USENET net.sources group (which is where big things like that get posted). It may be time to do that again. I'll confer with the moderator of the USENET mod.sources group to see what he thinks, and if he approves, this will be a reasonable way to spread the gospel. Wouldn't be too bad an idea if Berkeley would include some of these with their distribution tape either. They already send RFC822 (I think) with it so people will understand the 'sendmail' program better. Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 (619) 452-6865 decvax\ brian@sdcsvax.ucsd.edu ihnp4 >--- sdcsvax --- brian ucbvax/ Kantor@Nosc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D16-Jan-86.21:44:33.CERF] <1986011616440000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CERF@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: SYN with a window size of zero Message-ID: <[USC-ISI.ARPA]16-Jan-86.21:44:33.CERF> Date: Thu, 16-Jan-86 21:44:00 EST Article-I.D.: <[USC-ISI.ARPA]16-Jan-86.21:44:33.CERF> Posted: Thu Jan 16 21:44:00 1986 Date-Received: Sat, 18-Jan-86 01:21:38 EST References: <12175783367.9.HAAS@UTAH-20.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Walt, since one could not successfully "open" a connection without getting the matching SYN-ACK, it seems appropriate for the recipient of such a packet to respond, despite the apparent violation. As you know, it is allowed to send at least one octet into a closed (0) window to assure that when it opens you hear that. The SYN can safely elicit an ACK without opening the window any further. Depending on the implementation, some systems don't apply the window size until AFTER the connection has reached the OPEN state which it cannot get to without first exchanging SYN-ACKs. Jon Postel will undoubtedly have a reference to page xx para gg and sugestion to look in one of Dave Clark's marvelous tutorial sections... Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601170721.AA28467%40vax135.UUCP] <1986011621213600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Moderated newsgroup Message-ID: <8601170721.AA28467@vax135.UUCP> Date: Fri, 17-Jan-86 02:21:36 EST Article-I.D.: vax135.8601170721.AA28467 Posted: Fri Jan 17 02:21:36 1986 Date-Received: Sat, 18-Jan-86 01:26:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 38 Approved: tcp-ip@sri-nic.arpa This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site solar.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip From: jbn@FORD-WDL1.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Short course on DDN to be avoided Message-ID: <8601150017.AA28089@ucbvax.berkeley.edu> Date: Tue, 14-Jan-86 17:49:51 EST Article-I.D.: ucbvax.8601150017.AA28089 Posted: Tue Jan 14 17:49:51 1986 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa Computerworld this week has an article about the DoD protocol standards. It contains such gems as ``DOD-issued protocol standards include the following: [Sections on IP, TCP, FTP, SMTP deleted. JN] * Telenet. A terminal-handling program, GTE Telenet Communications Corp.'s Telenet was designed primarily to handle simple asynchronous terminals but will also support synchronous terminal traffic.'' CW, 13JAN86, p. 19 The author of the article, William Stallings (some DC-area consultant) is suppposedly conducting a seminar on this at the University of Maryland on 4-6 June, 1986. Surely the U of Md can come up with somebody who actually knows the subject; this guy doesn't even know what the big words mean yet. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601170722.AA28532%40vax135.UUCP] <1986011621224200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Moderated newsgroup Message-ID: <8601170722.AA28532@vax135.UUCP> Date: Fri, 17-Jan-86 02:22:42 EST Article-I.D.: vax135.8601170722.AA28532 Posted: Fri Jan 17 02:22:42 1986 Date-Received: Sat, 18-Jan-86 11:14:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 63 Approved: tcp-ip@sri-nic.arpa This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site solar.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip From: jbn@FORD-WDL1.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: retransmission timers in TCP Message-ID: <8601150355.AA01040@ucbvax.berkeley.edu> Date: Thu, 9-Jan-86 21:06:52 EST Article-I.D.: ucbvax.8601150355.AA01040 Posted: Thu Jan 9 21:06:52 1986 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 46 Approved: tcp-ip@sri-nic.arpa I had to go into 4.3BSD recently and fix a few bugs here, so I'll document how 4.3BSD does it, for the benefit of the community. John Nagle The algorithm in 4.3BSD works as follows: 1. Round trip times are computed for one packet at a time. Only packets containing data and which are not being retransmitted contribute to the round-trip time calculation. The timer starts when a data packet is transmitted and no other packet is being timed, and stops when an ACK covers the sequence number of the packet being timed. 2. There is a smoothed round-trip timer. Its value is initially 0 and is a smoothed running average of past round-trip times. It is updated at the completion of each successful timing, as described above. The formula is const = 0.1 srtt = srtt * (1-const) + lastrtt * const; This is actually computed in floating point. On the first round-trip, srtt is simply set to lastrtt. The result is then forced into the range 1 to 30 seconds. [It's possible to use the 0 value if there is no good round-trip before the first retransmit. This is a bug; see net.bugs.4bsd for a fix.] 3. The initial retransmit interval is 2*srtt. A backoff algorithm then applies. The standard algorithm is table-driven, and has a table of constants beginning 1.0, 1.2, etc. These are applied using the number of the retransmit as an index as multipliers to srtt. There is an alternate algorithm available by patching a flag, which uses srtt*(2^retransmitnumber) as the retransmit interval. [There's a bug here; there is a multiply by tcp-beta (=2.0) missing in one spot, and the time between the first and second retransmit is shorter than between the original and the first. Again, see net.bugs.4bsd for a fix.] We prefer the alternate algorithm, which backs off faster. Without the fixes, by the way, things are not good when the round-trip time on the net actually exceeds one second. JN ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601170723.AA28555%40vax135.UUCP] <1986011621231700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Moderated newsgroup Message-ID: <8601170723.AA28555@vax135.UUCP> Date: Fri, 17-Jan-86 02:23:17 EST Article-I.D.: vax135.8601170723.AA28555 Posted: Fri Jan 17 02:23:17 1986 Date-Received: Sat, 18-Jan-86 11:12:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site solar.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip From: lixia@COMET.LCS.MIT.EDU (Lixia Zhang) Newsgroups: mod.protocols.tcp-ip Subject: Re: Short course on DDN to be avoided Message-ID: <8601150110.AA01229@COMET.LCS.MIT.EDU> Date: Tue, 14-Jan-86 20:10:04 EST Article-I.D.: COMET.8601150110.AA01229 Posted: Tue Jan 14 20:10:04 1986 Sender: adrion@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa John, I'm not so sure how CW made such a joke. I happened to be the reviewer of one of Stallings' books, "Data and Computer Communications", in which the author talked both "Telenet" and "Telnet" right (though the INDEX made a mess on the two words). Lixia ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601170727.AA28701%40vax135.UUCP] <1986011621275200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Moderated newsgroup Message-ID: <8601170727.AA28701@vax135.UUCP> Date: Fri, 17-Jan-86 02:27:52 EST Article-I.D.: vax135.8601170727.AA28701 Posted: Fri Jan 17 02:27:52 1986 Date-Received: Sat, 18-Jan-86 11:15:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 183 Approved: tcp-ip@sri-nic.arpa This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site solar.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Moderated newsgroup Message-ID: <8601150343.AA05178@vax135.UUCP> Date: Tue, 14-Jan-86 22:43:34 EST Article-I.D.: vax135.8601150343.AA05178 Posted: Tue Jan 14 22:43:34 1986 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 166 Approved: tcp-ip@sri-nic.arpa This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site mtsol.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: mtsol!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!hropus!riccb!ihopa!ihnp4!ucbvax!tcp-ip From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: a couple of implementation issues Message-ID: <8601121945.AA19100@topaz.rutgers.edu> Date: Sun, 12-Jan-86 14:45:28 EST Article-I.D.: topaz.8601121945.AA19100 Posted: Sun Jan 12 14:45:28 1986 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 149 Approved: tcp-ip@sri-nic.arpa I would like to describe Rutgers current network configuration, and then mention some of the problems we are looking into at the moment. I would like to see whether my ideas seem reasonable to this community, and whether others have any better approaches. The major issues will involve addressing in an environment that uses a mix of Ethernet-level and IP-level gateways, and how to set up a system with redundant IP gateways so that it will survive gateway failures. First, the configuration. We have 5 Ethernets currently in operation, with several others coming on line shortly. Four of them are connected by an IP gateway built using a design from Stanford. It is a 68000 multibus system (Forward Technology SUN board), with 3Com Ethernet interfaces. The software handles PUP, IP, and XNS. It is a full PUP gateway, handling PUP directories and routing protocols. IP support is more limited, including only ARP and ICMP echo. The IP support assumes that subnetting is in use, with 8-bit host addresses and 8-bit subnet addresses. It implements the "ARP hack", so that hosts can use it even if they don't know about subnets. Stanford estimates a capacity of about 250 packets per second. However recent tweaking of the code has probably increased this. (We haven't pushed it hard enough to see this limit yet. The only limit we have seen is that Sun 3's that use NFS through the gateway have to have some non-default parameter settings. This is a known problem with the 3Com Ethernet interface, which also affects some older Sun 2's.) [For those who may be interested in duplicating this, there are now commercial equivlents of this gateway. Proteon sells one that should be fairly similar, though with higher performance and more IP support. It should handle EGP. Len Bosack from Stanford has apparently started a company that will market a re-engineered version of the Stanford gateway. You might also check Bridge Communications and DEC.] For hosts in isolated buildings, we are installing a broadband cable system. We plan to use Applitek Ethernet bridges. That is, each building will have an Ethernet. The Ethernets will be connected via the broadband cable. The Applitek bridges work at the Ethernet level. That is, they watch every packet on the Ethernet. They dynamically build a list of all machines on the local Ethernet. When they see a packet addressed to a machine that is not on the local Ethernet, they forward it to the proper Ethernet via the broadband. (Actually, there is somewhat more control available if you need it.) They forward all broadcast packets to all Ethernets. We do not yet have throughput data on it, as the system is new and is still in test. It does seem to be able to handle Sun 3 NFS transmissions with default parameter settings on the Sun. The Applitek bridges are 68000-based systems, with a fair amount of hardware in them. I'm fairly sure there is more than one 68000 in there. It uses a modern Ethernet interface, with its own processor. The broadband communications use one 6MHz channel, and can handle 10Mbits/sec. (Yes, it is possible to get more bits in a channel than its bandwidth. This has always seemed to me to violate some basic principle, but sophisticated communications technology can get more bits/sec than Hz.) Our first setup, which will probably be put in operation this week, will connect two Ethernets, one of which is also on the gateway described in the previous paragraph. [If you are in the market for one of these, other vendors that I know of with similar products are Proteon and possibly Bridge Communications. Both of these products will use IP gateways between the local Ethernet and their long-haul network. This has both advantages and disadvantages. It allows some improvements in support of TCP/IP, but it also means that you can't handle DECnet and other protocols.] The first issue is how to set up IP addresses for the Ethernets to be connected via the Applitek bridges. Initially we figured that each Ethernet would be a subnet, just like those connected by the IP gateway. However on second thought, I believe that is a mistake. Consider the following situation. subnets 6 and 7 are connected via Applitek bridge subnets 4 and 6 are connected via IP gateway a host on subnet 6 wants to talk to a host on subnet 7. The conversation will have to go through the Applitek bridge. Recall that this operates at Ethernet level. That means that the source host will have to send an Ethernet packet with the final destination's Ethernet address in it. In order to find this address, it will have to issue an ARP. If the host on 6 knows about subnets, it will consider subnet 7 to be a separate network. It will not issue an ARP to try to find the host. Rather, it will expect to find a gateway in its gateway table (or use its default gateway). With all subnet implementations that I know, there is no way to tell a host to use a gateway to talk to subnet 4, but to issue ARP's and talk directly to subnet 7. Once you turn on subnetting, it will expect to find gateways for all subnets. Obviously we could change this behavior. But we are reluctant to adopt a network design that violates the subnetting RFC's, and requires us to make kernel changes to systems that use it. Thus we reluctantly conclude that all of the Ethernets that are connected by the Applitek bridge must be considered a single subnet. I don't much like this, because I think eventually we are going to end up using IP gateways. In order to install an IP gateway between two Ethernets that are currently connected by the Applitek bridges, we would have to remove the Applitek bridge from one of them, give it a different subnet number, change the addresses of all of its hosts, and then install the IP gateway. Does anyone see something I am missing? The second issue involves gateway reliability. This is not a problem that is immediately pressing. The gateway code from Stanford is the only piece of software I have used that has never crashed. But now and then we do take it down for development work, and we do get complaints from people who are suddenly disconnected. We have several Unix systems with more than one Ethernet interface. These hosts could act as gateways. While their performance as gateways would not be as good as a dedicated 68000 gateway, they would be fine as backup gateways. The question is, how do we set things up so that a connection will move from one gateway to an alternate when the first one goes down. 4.3 has some hint of the basic ability needed. When TCP is about to time out a connection, it first tries to compute a new route. However in order for this to help, two things must be true: - the system has to know that a gateway is in use. This means that we can't use the ARP hack. We have to install subnet support on all the hosts. - something has to change in the system's routing database, or it will choose the same bad route again. This seems to imply that all of the hosts must be running routed or EGP, and that the gateways must all support it. Initially I had hoped that all of the intelligence could be put into the gateways. However this seems to be incompatible with the current design of Unix. Here's how I would do it with TOPS-20: The gateways would know about each other. They would exchange EGP, so they know if the other is up. Dual-homed hosts would know that it is better to use the dedicated gateway if it is up. So any attempt to use a dual-homed host as a gateway would result in an ICMP redirect telling the sender to try the dedicated gateway, unless the dedicated gateway is down. Here is what a normal host would do: - its gateway table would list both the dedicated gateway and the dual-homed host. (If there were losts of gateways accessible to it, only 2 or 3 would need to be listed.) - when starting a connection, if the system didn't already have a route to the destination system, it would send the packet to a randomly chosen "prime" gateway. If it chose the wrong one (e.g. a dual-homed host, when the dedicatd gateway is up), it would be directed to the right one via ICMP redirect. - it periodically pings all gateways that it knows about. If one goes down, it is marked as such, and a new route is used in the future. Since we have a mix of Unix and TOPS-20 systems, it looks like we may have to do either - add routed support to TOPS-20 or - add EGP support to Unix and TOPS-20. (This assumes that it is practical to use EGP on every host. I have a suspicion that EGP was really only intended for use between gateways.) or - add code to Unix to mark gateways as down when connections using them time out. (It is not clear quite how we would find that they are up again.) - add code to Unix so that dual-homed gateways issue ICMP redirects if they are asked to forward a packet for which they know of a better gateway Does anybody have reason to prefer one of the other approach? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601170728.AA28727%40vax135.UUCP] <1986011621282300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Moderated newsgroup Message-ID: <8601170728.AA28727@vax135.UUCP> Date: Fri, 17-Jan-86 02:28:23 EST Article-I.D.: vax135.8601170728.AA28727 Posted: Fri Jan 17 02:28:23 1986 Date-Received: Sat, 18-Jan-86 11:10:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 33 Approved: tcp-ip@sri-nic.arpa This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site solar.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!tcp-ip From: CERF@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Bits, Bauds and Hz Message-ID: <[USC-ISI.ARPA]14-Jan-86.23:25:31.CERF> Date: Tue, 14-Jan-86 23:25:00 EST Article-I.D.: <[USC-ISI.ARPA]14-Jan-86.23:25:31.CERF> Posted: Tue Jan 14 23:25:00 1986 References: Sender: adrion@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Art, about light pipes - recent reports indicate that it is feasible to modulate light by heterodyning as in radio carriers. This is an analog method (as opposed to baseband on/off signalling) which permits much better signal to noise ratios, longer distances between repeaters, and increased total bandwidth usable in a single mode fiber which might otherwise have to use wavelength multiplexing to achieve increased capacity with multiple channels each running in digital on/off mode. Vint P.S. as for 24 telephone channels on the 1.544 Mbps T1, there are commercial compression systems out (one made by Paul Baran!) which will put up to 96 voice channels on a single 1.544 mbps T1 link. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12175956263.13.MRC%40SIMTEL20.ARPA] <1986011704052200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MRC@SIMTEL20.ARPA (Mark Crispin) Newsgroups: mod.protocols.tcp-ip Subject: IP over synchronous links Message-ID: <12175956263.13.MRC@SIMTEL20.ARPA> Date: Fri, 17-Jan-86 09:05:22 EST Article-I.D.: SIMTEL20.12175956263.13.MRC Posted: Fri Jan 17 09:05:22 1986 Date-Received: Sat, 18-Jan-86 11:19:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa I too am interested in this. I have a 2020 with a KMC11/DUP11 (a.k.a. KDP or DN20-BA) low-speed synchronous interface. I think the KMC11 microcode does some DDCMP handling; I don't have sources for it. So I guess the real question is if there is a de facto standard for IP over a KDP that is nominally microcoded for DECnet? Has anybody successfully used TCP/IP over a 1200 baud link? Is it at all effective at such a low speed? I already have TELNET and reliable file transfer and mail connectivity with "Dialnet" and various tools (e.g. Kermit). I'm somewhat worried that TCP/IP at such a slow speed would introduce enough overhead to reduce my connectivity over "Dialnet", in which case I might want to hold off until I get a faster modem. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986011709081700> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 17 Jan 86 17:10:54-PST Date: 17 Jan 1986 17:08:17 PST Subject: mod.protocols.tcp-ip From: Dan Lynch To: tcp-ip@SRI-NIC.ARPA cc: LYNCH@USC-ISIB.ARPA Some thing has gone bonzo and is sending "rejection slips" to all of us in the TCP-IP mailing list reflected off of SRI-NIC. It is coming from the bowels of Berkeley. I doubt each of us needs to see each message twice along with a canned tougue lashing that is entirely inappropriate. This just started happening so would the person who caused it to start cause it to stop? Many thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601180340.AA27044%40ucbvax.berkeley.edu] <1986011715081700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: LYNCH@USC-ISIB.ARPA (Dan Lynch) Newsgroups: mod.protocols.tcp-ip Subject: mod.protocols.tcp-ip Message-ID: <8601180340.AA27044@ucbvax.berkeley.edu> Date: Fri, 17-Jan-86 20:08:17 EST Article-I.D.: ucbvax.8601180340.AA27044 Posted: Fri Jan 17 20:08:17 1986 Date-Received: Sat, 18-Jan-86 11:22:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Some thing has gone bonzo and is sending "rejection slips" to all of us in the TCP-IP mailing list reflected off of SRI-NIC. It is coming from the bowels of Berkeley. I doubt each of us needs to see each message twice along with a canned tougue lashing that is entirely inappropriate. This just started happening so would the person who caused it to start cause it to stop? Many thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601190004.AA13547%40ucbvax.berkeley.edu] <1986011716581800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: bzs@BOSTONU.CSNET (Barry Shein) Newsgroups: mod.protocols.tcp-ip Subject: Re: IBMPC-based implementations Message-ID: <8601190004.AA13547@ucbvax.berkeley.edu> Date: Fri, 17-Jan-86 21:58:18 EST Article-I.D.: ucbvax.8601190004.AA13547 Posted: Fri Jan 17 21:58:18 1986 Date-Received: Sun, 19-Jan-86 05:42:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa >I have used the MIT PC/IP package with some degree of success. I have >largely quit using it, however, in favor of serial protocols like Kermit >because of various problems like: > > 1. Can't upload a file unless it already exists. > 2. Can't upload a file unless it is accessible by everyone. > 3. Occasional bit errors. > >What I would really like is rcp, rsh, and rlogin on a PC. Let me >know if you find such. >Thomas N. Anderson ...uw-beaver!teltone!tna Obviously your problem is not really PC/IP but the way TFTP works. A while back I modified our 4.2bsd TFTP to add the following capability: On a WRQ or a RRQ if there are strings past the mode they are assumed to be a login-name/password to be used, the fork from the server changes to that person's home directory and sets itself to be that user (setuid/setgid in UNIX.) Otherwise the default rules apply. For example: RRQ thesis/chapter1\0netascii\0bzs\0passwd\0 (where \0 means a null byte) I needed this because we had lisp machines and my own IP/UDP/TFTP implementations for the 3B2 and the mentioned restrictions would be, well, too restrictive for use, they didn't have TCP. It's all backwards compatible, if I were you I would consider this with your administration (there are security problems but they are worse in my opinion the old way, in fact my server currently *demands* a legal login/password, I just wouldn't run it at all without the addition.) It requires a few minor changes to server and client, I would suggest it (is this too far out of spec to be accepted? I think TFTP is almost useless w/o it for the user these days. The TFTP RFC also mentions that extensions are appreciated, here's one...[I realize diskless nodes are using TFTP to boot, that's a slightly different issue but manageable.]) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986011716581801> Mail-From: VIVIAN created at 18-Jan-86 15:25:36 Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Sat 18 Jan 86 10:43:11-PST Received: from bostonu by csnet-relay.csnet id ag12072; 18 Jan 86 13:38 EST Received: by bu-cs.ARPA (4.12/4.7) id AA00915; Fri, 17 Jan 86 21:58:18 est Date: Fri, 17 Jan 86 21:58:18 est From: Barry Shein To: tcp-ip@sri-nic.csnet Subject: Re: IBMPC-based implementations ReSent-Date: Sat 18 Jan 86 15:25:36-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12176320394.18.VIVIAN@SRI-NIC.ARPA> >I have used the MIT PC/IP package with some degree of success. I have >largely quit using it, however, in favor of serial protocols like Kermit >because of various problems like: > > 1. Can't upload a file unless it already exists. > 2. Can't upload a file unless it is accessible by everyone. > 3. Occasional bit errors. > >What I would really like is rcp, rsh, and rlogin on a PC. Let me >know if you find such. >Thomas N. Anderson ...uw-beaver!teltone!tna Obviously your problem is not really PC/IP but the way TFTP works. A while back I modified our 4.2bsd TFTP to add the following capability: On a WRQ or a RRQ if there are strings past the mode they are assumed to be a login-name/password to be used, the fork from the server changes to that person's home directory and sets itself to be that user (setuid/setgid in UNIX.) Otherwise the default rules apply. For example: RRQ thesis/chapter1\0netascii\0bzs\0passwd\0 (where \0 means a null byte) I needed this because we had lisp machines and my own IP/UDP/TFTP implementations for the 3B2 and the mentioned restrictions would be, well, too restrictive for use, they didn't have TCP. It's all backwards compatible, if I were you I would consider this with your administration (there are security problems but they are worse in my opinion the old way, in fact my server currently *demands* a legal login/password, I just wouldn't run it at all without the addition.) It requires a few minor changes to server and client, I would suggest it (is this too far out of spec to be accepted? I think TFTP is almost useless w/o it for the user these days. The TFTP RFC also mentions that extensions are appreciated, here's one...[I realize diskless nodes are using TFTP to boot, that's a slightly different issue but manageable.]) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12176159649.11.LEPREAU%40UTAH-20.ARPA] <1986011722423600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Lepreau@UTAH-20.ARPA (Jay Lepreau) Newsgroups: mod.protocols.tcp-ip Subject: Re: SYN with a window size of zero Message-ID: <12176159649.11.LEPREAU@UTAH-20.ARPA> Date: Sat, 18-Jan-86 03:42:36 EST Article-I.D.: UTAH-20.12176159649.11.LEPREAU Posted: Sat Jan 18 03:42:36 1986 Date-Received: Sun, 19-Jan-86 05:42:22 EST References: <[USC-ISI.ARPA]16-Jan-86.21:44:33.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa This recently came up in another context: the TAC's put garbage in the window field in their initial SYN, all the way up to 64K. This raised havoc with some of our hosts which remembered the max window size they'd ever seen. I talked to the TAC folks at BBN who maintained that since the window is only defined relative to the ack seq number, the window is meaningless unless ACK is set, and therefore it's not their bug, it's ours. Sounds plausible, so we fixed it here. (A zero initial window is quite good behavior, in contrast with the TAC's, which are clearly violating the robustness principle.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12176319824.18.VIVIAN%40SRI-NIC.ARPA] <1986011813222800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Vivian@SRI-NIC.ARPA (Vivian Neou) Newsgroups: mod.protocols.tcp-ip Subject: TCP-IP mailing list Message-ID: <12176319824.18.VIVIAN@SRI-NIC.ARPA> Date: Sat, 18-Jan-86 18:22:28 EST Article-I.D.: SRI-NIC.12176319824.18.VIVIAN Posted: Sat Jan 18 18:22:28 1986 Date-Received: Sun, 19-Jan-86 05:42:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Until I can figure out which address is causing the rebroadcast of the list to itself, I will be hand filtering the messages to this list. Vivian Neou ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601210125.AA01159%40ucbvax.berkeley.edu] <1986011911065600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: IP over synchronous links Message-ID: <8601210125.AA01159@ucbvax.berkeley.edu> Date: Sun, 19-Jan-86 16:06:56 EST Article-I.D.: ucbvax.8601210125.AA01159 Posted: Sun Jan 19 16:06:56 1986 Date-Received: Wed, 22-Jan-86 00:26:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa In response to the message sent Fri 17 Jan 86 07:05:22-MST from MRC@SIMTEL20.ARPA Mark, I know of several ad-hoc synchronous gizmos used to pipe IP grams from one host/gateway to another, including one suggested in RFC-892 which has been used for several years around here. However, we have found DDCMP most popular, primarily because DMA hardware is readily available for the PDP11 (DMV11 for the Q bus). The U Michigan folk also have a nifty interface board for the Q bus that runs LAPB. I suspect several other folk have done similar things. TCP/IP is completely reasonable with most (but not all) implementations known to me at 1200 bps. In fact, I have used these protocols over amateur AX.25 packet-radio links at 1200 bps when one packet in four died. However, some famous TCP implementations croak dismally via such paths, especially when the implementor has not read RFC-889. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8601210140.AA01412%40ucbvax.berkeley.edu] <1986011918581400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcs@USNA.ARPA (Terry Slattery) Newsgroups: mod.protocols.tcp-ip Subject: Excelan tcp-ip on VMS Message-ID: <8601210140.AA01412@ucbvax.berkeley.edu> Date: Sun, 19-Jan-86 23:58:14 EST Article-I.D.: ucbvax.8601210140.AA01412 Posted: Sun Jan 19 23:58:14 1986 Date-Received: Wed, 22-Jan-86 00:26:51 EST Sender: luria@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 75 Approved: tcp-ip@sri-nic.arpa > We're thinking about getting a few of the Excelan TCP/IP boards/software > for our 11/780's running VMS. I remember a few problems mentioned about > their products before, but don't have that mail to refer back to now. > What are peoples experiences with Excelan, and mostly with the current > revision of their software EXOS 8043 3.2? Also, are there any archives > of tcp-ip mail around? I have installed Excelan's TCP/IP front-end-protocol hardware/software on several 2.9BSD Unix PDP11's at the Naval Academy. I can't comment on the VMS installation, but will try to shed some light on the implementation. Excelan makes several boards for Unibus, Q-bus, Multibus, and VME-bus. In terms of operation and capabilities, they are all identical. An on board 80186 CPU, ethernet chip, and SEEQ xcvr chip do most of the work. (The Unibus board is quite nice, Quad height, 5.5 amps total current.) When operated in link level mode, an on board PROM based kernel communicates with the host to transfer packets between the host and the wire. The driver is somewhat similar to the DEC DEUNA driver in that the host and interface communicate via a set of message buffers (organized in circular queues). In this mode, the measured throughput is 60Kbytes per second of user data from memory to memory between two Vax 780 processors with a cpu load of about 50% (BRL Vax Unix; based on 4.2BSD). When operated in front-end mode, the on board PROM module implements a skeleton operating system in which the TCP/IP network code module can execute. The net code is RAM resident and is generally downloaded to the board at boot time. (Avoid the 128Kb RAM configuration board for front-end operation; the additional memory is used for buffering to increase performance.) The host communicates with the net code via four device drivers and a set of library routines. The library implements the 4.1a network semantics which are sufficient for most applications. At the application level, they supply Telnet, FTP, rlogin, rcp, rsh, and rwho. The rlogin and telnet daemons run in the card for performance reasons. This implies that their rlogin daemon doesn't handle automatic authentication. They currently don't have an SMTP server, but I'm told that they are seriously considering one so that they have a full implementation. ARP, ICMP echo, and ICMP redirect are also supported. Gateways are supported and routes are determined by incoming ICMP packets or can be built manually with a maintenance program that they supply. (The older version 3.1 couldn't handle gateways. In fact, version 3.1 would crash if it received a packet from a host with a different net address. The 3.1a network module fixes this serious flaw. Anyone running Excelan software which says that the net module is version 3.1 should contact their supplier for the 3.1a version. ) The board status (things like ethernet collisions, etc) can be polled using another program. Sub-nets are not supported but I have mailed them some of the recent discussion and suggested that they work on it. I have measured the data rate of the PDP11 to Vax at 60Kbytes/sec for memory to memory transfers. Having ported their old 3.1 version and then beta tested the 3.2 version before its release, I found that they significantly cleaned up the code in their port to RSX and VMS. (I did find some additional bugs, but they have been reported and presumably fixed. Most of the ones I found would have appeared only on a machine like the PDP11 with its restricted addressing.) I'm quite pleased with my decision to use the Excelan cards. I've had no problems with the hardware and their software and documentation has improved significantly. Excelan has been quite helpful. Why didn't I chose CMC cards? They didn't have a shippable product at the time I needed the cards. Excelan's presence in the market seems to have been hurt a bit by the time they spent in getting the VMS/RSX ports done, but it has probably helped their code significantly. The next release is supposed to increase the performance. Now, if they just had an SMTP server for VMS, I'd buy it for our VMS machine. -tcs Terry Slattery U.S. Naval Academy 301-267-4413 ARPA: tcs@usna.arpa UUCP: decvax!brl-bmd!usna!tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986011918581401> Mail-From: VIVIAN created at 20-Jan-86 14:18:28 Received: from USNA.ARPA by SRI-NIC.ARPA with TCP; Sun 19 Jan 86 21:04:11-PST Date: Sun, 19 Jan 86 23:58:14 EST From: Terry Slattery To: dp4@cmu-cc-te.ARPA cc: tcp-ip@SRI-NIC.ARPA Subject: Excelan tcp-ip on VMS ReSent-Date: Mon 20 Jan 86 14:18:28-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12176832459.29.VIVIAN@SRI-NIC.ARPA> > We're thinking about getting a few of the Excelan TCP/IP boards/software > for our 11/780's running VMS. I remember a few problems mentioned about > their products before, but don't have that mail to refer back to now. > What are peoples experiences with Excelan, and mostly with the current > revision of their software EXOS 8043 3.2? Also, are there any archives > of tcp-ip mail around? I have installed Excelan's TCP/IP front-end-protocol hardware/software on several 2.9BSD Unix PDP11's at the Naval Academy. I can't comment on the VMS installation, but will try to shed some light on the implementation. Excelan makes several boards for Unibus, Q-bus, Multibus, and VME-bus. In terms of operation and capabilities, they are all identical. An on board 80186 CPU, ethernet chip, and SEEQ xcvr chip do most of the work. (The Unibus board is quite nice, Quad height, 5.5 amps total current.) When operated in link level mode, an on board PROM based kernel communicates with the host to transfer packets between the host and the wire. The driver is somewhat similar to the DEC DEUNA driver in that the host and interface communicate via a set of message buffers (organized in circular queues). In this mode, the measured throughput is 60Kbytes per second of user data from memory to memory between two Vax 780 processors with a cpu load of about 50% (BRL Vax Unix; based on 4.2BSD). When operated in front-end mode, the on board PROM module implements a skeleton operating system in which the TCP/IP network code module can execute. The net code is RAM resident and is generally downloaded to the board at boot time. (Avoid the 128Kb RAM configuration board for front-end operation; the additional memory is used for buffering to increase performance.) The host communicates with the net code via four device drivers and a set of library routines. The library implements the 4.1a network semantics which are sufficient for most applications. At the application level, they supply Telnet, FTP, rlogin, rcp, rsh, and rwho. The rlogin and telnet daemons run in the card for performance reasons. This implies that their rlogin daemon doesn't handle automatic authentication. They currently don't have an SMTP server, but I'm told that they are seriously considering one so that they have a full implementation. ARP, ICMP echo, and ICMP redirect are also supported. Gateways are supported and routes are determined by incoming ICMP packets or can be built manually with a maintenance program that they supply. (The older version 3.1 couldn't handle gateways. In fact, version 3.1 would crash if it received a packet from a host with a different net address. The 3.1a network module fixes this serious flaw. Anyone running Excelan software which says that the net module is version 3.1 should contact their supplier for the 3.1a version. ) The board status (things like ethernet collisions, etc) can be polled using another program. Sub-nets are not supported but I have mailed them some of the recent discussion and suggested that they work on it. I have measured the data rate of the PDP11 to Vax at 60Kbytes/sec for memory to memory transfers. Having ported their old 3.1 version and then beta tested the 3.2 version before its release, I found that they significantly cleaned up the code in their port to RSX and VMS. (I did find some additional bugs, but they have been reported and presumably fixed. Most of the ones I found would have appeared only on a machine like the PDP11 with its restricted addressing.) I'm quite pleased with my decision to use the Excelan cards. I've had no problems with the hardware and their software and documentation has improved significantly. Excelan has been quite helpful. Why didn't I chose CMC cards? They didn't have a shippable product at the time I needed the cards. Excelan's presence in the market seems to have been hurt a bit by the time they spent in getting the VMS/RSX ports done, but it has probably helped their code significantly. The next release is supposed to increase the performance. Now, if they just had an SMTP server for VMS, I'd buy it for our VMS machine. -tcs Terry Slattery U.S. Naval Academy 301-267-4413 ARPA: tcs@usna.arpa UUCP: decvax!brl-bmd!usna!tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012002120500> Mail-From: VIVIAN created at 20-Jan-86 18:11:46 Received: from ucbvax.berkeley.edu by SRI-NIC.ARPA with TCP; Mon 20 Jan 86 18:10:44-PST Received: by ucbvax.berkeley.edu (5.44/1.7) id AA02066; Mon, 20 Jan 86 18:10:08 PST Received: by ulysses.UUCP; Mon, 20 Jan 86 18:32:48 est Received: by uahcs1.UUCP (4.12/4.7) id AA23820; Mon, 20 Jan 86 08:12:05 cst Date: Mon, 20 Jan 86 08:12:05 cst From: ulysses!uahcs1!ingr!dorf@ucbvax.berkeley.edu Message-Id: <8601201412.AA23820@uahcs1.UUCP> To: uahcs1!tcp-ip Subject: Re: Wollongoing subnet support (sic) References: <8601140024.AA04700@ngp.UTEXAS.EDU> ReSent-Date: Mon 20 Jan 86 18:11:46-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12176874930.29.VIVIAN@SRI-NIC.ARPA> I am interested in a public domain TCP/IP for VMS (or what ever). I have not seen anything good though. Let me know if you do... David Dorfmueller ihnp4!akgua!ingr!bldg11!dorf (205) 772-6162 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012007040000> Mail-From: VIVIAN created at 20-Jan-86 18:07:10 Received: from SU-AI.ARPA by SRI-NIC.ARPA with TCP; Mon 20 Jan 86 15:05:01-PST Date: 20 Jan 86 1504 PST From: Joe Weening Subject: TCP question To: TCP-IP@SRI-NIC.ARPA ReSent-Date: Mon 20 Jan 86 18:07:10-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12176874094.29.VIVIAN@SRI-NIC.ARPA> Suppose the following happens: Host A Host B ---------- ---------- Sends SYN Enters SYN-SENT state Receives SYN Enters SYN-RECEIVED state Sends SYN ACK, but packet is lost Retransmits SYN Receives SYN The second SYN received by host B is out of the window, so my reading of RFC 793 is that host B should send an ACK and drop the segment (bottom of page 69). But this way, host A never receives a SYN from host B. Have I missed something? It seems that Host B should reply with another SYN ACK when it receives a SYN in the SYN-RECEIVED state (maybe after checking to make sure the sequence number on the SYN is one less than the current RCV.NXT), but I can't find this anywhere. Our implementation actually acts as described above, and I'd like to fix it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012008354900> Mail-From: VIVIAN created at 20-Jan-86 18:07:33 Received: from FORD-WDL1 by SRI-NIC.ARPA with TCP; Mon 20 Jan 86 16:36:02-PST Return-Path:<> Date: 20-Jan-86 16:35:49-PST From: jbn@FORD-WDL1 Subject: Re: 1200 baud links To: TCP-IP@NIC Cc: jbn@FORD-WDL1 ReSent-Date: Mon 20 Jan 86 18:07:32-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12176874162.29.VIVIAN@SRI-NIC.ARPA> I have tried IP/TCP over a 1200 baud link. I advise against it. It can be made to work, if all hosts and gateways using the path are very well-behaved. If my previously-posted fixes are put into 4.3BSD, it may indeed work between two 4.3BSD sites. General attachment to the Internet will definitely NOT work. Operation at 9600 baud is quite workable, and we've been doing it for years. We still have trouble with bad host implementations, but we talk routinely, using FTP, TELNET, and SMTP, to many Internet sites, over a path with three concatenated 9600 baud links. As dial-up modems approach 9600 baud and TCP/IP implementations for PCs become available, dial-up Internet service may start to appear. Anybody thinking seriously about this yet? Clearly there are naming and addressing problems, but I think that the congestion problem can be managed. See RFC970 for details. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012017103400> Mail-From: VIVIAN created at 21-Jan-86 11:47:53 Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Mon 20 Jan 86 19:12:54-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Mon, 20 Jan 86 22:10:34 est Date: Mon, 20 Jan 86 22:10:34 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8601210310.AA05913@BORAX.LCS.MIT.EDU> To: TCP-IP@NIC Cc: jbn@FORD-WDL1 In-Reply-To: jbn@FORD-WDL1's message of 20-Jan-86 16:35:49-PST Subject: 1200 baud links ReSent-Date: Tue 21 Jan 86 11:47:53-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177067191.41.VIVIAN@SRI-NIC.ARPA> The first net interface we supported in PC/IP was the PC's serial line using (of course) our own packet framing protocol over the serial line. The protocol is rather stupid in some ways (it's very wasteful of bytes), but it has worked fine for several years. We also implemented it for the C Gateway so that the PC's could talk to the rest of the world. We haven't done much with it since Ethernet and proNET cards became available for the PC; our interest was mostly in doing a TCP/IP implementation for the PC, not in investigating serial line dialups to the Internet, but that gateway is still there. It's two major uses now are some leased 9600 baud lines going to faculty members houses and a 1200 baud dialup modem that's on it that some people used to use to do file transfers. Getting the TFTP timeout algorithm to work well with line speeds varying from 1200 baud to 56kbps to 10Mbps (well...) was a bit of a challenge... The gateway supported 8 serial lines; we used a very simple addressing scheme. We assigned a whole subnet number to the serial lines and then gave them host numbers 1 through 8. The gateway had a host number on that subnet as well. Since we tend not to name PC's around here, there was never a problem with "Jerry Saltzer's home PC" changing its internet address (actually, the 9600 baud ports are all dedicated, anyway, so the addresses wouldn't change). - John Romkey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012017342100> Mail-From: VIVIAN created at 21-Jan-86 11:48:36 Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Mon 20 Jan 86 19:36:10-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Mon, 20 Jan 86 22:34:21 est Date: Mon, 20 Jan 86 22:34:21 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8601210334.AA06070@BORAX.LCS.MIT.EDU> To: tcp-ip@sri-nic.arpa Subject: IBMPC-based implementations ReSent-Date: Tue 21 Jan 86 11:48:36-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177067323.41.VIVIAN@SRI-NIC.ARPA> > From: hplabs!hplsla!tikal!tna@ucbvax.berkeley.edu (Tom Anderson) > > I have used the MIT PC/IP package with some degree of success. I have > largely quit using it, however, in favor of serial protocols like Kermit > because of various problems like: > > 1. Can't upload a file unless it already exists. > 2. Can't upload a file unless it is accessible by everyone. > 3. Occasional bit errors. > > What I would really like is rcp, rsh, and rlogin on a PC. Let me > know if you find such. Thanks to Barry Shein who already pointed out that most of these are just problems with TFTP itself. Actually, there shouldn't ever be bit errors; if you have a reproducable problem with PC/IP's TFTP where files get corrupted, let me know and I'll try to fix it. Maybe you were TFTP'ing with a 4.2 machine? 4.2 as shipped had *lots* of problems with TFTP and UDP checksums that might have caused bit errors. Having a real FTP would also solve your problems, and I know somewhere where you'll be able to get that, rcp, rsh and rlogin for the PC "soon". Some of the original authors of PC/IP have formed a company that will be commercially selling and supporting an "enhanced" (read: "lots of bugs fixed and some new programs") version of PC/IP. If you want more information, get in touch with them. The company's address is: FTP Software, Inc. PO Box 150 Kendall Square Branch Boston, MA 02142 Not sure of the phone number right now. Please forgive them if they're slow in responding to requests for information right now; they (honestly, *we*) are just getting organized now. If there's enough interest, I'll post a message describing what is supported in FTP Software's version of PC/IP (if you want to know, mail directly to me...), but I'd rather not right now 'less it be misconstrued as advertising. - John Romkey romkey@borax.lcs.mit.edu Disclaimer: I *am* strongly associated with FTP Software, so anything I say is quite prejudiced... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012103494900> Mail-From: VIVIAN created at 21-Jan-86 12:16:36 Received: from orion.ARPA by SRI-NIC.ARPA with TCP; Tue 21 Jan 86 11:50:02-PST Received: by orion.ARPA (5.28/1.2) id AA08431; Tue, 21 Jan 86 11:49:52 PST Message-Id: <8601211949.AA08431@orion.ARPA> To: tcp-ip@sri-nic.arpa Subject: OMB and ISO Date: 21 Jan 86 11:49:49 PST (Tue) From: Milo S. Medin (NASA ARC Code ED) ReSent-Date: Tue 21 Jan 86 12:16:35-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177072417.41.VIVIAN@SRI-NIC.ARPA> A friend of mine here at Ames met with a representative of OMB (Office of Management and Budget) last week while I was in USENIX, and was told that OMB is drafting a requirement that all computers bought by the Federal Government (including DoD) will be required to speak the "ISO" protocol (meaning TP-4 etc...). He said it should be out in the next couple of months. The idea is apparently to save bunches of money by forcing everyone to use 1 communications protocol. Has anyone else heard about this? This could be a VERY bad thing. Also, the vendors that OMB were talking to were very reluctant to start working on the ISO stuff right now, and OMB wanted to encourage them to start doing so quickly. Milo Medin NASA Ames Research Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012113010600> Mail-From: VIVIAN created at 21-Jan-86 17:41:37 Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Tue 21 Jan 86 15:02:07-PST Date: 21 Jan 1986 18:01:06 EST From: MILLS@USC-ISID.ARPA Subject: Re: 1200 baud links To: romkey@MIT-BORAX.ARPA, TCP-IP@SRI-NIC.ARPA cc: jbn@FORD-WDL1.ARPA, MILLS@USC-ISID.ARPA ReSent-Date: Tue 21 Jan 86 17:41:37-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177131586.15.VIVIAN@SRI-NIC.ARPA> In response to the message sent Mon, 20 Jan 86 22:10:34 est from romkey@BORAX.LCS.MIT.EDU John & Co., Interestingly enough, our ubiquitous Fuzzballs support your IBM PC protocol for the same reason - to provide a handy-dandy way to access the Internet from random spots, including 1200-bps packet-radio channels. In point of fact, we haven't tamed the PC timeouts to deal properly with radio channel congestion, but they work fine with direct serial connection at speeds as low as 1200 bps. Each "PC gateway" module is implemented as a single-line device driver with configured IP address. Having said that, you should not construe my pragmatics as endorsing the serial protocol itself for proliferated use. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012123000000> Mail-From: VIVIAN created at 22-Jan-86 01:34:24 Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Wed 22 Jan 86 01:07:52-PST Date: Wed, 22 Jan 86 04:00 EST From: Miyata@MIT-MULTICS.ARPA Subject: Re: OMB and ISO To: "Milo S. Medin" (NASA ARC Code ED) cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message of 21 Jan 86 14:49 EST from "Milo S. Medin" Message-ID: <860122090001.087233@MIT-MULTICS.ARPA> ReSent-Date: Wed 22 Jan 86 01:34:24-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177217655.15.VIVIAN@SRI-NIC.ARPA> See National Research Council's Report to the Department of Defense and the National Bureau of Standards "Transport Protocols for Department of Defense Data Networks", National Academy Press, February 1985. The Executive Summary is in RFC 939. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012202310200> Mail-From: VIVIAN created at 22-Jan-86 13:13:43 Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 22 Jan 86 10:33:35-PST Date: 22 Jan 1986 10:31:02 PST From: POSTEL@USC-ISIB.ARPA Subject: re: OMB and ISO To: tcp-ip@SRI-NIC.ARPA ReSent-Date: Wed 22 Jan 86 13:13:43-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177344960.36.VIVIAN@SRI-NIC.ARPA> > See National Research Council's Report to the Department of Defense > and the National Bureau of Standards "Transport Protocols for > Department of Defense Data Networks", National Academy Press, February > 1985. The Executive Summary is in RFC 939. The full report is RFC-942. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012204571800> Mail-From: VIVIAN created at 22-Jan-86 13:13:18 Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 22 Jan 86 06:58:24-PST Date: Wed 22 Jan 86 09:57:18-EST From: "J. Noel Chiappa" Subject: Re: 1200 baud links To: jbn@FORD-WDL1.ARPA, TCP-IP@SRI-NIC.ARPA cc: JNC@XX.LCS.MIT.EDU In-Reply-To: Message from "jbn@FORD-WDL1" of Mon 20 Jan 86 19:35:49-EST Message-ID: <12177276435.15.JNC@XX.LCS.MIT.EDU> ReSent-Date: Wed 22 Jan 86 13:13:18-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177344885.36.VIVIAN@SRI-NIC.ARPA> One thing I'd advise for slow speed links is header compression. Two sequential TCP packets on a connection look pretty much alike, and if you only send the bytes that are different you wind up with substantially smaller packets. For interactive typing, this makes a big difference. Dave Reed at MIT was one person who noticed this, and he took some statistics on which patterns of repeated bytes were most common. He proposed using a 'type byte' to identify the 250 most common patterns of commonality (the extras were for various flags, etc). He was going to compare the packet to the previous one, figure out which pattern applied best, and send the pattern number and the changed bytes; the packet would then be reassembled into the previous form at the far end. He also had a framing system that had only one byte per packet of overhead for sequential packets, and there are tricky issues like needing a checksum on the *uncompressed* data otherwhise things can get out of synch, etc. He wrote a note describing this but I don't think it is available online. If you want a copy (and please don't ask unless you are really interested, since the supply is limited) send a message to "Staton@xx.lcs.mit.edu", asking for "RFC 248, Improving Internet Protocol Performance on Low Speed Lines". I implemented the bulk of his proposal on the serial line code for the Portable C Gateway; this has been in service on the 4800 baud link to Proteon for several years, and works well. It was measured to reduce the amount of bytes actuallly sent down the wire by about 50% over a 2 month period! This is a figure averaged over *all* traffic, including mail and file transfer! We used a slightly different scheme for the compression, since I couldn't figure out an easy algorithm to pick the best pattern (he didn't give one)! I simply used a 32 bit mask, one bit for each of the first 32 bytes; you sent the mask, the changed bytes, and the rest of the packet. It was easy to compute the mask, and on a 4800 baud line I didn't need to squeeze every drop of compression out. (I think I figured out that 32 was almost as good as 48, even though the TCP header is 40 bytes, since many of the 8 bytes that are missed change from packet to packet, and you have to have an extra two bytes to mask to charge against the savings.) Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012206403100> Mail-From: VIVIAN created at 23-Jan-86 17:59:32 Received: from ucbvax.berkeley.edu by SRI-NIC.ARPA with TCP; Thu 23 Jan 86 14:10:01-PST Received: by ucbvax.berkeley.edu (5.44/1.8) id AA03911; Thu, 23 Jan 86 12:48:19 PST Received: by hplabs.ARPA ; Thu, 23 Jan 86 12:28:56 pst Received: by RDCF.SDC.UUCP (sdcrdcf) with UUCP (4.12/0.2.4) id AA12590; Thu, 23 Jan 86 03:35:01 pst Received: by psivax.UUCP (4.12/4.7) id AA00395; Thu, 23 Jan 86 02:21:41 pst Received: by nrcvax.UUCP (4.12/4.7) id AA04466; Wed, 22 Jan 86 14:40:31 pst Date: Wed, 22 Jan 86 14:40:31 pst From: hplabs!sdcrdcf!psivax!nrcvax!andre@ucbvax.berkeley.edu (Andre Hut) Message-Id: <8601222240.AA04466@nrcvax.UUCP> To: psivax!tcp-ip Subject: Re: SYN with a window size of zero Newsgroups: mod.protocols.tcp-ip In-Reply-To: <12176159649.11.LEPREAU@UTAH-20.ARPA> References: <[USC-ISI.ARPA]16-Jan-86.21:44:33.CERF> Organization: Network Research Corp. Oxnard, CA ReSent-Date: Thu 23 Jan 86 17:59:32-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177659135.21.VIVIAN@SRI-NIC.ARPA> MIL-STD-1778 (Transmission Control Protocol) Section 9.4.6.3.23 on generating a SYN specifies that when a SYN is sent without an ACK, the window is set to 0. Is this standard adhered to, or has it been abandoned for something else? ----------------------------------------------------------------------------- ihnp4-\ sdcsvax-\ \ Andre' Hut sdcrdcf!psivax!nrcvax!nrcutah!andre hplabs--/ / ucbvax!calma-/ Network Research Corporation 923 Executive Park Dr. Suite C Salt Lake City, Utah 84117 ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012212200000> Mail-From: VIVIAN created at 23-Jan-86 00:04:30 Received: from SU-AI.ARPA by SRI-NIC.ARPA with TCP; Wed 22 Jan 86 20:21:15-PST Date: 22 Jan 86 2020 PST From: Joe Weening Subject: Re: TCP question To: CERF@USC-ISI.ARPA CC: TCP-IP@SRI-NIC.ARPA ReSent-Date: Thu 23 Jan 86 00:04:29-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177463431.13.VIVIAN@SRI-NIC.ARPA> Vint, Thanks for your explanation and I'm sorry for bothering the list with this. The SYN ACK packet should indeed be retransmitted. I definitely observed that this was not happening, but unfortunately it's hard to reproduce and find out why. In any case, it seems to be a bug with our implementation and not the protocol. Joe ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012212480000> Mail-From: VIVIAN created at 23-Jan-86 00:02:56 Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 22 Jan 86 14:49:18-PST Date: Wed, 22 Jan 1986 17:48 EST From: "Karen R. Sollins" Message-ID: <[XX.LCS.MIT.EDU].SOLLINS.22-Jan-86 16:54:01> To: arpanet-bboards@MC.LCS.MIT.EDU, tcp-ip@SRI-NIC.ARPA, msggroup@BRL-AOS.ARPA, header-people@MC.LCS.MIT.EDU, namedroppers@SRI-NIC.ARPA, info-nets@OZ.AI.MIT.EDU Subject: IMPORTANT NOTICE ABOUT MC.LCS.MIT.EDU ReSent-Date: Thu 23 Jan 86 00:02:56-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177463148.13.VIVIAN@SRI-NIC.ARPA> Many rumors have been spreading about MC.LCS.MIT.EDU. The following are the facts: * The maintenance contract on the machine will be discontinued at the end of March. * MIT will continue to support the mail and mailing list activities that have run historically on MC. After the end of March this service will reside on other hardware that will be named MC.LCS.MIT.EDU. * The KL-10 will not evaporate immediately, although its name and possibly internet address will change. Karen R. Sollins Director of Computing Resources MIT/Laboratory for Computer Scinece ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012215050000> Mail-From: VIVIAN created at 23-Jan-86 00:04:49 Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Wed 22 Jan 86 23:12:00-PST Date: 22 Jan 1986 23:05-PST Sender: BILLW@SU-SCORE.ARPA Subject: Re: 1200 baud links From: William "Chops" Westfield To: JNC@XX.LCS.MIT.EDU Cc: jbn@FORD-WDL1.ARPA, TCP-IP@SRI-NIC.ARPA Message-ID: <[SU-SCORE.ARPA]22-Jan-86 23:05:54.BILLW> In-Reply-To: <12177276435.15.JNC@XX.LCS.MIT.EDU> ReSent-Date: Thu 23 Jan 86 00:04:49-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177463491.13.VIVIAN@SRI-NIC.ARPA> RFC914 discusses various means of using TCP/IP over "thin" transmission lines, doing thing along the lines that others have suggested (only sending changed header bytes, etc). It was written by dave Farber and some others... BillW ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012216500000> Mail-From: VIVIAN created at 23-Jan-86 00:03:22 Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Wed 22 Jan 86 18:50:58-PST Date: 22 Jan 1986 21:50-EST Sender: CERF@USC-ISI.ARPA Subject: Re: TCP question From: CERF@USC-ISI.ARPA To: JJW@SU-AI.ARPA Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]22-Jan-86 21:50:27.CERF> In-Reply-To: The message of 20 Jan 86 1504 PST from Joe Weening ReSent-Date: Thu 23 Jan 86 00:03:22-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177463227.13.VIVIAN@SRI-NIC.ARPA> In theory, once both hosts have orignated SYN packets, they will treat these as "occupying address space and therefore require ACKS and must be retransmitted until ACK received." What this means is that the host that went into SYN-RECEIVED state, when it gets another SYN, can respond with the appropriate ACK (namely indicating what sequence number it is expecting next). This is always a legitimate response. The SYN that was lost will also have to be retransmitted by the host that sent it (host B) upon finding by timeout, for instance, that the original SYN (pun intended) was not acknowledged. I believe it is correct that this retransmission of the lost SYN/ACK need not be correlated with ACK responses to SYNs sent from host A. That is, Host B may send ACKs for the packets it receives from Host A independently of retransmitting its unacknowledged SYN. The concept of the retransmitted SYN from HOST A being out of B's received window sounds wrong-headed. Since ACKS are cumulative (acking all previously received packets) an ACK from HOST B asserting what it is next expecting, implicitly ACKs the SYN from A as well. It has been a while since I looked carefully at the TCP state diagrams, and I don't have the material at hand, so I may be missing something here, but that's my recollection. Perhaps one of the current internet gurus like Jon or Dave M or Dave C might comment further. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012216580000> Mail-From: VIVIAN created at 23-Jan-86 00:03:38 Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Wed 22 Jan 86 18:59:07-PST Date: 22 Jan 1986 21:58-EST Sender: CERF@USC-ISI.ARPA Subject: Re: OMB and ISO From: CERF@USC-ISI.ARPA To: medin@ORION.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]22-Jan-86 21:58:33.CERF> In-Reply-To: <8601211949.AA08431@orion.ARPA> ReSent-Date: Thu 23 Jan 86 00:03:38-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177463276.13.VIVIAN@SRI-NIC.ARPA> Milo, The OMB requirement may not be as damaging as it sounds if it simply requires the vendors to support ISO but doesn't CONSTRAIN them to only ISO. I would imagine IBM would be pretty fierce if it was told the government could not make use of SNA... or DoD was told that operational networks protecting national security suddenly had to switch to an untested implementation... The thing to watch out for is a directive which prohibits all protocols except ISO. Considering the present state of implementation and test of that protocol suite, there is still a long way to go before it is reasonable to consider it robust. I hope I am not being too sanguine, here. Perhaps another reader will contribute further insights on this no doubt well-intended bit of bureaucracy. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012217540000> Mail-From: VIVIAN created at 23-Jan-86 12:58:39 Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Thu 23 Jan 86 11:24:01-PST Received: from (WITLICKI)WILLIAMS.BITNET by WISCVM.WISC.EDU on 01/23/86 at 13:23:13 CST Date: 22 JAN 86 22:54-EST From: WITLICKI%WILLIAMS.BITNET@WISCVM.WISC.EDU To: TCP-IP@SRI-NIC.ARPA Subject: Re: OMB and ISO ReSent-Date: Thu 23 Jan 86 12:58:39-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177604361.21.VIVIAN@SRI-NIC.ARPA> Could someone please post a brief summary about TP-4 ? Is it really an *improvement* over TCP/IP (i assume that is what it would replace). Or is it merely Invented By The ISO and Part Of The Holy Heptad ? Is there interoperability between TCP/IP and TP-4 or would one be faced with a switchover? - Randy Witlicki Williams College, Williamstown, Massachusetts Witlicki%Williams.Bitnet@Wiscvm.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012222480000> Mail-From: VIVIAN created at 23-Jan-86 12:58:16 Mail-From: STJOHNS created at 23-Jan-86 06:48:55 Date: 23 Jan 1986 06:48-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: TCP question From: STJOHNS@SRI-NIC.ARPA To: JJW@SU-AI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]23-Jan-86 06:48:51.STJOHNS> In-Reply-To: The message of 20 Jan 86 1504 PST from Joe Weening ReSent-Date: Thu 23 Jan 86 12:58:16-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177604292.21.VIVIAN@SRI-NIC.ARPA> And the answer is... Host B will retransmit the SYN upon time out since host A never sends an ACK accounting for host B's SYN. THe SYN is considered part of the sequence space and has to be handled like any other byte of unacknowledged data. You might want to see the TCP mill std (mil-std-1778) pgs 151 and 152 which shows some of the hair you need to consider when retransmitting SYNs. Mike (Oh yeah, proper behavior for Host B when it recieves a duplicate SYN is to reply with an ACK segment and drop the incoming, duplicate SYN) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012307555400> Mail-From: VIVIAN created at 23-Jan-86 17:58:21 Received: from LOKI.ARPA by SRI-NIC.ARPA with TCP; Thu 23 Jan 86 13:21:23-PST To: Vshank%Weizmann.bitnet@wiscvm.wisc.edu cc: tcp-ip@sri-nic.arpa Subject: re: Tp4 Date: Thu, 23 Jan 86 16:15:54 -0500 From: Craig Partridge ReSent-Date: Thu 23 Jan 86 17:58:21-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177658921.21.VIVIAN@SRI-NIC.ARPA> > Can anyone summerize the differences between Tcp/Ip and Tp4? I would > be interested in a sort of chart showing what Tc/Ip can do that Tp4 can't > and visa versa. When I asked about this of some people locally who were heavily involved with TP4 I seem to recall they said that TP4 was designed to offer all the functions that TCP offers. This was a while ago so I may well mis-remember (someone please correct me if I am wrong). Craig Partridge ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012308074300> Mail-From: VIVIAN created at 24-Jan-86 12:36:38 Received: from Huey.UDEL.EDU by SRI-NIC.ARPA with TCP; Fri 24 Jan 86 05:22:27-PST Received: from localhost by Huey.UDEL.EDU id a002518; 23 Jan 86 16:28 EST To: William Chops Westfield cc: JNC@xx.lcs.mit.EDU cc: jbn@ford-wdl1.ARPA, TCP-IP@sri-nic.ARPA cc: f-troup@huey.udel.EDU Subject: Re: 1200 baud links In-Reply-To: Your message of 22 Jan 1986 23:05-PST. <[SU-SCORE.ARPA]22-Jan-86 23:05:54.BILLW> Date: Thu, 23 Jan 86 16:27:43 -0500 From: Gary Delp ReSent-Date: Fri 24 Jan 86 12:36:38-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177862499.17.VIVIAN@SRI-NIC.ARPA> >> RFC914 discusses various means of using TCP/IP over "thin" >> transmission lines, doing thing along the lines that others >> have suggested (only sending changed header bytes, etc). >> It was written by dave Farber and some others... The others were Gary Delp and Tom Conte. Hard copies are available upon request. An alternative to header compression is discussed at the end of the RFC. In the paper it is called thinwire III, but as the header compression gives at best 2:1 IP level compression, we have abandoned thinwires I, and II, and are continuing this work with thinwire II as the only thinwire. (confusing enough?) In some instances, the linking of machines at the IP level is not what is desired. When only "tcp user services" are needed, using a gateway which provideds the tcp/ip/udp processing on the fast side of the 1200 baud baud link is not only sufficient, it is *much* better. We are putting together a gateway which provides these services to dialup clients. Maybe TCP/UDP connection server would be a more accurate title. regards, Gary Delp 140 Evans Hall Department of Electrical Engineering University of Delaware Newark DE 19716 (302) 451-6653 messages at 2405 delp@huey.udel.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012315010000> Mail-From: VIVIAN created at 23-Jan-86 12:57:47 Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Thu 23 Jan 86 03:11:08-PST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.WISC.EDU on 01/23/86 at 05:10:19 CST Received: by WEIZMANN (Mailer X1.23) id 6704; Thu, 23 Jan 86 11:33:56 O Date: Thu, 23 Jan 1986 11:31 O From: Henry Nussbacher Subject: Tp4 To: ReSent-Date: Thu 23 Jan 86 12:57:47-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177604204.21.VIVIAN@SRI-NIC.ARPA> Can anyone summerize the differences between Tcp/Ip and Tp4? I would be interested in a sort of chart showing what Tc/Ip can do that Tp4 can't and visa versa. Also, can someone tell me the full name for RFC942 on SRI-NIC so that I can FTP it. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012403281800> Mail-From: VIVIAN created at 24-Jan-86 12:37:06 Received: from bbnh by SRI-NIC.ARPA with TCP; Fri 24 Jan 86 05:59:33-PST Date: Fri, 24 Jan 86 8:28:18 EST From: Alex McKenzie Subject: TP4 and TCP To: tcp-ip@sri-nic.arpa ReSent-Date: Fri 24 Jan 86 12:37:05-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177862581.17.VIVIAN@SRI-NIC.ARPA> TP4 is intended to be functionally equivalent to TCP. The NBS and BBN people who worked in the ANSI and ISO committees defining the OSI Transport protocols were all familiar with TCP and had, as an explicit goal, getting TP4 to be as close to TCP functionality as they could manage. In fact, the inital NBS proposal was for ANSI and ISO to adopt TCP as it stood. The biggest differences I can remember offhand are: -For the purposes of allowing fragmentation, TCP numbers every byte. TP4 allows (requires) the two implementations to negotiate a maximum fragment size. Every message is broken into fragments of this size (only the final fragment of the message may be shorter) and numbers these fragments. [Silly window syndrome is not likely.] The motivation here was primarily to make the reassembly task as easy as possible, with fixed buffer pools and no byte shifting. A secondary motivation was to reduce the size of the field used to hold the number. -TP4 and TCP both allow a receiver to specify a zero window. TCP treats this as a "hint" and handles the loss of an ACK which opens the window by source probes. TP4 strongly discourages probing a zero window and provides a reliability mechanism for the ACK which opens a closed window. The motivation here is that the designers felt that a system might close windows when it was overloaded and really didn't want to spend ANY cycles processing traffic from the sources it had closed. -TCP (as I recall) has an "urgent" bit in the header of all data which, if set, tells the receiver to scan ahead looking for something special. TP4 has an "expedited" flow of limited capacity which is completely separate from the regular flow. [The expedited flow allows one outstanding message of up to 16 octets, I think.] I hope this helps, Alex McKenzie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012409090800> Mail-From: VIVIAN created at 24-Jan-86 12:38:45 Received: from EDN-VAX.ARPA by SRI-NIC.ARPA with TCP; Fri 24 Jan 86 11:10:33-PST Received: by EDN-VAX.ARPA (4.12/4.7) Date: Fri, 24 Jan 86 14:09:08 est From: swanson@EDN-VAX.ARPA (John Swanson) To: tcp-ip@sri-nic.ARPA ReSent-Date: Fri 24 Jan 86 12:38:45-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177862884.17.VIVIAN@SRI-NIC.ARPA> TCP-TP4 The ISO Transport Protocol Class 4 was designed to provide services similar to TCP i.e. a reliable transport medium, it does not provide an intranet service (ISO has its own IP). The TP4 services are similar with notable execptions. TP4 offers a true out-of-band signaling capability which can only simulated in TCP. However, TP4 does not have the ability to do graceful close, so that an Application that would need to have that capbility would have to incorperate that function above TP4. The protocols are not similar and therefore a conversion will be necessary. Hoever, the real question is once one goes to TP4 what does that buy you. Is the OMB going to require/suggest that the rest of the ISO suite also be adopted or are we going to be running FTP over TP4? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012412581100> Mail-From: VIVIAN created at 24-Jan-86 17:44:44 Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 24 Jan 86 15:09:15-PST Date: Fri 24 Jan 86 17:58:11-EST From: Geoffrey H. Cooper Subject: SUN V2 tcp checksum problems To: tcp-ip@SRI-NIC.ARPA cc: imagen!geof@DECWRL.DEC.COM Reply-To: "imagen!geof"@decwrl Message-ID: <12177888268.22.GEOF@XX.LCS.MIT.EDU> ReSent-Date: Fri 24 Jan 86 17:44:44-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177918587.17.VIVIAN@SRI-NIC.ARPA> In the 2.2 release of Imagen's TCP code the printer accepts TCP segments of 1425 bytes. The latest version of the SUN network software (2.x?) sends these segments with a bad tcp checksum. The checksums are random, not just off by one or two. A Vax 4.2 sending the same file with the same sender program to the same printer also sends 1425 byte segments, but the tcp checksums in these are accepted by the printer. Also, I tried two different checksum subroutines on the SUN packets (one with fancy unrolled loops, and one with a simple tight loop). Both indicated the same computation and both rejected the same segments. Finally, I took a look at the network statistics on a vax that is often connected to SUN's. Guess what? There were several hundred bad TCP checksums recorded. Apologies in advance if it turns out that the problem is mine, but the evidence points quite strongly to the SUN. To generate the full sized segments you must attempt to write more than 1425 bytes at once. I did it by calling write with 2048 byte blocks. I have empirically determined that calling write with smaller values (e.g., 512 bytes) does not exercise the bug. Has anyone else seen this? (does anyone else request such large and odd sized segments from a SUN?) If there is anyone from SUN out there who would like to track down the problem, I will be more than happy to help. Contact me through IMAGEN (408)986-9400 or at decwrl!imagen!geof or imagen!geof@decwrl. - Geof Cooper IMAGEN ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012413290000> Mail-From: VIVIAN created at 24-Jan-86 17:45:04 Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Fri 24 Jan 86 15:37:34-PST Date: 24 Jan 1986 18:29-EST Sender: CERF@USC-ISI.ARPA Subject: Re: OMB and ISO From: CERF@USC-ISI.ARPA To: WITLICKI%WILLIAMS.BITNET@WISCVM.WISC.EDU Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]24-Jan-86 18:29:27.CERF> In-Reply-To: The message of 22 JAN 86 22:54-EST from WITLICKI%WILLIAMS.BITNET@WISCVM.WISC.EDU ReSent-Date: Fri 24 Jan 86 17:45:04-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177918648.17.VIVIAN@SRI-NIC.ARPA> my opinion, biased as it may be, is that TP-4 is simply part of the Holy Heptad as you so wonderfully put it. There is no interoperability between TCP and TP although there has been some work, I believe by the Canadian Defense Research Establishment, on an on-the-fly conversion concept. I do not believe this has ever been implemented. John Robinson at DREO (Def Res Est Ottawa) is the point of contact. An Interoperability task force, sponsored by ARPA, has taken this up as one of many topics arising in interoperability of protocol systems. Jon Postel may be able to point to some on-line material available on the subject. Vint P.S. as to whether TP-4 is an improvement over TCP, I think one has to see what the implementation and operational experience with TP-4 is - it has not been implemented and used in nearly as many circumstances as TCP, so it is rather hard to say. The National Academy of Science study (RFC942) was more sanguine about the equivalence of the two protocols than I am, but I supposed I cannot be considered an unbiased source of opinion! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012418572300> Mail-From: VIVIAN created at 24-Jan-86 12:37:24 Received: from edn-vax.arpa by SRI-NIC.ARPA with TCP; Fri 24 Jan 86 10:58:15-PST Date: 24 Jan 86 18:57:23 GMT From: Bob Stine To: tcp-ip Subject: Re: Tp4 ReSent-Date: Fri 24 Jan 86 12:37:24-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12177862638.17.VIVIAN@SRI-NIC.ARPA> One of the major differences between TCP and TP-4 is in the support of passive opens. As related on p.16 of RFC 942, TP-4 "passes a Call Indication to a user entity whenever a Call Request is received." But, it is left as ".. an implementation decision as to how TP-4 finds and/or creates an appropriate user entity to give the Call Indication...". In other words, there is "... no Listen Service Primitive." This should make implementation of server processes interesting. Also, though TP-4 allows for the transmission of up to 16 octets of "expedited data," it has no equivalent of the TCP 'push.' 'Push' is useful for supporting record oriented or transaction oriented applications. Each expedited data PDU of TP-4 requires a separate ack, which could lead to high control traffic overhead if this option is overused. Another difference that could impact protocol developers is the fact that TP-4 uses negotiated "segment sizes" (max allowable TPDU sizes), rather than octets, as its unit of space allocation. Inappropriate segment sizes could result in over-allocation, and under utilization, of available memory resources (e.g., tinygrams could be stored in blocks of 512 bytes). Many of the other differences between TCP and TP-4 have to do with what TP-4 has not yet specified. In particular, "... the use of addresses at different levels in the ISO model has not yet been solidified ... addressing capabilities similar to TCP's will EVENTUALLY be provided by TP-4 ..." (p.15, RFC 942, emphasis added). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012504111400> Mail-From: VIVIAN created at 25-Jan-86 19:48:34 Received: from USC-ECL.ARPA by SRI-NIC.ARPA with TCP; Sat 25 Jan 86 17:38:21-PST Received: From nrtc-gremlin by NRTC id a027986 ;25 Jan 86 17:31 PST To: CERF@USC-ISI.ARPA cc: WITLICKI%WILLIAMS.BITNET@CRYS.WISC.EDU, TCP-IP@SRI-NIC.ARPA reply-to: TCP-IP@SRI-NIC.ARPA Subject: Re: OMB and ISO In-reply-to: Your message of 24 Jan 1986 18:29-EST. <[USC-ISI.ARPA]24-Jan-86 18:29:27.CERF> Date: Sat, 25 Jan 86 17:31:14 -0800 Message-ID: <29887.507087074@nrtc> From: Marshall Rose Via: Nrtc; 25 Jan 86 17:35:17 ReSent-Date: Sat 25 Jan 86 19:48:34-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12178203274.17.VIVIAN@SRI-NIC.ARPA> Although it's still in the embryonic stage, some work's being done to specify and implement a TCP socket for ISO session. This is misleading, actually the approach is to present a Transport-Service Access Point (TSAP) to applications which run over TCP/IP internetworks. A draft RFC is in the writing and a prototype 4.2BSD implementation is running now. Of course, until I can get my hands on some real ISO session/presentation/application programs, I really can't judge the merits of the approach. Along separate lines, I had heard (third hand, sigh) that Berkeley was going to be working on ISO stuff for a future release of BSD UNIX and that they thought they might try their hand at a TCP/TP4 gateway as a way of familiarizing themselves with the ISO protocols! Now this same third hand source gave me some bum information on another topic dealing with Berkeley and networking, so I won't put too much faith on it until someone from UCB says something. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012510351800> Mail-From: VIVIAN created at 25-Jan-86 18:35:18 Date: Sat 25 Jan 86 18:35:18-PST From: Vivian Neou Subject: TCP-IP mail yesterday To: tcp-ip-rebroadcast@SRI-NIC.ARPA cc: vivian@SRI-NIC.ARPA Message-ID: <12178189937.17.VIVIAN@SRI-NIC.ARPA> I don't mean to seem ungrateful, but please stop sending me copies of the messages that went out yesterday with the list prepended to it. I am aware of the problem, and I think it has been fixed. Thanks. Vivian ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012611020700> Mail-From: VIVIAN created at 26-Jan-86 20:36:41 Received: from SUMEX-AIM.ARPA by SRI-NIC.ARPA with TCP; Sun 26 Jan 86 19:03:19-PST Date: Sun 26 Jan 86 19:02:07-PST From: Jeannie Siegman Subject: LAN Consultant Position at Stanford To: bboard@SRI-KL.ARPA, bboard@AI.AI.MIT.EDU, tcp-ip@SRI-NIC.ARPA Message-ID: <12178456960.31.SIEGMAN@SUMEX-AIM.ARPA> ReSent-Date: Sun 26 Jan 86 20:36:41-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12178474177.16.VIVIAN@SRI-NIC.ARPA> Experienced professional to serve as networking consultant to academic departments of the University. Assist users with requirements definition, planning and operatingng LAN's, and connecting them to SUNet (Stanford's cross-campus video and data network). Prerepare configurations and bid requests oversee installation, teach, give demonstrations, write and review networking documents. Test new products and recommend support strategies. Qualifications: working experience with Ethernet, micro nets. Prefer some broadband experience. Excellent written and oral expression. Ask for detailed job description. Dynamic work environment, competitive salary, and excellent benefits. Full-time, immediate opening. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012613421300> Mail-From: VIVIAN created at 27-Jan-86 14:18:35 Received: from monet.berkeley.edu by SRI-NIC.ARPA with TCP; Sun 26 Jan 86 21:56:35-PST Received: by monet.berkeley.edu (5.44/1.8) id AA29522; Sun, 26 Jan 86 21:42:18 PST From: karels@monet.berkeley.edu (Mike Karels) Message-Id: <8601270542.AA29522@monet.berkeley.edu> To: TCP-IP@sri-nic.arpa Subject: Re: OMB and ISO In-Reply-To: Your message of Sat, 25 Jan 86 17:31:14 -0800. <29887.507087074@nrtc> Date: 26 Jan 86 21:42:13 PST (Sun) ReSent-Date: Mon 27 Jan 86 14:18:35-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12178667491.31.VIVIAN@SRI-NIC.ARPA> Marshall, I think you should stop paying that third-hand source for information about Berkeley plans. If someone here was planning an ISO protocol implementation and a TCP/TP4 gateway (whatever such a beast might be), I think I would have heard of it. Mike (Berkeley CSRG) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012704340100> Received: from USC-ECL.ARPA by SRI-NIC.ARPA with TCP; Wed 29 Jan 86 21:18:32-PST Received: From nrtc-gremlin by NRTC id a003274 ;27 Jan 86 17:55 PST To: Mike Karels cc: TCP-IP@SRI-NIC.ARPA reply-to: TCP-IP@SRI-NIC.ARPA Subject: Re: OMB and ISO In-reply-to: Your message of 26 Jan 86 21:42:13 PST (Sun). <8601270542.AA29522@monet.berkeley.edu> Date: Mon, 27 Jan 86 17:54:01 -0800 Message-ID: <4930.507261241@nrtc> From: Marshall Rose Via: Nrtc; 28 Jan 86 01:38:36 Yes, well it's good I don't pay anyone for any of that info! It was yet-another-rumor-floating-around-usenix-that-I-didn't-attend-but-got-reported- back-to-me. Thanks for clearing it up, /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012704435000> Mail-From: VIVIAN created at 27-Jan-86 14:09:19 Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Sun 26 Jan 86 20:49:24-PST Date: 27-Jan-86 04:43:50-UT From: mills@dcn6.arpa Subject: Network Time Protocol update To: tcp-ip@sri-nic.arpa ReSent-Date: Mon 27 Jan 86 14:09:19-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12178665803.31.VIVIAN@SRI-NIC.ARPA> Folks, Several faithful clockwatchers who desiged and built synchronized clocks based on the RFC-958 Network Time Protocol (NTP) have suggested revisions and additions to the specification. An updated copy of RFC-958 incorporating these suggestions and others on impelmentation techniques is available for ANONYMOUS FTP in the MILLS directory at ISID and called RFC958.DOC. Mike Petry kindly pointed out a bug in the Fuzzball NTP servers which was easily fixed, but might glitz some client implementations that do not follow the RFC-958 suggestions closely. Specifically, the Fuzzball servers formerly copied the Originate Timestamp field of the request into the same field of the reply; however, for correct symmetric-mode operation, they should (and now do) copy the Transmit Timestamp field into the Originate Timestamp field instead. If unsymmetric-mode client programs copy the transmit time into all three timestamp fields of the request, as suggested in RFC-958, this change will be transparent. The following message from Milo Medin shows where updated copies of the Unix servers now live. Dave ---Beginning of forwarded message(s)--- Return-path: Received: from orion.ARPA by DCN6.ARPA ; 26-Jan-86 23:02:02-UT Received: by orion.ARPA (5.28/1.2) id AA00418; Sun, 26 Jan 86 15:01:31 PST Message-Id: <8601262301.AA00418@orion.ARPA> To: mills@dcn6.arpa Subject: Re: Star time In-Reply-To: Your message of 26-Jan-86 22:26:24-UT. <8601262237.AA00331@orion.ARPA> Date: 26 Jan 86 15:01:29 PST (Sun) From: Milo S. Medin (NASA ARC Code ED) Dave, I've fixed the code so that things work again. No big deal at all. You can tell everyone to ftp the code from orion, login anonymous password foo, and that its in pub/time, as usual. It really was pretty trivial to fix, so they might just recompile it themselves, but its available here in any case... Milo PS What all changes did you make in the fuzzball ntp server? I'd like to put them into ntpd as well. PPS Have you had a chance to attack a 4.3 implementation with a fuzzball and inspect it for glitches? I know UMD has mimsy (I believe running 4.3) and my machines of course... ---End of forwarded message(s)--- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012706225400> Mail-From: VIVIAN created at 27-Jan-86 14:24:01 Date: Mon 27 Jan 86 14:22:54-PST From: Vivian Neou Subject: Direct distribution is back To: tcp-ip@SRI-NIC.ARPA Message-ID: <12178668274.31.VIVIAN@SRI-NIC.ARPA> I think the problem with the list getting remailed back to the list has been fixed, so I'm switching the list back to a direct distribution format. Vivian ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012710373600> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Mon 27 Jan 86 15:46:52-PST Date: Mon, 27 Jan 86 15:37:36 EST From: Mike Muuss To: Henry Nussbacher cc: tcp-ip@sri-nic.arpa Subject: Re: Tp4 The only real concern about the ISO protocols is the current lack of support for security and precedence, which are defined (but only minimally implemented) in IP already. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012717170300> Received: from mitre-gateway.arpa by SRI-NIC.ARPA with TCP; Mon 27 Jan 86 19:24:59-PST Date: 27 Jan 1986 22:17:03 EST (Monday) From: T. Michael Louden (MS W422) Subject: RE: TP4 To: tcp-ip@sri-nic Cc: louden@mitre-gateway.arpa Mike Muuss missed one concern. In TCP the checksum takes 10-15% of the CPU cycles. In TP4 it takes 67%!!!! This has a big performance impact. Otherwise performance is similar. -Mike Louden Louden@MITRE ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012802414000> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Tue 28 Jan 86 04:39:17-PST Received: by cu-arpa.cs.cornell.edu (5.31/4.30) id AA00702; Tue, 28 Jan 86 07:38:43 EST Date: Tue, 28 Jan 86 07:41:40 est From: swb@devvax.tn.cornell.edu (Scott Brim) Message-Id: <8601281241.AA04680@devvax.tn.cornell.edu> Received: by devvax.tn.cornell.edu (4.12/4.30) id AA04680; Tue, 28 Jan 86 07:41:40 est To: ibm-nets%bitnic.bitnet@wiscvm.wisc.edu, tcp-ip@sri-nic.arpa Subject: Enhancing Wiscnet (For those of you who don't know what Wiscnet is: it's the University of Wisconsin's TCP/IP networking software for IBM systems running VM/SP.) We at Cornell are feeling a strong need to improve Wiscnet's overall functionality and performance. It's a great start but it's just not robust enough for heavy use in a production environment. We'd like to start up a conversation with other sites that use Wiscnet. What are your plans for fixing bugs? dealing with performance? improving reliability? adding functionality (like subnetting and ARP)? Wiscnet is becoming critical to a goodly number of users here. We would like to share not only lists of problems, but also improvements, with anyone and everyone, in order to avoid redundant effort. We're also curious about the levels of commitment and effort going on out there. How many people are in the position we are, where we absolutely have to do something about it? Is there anyone considering a total re-write of Wiscnet (we certainly are!)? If you are not, what levels of performance, reliability and functionality are you aiming for, and what are your plans for getting there? We hope this conversation will end up being highly beneficial to all of us. Please write, Thanks ...... Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012804140000> Received: from ucbvax.berkeley.edu by SRI-NIC.ARPA with TCP; Tue 28 Jan 86 12:15:39-PST Received: by ucbvax.berkeley.edu (5.44/1.9) id AA04015; Tue, 28 Jan 86 12:15:41 PST Received: from UCBCMSA.BITNET by ucbjade.Berkeley.Edu (4.19/4.41.3) id AA06675; Tue, 28 Jan 86 12:15:20 pst Message-Id: <8601282015.AA06675@ucbjade.Berkeley.Edu> Date: Tue, 28 Jan 86 12:14 PST From: Greg Minshall Subject: Enhancing Wiscnet To: swb@devvax.tn.cornell.edu Cc: ibm-nets%bitnic.bitnet@wiscvm.wisc.edu, tcp-ip@sri-nic.arpa In-Reply-To: swb at devvax.tn.cornell.edu -- Tue, 28 Jan 86 07:41:40 est Scott, I don't understand about enhancing WISCNET for ARP. It HAS ARP already. We did subnet enhancements, which we have fed back to Wisconsin. There is a need for an enhanced product, with support and continuing development. Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012805310000> Received: from MARLBORO.DEC.COM by SRI-NIC.ARPA with TCP; Tue 28 Jan 86 07:34:33-PST Date: 28 Jan 1986 1031-EST From: Kevin Paetzold To: tcp-ip@sri-nic telephone: 617-460-2203 Subject: 802.3 Message-ID: <"MS11(2502)+GLXLIB5(0)" 12178855607.18.126.6839 at MARLBORO.DEC.COM> I have a couple of questions about 802.3/802.2 TCP/IP protocol suite implementations. First off i am curious as to how ARP has been implemented under 802.3 (eg. which SAP does it use?) Does anyone know of any existing 802.3 implementation that uses the 16 bit addressing "feature" of 802.3? -------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012807301200> Received: from proteon.arpa by SRI-NIC.ARPA with TCP; Tue 28 Jan 86 09:38:48-PST Date: Tue, 28 Jan 86 12:30:12 EST From: jas@proteon.arpa Subject: Re: 802.3 In-reply-to: Your message of 28 Jan 1986 1031-EST To: PAETZOLD@MARLBORO.DEC.COM CC: tcp-ip@sri-nic.arpa I rattled this cage with respect to 802.5 a while ago. Basically, the regulators of SAP's will not provide another one of the 64 globally-defined SAP's for ARP. Period. If Tony Lauck's scheme to extend the SAP space to 48 bits goes through 802.1/802.2, then one of those would be avaiable. What currently is done by CMU for their PC/IP on the 802.5 board is to just steal one of the "unadministered" SAP's. Any SAP with the low two bits 0 is unadministered, and not a broadcast SAP. What we need to do is wait for IBM to publish which unadministered SAP's they used for SNA. When that happens, we know which ones to dodge, and can just use some other one for the time being. I don't know exactly which SAP CMU used. Do you remember, Drew? John Shriver Proteon ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012808230300> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Tue 28 Jan 86 10:23:26-PST Date: Tue, 28 Jan 86 13:23:03 EST From: Mike Muuss To: tcp-ip@sri-nic.arpa cc: DCAb602@ddn1.arpa Subject: Bad Network Performance From 1312 to 1315 today (Tuesday 28-Jan-86), I was obtaining wretched service from the network, between BRL and Berkeley. PINGing between BRL-SAW (192.5.23.33) and UCBVAX.berkeley.edu (10.2.0.78) ----ucbvax.berkeley.edu PING Statistics---- 198 packets transmitted, 82 packets received, 58% packet loss round-trip (ms) min/avg/max = 6500/18939/28080 An average of 18.9 seconds from Maryland to California! Awful! The only thing that I could reliably determine was that the problem was not on our end; PINGs from SAW to BRL-GATEWAY ran at a constant 10-20 ms, and PING from SAW to BRL-TAC (which includes the Gateway->IMP access line, and MILNET IMP --> MILNET TAC) were running 50-80 ms. This rules out interface blocking or processor overload in our gateway. Anybody care to speculate on the cause of this? Any indications as to future trends? -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012812255900> Received: from PT.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Tue 28 Jan 86 14:25:48-PST Received: from CMU-ANDREW by PT.CS.CMU.EDU; 28 Jan 86 17:16:20 EST Message-Id: <8601282226.AA00224@cmu-andrew> Received: by cmu-andrew (4.12/3.15) id AA00224; Tue, 28 Jan 86 17:26:56 est Date: Tue, 28 Jan 86 17:25:59 EST From: John Leong Subject: Re: 802.3 To: Kevin Paetzold Cc: tcp-ip@sri-nic.arpa, postel@usc-isif.arpa, ira%upenn.csnet@csnet-relay.arpa We have TCP-IP running on the PC's (PC, PC-XT, PC-AT and the PC-RT) using the IBM (802.5 superset) token ring. During the implementation, we encountered the problem of assigning SAP to ARP. After a number of exchanges with Postel and Ira Winston (aurthor of RFC 948), we came to a conclusion that this is not going to get resolved in a hurry, we just pick a random number for ARP for our implementation. The way I will like to see it done is as follows : [using the bit ordering convention as defined in fig.3-2a of IEEE 802.2-1985 spec] For IP packets : DSAP 01 10 0000 SSAP 00 10 0000 For ARP packets : DSAP 01 10 0000 SSAP 00 01 0000 This is really to say, in view of the fact that SAP is really used as protocol ID, having two SAP fields is pretty redundant. (Can't image an SNA SAP meaningfully sending to an IP SAP). In which case, we bastardise the SSAP field to denote whether the IP 'family' packet [as denoted by the DSAP] is for IP or ARP or IP trailer or whatever ..... This does not conflict with any standard since (1) 802.2 does not define the relationship between DSAP and SSAP and (2) our SSAP encoding does not conflict with 802.2 standard. I will like to receive comment from on the above and if I do not get jump upon too heavily, I may submit it as an RFC (amendment to 948). John Leong@* leong@@h.cs.cmu.edu P.S. In RFC943 (Assigned Number), the DSAP for IP is given as binary 0110000 or decimal 96. It is actually incorrect. It is really 01100000 in IEEE terminology or 00000110 in binary or 6 in decimal. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012815255500> Received: from proteon.arpa by SRI-NIC.ARPA with TCP; Tue 28 Jan 86 17:34:13-PST Date: Tue, 28 Jan 86 20:25:55 EST From: jas@proteon.arpa Subject: Re: Re: 802.3 In-reply-to: Your message of Tue, 28 Jan 86 17:25:59 EST To: leong%ANDREW@PT.CS.CMU.EDU CC: tcp-ip@sri-nic.arpa The last 802.2 / 802.1 meeting approved Tony Lauck's extension scheme for SAPs. Basically, if you have a DSAP of 01010101 (10101010 for those of us who think forwards, or AA hex), then the next 5 (?) bytes of the packet after the SAPs are an extension of the DSAP. These would be administered just like the 48-bit addresses. Now we need to find out how to get a 48-bit DSAP for ARP. Of course, I hate variable length headers, and we could steal an unadministered DSAP. I, too, am completely mystified by the use and purpose of SSAPs. I would not want to jump too quickly at the scheme of stealing it, as CMU went through the 802.5 interface to the IBM board, rather than the 802.2 interface. It works, but is it really the cleanest way to go. IBM may not allow you to demulitplex on DSAP and SSAP, or may not pass up the SSAP to the network layer. I bet we need to wait until IBM releases the manuals, which apparently wont't be until April 1, 1986. (Some definition of first quarter 1986!) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012903270000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Wed 29 Jan 86 20:07:59-PST Received: from upenn by csnet-relay.csnet id a021950; 29 Jan 86 22:49 EST From: Ira Winston Subject: Re: 802.3 To: John Leong , Kevin Paetzold Cc: tcp-ip%sri-nic.arpa@csnet-relay.arpa, postel%usc-isif.arpa@csnet-relay.arpa, ira%upenn.csnet@csnet-relay.arpa Date: Wed, 29 Jan 86 08:27 EST I have heard that the IEEE committee is considering an extension that defines a special SAP value to handle Ethernet protocol types. When the SAP is set to this special value, the Ethernet protocol type appears later in the packet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012914301000> Received: from PT.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Wed 29 Jan 86 16:35:34-PST Received: from CMU-ANDREW-PO2 by PT.CS.CMU.EDU; 29 Jan 86 19:31:26 EST Message-Id: <8601300032.AA01351@cmu-andrew-po2> Received: by cmu-andrew-po2 (4.12/3.15) id AA01351; Wed, 29 Jan 86 19:32:01 est Date: Wed, 29 Jan 86 19:30:10 EST From: John Leong Subject: Re : 802.2 To: jas@proteon.arpa Cc: tcp-ip@sri-nic.arpa If Tony Lauck's managed to get the SAP extension scheme accepted by IEEE, I think we should consider adopting it. [ I also dislike variable length header, but then IP header is also variable (sigh) ] . Who in the TCP/IP community will grap a 48 bit SAP for ARP (and one for trailer protocol, and why not get one also for IP for the extended format too ....) ???? P.S. : In our IBM token ring implementations, all IP packets are encapsulated by 802.2 LLC headers. We did not go directly 802.5 interface. (Again, the SAP number for ARP we used is bogus) P.P.S. : For general interest, the IBM token ring interface cards for the IBM PC and the RT is different. The PC uses IBM's own chip set while the RT's interface is OEM'ed from TI and uses TI's chipset. The RT version is higher performance and can also be used with the AT (since the RT has an AT bus). Amazingly, both cards work well together in the same ring. We run MIT PCIP (and derivatives) in the PC and 4.2 in the RT. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012914580000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Thu 30 Jan 86 19:43:10-PST Received: from (JARRELLR)VTVAX3.BITNET by WISCVM.WISC.EDU on 01/30/86 at 21:40:46 CST Date: Thu, 30-JAN-1986 22:38 EST From: Ronald A. Jarrell To: Subject: tcp/ip implementations I'm sure this has been asked before, but we are in the middle of trying to come up with a configuration proposal for our multiple systems, with an eye towards getting an internet connection. Would people send me directly their recomendations on tcp/ip packages for the following system types: IBM 30xx series running VM/SP 3 or 4 and CMS VAX 7xx and 8xxx series running VMS 4.2 VAX 11/785 running Ultrix 1.1 Vax 11/785 running System V (I realize that the Ultrix supports tcp/ip.. I was thinking in terms of enhanced performance packages for that system..) Our environment is/will be all the Vaxen and some other unix-based workstations on ethernet. The IBM is not substantially connected. We'd really like to put an internet connection if we get one on the IBM and one VMS machine. Any suggestions? Once again, please send them to me.. If there's sufficient interest I'll summarize and post to the list. Thanks! Ron Jarrell Systems Programming Department Va Tech ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986012919470400> Received: from trantor.UMD.EDU by SRI-NIC.ARPA with TCP; Wed 29 Jan 86 21:46:58-PST Received: by trantor.UMD.EDU (5.5d/umd.04) id AA11617; Thu, 30 Jan 86 00:47:04 EST Date: Thu, 30 Jan 86 00:47:04 EST From: Louis A. Mamakos Message-Id: <8601300547.AA11617@trantor.UMD.EDU> To: tcp-ip@sri-nic.arpa Subject: Attention clockwatchers There's a newly installed Spectracom WWVB clock on UMD1.UMD.EDU available for your (ab)use. This clock should normally be synchronized to WWVB; when the radio link goes down, there is an automatic fallback to synchronize to DCN1.ARPA, also with its own WWVB clock. You can politely ask UMD1 for the time using ICMP echos, UDP time server and an NTP timerserver. You can also connect to the TCP timeserver port, but this is discouraged. UMD1.UMD.EDU is a fuzzball for those of you interested in such things. Its clock configuration is very similar to that on DCN1.ARPA. Enjoy. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986013004193700> Received: from nosc.ARPA by SRI-NIC.ARPA with TCP; Thu 30 Jan 86 12:25:04-PST Received: from cod.ARPA by nosc.ARPA (4.17/4.7) id AA02582; Thu, 30 Jan 86 12:20:57 pst Received: by cod.ARPA (5.31/4.7) id AA08261; Thu, 30 Jan 86 12:23:56 PST Date: Thu, 30 Jan 86 12:19:37 pst From: gould9!joel@nosc.ARPA (Joel West @ CACI) Message-Id: <8601302019.AA02252@gould9> Received: by gould9 (4.12/4.7) id AA02252; Thu, 30 Jan 86 12:19:37 pst Organization: CACI, Inc. -- La Jolla (home of SIMSCRIPT II.5) Xuucp-Path: {ihnp4,cbosgd,pyramid,sdcsvax}!gould9!joel Xarpa-Path: gould9!joel@nosc Subject: alleged TCP/IP controversy in BSD 4.3 Newsgroups: mod.protocols.tcp-ip To: tcp-ip@sri-nic.ARPA Keywords: UNIX Review As I recall, last summer BSD 4.3 was just "a few months away". It's still not out. David Chandler writes an article in UNIX Review (January 1986, p. 8) in which he claims to have an answer. The delay, Chandler writes, was caused by conflicts over the version of TCP/IP to be included in 4.3. According to Chandler: * the 4.2 TCP/IP was BBN code rewritten by UCB; * BBN then encouraged people to use an enhanced BBN code * DARPA decided only ONE of these would be allowed for 4.3 * after much vacillation, DARPA chose UCB for political and technical reasons. For more on this, see the mag. Joel West CACI, Inc. Federal, La Jolla {cbosgd,floyd,ihnp4,pyramid,sdcsvax,ucla-cs}!gould9!joel gould9!joel@nosc.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986013009415700> Received: from SRN-VAX.ARPA ([128.89.0.81]) by SRI-NIC.ARPA with TCP; Thu 30 Jan 86 11:41:56-PST Date: Thu, 30 Jan 86 14:41:57 EST From: Ross Callon To: tcp-ip@SRI-NIC.ARPA cc: leong%ANDREW@PT.CS.CMU.EDU, PAETZOLD@MARLBORO.DEC.COM, rcallon@SRN-VAX.ARPA Subject: on SAPs The same scheme for combined use of SSAPs and DSAPs was discussed in 802 several years ago, and was heavily beat upon, primarily on the basis that it conflicted with the reference model. SAPs should be significant in the context of the rest of the associated address, not in the context of the other specified SAP. For example, suppose the ultimate other end of the connection is not on the same LAN, but is on some other LAN that does not follow your convention. In this case you won't be able to figure out what to do. Also, since the SAP is supposed to be a continuation of the address, for traffic in the other direction you would expect to continue to associate each SAP value with the same address, (i.e., when you exchange source and destination addresses for return traffic you would also exchange SAP values). This of course wouldn't work with the proposed scheme. If you used the alternate scheme in which each SAP by itself identifies the user protocol, then these problems don't occur. For example, suppose that you use an explicit mapping between the SAP and the protocol, and the other end uses some other scheme (such as table lookup, or it implements only one protocol and uses the user specified part of the SAP for some other purpose). Here when you receive a packet you can determine what protocol it contains, and know what addresses to use for return packets. Originally the 802 standards were not going to include any SAPs at all. When the idea first came up I suggested that there was an alternate idea of a "user protocol" field that would eliminate the redundancy of having the same field twice. This was rejected quickly, partly on the rather compelling grounds that saving a single octet on a multi-megabit LAN didn't seem very important. Ross Callon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986013011090800> Received: from MARLBORO.DEC.COM by SRI-NIC.ARPA with TCP; Thu 30 Jan 86 13:11:59-PST Date: Thu 30 Jan 86 16:09:08-EST From: Kevin Paetzold Subject: more on saps To: tcp-ip@SRI-NIC.ARPA Message-ID: <12179441278.19.PAETZOLD@MARLBORO.DEC.COM> Thanks to all of you who replied to my original message on this subject. The whole 802.3/802.2 SAP issue seems like a major can of worms. I find it amazing that the IEEE and ISO could not come up with a better scheme or at least a scheme that allows more than 64 assigned SAPs!. I also find it amazing that the bureaucrats involved do not find ARP important enough to allocate its own SAP. Apparently the ISO networking world believes that it is never going to have any address mapping problems (or any other problems that ARP solves) due to great foresight. Having 64 SAPs available did not however indicate a lot of foresight. If this message sounds like a flame then so be it. I think the TCP/IP community should really push to get a SAP assigned to ARP. This issue seems like a major non technical stumbling block preventing wider acceptance of 802.3 (at least in this community). ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986013019212600> Received: from RED.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Fri 31 Jan 86 23:17:10-PST Date: 31 Jan 86 00:21:26 EST From: Stephen Carter Subject: TOP Subcommittee's Formed To: tcp-ip@SRI-NIC.ARPA, iso@ACC.ARPA Message-ID: <12179530900.7.SCARTER@RED.RUTGERS.EDU> I am sending a copy of this to the tcp folks as I thought some of them may be interested. Just received this in the USnail.. To: Top Participants [ of the TOP User's meeting in Seattle in December] From: Victor Lukasik, Vice Chair of TOP Technical and Test Subject: TOP Subcommittee's Formed TOP Executive Committee announces the formation of TOP Technical Subcommittees. The TOP Technical Subcommittees will address standards for the technical and office environment. The subcommittees formed are: - TOP Document Exchange - TOP Electronic Mail - TOP Graphics Exchange - TOP Physical Layer - TOP Product Data - TOP Virtual Terminal All interested vendors and user companies are asked and encouraged to join. Membership in the TOP technical subcommittee(s) is open to any individual with an interest to contribute to either defining standards, or equally important, to provide clear user requirement definitions to the vendor community. ....[for more info, contact Victor Lukasik- phone given below] The first TOP Technical and Test Review Meeting has been scheduled for Thursday, February 6, 1986 in Seattle, Washington. These meetings will primarily be a summation by each of the [..] chairs of work done to date, and planned work items. All are invited to attend these sessions to receive a status of current work activities, and have a forum to provide input to the technical activities of TOP. [Last paragraph states that these meetings will be the first Thursday of each month unless there is a MAP/TOP User's meeting in that month and they will held at that meeting instead....] If you are interested in this, the subcommittees will be meeting in Seattle on February 5th (with the exception of the Physical Layer which will be held January 30 in Austin, Tx.). For more info, contact person listed: Physical Layer (Jan 30) -- Arthur Miller (512) 440-2119 Electronic Mail -- Victor Lukasik (206) 763-5457 Document Exchange -- Frank Dawson (314) 232-5251 Product Data Exchange -- Herbert Ryan (314) 234-5161 Virtual Terminal -- Davis Dowlin (206) 763-5457 Graphics Exchange -- no chair yet, contact Victor above. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986013103270000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Fri 31 Jan 86 12:03:28-PST Date: 31 Jan 86 11:27:00 PST From: Subject: TCP port question To: "tcp-ip" Reply-To: I thought that I would forward this to tcp-ip for comment. ------------------------------------------------------------------------ > From: SAGE::KEITH 30-JAN-1986 05:59 > To: ART,KEITH > Subj: > > Hi Art, > > Can I ask you a TCP Question ? It concerns our TCP implementation, the > one in SIMON, and in the SPOT-FE (IBM-Ethernet I/F). We return a parameter > error to the caller of TCP if an Active-Open is issued with local Port = 0. > The guys at Ford had trouble with using low-valued ports on their > 4.2bsd on a Sun workstation (authorization problems, I think). So they > tried using port 0. Unix was apparently quite happy for them to issue an > Open for Port-0. So when they called us they were wondering why we gave > their IBM program a parameter error. BSD UNIX reserves TCP ports 1-1023 (well known ports) as privileged, which only super-user is allowed to bind. If someone tries to bind to local port 0, the socket is bound to an unused port > 1023. This would make a listen to port 0 of little use (because the active end does not know the actual port). > > I can find nothing prohibiting Port-0 in any TCP Spec. However, RFC-943 > (Assigned Numbers) lists Port-0 as Reserved, so nobody is supposed to listen > on it. In terms on defensive programming, a zero is the most probable > value which could result from a bug in a ULP. > > Any suggestions ? Should we remove our restriction on Port-0, or suggest > it to the TCP Community ? > > Keith. I would discourage use of port 0. ------ ----MESSAGE-END----