|
|
ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for February 1984 (74 messages, 47547 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1984/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 1984 1157 PST From: Eric P. Scott <EPS@JPL-VLSI> To: TCP-IP@SRI-NIC Subject: When a stranger knocks...
We changed our official name and address yesterday; this had some amusing effects on SMTP servers. Most didn't seem to mind, e.g. 220 UCB-VAX.ARPA Sendmail 4.22/4.21 ready at Wed, 1 Feb 84 19:15:25 pst HELO JPL-VLSI.ARPA 250 UCB-VAX.ARPA Hello JPL-VLSI.ARPA, pleased to meet you QUIT 221 UCB-VAX.ARPA closing connection [I discovered that FUZZBALLs match the first three characters of SMTP commands, e.g. HELP gives a 250 reply.] BRL was perfectly calm until I QUIT... 220 brl Server SMTP (Complaints/bugs to: MMDF@BRL-BMD.ARPA) HELO JPL-VLSI.ARPA 250 brl QUIT 221 brl says goodbye to 10.3.0.54 at Wed Feb 1 22:23:40 . ...but a number of TOPS-20 sites complained sooner: 220-SU-SCORE.ARPA SMTP Service 5.3(161) at Wed 1 Feb 84 19:07:23-PST 220 Bugs/Gripes to Bug-MAISER@SU-SCORE.ARPA HELO JPL-VLSI.ARPA 250 SU-SCORE.ARPA - You are a charlatan, [10.3.0.54] QUIT 221 SU-SCORE.ARPA Service closing transmission channel One REAL LOSER was UCI-750A. After a long pause: 521 Mail system claims 10.3.0.54 is an unknown host No CRLF followed the text; the connection closed immediately. Just the facts, ma'am. -=EPS=- ------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Thu 2 Feb 84 14:21:34-PST From: Mark Crispin <MRC@SU-SCORE.ARPA> To: EPS@JPL-VAX.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: When a stranger knocks...
The TOPS-20 SMTP server validates addresses vs. claimed
names, but will still accept the HELO command. Note that Score's
SMTP server responded with a 250. It will note the discrepancy
in the "Received" RFC 822 header line in a command, as in:
Received: from JPL-VLSI.ARPA ([10.3.0.54]) by SU-SCORE with TCP; Thu 2 Feb 84 11:59:48-PST
but otherwise will allow the mail through.
"You are a charlatan" means that the claimed name was known
on a different address; "never heard of you" means the claimed
name is unknown.
The TOPS-20 mailsystem considers bracketed host addresses
(as in [10.3.0.54]) to be completely equivalent to host names and
in fact it can't tell the difference in most places.
-- Mark --
-------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 02 Feb 84 16:04:15 PST (Thu) From: Network Services (agent: Marshall Rose) <netser@uci-750a> To: EPS@Jpl-Vax Cc: TCP-IP@Sri-Nic, Reply Distribution List: ; Subject: Re: When a stranger knocks...
I must take some issue with your description of one of our hosts.
I realize that your report was intentionally humorous (at least
that's how I read it), but I think you touched upon a legitimate
issue, while you were calling us names.
One REAL LOSER was UCI-750A. After a long pause:
521 Mail system claims 10.3.0.54 is an unknown host
No CRLF followed the text; the connection closed immediately.
At the bottom of the message, I have an explanation as to why we
didn't know who you were, but it's a digression, so I'll skip it
for now.
I object though to the term "loser". As far as we know, 10.3.0.54
is ficticious. It's not in any of OUR host tables which was
updated from the NiC's copy 1 week ago. Why should we accept mail
from you?
UCB-VAX is running SendMail which couldn't care less about the mail
it gets. It is not "secure" in the sense that it does not do
authentication of the sender.
BRL is running a later version of MMDF than we are and has what I
would imagine to be a much better server that the UCI counterpart.
My guess is that their server tells the mail system that you are
10.3.0.54 and the mail system uses that and not the name you gave
it. Apparently, the server does not take it as given that your
name really is JPL-VLSI. I applaud the efforts of the MMDF people
to try and make MMDF very "secure". MMDF does lots of
authentication checking. They treat mail very seriously [my
personal opinion, flames to me, not them].
MRC's TOPS-20 server also knows that you aren't who you say you
are, but says it up front, before you do anything else. I don't
know what Mark's implementation does, since I'm not familiar with
it, but I'd guess that it uses 10.3.0.54 instead of JPL-VLSI.
We are running one of the earliest versions of MMDF, which has been
modified quite a bit to use SMTP and act 822-ish. The long pause
is due to the fact that we search many host tables looking for
"10.3.0.54" (which we aren't going to find) and also because that
system is always heavily loaded. As far as the lack of a CRLF
goes, that's a typo. I've fixed it.
You might claim that because our server doesn't accept a connection
when it can't determine the internet name of a host making the
connection, that it doesn't meet the SMTP spec. I disagree. If
your host is not registered in the NiC's HOSTS.TXT file, we refuse
to talk mail with you. You are not an Internet site by "our
definition". Perhaps an Internet guru (listening JBP or PVM?) can
clarify this for me.
We had the same problem when we hooked into the Internet in
December of last year. Although we made it into the 26-Dec-83
HOSTS.TXT, a lot of sites didn't start accepting mail from us until
about mid-January. I'm sure there are still a few hosts about that
refuse to talk to us.
Also, being new at all of this, can someone tell me how often I
should be grabbing HOSTS.TXT from the NiC? I've been doing this
once every other week, but after reading the "ps" below, it seems
that isn't enough.
Thanks,
/mtr
ps:
Why we didn't know who you were:
On January 28th, I grabbed the 1-26-84 version of HOSTS.TXT from
the NiC. The entry for JPL-VAX was:
HOST : 26.3.0.54 : JPL-VAX,JPL-VLSI : VAX-11/780 : VMS :
TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER,UDP :
Just a few minutes ago, I grabbed the most "recent" HOSTS.TXT file
from the NiC. The date at the top STILL says 1-26-84, but the file
has changed. The version of the new file, according to the
hostnames server is 328. Sadly, I didn't check on the version of
the other file dated 1-26-84. Anyway, now the entry for JPL-VLSI is:
HOST : 10.3.0.54 : JPL-VLSI,JPL-VAX : VAX-11/780 : VMS :
TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER,UDP :
The address of a host called "NSWC-WO" has also changed between
these two files with the same date.
That explains why our host tables are supposedly 1 week out of
date, despite the fact the date on the HOSTS.TXT file at the NiC
hasn't changed. Guilty.
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 1984 1626 PST From: Eric P. Scott <EPS@JPL-VLSI> To: TCP-IP@SRI-NIC Cc: netser@UCI-750A Subject: When to update tables
I was under the impression that "the right thing to do" is to send a VERSION request to the hostnames server (as part of a daily procedure, for example) and retrieve the new tables if the reply you get doesn't agree with the last one you remember. Some sites apparently never update their tables unless they get a mass mailing from the NIC advertising the availability of a new set; this is suboptimal behavior. Many mailers have short attention spans; after three days of non-delivery they give up. "Can it wait until Monday?" "No!" I get really ticked when I get dropped from mailing lists because of temporary problems beyond my control, often with no notification whatsoever. When I notice non-deliveries in our mailer log, I try to track them down. Sometimes the 1822 host dead status is useful! IP is wonderful, etc., but if I have unnatural knowledge I use it. If your "secure" SMTP is going to be antisocial, it could at least notify someone human that something bozo is happening. Refusing to accept traffic just strikes me as blatently wrong behavior. I stand by my value judgement. -=EPS=- ------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 02 Feb 84 16:37:49 PST (Thu) From: Network Services (agent: Marshall Rose) <netser@uci-750a> To: EPS@Jpl-Vax Cc: TCP-IP@Sri-Nic, Reply Distribution List: ; Subject: Re: When to update tables
Thanks for the "version" tip. I'll start using it in a "automated" fashion. Actually, our mail server does tell us when something like that happens, once a day. Unfortunately, someone "stole" my status report listing last night and I haven't generated a new one yet. I really don't consider our SMTP either "secure" or anti-social. Cautious is a better term. (-: /mtr
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Thu 2 Feb 84 18:45:00-PST From: Mark Crispin <MRC@SU-SCORE.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: "secure"/"anti-social"/"cautious" SMTP server
Any SMTP server which rejects mail because its (possibly out of date) host tables cause a host name validation failure deserve to be called "losing". I can think of a zillion ways to forge mail to such a server. It is not secure. I seriously doubt that the server intentionally rejects mail in order to inconvenience new hosts. It is not anti-social. A cautious approach would dictate accepting the message, as it could be some critical message (e.g. funding information!); at most it should note the host name validation failure as a comment. The server in question is not cautious. If "losing" seems to be too personal, use "faulty" instead. A faulty SMTP server rejected a valid mail message from a site which validly stated its valid name on its valid address. The cause of the rejection was that the faulty SMTP server uses the faulty and obsolete concept of host tables. Only name server information should be considered current or trustworthy. We live in a networking era of incomplete knowledge of network topology. There are many sites at Stanford talking TCP which aren't in the NIC table. In general, most of those sites won't be sending mail to ARPANET anyway. But it doesn't mean that mail from such a site should necessarily be rejected. I wonder how many SMTP servers will accept a command such as: HELO [10.3.0.11] (TOPS-20s will!). -- Mark -- -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 02 Feb 84 23:21:18 PST (Thu) From: Network Services (agent: Marshall Rose) <netser@uci-750a> To: Mark Crispin <MRC@Su-Score> Cc: TCP-IP@Sri-Nic, Reply Distribution List: ; Subject: Re: "secure"/"anti-social"/"cautious" SMTP server
[Watch closely and I will remove the foot from my mouth.] I agree that faulty is a much better term, and I agree that uci-750a's SMTP server is faulty at best. However, you should think that I was claiming that our SMTP server was "secure". I made no advertisements of that kind at all. I was trying to explain, rather lamely, why it did what it did. /mtr
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Thu 2 Feb 84 23:57:57-PST From: David Roode <ROODE@SRI-NIC> To: wert.Rice@RAND-RELAY.ARPA, netser@UCI-750A Cc: EPS@JPL-VLSI, TCP-IP@SRI-NIC Subject: Re: When a stranger knocks...
On many hosts, users can reply to the ADDRESS even if the HOSTNAME is not known to the system. Thus they can slip around lax system operators who do not update hostables rapidly. Soon, we will have domain addressing with dynamic name resolution and such concerns will not be relevant (knock on wood). -------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 84 21:16:21 EST From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: netser.UCI-750A@RAND-RELAY.ARPA Cc: EPS@JPL-VAX.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: When a stranger knocks...
Probably your message crossed Crispin's in the mail. But in case you didn't notice, Tops-20 does what I think is the optimal thing: 1) it accepts the mail 2) the response to HELO, although 250 (which indicates that it worked), gives a clear indication that something is wrong, so that someone can follow up. 3) in the RECEIVED line, a comment is supplied giving the actual host address when it differs from what we think it should be. Actually I think my old code was better. It said Received from [1.2.3.4] (claiming to be FOO.ARPA) This message causes me to raise two other issues that have been sitting in my mind waiting for an excuse: 1) The protocol specified that user names must be validated. However as far as I can see there is no way to do that. We can verify the host from which it came, and Crispin's Tops-20 handles that fairly well. But anyone at that site can open a connect to us and claim to be anybody he wants. We prevent that on our Ethernet by having the mail sender use a privileged socket. The mail receiver refuses to talk to anyone who is not on a privileged socket. This guarantees that we accept mail only from the real mailer on the other end. We are able to use operating system facilities to make sure that the real mailer always gives a return-path that is the actual person who created the message. Either the RFC's should drop the requirement that names be validated, or some mechanism like this should be made network-wide. I realize that there will be systems where this doesn't make sense (e.g. ITS, where there is little security), or dialup implementations of TCP. But at least we should be able to preserve the same degree of security that was present on the originating system. 2) It might be helpful to have ways of reporting nonfatal problems. E.g. for problems on the sending side, the receiver could use a response meaning "this operation succeeded, but it probably shouldn't have". This would cause the mail system at the other end to make an entry in an exceptions log, send mail to the maintainer, or something else appropriate. Then we could acknowlege a HELO by: 251 You are internet [1.2.3.4]. You claim to be FOO.ARPA. 251-According to our records you are not. The sender should also be able to do this, presumably via a new commands, something like EXCEPTION-REPORT: EXCEPTION-REPORT 250 end with . In delivering a message from FOO.ARPA to BAR.ARPA, FOO.ARPA had to use 50-byte segments, pushed. Something may be wrong with your TCP. . -------
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Feb 84 00:18:26 CST From: Scott Comer <wert@rice> To: Network Services (agent: Marshall Rose) <netser@uci-750a> Cc: EPS@Jpl-Vax, TCP-IP@Sri-Nic Subject: Re: When a stranger knocks...
It seems to me to be better to reject mail from an unknown host than to accept mail from such a host and then have users (on the local host) get mail from this machine and not be able to reply. This puts the responsibility on the machine with the strange name to make sure everyone knows its name, rather than on the unsuspecting users who got mail from a bogus host. Of course, this is just my opinion... wert
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Feb 84 3:35:38 EST From: Mike Muuss <mike@brl-vgr> To: "Network Services (agent: Marshall Rose)" <netser@uci-750a> Cc: tcp-ip@sri-nic Subject: Fetching HOSTS.TXT from NIC
The strategy that we use at BRL is to download the NIC table to ONE machine once a night (at 0400 EST), and redistribute it to all BRLNET machine locally. The procedure is entirely automated, and makes heavy use of the UNIX RSH/RCP facility (Bravo, Berkeley!). This procedure is called /etc/nightly, and in addition to updating host tables, it also propagates changes in the "BRL global name space", and causes fresh MMDF binary databases to be generated. -Mike
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Saturday, 4 Feb 1984 23:05-PST Friday, 3 Feb 1984 07:59-PST From: geof@Shasta To: shasta!TCP-IP@sri-nic.arpa Cc: geof@Shasta Subject: RE:When a stranger knocks...
I don't see why the desire for a ``secure mailer'' prevents a host from accepting mail when the sender's host name is unknown. After all we are Receiving information, not sending it. As long as the receiver of the mail knows that the sender's identity is dubious, I see no reason to avoid forwarding the mail to its destination. I am arguing for an approach like that of Tops-20, where the unknown identity of the sender is added to the mail header. Actually, I think that the (somewhat obscure) message that is presently placed there should be more to the effect of: Security-Caution: THE IDENTITY OF THE HOST THAT SENT THIS MESSAGE (name) DOES NOT CONCUR WITH ITS ADDRESS IN INTERNAL TABLES (address). PLEASE AVOID RELYING ON THE AUTHENTICITY OF THE SENDER WITHOUT SEPARATE VERIFICATION. (alright, it's a little verbose, but who would overlook it?) - Geof Cooper Imagen
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Feb 84 09:16 PST From: Taft.PA@PARC-MAXC.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: Re: When a stranger knocks...
Who says the host named in the HELO command has anything to do with the domain of the message's originator? Validating the host name serves no useful purpose. If you insist on validating anything, it should be the return-path domain name given in the MAIL FROM command. Arguments about security considerations in this context are absurd. The ARPA Internet is an open system. "Validated" host names and "privileged" sockets are meaningless and have no security benefit. The only way to achieve secure communication in an open system is to use end-to-end encryption. Ed Taft
-----------[000013][next][prev][last][first]----------------------------------------------------
Date: 3 Feb 1984 1139 PST
From: Eric P. Scott <EPS@JPL-VLSI>
To: TCP-IP@SRI-NIC
Cc: wert@Rice
Subject: RTFM ("Read The Manual")RFC 821 states: Sometimes a host is not known to the translation function and communication is blocked. To bypass this barrier two numeric forms are also allowed for host "names". One form is a decimal integer prefixed by a pound sign, "#", which indicates the number is the address of the host. Another form is four small decimal integers separated by dots and enclosed by brackets, e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet Address in four 8-bit fields. -=EPS=- ------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Feb 84 11:40 PST From: Maron@LLL-MFE.ARPA To: tcp-ip@nic.arpa Subject: I need pointers to TCP/IP code
(1) I need to implement TCP/IP on PDP-11s using a home grown OS, i.e. not RSX, RT, VMS , UNIX, etc. etc. Does anyone have any PD code either in assembler (PDP-11) or C that I could get as a guide or to use fairly directly? (2) Please respond directly to me, I am not on the list. I'm MARON@LLL-MFE. Thanks in advance, --Neil Maron CC: tcp-ip@nic.arpa, Maron
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 1984 1745 PST From: Eric P. Scott <EPS@JPL-VLSI> To: TCP-IP@SRI-NIC Subject: Query for Murphy's Lawyers
What do you do when something goes wrong with the network where nothing *ever* goes wrong? We're learning... * * * Our IMP connection is via a microwave link that isn't quite as reliable as we'd like (you'd think JPL wouldn't have this problem, especially at terrestrial distances). Our 4.1cBSD- derived software doesn't seem to care that the IMP Ready line has gone away for an extended period of time. How can I convince it that the interface is unavailable? A non-obvious (to me, anyway) and somewhat elegant approach: capitalizing on the symmetry of the 1822 Host Access Protocol, put our ECU in Local Loopback 2 and send a Type 2 (IMP going down in 30 seconds) message using a "raw IMP" socket. Half a minute later things are left in a consistent state from which recovery will automatically occur once the link is restored and a Reset is received. * * * Does anyone have a set of guidelines related to network fault- finding? Comments? -=EPS=- ------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 1984 21:23:31 PST From: MILLS@USC-ISID To: EPS@JPL-VAX, TCP-IP@SRI-NIC Cc: MILLS@USC-ISID Subject: Re: When a stranger knocks...
In response to the message sent 2 Feb 1984 1157 PST from EPS@JPL-VLSI Eric, Oh gawrd, another one caught me! Fuzzies do, indeed, parse only the first three characters of the command name. THey should, however, return what they think is the current mapping between your host address and its apparent name from the NIC tables. Unfortunately, they are a leetle bit behind in snarfing the HOSTS.TXT, at least compared with the TOPSes. Dave -------
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 4 February 1984 12:58 EST From: David C. Plummer <DCP @ MIT-MC> To: MILLS @ USC-ISID Cc: TCP-IP @ SRI-NIC, EPS @ JPL-VLSI Subject: Re: When a stranger knocks...
Date: 3 Feb 1984 21:23:31 PST
From: MILLS@USC-ISID
In response to the message sent 2 Feb 1984 1157 PST from EPS@JPL-VLSI
BTW, folks. What silly mail reading program is putting this
textual "In response to ... " in the body instead of using an
In-reply-to: field in the header? I guess you've never used
m-X Select Conversation by References
on a Lisp Machine... (BABYL may have something similar.)
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 1984 18:37:53 PST From: MILLS@USC-ISID To: DCP@MIT-MC Cc: TCP-IP@SRI-NIC, EPS@JPL-VAX, MILLS@USC-ISID Subject: Re: When a stranger knocks...
In response to your message sent 4 February 1984 12:58 EST David, I just use 'em, not build 'em. On TOPS-20s anyway. If you want to take umbrage, wait until I send something from a fuzzball, which I do build. The little fuzzthings would never do anything like stuff an "In reply" in the text. Dave -------
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Sun 5 Feb 84 00:14:39-PST From: Mark Crispin <MRC@SU-SCORE.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: mail security
Let's end this discussion about mail security. As Ed Taft pointed
out, secure electronic mail in the Internet context is impossible. If
any user fantasizes that he cannot receive forged mail, or that his
outgoing (or incoming) mail cannot be read by anyone other than the
intended recipient, that user should be educated to the hard facts.
All the TOPS-20 mailsystem's "security" features will do is to
assist a reasonably competant user in resisting undetected forged mail
(or unauthorized reading of private mail) in those cases where the
attack is initiated by a relatively unskilled vandal. I wrote much of
the "security" code; it would not resist an attack by me or for that
matter from any other competant TOPS-20 system programmer who took the
time to familiarize himself with the mailsystem's internals.
This isn't due to any Trojan horses introduced by me. This is due
to the fact that Internet doesn't have any better support. Mail security
is only as good as the least secure host. That's pretty unsecure. The
only "secure mail" possible involves end to end encryption between
trusted hosts.
Let's drop this subject, and let's not hear "mail security"
presented or argued as a justification for faulty software. There ain't
no such thing, and the sooner this is generally recognized the sooner we
can move to more productive issues, such as multi-media mail.
-------
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 06-Feb-84 04:29:02-UT From: Mills@dcn6 To: tcp-ip@sri-nic Subject: An EGP one-act play
Folks, The following longish message is offered as an example of the world seen by an EGP gateway fighting the Packet Wars resulting from the various trash floating about the Internet system. Ordinarily, I would send it (as I have sent many similar previous messages) to the wizards to help in the casting of spells. However, I think the TCP-IP community at large may gain an interesting insight into the practical problems of day-to-day operation, as well as an appreciation of the importance of isolating potential routing loops entirely within an autonomous system. Please note that some of the ills related here are due to bugs that can in principle be quickly fixed. Others are due to the sheer size of the core-gateway community, which has far outgrown the present GGP protocol. In the "near" future GGP will be replaced by something more robust, so that the disasterous "counting to infinity" problem should disappear. On the other hand, routinge and congestion problems will probably be with us for some time, so the lessons of the following may be relearned in many implementations. OUR STORY DCN-GATEWAY lives on a lonely EGP island in the midst of the GGP core-gateway sea. The story you are invited to hear involves almost a day in its hard life maintaining order for the Protocol Police. CAST OF CHARACTERS The Hero DCN-GATEWAY 10.3.0.17 (aka DCN1) a good EGP soldier and teller 128.4.0.1 of this tale 128.5.0.1 The Villians BBN-INOC 10.2.0.82 the internet monitor interface and speaker of most of the dialog TEST3 10.3.0.63 the only EGP/GGP navigation aid in the area BBN-VAN-GW 10.3.0.40 a flakeway in search of stability 14.0.0.10 Shifty Characters COLUMBIA-20 10.0.0.89 a rather dense character which talks a lot and learns nothing SRI-NIC 10.0.0.51 a firehose hard to quench RICE 14.0.0.12 a TELENET host, usually recognized as a black hole CISL-SERVICE-MULTICS 10.3.0.31 believed an EGP gateway embryo 192.5.1.1 Incidental Players FORD-WDL1 128.5.32.1 a Unixcorn hiding behind DCN-GATEWAY and a 9.6-Kbps piece of plumbing UCB-VAX 10.2.0.78 a passerby MIT-MC 10.3.0.44 mostly used by people with unscrewed heads THE PLOT DCN-GATEWAY receives its only routing information from TEST3 via EGP. When a net or a GGP core gateway is killed in a skirmish, TEST3 tells DCN-GATEWAY sooner or later, mostly later. The story opens with a backstage whisper saying that somehow DCN-GATEWAY is the best route to TELENET. That seems to unhinge BBN-INOC, which just can't seem to believe the truth, probably because of an unstable routing loop within the core system. THE SCRIPT Stage directions: Ignore the octal process number following the time. The ICMP lines in the script represent ICMP messages sent by DCN-GATEWAY. The two octal numbers are the type and code, while the Internet addresses represent the source and destination of the original datagram. Type 003 is destination- unreachable, 004 is source-quench and 005 is redirect. The Leader error lines represent 1822 host-dead messages and include the octal leader exactly as received. The script, excerpted from the DCN-GATEWAY log, begins with about 30 minutes of misrouted packets from BBN-INOC to the TELENET side of BBN-VAN-GW. DCN-GATEWAY babbles redirects (presumably to 10.3.0.40) on and on, but BBN-INOC isn't listening. 23:12:59 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 178 duplicate(s) ... 23:41:44 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] Now, this is very curious, since TEST3 should be biasing anything sent by DCN-GATEWAY so that dialog within the core system should never, never escape outside. Then BBN-VAN-GW apparently dies and things get worse (note the byte-swapped leader reveals host 3 on IMP 40, which is one of the interfaces of BBN-VAN-GW). 23:41:44 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:41:44 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:02 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:02 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:14 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:14 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:44 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:44 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:46 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:49 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:15 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:15 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:15 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:16 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:35 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:35 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:47 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:47 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:47 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:47 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:44:16 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:44:16 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:44:16 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:44:16 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:44:20 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:44:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:45:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 277 duplicate(s) ... 23:51:53 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:51:53 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 ... 11 duplicate(s) ... 23:52:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:52:24 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:52:24 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:52:25 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:52:25 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:00 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:53:00 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:53:00 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:00 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:28 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:53:28 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:53:28 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:29 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:58 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 495 duplicate(s) ... 23:58:09 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] This spasm lasts for over 13 minutes, presumably being the time to count to infinity in that nasty GGP babble. Finally, TEST3 tells DCN-GATWEWAY net 14 is dead and things die down. BBN-INOC continues to sputter. 23:58:35 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 20 duplicate(s) ... 00:07:59 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] A few minutes later net 14 comes back up and the raunch resumes after only 5 minutes. 00:19:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:24:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:24:46 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:24:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:24:48 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:25:17 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:25:17 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:25:18 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:25:18 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:25:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:25:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:25:48 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:25:49 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:26:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:26:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:26:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:26:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:26:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:26:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:26:50 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:26:50 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:20 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:20 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:21 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:21 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:28 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:29 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:36 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 00:27:36 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:51 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:51 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:51 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:28:21 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:28:21 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:28:22 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:28:22 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:28:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 422 duplicate(s) ... 00:33:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] That spasm, having lasted over 8 minutes, passes the same way as the previous one. 00:33:30 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 21 duplicate(s) ... 00:42:30 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] Enter the clowns. Net 128.8 is off a dumb gateway on MILNET. How did COLUMBIA-20 get here? 00:42:41 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] Next, FORD-WDL1 attempts to FTP something from SRI-NIC, which sloshes over all 26 buffers in DCN-GATEWAY. The latter bitterly complains source-quenchedly, but SRI-NIC will have none of that truck. 00:56:30 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 00:56:30 006 ?TRAP-I-No buffer 2 00:56:42 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 00:56:43 006 ?TRAP-I-No buffer 2 00:56:47 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 00:56:47 006 ?TRAP-I-No buffer 2 TEST3 gets quenched, too (!). Later COLUMBIA-20 chimes again. 00:56:50 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 00:56:50 006 ?TRAP-I-No buffer 2 01:17:04 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] A bit later COLUMBIA-20 and a friend begin hammering on FORD-WDL1 again. Buffers and quenches are dripping all over the place. 01:37:38 006 ?TRAP-I-ICMP 004 000 [10.0.0.31] -> [128.5.32.1] 01:37:38 006 ?TRAP-I-No buffer 2 01:39:11 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:11 006 ?TRAP-I-No buffer 2 01:39:12 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:12 006 ?TRAP-I-No buffer 2 ... 5 duplicate(s) ... 01:39:17 006 ?TRAP-I-No buffer 2 01:39:18 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:18 006 ?TRAP-I-No buffer 2 01:39:19 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:19 006 ?TRAP-I-No buffer 2 01:39:20 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:21 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:21 006 ?TRAP-I-No buffer 2 01:39:22 006 ?TRAP-I-No buffer 2 01:39:23 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:23 006 ?TRAP-I-No buffer 2 01:39:24 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:24 006 ?TRAP-I-No buffer 2 01:39:25 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:25 006 ?TRAP-I-No buffer 2 ... 2 duplicate(s) ... 01:39:27 006 ?TRAP-I-No buffer 2 01:39:28 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:28 006 ?TRAP-I-No buffer 2 01:39:29 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:29 006 ?TRAP-I-Link up 01:39:29 006 ?TRAP-I-No buffer 2 01:39:30 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:31 006 ?TRAP-I-No buffer 2 01:39:32 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:32 006 ?TRAP-I-No buffer 2 01:39:33 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:33 006 ?TRAP-I-No buffer 2 ... 3 duplicate(s) ... 01:39:36 006 ?TRAP-I-No buffer 2 01:39:37 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 01:39:37 006 ?TRAP-I-No buffer 2 01:43:57 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] This mess, previously identified as an instance of the "runaway ACK" bug, has been repeatedly reported to the COLUMBIA-20 wizards. As evident from the above, it completely destabilizes any gateway in its path, not just DCN-GATEWAY, that happens to have smaller than 56-Kbps pipes on the other side. In the case of COLUMBIA-20 the bug has persisted for some weeks, at least, and caused many, many spasms of the kind illustrated above. Nevertheless, COLUMBIA-20 finally gives up. Meanwhile, CISL bobbles of unknown causes, probably irrelevant here. 02:06:37 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 02:07:33 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 02:09:42 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:11:35 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] What? Net 48 was removed from the NIC tables a month ago. Somebody needs a HOSTS.TXT injection. 02:19:41 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [48.3.2.41] 02:41:40 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] Net 14 comes unstuck again, but this time BBN-INOC is not the only one fooled. 02:45:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:48:40 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12] ... 34 duplicate(s) ... 02:48:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12] 02:48:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:48:50 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12] ... 44 duplicate(s) ... 02:49:05 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12] 02:51:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 355 duplicate(s) ... 02:54:37 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:54:38 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 02:54:38 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 2 duplicate(s) ... 02:54:38 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:54:48 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 21 duplicate(s) ... 03:03:51 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:09:14 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 03:10:10 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 03:11:51 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 03:20:23 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] Off we go again with net 14: 03:22:27 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:25:00 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:27:22 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] ... 95 duplicate(s) ... 03:27:42 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] The next one is legitimate. Bleeding continues after that: 03:27:43 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.3] 03:27:43 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] ... 2 duplicate(s) ... 03:27:43 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] 03:28:02 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 12 duplicate(s) ... 03:28:04 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:28:05 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] ... 2 duplicate(s) ... 03:28:05 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 03:28:05 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:28:06 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] ... 76 duplicate(s) ... 03:28:29 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 03:28:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 24 duplicate(s) ... 03:28:36 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:28:43 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] ... 14 duplicate(s) ... 03:28:45 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 03:29:33 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 149 duplicate(s) ... 03:31:39 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:32:36 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 4 duplicate(s) ... 03:35:46 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:36:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:40:04 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:40:37 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [14.0.0.12] ... 79 duplicate(s) ... 03:41:02 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [14.0.0.12] 03:41:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 03:42:41 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] ... 99 duplicate(s) ... 03:43:01 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] 03:43:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 156 duplicate(s) ... 03:49:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:49:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:49:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:49:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:50:21 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:51:27 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:51:44 006 ?TRAP-I-ICMP 003 000 [10.2.0.78] -> [14.0.0.12] 03:52:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 9 duplicate(s) ... 03:58:43 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 04:08:45 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] ... 47 duplicate(s) ... 04:09:34 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] 04:09:48 006 ?TRAP-I-ICMP 003 000 [10.2.0.78] -> [14.0.0.12] 04:12:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 04:12:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] 04:13:10 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 04:16:05 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] 04:41:05 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] CISL wobbles and bobbles. COLUMBIA-20 continues to whack on net 128.8 the wrong way every half hour (probably mail): 04:49:41 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 04:50:38 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 04:56:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 04:57:17 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 05:10:13 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 05:39:38 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 05:52:53 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 05:53:51 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 06:09:29 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 06:42:58 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 06:57:08 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 06:58:05 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 07:12:56 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 07:42:58 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 08:00:12 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 08:01:10 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 08:12:55 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] Somebody out there is fooling with the fuzzies. DCN2 and DCN3 are asleep. After all, it is 3:30 in the morning. The carnage continues sporadically and indefinately. 08:33:24 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.2] 08:33:32 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.3] 08:41:53 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.2] 08:42:57 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 09:03:09 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 09:04:06 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 09:12:56 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 09:42:54 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 10:05:49 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 10:06:47 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 Just for fun, DCN-GATEWAY's line to the ARPANET IMP flaps. 10:12:16 006 ?TRAP-I-Leader error 000017 000400 000000 000000 001000 10:13:01 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 10:42:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 11:06:08 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 11:07:04 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 11:12:51 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 11:42:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 12:08:39 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 12:09:36 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 12:12:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 12:42:46 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 13:11:14 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 13:12:10 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 13:12:44 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] ... 2 duplicate(s) ... 14:12:45 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 14:13:50 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 14:14:45 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 14:42:45 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 15:12:43 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] Finally, TEST3 dies as the curtain falls for the final time. 15:13:16 006 ?TRAP-I-Leader error 000017 003400 001400 037400 000233 ... 18 duplicate(s) ... 15:22:33 006 ?TRAP-I-Leader error 000017 003400 001400 037400 000233 15:23:04 006 ?TRAP-I-Leader error 000017 003400 001400 037400 000633 *** FIN *** This play will never make it to Broadway. However, even the bombs have morals: 1. How did any ARPANET host ever get the idea anything except 128.4 and 128.5 were reachable via DCN-GATEWAY? DCN-GATEWAY is known under certain conditions to fib about routing, but these conditions did not hold here. In any case, TEST3 should not believe any path outside the core system is shorter than any path inside. 2. Assuming the rash of misrouted packets from BBN-INOC was due to unstable routing information which existed while the system counted to infinity, note the terribly long time it takes to again reach stability - from a few minutes to twenty minutes or more in previous scenarios. 3. Much of the carnage illustrated in the play was apparently due to the BBN-VAN-GW gateway bobbing up and down. If we get many more gateways doing that kind of thing, it could happen that the entire gateway system could self-destruct and assume a pathological state where infinity would never be reached. 4. How can rogue hosta like COLUMBIA-20, which are second only to pingers as network disrupters, be politely but firmly repulsed until repaired? The runaway-ACK problem is probably the worst kind of thing that any host anywhere can do. Dave -------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 7-Feb-84 07:53 PST From: Bill Barns <WWB.TYM@OFFICE-2> To: tcp-ip@sri-nic Subject: Martian Attack on OFFICE-8
The SMTP server logs for host OFFICE-8 [26.0.0.93] show attempted connections from the same Martians referred to in the message of 07-Feb-84 05:22:33-UT from <mills@dcn6>, namely [97.128.13.75]. The connections failed to open up properly, as you might imagine. These connections began occurring on 30 Jan 84 13:15:53 PST and ended after 2 Feb 84 23:05:44 PST, ranging from about 14 minutes 48 seconds apart to 15 minutes 20 seconds apart, with about three 15-minute cycles skipped over entirely. The meaning of this is unknown to me. I find it interesting that the Martians are contacting us on the SMTP port. They must be on Jon Postel's RFC mailing list. I presume that every time OFFICE-8 tried to do its part of the TCP opening sequence, events similar to those cited for CMU-GATEWAY and DCN-GATEWAY probably occurred. I don't understand (and don't currently wish to understand) how all these things work at the protocol level, so I cannot interpret the meaning of it all. It does seem that it would be interesting to find out where the "Martian" datagrams are really coming from. It also seems that there is some value in distributing widely such implementation esoterica as the Mills messages. In this case it reassures me that my SMTP is not hallucinating and there really are such datagrams out there in the network. -b
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Tue 7 Feb 84 12:26:35-PST From: Mark Crispin <MRC@SU-SCORE.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: ICMP source quench
TOPS-20 TCP/IP, as distributed by DEC, does not implement Source Quench. I thought this was well known. Any time you have a TOPS-20 doing battle with a network that wants Source Quench you are going to lose. If ISI has written code to support Source Quench this would be the first that I have heard of it. Certainly ISI has taken no trouble to publicize the fact. If some kind ISI person would provide me with their code, I would be happy to do the work of translating it to DEC TOPS-20 and publicizing it further. TOPS-20's have a pre-set gateway table. It "pings" all pre-set "prime" and "dumb" gateways periodically, as this is the only way it can tell if a gateway is safe to use (let's hear it for this and other older and dumber implementations of TCP!). It assumes that all "always-up" gateways are "always up" and that silence from that gateway doesn't imply it is down. Now that I've described the stage, let's enter two of the stage designers who Dave has overlooked. One is the NIC, the other are the nice people who bring us gateways. In theory, it suffices for a host to only have two Prime gateways wired in. This has been demonstrated to NOT be the case. Repeatedly, TOPS-20s have discovered that there are gateways in the NIC INTERNET.GATEWAYS table which are NOT known to Prime gateways. So we must argue that there is a definite communication problem between the NIC and the gateway maintainers as to what are gateways on Internet. Next, the NIC evidentally refuses to provide an INTERNET.GATEWAYS table which is useful; that is, a table which contains only the gateways which a site needs to have pre-wired in. Nominally the table would only contain a few Prime gateways (implying a set of tables, with each site assigned to take a particular one) and those gateways not known to Prime gateways. The latter set of gateways should normally be empty, but let's say there is a problem in the gateways. I would like to hear why the NIC won't do this. All too many sites just take the full NIC INTERNET.GATEWAYS table and install it. They don't know any better, and some of them can't be taught any better. -------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 1984 1258 PST From: Eric P. Scott <EPS@JPL-VLSI> To: TCP-IP@SRI-NIC Cc: WWB.TYM@OFFICE-2 Subject: Re: Martian Attack on OFFICE-8
I suspect the Martians have INTERLANded somewhere in the Berkeley hills... -=EPS=- ------
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 07-Feb-84 05:22:33-UT From: mills@dcn6 To: tcp-ip@sri-nic Subject: A short story
Folks, After that bomb I dropped last night, I am hesitant to inflict more pain. With the kind help of Mike Brescia and Eric Rosen we may have found one reason for the hemorrhage of BBN-INOC redirects noted. To tell you true, DCN-GATEWAY may have contributed something to the mayhem itself; however, that is now fixed and swept quietly under the rug. The other problems remain. I have pondered whether sequels to my one-act play serve a useful purpose distributed to the entire tcp-ip list and concluded that the lessons learned may be useful to the implementors in general. Please understand that I am not trying to lob grenades (a few hit me, in fact) or make unneccesarily disparaging remarks. I am trying to good-naturedly flush some of the Bad Packets washing ashore on my island and in the process understand some of the nonsense that can happen in a community such as ours. Today, a short story. The players include a wanderer MIT-TAC (10.2.0.77) who shuffles on and then off the stage causing no lasting impression. The heavies include CMU-GATEWAY (10.2.0.14), who tries to call a friend on Mars (97.128.13.75) every half hour, but DCN-GATEWAY has no wires to that space. COLUMBIA-20 (10.0.0.89), RUTGERS (10.2.0.58) and AIDS-UNIX (10.2.0.56) appear to have DCN-GATEWAY wired in as the way to UMDNET (128.8), but that net has hidden behind a VAX on MILNET since early January, a fact well known to the core gateways. Here is a specimen from the DCN-GATEWAY log (Typ 003 is destination-unreachable, Typ 005 is redirect). Time (UT) 6-7 Feb Typ Cod From To ------------------------------------------------------------ 19:03:26 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] 19:13:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4] ... 3 duplicate(s) ... 19:13:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4] 19:15:30 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4] ... 2 duplicate(s) ... 19:15:39 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4] 19:15:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 19:24:14 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 19:24:36 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 19:39:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 19:55:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 19:55:15 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 19:55:42 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 20:12:19 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 20:20:03 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 20:25:31 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 20:37:44 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 20:40:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65] ... 7 duplicate(s) ... 20:40:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65] 20:53:16 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 20:55:06 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 20:55:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 21:06:31 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 21:24:43 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 21:25:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 21:36:55 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 21:55:16 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 21:55:35 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 22:09:58 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 22:20:30 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 22:25:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 22:25:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 22:38:31 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 22:55:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 22:55:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 23:05:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 23:10:27 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 23:26:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 23:35:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] 23:40:24 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] ... 5 duplicate(s) ... 01:28:17 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 01:46:25 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4] ... 3 duplicate(s) ... 01:49:21 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4] 02:01:49 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 02:02:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 02:20:34 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] ... 6 duplicate(s) ... 02:22:21 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 02:32:45 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] The Protocol Police would probably class these as misdemeanors. Now we add SU-SCORE (10.3.0.11) to COLUMBIA-20 (10.0.0.89) on the list of Firehose Felons. Following is a record of the ICMP source-quench messages sent to SU-SCORE during a recent instance (host 128.5.32.1 is at our back door connected via 9.6-Kbps line). Time (UT) 6 Feb Typ Cod From To ------------------------------------------------------------ 20:02:43 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 21 duplicate(s) ... 20:03:15 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:03:16 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:03:19 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 9 duplicate(s) ... 20:03:30 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:03:31 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:03:32 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 17 duplicate(s) ... 20:03:54 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:03:56 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:03:57 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 8 duplicate(s) ... 20:04:09 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:04:11 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:04:12 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 19 duplicate(s) ... 20:04:36 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:04:37 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:04:38 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 12 duplicate(s) ... 20:04:53 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:04:56 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:04:58 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 20 duplicate(s) ... 20:05:25 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:05:26 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:05:27 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 9 duplicate(s) ... 20:05:37 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] Note how the TEST3 (10.3.0.63) EGP gateway got trapped in that wash. I was watching the "ready-for-next-bit" light on our ECU during this spasm, from which it was apparent that the IMP was blocked for darn near three minutes. DCN-GATEWAY sends a source-quench when the number of free buffers falls below a threshold (currently two), hopefully before packets have to be dropped. Only a few hosts (fuzzballs among them) actually do something with source-quench. The fuzzballs keep careful track of the number of packets "outstanding" on a TCP connection and enforce an upper limit (currently 8) which is throttled back when a source-quench is received. We have learned that, without these controls we cannot build a stable network of multi-diameter plumbing. The firehose bug illustrated above with SU-SCORE, previously found with COLUMBIA-20 and suspected with several other TOPS-20s (but not those at ISI), could be due to naive retransmission controls or the "runaway-ACK" bug noted previously. From prior experience the culprit is probably the latter, which is known to quickly and completely distroy any gateway in its path. Dave -------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 1984 13:49-PST From: Joel Goldberger <JGoldberger@USC-ISIB> To: MRC@SU-SCORE Cc: TCP-IP@SRI-NIC Subject: Re: ICMP source quench
ISI has no code to obey Source Quench ICMP msgs. Like most other TCP implementations (as reported at the most recent Internet Research Group Meeting) we simply count their occurance. What ISI does have is a hardened IP/TCP as compared to that offered by DEC, or the older versions of the original BBN code. This is the result of folks like Dave Mills beating up on us to get things right, and Charlie Lynn (of BBN) and Dale Chase (of ISI) attacking specific problems as they have arisen (like the runaway ACKs). We have very extensive monitoring and tracing facilities installed in our system that has been of great help in isolating and correcting many of the problems Dave has uncovered. All of the corrective measures and bugfixes have been returned to BBN, and Charlie Lynn is currently working with DEC to get them all back into the DEC distributed version. As to the gateway questions; this is an issue that I believe was beaten to death recently enough that it should be dropped. BBN is busily at work on improving the general gateway situation through the use of EGP and changes in the core (prime) gateways. There was an announcement at the INRG meeting that dumb gateways would have to implement EGP within the next six months. This will insure that all legitimate gateways can be discovered, which is not the case now. BBN also recognizes the problems of GGP, which is the mechanism that the PRIME gateways use to maintain all their routing information. It simply doesn't work well as the number of gateways increases. As a point of information it was reported at this meeting that GGP amongst the 22 Arpanet and 8 Milnet gateways was responsible for 225K packets/hour. - Joel Goldberger -
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 1984 15:51:52 PST From: MILLS@USC-ISID To: MRC@SU-SCORE, TCP-IP@SRI-NIC Cc: MILLS@USC-ISID Subject: Re: ICMP source quench
In response to the message sent Tue 7 Feb 84 12:26:35-PST from MRC@SU-SCORE.ARPA Mark, I won't comment on the NIC issue. As for the TOPS-20s, I have been beating especially on ISID for as long as there was a TCP (over five years) using my haywire kit of leaky plumbing and know it well. So far as I know it and all other TOPS-20s and VAXen (exception: FORD-WDL1, which was locally massaged) disregard source-quench. It has generally been the case that gateways with a couple of dozen packet buffers can manage pretty well, even with mismatched pipes an order of magnitude apart. This is normally the case with DCN-GATEWAY, which hides perhaps two dozen active hosts behind it, some connected by pipes as low as 1200 bps. However, an especially agile typist can sometimes nudge a TOPS-20 to fill up all the buffers for echoes on the way back to one of these hosts, for example. With FTP and mail things generally go pretty well. The problems I reported are believed to be due to bugs in the host implementations. The "runaway-ACK" problem in particular just breaks everything in sight. Ill-advised TCP retransmission timeouts also break things, but not nearly so badly. I have observed several times today, for example, that hosts trying to send mail to DCN6 (connected via 4.8-Kbps pipe) appear to initialize their trx timeout as low as one second, which is clearly way too low for any path not confined to the ARPANET. It is not clear whether some "correct" implementation of source quench would help avoid the pain of these problems. Bugs of opposite sign seldom cancel. However, a rational response to these messages would certainly improve the behavior of the system, not to mention the host itself. We have argued these points within the ICCB incessantly and have not yet come up with a clearly optimal and architectable recommendation. The experiments with the fuzzballs, both as gateways and hosts, have shown that at least some mechanisms are not difficult to implement and work very well. Unfortunately, the inertia against change, especially in the case of vendor-maintained software, is terrific. Dave -------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Feb 84 17:18:33 cst From: jsq@ut-sally.ARPA (John Quarterman) To: Mike.Accetta@cmu-cs-ius.ARPA Cc: <WWB.TYM@office-2.ARPA>, Barns@ut-sally.ARPA, Bill@ut-sally.ARPA, jsq@ut-sally.ARPA, mills@dcn6.ARPA, tcp-ip@sri-nic.ARPA Subject: Re: A short story and Martian Attack on OFFICE-8
I'd already notified the appropriate people at ut-ngp (UT Computation Center) before your letter. [97.128.13.75] is ut-ngp's local ethernet address (about time to get a real network number, I'd say), but [97.128.13.72] doesn't seem to correspond to anything (at least on this planet...).
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Feb 84 17:35:40 CST From: Bill Lee <lee@ut-ngp.ARPA> To: Mike.Accetta@cmu-cs-ius.ARPA, WWB.TYM@office-2.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: A short story and Martian Attack on OFFICE-8
Ok, we are still alive and looking for the Martians. They seem to be us. In any case, this problem should go away very shortly. We seem to be letting some Ethernet traffic out on the ARPANET in an attempt to find a gateway that knows how to route things. This is especially unfortunate since these packets are coming from an unknown host on an unknown network (at least to the rest of the ARPANET). We will try very hard to prevent this from happening again.
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Tuesday, 7 February 1984 16:42:39 EST From: Mike.Accetta@cmu-cs-ius To: mills@dcn6, Bill Barns <WWB.TYM@office-2> Cc: tcp-ip@sri-nic Subject: Re: A short story and Martian Attack on OFFICE-8
After some investigation, the Martian attack seems to be originating from host 0 on IMP 62 (UT-NGP). At the moment, CMU-GATEWAY is receiving frequent packets from this IMP port with an IP source address of 97.128.13.72 (somewhere on Mars) and an IP destination address of 128.2.254.132 (CMU-CS-G). CMU-CS-G responds to the connection attempts and routes its replies back to CMU-GATEWAY. CMU-GATEWAY (itself having no direct communication with Mars) then asks a few of its gateway neighbors (including DCN-GATEWAY) if they know they way, yielding the previously described results. Of course, the question of the moment is now: have the Martians left anyone alive in Texas to fight back? - Mike
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 08-Feb-84 02:21:26-UT From: mills@dcn6 To: tcp-ip@nic Subject: Martian chronicles
Folks, The Martians have just landed at the dcn6 spaceport (25, or smtp, that is). Kamikazegrams are falling every fifteen minutes from 97.128.13.75 spewing unreachable shrapnel all about. The Protocol Police have been roused and horsed, but their numbers are sadly divided while fighting Smany battles under alien Suns. Will the last datagram, source-quenched from our zoo, please turn off the lights? Sadly, I bury our frazzled fuzzballs and resolve to go forth and beat those aliens caught in their Ethernets around their ears with a Valid Network Number. Long live the Czar! Dave -------
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 1984 1420 PST From: Eric P. Scott <EPS@JPL-VLSI> To: TCP-IP@SRI-NIC Subject: I see no Martians here
You don't see our "unadvertised" (and potentially conflicting) network addresses courtesy of the Class A logical host chameleon. UT-NGP, is that a viable solution for you? -=EPS=- ------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Feb 84 15:26:49 CST From: Paul Milazzo <milazzo@rice> To: Mike.Accetta@cmu-cs-ius Cc: mills@dcn6, Bill Barns <WWB.TYM@office-2>, tcp-ip@sri-nic Subject: Re: A short story and Martian Attack on OFFICE-8
A quick glance out the window reveals the Houston skyline still safely in place. Still, Rice periodically repulses a similar attack from the Martians, and I believe I understand the cause. Net 97 is what certain 4.2bsd sites which do not employ ARP use to address Interlan Ethernet boards. The Ethernet interface replaces the "97" with the high 3 bytes of an Interlan Ethernet address (02-07-01), and the remaining 3 class A address bytes become the lower 3 bytes. Thus, [97.128.13.72] corresponds to an Ethernet address of 02-07-01-80-0D-48. This is either the Ethernet board in UT-NGP or a host on UT's local network for which UT-NGP is gatewaying packets. Paul G. Milazzo <milazzo@rice> Dept. of Mathematical Sciences Rice University, Houston, TX
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 1984 at 0827-PST From: bobbi@sri-tsc To: TCP-IP@Sri-Nic Cc: bobbi@sri-tsc, dan@sri-tsc Subject: gateways
I've been tasked with determining the availability of a "compact, single-purpose processor" that could be a gateway between an Ethernet LAN and a packet-switching network. The gateway should support the Ethernet, TCP/IP, and Address Resolution protocols on one side and IP and 1822 protocols on the other. I would appreciate any suggestions of vendors and/or contacts who could supply me with product information on gateway hardware and software. Thank you for your help. -Bobbi bobbi@sri-tsc
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 1984 10:57:50 PST From: MILLS@USC-ISID To: bobbi@SRI-TSC, TCP-IP@SRI-NIC Cc: dan@SRI-TSC, MILLS@USC-ISID Subject: Re: gateways
In response to the message sent 9 Feb 1984 at 0827-PST from bobbi@sri-tsc Bobbi, We use LSI-11 "fuzzballs" for general packet-switching jobs in our shop. They support IP, 1822, HDH, GGP, EGP and 17 different hardware devices, including Interlan and 3COM Ethernets, as well as several kinds of SRI and ACC ARPANET gizmos. We happen to use then with various kinds of disks, since we tend to load miscellaneous application- level stuff into them. Others, including Paal Spilling at NTARE, are using them in the diskless configuration for the same application as you describe. If you need further informationk please see the file DCNET.DOC in the MILLS directory at ISID. You should contact me directly for further correspondence, rather than copy everybody in this group. Dave -------
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Feb 84 10:45:10 cst From: jsq@ut-sally.ARPA (John Quarterman) To: tcp-ip@sri-nic.ARPA Cc: clyde@ut-ngp.ARPA, jsq@ut-sally.ARPA, lee@ut-ngp.ARPA, smoot@ut-sally.ARPA Subject: Martians Beaten Back / Networks Sigh in Common Relief
Checking the backlog of TCP-IP list messages, I see nobody else has announced the problem has been fixed, and there seems to still be interest, so here's an announcement: From jsq Thu Feb 9 10:29:42 1984 Date: Thu, 9 Feb 84 10:28:53 cst From: jsq (John Quarterman) Posted-Date: Thu, 9 Feb 84 10:28:53 cst Received-Date: Thu, 9 Feb 84 10:28:53 cst Message-Id: <8402091628.AA12662@ut-sally.ARPA> Received: by ut-sally.ARPA (4.22/4.22) id AA12662; Thu, 9 Feb 84 10:28:53 cst To: brescia@BBN-UNIX Subject: Re: Have you been getting these mail exchanges? Cc: clyde@ut-ngp, jsq, smoot Yes. I threw in my two bits on the TCP-IP list a couple of times. It seems the folks at ut-ngp configured their Interlan board before their ACC IMP in their 4.2BSD kernel configuration file. The effects of this are actually documented in "Installing and Operating 4.2BSD," but it's easy to overlook that paragraph.... Anyway, the wormhole the Martians came through has evidently been closed.
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Feb 84 12:51:25 EST From: Jonathan Dreyer <jdreyer@BBN-UNIX> To: bobbi@sri-tsc Cc: TCP-IP@Sri-Nic, dan@sri-tsc Subject: Re: gateways
The BBN gateways currently support both Ethernet with ARP and 1822, and we have a few operational gateways with both an Ether leg and an 1822 leg. The gateway runs on LSI-11s with Interlan Ethernet boards and ACC 1822 boards. These are IP gateways; any encapsulated TCP information is passed transparently.
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 10 February 1984 10:43 est From: Ata.SysMaint at RADC-MULTICS To: Mark Crispin <MRC at SU-SCORE> Cc: TCP-IP at SRI-NIC, Ata.SysMaint at RADC-MULTICS Subject: Re: FTP implementation questions
Date: Fri 27 Jan 84 20:44:00-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: FTP implementation questions
I have the following questions for the Internet community regarding
FTP. Instead of hearing a chorus of "no"s I would rather just hear from
those who can answer "yes" to any or all of the following questions:
Answers are for the Multics FTP server.
. Does your FTP implementation implement TYPE L with bytesizes OTHER than
8, 32, or 36? If so, is it useful or necessary to transfer with such a
bytesize?
Yes, we support a logical bytesize of 9 only with the type L. This is
to support the native bytesize of 9. Processing is like type I. Where
one would use TYPE L 9 instead of type I (to the Multics FTP server) is
hypothetically possible, but doubtful in reality.
. Would you consider as deficient an FTP implementation which did not
support a TYPE L bytesize other than 8, 32, or 36? Would a useful data
transfer be prevented by this deficiency? Give examples.
I would think that most machines would support a logical bytesize based
on their hardware's native bytesize regardless of whether it is 8,32, or
36.
. The current FTP standard does not define the 0xx FTP reply codes the way
the previous one did. Do you feel that an FTP server should be prevented
from issuing any unsolicited or "irrelevant" replies, or that it is
alright to continue to use a 0xx FTP reply code? What will your FTP user
software do when it encounters a 0xx reply code (I feel that the "right
thing" is to ignore it, optionally printing it on the user's terminal).
In my opinion, FTP reply codes of the 0xx flavor are illegal and should
never be sent. All system messages (unsolicited) should be sent without
reply codes as per RFC 765 page 33. However on some systems (Multics is
one culprit, I admit) these spontaneous messages are buried whithin the
operating system code with the old 0xx reply format and are hard to
dispose of. Therfore, it is not unreasonable for a user FTP to print the
message on the user terminal, otherwise ignoring it.
. Consider an FTP implementation where the REIN command is not implemented
and you cannot change your USER once you have logged in. Suppose this
implementation allows an unlogged-in RETR by doing an implicit login of
ANONYMOUS (the special account which allows retrieval of public-access
files). Should the FTP implementation announce the auto-login? If 0xx
codes are allowed, 030 is the obvious code. If 0xx is not allowed, what
would you consider valid for it to use to announce the auto-login
(remember, this will prevent a login as something else).
If the auto-login anouncemnet is unsolicited, then no reply code should
precede it.
. Does your FTP user process change the port after each data transfer in
Stream mode?
Yes, otherwise you may be prevented from doing further file transfers
for a while. This is caused by some data connections taking over a
minute to fully close.
. Does your FTP user process implement a mode other than Stream mode? If
so, which?
Yes, we implement block mode also. The latest version should work
properly.
-------
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Sat 11 Feb 84 12:31:28-PST From: Mark Crispin <MRC@SU-SCORE.ARPA> To: Mills@DCN6.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Another nastygram report
As of sometime in the evening of 8 February, SU-SCORE has *all* the BBN/ISI fixes for "runaway ACK" as passed to me. Any instances of runaway ACK after that time (let's say starting from 9 February) would be a different bug. I think we would all appreciate hearing if the fixes at SU-SCORE so far have fixed the problem, because if they haven't, further investigation by all parties is required. -------
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 84 19:59:25 EST From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: Mills@DCN6.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Another nastygram report
I just looked at our INTERNET.GATEWAYS. It does not list 128 8 or 128 4. This suggests that some other gateway is telling us to use DCN-GATEWAY. Unfortunately we don't log ICMP level transactions, so I am unable to tell what is going on. However if Tops-20 does what it is supposed to do, there aren't a lot of candidates. The only gateways we list as PRIME are DCEC-MILNET-GW ARPA-MILNET-GW BBN-CRONUS-GW These are our assigned primary and alternate Milnet gateway, and a randomly chosen BBN-operated gateway. -------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 11-Feb-84 15:35:23-UT From: Mills@dcn6 To: TCP-IP@nic Subject: Another nastygram report
Folks, The Nastygram Novellas continue. Today's hit list includes: 10.0.0.15 ROCHESTER 10.0.0.51 SRI-NIC 10.0.0.89 COLUMBIA-20 10.1.0.31 CCA-VMS 10.1.0.72 BBN-UNIX 10.2.0.14 CMU-GATEWAY 10.2.0.52 USC-ISIF 10.2.0.56 AIDS-UNIX 10.2.0.58 RUTGERS 10.2.0.77 MIT-MC 10.2.0.82 BBN-INOC 10.3.0.11 SU-SCORE 10.3.0.44 MIT-MC 10.3.0.63 BBN-TEST3 10.4.0.2 SRI-AI 10.5.0.2 SRI-IU 128.32.0.11 UCBKIM 14.0.0.12 RICE 18.26.0.37 MIT smallfry The following data were collected in the DCN-GATEWAY log over the two-day period from about 20:00:00 Feb 8 to 20:0:0 Feb 10. This time I sorted the log by host, so that I could call out the problems more easily. Note that this scrambles the time relationships, so that you can't easily tell the times of the events during the ... duplicate(s) ... periods. Remember, ICMP 003 is destination-unreachable, ICMP 004 is source-quench and ICMP 005 is redirect. The addresses refer to those in the original datagram, not the ICMP itself, which is sent to the first address. During this period the BBN test EGP gateway appeared brain-damaged, so I reactivated our GGP and peered with MILARP. Thus, one would expect spasms as the GGP system counted to infinity when some net or gateway died. During such spasms one would also expect redirects to flail about, probably accounting for some of the mischief recorded below. The annotated script follows. 10.0.0.15 ROCHESTER This guy may have old gateway tables. Net 128.8 (UMDNET) is reachable now only via a dumb gateway on MILNET, but used to be reached via DCN-GATEWAY. 00:41:13 006 ?TRAP-I-ICMP 005 000 [10.0.0.15] -> [128.8.0.4] 10.0.0.51 SRI-NIC Only one source-quench returned to this guy, so probably not significant. 23:00:41 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 10.0.0.89 COLUMBIA-20 Multiple offenses. Evidence of runaway-ACK in the first spasm, old gateway tables for net 128.8 in the rest. 00:52:01 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] ... 67 duplicate(s) ... 23:25:31 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 16:54:05 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.11] 00:55:00 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] ... 71 duplicate(s) ... 23:59:14 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 00:15:07 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] ... 61 duplicate(s) ... 19:05:41 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 19:15:30 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4] ... 2 duplicate(s) ... 19:15:39 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4] 19:15:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] ... 16 duplicate(s) ... 23:42:29 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 10.1.0.31 CCA-VMS (Is this guy running Access-T?) Possible old tables for 128.8. 02:53:41 006 ?TRAP-I-ICMP 005 000 [10.1.0.31] -> [128.8.0.8] 10.1.0.72 BBN-UNIX Another 128.8 problem. This is a known good player, which leads me to believe this particular microspasm may have been the result of a counting-to-infinity glitch. 22:55:49 006 ?TRAP-I-ICMP 005 000 [10.1.0.72] -> [128.8.0.4] 22:55:50 006 ?TRAP-I-ICMP 005 000 [10.1.0.72] -> [128.8.0.4] 10.2.0.14 CMU-GATEWAY Note the kamikazegrams to nets 0, 77 and 97, some of them persistent. The Martians have apparently not been blown away yet. The remainder suggest trouble with redirects during counting-to-infinity spasms. Note, this gateway is ALWAYS-UP according to the NIC tables. 02:20:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [0.0.0.0] 16:22:57 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [0.0.0.0] 22:06:06 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.31.41.120] ... 4 duplicate(s) ... 22:09:22 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.31.41.120] 14:37:03 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.34.251.1] 04:31:58 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [14.0.0.12] 21:46:43 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.15.5] 22:02:04 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.15.5] 04:23:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.21.6] ... 3 duplicate(s) ... 22:16:26 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.21.6] 17:41:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.36.5] 20:00:09 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [26.0.0.14] 05:41:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [26.1.0.34] 00:15:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5] ... 18 duplicate(s) ... 22:51:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5] 00:33:57 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] ... 20 duplicate(s) ... 23:35:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] 05:21:53 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [36.40.0.205] 16:20:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [36.40.0.205] 22:25:36 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [77.45.0.2] 22:05:26 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [8.0.0.7] 00:06:33 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] ... 122 duplicate(s) ... 23:58:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 10.2.0.52 USC-ISIF Known good player apparently mildly annoyed by network glitches. Not believed significant. 21:19:08 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.47] ... 7 duplicate(s) ... 21:24:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.47] 21:15:31 006 ?TRAP-I-ICMP 005 000 [10.2.0.52] -> [128.9.0.48] ... 18 duplicate(s) ... 21:15:34 006 ?TRAP-I-ICMP 005 000 [10.2.0.52] -> [128.9.0.48] 21:17:31 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.48] ... 5 duplicate(s) ... 21:27:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.48] 10.2.0.56 AIDS-UNIX Old tables? 01:46:25 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4] ... 8 duplicate(s) ... 23:11:17 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4] 10.2.0.58 RUTGERS Fuzzy 128.4.0.2 has been hiding for some time now. Maybe somebody here tried to pet it. Also, suspected old 128.8 tables. 06:03:03 006 ?TRAP-I-ICMP 003 001 [10.2.0.58] -> [128.4.0.2] ... 3 duplicate(s) ... 06:03:20 006 ?TRAP-I-ICMP 003 001 [10.2.0.58] -> [128.4.0.2] 00:00:58 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] ... 48 duplicate(s) ... 18:53:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 19:13:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4] ... 3 duplicate(s) ... 19:13:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4] 19:23:51 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] ... 14 duplicate(s) ... 23:32:23 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 10.2.0.77 MIT-MC Redirects probably resulting from spasm not believed significant. 20:40:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65] ... 7 duplicate(s) ... 20:40:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65] 10.2.0.82 BBN-INOC This is a very frisky host, as noted on previous occasions. Note the spasm beginning about 20:16, indicating something big broke about then. That may account for many of the redirects reported to other hosts. The data are sorted the wrong way to correlate properly, however. 20:34:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.16.3.0] ... 7 duplicate(s) ... 20:34:09 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.16.3.0] 08:54:29 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1] ... 15 duplicate(s) ... 08:57:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1] 09:00:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1] ... 2 duplicate(s) ... 09:06:30 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1] 20:16:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1] ... 15 duplicate(s) ... 20:19:13 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1] 20:22:10 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1] ... 2 duplicate(s) ... 20:28:18 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1] 21:15:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.9.0.81] ... 32 duplicate(s) ... 21:15:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.9.0.81] 20:16:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.29.1] ... 15 duplicate(s) ... 20:19:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.29.1] 20:22:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.29.1] ... 2 duplicate(s) ... 20:28:18 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.29.1] 08:53:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] ... 40 duplicate(s) ... 20:19:13 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] 20:22:10 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.46.4] ... 2 duplicate(s) ... 20:28:18 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.46.4] 20:34:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [32.3.0.42] ... 7 duplicate(s) ... 20:34:15 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [32.3.0.42] 20:33:06 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [35.7.0.0] ... 7 duplicate(s) ... 20:33:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [35.7.0.0] 10.3.0.11 SU-SCORE Classic indications of the runaway-ACK problem, probably at least two occasions. 02:07:38 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 151 duplicate(s) ... 23:31:20 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 10.3.0.44 MIT-MC Our backdoor customer on FORDNET probably went belly-up for a couple of minutes. Not significant. 20:01:49 006 ?TRAP-I-ICMP 003 001 [10.3.0.44] -> [128.5.32.1] ... 4 duplicate(s) ... 20:02:03 006 ?TRAP-I-ICMP 003 001 [10.3.0.44] -> [128.5.32.1] 10.3.0.63 BBN-TEST3 This is our EGP peer, which gets knocked with source-quench when some other player, probably suffering from the runaway-ACK bug, hammers on DCN-GATEWAY. The times suggest the bad guys are COLUMBIA-20 and SU-SCORE. 02:08:24 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] ... 11 duplicate(s) ... 23:20:24 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 10.4.0.2 SRI-AI Old tables? 17:53:49 006 ?TRAP-I-ICMP 005 000 [10.4.0.2] -> [128.8.0.4] ... 2 duplicate(s) ... 19:03:25 006 ?TRAP-I-ICMP 005 000 [10.4.0.2] -> [128.8.0.4] 10.5.0.2 SRI-IU Old tables? 01:56:08 006 ?TRAP-I-ICMP 005 000 [10.5.0.2] -> [128.8.0.10] 128.32.0.11 UCBKIM This would seem to be a runaway-ACK problem; however, this is a VAX, leading me to suspect a retransmission-timeout problem (set way too short). My intelligence reports this to be a known problem with the 4.2 distribution. 21:54:11 006 ?TRAP-I-ICMP 004 000 [128.32.0.11] -> [128.5.32.1] ... 124 duplicate(s) ... 23:45:20 006 ?TRAP-I-ICMP 004 000 [128.32.0.11] -> [128.5.32.1] 14.0.0.12 RICE Trying to pet a fuzzy too briskly. Probably not significant. 22:00:51 006 ?TRAP-I-ICMP 004 000 [14.0.0.12] -> [128.4.0.6] 18.26.0.37 MIT smallfry IBM PC at MIT. These mutts are known to read the DCN-GATEWAY clock frequently. This one probably got surprised by a source-quench in response to the UDP request because somebody else was beating (runaway ACK?) on the gateway! 23:20:07 006 ?TRAP-I-ICMP 004 000 [18.26.0.37] -> [128.4.0.1] 23:20:09 006 ?TRAP-I-ICMP 004 000 [18.26.0.37] -> [128.4.0.1] Lessons learned deptartment: 1. The runaway-ACK problem continues to spasmatize the gateway system. At least two TOPS-20 hosts, COLUMBIA-20 and SU-SCORE, appear to have this bug, which apparently has been identified and fixed by the ISI system staff. 2. There is some evidence that the 4.2 distribution may have (initial) TCP retransmission timeouts set way too low. We have found five seconds to be a reasonable compromise for use over almost any existing path (see RFC889). 3. Implementors should expect source-quench in just about any situation, even using low-rate datagram protocols like UDP and EGP, and even when the sender is not at fault. When using TCP, the appropriate behavior in the case of one-way transmissions when the receiver gets one of these in response to an ACK it sent is an interesting case (should it shrink the window?). 4. The dumb-gateway table inertia seems uncomfortably high. The rash of misrouted net-128.8 traffic above (and the relatively minor level of misrouted traffic for other nets) suggests problems with old or conflicting table information. Net 128.8 is one of the nets advertised by DCN-GATEWAY in the GATEWAY portion of the NIC tables as reachable via that gateway. However, at least for the present, net 128.8 is wired in the core system as reachable via a dumb gateway (MARYLAND) on MILNET. However, DCN-GATEWAY does not currently advertise itself as a path to that net, either in EGP or GGP. I suspect that some of the dumb gateways on ARPANET may have wired in the old path and are failing to utilize redirect information. I suspect this problem may be happening elsewhere in the system. Dave -------
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 12-Feb-84 02:03:17-UT From: mills@dcn6 To: CharlesHedrick<HEDRICK@RUTGERS.ARPA>, Mills@DCN6.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: Another nastygram report
Charles, Thanks for the info. The detective hunt continues. Dave -------
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 12-Feb-84 22:09:22-UT From: Mills@dcn6 To: TCP-IP@nic Subject: Gateway system performance
Folks, As long as I have been banging on gateway issues, you might be interested in a capsule evaluation of how well the existing system works and how it has improved over the last several months. Following is an extract of gateway traffic information collected on a weekly basis by Eric Rosen of BBN. .. Searching from Mon Jan 30 00:02:12 1984 until Sun Feb 5 23:59:59 1984 (EST) A total of 19295 throughput messages were received from 30 gateways GWY GWY RCVD RCVD IP % IP DEST % DST NO. NAME DGRAMS BYTES ERRORS ERRORS UNRCH UNRCH TOTALS 79,068,588 3,748,292,651 22,989 0.03% 329,104 0.42% GWY GWY SENT SENT DROPPED % DROPPED NO. NAME DGRAMS BYTES DGRAMS DGRAMS TOTALS 80,874,600 3,977,797,017 485,184 0.60% 60.90% of all received packets are addressed to a gateway 62.61% of all sent packets originate at a gateway 57.56% of all sent packets are forwarded to another gateway .. Last August I analyzed similar data on 19 gateways in order to determine the protocol overhead and effectiveness of the system. The result was pretty dismal, showing that, of the traffic transiting the gateway system, less than one packet in five represented real user data and almost half the packets were misrouted. Following is a more detailed summary of these results. Note that all values have been normalized on a per-gateway, per-hour packet basis. (I'll describe the assumptions and methods for calculation separately if there is sufficient interest.) Totals - received 11591 sent 12406 difference 815 Received addressed to a gateway 8345 to a host 3246 Sent originating at a gateway 9304 at a host 3102 Sent forwarded to another gateway 7567 to a host 4839 Redirects sent to hosts 959 GGP pings sent/received 6608 Host pings sent/recieved 1737 Host traffic received 2287 Host traffic sent 2143 Efficiency .197 Misroutes .419 Last week I analyzed the data shown at the beginning of this message and obtained the following reults: Totals - received 15674 sent 16051 difference 377 Received addressed to a gateway 9545 to a host 6129 Sent originating at a gateway 10047 at a host 6004 Sent forwarded to another gateway 9245 to a host 6806 Redirects sent to hosts 502 GGP pings sent/received 8743 Host pings sent/recieved 802 Host traffic received 5627 Host traffic sent 5502 Efficiency .359 Misroutes .089 In spite of the growth from 19 to 30 gateways, more than one packet in three is real user data and less than one packet in ten is misrouted. A casual inspection of the data reveals three reasons for the improvement in performance: 1. Host pinging has diminished. 2. Hosts are paying closer attention to redirects. 3. Host traffic has grown faster than GGP traffic. The principal reason for the low efficiency is the overhead due to the gateways pinging each other, which is hardly news to anybody. However, many of the 30 GGP gateways now in the core system are used to splice relatively low-traffic local nets to the ARPANET and could be converted to EGP without significant loss of service. This would dramatically reduce the pinging din, as well as reduce the impact of up/down spasms. We could even split the core into two or more cliques of gateways, each running GGP between themselves and connected to the others by EGP. Since the deployment of "operational" EGP gateways is now being discussed, I suggest an interesting experiment might be to set up and test this idea. DCN-GATEWAY is in fact set up and instrumented to do this. The test would involve merely configuring one or more existing GGP gateways to include only each other and DCN-GATEWAY in their neighbor tables. DCN-GATEWAY would then boogie with them using either GGP or EGP and with the rest of the world using EGP and the core system. In principle, this idea would work with the operational EGP gateways as well. If there is interest in such a test, please contact me directly. Dave -------
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Mon 13 Feb 84 11:39:43-PST From: Mark Crispin <MRC@SU-SCORE.ARPA> To: Hornig%SCRC-QUABBIN@MIT-MC.ARPA Cc: tcp-ip@SRI-NIC.ARPA, bug-ftpser@MIT-XX.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA Subject: Re: TOPS-20 FTP server
If it makes anyone feel any better, I am finishing a rewrite of the TOPS-20 FTP server which I am confident won't have this problem. However, since it uses the DEC system call interface (the primary reason for the rewrite), I fear the old FTP server won't go away for a very long time. It took Tenex TELNET several years to go away on TOPS-20. -------
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Feb 84 09:26 EST From: Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: bug-ftpser@MIT-XX.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA Subject: TOPS-20 FTP server
I have run into a consistent problem talking to Internet TOPS-20 FTP servers from hosts on our local network. All of the ones I've tried (SRI-NIC, MIT-XX, ISIE, ECLB) do not respond to "USER ANONYMOUS" when the machine connecting is NOT in the NIC host table. When it is in the host table, everything works fine. In particular, it happened this morning connecting to SRI-NIC from SCRC-MERRIMACK (192.10.41.80) but not from SCRC-RIVERSIDE (192.10.41.21). Does anyone have any ideas on how to deal with this? Do I have to put all of our hosts in the NIC table?
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Feb 84 10:32:36 PST From: Andy Sills <sills@AEROSPACE> To: TCP-IP@SRI-NIC, TCP-IP@BRL Cc: perillo@SRI-NIC Subject: TCP/IP Implementation for RSX-11/M
TWIMC: I would like to know how many users running RSX-11/M would be interested in getting a TCP/IP implementation for their machines? The key to doing this is a board that plugs into the Unibus and creates a virtual IBM PC running MS-DOS. The software and hardware associated with this board create the connection between the virtual file structure of RSX and the host file structure of the PC. Tasks started under this program appear to be running on a PC even though they are under RSX. Here's the trick. If there really were a PC, there would be an Ethernet board plugged into the mother board, and TCP/IP code that already exists and would talk to that board. In an RSX machine, there would be an Ethernet board for networking, AND this virtual PC emulator board. What remains to be done is to write the code for having the virtual PC talk to the RSX machine's Ethernet board as if that board were actually mounted in a real PC. This job can be done as a special project (very expensive) or as a developed product by a comnpany that is willing to try. They would like to assess the interest of the RSX community. Aerospace has two users interested. Are there any others? Please reply to sills@AEROSPACE if you are.
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 1984 13:44:16 PST From: MILLS@USC-ISID To: sills@AEROSPACE, TCP-IP@SRI-NIC, TCP-IP@BRL Cc: perillo@SRI-NIC, MILLS@USC-ISID Subject: Re: TCP/IP Implementation for RSX-11/M
In response to the message sent Tue, 14 Feb 84 10:32:36 PST from sills@AEROSPACE Folks, While this appears to be an exotic and wonderful can of worms, there is at least one alternative. COMSAT is distributing IP/TCP code that runs under RSX to support the international INTELPOST electronic-mail network. The code happens to be a spinoff of the infamous Fuzzball code used here for Internet research for some years. Further information from Dave Jupin at COMSAT Laboratories (301) 428-4571. Dave -------
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 1984 14:00-PST From: BILLW@SRI-KL To: sills@AEROSPACE Cc: TCP-IP@SRI-NIC, TCP-IP@BRL, perillo@SRI-NIC Subject: Re: TCP/IP Implementation for RSX-11/M
Well, there is a company ("ExceLAN", San Jose), who manufatcures
an ethernet board with an onboard 8088 processor and TCP/IP
software. All I have around is a blurb on their multibus board,
But I think they also have a unibus version. I dont know anything
else about the product: their phone number is 408 945-9526
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 1984 11:50-EST From: CLYNN@BBNA To: Hornig%SCRC-QUABBIN@MIT-MC Cc: tcp-ip@SRI-NIC, bug-ftpser@MIT-XX lispm-networks%SCRC-TENEX@MIT-MC Subject: Re: TOPS-20 FTP server
I tried to repeat your problem by logging into SRI-NIC, MIT-XX, and ISIE from one of the BBN terminal concentrators (which are not listed in the NIC's host tables). They all accepted the USER ANONYMOUS, PASS ... sequence. What are we doing differently?
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Feb 84 1:43:35 EST From: Ron Natalie <ron@brl-vgr> To: Andy Sills <sills@aerospace> Cc: TCP-IP@sri-nic, TCP-IP@brl, perillo@sri-nic Subject: Re: TCP/IP Implementation for RSX-11/M
Putting TCP/IP on RSX-11M is a good idea. Your suggestion on how to do it is a little bazaar. IBM-PC's are hardly an effective network interface. If you've already got an ethernet or IMP interface for your Machine, why not just implement the TCP/IP directly on the PDP-11 (this is practical if you are using one of the larger 11's eg. 44,45,55,70). Try contacting my former employer, Martin Marritta. They seem to have FTP and TELNET at least on their RSX machines (MARTIN and MARTIN-ED). Also a few other hosts including NRL-ARCTAN and NSWC-DL claim to be up with TCP on RSX. These are 11/40's. All the RSX signons I've seen say "SAMNET" if that's any help. -Ron
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Feb 84 1:46:27 EST From: Ron Natalie <ron@brl-vgr> To: BILLW@sri-kl Cc: sills@aerospace, TCP-IP@sri-nic, TCP-IP@brl, perillo@sri-nic Subject: Re: TCP/IP Implementation for RSX-11/M
The EXCELAN people seem to have a very nice implementation of TCP on their board. Unfortunately we are still waiting for the UNIBUS board to be announced although they claim it is in the work. We are looking forward to using the EXCELAN's on our smaller machines (23's and 34's). It's got a really nice interface. -Ron
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 15-Feb-84 03:06:46-UT From: Mills@dcn6 To: TCP-IP@nic Subject: The babble diminishes
Folks, Digging in the muck is paying off - the trash heap continues to diminish. After discussions with individual implementors and fixes kindly supplied by ISI and BBN, the primary law-benders mentioned in my previous messages have been fixed. Like smallpox, the excitement now is to try to kill all the beasties off. The following hosts are suspected of some traffic violations still, although the wholesale destruction which prompted my recent messages has tapered off a lot. SRI-NIC: suspect runaway-ACK 15:59:23 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.32.1] ... 44 duplicate(s) ... 16:24:53 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.32.1] 00:56:07 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 00:56:08 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] COLUMBIA-20: excessive source quench 01:55:25 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] ... 4 duplicate(s) ... 19:01:23 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] COLUMBIA-20: excessive redirects for net 128.8 00:13:28 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] ... 50 duplicate(s) ... 23:43:27 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 00:01:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] ... 45 duplicate(s) ... 23:03:21 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] CMU-GATEWAY: excessive misroutes 14:25:39 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.42.1.1] 00:06:19 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.42.1.6] ... 2 duplicate(s) ... 21:25:03 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.42.1.6] 18:31:49 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.7.0.1] 00:13:30 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [14.0.0.12] 16:50:48 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [192.5.19.1] 16:51:01 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.21.4] 16:49:13 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [26.7.0.50] 01:28:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5] ... 7 duplicate(s) ... 19:30:24 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5] CMU-GATEWAY: Martian attacks 17:21:52 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [1.128.2.251] 15:41:46 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [19.0.0.0] 16:09:15 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.11.194] ... 2 duplicate(s) ... 16:17:19 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.11.194] The log scanned is for something over two days and has been culled to remove the occasional redirect or unreachable for J. Random Host. If this is evidence for similar behavior throughout the gateway system, things may be in much better shape than I first feared. Unless the situation deteriorates I will shut my mouth in this forum and go beat up the individual hosts directly. Charlie Lynn's recent fix for the TOPS-20 "window whapper," in which arriving TCP segments overrun the receiver window, almost exhausts my encrustated punch list of outstanding performance-related issues. The list still contains apparent connection-close problems noted at MIT-MULTICS, as well as known TOPS-20 FTP server connection-close problems and suspected 4.2 initial TCP timeout problems. Dave -------
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Feb 84 14:01 EST From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: martians indeed
Who will fix the "runaway duplicate long mail bug?} "
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Feb 84 15:54 EST From: Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA> To: CLYNN@BBNA.ARPA Cc: tcp-ip@SRI-NIC.ARPA, bug-ftpser@MIT-XX.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA Subject: Re: TOPS-20 FTP server
Date: 14 Feb 1984 11:50-EST
From: CLYNN@BBNA
I tried to repeat your problem by logging into SRI-NIC, MIT-XX, and
ISIE from one of the BBN terminal concentrators (which are not
listed in the NIC's host tables). They all accepted the USER
ANONYMOUS, PASS ... sequence. What are we doing differently?
We have found the problem. It is our fault. One of our gateways had a
very obscure bug involving Ethernet packets of length 3 mod 4. The
TOPS-20 response for our hosts which weren't in the table was long
enough to set it off. Sorry to bother you all.
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 16-Feb-84 17:23:33-UT From: Mills@DCN6 To: TCP-IP@SRI-NIC Cc: Byard@DCA-EMS, CAK@PURDUE, Clausen@USC-ISID, Fuzzball@USC-ISID, Gross@DCN7, Jay@FORD1, Louie@CVL, Mike.Accetta@CMU-CS-IUS, Mike@UMD9, Milazzo@RICE, Patrick@FORD-WDL1, Spilling@NTARE1 Subject: Fuzzball throughputs
Folks, You may be interested in the following overall performance data on the fuzzball implementation. The data reveal the total processing times for ordinary user interaction using a local terminal and for various network processing functions. These particular data were collected on an LSI-11/23 system using 256 Kbytes of memory, a 30-Mbyte Winchester disk and Interlan Ethernet interface. The processing times were determined from a number of statistical counters and timers maintained by the system itself and, in the case of interrupt times, by outboard electronic instrumentation. The worst-case interrupt CPU time was measured for the Winchester disk controller as about 800 microseconds - the times shown below for other devices were based on prior measurements corrected for the actual configuration. Per-process times are obtained by counting the number of 60-Hz timer interrupts when the process is active. Thus, if an interrupt occurs while the process is active and does not result in a context switch, the interrupt time is charged to the process. Also note that most processes are rescheduled withing only a few milliseconds, so that this method is accurate only if (a) the rescheduling event is not correlated with the timer event and (b) a large number of events are averaged. Fuzzballs are built using a pair of link-level processes which does the internal packet switching for each network interface, a network-level process which does the kernel-space IP and TCP processing, and an application process for every local user or network server. A pair of terminal processes is associated with each local terminal in the system. All except the application processes are run in kernel space. Each application (user) process is run in a separate user space as an emulated RT-11 background job. Local terminal input/output times were measured by simply banging on a key and watching the counters. Most of the processing in the user process is due to RT-11 EMT emulation. For output-only this process burns only about 1100 microseconds per character. Note that character input is necessarily character-at-a-time; however, character output is buffered several characters per interprocess message. The link-level process input/output times were measured using an ACC 1822 (DMA) interface connected to an ARPANET IMP. About two-thirds of the output time is burned in the ARPANET 1822 leader code, which can result in a table search to find gateway addresses. The network-level process handles all datagrams landing at the host. The times include reassembly queue processing, header validation, connection matching and protocol module processing. For raw datagrams the protocol processing is minimal, since the datagram is simply mapped into the appropriate user process virtual space. For TCP datagrams the processing includes reassembly, retransmission and copying to and from user virtual space. In both cases the times include a mixture of short and long packets up to 576 octets. Following is a summary of the data: Terminal input/output (per character) DLV11 PI interfaces Input interrupt 500 est Terminal input process 2429 Output interrupt 300 est Terminal output process 816 User process 3893 ---- Total 7938 microseconds/character Link input/output (per packet) ARPANET 1822 DMA interfaces Link input interrupt 300 (est) ARPANET net input process 2167 Link output interrupt 300 (est) ARPANET net output process 1876 ---- Total 4643 microseconds/packet Network process (per packet) Raw datagrams 3280 TCP datagrams (segments) 13620 One way of looking at these figures is that the LSI-11/23 becomes CPU bound at an aggregate data rate of 125 characters per second or 200 packets per second (assuming the characters and packets pass right through the system). The maximum aggregate character input rate is 150 characters per second and the maximum aggregate output rate is 400 characters per second. For datagrams landing at the host, the maximum raw-datagram rate is 125 packets per second, assuming equal input and output rates, while the maximum TCP rate is 50 576-octet packets per second, exclusive of user processing. Finally, an FTP disk-to-disk between a pair of fuzzies on an Ethernet is about 8000 characters per second. Obviously, the fuzzball performance can be improved, especially in the user process. The overhead for RT-11 emulation is severe, as is the requirement for character-at-a-time input. Packet processing can be improved by hashing the net table, which has lately grown to over 60 entries. TCP processing can be improved in the area of buffer management (every implementation can make that statement). Hopefully, this information will be useful in evaluating the performance of other implementations using LSI-11 or similar horsepower. Dave -------
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Fri, 17 Feb 84 0:24:39 EST From: Ron Natalie <ron@brl-vgr> To: tcp-ip@sri-nic Cc: nic@sri-nic, rnj@brl-vgr Subject: TACNEWS
The "@n" doesn't seem to give the TAC-NEWS host. Just says destination host unreachable. Telnet-ing to the TAC-NEWS address (8.7.0.4) yields the host but the old tacnews and anonymous/guest logins no longer work. -Ron
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Fri, 17 Feb 84 08:31:20 CST From: george@EGLIN-VAX To: tcp-ip@sri-nic Cc: george@afsc-hq Subject: RSX TCP/IP
In light of the recent RSX / TCP discussions I will add another message to the Bulletin Board. My apologies to those who are aware or co