|
|
ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for August 1985 (86 messages, 31011 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/08.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Thu, 1-Aug-85 10:26:19 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Beta release announcement for Sperry 1100 TCP/IP software
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
<louie@trantor.arpa> or
<louie@umd5.arpa>
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
-----------[000001][next][prev][last][first]---------------------------------------------------- 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
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Sun 4 Aug 85 20:13:23-EDT From: Lixia Zhang <Lixia@MIT-XX.ARPA> To: DCP@SCRC-QUABBIN.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Withholding Acks
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
-------
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Sun 4 Aug 85 22:58:55-EDT From: Asheem <CHANDNA@CWR20B> To: TCP-IP:; Subject: TCP/IP - DECNET Conversion.
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 -------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 Aug 85 10:42 EDT From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> To: Lixia Zhang <Lixia@MIT-XX.ARPA>, DCP@SCRC-QUABBIN.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Withholding Acks
Date: Sun 4 Aug 85 20:13:23-EDT
From: Lixia Zhang <Lixia@MIT-XX.ARPA>
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.
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Mon 5 Aug 85 16:59:30-PDT From: Ken Harrenstien <KLH@SRI-NIC.ARPA> To: MILLS@USC-ISID.ARPA, Lixia@MIT-XX.ARPA, DCP@SCRC-QUABBIN.ARPA Cc: tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Subject: Re: Withholding Acks
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. -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Mon, 5-Aug-85 14:10:37 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Withholding Acks
From: Lixia Zhang <Lixia@MIT-XX.ARPA>
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
-------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 1985 16:14:32 EDT From: MILLS@USC-ISID.ARPA To: Lixia@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA Cc: MILLS@USC-ISID.ARPA Subject: Re: Withholding Acks
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 -------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Mon, 5-Aug-85 17:54:00 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Withholding Acks
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Sun 4 Aug 85 20:13:23-EDT
From: Lixia Zhang <Lixia@MIT-XX.ARPA>
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.
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 1985 18:01:29 EDT From: MILLS@USC-ISID.ARPA To: Lixia@MIT-XX.ARPA, DCP@SCRC-QUABBIN.ARPA Cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA Subject: Re: Withholding Acks
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 -------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Mon, 5-Aug-85 18:58:33 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Withholding Acks
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 -------
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Mon, 5-Aug-85 19:53:19 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: TCP/IP - DECNET Conversion.
From: Asheem <CHANDNA@CWR20B> 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 -------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Mon, 5-Aug-85 20:49:45 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Withholding Acks
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 -------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Mon, 5-Aug-85 21:43:30 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Withholding Acks
From: Ken Harrenstien <KLH@SRI-NIC.ARPA> 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. -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 85 08:39:36 PDT (Tuesday) From: Cherry.pasa@Xerox.ARPA To: mknox@ut-ngp.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: X.25 implementation needed
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------>*
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Tue, 6-Aug-85 12:45:51 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: X.25 implementation needed
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------>*
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Wed 7 Aug 85 14:43:29-PDT From: Ken Harrenstien <KLH@SRI-NIC.ARPA> To: tops-20@SU-SCORE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: [CLYNN@BBNA.ARPA: Re: [Ken Harrenstien <KLH@SRI-NIC.ARPA>: It's definite - TOP...]
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: <CLYNN@BBNA.ARPA>
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 <KLH@SRI-NIC.ARPA>: 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 <KLH@SRI-NIC.ARPA>
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 <XFRCNT,LINBLK,PKTPTR,CNT>
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,(<POINT 8,.-.(TPKT)>) ; 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
-------
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Wed, 7-Aug-85 19:04:29 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: [CLYNN@BBNA.ARPA: Re: [Ken Harrenstien <KLH@SRI-NIC.ARPA>: It's definite - TOP...]
From: Ken Harrenstien <KLH@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: <CLYNN@BBNA.ARPA>
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 <KLH@SRI-NIC.ARPA>: 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 <KLH@SRI-NIC.ARPA>
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 <XFRCNT,LINBLK,PKTPTR,CNT>
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,(<POINT 8,.-.(TPKT)>) ; 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
-------
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 09 Aug 85 11:38:30 EDT (Fri) From: mgardner@BBNCC5.ARPA To: Lixia Zhang <zhang%erlang.DEC@DECWRL.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, mgardner@BBNCC5.ARPA Subject: Re: Interactive traffic punishment via MILNET?
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
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Fri, 9-Aug-85 12:50:14 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Interactive traffic punishment via MILNET?
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
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 1985 01:26:28 EDT From: MILLS@USC-ISID.ARPA To: jsq%tzec.UTEXAS@UT-SALLY.ARPA Cc: MILLS@USC-ISID.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: dcn1 time
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 -------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Mon, 12-Aug-85 02:20:33 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: dcn1 time
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 -------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 85 08:22:11 EDT From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: mgardner@BBNCC5.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Interactive traffic punishment via MILNET?
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 <name omitted to protect the guilty, of which there are several>. 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.) -------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 12 Aug 1985 11:26-PDT From: Dan <LYNCH@ISIB> To: HEDRICK@RUTGERS.ARPA Cc: mgardner@BBNCC5.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Interactive traffic punishment via MILNET?
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.
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Mon, 12-Aug-85 09:02:17 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Interactive traffic punishment via MILNET?
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> 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 <name omitted to protect the guilty, of which there are several>. 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.) -------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Mon, 12-Aug-85 15:34:38 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Interactive traffic punishment via MILNET?
From: Dan <LYNCH@ISIB> 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.
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Fri, 16 Aug 85 14:12:51 cdt From: smoot%uo.UTEXAS@ut-sally.ARPA (Smoot Carl-Mitchell) 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.
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri, 16-Aug-85 16:55:14 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: RFC940 subnet code for 4.2 BSD
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.
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Sun, 18 Aug 85 10:17:14 cdt From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) To: TCP-IP@SRI-NIC Cc: jsq@tzec.ARPA Subject: voting on the time
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]
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Sun, 18-Aug-85 13:02:12 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: voting on the time
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]
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 1985 13:30 PST From: Gary Krall <GARY@ACC> To: TCP-IP@SRI-NIC Subject: mail problem
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 ------
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Mon, 19 Aug 85 09:44:46 edt From: Alan Parker <parker@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
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Mon, 19-Aug-85 10:58:55 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: TCP/IP trademark?
From: Alan Parker <parker@nrl-css> 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
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 85 15:05:30 EST (Mon) From: Paul M. Albitz <albitz@Purdue.EDU> To: tcp-ip@sri-nic.arpa Subject: arpanet address for purdue
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
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 1985 18:26:57 PDT From: POSTEL@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: Internet Inc.
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. -------
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Mon, 19-Aug-85 17:10:43 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: arpanet address for purdue
From: Paul M. Albitz <albitz@Purdue.EDU> 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
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Mon, 19-Aug-85 18:21:17 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: mail problem
From: Gary Krall <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 ------
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 1985 19:47-EDT From: CERF@USC-ISI.ARPA To: parker@NRL-CSS.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP/IP trademark?
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
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 19 Aug 1985 19:56-EDT From: CERF@USC-ISI.ARPA To: GARY@ACC.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: mail problem
Gary, I am about to take MCI Mail from 3.6 to 4.2 - what am I about to face??? vint
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Mon, 19-Aug-85 21:03:21 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: TCP/IP trademark?
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
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Mon, 19-Aug-85 21:52:41 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: mail problem
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
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Mon, 19 Aug 85 23:30:25 EDT From: petry@trantor.ARPA (Michael G. Petry) 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
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Mon, 19-Aug-85 23:56:56 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Internet Inc.
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. -------
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Tue, 20-Aug-85 00:44:55 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Ether Broadcast Bedlam
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
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 85 14:03:33 PDT (Tue) From: Richard Johnson <raj@uci-icsa> To: tcp-ip@sri-nic Subject: Voting on time
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)
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA> To: jsq%tzec.UTEXAS@UT-SALLY.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: voting on the time
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.
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Tue, 20 Aug 85 13:28:23 cdt From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) To: DCP@SCRC-QUABBIN.ARPA Cc: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>, TCP-IP@SRI-NIC.ARPA, jsq%tzec.UTEXAS@ut-sally.ARPA Subject: Re: voting on the time
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.
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Tue, 20-Aug-85 13:17:19 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: voting on the time
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA> 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.
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Tue, 20 Aug 85 13:36 EDT From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> To: Michael G. Petry <petry@TRANTOR.ARPA>, tcp-ip@SRI-NIC.ARPA Subject: Ether Broadcast Bedlam
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
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Tue, 20 Aug 85 13:38 EDT From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> To: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>, jsq%tzec.UTEXAS@UT-SALLY.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: voting on the time
Date: Tue, 20 Aug 85 12:19:13 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
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?
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Tue, 20 Aug 85 13:39 EDT From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA> To: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>, jsq%tzec.UTEXAS@UT-SALLY.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: voting on the time
Date: Tue, 20 Aug 85 12:19:13 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
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?
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Tue, 20-Aug-85 15:04:25 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Ether Broadcast Bedlam
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
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
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Tue, 20-Aug-85 15:59:12 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: voting on the time
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Tue, 20 Aug 85 12:19:13 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
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?
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Tue, 20 Aug 85 16:02:32 EDT From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA> To: DCP@SCRC-QUABBIN.ARPA Cc: TCP-IP@SRI-NIC.ARPA, jsq%tzec.UTEXAS@UT-SALLY.ARPA Subject: voting on the time
Date: Tue, 20 Aug 85 13:39 EDT
From: David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>
To: Christopher C. Stacy <CSTACY at MIT-MC.ARPA>,
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 <CSTACY@MIT-MC.ARPA>
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.
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Tue, 20-Aug-85 16:58:35 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: voting on the time
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Tue, 20 Aug 85 12:19:13 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
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?
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Tue, 20-Aug-85 17:47:54 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: voting on the time
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Date: Tue, 20 Aug 85 13:39 EDT
From: David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>
To: Christopher C. Stacy <CSTACY at MIT-MC.ARPA>,
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 <CSTACY@MIT-MC.ARPA>
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.
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Tue, 20-Aug-85 18:40:57 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Voting on time
From: Richard Johnson <raj@uci-icsa> 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)
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Tue, 20-Aug-85 19:34:45 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: voting on the time
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.
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 21 Aug 85 11:05:12 PDT (Wed) From: Richard Johnson <raj@uci-icsa> To: tcp-ip@sri-nic Subject: Re: voting on the time
> 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)
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Wed, 21 Aug 85 13:44:57 cdt From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) To: raj@uci-icsa.arpa Cc: TCP-IP@SRI-NIC Subject: Re: Voting on time
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.
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Wed, 21 Aug 85 16:29:22 mdt From: nbires!cathy@Berkeley (Cathy Curley) 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
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Wed, 21-Aug-85 16:16:50 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: voting on the time
From: Richard Johnson <raj@uci-icsa> > 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)
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Wed, 21 Aug 85 17:20 EST From: Chris Johnson <johnson%northeastern.csnet@csnet-relay.arpa> 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
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Wed, 21-Aug-85 20:25:45 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: ???????
From: Chris Johnson <johnson%northeastern.csnet@csnet-relay.arpa>
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
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Thu, 22-Aug-85 01:37:34 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: Voting on time
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.
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Thu, 22 Aug 85 23:48:19 PDT From: Richard K. Jennings <jennings@AEROSPACE.ARPA> To: tcp-ip@Berkeley Subject: Ether Broadcast Bedlam
please delete me from this newsgroup.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Fri, 23-Aug-85 03:59:54 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Ether Broadcast Bedlam
From: Richard K. Jennings <jennings@AEROSPACE.ARPA> please delete me from this newsgroup.
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 23 August 1985 0958-PDT (Friday) From: stanonik@nprdc.arpa (Ron Stanonik) 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
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 23 Aug 85 10:56:12 PDT (Fri) From: guyton%condor@rand-unix.ARPA To: stanonik@nprdc.arpa (Ron Stanonik) Cc: tcp-ip@sri-nic, guyton%condor@rand-unix.ARPA Subject: Re: ien 116 name server
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
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Fri, 23-Aug-85 14:01:00 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: ien 116 name server
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
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Fri, 23-Aug-85 14:54:40 EDT From: tcp-ip@ucbvax.ARPA To: fa.tcp-ip Subject: Re: ien 116 name server
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
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Mon, 26-Aug-85 13:10:21 EDT From: albitz@Purdue.EDU (Paul M. Albitz) To: fa.tcp-ip Subject: mail getting to purdue
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
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Mon, 26-Aug-85 17:26:00 EDT From: dca-pgs@DDN1.ARPA To: fa.tcp-ip Subject: Gateway Requirements Query
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)-------------
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 26 Aug 85 17:26 EDT From: dca-pgs @ DDN1.ARPA To: tcp-ip @ sri-nic.arpa Subject: Gateway Requirements Query
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)-------------
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Tue, 27-Aug-85 17:04:00 EDT From: dca-pgs@DDN1.ARPA To: fa.tcp-ip Subject: Gateway Requirements Query - Resend
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 thi