The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

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 this
gateway. The Air Force folks are trying to gather requirements
to defend their POM submission, which includes Full Scale
Development and a limited production run in FY88.

The Gateway would appear to have considerable utility as a 
trusted local "permissive separator", especially in a heavily
LAN'd/WAN'd facility with different networks. Once the funding
battles are mastered, people who want to actually buy and field
the Multinet Gateway acn talk about contractual vehicles to
achieve that.

All info & assistance appreciated.

Thank you,
-Pat Sullivan
 IAS RDT&E Project Mgr
 Defense Communications Engineering Center
 Reston, VA.
 VON 364-2165
 Com 703-437-x.
 
-------------END OF FORWARDED MESSAGE(S)-------------

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 85 17:04 EDT
From:      dca-pgs @ DDN1.ARPA
To:        srose @ dca-ems.arpa, wnielsen @ dca-ems.arpa, tcp-ip @ sri-nic.arpa
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 this
gateway. The Air Force folks are trying to gather requirements
to defend their POM submission, which includes Full Scale
Development and a limited production run in FY88.

The Gateway would appear to have considerable utility as a 
trusted local "permissive separator", especially in a heavily
LAN'd/WAN'd facility with different networks. Once the funding
battles are mastered, people who want to actually buy and field
the Multinet Gateway acn talk about contractual vehicles to
achieve that.

All info & assistance appreciated.

Thank you,
-Pat Sullivan
 IAS RDT&E Project Mgr
 Defense Communications Engineering Center
 Reston, VA.
 VON 364-2165
 Com 703-437-x.
 
-------------END OF FORWARDED MESSAGE(S)-------------

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Aug-85 15:09:00 EDT
From:      nsi@DDN1.ARPA
To:        fa.tcp-ip
Subject:   Ethernet

Does anyone know of software which is presently available
to interface Ethernet (CSMA/CD) to the DDN using the standard DOD
protocols (i.e.,TCP/IP,TELNET,FTP,SMFTP) ? 

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 85 15:09 EDT
From:      nsi @ DDN1.ARPA
To:        tcp-ip @ sri-nic.arpa
Subject:   Ethernet
Does anyone know of software which is presently available
to interface Ethernet (CSMA/CD) to the DDN using the standard DOD
protocols (i.e.,TCP/IP,TELNET,FTP,SMFTP) ? 

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-Aug-85 18:52:08 EDT
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        fa.tcp-ip
Subject:   interesting loop

We just got our IP network into a loop.  It's clearly my fault, but the
problem is subtle enough that I thought it might be useful for me to
point it out to others.  It is important to understand our network
configuration.  We have two Ethernets, 128.6.3 and 128.6.4.  For
readability, I am going to drop the 128.6 and refer to them as
networks 3 and 4.  They are connected by two gateways.  One of them is a
Pyramid 90x (4.2 Unix).  It is configured to act as a normal IP gateway.
Because not all of our systems know about subnetting, it also does the
"ARP hack".  Suppose host 128.6.4.2 (which I will refer to as
4.2, since I am dropping 128.6) wants to talk to host 3.1. It will send
out an ARP:

  from 4.2, broadcast, who is 3.1?

The gateway will see this ARP request.  It will check its tables,
realize that the sender needs gatewaying to talk to the target, and that
it is prepared to act as that gateway.  So the gateway will respond

  from gateway, to 4.2, 3.1 is <gateway's Ethernet address>

This is a lie, since it is claiming that its own Ethernet address is
3.1's.  But the lie is useful, since it will cause 4.2 to send its
packets to the gateway, which will deliver them.

The second gateway is an Applitek Ethernet bridge.  This is a broadband
cable system onto which you can put Ethernet bridges.  They are not
IP gateways.  Instead, they are "transparent" Ethernet-level gateways.
Each bridge runs in promiscuous mode, looking at every packet on its
Ethernet.  When it sees any packet addressed to someone on a different
Ethernet, it sends the packet over the broadband to the bridge on
the appropriate Ethernet.  It makes no changes to the packet.  This
is totally invisible to the hosts.  The hosts think we just have one
big Ethernet.  Now, consider what happens when 4.2 wants to talk to
3.1.  It will send out an ARP

  from 4.2, broadcast, who is 3.1?

The bridge on network 4 will pass this to the bridge on 3, which will
then broadcast it.  3.1 will see it, and respond

  from 3.1 to 4.2, 3.1 is <its Ethernet address>

The bridge will pass this packet back to network 4, whose bridge will
send it to 4.2.  The connection is now set up, and all of the packets
will follow this same path.

Now for the fun.  Consider what will happen when a host wants to
talk to another host on the same network:

  from 4.2, broadcast, who is 4.3?

