----MESSAGE-BEGIN---- [9533%40ucbvax.ARPA] <1985080106261900> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Beta release announcement for Sperry 1100 TCP/IP software Message-ID: <9533@ucbvax.ARPA> Date: Thu, 1-Aug-85 10:26:19 EDT Article-I.D.: ucbvax.9533 Posted: Thu Aug 1 10:26:19 1985 Date-Received: Sat, 3-Aug-85 04:05:27 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 39 From: louie@trantor.arpa (Louis A. Mamakos) A beta-test release of the IP/TCP-1100 package is now available from the University of Maryland. IP/TCP-1100 is DoD standard IP and TCP networking software for the Sperry 1100 series mainframes. It includes the standard servers for TELNET, FTP and SMTP. Client programs for TELNET and an SMTP mailer are also included. The client FTP program is not yet ready for release. In addition, client and user MDQS programs are included to communicate with their peers on UNIX hosts. MDQS is a network based queuing system developed at BRL. An electronic mail system for the Sperry is also supplied as part of the package. The package will run on 1100/80, 1100/80A, 1100/60 with EIS, 1100/70 with EIS and 1100/90 systems. It will not run on 1110, 1108, 1100/10, 1100/20 or 1100/40 systems. OS1100 version 38R5 or later is required. The only network interfaces currently in use are a simple bytestuffing sync driver for a GCS CTS STD or CTMC CTM 6. This is used to talk to one of Dave Mills' fuzzball systems. The other uses the Front End Handler feature of the EXEC to connect a Word channel to a UNIBUS word channel interface. The board is custom hardware developed at NOSC. Drivers for 4.2 and 4.3 BSD are available. A driver for the DCP is not provided. The software *is* a beta release; the documentation is not complete, and some network and Sperry 1100 wizardary will be required. The software is available on an as-is basis, with no support provided or implied. So much for the disclamers. For details in obtaining the package, send mail to or The price is free; you send me a tape, and I send it back to you with the software and documentation (such as it is). If you find bugs, I'd be glad to hear about them (even more glad if a fix is included), but I cannot make any promises about fixing the bugs in a timely fashon. Louis A. Mamakos Computer Science Center University of Maryland ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080212343100> Received: from EDN-VAX.ARPA by SRI-NIC.ARPA with TCP; Fri 2 Aug 85 13:35:04-PDT Received: by EDN-VAX.ARPA (4.12/4.7) Date: Fri, 2 Aug 85 16:34:31 edt From: swanson@EDN-VAX (John Swanson) To: tcp-ip@sri-nic We have just brought Unix 4.2 on a VAX that does not currently have a network interface of any kind. Could anyone tell me if there is a way to configure the IP routing so that we can proceed with strictly internal loopback until our interface shows up? Thanks John Swanson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080416132300> Received: from MIT-XX.ARPA by SRI-NIC.ARPA with TCP; Mon 5 Aug 85 09:44:01-PDT Date: Sun 4 Aug 85 20:13:23-EDT From: Lixia Zhang Subject: Re: Withholding Acks To: DCP@SCRC-QUABBIN.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "David C. Plummer in disguise " of Wed 31 Jul 85 13:01:51-EDT Dave, Thanks for your msg. From yours and other replies I got, it seems that I didn't make the inquiry clear. By withholding acks I mean WITHHOLDING ACKs, i.e. do not acknowledge every incoming data segment so that the total number of acks sent out will be smaller that the number of incoming data packets. From your msg, "The Symbolics implementation for 3600s sets a flag in a connection saying "send an ack when you get a chance." Therefore, we do withhold ACKs in a sense." Do you mean the acks are polled by the sender only (i.e. the receiving end does not ack until it sees a flag) ? Withholding window enlargement may have an effect, but surely the two are not the same. I'm more concerned with the internet data traffic. I don't know how much percentage of the total is due to the acknowledgment packets. For telnet connections it is possible to do piggybacking (how well this is done is still up to the implementation), but for FTP or mail data basically flow in one direction only, do they generate as many acks as data pkts or substantially less? Lixia ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080418585500> Received: from columbia.arpa by SRI-NIC.ARPA with TCP; Mon 5 Aug 85 14:18:39-PDT Received: from CU20B.ARPA by columbia.arpa; Sun, 4 Aug 85 22:58:45 edt Received: from CWR20B by CU20B with DECnet; 4 Aug 85 22:59:10 EDT Date: Sun 4 Aug 85 22:58:55-EDT From: Asheem Subject: TCP/IP - DECNET Conversion. To: TCP-IP:; Reply-To: chandna%cwr20b@cmu-cc-te.arpa Hi, Does anyone know if any protocol conversion work has been done between DECNET and TCP/IP ? I'm a Senior in Electrical Engineering at Case Western Reserve University and am considering doing a Senior Project on DECNET - TCP/IP conversion. I'd appreciate any comments, advice, referrals etc. on this topic as well as on the feasibility of doing this as a year long senior project. Thanks. ^Asheem Chandna. Please reply to : CHANDNA%CWR20B@CMU-CC-TE.ARPA ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080506420000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Mon 5 Aug 85 13:40:03-PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 289144; Mon 5-Aug-85 10:40:30-EDT Date: Mon, 5 Aug 85 10:42 EDT From: David C. Plummer in disguise Subject: Re: Withholding Acks To: Lixia Zhang , DCP@SCRC-QUABBIN.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: The message of 4 Aug 85 20:13-EDT from Lixia Zhang Message-ID: <850805104259.5.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Sun 4 Aug 85 20:13:23-EDT From: Lixia Zhang Dave, Thanks for your msg. From yours and other replies I got, it seems that I didn't make the inquiry clear. By withholding acks I mean WITHHOLDING ACKs, i.e. do not acknowledge every incoming data segment so that the total number of acks sent out will be smaller that the number of incoming data packets. From your msg, "The Symbolics implementation for 3600s sets a flag in a connection saying "send an ack when you get a chance." Therefore, we do withhold ACKs in a sense." Do you mean the acks are polled by the sender only (i.e. the receiving end does not ack until it sees a flag) ? Withholding window enlargement may have an effect, but surely the two are not the same. I'm more concerned with the internet data traffic. I don't know how much percentage of the total is due to the acknowledgment packets. For telnet connections it is possible to do piggybacking (how well this is done is still up to the implementation), but for FTP or mail data basically flow in one direction only, do they generate as many acks as data pkts or substantially less? Here's a more detailed description of how we do it. When new data arrives, an flag is set which says "this connection has data that has not been acked." When an ack is sent for any reason, the flag is cleared. There is a timer (currently set at .1 seconds) that will cause the ack to be sent if the flag is set. .1 seconds was choosen to be long enough to gather other data and ACK an entire group and short enough so the other wide won't retransmit a longer packet. Acks are also sent with window enlargments (per silly window avoidance). Under normal high traffic conditions, this is the normal case. Data is normally received and gobbled and the window is enlarged faster than the .1 second timeout. I believe an ack is also sent when the input queue becomes empty. Under this strategy, with 1500 byte Ethernet packets, 20Kbyte window, we normally see 1 outgoing ACK (very small packets) for every 3 incoming (large) segments. We also see very few retransmissions because of timeouts. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080509593000> Mail-From: KLH created at 5-Aug-85 17:00:25 Date: Mon 5 Aug 85 16:59:30-PDT From: Ken Harrenstien Subject: Re: Withholding Acks To: MILLS@USC-ISID.ARPA, Lixia@MIT-XX.ARPA, DCP@SCRC-QUABBIN.ARPA cc: tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: Message from "MILLS@USC-ISID.ARPA" of Mon 5 Aug 85 18:01:29-PDT For what it's worth, the ITS implementation of TCP/IP uses an ACK strategy almost identical to that described by DCP and Mills. The timeout is likewise at most 1/2 second, although there is no attempt to be precise about it. I guess I am surprised to hear that there are systems which do not work this way. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9671%40ucbvax.ARPA] <1985080510103700> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: Withholding Acks Message-ID: <9671@ucbvax.ARPA> Date: Mon, 5-Aug-85 14:10:37 EDT Article-I.D.: ucbvax.9671 Posted: Mon Aug 5 14:10:37 1985 Date-Received: Tue, 6-Aug-85 11:04:22 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 27 From: Lixia Zhang Dave, Thanks for your msg. From yours and other replies I got, it seems that I didn't make the inquiry clear. By withholding acks I mean WITHHOLDING ACKs, i.e. do not acknowledge every incoming data segment so that the total number of acks sent out will be smaller that the number of incoming data packets. From your msg, "The Symbolics implementation for 3600s sets a flag in a connection saying "send an ack when you get a chance." Therefore, we do withhold ACKs in a sense." Do you mean the acks are polled by the sender only (i.e. the receiving end does not ack until it sees a flag) ? Withholding window enlargement may have an effect, but surely the two are not the same. I'm more concerned with the internet data traffic. I don't know how much percentage of the total is due to the acknowledgment packets. For telnet connections it is possible to do piggybacking (how well this is done is still up to the implementation), but for FTP or mail data basically flow in one direction only, do they generate as many acks as data pkts or substantially less? Lixia ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080512143200> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Mon 5 Aug 85 13:59:45-PDT Date: 5 Aug 1985 16:14:32 EDT From: MILLS@USC-ISID.ARPA Subject: Re: Withholding Acks To: Lixia@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA cc: MILLS@USC-ISID.ARPA In response to the message sent Tue 30 Jul 85 10:57:15-EDT from Lixia@MIT-XX.ARPA Lixia, We know this as the "ack policy." This interacts with the "send policy" (see MIL-STD-1778) in interesting ways, as we have found when experimenting with the send policy first suggested by John Nagle and previously reported to the tcp-ip list. Specifically, our fuzzballs transmit an ack in response to a tcp segment: 1. Immediately if the segment is entirely outside the receive window. 2. Immediately if the number of octets delivered to the user (sequence advanced at the right-window edge) is at least a magic number (currently the MSS of the connection) since the last ack. 3. After a short magic-number delay (currently 500 milliseconds) since the last segment that advanced the left-window edge with no intervening ack. The intent is to withold acks for short (interactive) segments to encourage piggybacking, both for acks and echoes, while supporting maximum throughput for large segments and low-delay nets. I am not entirely happy with the above, since segments that are a weenie bit shorter than MSS get poor treatment in both the send and ack policies. An ingenious adaptive strategy might be considered for trial. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9680%40ucbvax.ARPA] <1985080513540000> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: Withholding Acks Message-ID: <9680@ucbvax.ARPA> Date: Mon, 5-Aug-85 17:54:00 EDT Article-I.D.: ucbvax.9680 Posted: Mon Aug 5 17:54:00 1985 Date-Received: Tue, 6-Aug-85 12:33:13 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 51 From: David C. Plummer in disguise Date: Sun 4 Aug 85 20:13:23-EDT From: Lixia Zhang Dave, Thanks for your msg. From yours and other replies I got, it seems that I didn't make the inquiry clear. By withholding acks I mean WITHHOLDING ACKs, i.e. do not acknowledge every incoming data segment so that the total number of acks sent out will be smaller that the number of incoming data packets. From your msg, "The Symbolics implementation for 3600s sets a flag in a connection saying "send an ack when you get a chance." Therefore, we do withhold ACKs in a sense." Do you mean the acks are polled by the sender only (i.e. the receiving end does not ack until it sees a flag) ? Withholding window enlargement may have an effect, but surely the two are not the same. I'm more concerned with the internet data traffic. I don't know how much percentage of the total is due to the acknowledgment packets. For telnet connections it is possible to do piggybacking (how well this is done is still up to the implementation), but for FTP or mail data basically flow in one direction only, do they generate as many acks as data pkts or substantially less? Here's a more detailed description of how we do it. When new data arrives, an flag is set which says "this connection has data that has not been acked." When an ack is sent for any reason, the flag is cleared. There is a timer (currently set at .1 seconds) that will cause the ack to be sent if the flag is set. .1 seconds was choosen to be long enough to gather other data and ACK an entire group and short enough so the other wide won't retransmit a longer packet. Acks are also sent with window enlargments (per silly window avoidance). Under normal high traffic conditions, this is the normal case. Data is normally received and gobbled and the window is enlarged faster than the .1 second timeout. I believe an ack is also sent when the input queue becomes empty. Under this strategy, with 1500 byte Ethernet packets, 20Kbyte window, we normally see 1 outgoing ACK (very small packets) for every 3 incoming (large) segments. We also see very few retransmissions because of timeouts. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080514012900> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Mon 5 Aug 85 15:03:13-PDT Date: 5 Aug 1985 18:01:29 EDT From: MILLS@USC-ISID.ARPA Subject: Re: Withholding Acks To: Lixia@MIT-XX.ARPA, DCP@SCRC-QUABBIN.ARPA cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA In response to the message sent Sun 4 Aug 85 20:13:23-EDT from Lixia@MIT-XX.ARPA Lixia, Further to my previous message, the fuzzy ones do in fact produce fewer acks than received segments on average, far fewer in the case of tinygram (interactive) traffic due to the 500-millisecond left-window edge delay. In typical character-at-a-time traffic with TELNET, twinkling on the keys results in no unpiggybacked acks at all - just tinygrams. The send policy and ack policy then result in a packet exchange between the user and server every 500 milliseconds with whatever queues up in the interval in the segment. Watch a Unix, TOPS-20 or especially a PCIP for somewhat less efficient behavior (!). Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9685%40ucbvax.ARPA] <1985080514583300> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: Withholding Acks Message-ID: <9685@ucbvax.ARPA> Date: Mon, 5-Aug-85 18:58:33 EDT Article-I.D.: ucbvax.9685 Posted: Mon Aug 5 18:58:33 1985 Date-Received: Tue, 6-Aug-85 12:34:34 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 30 From: MILLS@USC-ISID.ARPA In response to the message sent Tue 30 Jul 85 10:57:15-EDT from Lixia@MIT-XX.ARPA Lixia, We know this as the "ack policy." This interacts with the "send policy" (see MIL-STD-1778) in interesting ways, as we have found when experimenting with the send policy first suggested by John Nagle and previously reported to the tcp-ip list. Specifically, our fuzzballs transmit an ack in response to a tcp segment: 1. Immediately if the segment is entirely outside the receive window. 2. Immediately if the number of octets delivered to the user (sequence advanced at the right-window edge) is at least a magic number (currently the MSS of the connection) since the last ack. 3. After a short magic-number delay (currently 500 milliseconds) since the last segment that advanced the left-window edge with no intervening ack. The intent is to withold acks for short (interactive) segments to encourage piggybacking, both for acks and echoes, while supporting maximum throughput for large segments and low-delay nets. I am not entirely happy with the above, since segments that are a weenie bit shorter than MSS get poor treatment in both the send and ack policies. An ingenious adaptive strategy might be considered for trial. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9686%40ucbvax.ARPA] <1985080515531900> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: TCP/IP - DECNET Conversion. Message-ID: <9686@ucbvax.ARPA> Date: Mon, 5-Aug-85 19:53:19 EDT Article-I.D.: ucbvax.9686 Posted: Mon Aug 5 19:53:19 1985 Date-Received: Tue, 6-Aug-85 12:34:59 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 20 From: Asheem Hi, Does anyone know if any protocol conversion work has been done between DECNET and TCP/IP ? I'm a Senior in Electrical Engineering at Case Western Reserve University and am considering doing a Senior Project on DECNET - TCP/IP conversion. I'd appreciate any comments, advice, referrals etc. on this topic as well as on the feasibility of doing this as a year long senior project. Thanks. ^Asheem Chandna. Please reply to : CHANDNA%CWR20B@CMU-CC-TE.ARPA ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9689%40ucbvax.ARPA] <1985080516494500> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: Withholding Acks Message-ID: <9689@ucbvax.ARPA> Date: Mon, 5-Aug-85 20:49:45 EDT Article-I.D.: ucbvax.9689 Posted: Mon Aug 5 20:49:45 1985 Date-Received: Tue, 6-Aug-85 12:40:28 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 18 From: MILLS@USC-ISID.ARPA In response to the message sent Sun 4 Aug 85 20:13:23-EDT from Lixia@MIT-XX.ARPA Lixia, Further to my previous message, the fuzzy ones do in fact produce fewer acks than received segments on average, far fewer in the case of tinygram (interactive) traffic due to the 500-millisecond left-window edge delay. In typical character-at-a-time traffic with TELNET, twinkling on the keys results in no unpiggybacked acks at all - just tinygrams. The send policy and ack policy then result in a packet exchange between the user and server every 500 milliseconds with whatever queues up in the interval in the segment. Watch a Unix, TOPS-20 or especially a PCIP for somewhat less efficient behavior (!). Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9693%40ucbvax.ARPA] <1985080517433000> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: Withholding Acks Message-ID: <9693@ucbvax.ARPA> Date: Mon, 5-Aug-85 21:43:30 EDT Article-I.D.: ucbvax.9693 Posted: Mon Aug 5 21:43:30 1985 Date-Received: Tue, 6-Aug-85 11:53:00 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 8 From: Ken Harrenstien For what it's worth, the ITS implementation of TCP/IP uses an ACK strategy almost identical to that described by DCP and Mills. The timeout is likewise at most 1/2 second, although there is no attempt to be precise about it. I guess I am surprised to hear that there are systems which do not work this way. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080601393600> Received: from Xerox.ARPA by SRI-NIC.ARPA with TCP; Tue 6 Aug 85 08:42:24-PDT Received: from PinotNoir.ms by ArpaGateway.ms ; 06 AUG 85 08:39:40 PDT Sender: cherry.Pasa@Xerox.ARPA Date: 6 Aug 85 08:39:36 PDT (Tuesday) Subject: Re: X.25 implementation needed In-reply-to: <8508010125.AA01055@ut-ngp.ARPA> To: mknox@ut-ngp.ARPA cc: tcp-ip@sri-nic.ARPA From: Cherry.pasa@Xerox.ARPA Message-ID: <850806-083940-1179@Xerox> I am running Unisoft System 5 and I found that TCP/IP, X.25, and some other networking bin files came with it (no docs, naturally). If you have recon rights, check for /usr/include/x25lib.h and /usr/include/sys/x25*.h. In /usr/lib/net (?) were the necessary pieces to put it all together. It operates via one of my SCC chips (serial communications controller). and get this, Unisoft didn't even know it was there! B.C. & Zot------>* ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9703%40ucbvax.ARPA] <1985080608455100> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: X.25 implementation needed Message-ID: <9703@ucbvax.ARPA> Date: Tue, 6-Aug-85 12:45:51 EDT Article-I.D.: ucbvax.9703 Posted: Tue Aug 6 12:45:51 1985 Date-Received: Sat, 10-Aug-85 20:30:53 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 16 From: Cherry.pasa@Xerox.ARPA I am running Unisoft System 5 and I found that TCP/IP, X.25, and some other networking bin files came with it (no docs, naturally). If you have recon rights, check for /usr/include/x25lib.h and /usr/include/sys/x25*.h. In /usr/lib/net (?) were the necessary pieces to put it all together. It operates via one of my SCC chips (serial communications controller). and get this, Unisoft didn't even know it was there! B.C. & Zot------>* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080707432900> Mail-From: KLH created at 7-Aug-85 14:44:19 Date: Wed 7 Aug 85 14:43:29-PDT From: Ken Harrenstien Subject: [CLYNN@BBNA.ARPA: Re: [Ken Harrenstien : It's definite - TOP...] To: tops-20@SU-SCORE.ARPA cc: tcp-ip@SRI-NIC.ARPA Here is another TOPS-20 TCP/IP bug fix, thanks to Charlie Lynn. We have been running the fixes at SRI-NIC for a couple days and I haven't seen any instances yet of the lossage that previously plagued us - sometimes duplicate data would be received on a TCP connection. This is annoying for TELNET, and highly dangerous for FTP! I believe this bug also explains the phenomenon of duplicate text being received on a telnet connection to 4.2BSD systems, which some time ago was mentioned and was blamed (wrongly, it appears) on a defective 4.2BSD server telnet implementation. Proof of TOPS-20 lossage came from testing connections to MIT-MC while using the ITS packet logging features. --KLH --------------- Return-Path: Received: from BBNA.ARPA by SRI-NIC.ARPA with TCP; Thu 1 Aug 85 10:46:33-PDT Date: 1 Aug 1985 13:49-EDT Sender: CLYNN@BBNA.ARPA Subject: Re: [Ken Harrenstien : It's definite - TOP... From: CLYNN@BBNA.ARPA To: KLH@SRI-NIC.ARPA Cc: clynn@BBNA.ARPA Message-ID: <[BBNA.ARPA] 1-Aug-85 13:49:21.CLYNN> In-Reply-To: The message of Sun 28 Jul 85 05:05:02-PDT from Ken Harrenstien Ken, Enough of the pieces fit for me to conclude that the duplication problem you documented is an instance of an old bug (it was fixed by the time BBN gave DEC updated files in October '84, but they haven't been distributed). The scenario of what is happening is that when a packet (e.g., ID 77475 in your example) is emptied and a buffer is simultaneously filled (e.g., PUSH was set) and another packet is available (77476) but there are no available buffers, then the "partial packet" flag (TRPP) is being set with a "processed byte count" (TRCBY) of zero. Then, when no buffer has yet been made available (e.g., slow net/output to a terminal in TN) by the time a retransmission arrives which includes "old" data before the sequence number in the partial packet (e.g., 77500), PRCPKT replaces the original packet with the larger retransmitted packet. Unfortunately, it fails to modify TRCBY, so that when a buffer finally arrives, data is removed beginning at the wrong offset. (The comment 'N.B. It works to replace a "partial packet" with a bigger one' is a lie.) The solution is to forget about TRCBY. Patches to fix the problem are: REASM3: LOAD RCVLFT,TRLFT,(TCB) JE TRPP,(TCB),REASM4 ; Jump if not continuing a p (jfcl) LOAD BYTNUM,TRCBY,(TCB) ; Where to resume in this pa jrst reas11 JRST REAS13 ; Go process the remainder ----------- ; Setup BYTNUM to be the byte number within the packet where ; handling should start. reas11: LOAD RCVLFT,TRLFT,(TCB) ; Get updated copy MOVE BYTNUM,RCVLFT ; Next to be reassembled LOAD T1,PSEQ,(TPKT) ; Start of packet SUB BYTNUM,T1 ; Offset into data JUMPLE BYTNUM,REAS12 ; No control to worry about LOAD T1,PSYN,(TPKT) ; Get value of SYN bit SUBI BYTNUM,0(1) ; Discount space taken by SY REAS12: ; Setup XFRCNT to be the number of bytes to transfer out of ; packet into the user buffer. jrst pat REAS13: LOAD XFRCNT,PIPL,(PKT) ; Get total length LOAD T1,PIDO,(PKT) ; Number of words in Interne pat: tlz q1,740000 (=MODSEQ BYTNUM , which should be at reas12, but here is ok) LOAD XFRCNT,PIPL,(PKT) ; Get total length jrst reas13+1 --------------- REAS19: ; Save the partial packet for the next time through. SETONE TRPP,(TCB) ; Set the partial packet wai ADD RCVLFT,XFRCNT MOVE T1,XFRCNT ; Number transferred STOR RCVLFT,TRLFT,(TCB) ADD T1,BYTNUM ; Where the transfer started jfcl STOR T1,TRCBY,(TCB) ; Is where to resume in the JUMPN BYTNUM,REAS20 ; First time we have JE PSYN,(TPKT),REAS20 ; Seen a packet with a SYN i jfcl ADD RCVLFT,XFRCNT ; Yes. Update Left jfcl STOR RCVLFT,TRLFT,(TCB) MOVX T1,^D500 ----------- The sources could be cleaned up to eliminate now unused instructions, etc. While you are making changes, check the SNDTVT routine in TTANDV.MAC as the initial value of PKTPTR was computed incorrectly, it should look something like SNDTVT:: ACVAR PUSH P,[-1] ; Last octet DMOVEM T1,XFRCNT ; T1,2 to XFRCNT and LINBLK MNTM5 AOS CELL(TCVST,0,,TCV) ; SNDTVT calls ** LOAD PKTPTR,PIPL,(PKT) ; Current packet length is next byte to insert ** ADJBP PKTPTR,[POINT 8,PKTELI(PKT)] ; Byte pointer there MOVEI CNT,0 ; Init number moved to packet where the ** instructions were (incorrectly) LOAD PKTPTR,PTDO,(TPKT) ; Get TCP data offset HRLI PKTPTR,() ; Pointer to data area ---------------------------------------- also, after TVTDTT: PUSH P,P2 ; BFR PUSH P,FR ** SETZB FR,T3 ; No flags, nor JCN XMOVEI T1,TCBLCK(TCB) ; Lock to lock XMOVEI T2,CLOSE1 ; Function to call CALL LCKCAL ; Do a cross-job close POP P,FR POP P,P2 ; BFR where the ** was SETZ FR, ; No flags Charlie ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9742%40ucbvax.ARPA] <1985080715042900> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: [CLYNN@BBNA.ARPA: Re: [Ken Harrenstien : It's definite - TOP...] Message-ID: <9742@ucbvax.ARPA> Date: Wed, 7-Aug-85 19:04:29 EDT Article-I.D.: ucbvax.9742 Posted: Wed Aug 7 19:04:29 1985 Date-Received: Sat, 10-Aug-85 23:48:10 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 131 From: Ken Harrenstien Here is another TOPS-20 TCP/IP bug fix, thanks to Charlie Lynn. We have been running the fixes at SRI-NIC for a couple days and I haven't seen any instances yet of the lossage that previously plagued us - sometimes duplicate data would be received on a TCP connection. This is annoying for TELNET, and highly dangerous for FTP! I believe this bug also explains the phenomenon of duplicate text being received on a telnet connection to 4.2BSD systems, which some time ago was mentioned and was blamed (wrongly, it appears) on a defective 4.2BSD server telnet implementation. Proof of TOPS-20 lossage came from testing connections to MIT-MC while using the ITS packet logging features. --KLH --------------- Return-Path: Received: from BBNA.ARPA by SRI-NIC.ARPA with TCP; Thu 1 Aug 85 10:46:33-PDT Date: 1 Aug 1985 13:49-EDT Sender: CLYNN@BBNA.ARPA Subject: Re: [Ken Harrenstien : It's definite - TOP... From: CLYNN@BBNA.ARPA To: KLH@SRI-NIC.ARPA Cc: clynn@BBNA.ARPA Message-ID: <[BBNA.ARPA] 1-Aug-85 13:49:21.CLYNN> In-Reply-To: The message of Sun 28 Jul 85 05:05:02-PDT from Ken Harrenstien Ken, Enough of the pieces fit for me to conclude that the duplication problem you documented is an instance of an old bug (it was fixed by the time BBN gave DEC updated files in October '84, but they haven't been distributed). The scenario of what is happening is that when a packet (e.g., ID 77475 in your example) is emptied and a buffer is simultaneously filled (e.g., PUSH was set) and another packet is available (77476) but there are no available buffers, then the "partial packet" flag (TRPP) is being set with a "processed byte count" (TRCBY) of zero. Then, when no buffer has yet been made available (e.g., slow net/output to a terminal in TN) by the time a retransmission arrives which includes "old" data before the sequence number in the partial packet (e.g., 77500), PRCPKT replaces the original packet with the larger retransmitted packet. Unfortunately, it fails to modify TRCBY, so that when a buffer finally arrives, data is removed beginning at the wrong offset. (The comment 'N.B. It works to replace a "partial packet" with a bigger one' is a lie.) The solution is to forget about TRCBY. Patches to fix the problem are: REASM3: LOAD RCVLFT,TRLFT,(TCB) JE TRPP,(TCB),REASM4 ; Jump if not continuing a p (jfcl) LOAD BYTNUM,TRCBY,(TCB) ; Where to resume in this pa jrst reas11 JRST REAS13 ; Go process the remainder ----------- ; Setup BYTNUM to be the byte number within the packet where ; handling should start. reas11: LOAD RCVLFT,TRLFT,(TCB) ; Get updated copy MOVE BYTNUM,RCVLFT ; Next to be reassembled LOAD T1,PSEQ,(TPKT) ; Start of packet SUB BYTNUM,T1 ; Offset into data JUMPLE BYTNUM,REAS12 ; No control to worry about LOAD T1,PSYN,(TPKT) ; Get value of SYN bit SUBI BYTNUM,0(1) ; Discount space taken by SY REAS12: ; Setup XFRCNT to be the number of bytes to transfer out of ; packet into the user buffer. jrst pat REAS13: LOAD XFRCNT,PIPL,(PKT) ; Get total length LOAD T1,PIDO,(PKT) ; Number of words in Interne pat: tlz q1,740000 (=MODSEQ BYTNUM , which should be at reas12, but here is ok) LOAD XFRCNT,PIPL,(PKT) ; Get total length jrst reas13+1 --------------- REAS19: ; Save the partial packet for the next time through. SETONE TRPP,(TCB) ; Set the partial packet wai ADD RCVLFT,XFRCNT MOVE T1,XFRCNT ; Number transferred STOR RCVLFT,TRLFT,(TCB) ADD T1,BYTNUM ; Where the transfer started jfcl STOR T1,TRCBY,(TCB) ; Is where to resume in the JUMPN BYTNUM,REAS20 ; First time we have JE PSYN,(TPKT),REAS20 ; Seen a packet with a SYN i jfcl ADD RCVLFT,XFRCNT ; Yes. Update Left jfcl STOR RCVLFT,TRLFT,(TCB) MOVX T1,^D500 ----------- The sources could be cleaned up to eliminate now unused instructions, etc. While you are making changes, check the SNDTVT routine in TTANDV.MAC as the initial value of PKTPTR was computed incorrectly, it should look something like SNDTVT:: ACVAR PUSH P,[-1] ; Last octet DMOVEM T1,XFRCNT ; T1,2 to XFRCNT and LINBLK MNTM5 AOS CELL(TCVST,0,,TCV) ; SNDTVT calls ** LOAD PKTPTR,PIPL,(PKT) ; Current packet length is next byte to insert ** ADJBP PKTPTR,[POINT 8,PKTELI(PKT)] ; Byte pointer there MOVEI CNT,0 ; Init number moved to packet where the ** instructions were (incorrectly) LOAD PKTPTR,PTDO,(TPKT) ; Get TCP data offset HRLI PKTPTR,() ; Pointer to data area ---------------------------------------- also, after TVTDTT: PUSH P,P2 ; BFR PUSH P,FR ** SETZB FR,T3 ; No flags, nor JCN XMOVEI T1,TCBLCK(TCB) ; Lock to lock XMOVEI T2,CLOSE1 ; Function to call CALL LCKCAL ; Do a cross-job close POP P,FR POP P,P2 ; BFR where the ** was SETZ FR, ; No flags Charlie ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985080907383000> Received: from BBNCC5 by SRI-NIC.ARPA with TCP; Fri 9 Aug 85 08:46:25-PDT To: Lixia Zhang cc: tcp-ip@SRI-NIC.ARPA, mgardner@BBNCC5.ARPA Subject: Re: Interactive traffic punishment via MILNET? In-reply-to: Your message of Friday, 26 Jul 1985 06:20:22-PDT. <8507261322.AA28664@decwrl.ARPA> Date: 09 Aug 85 11:38:30 EDT (Fri) From: mgardner@BBNCC5.ARPA Lixia, It is not easy to give a brief answer to your question of what exactly are the problems with the mailbridges, but I will do my best. Gateways are inherently bottlenecks to traffic between two networks. For example, ARPANET and MILNET are reliable networks, but their traffic is funneled through gateways designed to drop data whenever pressed for space. Retransmission at the link level is fast, because the retransmission timer triggers a retransmission fairly quickly. The retransmission timers at the transport layer must be slower, and so retransmission by TCP will affect what the user sees. The interactive user is, of course, most likely to notice. Speeding up this timer, by the way, is not a good solution, since the effect is increased congestion and poorer service for everyone. (More dropped datagrams, more retransmitted datagrams.) Another reason that the internet will never function as well as a subnet is that the gateways link heterogeneous systems. If one side is sending much faster than the other side is receiving, the gateways are designed to drop datagrams. This problem are exacerbated by the current lack of buffer space in the LSI/11s, by the lack of an effective means of slowing down a source, and by a rudimentary routing metric that does not allow routing to respond to bursts in traffic. The mailbridges are a worse bottleneck than other gateways for several good reasons. First they were placed with the idea that the traffic between them would be filtered for mail. We expected a reduction in traffic. On the contrary, since the physical split of ARPANET and MILNET, there has been a sharp rise in the amount of traffic between the two networks. The bridges are overloaded. In addition, there are a number of hosts which send almost all their traffic to the other net. These hosts may be on the wrong network. A third problem for the mailbridges is load-sharing. It is important that the traffic between the two networks be spread among the different mailbridges. This is the function of the load-sharing tables. But this is a static routing, based on expected traffic. Since the destination is not known, the routing most likely to provide good service is to home a host to its nearest mailbridge. However, when the host has a one or two hop path on one side of the mailbridge and a five or six hop path on the other side, the mailbridge will see speed mismatch problems, similar to those associated with mismatched network speed. The solution is not to ignore the load-sharing, since, everyone sending to the same bridge will create even worse problems. These are the problems we see in a perfect world where hardware and software problems have been banished. Unfortunately, we live in the real world. The software and hardware problems themselves can be in the hosts, the lines, or the network. They are usually hard to diagnose, since the symptom of the problem, for example congestion, may be physically remote from the source of the problem. It is often not even clear where in the chain the problem lies. For example, is congestion at an ISI IMP caused by the mailbridge, by ARPANET congestion around ISI, by back-up from a local net, by ARPANET congestion remote from ISI, by a host at another IMP, or by still another factor? I look at mailbridge statistics every day. I see, almost daily, the effects of host problems. Although these problems are most often caught by the host administrators, and, if not, are tracked by our monitoring center, let me list a few of the problems that I followed personally. I have seen a run-away ethernet bring MILISI to its knees, a gateway with a routing plug cause congestion felt by a host on the other side of the network, and three cases of hosts flooding the network with faulty IP datagrams. The internet is pathetically vulnerable to congestion caused by a single host. At BBN we have a number of tools to monitor the long-range performance of the internet. The gateways send messages, called traps, any time an event of interest occurs. We summarize these on a daily basis, and keep the detailed trap reports on hand for use when we see a problem. The gateways store throughput information, including how many datagrams were processed by each gateway, summarized for the gateway, and separated by interface or neighbor. Throughput reports give us detailed information, such as how many datagrams are dropped (discarded) by the gateway, broken down by reason, and the number of datagrams sent back out the same interface they used on arrival. We can also collect statistics on the number of datagrams between each source and destination host. In addition, we can measure a wide range of parameters in ARPANET or MILNET. These include detailed throughput statistics, statistics about the end-to-end traffic and about the store-and-forward traffic. But even with all these tools (and others) at our disposal, we are stopped at the host. There we find TCP/IP implementations written by many different people and containing subtle differences in interpretation that could lead to major problems. Given this range of sources for the problems, what can we, at BBN, do to improve the situation? Keep in mind that we affect the mailbridges, the IMPs, and, since we monitor the lines, the line quality, but we can only open a discussion concerning host problems. Analysis of the host to mailbridge traffic data, has revealed that there are a number of hosts (including TACs) sending most of their traffic to the other net. Some of this traffic can be moved off the internet, reducing the load, by the addition of TACs and rehoming hosts. We are considering adding a mailbridge. Software to increase the number of buffers in the LSI/11 gateways has already been written. We are investigating ways to reduce the control traffic, which should also reduce the load on the mailbridges. We have increased our attention to host problems and are notifying the host administrator when see problems. We are also considering writing guidelines for optimizing communication with ARPANET/MILNET. This would include appropriate settings for retransmission timers and sending rates. It should also include guidelines for reasonable responses to source quenches, those largely ignored messages sent by the gateway to a host which is sending data too fast. I hope this answers your question and will open up some interesting discussion on this mailing list. Marianne ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9794%40ucbvax.ARPA] <1985080908501400> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: Interactive traffic punishment via MILNET? Message-ID: <9794@ucbvax.ARPA> Date: Fri, 9-Aug-85 12:50:14 EDT Article-I.D.: ucbvax.9794 Posted: Fri Aug 9 12:50:14 1985 Date-Received: Mon, 12-Aug-85 21:09:58 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 108 From: mgardner@BBNCC5.ARPA Lixia, It is not easy to give a brief answer to your question of what exactly are the problems with the mailbridges, but I will do my best. Gateways are inherently bottlenecks to traffic between two networks. For example, ARPANET and MILNET are reliable networks, but their traffic is funneled through gateways designed to drop data whenever pressed for space. Retransmission at the link level is fast, because the retransmission timer triggers a retransmission fairly quickly. The retransmission timers at the transport layer must be slower, and so retransmission by TCP will affect what the user sees. The interactive user is, of course, most likely to notice. Speeding up this timer, by the way, is not a good solution, since the effect is increased congestion and poorer service for everyone. (More dropped datagrams, more retransmitted datagrams.) Another reason that the internet will never function as well as a subnet is that the gateways link heterogeneous systems. If one side is sending much faster than the other side is receiving, the gateways are designed to drop datagrams. This problem are exacerbated by the current lack of buffer space in the LSI/11s, by the lack of an effective means of slowing down a source, and by a rudimentary routing metric that does not allow routing to respond to bursts in traffic. The mailbridges are a worse bottleneck than other gateways for several good reasons. First they were placed with the idea that the traffic between them would be filtered for mail. We expected a reduction in traffic. On the contrary, since the physical split of ARPANET and MILNET, there has been a sharp rise in the amount of traffic between the two networks. The bridges are overloaded. In addition, there are a number of hosts which send almost all their traffic to the other net. These hosts may be on the wrong network. A third problem for the mailbridges is load-sharing. It is important that the traffic between the two networks be spread among the different mailbridges. This is the function of the load-sharing tables. But this is a static routing, based on expected traffic. Since the destination is not known, the routing most likely to provide good service is to home a host to its nearest mailbridge. However, when the host has a one or two hop path on one side of the mailbridge and a five or six hop path on the other side, the mailbridge will see speed mismatch problems, similar to those associated with mismatched network speed. The solution is not to ignore the load-sharing, since, everyone sending to the same bridge will create even worse problems. These are the problems we see in a perfect world where hardware and software problems have been banished. Unfortunately, we live in the real world. The software and hardware problems themselves can be in the hosts, the lines, or the network. They are usually hard to diagnose, since the symptom of the problem, for example congestion, may be physically remote from the source of the problem. It is often not even clear where in the chain the problem lies. For example, is congestion at an ISI IMP caused by the mailbridge, by ARPANET congestion around ISI, by back-up from a local net, by ARPANET congestion remote from ISI, by a host at another IMP, or by still another factor? I look at mailbridge statistics every day. I see, almost daily, the effects of host problems. Although these problems are most often caught by the host administrators, and, if not, are tracked by our monitoring center, let me list a few of the problems that I followed personally. I have seen a run-away ethernet bring MILISI to its knees, a gateway with a routing plug cause congestion felt by a host on the other side of the network, and three cases of hosts flooding the network with faulty IP datagrams. The internet is pathetically vulnerable to congestion caused by a single host. At BBN we have a number of tools to monitor the long-range performance of the internet. The gateways send messages, called traps, any time an event of interest occurs. We summarize these on a daily basis, and keep the detailed trap reports on hand for use when we see a problem. The gateways store throughput information, including how many datagrams were processed by each gateway, summarized for the gateway, and separated by interface or neighbor. Throughput reports give us detailed information, such as how many datagrams are dropped (discarded) by the gateway, broken down by reason, and the number of datagrams sent back out the same interface they used on arrival. We can also collect statistics on the number of datagrams between each source and destination host. In addition, we can measure a wide range of parameters in ARPANET or MILNET. These include detailed throughput statistics, statistics about the end-to-end traffic and about the store-and-forward traffic. But even with all these tools (and others) at our disposal, we are stopped at the host. There we find TCP/IP implementations written by many different people and containing subtle differences in interpretation that could lead to major problems. Given this range of sources for the problems, what can we, at BBN, do to improve the situation? Keep in mind that we affect the mailbridges, the IMPs, and, since we monitor the lines, the line quality, but we can only open a discussion concerning host problems. Analysis of the host to mailbridge traffic data, has revealed that there are a number of hosts (including TACs) sending most of their traffic to the other net. Some of this traffic can be moved off the internet, reducing the load, by the addition of TACs and rehoming hosts. We are considering adding a mailbridge. Software to increase the number of buffers in the LSI/11 gateways has already been written. We are investigating ways to reduce the control traffic, which should also reduce the load on the mailbridges. We have increased our attention to host problems and are notifying the host administrator when see problems. We are also considering writing guidelines for optimizing communication with ARPANET/MILNET. This would include appropriate settings for retransmission timers and sending rates. It should also include guidelines for reasonable responses to source quenches, those largely ignored messages sent by the gateway to a host which is sending data too fast. I hope this answers your question and will open up some interesting discussion on this mailing list. Marianne ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081121262800> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Sun 11 Aug 85 22:27:33-PDT Date: 12 Aug 1985 01:26:28 EDT From: MILLS@USC-ISID.ARPA Subject: Re: dcn1 time To: jsq%tzec.UTEXAS@UT-SALLY.ARPA cc: MILLS@USC-ISID.ARPA, tcp-ip@SRI-NIC.ARPA In response to your message sent Sun, 11 Aug 85 16:17:35 cdt John, Sorry about that. Our WWVB clock suddenly went berserk and started handing out timestamps eight hour off. I discovered that on Saturday morning and resynchronized DCN-GATEWAY to the GOES radio clock in Dearborn, MI. I'll kick the WWVB clock on Monday. Meanwhile, subtract 38 milliseconds from all timestamps handed out by DCN-GATEWAY. See the July issue of the ACM Operating System Review for suggestions on how to tell the good guys from the bad in a clique of clockwatchers. The invitation to expand the set of good guys in our timetelling community remains open. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9842%40ucbvax.ARPA] <1985081122203300> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: dcn1 time Message-ID: <9842@ucbvax.ARPA> Date: Mon, 12-Aug-85 02:20:33 EDT Article-I.D.: ucbvax.9842 Posted: Mon Aug 12 02:20:33 1985 Date-Received: Sun, 18-Aug-85 20:57:36 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 19 From: MILLS@USC-ISID.ARPA In response to your message sent Sun, 11 Aug 85 16:17:35 cdt John, Sorry about that. Our WWVB clock suddenly went berserk and started handing out timestamps eight hour off. I discovered that on Saturday morning and resynchronized DCN-GATEWAY to the GOES radio clock in Dearborn, MI. I'll kick the WWVB clock on Monday. Meanwhile, subtract 38 milliseconds from all timestamps handed out by DCN-GATEWAY. See the July issue of the ACM Operating System Review for suggestions on how to tell the good guys from the bad in a clique of clockwatchers. The invitation to expand the set of good guys in our timetelling community remains open. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081204221100> Received: from RUTGERS.ARPA by SRI-NIC.ARPA with TCP; Mon 12 Aug 85 05:22:19-PDT Date: 12 Aug 85 08:22:11 EDT From: Charles Hedrick Subject: Re: Interactive traffic punishment via MILNET? To: mgardner@BBNCC5.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "mgardner@BBNCC5.ARPA" of 9 Aug 85 11:38:30 EDT To complicate things, the host administrators often don't know that much about how their software works. When somebody posts a message on the net saying that some horrible thing is causing some inconceivable result, I have no way of knowing whether any of my hosts are contributing. I run TOPS-20, Unix, and Eunice TCP's, and I do not know the details of any of the TCP implementations. (With Eunice I do not even have access to the source.) If you sent me a patch and told me to install it, I would, but if you asked me whether my retransmission gizmo was frabulating the gateway matter-antimatter mix, I would have no way to respond. I'm not sure quite what you can do about this, but in some ways it may make your problem easier. What you probably need is one or two knowlegable sites for each OS. Then you could download fixes they develop to the rest of us. You will also have to find a stick big enough to get these fixes put into the next release from the vendor. Maybe DCA could arrange to have Norad point a few missles in the direction of . One problem that is making this more complex is that the natural experts on TOPS-20 TCP are ISI and BBN, but their code has diverged from the code supported by DEC and used by the less sophisticated sites such as ourselves. This is an area that seems particularly amenable to the use of stategic weaponry. Whether the missles should be pointed at Marlboro or Cambridge and California is a decision I would be happy to leave up to you. (There are some unpleasant politics hiding behind the surface here, which I am going to avoid talking about in public, at least at the moment.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081204260000> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Mon 12 Aug 85 11:29:48-PDT Date: 12 Aug 1985 11:26-PDT Sender: LYNCH@USC-ISIB.ARPA Subject: Re: Interactive traffic punishment via MILNET? From: Dan To: HEDRICK@RUTGERS.ARPA Cc: mgardner@BBNCC5.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISIB.ARPA]12-Aug-85 11:26:41.LYNCH> In-Reply-To: The message of 12 Aug 85 08:22:11 EDT from Charles Hedrick Charles, Your displeasure at some combination of ISI/BBN/DEC for the sorry state of affairs in TCP updates/maintenance is noted. Since I was in the middle of that menage for a few years I can shed some light (and dark?) on the subject. There are two main issues: 1) Money 2) Research Take the "research" issue first. Many of the "problems" seen in TCP usage are truly complicated and need to be examined carefully in the diverse internet enviornment. That brings up "money"... DEC gets money for selling machines (and attendant software). BBN gets money for doing research on networking (and for operating some networks). ISI gets money for running systems and keeping customers content. The above simplifications are accurate enough for this diatribe. The major flaw in the above division of effort is that the vendor, DEC, does not spend enough money on making a great TCP for TOPS20. They do not live in the Internet environment on a daily basis. I am sure that they do a much better job with DECNET because they live in that environment daily. And make money on it. As for BBN, they have many fish to fry these days and have been known to refuse to work on a problem unless they got paid for it. ISI (where I was located from 1980-1983) basically gave up on both DEC and BBN as timely sources of help in resolving vexing performance and functionaility problems. We relied on them heavily for longer term solutions while we tried to keep our systems on the air for our thousands of users. ISI would readily give out its code to anyone who had a source license from DEC. Of course the recipient would have to take out our ISI site specific enhancements to get a running system... And we did not have a lot of time/energy to promulgate and assist others in the quest of a stable, high performance TCP. That's a short recap in history. What did we learn and what can we do better in the future? We learned that Internetting is very complex, that declaring something to be a product does not make it so, and that money is the root of all good. I'd better cut it short on the "future" part. Since TOPS20 is dying I don't see much impetus (money) for improving the mechanisms in that arean. But Unix sure ain't dead nor is VMS. If improvements are to be readily produced and distributed then I suggest that some entity be formed (or identified as existing) and funded to do a quality job for all internet users. Laissez faire just doesn't cut it. Dan PS. I have been entering this via a Milnet TAC to the Arpanet host at ISIB and have held my breath until now! Geoff, thank you for airing this subject. The stuttering and delays are awesome. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9847%40ucbvax.ARPA] <1985081205021700> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: Interactive traffic punishment via MILNET? Message-ID: <9847@ucbvax.ARPA> Date: Mon, 12-Aug-85 09:02:17 EDT Article-I.D.: ucbvax.9847 Posted: Mon Aug 12 09:02:17 1985 Date-Received: Sun, 18-Aug-85 20:57:54 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 28 From: Charles Hedrick To complicate things, the host administrators often don't know that much about how their software works. When somebody posts a message on the net saying that some horrible thing is causing some inconceivable result, I have no way of knowing whether any of my hosts are contributing. I run TOPS-20, Unix, and Eunice TCP's, and I do not know the details of any of the TCP implementations. (With Eunice I do not even have access to the source.) If you sent me a patch and told me to install it, I would, but if you asked me whether my retransmission gizmo was frabulating the gateway matter-antimatter mix, I would have no way to respond. I'm not sure quite what you can do about this, but in some ways it may make your problem easier. What you probably need is one or two knowlegable sites for each OS. Then you could download fixes they develop to the rest of us. You will also have to find a stick big enough to get these fixes put into the next release from the vendor. Maybe DCA could arrange to have Norad point a few missles in the direction of . One problem that is making this more complex is that the natural experts on TOPS-20 TCP are ISI and BBN, but their code has diverged from the code supported by DEC and used by the less sophisticated sites such as ourselves. This is an area that seems particularly amenable to the use of stategic weaponry. Whether the missles should be pointed at Marlboro or Cambridge and California is a decision I would be happy to leave up to you. (There are some unpleasant politics hiding behind the surface here, which I am going to avoid talking about in public, at least at the moment.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9850%40ucbvax.ARPA] <1985081211343800> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: Interactive traffic punishment via MILNET? Message-ID: <9850@ucbvax.ARPA> Date: Mon, 12-Aug-85 15:34:38 EDT Article-I.D.: ucbvax.9850 Posted: Mon Aug 12 15:34:38 1985 Date-Received: Sun, 18-Aug-85 20:58:24 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 57 From: Dan Charles, Your displeasure at some combination of ISI/BBN/DEC for the sorry state of affairs in TCP updates/maintenance is noted. Since I was in the middle of that menage for a few years I can shed some light (and dark?) on the subject. There are two main issues: 1) Money 2) Research Take the "research" issue first. Many of the "problems" seen in TCP usage are truly complicated and need to be examined carefully in the diverse internet enviornment. That brings up "money"... DEC gets money for selling machines (and attendant software). BBN gets money for doing research on networking (and for operating some networks). ISI gets money for running systems and keeping customers content. The above simplifications are accurate enough for this diatribe. The major flaw in the above division of effort is that the vendor, DEC, does not spend enough money on making a great TCP for TOPS20. They do not live in the Internet environment on a daily basis. I am sure that they do a much better job with DECNET because they live in that environment daily. And make money on it. As for BBN, they have many fish to fry these days and have been known to refuse to work on a problem unless they got paid for it. ISI (where I was located from 1980-1983) basically gave up on both DEC and BBN as timely sources of help in resolving vexing performance and functionaility problems. We relied on them heavily for longer term solutions while we tried to keep our systems on the air for our thousands of users. ISI would readily give out its code to anyone who had a source license from DEC. Of course the recipient would have to take out our ISI site specific enhancements to get a running system... And we did not have a lot of time/energy to promulgate and assist others in the quest of a stable, high performance TCP. That's a short recap in history. What did we learn and what can we do better in the future? We learned that Internetting is very complex, that declaring something to be a product does not make it so, and that money is the root of all good. I'd better cut it short on the "future" part. Since TOPS20 is dying I don't see much impetus (money) for improving the mechanisms in that arean. But Unix sure ain't dead nor is VMS. If improvements are to be readily produced and distributed then I suggest that some entity be formed (or identified as existing) and funded to do a quality job for all internet users. Laissez faire just doesn't cut it. Dan PS. I have been entering this via a Milnet TAC to the Arpanet host at ISIB and have held my breath until now! Geoff, thank you for airing this subject. The stuttering and delays are awesome. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081609125100> Received: from ut-sally.ARPA by SRI-NIC.ARPA with TCP; Fri 16 Aug 85 12:51:54-PDT Posted-Date: Fri, 16 Aug 85 14:12:51 cdt Received: from uo.UTEXAS (uo.UTEXAS.ARPA) by ut-sally.ARPA (4.22/4.22) id AA19433; Fri, 16 Aug 85 14:21:20 cdt Date: Fri, 16 Aug 85 14:12:51 cdt From: smoot%uo.UTEXAS@ut-sally.ARPA (Smoot Carl-Mitchell) Message-Id: <8508161912.AA18861@uo.UTEXAS> Received: by uo.UTEXAS (4.24/4.22) id AA18861; Fri, 16 Aug 85 14:12:51 cdt To: tcp-ip@sri-nic.ARPA Subject: RFC940 subnet code for 4.2 BSD I have backfitted the 4.3 subnet code into the 4.2 kernel. This change implements subnets as described in rfc940. We have been running it on our systems for about 2 weeks with no problems. In addition I also enhanced the ARP code in 4.2 to allow subnet gateways to answer ARP requests for hosts on a directly attached subnet or for a host on a subnet with a route through the gateway. This allows a site to use subnets by running the subnet kernel on gateway hosts only. This is useful in a heterogeneous environment where there are hosts running non-subnet kernels and the kernel sources are not available to modify them to know about subnets. Of course, it only works on ethernets or other LAN technology which supports ARP. The code is currently working on VAX hardware and should work on any other system running 4.2, since the modifications are machine independent. Diff listings of the mods and installation instructions are in the file pub/subnet.tar accessible by anonymous ftp on ut-sally.ARPA (soon to be sally.UTEXAS.EDU). Send any comments, bug fixes to me. I have also notified Berkeley and suggested they incorporate the ARP enhancement in future releases. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9947%40ucbvax.ARPA] <1985081612551400> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: RFC940 subnet code for 4.2 BSD Message-ID: <9947@ucbvax.ARPA> Date: Fri, 16-Aug-85 16:55:14 EDT Article-I.D.: ucbvax.9947 Posted: Fri Aug 16 16:55:14 1985 Date-Received: Tue, 20-Aug-85 01:36:12 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 23 From: smoot%uo.UTEXAS@ut-sally.ARPA (Smoot Carl-Mitchell) I have backfitted the 4.3 subnet code into the 4.2 kernel. This change implements subnets as described in rfc940. We have been running it on our systems for about 2 weeks with no problems. In addition I also enhanced the ARP code in 4.2 to allow subnet gateways to answer ARP requests for hosts on a directly attached subnet or for a host on a subnet with a route through the gateway. This allows a site to use subnets by running the subnet kernel on gateway hosts only. This is useful in a heterogeneous environment where there are hosts running non-subnet kernels and the kernel sources are not available to modify them to know about subnets. Of course, it only works on ethernets or other LAN technology which supports ARP. The code is currently working on VAX hardware and should work on any other system running 4.2, since the modifications are machine independent. Diff listings of the mods and installation instructions are in the file pub/subnet.tar accessible by anonymous ftp on ut-sally.ARPA (soon to be sally.UTEXAS.EDU). Send any comments, bug fixes to me. I have also notified Berkeley and suggested they incorporate the ARP enhancement in future releases. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081805171400> Received: from ut-sally.ARPA by SRI-NIC.ARPA with TCP; Sun 18 Aug 85 08:56:02-PDT Posted-Date: Sun, 18 Aug 85 10:17:14 cdt Received: from tzec.UTEXAS (tzec.UTEXAS.ARPA) by ut-sally.ARPA (4.22/4.22) id AA00239; Sun, 18 Aug 85 10:19:32 cdt Date: Sun, 18 Aug 85 10:17:14 cdt From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) Message-Id: <8508181517.AA26239@tzec.UTEXAS> Received: by tzec.UTEXAS (4.24/4.22) id AA26239; Sun, 18 Aug 85 10:17:14 cdt To: TCP-IP@SRI-NIC Subject: voting on the time Cc: jsq@tzec.ARPA After the incident when dcn1's time was eight hours off, Dave Mills suggested that the client should check with a neighbor or two before believing what any host says about the time. I have followed this up and written a time client program for 4.2BSD which allows letting an arbitrary number of hosts vote on the time. It also can connect using either TCP or UDP, since the set of really accurate hosts which run time servers using either protocol is very small. The program is available by anonymous ftp from ut-sally.ARPA (soon to be sally.UTEXAS.EDU) as ~ftp/pub/netdate.c and ~ftp/pub/netdate.8. Here are a couple of usage examples from the manual entry: EXAMPLE The most accurate hosts are named first in each example. /etc/netdate -l 30 udp dcn-gateway tcp neighbor _D_c_n-_g_a_t_e_w_a_y is a hypothetical host which usually keeps time accurate to within milliseconds of Coordinated Universal Time, but may occasionally be eight hours off. _N_e_i_g_h_b_o_r is a neighbor of the local host which keeps time with moderate accuracy. The time will be set to that of _d_c_n-_g_a_t_e_w_a_y if that and _n_e_i_g_h_b_o_r agree to within thirty seconds, else it will not be set at all. This is almost good enough for most circumstances, but won't do when the local host's time is known to be wrong (e.g., after a long downtime or a bad crash) and must be set to something. If one of the hosts named is inaccurate or not responding, there is a problem. /etc/netdate -l 30 udp dcn-gateway tcp neighbor neighbor2 Only two of the three hosts named must agree on the time. The time will still be set (to that of the first neighbor), even if _d_c_n-_g_a_t_e_w_a_y is far off as long as the two neighbors agree. This is probably good enough for most cases. One can arbitrarily gerrymander the vote for more insurance (and less clarity), as in the following example. [end of excerpt] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9968%40ucbvax.ARPA] <1985081809021200> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: voting on the time Message-ID: <9968@ucbvax.ARPA> Date: Sun, 18-Aug-85 13:02:12 EDT Article-I.D.: ucbvax.9968 Posted: Sun Aug 18 13:02:12 1985 Date-Received: Tue, 20-Aug-85 21:03:50 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 39 From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) After the incident when dcn1's time was eight hours off, Dave Mills suggested that the client should check with a neighbor or two before believing what any host says about the time. I have followed this up and written a time client program for 4.2BSD which allows letting an arbitrary number of hosts vote on the time. It also can connect using either TCP or UDP, since the set of really accurate hosts which run time servers using either protocol is very small. The program is available by anonymous ftp from ut-sally.ARPA (soon to be sally.UTEXAS.EDU) as ~ftp/pub/netdate.c and ~ftp/pub/netdate.8. Here are a couple of usage examples from the manual entry: EXAMPLE The most accurate hosts are named first in each example. /etc/netdate -l 30 udp dcn-gateway tcp neighbor _ D_ c_ n-_ g_ a_ t_ e_ w_ a_ y is a hypothetical host which usually keeps time accurate to within milliseconds of Coordinated Universal Time, but may occasionally be eight hours off. _ N_ e_ i_ g_ h_ b_ o_ r is a neighbor of the local host which keeps time with moderate accuracy. The time will be set to that of _ d_ c_ n-_ g_ a_ t_ e_ w_ a_ y if that and _ n_ e_ i_ g_ h_ b_ o_ r agree to within thirty seconds, else it will not be set at all. This is almost good enough for most circumstances, but won't do when the local host's time is known to be wrong (e.g., after a long downtime or a bad crash) and must be set to something. If one of the hosts named is inaccurate or not responding, there is a problem. /etc/netdate -l 30 udp dcn-gateway tcp neighbor neighbor2 Only two of the three hosts named must agree on the time. The time will still be set (to that of the first neighbor), even if _ d_ c_ n-_ g_ a_ t_ e_ w_ a_ y is far off as long as the two neighbors agree. This is probably good enough for most cases. One can arbitrarily gerrymander the vote for more insurance (and less clarity), as in the following example. [end of excerpt] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081905300000> Received: from ACC.ARPA by SRI-NIC.ARPA with TCP; Mon 19 Aug 85 13:40:04-PDT Date: 19 Aug 1985 13:30 PST From: Gary Krall Subject: mail problem To: TCP-IP@SRI-NIC Reply-To: GARY@ACC ACC's VAX system has been going through VMS 3.7 to 4.1 upgrading and as such my personal box has been on the 'fritz'. As you can see I'm now back on the air. Thanks.. Gary Krall/ACC ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081905444600> Received: from nrl-css by SRI-NIC.ARPA with TCP; Mon 19 Aug 85 06:43:50-PDT Date: Mon, 19 Aug 85 09:44:46 edt From: Alan Parker Message-Id: <8508191344.AA22402@nrl-css> To: tcp-ip@nic Subject: TCP/IP trademark? DEC ad on page 20-21 of August 1985 Mini-Micro Systems magazine for Venix on DEC's PRO workstations tells us that TCP/IP is a trademark of Xerox Corporation. -Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9976%40ucbvax.ARPA] <1985081906585500> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: TCP/IP trademark? Message-ID: <9976@ucbvax.ARPA> Date: Mon, 19-Aug-85 10:58:55 EDT Article-I.D.: ucbvax.9976 Posted: Mon Aug 19 10:58:55 1985 Date-Received: Tue, 20-Aug-85 22:33:51 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 7 From: Alan Parker DEC ad on page 20-21 of August 1985 Mini-Micro Systems magazine for Venix on DEC's PRO workstations tells us that TCP/IP is a trademark of Xerox Corporation. -Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081910053000> Received: from gwen.ARPA (GUENEVERE.PURDUE.EDU) by SRI-NIC.ARPA with TCP; Mon 19 Aug 85 13:05:47-PDT Message-Id: <8508192005.AA24109@gwen.ARPA> Received: by gwen.ARPA; Mon, 19 Aug 85 15:05:33 EST To: tcp-ip@sri-nic.arpa Subject: arpanet address for purdue Date: 19 Aug 85 15:05:30 EST (Mon) From: Paul M. Albitz Please note that as of sometime tomorrow (Tuesday Aug. 20), purdue will not be responding to the 10.0.0.37 address anymore. We are moving purdue-arthur to a new building where it will not be directly connected to the imp. After it comes back up, purdue-arthur will be using its 128.10.0.1 address. You may have to edit your hosts table to reflect this as it probably won't be out of HOSTS.TXT yet. Paul Albitz ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081911265700> Received: from USC-ISIF.ARPA by SRI-NIC.ARPA with TCP; Mon 19 Aug 85 18:27:40-PDT Date: 19 Aug 1985 18:26:57 PDT From: POSTEL@USC-ISIF.ARPA Subject: Internet Inc. To: TCP-IP@SRI-NIC.ARPA I have heard of at least two different companies that have the name "Internet". Both seem to think it was very clever of them to have thought of that name and totally disbelieving that any one else could have used it before. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9991%40ucbvax.ARPA] <1985081913104300> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: arpanet address for purdue Message-ID: <9991@ucbvax.ARPA> Date: Mon, 19-Aug-85 17:10:43 EDT Article-I.D.: ucbvax.9991 Posted: Mon Aug 19 17:10:43 1985 Date-Received: Tue, 20-Aug-85 22:37:33 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 11 From: Paul M. Albitz Please note that as of sometime tomorrow (Tuesday Aug. 20), purdue will not be responding to the 10.0.0.37 address anymore. We are moving purdue-arthur to a new building where it will not be directly connected to the imp. After it comes back up, purdue-arthur will be using its 128.10.0.1 address. You may have to edit your hosts table to reflect this as it probably won't be out of HOSTS.TXT yet. Paul Albitz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9995%40ucbvax.ARPA] <1985081914211700> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: mail problem Message-ID: <9995@ucbvax.ARPA> Date: Mon, 19-Aug-85 18:21:17 EDT Article-I.D.: ucbvax.9995 Posted: Mon Aug 19 18:21:17 1985 Date-Received: Tue, 20-Aug-85 22:38:45 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 11 From: Gary Krall ACC's VAX system has been going through VMS 3.7 to 4.1 upgrading and as such my personal box has been on the 'fritz'. As you can see I'm now back on the air. Thanks.. Gary Krall/ACC ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081915470000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Mon 19 Aug 85 16:48:22-PDT Date: 19 Aug 1985 19:47-EDT Sender: CERF@USC-ISI.ARPA Subject: Re: TCP/IP trademark? From: CERF@USC-ISI.ARPA To: parker@NRL-CSS.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]19-Aug-85 19:47:45.CERF> In-Reply-To: <8508191344.AA22402@nrl-css> Xerox Network Protocols include an Internet protocol - I wonder if the DEC person preparing the material confused the Xerox internet protocols with the DoD protocols? This has happened before. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081915560000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Mon 19 Aug 85 16:55:50-PDT Date: 19 Aug 1985 19:56-EDT Sender: CERF@USC-ISI.ARPA Subject: Re: mail problem From: CERF@USC-ISI.ARPA To: GARY@ACC.ARPA Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]19-Aug-85 19:56:20.CERF> In-Reply-To: The message of 19 Aug 1985 13:30 PST from Gary Krall Gary, I am about to take MCI Mail from 3.6 to 4.2 - what am I about to face??? vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10003%40ucbvax.ARPA] <1985081917032100> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: TCP/IP trademark? Message-ID: <10003@ucbvax.ARPA> Date: Mon, 19-Aug-85 21:03:21 EDT Article-I.D.: ucbvax.10003 Posted: Mon Aug 19 21:03:21 1985 Date-Received: Tue, 20-Aug-85 22:42:42 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 8 From: CERF@USC-ISI.ARPA Xerox Network Protocols include an Internet protocol - I wonder if the DEC person preparing the material confused the Xerox internet protocols with the DoD protocols? This has happened before. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10005%40ucbvax.ARPA] <1985081917524100> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: mail problem Message-ID: <10005@ucbvax.ARPA> Date: Mon, 19-Aug-85 21:52:41 EDT Article-I.D.: ucbvax.10005 Posted: Mon Aug 19 21:52:41 1985 Date-Received: Fri, 23-Aug-85 07:42:30 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 8 From: CERF@USC-ISI.ARPA Gary, I am about to take MCI Mail from 3.6 to 4.2 - what am I about to face??? vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985081919302500> Received: from trantor.arpa by SRI-NIC.ARPA with TCP; Mon 19 Aug 85 20:28:33-PDT Received: by trantor.arpa (5.5/4.7) id AA09176; Mon, 19 Aug 85 23:30:25 EDT Date: Mon, 19 Aug 85 23:30:25 EDT From: petry@trantor.ARPA (Michael G. Petry) Message-Id: <8508200330.AA09176@trantor.arpa> To: tcp-ip@sri-nic Subject: Ether Broadcast Bedlam Since I haven't seen any recent war stories, I'll pass along one that just attacked our shop. The story takes place on a moderately sized ethernet(tm) (~50 nodes) at the Univ of Maryland. Panic struck just after the gweat (go eat)crowd returned from lunch to find the ether in a state disaster. The carrier lights shown bright on our ether boards, but no traffic was flowing. Fingers were pointing in all directions. A few hours latter fingers stopped on a tucked away Unix(tm) fileserver/workstation (Host X). The machine had problems reading the hardware ether address from it's prom. The software decided it wanted to be heard and chose FF:FF:FF:FF:FF:FF as its ether address. Well imagine what took place when a simple ICMP PING was attempted on host X by host Y. 1) Send an ARP request to determine X's ether address 2) X replys that it is FF:FF:FF:FF:FF:FF 3) Y sends ICMP ping to X using FF:FF:FF:FF:FF:FF 4) EVERY host sees the message. The Unix(tm) 4.X hordes decide to send an ICMP destination unreachable or forward it on to X 5) EVERY forwarding host then ARPs for host X. (Most of our hosts have ipforwarding enabled) 6) X replys that it is FF:FF:FF:FF:FF:FF 7) The forwarding hosts then send the message to X using FF ... FF Need I go any further........... The first thing to do is get the bloody hardware fixed. What should be the second? Should a host be allowed to ARP reply as the ether broadcast address? My first impression is not, since all boards are suppose to be bound to a unique address. (maybe its time for a fast hack to disallow FF .. FF in if_ether.c) As an exercise think what happens if ipforwarding is off. The scenario is mildy better. Is this what is meant by radiation tolerant components? P.S. Thanks to Interlan for having activity lights on boards. (It WASN'T their board that was broken) Thanks to John Romkey and friends for writting the PC/IP Netwatch program. (finally a good use for a PC) Mike Petry UOM Computer Science Center  ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10007%40ucbvax.ARPA] <1985081919565600> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Internet Inc. Message-ID: <10007@ucbvax.ARPA> Date: Mon, 19-Aug-85 23:56:56 EDT Article-I.D.: ucbvax.10007 Posted: Mon Aug 19 23:56:56 1985 Date-Received: Fri, 23-Aug-85 07:43:29 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 10 From: POSTEL@USC-ISIF.ARPA I have heard of at least two different companies that have the name "Internet". Both seem to think it was very clever of them to have thought of that name and totally disbelieving that any one else could have used it before. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10008%40ucbvax.ARPA] <1985081920445500> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Ether Broadcast Bedlam Message-ID: <10008@ucbvax.ARPA> Date: Tue, 20-Aug-85 00:44:55 EDT Article-I.D.: ucbvax.10008 Posted: Tue Aug 20 00:44:55 1985 Date-Received: Fri, 23-Aug-85 07:43:57 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 46 From: petry@trantor.ARPA (Michael G. Petry) Since I haven't seen any recent war stories, I'll pass along one that just attacked our shop. The story takes place on a moderately sized ethernet(tm) (~50 nodes) at the Univ of Maryland. Panic struck just after the gweat (go eat)crowd returned from lunch to find the ether in a state disaster. The carrier lights shown bright on our ether boards, but no traffic was flowing. Fingers were pointing in all directions. A few hours latter fingers stopped on a tucked away Unix(tm) fileserver/workstation (Host X). The machine had problems reading the hardware ether address from it's prom. The software decided it wanted to be heard and chose FF:FF:FF:FF:FF:FF as its ether address. Well imagine what took place when a simple ICMP PING was attempted on host X by host Y. 1) Send an ARP request to determine X's ether address 2) X replys that it is FF:FF:FF:FF:FF:FF 3) Y sends ICMP ping to X using FF:FF:FF:FF:FF:FF 4) EVERY host sees the message. The Unix(tm) 4.X hordes decide to send an ICMP destination unreachable or forward it on to X 5) EVERY forwarding host then ARPs for host X. (Most of our hosts have ipforwarding enabled) 6) X replys that it is FF:FF:FF:FF:FF:FF 7) The forwarding hosts then send the message to X using FF ... FF Need I go any further........... The first thing to do is get the bloody hardware fixed. What should be the second? Should a host be allowed to ARP reply as the ether broadcast address? My first impression is not, since all boards are suppose to be bound to a unique address. (maybe its time for a fast hack to disallow FF .. FF in if_ether.c) As an exercise think what happens if ipforwarding is off. The scenario is mildy better. Is this what is meant by radiation tolerant components? P.S. Thanks to Interlan for having activity lights on boards. (It WASN'T their board that was broken) Thanks to John Romkey and friends for writting the PC/IP Netwatch program. (finally a good use for a PC) Mike Petry UOM Computer Science Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082007033300> Received: from UCI-ICSA by SRI-NIC.ARPA with TCP; Tue 20 Aug 85 14:10:44-PDT To: tcp-ip@sri-nic Subject: Voting on time Reply-To: raj@uci-icsa Date: 20 Aug 85 14:03:33 PDT (Tue) Message-ID: <376.493419813@uci-icsa> From: Richard Johnson Received: from Localhost by UCI-ICSA; 20 Aug 85 14:03:53 PDT (Tue) When DCN1's time got screwed up a while back, I decided to never completely trust any system again. Thus I changed my program which gets the time upon system startup to use a rather involved system of verification. This program uses a udp broadcast on the local net to get time from all local systems. It also sends special udp requests to any systems listed on the command line. After getting all the replies it averages all the localnet times, throughs out the time farthest from the average if it's too far away (a parameter), and continues to do this until it either gets a bunch of times within a specified range or has one time left. After all of this, if it has a "usable" average (taken from more than one number all within the max. range), then it begins looking through the times received from the "special requests". The first one of these it finds which is within another settable range of the local average, it takes as an authority. Basically the idea is to avoid asking the operator to set the time as much as possible. As a last resort we call a special program "settime" which allows the operator to type in the date a time in almost any format he feels like. We always use "/bin/date" to actually set the time so that accounting information is updated correctly (this was a fast hack and I didn't feel like rewriting /bin/date). This program is available with anonymous ftp (password guest) from uci-icsa.arpa. Warning: It has never been run through lint and thus probably has lots of things in it people will not like. If anyone makes improvements, I would like to hear about them. ------------------------------------------------------------------------ Richard Johnson raj@uci.arpa (ARPA) UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082008191300> Received: from MIT-MC.ARPA by SRI-NIC.ARPA with TCP; Tue 20 Aug 85 09:17:19-PDT Date: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy Subject: voting on the time To: jsq%tzec.UTEXAS@UT-SALLY.ARPA cc: TCP-IP@SRI-NIC.ARPA In-reply-to: Msg of Sun 18 Aug 85 10:17:14 cdt from jsq%tzec.UTEXAS at ut-sally.ARPA (John Quarterman) Message-ID: <[MIT-MC.ARPA].618951.850820.CSTACY> When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082008282300> Received: from ut-sally.ARPA by SRI-NIC.ARPA with TCP; Tue 20 Aug 85 14:54:23-PDT Posted-Date: Tue, 20 Aug 85 13:28:23 cdt Received: from tzec.UTEXAS (tzec.UTEXAS.ARPA) by ut-sally.ARPA (4.22/4.22) id AA19492; Tue, 20 Aug 85 13:28:50 cdt Date: Tue, 20 Aug 85 13:28:23 cdt From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) Message-Id: <8508201828.AA00740@tzec.UTEXAS> Received: by tzec.UTEXAS (4.24/4.22) id AA00740; Tue, 20 Aug 85 13:28:23 cdt To: DCP@SCRC-QUABBIN.ARPA Subject: Re: voting on the time Cc: Christopher C. Stacy , TCP-IP@SRI-NIC.ARPA, jsq%tzec.UTEXAS@ut-sally.ARPA My assumption was that checking the time of independent hosts should be more dependable than checking anything on the local host, especially after a bad crash or operator error. There are many other things which netdate could do. Once it's chosen what it thinks is the set of most accurate hosts, it could take the RMS average, toss out anything which deviates too far, average again, and use the result as the time. It could poll the whole set of accurate hosts several times when averaging, or it could just poll the single most accurate host several times and average. It could notice the network latency and adjust for it. I may add some of these things (preferably after wiser heads remark on which ones would be most useful). What I wanted to start with was something simple which could be depended upon to reject truly bogus times. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10014%40ucbvax.ARPA] <1985082009171900> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: voting on the time Message-ID: <10014@ucbvax.ARPA> Date: Tue, 20-Aug-85 13:17:19 EDT Article-I.D.: ucbvax.10014 Posted: Tue Aug 20 13:17:19 1985 Date-Received: Fri, 23-Aug-85 08:35:36 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 8 From: Christopher C. Stacy When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082009360000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Tue 20 Aug 85 10:40:09-PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 298998; Tue 20-Aug-85 13:34:40-EDT Date: Tue, 20 Aug 85 13:36 EDT From: David C. Plummer in disguise Subject: Ether Broadcast Bedlam To: Michael G. Petry , tcp-ip@SRI-NIC.ARPA In-Reply-To: <8508200330.AA09176@trantor.arpa> Message-ID: <850820133607.9.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 19 Aug 85 23:30:25 EDT From: petry@trantor.ARPA (Michael G. Petry) Since I haven't seen any recent war stories, I'll pass along one that just attacked our shop. The first thing to do is get the bloody hardware fixed. What should be the second? Should a host be allowed to ARP reply as the ether broadcast address? My first impression is not, since all boards are suppose to be bound to a unique address. (maybe its time for a fast hack to disallow FF .. FF in if_ether.c) As an exercise think what happens if ipforwarding is off. The scenario is mildy better. I've seen this kind of story before. Maybe it was only in-house and didn't get out into the big-wide-world. The solution is to ignore ARP packets from people claiming to have any form of multicast hardware address (and that includes broadcast). You still need a low level netwatch program to realize somebody is trying to confuse the world. Is this what is meant by radiation tolerant components? P.S. Thanks to Interlan for having activity lights on boards. (It WASN'T their board that was broken) Thanks to John Romkey and friends for writting the PC/IP Netwatch program. (finally a good use for a PC) Mike Petry UOM Computer Science Center  ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082009380000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Tue 20 Aug 85 10:50:08-PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 299002; Tue 20-Aug-85 13:37:29-EDT Date: Tue, 20 Aug 85 13:38 EDT From: David C. Plummer in disguise Subject: voting on the time To: Christopher C. Stacy , jsq%tzec.UTEXAS@UT-SALLY.ARPA cc: TCP-IP@SRI-NIC.ARPA In-Reply-To: <[MIT-MC.ARPA].618951.850820.CSTACY> Message-ID: <850820133855.0.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. But what happens if somebody spazzes and warps MIT-MC 9 months into the future. (It has happened before.) What if one of the files you check against was created by such a time-warped machine? Indeed, the normal case will be caught by your probable-bogosity meter, but when the baseline is bogus, then what? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082009390000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Tue 20 Aug 85 10:50:35-PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 299003; Tue 20-Aug-85 13:37:44-EDT Date: Tue, 20 Aug 85 13:39 EDT From: David C. Plummer in disguise Subject: voting on the time To: Christopher C. Stacy , jsq%tzec.UTEXAS@UT-SALLY.ARPA cc: TCP-IP@SRI-NIC.ARPA In-Reply-To: <[MIT-MC.ARPA].618951.850820.CSTACY> Message-ID: <850820133912.1.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. But what happens if somebody spazzes and warps MIT-MC 9 months into the future. (It has happened before.) What if one of the files you check against was created by such a time-warped machine? Indeed, the normal case will be caught by your probable-bogosity meter, but when the baseline is bogus, then what? What about systems who can't access the filesystem until the time is known? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10018%40ucbvax.ARPA] <1985082011042500> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Ether Broadcast Bedlam Message-ID: <10018@ucbvax.ARPA> Date: Tue, 20-Aug-85 15:04:25 EDT Article-I.D.: ucbvax.10018 Posted: Tue Aug 20 15:04:25 1985 Date-Received: Fri, 23-Aug-85 08:35:58 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 31 From: David C. Plummer in disguise Date: Mon, 19 Aug 85 23:30:25 EDT From: petry@trantor.ARPA (Michael G. Petry) Since I haven't seen any recent war stories, I'll pass along one that just attacked our shop. The first thing to do is get the bloody hardware fixed. What should be the second? Should a host be allowed to ARP reply as the ether broadcast address? My first impression is not, since all boards are suppose to be bound to a unique address. (maybe its time for a fast hack to disallow FF .. FF in if_ether.c) As an exercise think what happens if ipforwarding is off. The scenario is mildy better. I've seen this kind of story before. Maybe it was only in-house and didn't get out into the big-wide-world. The solution is to ignore ARP packets from people claiming to have any form of multicast hardware address (and that includes broadcast). You still need a low level netwatch program to realize somebody is trying to confuse the world. Is this what is meant by radiation tolerant components? P.S. Thanks to Interlan for having activity lights on boards. (It WASN'T their board that was broken) Thanks to John Romkey and friends for writting the PC/IP Netwatch program. (finally a good use for a PC) Mike Petry UOM Computer Science Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10023%40ucbvax.ARPA] <1985082011591200> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: voting on the time Message-ID: <10023@ucbvax.ARPA> Date: Tue, 20-Aug-85 15:59:12 EDT Article-I.D.: ucbvax.10023 Posted: Tue Aug 20 15:59:12 1985 Date-Received: Fri, 23-Aug-85 08:36:18 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 17 From: David C. Plummer in disguise Date: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. But what happens if somebody spazzes and warps MIT-MC 9 months into the future. (It has happened before.) What if one of the files you check against was created by such a time-warped machine? Indeed, the normal case will be caught by your probable-bogosity meter, but when the baseline is bogus, then what? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082012023200> Received: from MIT-MC.ARPA by SRI-NIC.ARPA with TCP; Tue 20 Aug 85 13:00:34-PDT Date: Tue, 20 Aug 85 16:02:32 EDT From: Christopher C. Stacy Subject: voting on the time To: DCP@SCRC-QUABBIN.ARPA cc: TCP-IP@SRI-NIC.ARPA, jsq%tzec.UTEXAS@UT-SALLY.ARPA Message-ID: <[MIT-MC.ARPA].619300.850820.CSTACY> Date: Tue, 20 Aug 85 13:39 EDT From: David C. Plummer in disguise To: Christopher C. Stacy , jsq%tzec.UTEXAS at UT-SALLY.ARPA cc: TCP-IP at SRI-NIC.ARPA Re: voting on the time In-Reply-To: <[MIT-MC.ARPA].618951.850820.CSTACY> Date: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. But what happens if somebody spazzes and warps MIT-MC 9 months into the future. (It has happened before.) What if one of the files you check against was created by such a time-warped machine? Indeed, the normal case will be caught by your probable-bogosity meter, but when the baseline is bogus, then what? Yeah, that's a pretty awful state to get into. Part of the recovery strategy for a file system which was active with the wrong time should be to locate (important) files which may have been written with the wrong date and fix them to sometime in the past, perhaps the shutdown time. The file date hack is not intended as a recovery mechanism for bad times. It is merely another source of information that tells you when things appear inconsistant. Some human who knows better can come along and consult a sundial or something to decide which time is really correct. Also, the file date check is only useful for fairly gross times. It might be appropriate to use it when booting the system to see if tomorrow is yesterday, but I wouldn't bother trying to use it for second (or minute) accuracy. What about systems who can't access the filesystem until the time is known? That's what "almost everyone" in my statement refers to. You obviously can't use this hack if you can't read the file directory information. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10027%40ucbvax.ARPA] <1985082012583500> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: voting on the time Message-ID: <10027@ucbvax.ARPA> Date: Tue, 20-Aug-85 16:58:35 EDT Article-I.D.: ucbvax.10027 Posted: Tue Aug 20 16:58:35 1985 Date-Received: Fri, 23-Aug-85 08:36:59 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 18 From: David C. Plummer in disguise Date: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. But what happens if somebody spazzes and warps MIT-MC 9 months into the future. (It has happened before.) What if one of the files you check against was created by such a time-warped machine? Indeed, the normal case will be caught by your probable-bogosity meter, but when the baseline is bogus, then what? What about systems who can't access the filesystem until the time is known? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10028%40ucbvax.ARPA] <1985082013475400> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: voting on the time Message-ID: <10028@ucbvax.ARPA> Date: Tue, 20-Aug-85 17:47:54 EDT Article-I.D.: ucbvax.10028 Posted: Tue Aug 20 17:47:54 1985 Date-Received: Fri, 23-Aug-85 20:27:05 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 48 From: Christopher C. Stacy Date: Tue, 20 Aug 85 13:39 EDT From: David C. Plummer in disguise To: Christopher C. Stacy , jsq%tzec.UTEXAS at UT-SALLY.ARPA cc: TCP-IP at SRI-NIC.ARPA Re: voting on the time In-Reply-To: <[MIT-MC.ARPA].618951.850820.CSTACY> Date: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. But what happens if somebody spazzes and warps MIT-MC 9 months into the future. (It has happened before.) What if one of the files you check against was created by such a time-warped machine? Indeed, the normal case will be caught by your probable-bogosity meter, but when the baseline is bogus, then what? Yeah, that's a pretty awful state to get into. Part of the recovery strategy for a file system which was active with the wrong time should be to locate (important) files which may have been written with the wrong date and fix them to sometime in the past, perhaps the shutdown time. The file date hack is not intended as a recovery mechanism for bad times. It is merely another source of information that tells you when things appear inconsistant. Some human who knows better can come along and consult a sundial or something to decide which time is really correct. Also, the file date check is only useful for fairly gross times. It might be appropriate to use it when booting the system to see if tomorrow is yesterday, but I wouldn't bother trying to use it for second (or minute) accuracy. What about systems who can't access the filesystem until the time is known? That's what "almost everyone" in my statement refers to. You obviously can't use this hack if you can't read the file directory information. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10029%40ucbvax.ARPA] <1985082014405700> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Voting on time Message-ID: <10029@ucbvax.ARPA> Date: Tue, 20-Aug-85 18:40:57 EDT Article-I.D.: ucbvax.10029 Posted: Tue Aug 20 18:40:57 1985 Date-Received: Fri, 23-Aug-85 20:27:34 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 32 From: Richard Johnson When DCN1's time got screwed up a while back, I decided to never completely trust any system again. Thus I changed my program which gets the time upon system startup to use a rather involved system of verification. This program uses a udp broadcast on the local net to get time from all local systems. It also sends special udp requests to any systems listed on the command line. After getting all the replies it averages all the localnet times, throughs out the time farthest from the average if it's too far away (a parameter), and continues to do this until it either gets a bunch of times within a specified range or has one time left. After all of this, if it has a "usable" average (taken from more than one number all within the max. range), then it begins looking through the times received from the "special requests". The first one of these it finds which is within another settable range of the local average, it takes as an authority. Basically the idea is to avoid asking the operator to set the time as much as possible. As a last resort we call a special program "settime" which allows the operator to type in the date a time in almost any format he feels like. We always use "/bin/date" to actually set the time so that accounting information is updated correctly (this was a fast hack and I didn't feel like rewriting /bin/date). This program is available with anonymous ftp (password guest) from uci-icsa.arpa. Warning: It has never been run through lint and thus probably has lots of things in it people will not like. If anyone makes improvements, I would like to hear about them. ------------------------------------------------------------------------ Richard Johnson raj@uci.arpa (ARPA) UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10033%40ucbvax.ARPA] <1985082015344500> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: voting on the time Message-ID: <10033@ucbvax.ARPA> Date: Tue, 20-Aug-85 19:34:45 EDT Article-I.D.: ucbvax.10033 Posted: Tue Aug 20 19:34:45 1985 Date-Received: Fri, 23-Aug-85 20:29:54 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 18 From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) My assumption was that checking the time of independent hosts should be more dependable than checking anything on the local host, especially after a bad crash or operator error. There are many other things which netdate could do. Once it's chosen what it thinks is the set of most accurate hosts, it could take the RMS average, toss out anything which deviates too far, average again, and use the result as the time. It could poll the whole set of accurate hosts several times when averaging, or it could just poll the single most accurate host several times and average. It could notice the network latency and adjust for it. I may add some of these things (preferably after wiser heads remark on which ones would be most useful). What I wanted to start with was something simple which could be depended upon to reject truly bogus times. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082104051200> Received: from UCI-ICSA by SRI-NIC.ARPA with TCP; Wed 21 Aug 85 11:08:18-PDT To: tcp-ip@sri-nic Subject: Re: voting on the time Date: 21 Aug 85 11:05:12 PDT (Wed) Message-ID: <376.493495512@uci-icsa> From: Richard Johnson Received: from Localhost by UCI-ICSA; 21 Aug 85 11:07:11 PDT (Wed) > There are many other things which netdate could do. Once it's chosen > what it thinks is the set of most accurate hosts, it could take the > RMS average, toss out anything which deviates too far, average again, > and use the result as the time. My program takes a simple average, not RMS. However, the rest of the description is exactly what it does. > It could notice the network latency and adjust for it. I do this also. ------------------------------------------------------------------------ Richard Johnson raj@uci.arpa (ARPA) UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082108445700> Received: from ut-sally.ARPA by SRI-NIC.ARPA with TCP; Wed 21 Aug 85 21:37:27-PDT Posted-Date: Wed, 21 Aug 85 13:44:57 cdt Received: from tzec.UTEXAS (tzec.UTEXAS.ARPA) by ut-sally.ARPA (4.22/4.22) id AA01076; Wed, 21 Aug 85 13:50:29 cdt Date: Wed, 21 Aug 85 13:44:57 cdt From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) Message-Id: <8508211844.AA02298@tzec.UTEXAS> Received: by tzec.UTEXAS (4.24/4.22) id AA02298; Wed, 21 Aug 85 13:44:57 cdt To: raj@uci-icsa.arpa Subject: Re: Voting on time Cc: TCP-IP@SRI-NIC Basically the idea is to avoid asking the operator to set the time as much as possible. Same goal as I had, slightly different assumptions. I decided not to average over times from all known time servers because my experience in polling actual servers is that they tend to cluster in groups of hosts with times similar to a second or so, but the times of the groups can be different by as much as a minute or more. Also, the most accurate group is almost always the fastest one, not the one in the middle. And hosts which set their time directly from WWV or some other accurate outside source will almost always be more accurate than those which don't, except for the occasional instances when they're wildly wrong. Of course, since you choose to poll only your local network, and if no system on it has a WWV clock, averaging makes much more sense. Netdate does record the time change in /usr/adm/wtmp properly like /bin/date, though I neglected to mention it in the manual entry. I've updated the manual entry for that and a couple of other omissions, and I've added a few details to the verbose output option (the network delay is shown). The result is available by anonymous ftp from ut-sally as ~ftp/pub/netdate.c and ~ftp/pub/netdate.8. Also in the same directory are udp.timed.c and tcp.timed.c, which are implementations of the server end of RFC868, suitable for use with inetd. (Chris Kent earlier announced a UDP time server that doesn't need inetd.) Some people tried to retrieve things this morning and couldn't: we had a hardware problem with a disk; it's fixed now. All these things have been run through lint, and we use them on several systems here (im4u.ARPA and ut-sally.ARPA run both time servers). However, they haven't been around long, so don't be surprised if they have bugs, and please let me know about any you find. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082110292200> Received: from UCB-VAX.ARPA by SRI-NIC.ARPA with TCP; Thu 22 Aug 85 00:56:59-PDT Received: by UCB-VAX.ARPA (4.24/5.3) id AA08739; Thu, 22 Aug 85 00:58:49 pdt Received: from opus (opus.ARPA) by nbires (4.12/3.7) id AA00264; Wed, 21 Aug 85 16:29:40 mdt Date: Wed, 21 Aug 85 16:29:22 mdt From: nbires!cathy@Berkeley (Cathy Curley) Message-Id: <8508212229.AA19516@opus> Received: by opus (4.14/3.7) id AA19516; Wed, 21 Aug 85 16:29:22 mdt To: TCP-IP@SRI-NIC.ARPA I would like to be added to the mailing list. I also have a question I would like to submit to the users of this list. NBI is very new to networking, and so there are certain considerations which need addressing, one of which is training of our Field Personnel and troubleshooting in general. I have the responsibility of developing a comprehensive training course for network troubleshooting. However, since I have not yet seen an unhealthy network, I have no prior experience to go on. There is no documentation I can find on this subject, and so I am led to believe that troubleshooting techniques are learned through experience. If there are any suggestions on symptoms and their possible or probable cause, I would welcome them. If there is any documentation I have overlooked, I would welcome becoming aware of it. Thank you, Cathy Curley NBI - Service Planning ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10057%40ucbvax.ARPA] <1985082112165000> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: voting on the time Message-ID: <10057@ucbvax.ARPA> Date: Wed, 21-Aug-85 16:16:50 EDT Article-I.D.: ucbvax.10057 Posted: Wed Aug 21 16:16:50 1985 Date-Received: Sat, 24-Aug-85 14:18:15 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 17 From: Richard Johnson > There are many other things which netdate could do. Once it's chosen > what it thinks is the set of most accurate hosts, it could take the > RMS average, toss out anything which deviates too far, average again, > and use the result as the time. My program takes a simple average, not RMS. However, the rest of the description is exactly what it does. > It could notice the network latency and adjust for it. I do this also. ------------------------------------------------------------------------ Richard Johnson raj@uci.arpa (ARPA) UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082112200000> Received: from csnet-relay by SRI-NIC.ARPA with TCP; Wed 21 Aug 85 16:24:48-PDT Received: from northeastern by csnet-relay.csnet id a001569; 21 Aug 85 19:23 EDT Date: Wed, 21 Aug 85 17:20 EST From: Chris Johnson To: tcp-ip@sri-nic.ARPA cc: johnson%northeastern.csnet@csnet-relay.arpa Subject: ??????? Everyone has bad days now and then. After a hard day of fighting fires, crashed networks, clogged networks, irate users, obfuscated software and hardware bugs ... etc... one finds oneself in desperate need of a good chuckle or the occasional guffaw. One would not usually think of a network as the place to find the necessary release. Although I do get VERY useful information from the tcp-ip@sri-nic mailing list (thank you), I wish to thank those that have it for their sense of humor and proportion. These are good things to have when dealing with computers (most of whom don't have either a sense of humor or a sense of proportion) and users (many of which suffer similar complaints). Chris Johnson Northeastern University johnson%northeastern@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10069%40ucbvax.ARPA] <1985082116254500> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: ??????? Message-ID: <10069@ucbvax.ARPA> Date: Wed, 21-Aug-85 20:25:45 EDT Article-I.D.: ucbvax.10069 Posted: Wed Aug 21 20:25:45 1985 Date-Received: Sat, 24-Aug-85 14:21:43 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 19 From: Chris Johnson Everyone has bad days now and then. After a hard day of fighting fires, crashed networks, clogged networks, irate users, obfuscated software and hardware bugs ... etc... one finds oneself in desperate need of a good chuckle or the occasional guffaw. One would not usually think of a network as the place to find the necessary release. Although I do get VERY useful information from the tcp-ip@sri-nic mailing list (thank you), I wish to thank those that have it for their sense of humor and proportion. These are good things to have when dealing with computers (most of whom don't have either a sense of humor or a sense of proportion) and users (many of which suffer similar complaints). Chris Johnson Northeastern University johnson%northeastern@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10081%40ucbvax.ARPA] <1985082121373400> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: Voting on time Message-ID: <10081@ucbvax.ARPA> Date: Thu, 22-Aug-85 01:37:34 EDT Article-I.D.: ucbvax.10081 Posted: Thu Aug 22 01:37:34 1985 Date-Received: Sat, 24-Aug-85 14:34:51 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 34 From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) Basically the idea is to avoid asking the operator to set the time as much as possible. Same goal as I had, slightly different assumptions. I decided not to average over times from all known time servers because my experience in polling actual servers is that they tend to cluster in groups of hosts with times similar to a second or so, but the times of the groups can be different by as much as a minute or more. Also, the most accurate group is almost always the fastest one, not the one in the middle. And hosts which set their time directly from WWV or some other accurate outside source will almost always be more accurate than those which don't, except for the occasional instances when they're wildly wrong. Of course, since you choose to poll only your local network, and if no system on it has a WWV clock, averaging makes much more sense. Netdate does record the time change in /usr/adm/wtmp properly like /bin/date, though I neglected to mention it in the manual entry. I've updated the manual entry for that and a couple of other omissions, and I've added a few details to the verbose output option (the network delay is shown). The result is available by anonymous ftp from ut-sally as ~ftp/pub/netdate.c and ~ftp/pub/netdate.8. Also in the same directory are udp.timed.c and tcp.timed.c, which are implementations of the server end of RFC868, suitable for use with inetd. (Chris Kent earlier announced a UDP time server that doesn't need inetd.) Some people tried to retrieve things this morning and couldn't: we had a hardware problem with a disk; it's fixed now. All these things have been run through lint, and we use them on several systems here (im4u.ARPA and ut-sally.ARPA run both time servers). However, they haven't been around long, so don't be surprised if they have bugs, and please let me know about any you find. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082216481900> Received: from UCB-VAX.ARPA by SRI-NIC.ARPA with TCP; Thu 22 Aug 85 23:49:22-PDT Received: from aerospace (aerospace.arpa.ARPA) by UCB-VAX.ARPA (4.24/5.3) id AA05131; Thu, 22 Aug 85 23:50:09 pdt Message-Id: <8508230650.AA05131@UCB-VAX.ARPA> Date: Thu, 22 Aug 85 23:48:19 PDT From: Richard K. Jennings To: tcp-ip@Berkeley Subject: Ether Broadcast Bedlam In-Reply-To: <10018@ucbvax.ARPA> please delete me from this newsgroup. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10145%40ucbvax.ARPA] <1985082223595400> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Ether Broadcast Bedlam Message-ID: <10145@ucbvax.ARPA> Date: Fri, 23-Aug-85 03:59:54 EDT Article-I.D.: ucbvax.10145 Posted: Fri Aug 23 03:59:54 1985 Date-Received: Sat, 24-Aug-85 20:00:02 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 3 From: Richard K. Jennings please delete me from this newsgroup. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082302580000> Received: from nprdc.ARPA by SRI-NIC.ARPA with TCP; Fri 23 Aug 85 09:58:56-PDT Received: from pacific.ARPA by nprdc.ARPA (4.12/4.7) id AA20373; Fri, 23 Aug 85 09:59:48 pdt Received: by pacific.ARPA (4.12/4.7) id AA11013; Fri, 23 Aug 85 09:59:27 pdt From: stanonik@nprdc.arpa (Ron Stanonik) Message-Id: <8508231659.AA11013@pacific.ARPA> Date: 23 August 1985 0958-PDT (Friday) To: tcp-ip@sri-nic Subject: ien 116 name server One of our users acquired a tcp/ip implementation for their ibm pc. It seems look for an ien 116 style name server for hostname lookup; ie, udp port 42. Are any implementations of the ien 116 server available for unix, preferably 4.2bsd? Thanks, Ron Stanonik stanonik@nprdc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082303561200> Received: from rand-unix.ARPA by SRI-NIC.ARPA with TCP; Fri 23 Aug 85 10:56:30-PDT Return-Path: Received: from condor.arpa (condor) by rand-unix.ARPA; Fri, 23 Aug 85 10:59:05 pdt Received: by condor.arpa; Fri, 23 Aug 85 10:56:16 pdt Message-Id: <8508231756.AA08487@condor.arpa> To: stanonik@nprdc.arpa (Ron Stanonik) Cc: tcp-ip@sri-nic Cc: guyton%condor@rand-unix.ARPA Subject: Re: ien 116 name server In-Reply-To: Your message of 23 August 1985 0958-PDT (Friday). <8508231659.AA11013@pacific.ARPA> Date: 23 Aug 85 10:56:12 PDT (Fri) From: guyton%condor@rand-unix.ARPA Yup, I just wrote one (for the same reason). I've also been making lots of bug-fixes to the 4.2bsd tftp code. -- Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10158%40ucbvax.ARPA] <1985082310010000> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: ien 116 name server Message-ID: <10158@ucbvax.ARPA> Date: Fri, 23-Aug-85 14:01:00 EDT Article-I.D.: ucbvax.10158 Posted: Fri Aug 23 14:01:00 1985 Date-Received: Sun, 25-Aug-85 00:06:13 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 11 From: stanonik@nprdc.arpa (Ron Stanonik) One of our users acquired a tcp/ip implementation for their ibm pc. It seems look for an ien 116 style name server for hostname lookup; ie, udp port 42. Are any implementations of the ien 116 server available for unix, preferably 4.2bsd? Thanks, Ron Stanonik stanonik@nprdc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10159%40ucbvax.ARPA] <1985082310544000> 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.ARPA From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Re: ien 116 name server Message-ID: <10159@ucbvax.ARPA> Date: Fri, 23-Aug-85 14:54:40 EDT Article-I.D.: ucbvax.10159 Posted: Fri Aug 23 14:54:40 1985 Date-Received: Sun, 25-Aug-85 00:06:25 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 6 From: guyton%condor@rand-unix.ARPA Yup, I just wrote one (for the same reason). I've also been making lots of bug-fixes to the 4.2bsd tftp code. -- Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8508261710.AA00243%40gwen.ARPA] <1985082609102100> 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.ARPA From: albitz@Purdue.EDU (Paul M. Albitz) Newsgroups: fa.tcp-ip Subject: mail getting to purdue Message-ID: <8508261710.AA00243@gwen.ARPA> Date: Mon, 26-Aug-85 13:10:21 EDT Article-I.D.: gwen.8508261710.AA00243 Posted: Mon Aug 26 13:10:21 1985 Date-Received: Wed, 28-Aug-85 20:51:56 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: the arpa internet Lines: 8 I understand there are some sites that are having trouble mailing to purdue. We have moved to a new building and have lost one imp connection and its associated address (10.0.0.37). The names purdue.arpa and purdue.edu are now associated with the machine purdue-mordred with the address 128.10.0.2. If you are having trouble mailing to us, please update your files. Paul Albitz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8508262233.AA06887%40UCB-VAX.ARPA] <1985082613260000> 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.ARPA From: dca-pgs@DDN1.ARPA Newsgroups: fa.tcp-ip Subject: Gateway Requirements Query Message-ID: <8508262233.AA06887@UCB-VAX.ARPA> Date: Mon, 26-Aug-85 17:26:00 EDT Article-I.D.: UCB-VAX.8508262233.AA06887 Posted: Mon Aug 26 17:26:00 1985 Date-Received: Wed, 28-Aug-85 20:55:42 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: the arpa internet Lines: 46 Comment: Forwarded message(s): ----------------------------------------------------- Received: by EDN-VAX.ARPA (4.12/4.7) Date: Mon, 26 Aug 85 17:19:34 edt From: sullivan @ EDN-VAX.ARPA To: dca-pgs @ ddn1.APRA, sullivan @ EDN-VAX.ARPA Text: My question is this: I manage the Integrated AUTODIN System (IAS) RDT&R E Project. A task under this project is the Multinet Gatewau y, which the Air Force is building for us. I , or ut od f RADC. The MG is an IP gatewaay y which can accomodate n modate a number of different kinds of LAN and lo network interfaces, LAN and long-haul. It will also be A-1 multi- certified as a multi-level secure system tto o the A-1 level. The DDN Ford Aerospace is the prime contractoe r for this, with SDC as a sub for the certification. Six ADM's will be delivered to the DDN PMO for T&E. The DDN PMO will be using these in their security architecture as Gu so-called Guard Gateways. The Ait r Force os is people are submitting an FY87 POM input for full-scale development (and a limited production run ) in FY88. To To defend their POM submission, they need to reference some some requirements and prospective users. Hence my note; I'm trying to sound out people on w the Govre ernment net managers that I can find out about if they might conceivably be able to use something like this. I am not looking for money funding. I am looking for potentail ial future requirements. Also, if you anybody wanted to make arrangements to buy one of these things for their facility, (it would make a lot of sense as a trusted local compartmented distributor) we could ; 'll have the be in a position to have contracual tual vegi hicles in place to buy these. Thank you, Pat Sullivan Defense Communications Engineering Center Reston, VA. VON 364-2165 Com om 703-437-2165 -------------END OF FORWARDED MESSAGE(S)------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082613260001> Received: from ddn1 by SRI-NIC.ARPA with TCP; Mon 26 Aug 85 14:35:20-PDT Date: 26 Aug 85 17:26 EDT From: dca-pgs @ DDN1.ARPA Subject: Gateway Requirements Query To: tcp-ip @ sri-nic.arpa Comment: Forwarded message(s): ----------------------------------------------------- Received: by EDN-VAX.ARPA (4.12/4.7) Date: Mon, 26 Aug 85 17:19:34 edt From: sullivan @ EDN-VAX.ARPA To: dca-pgs @ ddn1.APRA, sullivan @ EDN-VAX.ARPA Text: My question is this: I manage the Integrated AUTODIN System (IAS) RDT&RE Project. A task under this project is the Multinet Gatewauy, which the Air Force is building for us. I, orut odf RADC. The MG is an IP gatewaayy which can accomodate nmodate a number of different kinds of LAN and lonetwork interfaces, LAN and long-haul. It will also be A-1 multi-certified as a multi-level secure system ttoo the A-1 level. The DDN Ford Aerospace is the prime contractoer for this, with SDC as a sub for the certification. Six ADM's will be delivered to the DDN PMO for T&E. The DDN PMO will be using these in their security architecture as Guso-called Guard Gateways. The Aitr Force osis people are submitting an FY87 POM input for full-scale development (and a limited production run ) in FY88. ToTo defend their POM submission, they need to reference somesome requirements and prospective users. Hence my note; I'm trying to sound out people on wthe Govreernment net managers that I can find out about if they might conceivably be able to use something like this. I am not looking for moneyfunding. I am looking for potentailial future requirements. Also, if you anybody wanted to make arrangements to buy one of these things for their facility, (it would make a lot of sense as a trusted local compartmented distributor) we could ;'ll have the be in a position to have contracualtual vegihicles in place to buy these. Thank you, Pat Sullivan Defense Communications Engineering Center Reston, VA. VON 364-2165 Comom 703-437-2165 -------------END OF FORWARDED MESSAGE(S)------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8508272248.AA11035%40UCB-VAX.ARPA] <1985082713040000> 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.ARPA From: dca-pgs@DDN1.ARPA Newsgroups: fa.tcp-ip Subject: Gateway Requirements Query - Resend Message-ID: <8508272248.AA11035@UCB-VAX.ARPA> Date: Tue, 27-Aug-85 17:04:00 EDT Article-I.D.: UCB-VAX.8508272248.AA11035 Posted: Tue Aug 27 17:04:00 1985 Date-Received: Fri, 30-Aug-85 00:36:07 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: the arpa internet Lines: 45 Comment: The other one had a lot of "hard" backspaces in it and I got some complaints about readability. Sorry about that - -Pat s. Forwarded message(s): ----------------------------------------------------- To: dca-pgs @ DDN1 From: dca-pgs @ DDN1 Subject: Gateway Query Date: 27 Aug 85 16:45 EDT cc: Text: My question is this: I manage the Integrated AUTODIN System (IAS) RDT&E Project. A task under this project is the Multinet Gateway which the AF is building for us out of RADC. It is an IP gateway which can accommodate a number of different kinds of network interfaces, both LAN and long-haul. It will also be certified as a multi-level secure system to the A-1 level. Ford Aerospace is the prime contractor for this. The purpose of this note is to sound out any government net managers who might conceivably have a requirement for this gateway. The Air Force folks are trying to gather requirements to defend their POM submission, which includes Full Scale Development and a limited production run in FY88. The Gateway would appear to have considerable utility as a trusted local "permissive separator", especially in a heavily LAN'd/WAN'd facility with different networks. Once the funding battles are mastered, people who want to actually buy and field the Multinet Gateway acn talk about contractual vehicles to achieve that. All info & assistance appreciated. Thank you, -Pat Sullivan IAS RDT&E Project Mgr Defense Communications Engineering Center Reston, VA. VON 364-2165 Com 703-437-x. -------------END OF FORWARDED MESSAGE(S)------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082713040001> Received: from ddn1 by SRI-NIC.ARPA with TCP; Tue 27 Aug 85 14:13:58-PDT Date: 27 Aug 85 17:04 EDT From: dca-pgs @ DDN1.ARPA Subject: Gateway Requirements Query - Resend To: srose @ dca-ems.arpa, wnielsen @ dca-ems.arpa, tcp-ip @ sri-nic.arpa Comment: The other one had a lot of "hard" backspaces in it and I got some complaints about readability. Sorry about that - -Pat s. Forwarded message(s): ----------------------------------------------------- To: dca-pgs @ DDN1 From: dca-pgs @ DDN1 Subject: Gateway Query Date: 27 Aug 85 16:45 EDT cc: Text: My question is this: I manage the Integrated AUTODIN System (IAS) RDT&E Project. A task under this project is the Multinet Gateway which the AF is building for us out of RADC. It is an IP gateway which can accommodate a number of different kinds of network interfaces, both LAN and long-haul. It will also be certified as a multi-level secure system to the A-1 level. Ford Aerospace is the prime contractor for this. The purpose of this note is to sound out any government net managers who might conceivably have a requirement for this gateway. The Air Force folks are trying to gather requirements to defend their POM submission, which includes Full Scale Development and a limited production run in FY88. The Gateway would appear to have considerable utility as a trusted local "permissive separator", especially in a heavily LAN'd/WAN'd facility with different networks. Once the funding battles are mastered, people who want to actually buy and field the Multinet Gateway acn talk about contractual vehicles to achieve that. All info & assistance appreciated. Thank you, -Pat Sullivan IAS RDT&E Project Mgr Defense Communications Engineering Center Reston, VA. VON 364-2165 Com 703-437-x. -------------END OF FORWARDED MESSAGE(S)------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8508282036.AA03463%40UCB-VAX.ARPA] <1985082811090000> 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.ARPA From: nsi@DDN1.ARPA Newsgroups: fa.tcp-ip Subject: Ethernet Message-ID: <8508282036.AA03463@UCB-VAX.ARPA> Date: Wed, 28-Aug-85 15:09:00 EDT Article-I.D.: UCB-VAX.8508282036.AA03463 Posted: Wed Aug 28 15:09:00 1985 Date-Received: Fri, 30-Aug-85 11:05:21 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 3 Does anyone know of software which is presently available to interface Ethernet (CSMA/CD) to the DDN using the standard DOD protocols (i.e.,TCP/IP,TELNET,FTP,SMFTP) ? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082811090001> Received: from ddn1 by SRI-NIC.ARPA with TCP; Wed 28 Aug 85 12:22:53-PDT Date: 28 Aug 85 15:09 EDT From: nsi @ DDN1.ARPA Subject: Ethernet To: tcp-ip @ sri-nic.arpa Does anyone know of software which is presently available to interface Ethernet (CSMA/CD) to the DDN using the standard DOD protocols (i.e.,TCP/IP,TELNET,FTP,SMFTP) ? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8508300028.AA05209%40UCB-VAX.ARPA] <1985082914520800> 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.ARPA From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: fa.tcp-ip Subject: interesting loop Message-ID: <8508300028.AA05209@UCB-VAX.ARPA> Date: Thu, 29-Aug-85 18:52:08 EDT Article-I.D.: UCB-VAX.8508300028.AA05209 Posted: Thu Aug 29 18:52:08 1985 Date-Received: Sat, 31-Aug-85 05:48:50 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 99 We just got our IP network into a loop. It's clearly my fault, but the problem is subtle enough that I thought it might be useful for me to point it out to others. It is important to understand our network configuration. We have two Ethernets, 128.6.3 and 128.6.4. For readability, I am going to drop the 128.6 and refer to them as networks 3 and 4. They are connected by two gateways. One of them is a Pyramid 90x (4.2 Unix). It is configured to act as a normal IP gateway. Because not all of our systems know about subnetting, it also does the "ARP hack". Suppose host 128.6.4.2 (which I will refer to as 4.2, since I am dropping 128.6) wants to talk to host 3.1. It will send out an ARP: from 4.2, broadcast, who is 3.1? The gateway will see this ARP request. It will check its tables, realize that the sender needs gatewaying to talk to the target, and that it is prepared to act as that gateway. So the gateway will respond from gateway, to 4.2, 3.1 is This is a lie, since it is claiming that its own Ethernet address is 3.1's. But the lie is useful, since it will cause 4.2 to send its packets to the gateway, which will deliver them. The second gateway is an Applitek Ethernet bridge. This is a broadband cable system onto which you can put Ethernet bridges. They are not IP gateways. Instead, they are "transparent" Ethernet-level gateways. Each bridge runs in promiscuous mode, looking at every packet on its Ethernet. When it sees any packet addressed to someone on a different Ethernet, it sends the packet over the broadband to the bridge on the appropriate Ethernet. It makes no changes to the packet. This is totally invisible to the hosts. The hosts think we just have one big Ethernet. Now, consider what happens when 4.2 wants to talk to 3.1. It will send out an ARP from 4.2, broadcast, who is 3.1? The bridge on network 4 will pass this to the bridge on 3, which will then broadcast it. 3.1 will see it, and respond from 3.1 to 4.2, 3.1 is The bridge will pass this packet back to network 4, whose bridge will send it to 4.2. The connection is now set up, and all of the packets will follow this same path. Now for the fun. Consider what will happen when a host wants to talk to another host on the same network: from 4.2, broadcast, who is 4.3? First, 4.3 will see this, and respond from 4.3 to 4.2, 4.3 is However the Applitek bridge will pick up the original broadcast and repeat it on all of the other subnets. (Since the bridges are protocol-independent, they know nothing about Internet addresses. They have no way to know that the ARP will be satisfied locally. Thus they forward all broadcasts to all subnets. This is moderately reasonable.) In particular, it will repeat it on network 3. Our Pyramid gateway will see this request. Since it is an ARP on network 3 looking for a host on network 4, the Pyramid will offer to gateway: from gateway to 4.2, 4.3 is The Applitek bridge will pick this on on network 3 and pass it back to 4, where it gets sent back to 4.2. If 4.2 is a Unix system, it will believe the last ARP reply that it sees. So we now have an ARP entry: 4.3 gateway's address on network 3 The funny thing is, this may work. Packets destined for 4.3 will be sent to the gateway's other side. The Applitek bridge will see an Ethernet address on the other subnet, and forward it. The gateway will get the packet, and forward it back to network 4, where it will presumably be delivered to the correct place. However the gateway itself is not immune from this problem (at least not with the code I have in it now). When the gateway attempts to talk to 4.3, the ARP packet will again be forwarded to the other subnet, and the gateway itself will respond. Thus the gateway will end up with an ARP table entry containing 4.3 gateway's own address on network 3 At this point we have a loop. Obviously the simplest answer is that as long as the Applitek system is working, we turn off the Pyramid gateway code. However we would like that code to be available as a backup should the Applitek system go down. It begins to appear that we are going to have to check specifically for this sort of situation. However in a complex network topology, it may not be entirely clear who one should and should not be willing to gateway for. It is possible that the real moral is that "transparent" gateways and IP gateways may have trouble coexisting. Let my hasten to point out that both the subnetting implementation and the "ARP hacking" code on the Pyramid are mine. They should not be blamed on either Berkeley or Pyramid. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985082914520801> Received: from RED.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Thu 29 Aug 85 15:53:29-PDT Date: 29 Aug 85 18:52:08 EDT From: Charles Hedrick Subject: interesting loop To: tcp-ip@SRI-NIC.ARPA cc: remarks@RED.RUTGERS.EDU, marantz@RED.RUTGERS.EDU We just got our IP network into a loop. It's clearly my fault, but the problem is subtle enough that I thought it might be useful for me to point it out to others. It is important to understand our network configuration. We have two Ethernets, 128.6.3 and 128.6.4. For readability, I am going to drop the 128.6 and refer to them as networks 3 and 4. They are connected by two gateways. One of them is a Pyramid 90x (4.2 Unix). It is configured to act as a normal IP gateway. Because not all of our systems know about subnetting, it also does the "ARP hack". Suppose host 128.6.4.2 (which I will refer to as 4.2, since I am dropping 128.6) wants to talk to host 3.1. It will send out an ARP: from 4.2, broadcast, who is 3.1? The gateway will see this ARP request. It will check its tables, realize that the sender needs gatewaying to talk to the target, and that it is prepared to act as that gateway. So the gateway will respond from gateway, to 4.2, 3.1 is This is a lie, since it is claiming that its own Ethernet address is 3.1's. But the lie is useful, since it will cause 4.2 to send its packets to the gateway, which will deliver them. The second gateway is an Applitek Ethernet bridge. This is a broadband cable system onto which you can put Ethernet bridges. They are not IP gateways. Instead, they are "transparent" Ethernet-level gateways. Each bridge runs in promiscuous mode, looking at every packet on its Ethernet. When it sees any packet addressed to someone on a different Ethernet, it sends the packet over the broadband to the bridge on the appropriate Ethernet. It makes no changes to the packet. This is totally invisible to the hosts. The hosts think we just have one big Ethernet. Now, consider what happens when 4.2 wants to talk to 3.1. It will send out an ARP from 4.2, broadcast, who is 3.1? The bridge on network 4 will pass this to the bridge on 3, which will then broadcast it. 3.1 will see it, and respond from 3.1 to 4.2, 3.1 is The bridge will pass this packet back to network 4, whose bridge will send it to 4.2. The connection is now set up, and all of the packets will follow this same path. Now for the fun. Consider what will happen when a host wants to talk to another host on the same network: from 4.2, broadcast, who is 4.3? First, 4.3 will see this, and respond from 4.3 to 4.2, 4.3 is However the Applitek bridge will pick up the original broadcast and repeat it on all of the other subnets. (Since the bridges are protocol-independent, they know nothing about Internet addresses. They have no way to know that the ARP will be satisfied locally. Thus they forward all broadcasts to all subnets. This is moderately reasonable.) In particular, it will repeat it on network 3. Our Pyramid gateway will see this request. Since it is an ARP on network 3 looking for a host on network 4, the Pyramid will offer to gateway: from gateway to 4.2, 4.3 is The Applitek bridge will pick this on on network 3 and pass it back to 4, where it gets sent back to 4.2. If 4.2 is a Unix system, it will believe the last ARP reply that it sees. So we now have an ARP entry: 4.3 gateway's address on network 3 The funny thing is, this may work. Packets destined for 4.3 will be sent to the gateway's other side. The Applitek bridge will see an Ethernet address on the other subnet, and forward it. The gateway will get the packet, and forward it back to network 4, where it will presumably be delivered to the correct place. However the gateway itself is not immune from this problem (at least not with the code I have in it now). When the gateway attempts to talk to 4.3, the ARP packet will again be forwarded to the other subnet, and the gateway itself will respond. Thus the gateway will end up with an ARP table entry containing 4.3 gateway's own address on network 3 At this point we have a loop. Obviously the simplest answer is that as long as the Applitek system is working, we turn off the Pyramid gateway code. However we would like that code to be available as a backup should the Applitek system go down. It begins to appear that we are going to have to check specifically for this sort of situation. However in a complex network topology, it may not be entirely clear who one should and should not be willing to gateway for. It is possible that the real moral is that "transparent" gateways and IP gateways may have trouble coexisting. Let my hasten to point out that both the subnetting implementation and the "ARP hacking" code on the Pyramid are mine. They should not be blamed on either Berkeley or Pyramid. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985083002433700> Received: from su-shasta.arpa by SRI-NIC.ARPA with TCP; Fri 30 Aug 85 21:28:20-PDT Received: by su-shasta.arpa with TCP; Fri, 30 Aug 85 21:26:41 pdt From: imagen!geof@su-shasta.ARPA Received: by imagen.UUCP; Fri, 30 Aug 85 09:44:23 pdt To: Charles Hedrick Cc: shasta!tcp-ip@SRI-NIC.ARPA Reply-To: imagen!geof@shasta Phone: (408) 986-9400 (work) Postal-Address: IMAGEN, 2650 San Thomas Expressway, Santa Clara, CA 95052 Real-Name: Geoffrey H. Cooper Subject: Re: interesting loop In-Reply-To: Your message of 29 Aug 85 18:52:08 EDT. Date: 30 Aug 85 09:43:37 PDT (Fri) Actually, the real moral of the story is that transparent gateways and transparent gateways have trouble coexisting. If you had been using a real IP gateway (no criticism intended) there would have been no problem. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985083004100000> Received: from Navajo by SRI-NIC.ARPA with TCP; Fri 30 Aug 85 11:13:40-PDT Date: 30 Aug 1985 1110-PDT (Friday) From: Jeff Mogul To: Charles Hedrick Cc: remarks@RUTGERS, marantz@RUTGERS, tcp-ip@SRI-NIC.ARPA Subject: Re: interesting loop Obviously the simplest answer is that as long as the Applitek system is working, we turn off the Pyramid gateway code. However we would like that code to be available as a backup should the Applitek system go down. It begins to appear that we are going to have to check specifically for this sort of situation. However in a complex network topology, it may not be entirely clear who one should and should not be willing to gateway for. It is possible that the real moral is that "transparent" gateways and IP gateways may have trouble coexisting. What is going on here is that the two gateways (transparent and IP) are based on different models of the world; the transparent gateway (bridge) assumes that it should act like a piece of wire, i.e. that the cables connected to it should appear to be electrically connected. In this model, forwarding the broadcasts (ARP messages) is not only legal but required. The IP gateway does not assume this; specifically, the "ARP hack" assumes that the cables are NOT electrically connected. In this model, forwarding of undirected broadcasts is a no-no. I believe the moral is that one should not mix metaphors. If you don't want to use your Pyramid as a full-time gateway, buy a gateway box from someone. Scrap the Applitek, or use it to physically extend a subnet and pray that it doesn't fail. Question of the day: is it possible to put two Appliteks (or any other transparent bridges) in parallel, for reasons of reliability, without getting into a loop? If not, then you shouldn't expect that putting a bridge in parallel with a gateway should work any better. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8508310508.AA04128%40UCB-VAX.ARPA] <1985083008433700> 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.ARPA From: geof@su-shasta.ARPA Newsgroups: fa.tcp-ip Subject: Re: interesting loop Message-ID: <8508310508.AA04128@UCB-VAX.ARPA> Date: Fri, 30-Aug-85 12:43:37 EDT Article-I.D.: UCB-VAX.8508310508.AA04128 Posted: Fri Aug 30 12:43:37 1985 Date-Received: Sat, 31-Aug-85 21:24:40 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 7 Actually, the real moral of the story is that transparent gateways and transparent gateways have trouble coexisting. If you had been using a real IP gateway (no criticism intended) there would have been no problem. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8508302018.AA25441%40UCB-VAX.ARPA] <1985083009222200> 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.ARPA From: root%bostonu.csnet@csnet-relay.arpa (BostonU SysMgr) Newsgroups: fa.tcp-ip Subject: Re: interesting loop Message-ID: <8508302018.AA25441@UCB-VAX.ARPA> Date: Fri, 30-Aug-85 13:22:22 EDT Article-I.D.: UCB-VAX.8508302018.AA25441 Posted: Fri Aug 30 13:22:22 1985 Date-Received: Sat, 31-Aug-85 21:23:22 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 30 Re: Packet loops caused by dumb broad/base band gateways This is one of the major reasons why at Boston University we chose to put our broad/base band gateways into our 4.2 hosts, we use Ungermann/Bass Net/1 DR11-W (soon SUN also) NIUs. The 4.2 hosts then are just typical gateways and are intelligent about IP and our broadband interfaces are completely analagous to our baseband (eg. they support ARP.) For reliability we have more than one 4.2 host on our baseband with broadband interfaces. Routed (with the bugs removed) takes care of transitions for us, it all works quite smoothly and I have not yet detected it to cause any load. Further, those hosts with broadband interfaces just talk to each other directly under this scheme, rather than routing over ethernets. I was always very suspicious about this mindless gateway approach for this and a few other reasons, like what happens to your broadcast packets? I am sure there is a reasonable solution to this, but utilizing the broadband directly seemed the way to go. If I needed to add PUP or XNS I am pretty sure it would just be a 'typical' job to recognize those packets need to be forwarded in the drivers. If I needed to gateway DECNET, I would tell them too bad, I told you to stay away from it (I am anticipating a response viz a viz the need to support other protocols on the system.) We in fact can give our DECNET hosts 19.2kb synchronous p-p interfaces on our broadband cable which is about all they can expect. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985083009222201> Received: from csnet-relay by SRI-NIC.ARPA with TCP; Fri 30 Aug 85 11:55:58-PDT Received: from bostonu by csnet-relay.csnet id ai01167; 30 Aug 85 14:44 EDT Received: by bu-cs.ARPA (4.12/4.7) id AA00373; Fri, 30 Aug 85 13:22:22 edt Date: Fri, 30 Aug 85 13:22:22 edt From: BostonU SysMgr To: HEDRICK@rutgers.csnet, tcp-ip@SRI-NIC.ARPA Subject: Re: interesting loop Cc: marantz@rutgers.csnet, remarks@rutgers.csnet Re: Packet loops caused by dumb broad/base band gateways This is one of the major reasons why at Boston University we chose to put our broad/base band gateways into our 4.2 hosts, we use Ungermann/Bass Net/1 DR11-W (soon SUN also) NIUs. The 4.2 hosts then are just typical gateways and are intelligent about IP and our broadband interfaces are completely analagous to our baseband (eg. they support ARP.) For reliability we have more than one 4.2 host on our baseband with broadband interfaces. Routed (with the bugs removed) takes care of transitions for us, it all works quite smoothly and I have not yet detected it to cause any load. Further, those hosts with broadband interfaces just talk to each other directly under this scheme, rather than routing over ethernets. I was always very suspicious about this mindless gateway approach for this and a few other reasons, like what happens to your broadcast packets? I am sure there is a reasonable solution to this, but utilizing the broadband directly seemed the way to go. If I needed to add PUP or XNS I am pretty sure it would just be a 'typical' job to recognize those packets need to be forwarded in the drivers. If I needed to gateway DECNET, I would tell them too bad, I told you to stay away from it (I am anticipating a response viz a viz the need to support other protocols on the system.) We in fact can give our DECNET hosts 19.2kb synchronous p-p interfaces on our broadband cable which is about all they can expect. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8508301920.AA23992%40UCB-VAX.ARPA] <1985083010100000> 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.ARPA From: mogul@Navajo (Jeff Mogul) Newsgroups: fa.tcp-ip Subject: Re: interesting loop Message-ID: <8508301920.AA23992@UCB-VAX.ARPA> Date: Fri, 30-Aug-85 14:10:00 EDT Article-I.D.: UCB-VAX.8508301920.AA23992 Posted: Fri Aug 30 14:10:00 1985 Date-Received: Sat, 31-Aug-85 21:22:57 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.berkeley.edu Organization: The ARPA Internet Lines: 32 Obviously the simplest answer is that as long as the Applitek system is working, we turn off the Pyramid gateway code. However we would like that code to be available as a backup should the Applitek system go down. It begins to appear that we are going to have to check specifically for this sort of situation. However in a complex network topology, it may not be entirely clear who one should and should not be willing to gateway for. It is possible that the real moral is that "transparent" gateways and IP gateways may have trouble coexisting. What is going on here is that the two gateways (transparent and IP) are based on different models of the world; the transparent gateway (bridge) assumes that it should act like a piece of wire, i.e. that the cables connected to it should appear to be electrically connected. In this model, forwarding the broadcasts (ARP messages) is not only legal but required. The IP gateway does not assume this; specifically, the "ARP hack" assumes that the cables are NOT electrically connected. In this model, forwarding of undirected broadcasts is a no-no. I believe the moral is that one should not mix metaphors. If you don't want to use your Pyramid as a full-time gateway, buy a gateway box from someone. Scrap the Applitek, or use it to physically extend a subnet and pray that it doesn't fail. Question of the day: is it possible to put two Appliteks (or any other transparent bridges) in parallel, for reasons of reliability, without getting into a loop? If not, then you shouldn't expect that putting a bridge in parallel with a gateway should work any better. ----MESSAGE-END----