First, 4.3 will see this, and respond

  from 4.3 to 4.2, 4.3 is <its Ethernet address>

However the Applitek bridge will pick up the original broadcast and
repeat it on all of the other subnets.  (Since the bridges are
protocol-independent, they know nothing about Internet addresses. They
have no way to know that the ARP will be satisfied locally. Thus they
forward all broadcasts to all subnets.  This is moderately reasonable.)
In particular, it will repeat it on network 3.  Our Pyramid gateway will
see this request.  Since it is an ARP on network 3 looking for a host on
network 4, the Pyramid will offer to gateway:

  from gateway to 4.2, 4.3 is <gateway's Ethernet address on network 3>

The Applitek bridge will pick this on on network 3 and pass it back to
4, where it gets sent back to 4.2.  If 4.2 is a Unix system, it will
believe the last ARP reply that it sees.  So we now have an ARP entry:

   4.3  gateway's address on network 3

The funny thing is, this may work.  Packets destined for 4.3 will be
sent to the gateway's other side.  The Applitek bridge will see an
Ethernet address on the other subnet, and forward it. The gateway will
get the packet, and forward it back to network 4, where it will
presumably be delivered to the correct place. However the gateway itself
is not immune from this problem (at least not with the code I have in it
now).  When the gateway attempts to talk to 4.3, the ARP packet will
again be forwarded to the other subnet, and the gateway itself will
respond.  Thus the gateway will end up with an ARP table entry
containing
  4.3 gateway's own address on network 3
At this point we have a loop.

Obviously the simplest answer is that as long as the Applitek system
is working, we turn off the Pyramid gateway code.  However we would
like that code to be available as a backup should the Applitek system
go down.  It begins to appear that we are going to have to check
specifically for this sort of situation.  However in a complex network
topology, it may not be entirely clear who one should and should not
be willing to gateway for.  It is possible that the real moral is
that "transparent" gateways and IP gateways may have trouble
coexisting.

Let my hasten to point out that both the subnetting implementation
and the "ARP hacking" code on the Pyramid are mine.  They should not
be blamed on either Berkeley or Pyramid.
-------

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 85 18:52:08 EDT
From:      Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        remarks@RED.RUTGERS.EDU, marantz@RED.RUTGERS.EDU
Subject:   interesting loop
We just got our IP network into a loop.  It's clearly my fault, but the
problem is subtle enough that I thought it might be useful for me to
point it out to others.  It is important to understand our network
configuration.  We have two Ethernets, 128.6.3 and 128.6.4.  For
readability, I am going to drop the 128.6 and refer to them as
networks 3 and 4.  They are connected by two gateways.  One of them is a
Pyramid 90x (4.2 Unix).  It is configured to act as a normal IP gateway.
Because not all of our systems know about subnetting, it also does the
"ARP hack".  Suppose host 128.6.4.2 (which I will refer to as
4.2, since I am dropping 128.6) wants to talk to host 3.1. It will send
out an ARP:

  from 4.2, broadcast, who is 3.1?

The gateway will see this ARP request.  It will check its tables,
realize that the sender needs gatewaying to talk to the target, and that
it is prepared to act as that gateway.  So the gateway will respond

  from gateway, to 4.2, 3.1 is <gateway's Ethernet address>

This is a lie, since it is claiming that its own Ethernet address is
3.1's.  But the lie is useful, since it will cause 4.2 to send its
packets to the gateway, which will deliver them.

The second gateway is an Applitek Ethernet bridge.  This is a broadband
cable system onto which you can put Ethernet bridges.  They are not
IP gateways.  Instead, they are "transparent" Ethernet-level gateways.
Each bridge runs in promiscuous mode, looking at every packet on its
Ethernet.  When it sees any packet addressed to someone on a different
Ethernet, it sends the packet over the broadband to the bridge on
the appropriate Ethernet.  It makes no changes to the packet.  This
is totally invisible to the hosts.  The hosts think we just have one
big Ethernet.  Now, consider what happens when 4.2 wants to talk to
3.1.  It will send out an ARP

  from 4.2, broadcast, who is 3.1?

The bridge on network 4 will pass this to the bridge on 3, which will
then broadcast it.  3.1 will see it, and respond

  from 3.1 to 4.2, 3.1 is <its Ethernet address>

The bridge will pass this packet back to network 4, whose bridge will
send it to 4.2.  The connection is now set up, and all of the packets
will follow this same path.

Now for the fun.  Consider what will happen when a host wants to
talk to another host on the same network:

  from 4.2, broadcast, who is 4.3?

First, 4.3 will see this, and respond

  from 4.3 to 4.2, 4.3 is <its Ethernet address>

However the Applitek bridge will pick up the original broadcast and
repeat it on all of the other subnets.  (Since the bridges are
protocol-independent, they know nothing about Internet addresses. They
have no way to know that the ARP will be satisfied locally. Thus they
forward all broadcasts to all subnets.  This is moderately reasonable.)
In particular, it will repeat it on network 3.  Our Pyramid gateway will
see this request.  Since it is an ARP on network 3 looking for a host on
network 4, the Pyramid will offer to gateway:

  from gateway to 4.2, 4.3 is <gateway's Ethernet address on network 3>

The Applitek bridge will pick this on on network 3 and pass it back to
4, where it gets sent back to 4.2.  If 4.2 is a Unix system, it will
believe the last ARP reply that it sees.  So we now have an ARP entry:

   4.3  gateway's address on network 3

The funny thing is, this may work.  Packets destined for 4.3 will be
sent to the gateway's other side.  The Applitek bridge will see an
Ethernet address on the other subnet, and forward it. The gateway will
get the packet, and forward it back to network 4, where it will
presumably be delivered to the correct place. However the gateway itself
is not immune from this problem (at least not with the code I have in it
now).  When the gateway attempts to talk to 4.3, the ARP packet will
again be forwarded to the other subnet, and the gateway itself will
respond.  Thus the gateway will end up with an ARP table entry
containing
  4.3 gateway's own address on network 3
At this point we have a loop.

Obviously the simplest answer is that as long as the Applitek system
is working, we turn off the Pyramid gateway code.  However we would
like that code to be available as a backup should the Applitek system
go down.  It begins to appear that we are going to have to check
specifically for this sort of situation.  However in a complex network
topology, it may not be entirely clear who one should and should not
be willing to gateway for.  It is possible that the real moral is
that "transparent" gateways and IP gateways may have trouble
coexisting.

Let my hasten to point out that both the subnetting implementation
and the "ARP hacking" code on the Pyramid are mine.  They should not
be blamed on either Berkeley or Pyramid.
-------
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 85 09:43:37 PDT (Fri)
From:      imagen!geof@su-shasta.ARPA
To:        Charles Hedrick <shasta!HEDRICK@RED.RUTGERS.EDU>
Cc:        shasta!tcp-ip@SRI-NIC.ARPA
Subject:   Re: interesting loop

Actually, the real moral of the story is that transparent gateways and
transparent gateways have trouble coexisting.  If you had been using
a real IP gateway (no criticism intended) there would have been no
problem.

- Geof
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 1985 1110-PDT (Friday)
From:      Jeff Mogul <mogul@Navajo>
To:        Charles Hedrick <HEDRICK@RUTGERS>
Cc:        remarks@RUTGERS, marantz@RUTGERS, tcp-ip@SRI-NIC.ARPA
Subject:   Re: interesting loop
    Obviously the simplest answer is that as long as the Applitek system
    is working, we turn off the Pyramid gateway code.  However we would
    like that code to be available as a backup should the Applitek system
    go down.  It begins to appear that we are going to have to check
    specifically for this sort of situation.  However in a complex network
    topology, it may not be entirely clear who one should and should not
    be willing to gateway for.  It is possible that the real moral is
    that "transparent" gateways and IP gateways may have trouble
    coexisting.

What is going on here is that the two gateways (transparent and IP)
are based on different models of the world; the transparent gateway
(bridge) assumes that it should act like a piece of wire, i.e. that
the cables connected to it should appear to be electrically connected.
In this model, forwarding the broadcasts (ARP messages) is not only
legal but required.

The IP gateway does not assume this; specifically, the "ARP hack"
assumes that the cables are NOT electrically connected.  In this
model, forwarding of undirected broadcasts is a no-no.

I believe the moral is that one should not mix metaphors.  If you
don't want to use your Pyramid as a full-time gateway, buy a
gateway box from someone.  Scrap the Applitek, or use it to
physically extend a subnet and pray that it doesn't fail.

Question of the day: is it possible to put two Appliteks (or
any other transparent bridges) in parallel, for reasons of
reliability, without getting into a loop?  If not, then you
shouldn't expect that putting a bridge in parallel with a
gateway should work any better.
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30-Aug-85 12:43:37 EDT
From:      geof@su-shasta.ARPA
To:        fa.tcp-ip
Subject:   Re: interesting loop


Actually, the real moral of the story is that transparent gateways and
transparent gateways have trouble coexisting.  If you had been using
a real IP gateway (no criticism intended) there would have been no
problem.

- Geof

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30-Aug-85 13:22:22 EDT
From:      root%bostonu.csnet@csnet-relay.arpa (BostonU SysMgr)
To:        fa.tcp-ip
Subject:   Re:  interesting loop

Re: Packet loops caused by dumb broad/base band gateways

This is one of the major reasons why at Boston University we
chose to put our broad/base band gateways into our 4.2 hosts,
we use Ungermann/Bass Net/1 DR11-W (soon SUN also) NIUs.
The 4.2 hosts then are just typical gateways and are
intelligent about IP and our broadband interfaces are
completely analagous to our baseband (eg. they support ARP.)

For reliability we have more than one 4.2 host on our baseband
with broadband interfaces. Routed (with the bugs removed) takes
care of transitions for us, it all works quite smoothly and
I have not yet detected it to cause any load. Further, those
hosts with broadband interfaces just talk to each other directly
under this scheme, rather than routing over ethernets.

I was always very suspicious about this mindless gateway approach
for this and a few other reasons, like what happens to your broadcast
packets? I am sure there is a reasonable solution to this, but
utilizing the broadband directly seemed the way to go.

If I needed to add PUP or XNS I am pretty sure it would just be a
'typical' job to recognize those packets need to be forwarded in
the drivers. If I needed to gateway DECNET, I would tell them
too bad, I told you to stay away from it (I am anticipating a
response viz a viz the need to support other protocols on the system.)
We in fact can give our DECNET hosts 19.2kb synchronous p-p interfaces
on our broadband cable which is about all they can expect.

	-Barry Shein, Boston University

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Aug 85 13:22:22 edt
From:      BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To:        HEDRICK@rutgers.csnet, tcp-ip@SRI-NIC.ARPA
Cc:        marantz@rutgers.csnet, remarks@rutgers.csnet
Subject:   Re:  interesting loop
Re: Packet loops caused by dumb broad/base band gateways

This is one of the major reasons why at Boston University we
chose to put our broad/base band gateways into our 4.2 hosts,
we use Ungermann/Bass Net/1 DR11-W (soon SUN also) NIUs.
The 4.2 hosts then are just typical gateways and are
intelligent about IP and our broadband interfaces are
completely analagous to our baseband (eg. they support ARP.)

For reliability we have more than one 4.2 host on our baseband
with broadband interfaces. Routed (with the bugs removed) takes
care of transitions for us, it all works quite smoothly and
I have not yet detected it to cause any load. Further, those
hosts with broadband interfaces just talk to each other directly
under this scheme, rather than routing over ethernets.

I was always very suspicious about this mindless gateway approach
for this and a few other reasons, like what happens to your broadcast
packets? I am sure there is a reasonable solution to this, but
utilizing the broadband directly seemed the way to go.

If I needed to add PUP or XNS I am pretty sure it would just be a
'typical' job to recognize those packets need to be forwarded in
the drivers. If I needed to gateway DECNET, I would tell them
too bad, I told you to stay away from it (I am anticipating a
response viz a viz the need to support other protocols on the system.)
We in fact can give our DECNET hosts 19.2kb synchronous p-p interfaces
on our broadband cable which is about all they can expect.

	-Barry Shein, Boston University

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30-Aug-85 14:10:00 EDT
From:      mogul@Navajo (Jeff Mogul)
To:        fa.tcp-ip
Subject:   Re: interesting loop


    Obviously the simplest answer is that as long as the Applitek system
    is working, we turn off the Pyramid gateway code.  However we would
    like that code to be available as a backup should the Applitek system
    go down.  It begins to appear that we are going to have to check
    specifically for this sort of situation.  However in a complex network
    topology, it may not be entirely clear who one should and should not
    be willing to gateway for.  It is possible that the real moral is
    that "transparent" gateways and IP gateways may have trouble
    coexisting.

What is going on here is that the two gateways (transparent and IP)
are based on different models of the world; the transparent gateway
(bridge) assumes that it should act like a piece of wire, i.e. that
the cables connected to it should appear to be electrically connected.
In this model, forwarding the broadcasts (ARP messages) is not only
legal but required.

The IP gateway does not assume this; specifically, the "ARP hack"
assumes that the cables are NOT electrically connected.  In this
model, forwarding of undirected broadcasts is a no-no.

I believe the moral is that one should not mix metaphors.  If you
don't want to use your Pyramid as a full-time gateway, buy a
gateway box from someone.  Scrap the Applitek, or use it to
physically extend a subnet and pray that it doesn't fail.

Question of the day: is it possible to put two Appliteks (or
any other transparent bridges) in parallel, for reasons of
reliability, without getting into a loop?  If not, then you
shouldn't expect that putting a bridge in parallel with a
gateway should work any better.

END OF DOCUMENT