----MESSAGE-BEGIN---- <1986020321070100> Received: from RED.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Mon 3 Feb 86 23:13:47-PST Date: 4 Feb 86 02:07:01 EST From: Charles Hedrick Subject: TOP (ISO) addressing To: tcp-ip@SRI-NIC.ARPA Message-ID: <12180598695.5.HEDRICK@RED.RUTGERS.EDU> Apparently a few people on this group are interested in the ISO protocols. At least there has been enough interest to post some of the standards as RFC's (for which I am grateful). So I hope there may be someone who can answer a question: I have been looking at the specifications for TOP. (For those who don't know what this is, this is the most likely candidate among the ISO protocols for a replacement to TCP/IP in the environment where most of us use it. ISO is a large family of protocols. It provides alternatives at many steps, and leaves a number of things unspecified. MAP and TOP are specifications that make choices where choices are needed, and that fill in the unspecified details. MAP is intended for manufacturing, whereas TOP is intended for the office or research environment. MAP and TOP are really a family, and make similar choices where there is no specific reason to do otherwise.) If I undestand all of the verbiage correctly (and the probability is high that I do not), it looks like TOP is likely to run out of address space. As I read the spec, an address contains two major parts: a two-byte subnetwork number and a variable component which for most of us will turn out to be the host's Ethernet address. It seems to me that 16 bits is not very much for the subnetwork number. As I understand it, the subnetwork number will have to be globally unique (i.e. no other subnetwork in the world can have the same subnetwork number). Even if that is not said in the spec, it seems clear that it is going to have to be the case if we are going to allow for the possibility that subnetworks will communicate with each other over common-carrier X.25 networks or the Arpanet. Furthermore, it is said that routing through gateways is to be based entirely on the subnetwok number. This seems to imply that places like Rutgers that are class B Internet sites will need to use a separate TOP subnetwork number for each of our internal subnets. So in practice, it seems like we are going to need roughly one subnetwork number for every Ethernet that runs TOP. I find it hard to believe that 16 bits will be enough. Does anyone see an error in this argument? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020401430000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Tue 4 Feb 86 10:22:57-PST Date: 4 Feb 86 09:43:00 PST From: " RT BERGGREEN" Subject: RE: TOP (ISO) addressing To: "hedrick" cc: tcp-ip@sri-nic Reply-To: "ART BERGGREEN" > Apparently a few people on this group are interested in the ISO > protocols. At least there has been enough interest to post some > of the standards as RFC's (for which I am grateful). So I hope > there may be someone who can answer a question: > > I have been looking at the specifications for TOP. [deleted text] > If I undestand all of the > verbiage correctly (and the probability is high that I do not), > it looks like TOP is likely to run out of address space. As I > read the spec, an address contains two major parts: a two-byte > subnetwork number and a variable component which for most of us > will turn out to be the host's Ethernet address. It seems to > me that 16 bits is not very much for the subnetwork number. > As I understand it, the subnetwork number will have to be > globally unique (i.e. no other subnetwork in the world can > have the same subnetwork number). Even if that is not said in > the spec, it seems clear that it is going to have to be the > case if we are going to allow for the possibility that subnetworks > will communicate with each other over common-carrier X.25 networks > or the Arpanet. Furthermore, it is said that routing through > gateways is to be based entirely on the subnetwok number. This > seems to imply that places like Rutgers that are class B > Internet sites will need to use a separate TOP subnetwork number > for each of our internal subnets. So in practice, it seems > like we are going to need roughly one subnetwork number for > every Ethernet that runs TOP. I find it hard to believe that > 16 bits will be enough. The Top spec is very early in its development (at V1.0). TOP is intended to interoperate with MAP at the Network, Transport and Session layers. For interoperation at the Network layer, both MAP and TOP will have to use the same addressing formats. The MAP 2.1 spec calls out three Network address formats allowed by the ISO address rules. One of these formats has a CCITT administered Initial Domain Identifier (IDI), and the other two formats are for locally administered addresses. The address format in the V1.0 TOP spec is not compatible with any of these. The TOP spec appears to call out the address format that was chosen for the Autofact show and I believe is also the NBS OSINET format. Also, routing protocols are not currently defined. Routing and congestion control will be absolutely necessary before ISO protocols could be used in the DoD community. MAP 3.0 is supposed to include network routing and management protocols. There is a recently established distribution list for ISO protocol discussion: . ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020411175900> Received: from proteon.arpa by SRI-NIC.ARPA with TCP; Tue 4 Feb 86 13:19:27-PST Date: Tue, 4 Feb 86 16:17:59 EST From: jas@proteon.arpa Subject: 802.2 SAP for ARP To: tcp-ip@sri-nic.arpa I'm trying to get an extended (48 bit) one. We'll see how I do. I'll report next week. John Shriver ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020414430900> Received: from SUMEX-AIM.ARPA by SRI-NIC.ARPA with TCP; Tue 4 Feb 86 22:43:34-PST Date: Tue 4 Feb 86 22:43:09-PST From: Mark Crispin Subject: DOWN WITH DUMB GATEWAYS! To: TCP-IP@SRI-NIC.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12180856495.29.CRISPIN@SUMEX-AIM.ARPA> Right now, the core gateways claim that FORDNET (128.5) is unreachable. However, FORD-SCF1 is sending SYN's at SUMEX's SMTP server at an alarming rate, tying it up so that very little mail is coming through. Either some dumb gateway is forwarding these packets from FORDNET, or the DCN-GATEWAY is doing so without telling the EGP world about it. Somebody please stop FORD-SCF1 and/or the gateway. By the way, I think it is very antisocial of a mailer to repeatedly SYN a port for hours. It ought to take no for an answer and go to sleep for a bit before trying again. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020502060000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Wed 5 Feb 86 10:07:23-PST Date: 5 Feb 86 10:06:00 PST From: Subject: RE: iso-request@acc-sb-unix To: "tcp-ip" Reply-To: My appologies to anyone who failed attempting to send to wishing to get on the ISO mailing. Iso-request should now work properly (It ends up coming to me anyhow). ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020503183800> Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Wed 5 Feb 86 06:58:32-PST Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2685451721871547@MIT-MULTICS.ARPA>; 05 Feb 1986 09:48:41 est Date: Wed, 5 Feb 86 08:18:38 EST From: Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: TCP-IP@SRI-NIC.ARPA, TCP-IP-RELAY@SRI-NIC.ARPA Message-ID: <1119927@UMich-MTS.Mailnet> Subject: DOWN WITH DUMB GATEWAYS! I see lots of similar things (routing) since the core gateway egp tables got full. What I see happening from lots of hosts is that I receive datagrams (mostly SYNs or UDP Domain requests to our domain server) to which I respond. The responses bounce at the gateway since it does not find the entry in the egp table and sends an ICMP net unreachable back to me. The frequent retransmissions are a different problem which also showed up in a much elevated way since the egp problem appeared since I get the data but the response is not able to get back. We could use this situation as a tool to find lots of flakey implementation because the retransmission problems are much more easily visible. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020506451100> Received: from uw-beaver.arpa by SRI-NIC.ARPA with TCP; Wed 5 Feb 86 20:41:14-PST Received: by uw-beaver.arpa (4.42/4.2) id AA04098; Wed, 5 Feb 86 20:45:39 PST Return-Path: Message-Id: <8602060445.AA04098@uw-beaver.arpa> Date: Wed, 5 Feb 86 11:45:11 est From: Nathaniel Mishkin Subject: 4.2bsd UDP/IP Bug? To: apollo!tcp-ip@sri-nic.arpa For reasons that don't bear explanation, I recently had to look through the 4.2bsd "tftp" server and client code. I saw some strange things that led me to wonder how UDP works under 4.2 and how it's supposed to work. I saw that once the server gets a "request" packet on the "tftp" well-known port, it forks. The child continues to read on the same file descriptor (port). The parent goes back to the top of its listen loop, creates a new socket, and binds its end to the "tftp" well-known port again. According to my understand of how UDP is supposed to work, if the implementation is correct, then "tftp" could never work since both the parent and the child would be reading packets from the same port -- it would be random which were gotten by the parent and which were gotten by the child. The apparent reason things work on 4.2 is because the kernel demultiplexes incoming UDP packets based on BOTH the packet's local AND foreign port. If I understand the UDP/IP spec, this is a bug -- you're supposed to demultiplex incoming packets by looking ONLY at the local port. Do I misunderstand UDP? Is 4.2 broken? Is 4.3 fixed? Please respond to me since I'm not on this list. -- Nat Mishkin Apollo Computer Inc. {wangins,yale,uw-beaver}!apollo!mishkin apollo!mishkin@UW-BEAVER.ARPA ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020507025700> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Wed 5 Feb 86 09:03:33-PST Date: 5 Feb 1986 12:02:57 EST From: MILLS@USC-ISID.ARPA Subject: Re: DOWN WITH DUMB GATEWAYS! To: Crispin@SUMEX-AIM.ARPA, TCP-IP@SRI-NIC.ARPA cc: MILLS@USC-ISID.ARPA In response to the message sent Tue 4 Feb 86 22:43:09-PST from Crispin@SUMEX-AIM.ARPA Mark, No, you have it wrong. FORDnet is being actively asserted as up via EGP from DCN-GATEWAY, which it in fact really is. You are seeing IDMP Destination Unreachable messages returned from FORDnet host FORD1, since the particular subnet used by the offending host appears down at that host, which is in fact a subnet gateway. The infrastructure supporting connectivity to the offending host is presently working correctly; however, your comments re the host itself are well taken. Please direct your comments to John Nagle (jbn@ford-wdl1.arpa), who is the responsible person for those Ford Aerospace hosts. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020510061400> Received: from BRL-SMOKE.ARPA by SRI-NIC.ARPA with TCP; Wed 5 Feb 86 12:12:42-PST Date: Wed, 5 Feb 86 15:06:14 EST From: Ron Natalie To: Hans-Werner_Braun%UMich-MTS.Mailnet@mit-multics.arpa cc: TCP-IP@sri-nic.arpa, TCP-IP-RELAY@sri-nic.arpa Subject: Re: DOWN WITH DUMB GATEWAYS! I wouldn't quite blame the non-core gateways for this. It is hardly there fault that the core-IGP doesn't work. Currently EGP is in a state that you have to very carefully meter how you deal with the core, e.g. you have to watch which core-EGP speaker you load your routing table with, you've always had to discard entries for your own networks, etc... -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020516074500> Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Wed 5 Feb 86 12:19:40-PST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Wed, 5 Feb 86 14:29:20 EST Received: by mcvax.uucp; Wed, 5 Feb 86 19:51:22 +0100 (MET) Received: by vmucnam.UUCP; Wed, 5 Feb 86 19:43:13 GMT (MET) Received: by vmucnam.UUCP; Wed, 5 Feb 86 19:42:40 GMT (MET) Received: by imag.UUCP; Wed, 5 Feb 86 19:27:45 -0200 (MET) Date: Wed, 5 Feb 86 19:27:45 -0200 From: mcvax!imag!pierre@seismo.CSS.GOV (Pierre L. LAFORGUE) Message-Id: <8602051727.AA27775@imag.UUCP> To: info-vax@sri-kl.ARPA, tcp-ip@sri-nic.ARPA Subject: Submission about TCP/IP under VMS May you think appropriate to post this in your moderated newsgroups? Thank you very much in advance, if possible. To insert a VAX/VMS on an Ethernet linking heterogeneous Unix computers, and later Microvaxes/VMS, we are looking for a TCP-IP software running under DEC/VMS, and supporting possibly NFS. We received no response from Wollongong, but a proposition from GEC-Software (132-135 Long Acre LONDON WC2E9AH G.B. , Tel 01-2407171) which offers TCP-IP and a gateway with DECNET named "Dbridge". As I saw somebody seeking vendors of TCP-IP, this information should be usefull to him. My questions are : 1- Is there anyone who experienced the TCP-IP/VMS of GEC-Software ? Is it possible to use all of the application level Unix stuff with it, as rlogin, rwho, from Unix and from VMS ? 2- Does anybody know a source for NFS/VMS ? Thank you very much to answer to: pierre@imag.UUCP (or ...!seismo!mcvax!vmucnam!imag!pierre) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020519183500> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Wed 5 Feb 86 21:20:01-PST Date: 6 Feb 1986 00:18:35 EST From: MILLS@USC-ISID.ARPA Subject: Re: DOWN WITH DUMB GATEWAYS! To: ron@BRL.ARPA, To: Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA cc: TCP-IP@SRI-NIC.ARPA, TCP-IP-RELAY@SRI-NIC.ARPA, cc: MILLS@USC-ISID.ARPA In response to the message sent Wed, 5 Feb 86 15:06:14 EST from ron@BRL.ARPA Ron, Careful peruse of RFC-904 should reveal an EGP stalwart should in fact report every network directly reachable from its own autonomous system, which includes the net common with the core gateway. With that bit, you should not be surprised if said core gateway hands your net back to you. In fact, DCN-GATEWAY peers with up to three core gateways and an odd-lot non-core gateway or two sometimes, but with unspectacular consequences. Turns out, if you believe EGP hop counts sent by core gateways (i.e. from the same system) hop counts can be compared and all except the lowest discarded. This, however, is an unadvertised feature the existence of which could probably be inferred from the tortuous history of this protocol and the personality of its developers. What else can be said, except stay tuned for more formal proposals in this area that might even legitimize this inference. You did not hear me say these words. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020520502200> Received: from DCN8.ARPA by SRI-NIC.ARPA with TCP; Wed 5 Feb 86 12:50:34-PST Date: 05-Feb-86 20:50:22-UT From: mills@dcn6.arpa Subject: Conversations with an Ethernet watcher To: tcp-ip@sri-nic.arpa Folks, Further to my recent note and the previous notes from Mark and Hans-Werver. I watched packets wade through our DCnet Etherswamp and found alligators still munching. Briefly, that swamp includes gateways to ARPANET (56K bps), UMICHnet (9.6K bps) and FORDnet (9.6K bps), as well as a raft of other swamp creatures. Thus, I can see all packets flying between DCnet gateways and in some cases the subnet gateways on FORDnet and UMICHnet. The hosts lurking on the subnets include 3COM, 4.3bsd, Wollongong, Sun, fuzzball and even more bizarre creatures scattered all over the country. The subnets are connected mostly by multiple 9.6K bps lines and fuzzball gateways, which run a dynamic routing algorithm that functions both at the net and subnet level. As you might expect, we take moderate to severe congestion hits when things break or when hosts on any of the nets misbehave, which seems fairly often these days. Mark and Hans-Werner report only the tip of the swampberg, to phrase a coin. Following is a quick summary of my Etherwatch, captured in the interval between curiousity and eyestrain and intended not so much as a specific problem report as a generic speculation on what might be happening in other ponds. 1. Congestive collapse. When things get really bad the fuzzball routing algorithm will occasionally declare a line down, which can activate a secondary path, but only after a period of hold-down and possibly non-reciprocal connectivity (we call these "one-wire feeds" after a term used in the radio/TV broadcast community). When this happens transient black holes and ICMP error messages can originate at the strangest places. 2. Black holes. Not all subnet gateways subscribe to the fuzzball routing algorithm; in particular, some FORDnet subnet gateways. The fuzzballs thus cannot determine reachability and do not generate ICMP error messages. Unfortunately, this situation now holds (since Mark's complaint) for all FORDnet subnets except 128.5.0. Mark will henceforth get no error messages at all when Ford Aerospace gateways or lines west of Dearborn are blitzed. 3. Disregarding error reports. I see what appears to be almost universal disregard for ICMP error messages. Certainly Unix and TOPS-20 users remain blissfully ignorant of these things, which many gateways, including the core gateways and fuzzballs, take some pain to get right. Thus, the casual user has no hard evidence to beat up the system or net maintainers. 4. Mismatched routing dynamics. EGP dynamics are very slow compared with most IGP dynamics, including the fuzzballs. Thus, nets on the business side of our EGP gateway, for example, can flap up and down with the effect that EGP advertisements may disagree with the actual routes delivered. Our own warranty has a clause relieving liability during transient periods up to several minutes. 5. Hidden gateways. There is a lot of subnet plumbing in our waterworks, some of it rather leaky (in the best and most common tradition). Thus, ICMP error messages can originate at a subnet gateway or even a host without implying problems further up the pipe. Unless the recipient of such an error message is aware of the subnet configuration, it might mistakenly assume the primary (net) gateway is broken. 6. Protocol problems. Certain hosts tapping our plumbing make rather good random-noise/congestion generators (not our DCnet hosts, of course). I watched Wollongong 128.5.0.9 generate between 1.5 and 5 ACKs for every TCP data segment just now. I also saw 4.3bsd(?) 128.5.33.1 and 10.2.0.78 get into ACK-ACK fights. Host 10.2.0.78 apparently has a bunch (3) of hung TCP connections sending something every few seconds but ignoring what appear to be valid reset segments from 128.5.33.1. The 128.5.32.1 and 128.5.33.1 hosts advertise, probably unwisely, windows of 2048 and 4096 octets respectively, which is much larger than necessary (two to four seconds at 9.6K bps) and almost guarantees gateway congestion. Almost every initial-connection attempt involves at least two and up to five retransmissions at intervals much less than the estimated roundtrip delay. 7. Fairness abusers. Why do some hosts (10.2.0.78, among others) open multiple parallel SMTP connections to the same host? This might represent a misguided attempt to "optimize" the delivery delay, but certainly makes the congestion problems that much worse. There are two such connections right now between 10.2.0.78 and 128.5.32.1 and three between 10.2.0.78 and 128.5.33.1. No wonder our poor fuzzthings get eaten by the alligators. 8. Tinygrams and jumbograms. Occasionally I see connections across the net with probably unwise selection of maximum segment size MSS, with a particularily uncomfortable choice of 1024. This guarantees fragmentation at least once somewhere on the path and usually twice, as well as clogs reassembly resources in congested weather. Smaller values less than the ARPANET maximum (906-odd) are much more appropriate. In fact, gains in efficiency on many paths with MSS greater than 576 are lost due to congestion, itself due to lower buffer-space utilization. At the other end of the spectrum, vast spasms of tinygrams (usually character-at-a-time TELNET) continue to flood the swamps, in spite of well-documented fixes for this. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020521311900> Received: from sri-gemini.ARPA by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 05:35:27-PST Received: by sri-gemini.ARPA at Thu, 6 Feb 86 05:31:19 pst Date: Thu, 6 Feb 86 05:31:19 pst From: Earl Craighill Message-Id: <8602061331.AA10091@sri-gemini.ARPA> To: iso-request@acc-sb-unix Cc: "tcp-ip" Subject: RE: iso-request@acc-sb-unix In-Reply-To: Your message of 5 Feb 86 10:06:00 PST. <8602052056.AA14354@sri-tsc> Art- Please put me on the iso mailing list. The safest address to use is Craighill@sri-kl. Thanx Earl ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020603392500> Received: from mitre-gateway.arpa by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 06:07:08-PST Date: 6 Feb 1986 8:39:25 EST (Thursday) From: T. Michael Louden (MS W422) Subject: Re: DOWN WITH DUMB GATEWAYS! To: ron@brl Cc: tcp-ip@sri-nic Maybe the solution to much of the EGP related problems it to have BBN upgrade the core to meet the EGP specs., the problem where the core says that it is the route to your network strikes me as a dangerous bug that can easily result in a black hole in the INTERNET. The less serious problems of incomplete status fields on error messages and not peering with gateways that are not directly connected should also be fixed. I have heard suggestions that the Butterfly gateways should be used to replace the current 11/23s. I am concerned that the code in these will be no better since it comes from the same place. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020605124100> Received: from mitre-gateway.arpa by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 07:18:01-PST Date: 6 Feb 1986 10:12:41 EST (Thursday) From: T. Michael Louden (MS W422) Subject: Re: DOWN WITH DUMB GATEWAYS! In-Reply-to: Your message of 6 Feb 1986 00:18:35 EST To: mills@dcn6 Cc: tcp-ip@sri-nic, louden@mitre-gateway.arpa Dave, Your net is not directly reachable from the core autonomous system since your gateway is not part of the core autonomous system. The core must us your gateway to reach your net. Thus I do not understand your comments. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020606031200> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 10:13:16-PST Received: by cu-arpa.cs.cornell.edu (5.31/4.30) id AA00579; Thu, 6 Feb 86 13:12:43 EST Date: Thu, 6 Feb 86 11:03:12 est From: swb@devvax.tn.cornell.edu (Scott Brim) Message-Id: <8602061603.AA00884@devvax.tn.cornell.edu> Received: by devvax.tn.cornell.edu (4.12/4.30) id AA00884; Thu, 6 Feb 86 11:03:12 est To: tcp-ip@sri-nic.arpa Subject: Tektronix VMS We have heard that someone has adopted Tektronix's VMS TCP/IP software and is "fixing it up" (as is it doesn't know about gateways, for example). We've also heard, less reliably, that it is someone at CMU. We're VERY interested and would like to get in touch with anyone who is working on this. Thanks -- Scott ----- Scott Brim swb@devvax.tn.cornell.edu Cornell University Theory Center {decvax,ihnp4,cmcl2,vax135}!cornell!swb 607-256-8686 swb@cornella.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020606115900> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 10:37:20-PST Received: from (MAILER)OHSTVMA.BITNET by WISCVM.WISC.EDU on 02/06/86 at 09:17:26 CST Return-path: TS0400%OHSTVMA.BITNET@WISCVM.ARPA Received: by OHSTVMA (Mailer X1.21) id 2295; Thu, 06 Feb 86 10:17:06 EDT Date: Thu, 06 Feb 86 10:11:59 EDT From: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU (Bob Dixon) To: TCP-IP@SRI-NIC.ARPA Subject: GEC Software A telephone call to London revealed that the VMS tcp-ip software mentioned here recently by Pierre is in fact the Wollongong software, exported to England. They refer all US inquiries to Wollongong. Th However, I am still interested in the DECnet gateway called Dbridge. Does anyone have info about that, and is it really a "gatweay" ? Bob Dixon Ohio State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020606312800> Received: from nrl-aic by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 11:14:50-PST Date: 6 Feb 1986 11:31:28 EST (Thu) From: Dan Hoey Subject: Re: Conversations with an Ethernet watcher To: mills@dcn6.ARPA Cc: tcp-ip@sri-nic.ARPA Message-Id: <508091488/hoey@nrl-aic> In-Reply-To: mills's message of 05-Feb-86 205022-UT Date: 05-Feb-86 20:50:22-UT From: mills@dcn6.arpa ... 7. Fairness abusers. Why do some hosts (10.2.0.78, among others) open multiple parallel SMTP connections to the same host? Maybe for the same reason they open multiple TELNET connections--when a user wants to send a message, I see no reason why the system must queue it until any current traffic to the destination host is past. Certainly the ability to queue is useful, but hardly required. Of course, it could just be that they restarted after giving up on a catatonic SMTP connection, and they couldn't wake up the corpse enough to kill it. Dan Hoey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020606520000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 14:59:34-PST Date: 6 Feb 86 14:52:00 PST From: Subject: DBridge To: "ts0400%ohstvma.bitnet" cc: tcp-ip@sri-nic Reply-To: > A telephone call to London revealed that the VMS tcp-ip software mentioned > here recently by Pierre is in fact the Wollongong software, exported to > England. They refer all US inquiries to Wollongong. Th > > However, I am still interested in the DECnet gateway called Dbridge. > Does anyone have info about that, and is it really a "gatweay" ? DBridge is part of the Wollongong package. This is a VMS process which opens a Decnet circuit to another DBridge process across the Decnet. The DBridge process uses a raw socket to pass IP datagrams to/from the local TCP/IP kernel and forward them across the Decnet. This allows a TCP/IP network to be layered on top of a Decnet. If one of the TCP/IP nodes is connected to a real IP network, it can route IP datagrams to/from that network. Art@ACC.ARPA ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020610090000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Fri 7 Feb 86 00:31:25-PST Received: from northeastern by csnet-relay.csnet id ae03510; 7 Feb 86 3:32 EST Date: Thu, 6 Feb 86 14:09 EDT From: Chris Johnson To: tcp-ip@sri-nic.arpa, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: Mystic words and phrases. Hi. All languages have a set of common words which most people use in every day speech. Then there are various subset for technical fields. Networking is no exception to this. Because or in spite of much use of certain phrases there also arises abbreviated forms and shortcuts. I'm usually the first to admit that my ignorance is rife. In this case it's about time I got some enlightenment. The two specialized terms I am currently having trouble with are: 1) EGP and 2) fuzzball I think I understand them from much context hunting but am not sure. I don't have ARPA network stuff here and was wondering if someone out there in the big wide universe would enlighten me as to the true meaning of these terms. Please remember that not everyone who listens to this list is always in tune. It would be nice if now and then and abbreviation was expanded. Thank you. peace, Chris Johnson johnson@northeastern (CSNet) johnson%northeastern@csnet-relay (ARPAnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020612445800> Received: from proteon.arpa by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 14:48:26-PST Date: Thu, 6 Feb 86 17:44:58 EST From: jas@proteon.arpa Subject: Re: GEC Software In-reply-to: Your message of Thu, 06 Feb 86 10:11:59 EDT To: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU (Bob Dixon) CC: tcp-ip@sri-nic.arpa DBridge is not a protocol translator. It is a facility to tranport IP packets over the DECnet transport facilities. What you get in ISO layers is TCP 7 6 5 4 3 TCP 2 (IP) DECnet 4 3 2 DECnet 1 Thus you get to use the web of DECnet point-to-point facilities and long-haul stuff to move IP packets around. Same idea as IP over X.25. John Shriver Proteon ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020613353300> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 15:36:40-PST Date: 6 Feb 1986 18:35:33 EST From: MILLS@USC-ISID.ARPA Subject: Re: DOWN WITH DUMB GATEWAYS! To: louden@MITRE-GATEWAY.ARPA, ron@BRL.ARPA cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA In response to the message sent 6 Feb 1986 8:39:25 EST (Thursday) from louden@mitre-gateway.arpa Mike, In BBN's defense, remember that the LSI-11 gateways were evolved way beyond reasonable conjecture from the first design, include protocol support (EGP and VAN) unanticipated in the original design and are deployed in much greater numbers of gateways and networks than are reasonable with this design. The Buttergates were evolved precisely in response to many of the existing problems and, assuming money to pay for them is found, should eventually overtake the LSI-11s. The presence of apparent routing loops in updates received from the core system is an expected consequence of the intrinsic GGP routing protocol used in the LSI-11 gateways for the last seven years. This protocol, as well as other similar protocols based on min-hop algorithms can for form transient loops when various nets bob up and down and the hop-count fields are "counted to infinity." The problem has been long recognized and has nothing intrinsically to do with EGP or even the particular implementation, but is an intrinsic problem with min-hop algorithms. The SPF algorithm developed for the ARPANET and adapted for the Buttergates should make these loops much less likely. You might speculate on what might happen if we did not have EGP and peered GGP directly with the core instead. Before we had EGP there was this incident that became enshrined in legend and called the Great Commando Raid. Someday either Mike Brescia or I will include that chuckle in our memoirs. The circumstances were funny enough and won't be repeated here; however, the result was a new packet type, called the Kiss of Death (KOD) packet, that killed the recipient, but not before forwarding the packet to the next victim. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020615214100> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 08:19:09-PST Date: 06-Feb-86 15:21:41-UT From: mills@dcn6.arpa Subject: Re: DOWN WITH DUMB GATEWAYS! To: T.MichaelLouden(MSW422), mills@dcn6, tcp-ip@sri-nic In-reply-to: Your message of 6 Feb 1986 10:12:41 EST (Thursday) Mike, Oop, you are absolutely right. My intent was to point out that ARPANET itself is legitimate to advertise on the part of both the core and non-core gateways sharing it. While RFC-904 specifies what a non-core gateway must do, there is no specification on what a core gateway must do; therefore, we can't beat up those villans for sending your net back to you. A reasonable sketch of a core- gateway specification might conclude that is, indeed, broken. My foo-paw was a thlip of the thongue. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020615544400> Received: from SUMEX-AIM.ARPA by SRI-NIC.ARPA with TCP; Fri 7 Feb 86 01:27:15-PST Date: Thu 6 Feb 86 23:54:44-PST From: Mark Crispin Subject: [jbn@Ford-wdl1.ARPA (John B. Nagle): FORD-SCF1 now under control] To: TCP-IP@SRI-NIC.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12181393816.8.MRC@PANDA> Another varmint bites the dust. Thanks JBN!!! --------------- Return-Path: <@SUMEX-AIM,@SU-SCORE.ARPA:jbn@Ford-wdl1.ARPA> Received: from SU-SCORE.ARPA by SUMEX-AIM.ARPA with TCP; Thu 6 Feb 86 14:04:19-PST Received: from FORD-WDL1.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Feb 86 13:46:26-PST Received: by FORD-WDL1.ARPA (5.15/5.9) id AA17695; Thu, 6 Feb 86 13:51:59 PST Date: Thu, 6 Feb 86 13:51:59 PST From: jbn@Ford-wdl1.ARPA (John B. Nagle) Message-Id: <8602062151.AA17695@FORD-WDL1.ARPA> To: MRC@su-score.arpa Subject: FORD-SCF1 now under control The mailer misbehavior at FORD-SCF1 has been taken care of. That machine had been accidentally set up with the Berkeley trailer kludge enabled, but the other end of the synchronous link was not set up for trailers, so little packets got through but big packets didn't. We've also changed the mailer retry interval from 1 minute to 30 minutes. This should fix the problem. John Nagle ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020617075000> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Fri 7 Feb 86 00:23:58-PST Date: Fri 7 Feb 86 00:07:50-MST From: Mark Crispin Subject: Re: Conversations with an Ethernet watcher To: mills@DCN6.ARPA cc: hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "mills@dcn6.arpa" of Thu 6 Feb 86 12:33:37-MST Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Telephone: +1 (415) 968-1052 Message-ID: <12181385277.10.MRC@SIMTEL20.ARPA> Add my voice to the clamor -- it is a bug or misfeature that Berkeley Unix has multiple simultaneous SMTP streams to the same host. SMTP is a batching type process and overall mailer throughput is more important than the small gains some messages may gain from multiple streams. It really nailed SUMEX badly that the nastygrams that hit its SMTP server came from a Berkeley Unix SMTP mailer. I tried opening multiple listeners (a listener just negotiates SYNs then hands the connection off to the server... normally a very fast task) and the damn host just went and grabbed the new listener! ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020619333700> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Thu 6 Feb 86 12:05:19-PST Date: 06-Feb-86 19:33:37-UT From: mills@dcn6.arpa Subject: Re: Conversations with an Ethernet watcher To: DanHoey, mills@dcn6.ARPA, tcp-ip@sri-nic.ARPA In-reply-to: Your message of 6 Feb 1986 11:31:28 EST (Thu) Dan, I will respond with the voice of Jack Haverty, longtime and intrepid Internet Engineer. If you really need to open n simultaneous connections, each with full complement of windows, buffers and whatnot, then we must provide sufficient buffering at all transit points for the aggregate of all such connections, even if only infrequently used. However, a little care in the engineering of the client software can result in major savings in total system cost. The multiple- connection scenario I reported yesterday persisted for most of the day, from which I infer either an unlikely multiplicity of users patiently waiting for many messages to barge through the swamps or the existance of multiple mailer daemons. The former are obviously patience-limited, so I don't worry overmuch about them; however, I do worry about the latter. Jack, who is usually more conservative than I, might toss off the following on an envelope while waiting for an airplane. The two 2048-octet windows on one machine and three 4096-octet windows on the other require up to 16K for buffering on transit systems. If comfortably tucked in 576-octet packets (536 data octets), something like 30 packets could be wandering around our gateway. A conservative might also observe from my observations that multiple ACKs are sometimes returned from the destination that an additional number (we'll call it 30) might be soaked up for traffic toward the source. However, those packets have to live in real buffer space, which with most hardware and software require a contiguous region of at least the MTU for the net, in the Ethernet case 1500 octets. Thus, our underpowered fuzzthing would have to cough up 60 1500-octet buffers, or 90K of memory just for those two hosts. See RFC-970 for an even less palatable scenario. The little dears only have about a fifth of that in the present configuration, from which Jack would conclude we should either pull the plug or convert to X.25. While Jack and I do kid each other mercilessly, you have to admit he has a point. The Internet Engineer cum Protocol Cop is seldom seen in these parts. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020703410000> Received: from bbnh by SRI-NIC.ARPA with TCP; Fri 7 Feb 86 05:49:44-PST Date: Fri, 7 Feb 86 8:41:00 EST From: Alex McKenzie Subject: DEC "LANBridge 100" To: tcp-ip@sri-nic.arpa Someone recently asked about the "Dbridge" and someone else answered that it was a piece of software. I don't know about that, but thought I'd add that there is a new DEC product called the "LANBridge 100" which is intended to interconnect two Ethernets. It learns (or can be told, I think) what Ethernet addresses are on its side "A". If it sees any Ethernet frames on the Ethernet on side A whose addresses aren't on this list, it copies the frames to the Ethernet on its side B. If it sees any Ethernet frames on side B whose addresses ARE in the list, it copies these to the Ethernet on side A. Thus, it is at ISO level 2, unlike an Ethernet repeater (a level 1 device) or an IP gateway (a level 3 device). I thought it might be possible that this device was intended in the question about the "Dbridge". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020708005300> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Fri 7 Feb 86 09:09:55-PST Received: from (MAILER)OHSTVMA.BITNET by WISCVM.WISC.EDU on 02/07/86 at 11:08:58 CST Return-path: TS0400%OHSTVMA.BITNET@WISCVM.ARPA Received: by OHSTVMA (Mailer X1.21) id 8342; Fri, 07 Feb 86 12:08:12 EDT Date: Fri, 07 Feb 86 12:00:53 EDT From: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU (Bob Dixon) To: IBM-NETS%BITNIC.BITNET@WISCVM.WISC.EDU , TCP-IP@SRI-NIC.ARPA Subject: Ethernet/T1 bridges We have need for devices that will interconnect distant (few miles) ethernets via T1 links, and which have enough intelligence to send only the needed traffic. All protocols must pass transparently. We have heard that Vitalink makes such a box, but have been unable to get any details as yet. Also Applitek can do this, but it takes 2 boxes in series at each end, which doubles the cost. Does anyone know of other options? Another alternative is to use something like the DEC Lan bridge for the intelligence, and then some simpler box for just Ethernet/T1 connection. But we have been unable to locate such a box. Anyone know of any? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020708033000> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Fri 7 Feb 86 10:03:56-PST Date: 7 Feb 1986 13:03:30 EST From: MILLS@USC-ISID.ARPA Subject: Re: Mystic words and phrases. To: JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA, To: tcp-ip@SRI-NIC.ARPA cc: MILLS@USC-ISID.ARPA In response to the message sent Thu, 6 Feb 86 14:09 EDT from JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA Chris, You're right, and I apologize for thinking everybody has a psionic tap on the Old Boy Network (resisting heroically the urge to pun that one). EGP stands for the Exterior Gateway Protocol, which is used to exchange information between gateways and is described in RFC-904. As for the fuzzballs, he bleats sheepishly, they are a bunch of frisky PDP11-compatible workstations used by some of us to develop, test and evaluate new protocols and nets. See for reference "The Empire Strikes Back," in which "fuzzball" is mentioned in the dialog. In point of fact, the fuzz predate the movie. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020717210000> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Fri 7 Feb 86 23:24:15-PST Date: Sat, 8 Feb 1986 00:21 MST Message-ID: From: "Frank J. Wancho" To: TCP-IP@SRI-NIC.ARPA cc: WANCHO@SIMTEL20.ARPA Subject: TCP/IP via X.25 connection to DDN Please tell me I'm wrong... Last I heard, if a site runs TCP/IP through an X.25 interface to an IMP, it can talk only to other X.25 sites. Is this (still) true? --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020817521500> Received: from ngp.UTEXAS.EDU by SRI-NIC.ARPA with TCP; Sat 8 Feb 86 22:10:29-PST Date: Sat, 8 Feb 86 23:52:15 cst From: rick@ngp.UTEXAS.EDU (Rick Watson) Posted-Date: Sat, 8 Feb 86 23:52:15 cst Message-Id: <8602090552.AA15026@ngp.UTEXAS.EDU> Received: by ngp.UTEXAS.EDU (4.22/4.22) id AA15026; Sat, 8 Feb 86 23:52:15 cst To: TCP-IP@SRI-NIC.ARPA, TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU Subject: Re: GEC Software Cc: rick@ngp.UTEXAS.EDU Dbridge is a Wollongong product that allows you to transport IP packets over a DECnet connection. It connects 2 hosts running (Wollongong) TCP/IP. It uses DECnet for the transport layer. It does no gatewaying between DECnet and TCP/IP. The DEC Lan Bridge 100 is an ethernet level gateway. It also does no protocol translation. DEC's DECnet for Ultrix is supposed to do some kind of DECnet to TCP gatewaying, but I don't know what yet. I have this software on order, so I'll let you know what it does when I get it. Rick Watson University of Texas Computation Center arpa: rick@ngp.UTEXAS.EDU rick@ngp.ARPA uucp: ...seismo!ut-sally!ut-ngp!rick rick@ut-ngp.UUCP bitnet: ccaw001@utadnx phone: 512/471-3241 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020818070000> Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU) by SRI-NIC.ARPA with TCP; Sat 8 Feb 86 20:07:19-PST Date: Sat, 8 Feb 1986 23:07 EST Message-ID: Sender: GZT.TDF%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU From: "David D. Story" To: Chris Johnson Cc: tcp-ip@SRI-NIC.ARPA Subject: Mystic words and phrases. Phase-Of-The-Moon: NM+5H.37M.25S. In-reply-to: Msg of 6 Feb 1986 13:09-EST from Chris Johnson 1) Electronic Graphics Printer 2) IBM selectric style ball (letter quality) or 1) A sixth sense that always means trouble. 2) A spitball but with Newsprint. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020907340000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Sun 9 Feb 86 09:35:16-PST Date: 9 Feb 1986 12:34-EST Sender: CERF@USC-ISI.ARPA Subject: Re: TCP/IP via X.25 connection to DDN From: CERF@USC-ISI.ARPA To: WANCHO@SIMTEL20.ARPA Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA] 9-Feb-86 12:34:38.CERF> In-Reply-To: Frank, Last I hear, BBN had succeeded in figuring out how to make the X.25 interfaces and the 1822 interfaces interoperate - whether this code is in the operational network, however, I am not sure about. I hope you are wrong but your statement was, at one time in the past, true, and may still be. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020914235200> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Mon 10 Feb 86 19:31:01-PST Date: 9 Feb 1986 19:23:52 EST Sender: POSTEL@USC-ISIB.ARPA From: CLAUSEN@USC-ISID.ARPA Subject: hello To: TCP-IP@SRI-NIC.ARPA cc: clausen%UKans@CSNET-RELAY.ARPA Folks, I want to use a Microvax as a "front-end" for our 750 running Unix B4.2 and one of the ACC interfaces. Do you know of anybody who has a Microvax (q-bus!) with an ACC interface and 4.2 with the IP/TCP software running? --Horst ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020915532600> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Sun 9 Feb 86 17:53:09-PST Date: Sun 9 Feb 86 20:53:26-EST From: "J. Noel Chiappa" Subject: Re: Ethernet/T1 bridges To: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU, IBM-NETS%BITNIC.BITNET@WISCVM.WISC.EDU, TCP-IP@SRI-NIC.ARPA cc: JNC@XX.LCS.MIT.EDU In-Reply-To: Message from "TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU (Bob Dixon)" of Fri 7 Feb 86 13:26:59-EST Message-ID: <12182114473.18.JNC@XX.LCS.MIT.EDU> I will point out to everyone (once again) that bridges have severe technical disadvantages, especially in a system which is intended to be connected to the main internet. Now, you should take my words with a grain of salt, because I have a financial interest in seeing people use routers (aka 'IP gateways') instead of filtering digital repeaters ('bridges'), but I was saying this for years before I got involved with a product. I don't want to conduct a technical discussion on this (large) mailing list; if you don't believe me, retrieve (via anonymous FTP) the file BRIDGES.TXT from MIT-XX; it contains an earlier discussion on this issue. See BRIDGES.LOSE for an example of a user of bridges losing big. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020916090000> Received: from ddn1 by SRI-NIC.ARPA with TCP; Sun 9 Feb 86 19:19:20-PST Date: 9 Feb 86 21:09 EST From: Corrigan @ DDN1.ARPA Subject: Re: TCP/IP via X.25 connection to DDN To: WANCHO @ simtel20.arpa CC: TCP-IP @ sri-nic.arpa, WANCHO @ simtel20.arpa Interoperation of TCP/IP users using 1822 and X.25 interfaces is first supported in Packet Switch release 6.0. We are currently fielding this release as required (namely at nodes with x.25 subscribers) in the MILNET. We will be fielding it as the standard release in the MILNET in the next few months. We will also field it in the ARPANET as soon as possible. The holdup there is upgrading all the switches to the C-30e configuration. This should also be completed in the next few months. Mike Corrigan Technical Manager DDN ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986020917272900> Received: from BBNCC5.ARPA by SRI-NIC.ARPA with TCP; Sun 9 Feb 86 19:32:41-PST To: "Frank J. Wancho" cc: TCP-IP@sri-nic.ARPA Subject: Re: TCP/IP via X.25 connection to DDN In-reply-to: Your message of Sat, 8 Feb 1986 00:21 MST. Date: 09 Feb 86 22:27:29 EST (Sun) From: Frederick E Serr Interoperability between X.25 and 1822 hosts is implemented in Release 6 of the PSN software. Unfortunately, the ARPANET is still running the equivalent of PSN Release 4. The hardware on the network is currently being upgraded to allow installation of PSN 5. I don't know the official schedule, but I would guess that PSN 5 will go in sometime in March, and you won't see PSN 6 until a couple of months after that. Until that time, hosts with X.25 interfaces on the ARPANET cannot talk to 1822 hosts. --Fred ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021000230000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Mon 10 Feb 86 08:39:35-PST Date: 10 Feb 86 08:23:00 PST From: Subject: TCP/IP via X.25 To: "wancho" cc: tcp-ip@sri-nic Reply-To: Frank, The X.25 connection you mentioned in your 8 February message describes, what is known as "Basic Mode" DDN X.25. Although TCP/IP is used for such things as data integrity, 'Basic Mode' service provides communication only between a X.25 DTE and other X.25 DTE's. Specifically, only a X.25 Host can communicate with another X.25 Host on the DDN. As DCA has mandated that all host be interoperable with each other another form of X.25 has been devised which is called "Standard Mode". This is to allow hosts which have been previously connected to the net, either with 1822 or 1822-J (HDH) connections, to communicate with X.25 hosts. TCP/IP is used as the upper-level protocols to provide continuity and full interoperablity. As you may or may not know, DCA is in the process of qualifying various vendors implementations of the DDN X.25 specification. It is important for user evaluation to determine if the vendor has a fully qualified product in accordance with the test scenarios of the DDN X.25 Standard Service for achieving full interoperability. For additional information contact the NIC and request the circular entitled: "Defense Data Network X.25 Host Interface Specification, December 1983. Sincerely, Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021001582400> Received: from nswc-wo.ARPA by SRI-NIC.ARPA with TCP; Mon 10 Feb 86 03:59:26-PST Date: Mon, 10 Feb 86 06:58:24 est From: rsparbe@nswc-wo.ARPA To: tcp-ip@sri-nic Subject: Inter operable X.25 Could someone tell me if the problem I am having with sending mail to one site could be related to the HDH/X.25 inter operability issue. We run a HDH and 1822 hosts. The other sites have X.25 connections. We cannot send mail to each other. I know there could be many different problems, but is it possible the problem relates to the release 5.0 software running on the net not allowing HDH/X.25 inter operability? Please answer direct to me at rsparbe@nswc-wo. Thanks Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021003110000> Received: from hydra.ARPA (RIACS-HYDRA.ARPA) by SRI-NIC.ARPA with TCP; Mon 10 Feb 86 11:15:17-PST From: Barry Leiner Message-Id: <8602101911.AA16750@hydra.ARPA> Received: by hydra.ARPA (4.12/4.01) Mon, 10 Feb 86 11:11:40 pst Date: 10 Feb 1986 1111-PST (Monday) To: "Frank J. Wancho" Cc: WANCHO@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: TCP/IP via X.25 connection to DDN In-Reply-To: Your message of Sat, 8 Feb 1986 00:21 MST. Someone from DDN or BBN should respond directly, but let me state what I believe to be the case. There are two types of X.25 interface to the Milnet/DDN. The first, which was put in place first, was called Basic (for some obscure reason) and the second called Standard. Not sure if those are still the names. The Basic interface is an X.25 end to end service, and was put in place to support hosts that talk only X.25. This is supposed to be a "temporary" interface, as all hosts are eventually supposed to use TCP/IP. The STandard interface is an X.25 interface to the DDN, on top of which hosts are to run TCP/IP. My understanding is that, for this interface, X.25 is terminated in the local imp, and therefore should be interoperable with other local interfaces, in particular 1822. Barry ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021005573800> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Mon 10 Feb 86 07:06:11-PST Received: from (MAILER)OHSTVMA.BITNET by WISCVM.WISC.EDU on 02/10/86 at 09:05:07 CST Return-path: TS0400%OHSTVMA.BITNET@WISCVM.ARPA Received: by OHSTVMA (Mailer X1.21) id 6246; Mon, 10 Feb 86 10:03:09 EDT Date: Mon, 10 Feb 86 09:57:38 EDT From: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU (Bob Dixon) To: RICK@NGP.UTEXAS.EDU cc: TCP-IP@SRI-NIC.ARPA , TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU Subject: Re: GEC Software In-Reply-To: rick AT ngp.UTEXAS.EDU -- Sat, 8 Feb 86 23:52:15 cst Thanks for the info, Rick. The word I got from DEC regarding Ultrix (after intense questionning) is that it supports tcp/ip and DECnet, but does not provide any gateway function. We urged them to provide such a gateway and even offered to contract with them to do so, but they said there is not enough market for it, and it is contrary to company policy. Their policy is to offer token support to tcp/ip via selling things like Wollongong and Ultrix, but to expend no real effort on tcp/ip. Instead they are aiming for migtation to future ISO standards, bypassing tcp/ip. If you get any word to the contrary, I'd be anxious to hear it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021009143700> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Mon 10 Feb 86 17:16:08-PST Date: 10 Feb 1986 17:14:37 PST Subject: SXecurity and Precedence Options From: Dan Lynch To: tcp-ip@SRI-NIC.ARPA cc: LYNCH@USC-ISIB.ARPA Does anyone know of any implementations of those options? I realize that the "nodes" "IMPS" in such a network would also have to properly implement those options (or support them somehow). Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021010040000> Mail-From: STJOHNS created at 10-Feb-86 18:05:32 Date: 10 Feb 1986 18:04-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: SXecurity and Precedence Options From: STJOHNS@SRI-NIC.ARPA To: LYNCH@USC-ISIB.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]10-Feb-86 18:04:51.STJOHNS> In-Reply-To: The message of 10 Feb 1986 17:14:37 PST from Dan Lynch Please note: There is a revised version of the IP security option. The IP option as detailed in the IP RFC and the IP MIL STD is "officially" defunct. To answer your question, the only implementation I know of which uses any form of security option is at the 1ISG at the Pentagon on their Multics systems. Contact Housley%his-phoenix-multics@cisl-service-multics.arpa for details. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021100200000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Tue 11 Feb 86 08:38:20-PST Date: 11 Feb 86 08:20:00 PST From: Subject: uVAX interface To: "clausen" cc: tcp-ip@sri-nic Reply-To: Horst, ACC's interface for a uVAX, termed the ACP 5250, is being shipped to our beta-site this week. We are anticipating DDN qualification for standard mode operation within the next 2-3 weeks. The first implementation will support a VMS device driver which will be integrated into the Internet TCP/IP package. We are anticipating that support will follow in fairly short order for Wollongong's package, 4.2 and 4.3, and Ultrix. A good lead time for ordering purposes would be 60 days ARO, to allow for the above to take place. Hope this helps. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021102093100> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Tue 11 Feb 86 06:11:02-PST Date: 11 Feb 1986 08:09:31 CST Subject: Removal from mailing list From: DDN-REQT@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA cc: DDN-REQT@GUNTER-ADAM.ARPA, DDN-REQT@GUNTER-ADAM.ARPA Please remove DDN-REQT@GUNTER-ADAM FROfrom the tcp-ip mailing list. thanks, Link Verstegen ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021107113900> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Tue 11 Feb 86 09:12:37-PST Date: 11 Feb 1986 12:11:39 EST From: PADLIPSKY@USC-ISI.ARPA Subject: Tails and Dogs To: tcp-ip@SRI-NIC.ARPA Feeling that I owe myself one indulgence for not flaming about the recent rash of unexpanded alien acronyms ("TOP" and [shudder] "MAP"), I fear I've got to risk taking on Dave Mills (and perhaps the spirit of Jack Haverty, though I hope and trust not) on what I take to be a rather pernicious implication: Loath as I am to be cruel to fuzzballs--not only on cruelty to animals grounds but also out of respect for their/their person's ability to bite back-- and with some trepidation that I've misconstrued the relevant cryptomillsisms, if Dave really thinks there should be limitations imposed on logical constructs ("connections," whether SMTP or other) to cater to the shortcomings of physical constructs (gateways, whether fuzzy or other), then he seems to be to be letting the tail wag the dog. In the first place, aren't gateways fundamentally supposed to be "receive and forward" devices? If so, what's the fuss about consuming their buffers? In the second place, if line speeds preclude rapid enough forwarding after receipt, isn't this a "virtual comm subnet" problem of the "congestion control" kind? If so, why should it be solved by imposing constraints on Hosts other than through an appropriate, real, called-for for years congestion control mechanism? In other words, the Hosts should worry about how many connections they need/want and how much data they can accept over them, and "the net" (all flavors of gateway and all flavors of comm subnet) should worry about getting bits from Host to Host. (And if some Hosts "abuse" the net by demanding character-at-a-time traffic, let 'em--but charge by the kilo- packet, not the mega-bit.) In those thrilling days of yesteryear, Multics caused the TIPs to crash by sending out full-ALL-field's-worths-of-one-bits in NCP's flow control mechanism (something about they couldn't afford the table space, assumed nobody would ever send a full allocation, wound up clobbering the adjacent field...): I played along then, in the spirit of "all pioneers together," and made the NCP send small enough ALLs for them to handle, even though Multics was perfectly happy to accept however many bits it was--but that was some 15 years ago! "Great Wheel of Reincarnation" notwithstanding, can't we solve the problems where the problems are yet? cheers, map P.S. In my longhand draft of this, I was going to take issue with the notion that 2 or 4 K "octet" windows are too large, but it seems like gilding the ragweed compared to the more abstract issue of rendering unto the Hosts that which is the Hosts' and unto the net that which is the net's. It's not just an issue of whether SMTP should be barred from using multiple TCP connections, though. (To the same Host, of course; presumably even the greatest friend of fuzzies wouldn't argue that we should force mail through "post office" sorts of things over single connections with small windows just to ease the strain on the gateways, when many Hosts are involved.) Windows are and should be, in my humble but dogmatic opinion, Host artifacts which pertain to Host-Host flow control; employing them in lieu of a congestion control mechanism at least violates Layering and at best is a bad hack. P.P.S. Apologies for any cryptomapisms herein, it's just that even if I were up to a fully-"tutorial" treatment--which I'm not--it doesn't seem worthwhile to burden everybody with all those bytes, however many connections they go over and however small the windows are thought to have to be. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021108360000> Received: from A.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Tue 11 Feb 86 10:50:45-PST Date: 11 Feb 86 13:36 EST From: Rudy.Nedved@A.CS.CMU.EDU To: PADLIPSKY@USC-ISI.ARPA Subject: Re: Tails and Dogs CC: tcp-ip@SRI-NIC.ARPA In-Reply-To: "PADLIPSKY@USC-ISI.ARPA's message of 11 Feb 86 12:11-EST" Message-Id: <11Feb86.133608.EN0C@A.CS.CMU.EDU> I have yet to hear a solid definition that is not disputed by someone for the terms "gateway", "router", "repeater" and "bridge". I don't believe a gateway simply forwards packets nor do I believe the software in a gateway can be simply stated in a paragraph or less of writing. This is based on CMU's and the ARPA Internet's crazy internet and the myriad of different pieces and functions (everything from 1200 async lines to x.25 virtual circuit lines to satellite links to multichannel broadband networks). Anyhow, the issue is not a congestion one. If you look out your window during rush hour, can you imagine some kinda of congestion control mechanism that will gracefully deal with the problem? I can't but trying to stagger network connections is a big help just like some companies encourage or command employees to show up at different times to help rush hour traffic. Of course, to certain degree rush hour traffic is impossible to solve, just like around CMU we have rush hour printing and mail time at 430 (everyone is trying to do last minute work they put off all day) and then people wonder why their mail has not arrived by 5pm. The concept that a mail delivery system creates a process and connection for each recipient or each host at the same time has got to be a burden on the local system if the mail list is huge. At some point it has to queue things or disaster will strike. Of course I agree that the gateways should shutdown a connection if attempts to limit the load fail since that may be the only way to encourage software builders and maintainers to not abuse resources. Anyone who does not practice software engineering or "using current resources with an eye toward the future" and instead practices the "infinite resource" design concept is going to make the users real sorry (of course the guy has left by then and is doing a research project in another company). -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021111180600> Received: from OFFICE-1.ARPA by SRI-NIC.ARPA with TCP; Tue 11 Feb 86 16:27:02-PST Date: 11 FEB 86 16:18:06 From: {ATE.R/CHESTNUT}ONTYME@OFFICE-1 Reply-to: rc.tym@office-1.arpa Subject: Heterogeneous net To: tcp-ip@sri-nic Message-ID: At our location we are planning to (finally) install Ethernet which will connect several machines: 2 vintage VAX-750, a MicroVAX-II, a TI-Explorer, several SUN systems, as well as a few assorted IBM-PC/XT and ATs. We would like to be able to access files on other machines, print on the few laser printers (on the MicroVAX and one SUN), and support remote log-in as much as possible. We are currently gathering information from various vendors but would appreciate any words of wisdom or benefits of experience from the rest of the world. How can the various joys of NFS, TELNET, DECNET, not to mention naked TCP IP be combined? Any responses by phone will also be appreciated: (408) 446-6553 Ron Chestnut ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021119212300> Received: from sri-spam.arpa by SRI-NIC.ARPA with TCP; Wed 12 Feb 86 03:21:31-PST Received: from localhost by sri-spam.arpa (5.4/4.16) id AA07324; Wed, 12 Feb 86 03:21:25 PST Message-Id: <8602121121.AA07324@sri-spam.arpa> Date: 12 Feb 86 03:21:23 PST (Wed) To: tcp-ip@sri-nic.ARPA Subject: 4.2bsd routing strategy for multihomed host From: gds@sri-spam I had a vax running 4.2bsd BBN TCP/IP on our local ethernet, however recently it has acquired an ACC and is attached to an IMP also. Well, today I was looking at our routing tables and playing around with opening connections from other hosts on other networks, and was wondering if my current routing strategy is correct. Since my vax was only on an ethernet, my /etc/gateways file reflects all the other networks as being relative to our arpanet-ethernet gateway. I took a look on another vax (lll-crg) to see what its routing tables and /etc/gateways file look like, and they list all the networks and their associated gateways. It looked to me as if all the reachable networks were in their routing tables also. What I did was to make the arpanet half of the arpanet-ethernet gateway my default gateway, so that when I don't know how to get somewhere directly, I get a redirect from the arpanet-half telling me where to go. I don't have very many entries in my routing tables (perhaps that is because a lot of sites don't connect to us). At any rate, I was wondering if my strategy is correct. To me, it seems that if I can use a smart gateway to tell me where to go, it saves me the trouble of knowing what all the gateways to the reachable networks are. However I am not sure about the side-effects of using a smart gateway -- I have pinged out my gateway on numerous occasions, plus our IMP (107) occasionally goes out of service and needs to be reloaded. For the record, the vax is sri-joyce, usually on 192.5.38.2, and temporarily on 10.2.0.107. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021201282300> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Wed 12 Feb 86 05:31:32-PST Date: 12 Feb 1986 07:28:23 CST Subject: Re: TCP/IP via X.25 connection to DDN From: DDN-REQT@GUNTER-ADAM.ARPA To: "Frank J. Wancho" cc: TCP-IP@SRI-NIC.ARPA, DDN-REQT@GUNTER-ADAM.ARPA In-Reply-To: You'rree NOT wrongf! However, PSN Release 6.0 will allow X.25 /w/TCP-IP to talk to 1822 w/TCP-IP. I don't have a schedule for release of 6.0. Regards Darrel B. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021214493400> Received: from merlin.Purdue.EDU by SRI-NIC.ARPA with TCP; Wed 12 Feb 86 17:14:23-PST Message-Id: <8602130049.AA22457@merlin.Purdue.EDU> Received: by merlin.Purdue.EDU; Wed, 12 Feb 86 19:49:37 EST To: gds@sri-spam.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: 4.2bsd routing strategy for multihomed host In-Reply-To: Your message of 12 Feb 86 03:21:23 PST (Wed). <8602121121.AA07324@sri-spam.arpa> Date: 12 Feb 86 19:49:34 EST (Wed) From: "Thomas Narten" We also have one connection to the Internet, but we have several local nets as well. We have a dedicated gateway (taliesyn) that is connected to an ARPANET IMP. We run routed on all our machines, our /etc/gateways are set up so that the ONLY entry in it is for a default route to taliesyn. We do this only for all machines that are on the SAME LAN as taliesyn. All other machines have an empty /etc/gateway's file. They pick up a default route through one of the machines on the same network as taliesyn. The nice thing about this is that there are no static routes. The default route (which you might say is static) is only used as a last resort. If taliesyn is down, the route is bogus, but you are cut off from the Internet so it doesn't matter. The other routes that get exchanged are for the local nets of which there aren't that many. Thomas ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021218373000> Received: from UTAH-20.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 00:38:55-PST Date: Thu 13 Feb 86 01:37:30-MST From: Jay Lepreau Subject: Re: Conversations with an Ethernet watcher To: mills@DCN6.ARPA cc: hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "mills@dcn6.arpa" of Thu 6 Feb 86 18:41:56-MST Message-ID: <12182974464.6.LEPREAU@UTAH-20.ARPA> Re multiple SMTP connections: what do you want, a hung connection to one host "forever" to prevent any further connections to that host? Personally, I don't. To further abuse the highway analogy-- if I send a car out to deliver something and it doesn't arrive, it could be caught in rush hour traffic but it could also have had an accident. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021222291100> Received: from BRL-AOS.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 00:35:00-PST Date: Thu, 13 Feb 86 3:29:11 EST From: Ron Natalie To: tcp-ip@sri-nic.ARPA Subject: IPTO-FACTO Does anyone know why the IPTO gateway on ARPANET is sending ICMP redirects to my MILNET hosts? -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021300140000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 02:14:39-PST Date: 13 Feb 1986 05:14-EST Sender: CERF@USC-ISI.ARPA Subject: Re: Tails and Dogs From: CERF@USC-ISI.ARPA To: PADLIPSKY@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]13-Feb-86 05:14:10.CERF> In-Reply-To: The message of 11 Feb 1986 12:11:39 EST from PADLIPSKY@USC-ISI.ARPA One of the wonderful things about layered architectures is that they have a tendency to result in resource allocation problems in each layer. Generally, the solution to the resource allocation problem at one layer (congestion control, flow control, Receiver not Ready ....) does nothing for the resource allocation problem at some other layer. As a consequence, we seem to relearn now and then that we have to invent resource allocation strategies for each layer to use to protect its resources. The methods may vary from layer to layer, of course, depending on the functionality of the layer, the freedom it may have to discard information (or lack of freedom to do so), etc. The best example I can think of is in a packet net - there may be end to end flow control above the network layer (e.g TCP) and flow control on the access link (e.g. HDLC), but the network needs internal (end/end) flow control to avoid lockups and store/forward congestion control to deal with trunking/tandem resource limits. The biggest challenge in communication system design is recognizing all these various limitations and figuring out a constellation of resource allocation strategies which are consistent and which can yield high performance. Usually, this requires that one look at the problem at all (or at least, several) layers at once and not focus solely on one layer and hope that solving its problems will solve all of them - it will simply move the place where congestion occurs to someplace else... like a balloon filled with water; you squeeze here and it pops out there. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021300250000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 02:26:42-PST Date: 13 Feb 1986 05:25-EST Sender: CERF@USC-ISI.ARPA Subject: Re: hello From: CERF@USC-ISI.ARPA To: CLAUSEN@USC-ISID.ARPA Cc: TCP-IP@SRI-NIC.ARPA, clausen%UKans@CSNET-RELAY.ARPA Message-ID: <[USC-ISI.ARPA]13-Feb-86 05:25:29.CERF> In-Reply-To: The message of 9 Feb 1986 19:23:52 EST from CLAUSEN@USC-ISID.ARPA Horst, I see you got a fairly positive answer already on your question - nice having all those hundreds of people to query! Glad to see you back on the net. How is Kansas? Sigrid sends her best regards. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021305305400> Received: from monet.berkeley.edu by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 18:51:37-PST Received: by monet.berkeley.edu (5.44/1.8) id AA06964; Thu, 13 Feb 86 18:51:04 PST From: karels@monet.berkeley.edu (Mike Karels) Message-Id: <8602140251.AA06964@monet.berkeley.edu> To: mills@dcn6.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: Conversations with an Ethernet watcher In-Reply-To: Your message of 13 Feb 86 19:38:33 +0000 Date: Thu, 13 Feb 86 18:50:54 -0800 Dave, I was most tempted to flames by your first message in this series, but restrained myself to see what other reactions would be. Fortunately, others have beaten me to the punch. Concerning the Unix mailer (sendmail), though, I'd like to add an informational point. The major reason that multiple connections are made to a single destination host is that mail is not queued separately for each host. I have long wanted it to do so, and I believe that the program's author now agrees. My reasons have more to do with serializing the work when a major mail node has been down or unreachable than with easing the task of the gateways. If ucbvax is down for a day, innumerable connections are received from everywhere as soon as it comes up. Only by cutting off new connections when the machine overloads can it avoid disaster. However, the amount of work required to change sendmail's way of doing business is nontrivial, and I don't know who will take on such a problem. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021306480000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 15:11:28-PST Date: 13 Feb 86 14:48:00 PST From: Subject: HP 3000 support To: "sutter" cc: blumenthal@bbn-unix,tcp-ip@sri-nic Reply-To: Bob, You need to speak with Steve Blumenthal at BBN. They have an implementation for the HP 3000, that handles TCP/IP, user and server Telnet, user FTP, and unfortunately no SMTP support. It uses a INP as the interface to the network which will support either 1822 or HDH. Hope that helps, Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021309073000> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 17:09:26-PST Date: 13 Feb 1986 17:07:30 PST From: MOCKAPETRIS@USC-ISIB.ARPA Subject: Re: Conversations with an Ethernet watcher To: mills@DCN6.ARPA, Lepreau@UTAH-20.ARPA, hoey@NRL-AIC.ARPA, To: tcp-ip@SRI-NIC.ARPA cc: MOCKAPETRIS@USC-ISIB.ARPA In response to the message sent 13-Feb-86 19:38:33-UT from mills@dcn6.arpa Dave, At ISI we run a TOPS-20 mail receiver that uses separate subprocesses to receive mail on multiple simultaneous connections. The number of subprocesses is limited to 5, and a status program displays the number of subprocesses active plus the max which were ever needed simultaneously. Typical behavior is 0-3 subprocesses with open connections at any time, and it's a rare day which never sees a need for all 5. paul ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021310021800> Received: from ohio-state.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 12:54:14-PST Return-Path: Received: by ohio-state.ARPA (4.12/6.1.OSU-CIS) id AA22361; Thu, 13 Feb 86 15:02:18 est Date: Thu, 13 Feb 86 15:02:18 est From: Bob Sutterfield Message-Id: <8602132002.AA22361@ohio-state.ARPA> To: net.dcom@ohio-state.ARPA, net.lan@ohio-state.ARPA, net.mail@ohio-state.ARPA, net.wanted@ohio-state.ARPA, tcp-ip@sri-nic.arpa Subject: TCP/IP for HP-3000 We need to connect a VMS VAX (of which I am the System Manager) with a Hewlett-Packard 3000 series machine (of which the System Manager has no net access). Minimal service level will be dial-up mail, though the rest would be nice, too. It seems that our best bet will be to run TCP/IP on both. I've run QUERY on sri-nic and seen that there are several hosts listed as being HP-3000s. However, in "sri-nic:tcp-ip-implementations.txt" there is no mention of a TCP/IP implementation for the HP-3000. Where do I try next? Any other ideas? Thanks for your help... ----- Human: Bob Sutterfield Mail: sutter@osu-eddie.UUCP sutterfield-r%osu-20@osu-eddie.UUCP or: sutter@ohio-state.ARPA sutterfield-r%osu-20@ohio-state.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021314101100> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 19:51:55-PST Date: Thu, 13 Feb 86 19:10:11 EST From: Mike Muuss To: mills@dcn6.arpa cc: JayLepreau , mills@dcn6.arpa, hoey@nrl-aic.arpa, tcp-ip@sri-nic.arpa Subject: Network Mail Observations BRL machines processes lots of mail, and so does the CSNET-Relay, but with different patterns of usage. The busier BRL machines handle 200-1000 messages/day, but with an average of like 200 recipients/message, some local, many not. (Statistics here are aproximate, from memory from the last time I looked, half a year ago). To handle incoming mail, we permit two simultaneous SMTP servers; this seems fine. To handle outgoing mail, our busier machines run from 3 to 5 deliver processes. There are (strict) timeouts on all parts of the SMTP dialog (different timeouts at different stages), so that none of the delivery processes "hang up" for very long. This may have the occasional side effect of "ganging up" on some recipient host. If that host is also implementing a policy of limiting the number of inbound connections, then this can't ever get too bad. From hours of watching the SMTP dialogs (in a spare window), it seems to me that a lot of delivery time is spent engaged in the back-and-forth validation of the recipient addresses, one at a time. With the majority of our messages going to several people at any given site, and the very long round-trip times through the core during the daytime (RTT from MILNET in Maryland to ARPANET in California runs 3-12 seconds in the daytime), this is a non-trivial factor. For people at the end of low-bandwidth pipelines, the transmission of the data portion of the message tends to take most of the time. (We require a recipient host to accept data at a minimum rate of about 300 baud plus a constant, or we timeout the transmission). Overall, we feel that our mail system is pretty well balanced, and represents a significant, but reasonable, load on our systems. (If anybody cares, we run MMDF II and IIb on 4.2 and 4.3beta UNIX systems). The single biggest improvement for our mail traffic would probably come from better core gateway performance (jab jab). The next biggest improvement would come from additional bandwidth on our IMP (more trunks). And speaking of which, I heard a rumor that a recent (last 3-4 months) change to the IMPs changed the behavior of the IMPs w.r.t. traffic originating at the IMP -vs- through traffic. (To more strongly favor through traffic). On the face of it, this is probably the right thing to do for overall system optimization. However, we noticed a SERIOUS loss of available bandwidth, a loss which seems to have only partly been restored. Am I dreaming? Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021314440000> Received: from LOGICON.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 23:32:05-PST Date: 13 Feb 86 22:44 PST From: Jeff Makey To: TCP-IP@SRI-NIC.ARPA Cc: Makey@LOGICON.ARPA Subject: Choosing a gateway There are quite a few gateways between the ARPANET and the MILNET. What is a good strategy for choosing a gateway between two nets when more than one exists? It seems to me that some relevant factors are: (1) whether a gateway is up at the moment I want to use it; (2) how heavily a gateway is loaded; and (3) the distance (in terms of IMP hops) from my host to a gateway. How can my TCP/IP daemon evaluate these factors? Is there an RFC or some other available documentation that will answer these questions? :: Jeff Makey Makey@LOGICON.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021319383300> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 11:56:43-PST Date: 13-Feb-86 19:38:33-UT From: mills@dcn6.arpa Subject: Re: Conversations with an Ethernet watcher To: JayLepreau, mills@DCN6.ARPA, hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA In-reply-to: Your message of Thu 13 Feb 86 01:37:30-MST Jay, I don't want to prolong the agony more than the issue justifies, so subsequent bickering should probably be restricted between us. However, to your point: Each of your SMTP connections - one or more - should have a user timeout in any case, so that your concern more properly is represented by the question whether more than a single such connection can deliver the throughput required in the face of occasional (likely) temporary hangups. It's not hard to generate an engineering answer to this question, given the expected (or measured) incidence of hangup, timeout interval and so forth. Next, you compute the network bandwidth necessary to accomplish all the successful and not-so-successful transactions, then construct a requirements analysis, then procure the necessary bucks. When the last step fails you go back and try to make what you can afford work the best way it can, which was the point of my memo. I would be tickled pink to participate in an exercise designed to explore the scenario space of our present mail system. Can you (or anyone) at some "busy" site provide data on the number of SMTP agents active at any time, retransmission parameters, failure messages and all that stuff? Ed Cain of the Testing Task Force has been stirring that pot as well. I have rather extensive logs on our fuzzies, but the volume of mail traffic is underwhelming. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021402320100> Received: from orion.ARPA by SRI-NIC.ARPA with TCP; Fri 14 Feb 86 10:33:22-PST Received: by orion.ARPA (5.28/1.3) id AA09398; Fri, 14 Feb 86 10:32:04 PST Message-Id: <8602141832.AA09398@orion.ARPA> To: mills@dcn6.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: Killing time In-Reply-To: Your message of 14-Feb-86 07:37:08-UT. <8602140804.AA08879@ames.ARPA> Date: 14 Feb 86 10:32:01 PST (Fri) From: Milo S. Medin (NASA ARC Code ED) Very interesting Dave. I've got a few SUN's lying around, feel free to send the data to me, or point me to it on dcn9 (my account there still works). Thanks, Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021402461700> Received: from orion.ARPA by SRI-NIC.ARPA with TCP; Fri 14 Feb 86 10:49:19-PST Received: by orion.ARPA (5.28/1.3) id AA09512; Fri, 14 Feb 86 10:46:19 PST Message-Id: <8602141846.AA09512@orion.ARPA> To: "Milo S. Medin" (NASA ARC Code ED) Cc: mills@dcn6.arpa, tcp-ip@sri-nic.arpa Subject: Re: Killing time In-Reply-To: Your message of 14 Feb 86 10:32:01 PST (Fri). <8602141832.AA09398@orion.ARPA> Date: 14 Feb 86 10:46:17 PST (Fri) From: Milo S. Medin (NASA ARC Code ED) Sorry folks, hit the wrong type of reply, and it was too late to stop it when I realized what happened... Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021404484500> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 23:38:52-PST Date: 14-Feb-86 04:48:45-UT From: mills@dcn6.arpa Subject: Re: Confessions of an Ethernet watcher To: tcp-ip@sri-nic.arpa Mike, Mike and Paul, I'm finding this exchange highly informative, although it was certainly not my intent in starting this off to provoke flames or even warm gases. Whether any of us realized it or not, thorughout the spectrum from the TOPS-20s to the scruffy fuzzballs, we are building real networks, even if the nodes are mailer and femailer entities and the links are flaky transport-level connections. You guys and others here have raised issues of congestion, routing, flow control and fairness, not to mention multicasting and alternate-route fallback. Wonderful! This scenario is being studied by the Testing Task Force, chaired by Ed Cain of DCEC. Ed has been clamoring for hard data, which from your and my watches is available only by holographing our eyeballs. More reports like yours would be warmly welcomed. Especially useful are reports on mean aggregate traffic per day and per busiest hour, as well as typical and maximum simultaneous transport connections (for mailer and femailer separately). Of particular interest would be the strategy used in response to errors: requeueing interval and priority, dependency on type of error and position in the protocols stack. Hard data on the incidences of such errors, such as might be captured in the system log file, would be invaluable. It would also be useful to have a sketch of the queueing discipline, connection-service discipline and fairness principles, as well as a description of any special mechanisms for congestion and flow controls. I'm not sure I want to volunteer to manage the collection and distribution of such a trove, but I would be glad to tickle the discussion and contribute what interesting data I can collect. It is my view, as expressed in several fora, that the effort to collect this kind of information and construct an appropriate network-mail model is a legitimate research area which should be funded accordingly. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021405272800> Received: from BRL-SMOKE.ARPA by SRI-NIC.ARPA with TCP; Fri 14 Feb 86 07:34:00-PST Date: Fri, 14 Feb 86 10:27:28 EST From: Ron Natalie To: CERF@usc-isi.arpa cc: PADLIPSKY@usc-isi.arpa, tcp-ip@sri-nic.arpa Subject: Re: Tails and Dogs CERF: One of the wonderful things about layered architectures is that they have a tendency to result in resource allocation problems in each layer. Layered Architectures are like Onions. They're smelly and make you cry a lot. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021407370800> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 23:39:18-PST Date: 14-Feb-86 07:37:08-UT From: mills@dcn6.arpa Subject: Killing time To: tcp-ip@sri-nic.arpa Folks, It has been about six months since the series of experiments on Internet clock synchronization reported in RFC-756 et seq, so I thought you might enjoy a capsule description of a recent repeat of some of them. Some fascinating (at least to a slightly fractured bunch of us) phenomena seem to be oozing from the data which might have to wait detailed archeological excavation; however, some tidbits sticking from the murk are relishable in this note. The experiments involved sending datagrams between intrepid fuzzball DCN6 to each and every one of the 2135 hosts listed in the latest NIC file HOSTS.TXT. Three protocols were used, one with ICMP Timestamp messages, a second with the TIME protocol based on UDP and the third with the new NTP protocol, also based on UDP. Four messages in each of the three protocols were sent to each host and each reply recorded and processed to produce an offset estimate representing the difference, in milliseconds, between the clock at the target machine and the clock at DCN6. The DCN6 clock is synchronized using local-net protocols to within a few milliseconds of a WWVB radio clock, so for the purposes here its clock can be considered a reference standard. Before describinb the results of the experiments themselves, it might be of interest (says he coyly) to reflect on the health of the Internet innards in which these datagrams were digested. The following menus summarize the metabolic products of the three-course meal, which took over 24 hours and 25000 datagrams to swallow. ICMP Timestamp, UDP/NTP and UDP/TIME volleys were sent to each host one after the other, so that accurate comparisons could be made between them. If at least one valid reply was received for a protocol, the volley was recorded as successful; while, if not, the last received error message (if available) or "no response" was recorded. 2135 ICMP timestamp request sent 722 ICMP timestamp valid reply 72 ICMP invalid timestamp reply (marked unknown or invalid time) 170 ICMP host unreachable 111 ICMP net unreachable 11 ICMP time exceeded (probably a loop) 4 Local host down 1215 No response 2135 UDP/TIME request sent 229 UDP/TIME valid reply 4 UDP invalid packet format (echo host swapped ports) 161 ICMP host unreachable 114 ICMP net unreachable 433 ICMP port unreachable (TIME not implemented) 42 ICMP protocol unreachable (UDP not implemented) 11 ICMP time exceeded (probably a loop) 4 Local host down 1137 No response 2135 UDP/NTP request sent 24 UDP/NTP valid reply 178 ICMP host unreachable 115 ICMP net unreachable 521 ICMP port unreachable (NTP not implemented) 42 ICMP protocol unreachable (UDP not implemented) 10 ICMP time exceeded (probably a loop) 4 Local host down 1241 No response The most disturbing feature of the above is the astonishing incidence of black holes (no response). The scarred old warriors among us hate these things passionately, since they often result in long hours of snoop when something breaks. A little prying revealed that some number of these were the result of dropping an otherwise valid reply due to IP or UDP format or checksum problems at the sender. These provoke more deja vu than surprise, since similar bugs have been reported and re-reported in famous implementations for years. One inspired felon even returned all ICMP error messages with a runt ICMP header too short by four octets. I did manage to explain all the ICMP-time-exceeded and local-host-down complaints (except one) as originating in our swamp. Turning now to the valid sample population, it is apparent that the discipline of the truth-timetellers is somewhat better than last time - only one host was found nearly exactly one day off (sic) and two were found with blatently nonsense ICMP times. Taking just the 139 hosts (298 total replies) with samples from two or more of the three protocols, for example, reveals the following summary: Host Address ICMP NTP UDP Notes ------------------------------------------------------------------------- DCN6.ARPA [128.4.0.6] 0 -48 612 DCN-WWVB.ARPA [128.4.0.15] 1 -466 WWVB echo ETAM-ECHO.ARP [4.0.0.62] -3 105 -199 IP echo ISI-ECHO.ARPA [10.1.254.27] -6 26 -22 IP echo DCN5.ARPA [128.4.0.5] 7 -20 -168 DCN1.ARPA [128.4.0.1] -8 -35 -162 DCN8.ARPA [128.4.0.8] -21 -29 -514 GW.UMICH.EDU [35.1.1.1] -48 -7 -219 TANUM-ECHO.AR [4.0.0.64] -48 3528 -3718 IP echo WWV.UMICH.EDU [35.1.1.17] -58 -627 WWV echo FORD1.ARPA [128.5.0.1] 62 -6 -16 DCN-WWV.ARPA [128.4.0.14] -75 -11 WWV echo UMD1.UMD.EDU [128.8.0.1] 100 55 360 SATNET-ECHO.A [4.0.0.40] 277 180 703 IP echo GOONHILLY-ECH [4.0.0.63] 294 141 -3021 IP echo XYZZY.UMICH.E [35.1.1.3] -321 -315 -578 RAISTING-ECHO [4.0.0.77] 479 -12 -4821 IP echo ORNL-MSR.ARPA [26.3.0.41] 497 -915 STC.ARPA [128.16.9.9] -665 3 -2858 IP echo SALLY.UTEXAS. [10.2.0.62] -1478 -2542 AMES.ARPA [26.0.0.16] -1490 -1294 -1408 IPTO-FAX.ARPA [192.5.18.51] -1975 -2119 -1882 IPTO-ECHO.ARP [192.5.18.52] -2000 -627 UDP echo ORION.ARPA [192.12.49.2] 2074 914 1314 USC-OBERON.AR [10.0.0.121] 2484 932 ROCHESTER.ARP [10.0.0.15] 3633 2500 SCORPIO.THINK [192.5.104.195] 5196 4395 C.CS.UIUC.EDU [192.5.69.3] 5242 4568 MIT-MULTICS.A [10.0.0.6] -6606 -7651 BRAND.USC.EDU [192.5.10.61] 7887 6792 DWORKIN.USC.E [192.5.10.64] 8516 7306 GRANITE.ARPA [128.45.0.101] -10023 -10790 A.CS.UIUC.EDU [10.3.0.37] -10373 -10988 ICSC.UCI.EDU [192.5.19.3] 10414 9654 ICSD.UCI.EDU [192.5.19.4] 11184 12025 NETWOLF.UMD.E [128.8.1.13] -11498 -12204 COLUMBIA.EDU [10.3.0.89] -11868 -14486 NYU-CSD2.ARPA [192.5.15.132] -14138 -14036 DOCKMASTER.AR [26.0.0.57] -15842 -17585 DCN9.ARPA [128.4.0.9] -16860 -16866 -17677 NOSC-GUPPY.AR [128.49.0.3] -17211 -17908 TRANTOR.UMD.E [128.8.0.14] 17922 17938 16846 HI-MULTICS.AR [10.1.0.94] 21274 20242 TB.CC.CMU.EDU [128.2.253.34] 22848 24304 SU-SAFE.ARPA [36.44.0.193] 25114 25908 PATCH.ARPA [26.6.0.2] -26211 -27396 BBNCC5.ARPA [128.89.0.88] -27836 -32280 ATRP.MIT.EDU [18.85.0.3] 30453 29554 NPRDC-PACIFIC [192.5.65.2] -31432 -32233 TF.CC.CMU.EDU [128.2.253.38] 33023 34611 GARFIELD.COLU [128.59.16.2] -36358 -35630 TC.CC.CMU.EDU [128.2.253.35] 39542 40695 USGS2-MULTICS [26.0.0.69] -45500 -46397 B.CS.UIUC.EDU [192.5.69.2] -51185 -52065 CU-ARPA.CS.CO [10.3.0.96] -54810 -55610 ICSE.UCI.EDU [192.5.19.5] -58193 -59623 USC-ISIC.ARPA [10.0.0.52] -59430 -59212 TD.CC.CMU.EDU [128.2.253.36] 59699 60560 NPRDC.ARPA [26.3.0.3] 67029 64915 UCI.EDU [192.5.19.1] -70709 -71224 CIP3.UCI.EDU [192.5.19.8] -74679 -76161 SU-AIMVAX.ARP [36.45.0.193] 84666 83903 NYU-ACF5.ARPA [192.5.15.13] -88445 -91559 MERLIN.PURDUE [192.5.48.3] 88691 87860 MITRE-BEDFORD [26.3.0.66] 90742 90366 NS2.CS.UCL.AC [128.16.5.2] 97395 96411 MEDIA-LAB.ARP [18.85.0.2] 100189 99256 TE.CC.CMU.EDU [128.2.253.37] 107915 108221 CIP4.UCI.EDU [192.5.19.11] -109144 -109610 BLAYS.PURDUE. [128.10.2.7] 123395 119781 FAS.RI.CMU.ED [128.2.254.138] -129306 -130533 CAD.CS.CMU.ED [128.2.254.133] -134145 -135394 THEORY.CS.CMU [128.2.254.182] -137348 -138211 GANDALF.CS.CM [128.2.254.140] -139830 -140677 CIVE.RI.CMU.E [128.2.254.177] -139857 -140732 H.CS.CMU.EDU [128.2.254.156] -140138 -141135 SAM.CS.CMU.ED [128.2.254.181] -140886 -141504 K.CS.CMU.EDU [128.2.254.137] -143272 -144436 SENSOR.RI.CMU [128.2.254.147] -144797 -145883 SPEECH1.CS.CM [128.2.254.145] -145322 -146576 ME.RI.CMU.EDU [128.2.254.142] -145774 -146565 CIP.UCI.EDU [192.5.19.6] -146244 -146019 NYU-ACF2.ARPA [192.5.15.9] 146843 145399 C.CS.CMU.EDU [10.3.0.14] 149915 150837 IUS1.CS.CMU.E [128.2.254.128] -150642 -151298 VI.RI.CMU.EDU [128.2.254.158] -150781 -151567 SPICE.CS.CMU. [128.2.254.139] -151411 -152188 ARM.RI.CMU.ED [128.2.254.151] -152310 -153136 MAPS.CS.CMU.E [128.2.254.184] -152825 -153692 ISL1.RI.CMU.E [128.2.254.143] -154190 -155976 ML.RI.CMU.EDU [128.2.254.178] -155618 -156754 IUS2.CS.CMU.E [128.2.254.176] -157583 -158408 A.SEI.CMU.EDU [128.2.254.131] -158382 -159449 SU-MOJAVE.ARP [36.10.0.14] -162822 -163537 SPEECH2.CS.CM [128.2.254.179] -165127 -166118 SU-SONOMA.ARP [36.20.0.99] -167543 -167882 PT.CS.CMU.EDU [128.2.254.155] -198025 -198966 MITRE.ARPA [26.0.0.17] 201594 200484 NYU.ARPA [26.0.0.58] 207805 207160 SU-ARGUS.ARPA [36.9.0.10] -216438 -216367 ROVER.RI.CMU. [128.2.254.157] -218641 -219583 MIT-HERA.ARPA [18.58.0.3] -226707 -227641 MIT-APOLLO.AR [18.58.0.10] -233509 -234152 SU-HELENS.ARP [36.2.0.5] 241465 240527 MIT-DEMETER.A [18.58.0.4] -265113 -266357 MIT-APHRODITE [18.58.0.12] -265862 -266957 MIT-CASTOR.AR [18.71.0.5] -267411 -268406 MIT-ATLAS.ARP [18.58.0.15] -268763 -269762 MIT-HELEN.ARP [18.71.0.11] -269498 -270900 MIT-HECTOR.AR [18.71.0.13] -275008 -275890 MIT-THESEUS.A [18.71.0.2] -280386 -281468 MIT-ARTEMIS.A [18.58.0.11] -282770 -283816 MIT-ORPHEUS.A [18.71.0.4] -286828 -287853 MIT-MENELAUS. [18.71.0.17] -294194 -294229 SU-FUJI.ARPA [36.2.0.9] 295277 294896 MIT-JASON.ARP [18.71.0.7] -296300 -297382 MICRO.UDEL.ED [192.5.39.4] 297334 296792 MIT-PRIAM.ARP [18.71.0.14] -300702 -301975 MIT-PARIS.ARP [18.71.0.12] -301652 -302932 ATHENA.MIT.ED [18.58.0.1] -301792 -303244 MIT-ODYSSEUS. [18.71.0.15] -303007 -304354 MIT-ZEUS.ARPA [18.58.0.2] -305836 -307120 MIT-HERACLES. [18.71.0.3] -309782 -310816 RADC-MULTICS. [26.0.0.18] -313852 -314576 MIT-POSEIDON. [18.58.0.6] -321949 -322546 DEWEY.UDEL.ED [192.5.39.2] 322621 322913 SU-COYOTE.ARP [36.18.0.215] -322956 -323303 BBNG.ARPA [192.1.2.67] -331109 -331111 UW-KRAKATOA.A [192.5.8.45] -333876 -334815 MIT-AGAMEMNON [18.71.0.16] -341461 -342518 NYU-ACF4.ARPA [192.5.15.133] -419460 -420123 CIP2.UCI.EDU [192.5.19.7] -435654 -435619 SU-LINDY.ARPA [36.9.0.11] -449513 -448490 VLSI.CS.CMU.E [128.2.254.129] -480627 -481678 NYU-CSD1.ARPA [192.5.15.131] -715648 -717005 SU-PESCADERO. [36.8.0.8] -751799 -751814 AMES-ATLAS.AR [192.12.49.50] -792499 -793442 S1-A.ARPA [26.1.0.95] 114428000 -773226 SU-AI.ARPA [10.0.0.11] 115126000 -76368 Notes WWVB echo Synchronized to WWVB radio; swaps addresses and ports WWV echo Synchronized to WWV radio; swaps addresses and ports GOES echo Synchronized to GOES satellite; swaps addresses and ports UDP echo Swaps addresses and ports IP echo Swaps addresses If anybody is interested in further details, raw data or pretty pics to light up your Sun, please tinkle me directly. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021407414700> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Fri 14 Feb 86 09:42:56-PST Date: 14 Feb 1986 12:41:47 EST From: PADLIPSKY@USC-ISI.ARPA Subject: Re: Tails and Dogs To: CERF@USC-ISI.ARPA cc: tcp-ip@SRI-NIC.ARPA In response to your message sent 13 Feb 1986 05:14-EST Vint-- Always good to hear from you, especially on the present topic, and even more especially since it lets me avoid being churlish (which would have been the case had I had to answer the other response independently; now I can merely observe that I'm sure you agree that in the context of the TCP-IP "bulletin board" Gateways must be IP Gateways unless otherwise specified and connections must be TCP connections U.O.S. and hence Gateways can't drop connections, without being explicitly rude to "Rudy.Nedved" [if I remember aright], and I might even go so far as to imagine you'd agree that it's at best peculiar to enter a discussion with a declaration that you don't believe the terms being discussed can be defined). [Well, I never said it would let me avoid being a little snide, but good grief, this isn't SF-Lovers! I mean, I'll apologize if he was being facetious about undefinability --though the business about Gateways dropping connections certainly suggests that he's not using our definitions--but it really is annoying, and rather insulting, to get a message that in essence says Since I don't know what you're talking about, you can't know what you're talking about. (That's probably more than the incident's worth--but you should have seen my longhand draft of a day or two ago.)] At any rate, subject to a little interpretation of the last paragraph I find myself in complete agreement with your comments-- particularly the second paragraph, which I take to be an elegant statement of what I was trying to say in the first place. The real question, in my mind, anyway, is what's meant by "looking at" the layers severally. Consider the (I think treacherous) analogy to staggered work hours and traffic congestion: what if somebody said Gee, that works so well that not only will we make it mandatory, we'll also send traffic cops into the buildings and have them turn off the elevators and lock the stairwells so those damn commuters can't flood our scarce street resources? Not only bad safety engineering practice, but really dubious on Constitutional grounds, yes? Well, isn't it even more dubious on Layering grounds to HAVE TO use fewer TCP connections or HAVE TO send out fewer datagrams (in the full awareness some will have to be retransmitted)? That is, it's perfectly licit to expect the Hosts to use the net intelligently, but when push comes to shove the net's there for the Hosts' benefit, not conversely, so the net has no business "demanding" the Hosts' lay off--except, of course, by giving the Gateways-part-of-the-net an analogue to the IMPs' ability to keep the ready line down (or whatever the equivalent is in HDLC/LAP B/whatever). And strong though my feelings are against arguing with the inventors of things about what the things are for, if you of all people support the use of TCP windows for something other than Host-Host flow control, well, let's step into the nearest time machine and go back around a dozen years and talk about what's wrong will NCP ALL again. Another way of attempting to express my concern is that while I have considerable sympathy (and even empathy) for people who are trying to split logs with toy hatchets because nobody will give them real ones, and will even buy whatever wood they can generate for me, I don't think they've got any business telling me I shouldn't look for somebody with a chain saw if I need more wood to keep the house warm enough to live in. I'm not asking for "infinite resources," just appropriate technology. But that's probably what your last paragraph meant anyway... and I daresay Dave wouldn't really let the cops lock the stairwells, even if I'm not so sure what he'd do with the elevators.... cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021409113900> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Fri 14 Feb 86 11:12:53-PST Date: 14 Feb 1986 14:11:39 EST From: PADLIPSKY@USC-ISI.ARPA Subject: Re: Tails and Dogs To: CERF@USC-ISI.ARPA cc: tcp-ip@SRI-NIC.ARPA In response to your message sent 13 Feb 1986 05:14-EST Ooops. Realized while suffering through lunch (dental anguish, not worse than usual provender) that I should have said give the Gateways an APPROPRIATE analogue to the ready line, since if Source Quenches and (or?) Redirects worked I'm confident Dave wouldn't have (inadvertantly?) gotten me started on this tack. And, since a new msg came in just now: I'll defer to your rejoinder in re Onions...unless you can't come up with anything better than IF you know how to deal with them, onions CAN be a tearless way of adding indispensible flavor to certain recipes. re-cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021418035200> Received: from SRI-CSL.ARPA by SRI-NIC.ARPA with TCP; Wed 19 Feb 86 10:01:14-PST Date: 14 Feb 86 18:03:52 GMT Subject: The LAN's Prayer From: Brian Goodmon Organization: Encore Computer Corp., Marlboro, MA ReSent-To: tcp-ip@SRI-NIC.ARPA ReSent-From: GEOFF at SRI-CSL.ARPA ReSent-Date: 19 Feb 1986 Rwhod who art in /etc, well-known be thy port; thy packets come, thy protocol be done, in user space as it is in kernel. Give us this day our daily dump, and forgive us our bugs as we forgive those who submit SPR's against them. Lead us not into address resolution, and deliver us from ISO. For thine is the transport and the session and the physical forever, EOF. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021418300000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Fri 14 Feb 86 20:31:34-PST Date: 14 Feb 1986 23:30-EST Sender: CERF@USC-ISI.ARPA Subject: Re: TCP/IP for HP-3000 From: CERF@USC-ISI.ARPA To: sutter@OHIO-STATE.ARPA Cc: net.dcom@OHIO-STATE.ARPA, net.lan@OHIO-STATE.ARPA Cc: net.mail@OHIO-STATE.ARPA, net.wanted@OHIO-STATE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]14-Feb-86 23:30:43.CERF> In-Reply-To: <8602132002.AA22361@ohio-state.ARPA> BBN did a TCP/IP for HP3000. Also, I believe HP is doing one as well, although I don't think it is in product form as yet. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021421483400> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Fri 14 Feb 86 14:36:02-PST Date: 14-Feb-86 21:48:34-UT From: mills@dcn6.arpa Subject: Re: Killing time To: MiloS.Medin(NASAARCCodeED), mills@dcn6.arpa, tcp-ip@sri-nic.arpa, Re:Killingtime@DCN6.ARPA In-reply-to: Your message of 14 Feb 86 10:32:01 PST (Fri) Milo, Snarf *.BIT on DCN1, ANONYMOUS, GUEST, then light up your Sun with screenload. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021504085300> Received: from MC.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Sat 15 Feb 86 06:07:49-PST Date: Sat, 15 Feb 86 09:08:53 EST From: "George J. Carrette" Subject: comments about Bridge Communication's IP bridge. To: tcp-ip@SRI-NIC.ARPA Message-ID: <[MC.LCS.MIT.EDU].819307.860215.GJC> I have two ethernets *almost* connected by a 56KB line. Almost because I have the V.35 connectors staring into space waiting for me to decide what bridge/gateway to buy. The Bridge Inc box is an attractive off-the-shelf hardware combination of 68000/ETHERNET-BOARD/SERIAL-BOARD/FLOPPY-BOOT-DISK if anything else. What experiences have people had (if any) with their IP bridging software. Does anyone have their own software for the box? -gjc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021504580000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Sat 15 Feb 86 06:58:23-PST Date: 15 Feb 1986 09:58-EST Sender: CERF@USC-ISI.ARPA Subject: Re: Tails and Dogs From: CERF@USC-ISI.ARPA To: PADLIPSKY@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]15-Feb-86 09:58:19.CERF> In-Reply-To: The message of 14 Feb 1986 14:11:39 EST from PADLIPSKY@USC-ISI.ARPA Mike, There was an old joke once about crossing an onion with a donkey and getting a piece of ass that brought tears to your eyes. I suppose one might say the same thing about crossing architectures with onions, although I am not sure what the connotations are. I was not advocating that the TCP level of flow control be used, somehow, to protect the network - just the opposite. The point is that the network (lower) layer must have mechanisms to protect its resources DESPITE the presence of the higher level end/end flow control. This does NOT, however, mean that one should design systems by deliberately being blind to how things work. John Nagle's recent RFC's and Dave Mills' work on tiny pipes/flow control algorithms are manifestations of the Jack Haverty school of engineering: "the smarter you are about the environment, the better you can tune the system to give optimum performance." The hard line to draw or engineering judgement to make is when to deliberately ignore specific information or not rely on it to achieve greater generality, but probably at the cost of poorer performance. Much of the initial INTERNET design deliberately took the latter approach in the interest of bringing an experimental facility into being from which we could learn in what ways it made sense to be "smart." Hope this makes my point a bit more clearly. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021622102300> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Sun 16 Feb 86 14:17:36-PST Date: 16-Feb-86 22:10:23-UT From: mills@dcn6.arpa Subject: Incestuous clockwatching To: tcp-ip@sri-nic.arpa Folks, I have had several messages of the general form "Why didn't my host show up in your list of clock respondents?" If said host did not respond to at least two of the three protocols: ICMP Timestamp, UDP/NTP or UDP/TIME, it was intentionally not included. In almost all cases those hosts that responded with UDP/NTP or UDP/TIME responded also to ICMP Timestamp. Accordingly, for those of you who are interested, I have put up the file TIME.TXT on DCN1 (ANONYMOUS/GUEST) containing all the IMCP Timestamp responses ordered by (apparent) subnet. Examination of the data in that file, by the way, suggests some revealing insights. The intent of the experiment that produced the file was to determine to what extent local nets tend to cluster closely around the "wrong" time, presumably due to incestuous clockwatching. In some local nets this tendency is readily apparent, with almost all hosts eagerly tracking some tens of seconds or minutes off with maybe a few broken or defiant exceptions. This has interesting implications for the design of synchronization algorithms such as suggested in RFC-956, since a large local net could in principle "take over" the world of clocks with the wrong time. Interestingly enough, however, the clustering algorithm of RFC-956 was fed the entire data base collected in last wwek's experiment, but it still came up with the "real" time to within a few millisceonds. For the crew working on NTP implementations, the following list of known reference hosts and clocks is as follows, along with the unsmoothed offset (milliseconds) measured with respect to DCN6 just to give you some idea of the accuracies that can be expected. The best accuracies are normally obtained with ICMP Timestamp (I), with UDP/NTP (N) next and UDP/TIME (U) last. The hosts marked * are corrected to agree to zero offset relative to radio time, but only with ICMP Timestamp. The offsets shown are almost completely dominated by network-delay dispersion, except for UDP/TIME, which has an inherent precision of one second. P Host Name Address Offset -------------------------------------- I GW.UMICH.EDU [35.1.1.1] -30 N GW.UMICH.EDU [35.1.1.1] -152 U GW.UMICH.EDU [35.1.1.1] -118 I UMICH-WWV.UMI [35.1.1.17] 58 * I DCN1.ARPA [128.4.0.1] -9 N DCN1.ARPA [128.4.0.1] 8 U DCN1.ARPA [128.4.0.1] -73 I DCN-WWV.ARPA [128.4.0.14] -14 * I DCN-WWVB.ARPA [128.4.0.15] -60 * I FORD1.ARPA [128.5.0.1] 49 N FORD1.ARPA [128.5.0.1] 40 U FORD1.ARPA [128.5.0.1] -167 I FORD-GOES.ARP [128.5.0.19] 36 * I UMD1.UMD.EDU [128.8.0.1] -183 N UMD1.UMD.EDU [128.8.0.1] -81 U UMD1.UMD.EDU [128.8.0.1] 656 I UMD-WWVB.UMD. [128.8.0.4] 174 * Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021705512100> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Mon 17 Feb 86 08:01:29-PST To: Ron Natalie cc: tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA Subject: Re: IPTO-FACTO In-reply-to: Your message of Thu, 13 Feb 86 3:29:11 EST. Date: 17 Feb 86 10:51:21 EST (Mon) From: Mike Brescia Does anyone know why the IPTO gateway on ARPANET is sending ICMP redirects to my MILNET hosts? Ron, There were three separate factors which conspired together (&&) to cause the newly installed IPTO butterfly gateway to send you (and others) redirects. 1. the redirect code did not include the test that the IP source of the packet must be on the same net as the gateway's input interface to permit a redirect to be sent. 2. the butterfly gateway includes minimal GGP code to advertize its own connected net (ARPA-LAN, 192.5.18, in this case) to those 'core' gateways which ask. 3. the butterfly gateway was plugged in to replace an lsi-11 'core' gateway, but the plug transfer was done too fast (5 seconds rather than 5 minutes) for the other core gateways to notice the fact that a core gateway had gone away. Because of (3), the core gateways did not get any new information from IPTO which would have only listed the ARPA-LAN net. This meant that when some nets went down, a route was mistakenly thought to exist through IPTO. Because of (1), IPTO was sending redirects for these packets not only to arpanet hosts, but also to hosts on milnet and other nets farther out. On Thursday morning, about 1100 EST, the IPTO gateway was brought up after being down for at least 10 minutes, forcing the core gateways to clear out the extraneous information. Friday, the gateway was reloaded with the redirect bug fixed. Mike Brescia ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021722401300> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 18 Feb 86 00:39:22-PST Date: Tue 18 Feb 86 03:40:13-EST From: "J. Noel Chiappa" Subject: More EGP musical tables To: tcp-ip@SRI-NIC.ARPA, egp-people@BBN-UNIX.ARPA cc: mit-ip-people@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU Message-ID: <12184285678.15.JNC@XX.LCS.MIT.EDU> OK, we have run out of a different kind of table resource in the EGP core gateways. (Yow, am I having *fun* yet?) This time, you don't even get to be a neighbour; there is no table space for new EGP neighbours. This happened to the MIT-AI-GW. It couldn't connect up to the two core EGP gateways it has been using for months. Since my EGP was refused by both of the core neighbours in its static 'toehold' table, it was completely out in the cold; it couldn't even try to shift to an alternate. (My EGP has all these heurisitics where you can set a 'minimum neighbour count' and it trys to keep that many neighbours around all the time by trying to peer with new neighbours its initial neighbours tell it about.) I called up the NOC, and they couldn't help, but I did get the info on which core gateways were running EGP; I tried them all, and after several failures found that the *last one* had room. Does anyone from BBN know why this suddenly happened? Are there just more EGP gateways out there, using up the table space? Was there an adverse effect from the release of the memory mapping software? If the table size cannot be increased, can EGP be put in more core gateways to spread the load? Whatever the reason, this is very disturbing, since hardwired 'bootstrap' information that has been good for months has effectively gone bad. Bad marks on the 'realiable service' front. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021804395100> Received: from bbnv1.ARPA by SRI-NIC.ARPA with TCP; Tue 18 Feb 86 12:39:51-PST Date: Tue 18 Feb 86 12:39:51-PST From: "ARAM BOORNAZIAN" Subject: Cerf and Natalie continued To: "tcp-ip" Reply-To: "ARAM BOORNAZIAN" There is a class of tools that make a job possible. The Layered Architecture is in that class. Aram ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021805452400> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Tue 18 Feb 86 07:47:47-PST Date: 18 Feb 1986 10:45:24 EST From: PADLIPSKY@USC-ISI.ARPA Subject: Re: Tails and Dogs To: CERF@USC-ISI.ARPA cc: tcp-ip@SRI-NIC.ARPA In response to your message sent 15 Feb 1986 09:58-EST Hi-- Mulishly ignoring the opening presented by your first paragraph, I'll merely observe that it's getting uncanny how your second paragraphs make just the points I want to. In the interests of getting on, I choose to infer from your third paragraph that I must have been wrong in thinking Dave WAS implicitly advocating Bad Things in the msg that started me off, and hence will couch my lance until somebody shoves another windmill into my path. (Rosinante and I are both getting on enough that it no longer seems worthwhile to cross roads for windmills, however attractive, but it's certainly beyond our scope to go around 'em if they're right there--to end with just a bit of horsing around, as it were.) cheers, map P.S. It might be a purist's point, but I do hope everybody remembers that OPTIMALITY DIFFERS ACCORDING TO CONTEXT ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021806100000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Tue 18 Feb 86 14:13:38-PST Date: 18 Feb 86 14:10:00 PST From: Subject: Logical addressing To: "tcp-ip" Reply-To: Does anyone know if the IMPs on the network currently support logical addressing for X.25 options? In the DDN X.25 Interface Specification a reference is made to the "Logical Addressing Facility", and that implementation of DDN logical addressing by a host is optional. If a host elected to implement this option would the IMP software support this, and does PSN 6.0 already have this implemented? Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021808102500> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Tue 18 Feb 86 10:11:47-PST Date: 18 Feb 1986 13:10:25 EST From: MILLS@USC-ISID.ARPA Subject: Re: Tails and Dogs To: PADLIPSKY@USC-ISI.ARPA, CERF@USC-ISI.ARPA cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA In response to the message sent 18 Feb 1986 10:45:24 EST from PADLIPSKY@USC-ISI.ARPA Good Lord, what have I done? It started with a few wayward packets and now we have windmills, horses, bad puns and Bad Things. May the Bird of Paradise redundancy all over your floor. Having had the first word, can I have the last and can this be it? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021813004000> Received: from mitre-bedford.ARPA by SRI-NIC.ARPA with TCP; Tue 18 Feb 86 15:00:15-PST Full-Name: Stanley R. Ames Message-Id: <8602182300.AA17593@mitre-bedford.ARPA> Organization: The MITRE Corp., Bedford, MA To: tcp-ip@sri-nic.ARPA, sra@mitre-bedford.ARPA Subject: rlogin support for non unix hosts Date: 18 Feb 86 18:00:40 EST (Tue) From: Stan Ames We are currently performing an independant assessment of the WIS program. One of the issues raised is whether commercial equipment could be used to solve the WIS requirements. One of the requirements of WIS is a single login. A potential solution is to use the rlogin capability found on most Unix hosts. Does anyone know whether this command is to be found in network implementations for machines other than Unix. Specifically does rlogin exist for IBM mainframes or VAXs running VMS. Thanks Stan Ames sra at mitre-bedford ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021905563600> Received: from bbncc2.arpa by SRI-NIC.ARPA with TCP; Wed 19 Feb 86 08:02:35-PST Date: Wed, 19 Feb 86 10:56:36 EST From: Joel B Levin Subject: Logical Addressing To: tcp-ip@sri-nic.arpa Cc: levin@bbncc2.arpa In answer to Gary Krall's query of 18 February: PSN 5.0 and PSN 6.0 fully support logical addressing as described in BBN report 5476, the DDN X.25 Interface Specification. Use of this facility is by arrangement with the administrators of the network. Joel B. Levin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021910120900> Received: from ucl-cs by SRI-NIC.ARPA with TCP; Wed 19 Feb 86 02:23:20-PST Date: Wed, 19 Feb 86 10:12:09 GMT From: Jon Crowcroft To: tcp-ip@sri-nic.arpa cc: jon@ucl-cs.arpa Subject: Re: [George J. Carre: comments about Bridge Communication's IP bridge.] As part of an Alvey project, University College London have been using Bridge Incs Gs/3 boxes to bridge 5 sites with local ethernets together, over 64 kbps serial lines. Each site has 2 bridge boxes, each box with 2 serial line boards capable of around 200 pkts/sec thruput. We use our own IP software, rather than bridges since it was'nt available when we installed the network. Re their software. 1. The Bridge Inc developement system and kernel is neat for building network software 2. The serial line driver software is a bit tacky, but can be made to do what you want. We have to fragment IP over the serial line down to 576 bytes to get good performance, but thats standard anyway. 3. Bridge don't do dynamic routing, we do (an IGP + EGP setup) 4. We support most of ICMP, but not all IP options (eg Redirects, Quenches. Not Source-Route or Route-Record) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986021923290000> Received: from nprdc.arpa by SRI-NIC.ARPA with TCP; Thu 20 Feb 86 07:38:52-PST Received: from pacific.ARPA by nprdc.arpa (4.12/ 1.1) id AA29108; Thu, 20 Feb 86 07:29:35 pst Received: by pacific.ARPA (4.12/4.7) id AA16323; Thu, 20 Feb 86 07:29:52 pst From: stanonik@nprdc.arpa (Ron Stanonik) Message-Id: <8602201529.AA16323@pacific.ARPA> Date: 20 February 1986 0729-PST (Thursday) To: tcp-ip@sri-nic.arpa, unix-wizards@brl-tgr.arpa Subject: 4.3bsd subnetting Cc: wallen@nprdc.arpa Berkeley 4.3bsd (beta) contains subnetting, but no support for non-subnetted hosts (suns) on the subnet. Rumor has it that 4.3bsd (distributed) also lacks support for non-subnetted hosts on the subnet. The subnetting rfc's suggest some solutions based on arp changes. Has anyone implemented these, or any other solutions? Thanks, Ron Stanonik stanonik@nprdc.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022001175900> Received: from GW.UMICH.EDU by SRI-NIC.ARPA with TCP; Wed 19 Feb 86 17:20:27-PST Date: 20-Feb-86 01:17:59-UT From: hwb@gw.umich.edu Subject: Swapped IP address bytes. To: tcp-ip@sri-nic.arpa cc: hwb@GW.UMICH.EDU What's going on here? First Cornell started to send lots of requests while having the destination IP address obviously swapped, and now BBN starts to be doing the same. Is this one of the jokes BBN had half a year or so ago with BBN-META or what's up? The following is going on for more than 90 minutes now, and I don't consider it to be very funny (even though I was fairly amused when I saw it in the first place). More seriously, since BBN is now the second place which is doing this, I wonder whether some "new" problem is showing up. -- Hans-Werner Braun PS: ICMP 003 000 is a (sub)net unreachable response ********************************************************************** 23:45:24 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:45:33 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:45:48 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:46:03 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:46:19 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:46:34 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:46:49 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:47:04 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:47:19 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:47:35 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:47:49 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:48:19 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:49:05 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:49:18 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:49:33 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] 23:49:48 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022002551600> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Thu 20 Feb 86 07:05:57-PST To: hwb@gw.umich.EDU cc: tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA Subject: Re: Swapped IP address bytes. In-reply-to: Your message of 20-Feb-86 01:17:59-UT. Date: 20 Feb 86 07:55:16 EST (Thu) From: Mike Brescia PS: ICMP 003 000 is a (sub)net unreachable response 23:45:24 010 ?TRAP-I-ICMP 003 000 [128.89.0.81] -> [35.0.23.128] (flame) It would be informative if you would mention what the 010 means, and whether we can deduce the protocol involved. It would also be informative if you would examine the NIC tables for info about what the address numbers map into. (emalf) Note that 128.89.0.81 is 'suran-vax' at BBN, and net 128.23 is the BBN packet radio (suran) net. I surmise that some debugging of a new monitoring program is going on. Be glad that it is happening around midnight rather than around noon. Regards, Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022004281700> Return-Path: Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Thu 20 Feb 86 06:27:07-PST Date: Thu 20 Feb 86 09:28:17-EST From: Dan Tappan Subject: Re: Swapped IP address bytes. To: hwb@GW.UMICH.EDU cc: brescia@CCV.BBN.COM, tcp-ip@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, Tappan@G.BBN.COM In-Reply-To: Message from "hwb@gw.umich.edu" of Thu 20 Feb 86 08:56:10-EST The problem turns out to have been a program being ported from a SUN to the VAX - and not properly handling the byte swapping. Not a problem with 4.2. I wouldn't be suprised is cornell's problem was similar. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022008462500> Received: from ames-nas.ARPA by SRI-NIC.ARPA with TCP; Thu 20 Feb 86 17:11:48-PST Received: from wilbur.ARPA (wilbur-hy) by ames-nas.ARPA; Thu, 20 Feb 86 16:50:10 pst Received: by wilbur.ARPA (4.12/4.7) id AA14210; Thu, 20 Feb 86 16:46:25 PST Date: Thu, 20 Feb 86 16:46:25 PST From: wayne@wilbur.ARPA (Wayne Hathaway) Message-Id: <8602210046.AA14210@wilbur.ARPA> To: iso@acc-sb-unix.ARPA, tcp-ip@sri-nic.ARPA Subject: Papers for classroom use? [Apologies for sending this to two lists. I'll keep it short. Chomp.] I teach a computer networks class at the University of Santa Clara, using Tanenbaum. The book is quite good for the lower OSI layers, but is very weak at ISO IP and above. Does anybody know of any articles, papers etc. that would serve as good handouts for things like ISO IP, TP4, Session protocols, and so forth? Looking for 10-15 pages max, "survey" type stuff, suitable for handouts to be fleshed out with class discussion. Adthanksvance for any pointers. Wayne Hathaway wayne@ames-nas.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022012393200> Received: from im4u by SRI-NIC.ARPA with TCP; Thu 20 Feb 86 17:08:29-PST Posted-Date: Thu, 20 Feb 86 18:39:32 cst Received: from zotz.UTEXAS.EDU by im4u (4.22/4.22) id AA06264; Thu, 20 Feb 86 18:53:22 cst Date: Thu, 20 Feb 86 18:39:32 cst From: jsq@zotz.UTEXAS.EDU (John Quarterman) Message-Id: <8602210039.AA05012@zotz.UTEXAS.EDU> Received: by zotz.UTEXAS.EDU (2.0/4.22) id AA05012; Thu, 20 Feb 86 18:39:32 cst To: stanonik@NPRDC.ARPA Subject: Re: 4.3bsd subnetting Cc: tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL-TGR.ARPA, wallen@NPRDC.ARPA I'm working on fitting Smoot Carl-Mitchell's 4.2BSD ARP hack into 4.3BSD. Should be ready in about a week. Somebody else may have already done it, or something like it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022013164200> Return-Path: <@GW.UMICH.EDU:hwb@gw.umich.edu> Received: from GW.UMICH.EDU by SRI-NIC.ARPA with TCP; Thu 20 Feb 86 05:18:55-PST Date: 20-Feb-86 13:16:42-UT From: hwb@gw.umich.edu Subject: Re: Swapped IP address bytes. To: MikeBrescia, hwb@gw.umich.EDU, tcp-ip@sri-nic.ARPA, tcp-ip@sri-nic.ARPA cc: hwb@GW.UMICH.EDU In-reply-to: Your message of 20 Feb 86 07:55:16 EST (Thu) Mike: Sorry about the lack of information and probably sad wording in my message. The 10 is only of local significance and the time was in UT and therefore off by five hours compared to EST. I had a hard time to type because I got these messages every 15 seconds, which is not a good excuse but at least some reason for strangeities in my messages. The reason I was sending it so broadly was because I noticed before that a few hosts at Cornell started to do the same about two weeks or so ago. Now that even a host at BBN starts doing it I wonder whether there is a more general problem (may be with 4.3?). The mentioned connection requests arrived on a Fuzzball which allowed me to remap the destination host to UMICH1.ARPA. Then I saw that it was actually a Telnet request. By the way, I figured that out after I sent the message; my major reason were the swapped IP bytes and nothing else. Anyway, this showed me that SRN-VAX.ARPA attempted a telnet (Port #23) request. This means that there might be another problem, too, since SRN-VAX tried to get a Telnet connection for over 90 minutes while retrying about every 15 seconds and always getting net unreachables. I hope this helps more than my original message. Thank's for checking into this so far. Please let me know if I can be of more help to figure out what the problem is. -- Hans-Werner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022018351700> Received: from BITSY.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 20 Feb 86 21:34:18-PST Received: by BITSY.MIT.EDU (5.15/4.7) id AA02406; Thu, 20 Feb 86 23:35:17 EST Date: Thu, 20 Feb 86 23:35:17 EST From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Message-Id: <8602210435.AA02406@BITSY.MIT.EDU> To: tcp-ip@sri-nic.arpa Subject: Interesting Ethernet/UNIX 4.2 observation. I thought I would share this one with everybody: We have just finished installing an Ethernet with ~40 single user Vaxstation II's running UNIX 4.2 on it. We also have a few IBM RT PC's as well. The Vaxstations use the MIT Developed RVD protocol to access the files in "/usr" which are in fact located on a VAX 11/750. I mention RVD not because it is related to the problem described, but because it means that these workstations make quite regular use of the network even when involved in otherwise non-network activity. And obviously they also depend strongly on the network in order to function properly at all. Therefore it was a major problem when people began complaining to me about the network dying for 20 second intervals about once a minute. The network would come back to life with the Vaxstations spiting out an error about their Ethernet board being wedged and having to be restarted. One might normally expect there to be some hardware problem behind all this. This turned out to only partially be the case, which is to say the hardware problem found was of a design nature, not just one broken board... read on. A running examination of network hardware statistics showed that we were getting a large number of collisions about once a minute, exactly. At this point we turned on "Netwatch." For those who don't know what it is: Netwatch is a program which is part of the MIT PC/IP package for the IBM PC (PC/XT/AT and compatibles). It allows one to examine packet traffic on the Ethernet and also does some automatic packet analysis (ie. Type of packet, Protocol, Source and Destination etc). The problem turned out to be that one workstation was misconfigured so that it thought it was on network 46 (whereas the real network is 18.72, we use a subnetting scheme). Most UNIX 4.2 systems have a cute little daemon named "rwhod" that broadcasts information to all other stations once per minute. In the case of our misconfigured workstation this packet was sent to the Ethernet broadcast address and to IP address 46.0.0.0. Now this resulted in all other workstations on the network receiving this packet and deciding that they would be good citizens and forward it on to our gateway. Because this level of processing occurs at interrupt level, and most of our stations are not loaded to the point that significant interrupt latency occurs, all ~40 workstations would simultaneously attempt to forward this packet to our gateway. This resulted in a monster collision on the Ethernet. Now combine this with a hardware design problem in the Ethernet controller that results in the Ethernet hardware having a good probability for wedging up in the (otherwise rare) case of monster collision, and add a 20 second timeout in the device driver software and you have a neat problem on your hands. Obviously we fixed the misconfigured machine, however this problem has occurred several times since (we are still installing machines). Btw. tracing down the location of the offending machine is also a bit of a bear. The network is in an office area. Each office has two Ethernet drops, each coming from a dedicated transceiver above the (icky dirty) ceiling. The offices are generally locked. People leave their workstations on, up and in operation. Admittedly this Ethernet topology is just asking for this kind of problem (ie. what do you do when an interface starts jabbering). To help track this kind of problem down I have established a database of IP address => Ethernet Address => Physical Location. Luckily the software tools our workstations have do not allow a user to easily change his Ethernet address, so that can be relied on to determine the location of the offending machine. Moral of the story: 1) The Ethernet topology described above may not be the best possible for an office area (but we all probably know that anyway). 2) A Network Spy program like netwatch is an invaluable tool. 3) WORKSTATIONS THAT ARE HAPPY TO ACT AS GATEWAYS are probably a BAD idea. In fact it is probably best that when a workstation receives a packet incorrectly sent to it, the packet be DISCARDed and perhaps logged for debugging purposes. Note that if a workstation sends an ICMP destination unreachable message back to the source, the monster collision would still occur as ALL workstations would try to send the ICMP message. 4) Ethernet controllers that work "most" of the time may not be good enough. -Jeff P.S. Sorry this message was so long. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022020222400> Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Fri 21 Feb 86 04:26:36-PST Date: Fri 21 Feb 86 04:22:24-PST From: William "Chops" Westfield Subject: Tops20 TVT performance improvments To: tops-20@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <12185112557.8.BILLW@SU-SCORE.ARPA> BUG: Under certain situations, throughput on TOPS20 TVTs drops to approximately 0 for long periods of time. I believe that the problem got worse with v6.1, and may be the reason that the TVT SMTP server doesn't work well under 6.1. Reproduce by: I think this shows up best when trying to run a dialout type program while logged in on a TVT. However, the following program will exhibit the problem too: start: movei 6,^d32 loop: movei 1,"%" pbout movei 1,^d30 disms sojg 6,loop haltf Diagnosis: The tops20 TVT scanner attempts to send characters that are part of "echoing" immediately. It's criteria for recognizing "echoes" is that there be fewer than 8 characters in the terminal output buffer. Since the TCP process runs at a very high priority, it will probably get to look at the TTY output buffers if the user process blocks for any reason. In the case above, therefore, there is a good chance that 32 separate 1 byte packets are queued. And there are certainly lots of machines that don't like to receive 32 almost back-to-back short packets. This leads to many retransmissions and excessive use of CPU time on both systems, not to mention any gateways that might be in between them. Fix: Make TOPS20 TCP pickier about what it considers echoing. In addition to there being only a few characters in the buffer, have it insist that the retransmission queue for that connection be empty. (If a person types faster than the Round trip times, it won't hurt to have his echoing clumped together a little anyway.) This is much simpler than having the TCP repacketize retransmissions. By the way, it turns out that this is "reinventing the wheel", as almost identical suggestions were made by John Nagle in RFC896. It is surprising, however, that this makes such a difference even on local ethernets with no gateways involved. Admittedly, tops20's scheduling of TCP provides a pathological case! The relevant code is in TVTSRV, just before OPSCA7: [This is from 6.1 sources. There should be an easy equivalent for 5.x. From SCORE:: <6-1-monitor>TVTSRV.MAC ] SKIPA T4,T1 ; Yes. Get PZ to call SNDTVT JRST OPSCA7 ; No. IFE STANSW,< MOVX T1,^D200 ; The function to queue for PZ if a lot MOVX T2, ; to send - wait a bit, maybe more CAIGE T4,^D8 ; Less that 8 is echoing so MOVX T2, ; Force it now CALL (T2) ; See Note above >;IFE STANSW IFN STANSW,< ;;; there is not going to be any more output if all of the ;;; output buffers are full, so send packets immediately. CALL TTSOBF ;output buffer full? CAIGE T4,^D8 ; or looks like echoing. SKIPA T2,[XCDSEC,,FRCPKT] ; Force it now MOVX T2, ; otherwise wait for more data LOAD T1,QNEXT,<+TCBRXQ(TCB)> ;check if retranmission queue empty? CAIE T1,TCBRXQ(TCB) ;skip if RXQ empty CAIL T4,^D8 ; or if a large packet TRNA MOVX T2, ; otherwise wait for more data MOVEI T1,^D200 ; for a couple hundred millisecs. CALL (T2) ;call appropriate packet routine. >;IFN STANSW OPSCA7: MOVE T2,LINADR ; Restore address of terminal block OPSCA8: CALL ULKTTY ; Decrease reference count, OKINT ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022022121100> Received: from SUMEX-AIM.ARPA by SRI-NIC.ARPA with TCP; Fri 21 Feb 86 06:51:08-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 21 Feb 86 06:50:30-PST Date: Fri 21 Feb 86 06:12:11-PST From: Mark Crispin Subject: Re: Tops20 TVT performance improvments To: BILLW@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: <12185112557.8.BILLW@SU-SCORE.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12185132542.9.MRC@PANDA> A release 5.4 equivalent of BillW's change is follows. It does make a difference. SKIPA T4,T1 ; Yes. Get PZ to call SNDTVT JRST OPSCA7 ; No. IFE PANDASW,< ;[5] MOVX T1,^D200 ; The function to queue for PZ if a lot XMOVEI T2,ENCPKT ; to send - wait a bit, maybe more CAIGE T4,^D8 ; Less that 8 is echoing so XMOVEI T2,FRCPKT ; Queue for PZ promptly CALL (T2) ; See Note above >;IFE PANDASW IFN PANDASW,< ;[5] ;;; FRCPKT is called if: ;;; . There are less than 8 bytes (probably echoing) in the packet and the ;;; retransmission queue is empty ;;; OR ;;; . The terminal output buffer is full ;;; Otherwise ENCPKT is called instead CALL TTSOBF ; Is output buffer full? IFSKP. CALL FRCPKT ; Yes, might as well send it now ELSE. CAIL T4,^D8 ; Looks like echoing? IFSKP. LOAD T1,QNEXT,<+TCBRXQ(TCB)> ; Yes, get RXQ CAIE T1,TCBRXQ(TCB) ; Is the retransmission queue empty? ANSKP. CALL FRCPKT ; Yes, queue for PZ promptly ELSE. MOVX T1,^D200 ; Output not full and not echoing, wait a bit CALL ENCPKT ; for more to output ENDIF. ENDIF. >;IFN PANDASW OPSCA7: MOVE T2,LINADR ; Restore address of terminal block OPSCA8: CALL ULKTTY ; Decrease reference count, OKINT I don't believe this problem was the cause of the TVT SMTP server problem, nor will this fix repair it. The TVT SMTP server doesn't echo. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022104314200> Received: from proteon.arpa by SRI-NIC.ARPA with TCP; Fri 21 Feb 86 06:39:03-PST Date: Fri, 21 Feb 86 09:31:42 EST From: jas@proteon.arpa Subject: workstation != gateway To: tcp-ip@sri-nic.arpa I totally concur with Jeff that workstations should not think they are gateways. That is a massive abuse of the IP spec. It should be possible to turn off all gateway functionality in 4.2 and 4.3BSD machines. My example of the problem was forwarding loops of unusally addressed broadcast packets. This happened on a full-duplex network (proNET), where a packet came in and went out as a hardware broadcast. This is yet another danger of gateway/workstations, but one you don't see with half-duplex networks like Ethernet. John Shriver Proteon ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022105180000> Received: from ALLEGHENY.SCRC.Symbolics.COM ([192.10.41.45]) by SRI-NIC.ARPA with TCP; Fri 21 Feb 86 17:09:31-PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 481; Fri 21-Feb-86 10:11:57-EST Date: Fri, 21 Feb 86 10:18 EST From: David C. Plummer Subject: Interesting Ethernet/UNIX 4.2 observation. To: Jeffrey I. Schiller , tcp-ip@SRI-NIC.ARPA In-Reply-To: <8602210435.AA02406@BITSY.MIT.EDU> Message-ID: <860221101851.0.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Thu, 20 Feb 86 23:35:17 EST From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Moral of the story: 1) The Ethernet topology described above may not be the best possible for an office area (but we all probably know that anyway). 2) A Network Spy program like netwatch is an invaluable tool. 3) WORKSTATIONS THAT ARE HAPPY TO ACT AS GATEWAYS are probably a BAD idea. In fact it is probably best that when a workstation receives a packet incorrectly sent to it, the packet be DISCARDed and perhaps logged for debugging purposes. Note that if a workstation sends an ICMP destination unreachable message back to the source, the monster collision would still occur as ALL workstations would try to send the ICMP message. 4) Ethernet controllers that work "most" of the time may not be good enough. There are two more morals: 5) Unix is being antisocial by BROADCASTING information (rwhod) once a minute. As far as I know, only Unix cares about this. 6) Unix is being antisocial by BROADCASTING requests (rwho) once every few minutes. Consider 200 nodes on the same cable. That is a moral#5 broadcast packet averaging 4 times a second, and a moral#6 packet at a hopefully slower rate. There are other things than Unix in the world. If Unix doesn't have system configuration parameters to turn either or both of these off; it should. Why must EACH Unix do this sort of thing all night long when there is no user that is actually requesting the information. It's sort of like me programming my machine to send a message to this mailing list every half hour just to let everybody know my machine is still up. Summary of morals 5 and 6: fix Unix. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022107104600> Received: from mouton.ARPA by SRI-NIC.ARPA with TCP; Fri 21 Feb 86 09:11:37-PST Received: from sabre.bellcore.com by mouton.ARPA (4.12/4.7) id AA06261; Fri, 21 Feb 86 12:14:13 est Received: from blade.bellcore.com (blade.ARPA) by sabre.bellcore.com (4.12/SMI-2.0mjl) id AA22739; Fri, 21 Feb 86 12:08:55 est Received: by blade.bellcore.com (4.12/SMI-2.0mjl) id AA25290; Fri, 21 Feb 86 12:10:46 est Date: Fri, 21 Feb 86 12:10:46 est From: martin%blade@mouton.ARPA (Martin J Levy) Message-Id: <8602211710.AA25290@blade.bellcore.com> To: tcp-ip@sri-nic.arpa Subject: Re: workstation != gateway Cc: jas@proteon.arpa There are two problems with the 4.2bsd release running on a workstation. The first is the concept of IP forwarding, you can turn this off by setting the kernel variable "ipforwarding" to 0. This can be done with adb(1), or by recompiling. The second problem is a bit more serious. The router running under 4.2bsd is ment to keep quiet if it's running on a machine with one one interface and just listen to route packets. But under some conditions it will send out a route packet and some machines on the local network will belive that the workstation is a valid gateway to another network. This is of course wrong. It's just a coding error, but it got out on the release tape. There is another school of thought that believes that a host (ie a workstation) with one one interface should not run a routing protocol and just use a default route and expect ICMP redirects to guide it to the correct gateway. If that view is taken then you will never get the case of a workstation acting as a gateway martin levy. bellcore, nj. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022109574500> Received: from mitre-gateway.arpa by SRI-NIC.ARPA with TCP; Fri 21 Feb 86 12:08:53-PST Date: 21 Feb 1986 14:57:45 EST (Friday) From: T. Michael Louden (MS W422) Subject: Re: workstation != gateway In-Reply-to: Your message of Fri, 21 Feb 86 09:31:42 EST To: tcp-ip@sri-nic Cc: louden@mitre-gateway.arpa There was a second problem mentioned that is just as bad! Neither Gateways nor Workstations should reply with an unreachable message to a packet sent to the broadcast address!! This can cause a big mess!! ( I have been a victim if this one also!) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022110485600> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 21 Feb 86 12:50:43-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Fri, 21 Feb 86 15:48:56 est Date: Fri, 21 Feb 86 15:48:56 est From: dab@BORAX.LCS.MIT.EDU (David A. Bridgham) Message-Id: <8602212048.AA23705@BORAX.LCS.MIT.EDU> To: tcp-ip@sri-nic.arpa, jas@proteon.arpa Subject: workstation != gateway In general, machines (either gateways or workstations) should not forward packets that were broadcast. This can causes all manner of breakage with packet loops and flooded nets (Send an ICMP ping to the broadcast address of a ringnet that has machines on it which forward broadcast packets. It will take a couple of minutes for the time-to-live fields to get rid of all the packets, during which time the machines on that net will not be much use.). The exception of course is the case where there is a specified mechanism for multi-subnet broadcast and that is being used. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022114154600> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 21 Feb 86 16:12:47-PST Date: Fri 21 Feb 86 19:15:46-EST From: "J. Noel Chiappa" Subject: Re: workstation != gateway To: martin%blade@MOUTON.ARPA, tcp-ip@SRI-NIC.ARPA cc: jas@PROTEON.ARPA, JNC@XX.LCS.MIT.EDU In-Reply-To: <8602211710.AA25290@blade.bellcore.com> Message-ID: <12185242421.46.JNC@XX.LCS.MIT.EDU> Right. There isn't a spec for exactly what a gateway has to do; if there was such a spec it would need massive updating, since the job of the gateways is continually changing. The IP Engineering Group is exploring some pretty substantial changes to gateways, which will make tracking the gateway functions even more difficult. My recommendation has for quite some time been that hosts and gateways are very different, and that we should provide a 'specification for a host IP layer' that will insulate hosts from changes in the switches. It's not easy to make a host into a gateway, as the Berkeley people found to their (and our) cost. Worse yet, the Engineering group is stuck with either having its options limited by backward compatabilty with unsuitable designs (as is the case with RIP [routed] and EGP). People building host IP layers should eschew adding 'simple gateway functionality'; it's not simple. If you do, you'll be stuck with something that a) doesn't work right, and b) will break even if it works OK now, as the architecture changes. I like to make the analogy with the electric power grid; it's easy to build an appliance you can plug in that uses power (equivalnte of host); it's a much trickeier job to build a generator you can plug into the system to support it (gateway). Too many people say "Oh, I already have a PDP11 (VAX, Sun, PC, RT, etc); I'll just add another interface board and whip up a little code." It's not that simple; 'nothing in networks is ever as simple as it seems'. As the system grows, and we add mechanisms to deal with the problem we are now seeing (e.g. the massive congestion, etc) it will just get more complicated. 'There's no such thing as a free lunch.' Believe it. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022117030300> Received: from BITSY.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 21 Feb 86 19:01:50-PST Received: by BITSY.MIT.EDU (5.15/4.7) id AA03976; Fri, 21 Feb 86 22:03:03 EST Date: Fri, 21 Feb 86 22:03:03 EST From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Message-Id: <8602220303.AA03976@BITSY.MIT.EDU> To: martin%blade@mouton.ARPA (Martin J Levy) Cc: tcp-ip@sri-nic.arpa In-Reply-To: Martin J Levy's message of Fri, 21 Feb 86 12:10:46 est Subject: Re: workstation != gateway Our workstations DON'T run a routed routing daemon. They do in fact maintain a default route to a "smart" gateway. The problem we were experiencing was the result of a misconfigured machine sending a broadcast packet that the other machines misinterpreted as a packet that needed to be forwared. Setting ip_forwarding to 0 doesn't help the problem because what would happen in that case (under 4.2) is that all ~40 stations would simultaneously attempt to send an ICMP destination unreachable message, which would cause a monster collision (I am repeating myself slightly here). To summarize: The problem is that 4.2 thinks it is a gateway, so that when someone accidently sends it a misdirected packet, it does something... usually it is something harmless, but not always. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022207170000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Sat 22 Feb 86 09:17:03-PST Date: 22 Feb 1986 12:17-EST Sender: CERF@USC-ISI.ARPA Subject: Re: rlogin support for non unix hosts From: CERF@USC-ISI.ARPA To: sra@MITRE-BEDFORD.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]22-Feb-86 12:17:17.CERF> In-Reply-To: <8602182300.AA17593@mitre-bedford.ARPA> MCI Mail uses VMS on an X.25 network. Users authenticate themselves at the TAC (PAD) level and a network authentication server tells the TAC (PAD) which host to connect the user to (mailboxes move around, but users don't need to be aware of it). We use a non-standard X.3/28/29 virtual call protocol to make the connection to the target VAX and carry the user identifying information in the initial call request to avoid the need for double login. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022308375300> Received: from Xerox.COM by SRI-NIC.ARPA with TCP; Sun 23 Feb 86 16:35:55-PST Received: from Chardonnay.ms by ArpaGateway.ms ; 23 FEB 86 16:38:18 PST Date: Sun, 23 Feb 86 16:37:53 PST From: Murray.pa@Xerox.COM Subject: Re: Interesting Ethernet/UNIX 4.2 observation. In-reply-to: <8602210435.AA02406@BITSY.MIT.EDU> To: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Cc: tcp-ip@sri-nic.arpa Message-ID: <860223-163818-1909@Xerox> Neat story. Thanks for sharing the info. The Pup specs have always included a bit of important fine print about sending back error Pups: don't send them in response to another error Pup, and don't send them in response to a broadcast Pup. I think "broadcast" should be extended to include the physical layer as well as the logical layer to catch ARP type mixups. I couldn't find the corresponding idea in the ICMP specs. Did I flip the pages too fast? We recently uncovered a similar glitch. We had a bug in our ARP like code. It was returning an unitialized variable if the target machine hadn't yet responded to the ARP request. That gives a 50% chance of the multicast bit being on. Our gateways are willing to "forward" a Pup back out the same interface it came in on. (That occasionally happens while the routing tables are changing.) We have 6 or 8 gateways on that net and they all include the same bug, so I'd expect a real explosion. All we got was occasional "too many hops" errors. I guess the frames were mostly reused in a lucky pattern. BTW: Broadcasting an echo packet is a wonderful stress test for a network. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022318222400> Received: from gyre.umd.edu by SRI-NIC.ARPA with TCP; Sun 23 Feb 86 20:19:40-PST Received: by gyre.umd.edu (5.9/4.7) id AA10688; Sun, 23 Feb 86 23:22:24 EST Date: Sun, 23 Feb 86 23:22:24 EST From: Chris Torek Message-Id: <8602240422.AA10688@gyre.umd.edu> To: DCP@SCRC-QUABBIN.ARPA Subject: Re: Interesting Ethernet/UNIX 4.2 observation. Cc: tcp-ip@sri-nic.ARPA Unix does not broadcast rwho requests; rwho runs entirely locally. Rwhod *must* send updates in order to allow downtime determination at remote sites (though if all you are interested in is load average and users, sending updates makes little sense). In addition, there is no easy way to determine who really *is* interested in the information; the problem is quite similar to that of determining to whom to send routing information. The obvious easy answer is to use broadcasts (on networks that support the concept). In 4.3, rwhod sends broadcasts only once every two minutes. If this is still too much for your network, why are you running it at all? And if you are running it because it is more useful than it is expensive, why are you complaining? If you know how to make it work better, change it! This is not intended as flamage. I am entirely serious: if it is broken, fix it; if it is useless, do not use it; but please do not simply complain that Unix is flawed because rwho uses broadcasts. It comes configured that way only because those who make the tapes find it more useful than costly. It is quite simple to turn off. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022404110500> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 08:24:07-PST To: tcp-ip@sri-nic.ARPA Subject: Re: Interesting Ethernet/UNIX 4.2 observation. In-reply-to: Your message of Sun, 23 Feb 86 23:22:24 EST. <8602240422.AA10688@gyre.umd.edu> Date: 24 Feb 86 09:11:05 EST (Mon) From: Mike Brescia One of the objections to 'rwho' is that it broadcasts. It would be like having one mailing list in usenet, and reading all the junk to get to the good stuff. What features would be needed on the local ethernet, and in the cooperating U**'s, to have such services as 'rwho' multicast instead of broadcast? How would the multicast address be assigned? How would you do it on other nets which do not have logical addressing or multicast? Is RFC966 (Deering and Cheriton, Host Groups: A Multicast Extension to the Internet Protocol) a framework? ? Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022404340600> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 08:24:29-PST To: Murray.pa@xerox.COM cc: tcp-ip@sri-nic.ARPA Subject: Re: Interesting Ethernet/UNIX 4.2 observation. (gateway & multicast) In-reply-to: Your message of Sun, 23 Feb 86 16:37:53 PST. <860223-163818-1909@Xerox> Date: 24 Feb 86 09:34:06 EST (Mon) From: Mike Brescia We have gateway interfaces to 3 different networks which implement a hardware broadcast address, and in each of them have seen the effects of looping packets because the gateway forwarded broadcast packets back onto the net. We have put in the extra check to drop at the local net layer, IP datagrams which are addressed to the local net hardware broadcast address. (ARP is not dropped because it uses a different link/protocol number.) This means that the gateways will not respond to echo packets addressed to 'broadcast', but this means we can keep the test simple, and not have to search all the possible broadcast addresses also. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022404410000> Received: from su-navajo.arpa by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 13:20:17-PST Received: by su-navajo.arpa with Sendmail; Mon, 24 Feb 86 12:41:16 pst Date: 24 Feb 1986 1241-PST (Monday) From: Jeff Mogul To: Barry Shein Cc: tcp-ip@sri-nic.ARPA Subject: What to do about rwhod In-Reply-To: Barry Shein / Mon, 24 Feb 86 12:06:37 EST. P.S. Just a thought, perhaps the ultimate solution will be smart interfaces that can be told a little about what packets the host is interested in and drop all others, tho again ultimately the problem will be the bandwidth of the cable. sigh. I.e., multicast, as other people have suggested, would be the ideal solution to the rwhod problem (and similar ones, such as broadcast-based routing protocols.) Unfortunately, it's not clear how easy it will be to implement multicast support in 4.2 (and successors) even if someone comes up with a good IP multicast spec. Alternatively, maybe rwho/d could be run on a "lazy-evaluation" basis. Change the rwhod servers so that the only time they broadcast status packets is when they start up. When someone types "ruptime" or "rwho", if the information stored at the local host is more than, say, 5 minutes out of date, an "rwho status request" packet is broadcast; the rwhod servers on the net respond with packets directed at the requesting host. This means that some packets are broadcast, but only when the information is both wanted and hasn't been updated recently; the number of broadcasts in the worst case is no more than currently, and in the best case is epsilon more than zero. The disadvantage of this scheme is that you no longer can be sure just how long a catatonic host has been down, unless people having been requesting updates fairly often. There are obvious algorithms to maintain this sort of information, i.e. use a designated central site to poll other sites (non-broadcast) at reasonable intervals, and use broadcasts only to join the group or recover from the loss of a central site. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022405220000> Received: from ALLEGHENY.SCRC.Symbolics.COM ([192.10.41.45]) by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 07:12:10-PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 727; Mon 24-Feb-86 10:15:00-EST Date: Mon, 24 Feb 86 10:22 EST From: David C. Plummer Subject: Re: Interesting Ethernet/UNIX 4.2 observation. To: tcp-ip@SRI-NIC.ARPA In-Reply-To: <8602240422.AA10688@gyre.umd.edu> Message-ID: <860224102218.9.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Sun, 23 Feb 86 23:22:24 EST From: Chris Torek [Sigh, our domain code isn't quite in yet... I'm assuming this gets to you through the mailing list...] [Disclaimer: I don't use Unix. For that matter, I seriously dislike Unix.] Unix does not broadcast rwho requests; rwho runs entirely locally. Rwhod *must* send updates in order to allow downtime determination at remote sites (though if all you are interested in is load average and users, sending updates makes little sense). In addition, there is no easy way to determine who really *is* interested in the information; the problem is quite similar to that of determining to whom to send routing information. The obvious easy answer is to use broadcasts (on networks that support the concept). Maybe I'm confused then. Somebody is sending out broadcast packets to UDP port 513 (decimal). Is that RWHO or RWHOD? Our Lisp machine system thinks that the protocol is called :UNIX-RWHO. Maybe that is wrong. In 4.3, rwhod sends broadcasts only once every two minutes. If this is still too much for your network, why are you running it at all? I wish we weren't. Tell me the flag to set, and I'll tell our unix people to set it. If you tell me, 'Well, you have to go in a modify code...' I'll ask why there isn't a flag. And if you are running it because it is more useful than it is expensive, why are you complaining? I don't know if anybody uses the information. I would guess not. We aren't a unix house. If you know how to make it work better, change it! I've fixed my machine to ignore these, but that doesn't affect the other 100+ workstations that are still wasting time responding to our 3 unix machines. This is not intended as flamage. I am entirely serious: if it is broken, fix it; if it is useless, do not use it; but please do not simply complain that Unix is flawed because rwho uses broadcasts. It comes configured that way only because those who make the tapes find it more useful than costly. It is quite simple to turn off. Tell me how. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022406302900> Received: from monet.berkeley.edu by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 19:47:48-PST Received: by monet.berkeley.edu (5.44/1.9) id AA18567; Mon, 24 Feb 86 19:50:33 PST From: karels@monet.berkeley.edu (Mike Karels) Message-Id: <8602250350.AA18567@monet.berkeley.edu> To: "J. Noel Chiappa" Cc: tcp-ip@sri-nic.arpa Subject: Re: workstation != gateway In-Reply-To: Your message of Fri, 21 Feb 86 19:15:46 -0500 Date: Mon, 24 Feb 86 19:50:29 -0800 I agree with Noel and others that hosts and gateways have rather different properties, and that the gateways' role is changing faster than that of hosts. If there were a specification for a host IP layer that insulated hosts from all future changes (except, of course, those required to bring them into compliance initially, and whenever the spec did finally change), then I would only have to worry about changes affecting gateways at Berkeley. Until that time, I will have to continue to support both hosts and gateways. If I were to do each separately, I would have twice the work. Instead, I have chosen to extend and correct the gateway support that was in 4.2 and continue to use "hosts" as gateways. Although there is no spec for what a gateway has to do, I think that it is quite likely that a 4.3BSD Unix system would pass most reasonable specs. At the same time, 4.3 is better at 4.2 at discovering that it is not in a position to act as a gateway and remaining quiet. (Before the corrections fly, as a result of this discussion I changed 4.3 not to respond with ICMP unreachables if it is unable/unwilling to forward packets). The idea of well-defined interface between hosts and gateways to avoid future need for changes in the host is attractive. However, such an interface must be sufficient for optimal use of the network by the host, resilient to future change in the gateways and other network underpinnings, and compatible with varying usage of IP-based networks from isolated LAN's, to single hosts on the Arpanet, to subnetted and heterogeneous high-speed networks interconnected to one or more long-haul nets. I find it hard to believe that such a specification will be sufficiently functional that people will not be forced to extend it for some situations, but will be sufficiently simple and close to the current specifications that it will be widely adopted by vendors. Minor variations, such as multi-homed hosts, require the host to be much more knowledgeable about its environment. Even Noel, in complaining of the need to be compatible with the Berkeley routing protocol and EGP, recognizes that there are limits to the changes that are possible now. I don't think that compatibility with either of these is actually necessary. Incidentally, Noel, the unknowing might take your statement to imply that both of these "unsuitable designs" originated at Berkeley; we won't take the blame for EGP, nor will we claim that the "RIP" protocol is suitable for the things that you are trying to do with it. An unfortunate fraction of the discussion that resulted from Jeff Schiller's original note was based on oversimplification or misinformation. For example, a number of comments mentioned "the broadcast address": wayward packets sent to the broadcast address should not receive error indications or be forwarded. Which broadcast address? If the hardware broadcast address, this can be handled easily on machines that support only IP and 10Mb/s Ethernet. This is a bit more difficult in the 4.2 architecture, which supports numerous types of network interfaces as well as multiple protocol families. By the time IP or ICMP receives the packet, the hardware sender address is not longer around, and IP/ICMP neither do nor should know how to tell if a hardware address is a broadcast. On the other hand, if the comments were directed at handling packets with an IP broadcast address, there is the problem of determining the sender's notion of a broadcast. Possibilities on a subnetted net include (as net.host) "ThisNet.0", "ThisSubnet.0", "ThisNet.ff", "ThisSubnet.ff", "SomeOtherNetOrSubnet.0", "SomeOtherNetOrSubnet.ff", "0.0" from diskless workstations trying to find out where they are, and perhaps 32 bits of ones. (4.3 recognizes and receives all of the above except for the two "SomeOtherNetOrSubnet". The outgoing broadcast address is the address with a host part of all ones, but this can be set to use other addresses for compatibility.) If two packet-forwarders on the same net disagree as to the broadcast address, chaos will likely ensue. On one of our subnets, each time a router broadcasts an update, it receives 4 redirects from the 3600's on the net that don't understand subnet broadcasts. Another bit of misinformation concerned the Unix insistence on broadcasting this information. The broadcast "rwho" status updates are sent by a user-level program ("/etc/rwhod"). It uses no requests, broadcast or otherwise. If a site doesn't want to run this program, they need only delete the line invoking it from the system startup file. The Unix kernel does not demand or provide any network servers or clients; they are all implemented as user-level processes, and any or all may be omitted or substituted at any site. This includes the routing program "routed", which may be used to manage routing within a set of connected local nets, or which may be omitted in favor of a default gateway or manually-installed routes. The use of multicast for such functions as Unix "rwho" status, routing, ARP requests, etc. is attractive. However, many of these things are not restricted to networks and hardware interfaces that support multicast. By the way, I was interested to hear that the BBN gateways reject all IP packets sent to the hardware broadcast address. It seems that one of the "hosts" on the net will have to answer the broadcast ICMP information requests and network mask requests. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022406350000> Received: from su-pescadero.arpa by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 15:51:16-PST Received: by su-pescadero.arpa with Sendmail; Mon, 24 Feb 86 15:40:43 pst Date: 24 Feb 1986 14:35-PST From: Steve Deering Subject: Re: Ethernet / Unix Rwhod To: Philip Budne Cc: tcp-ip@sri-nic.ARPA Message-Id: <86/02/24 1435.800@su-pescadero.arpa> In-Reply-To: Philip Budne's message of Mon 24 Feb 86 140849-EST > I have often wondered if the problem might be better solved using > "multicast" ethernet addresses. This way only sites which care about > the information ever see it on the host end of the ethernet. > > The problem is specifying how to map IP addresses into outgoing > ethernet multicasts. See RFC966 for a proposal for IP multicasting. I am planning to publish, sometime soon, a complete specification and report on our implementation experience. I believe ALL use of broadcast should be replaced by multicast. Ethernet and all flavours of IEEE 802.2 networks support the proper addressing mode, and interfaces that provide adequate multicast filtering are available, so that we can now obtain the benefits of cheap multidestination (and unknown destination) delivery without interrupting every machine on a network. If it didn't mean changing the whole world, I would advocate changing ARP to use a multicast address. Currently, when we want to use the Internet protocols on our workstations, we must listen to the broadcast address just so we can hear ARPs. That opens us up to all the other broadcast junk that flies around the Stanford subnets (UNIX rwho packets, PUP routing updates, Sun ND boot requests, XNS broadcasts, Chaos broadcasts, DecNet diagnostic packets, etc., etc.) In this kind of environment, there is no type of packet that EVERYONE wants to hear. -- Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022407063700> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 09:20:16-PST Received: from bostonu by csnet-relay.csnet id ab27640; 24 Feb 86 12:18 EST Received: by bu-cs.ARPA (3.0/4.7) id AA12460; Mon, 24 Feb 86 12:06:37 EST Date: Mon, 24 Feb 86 12:06:37 EST From: Barry Shein To: tcp-ip@sri-nic.ARPA Subject: Re: Interesting Ethernet/UNIX 4.2 observation. The fix to UNIX to stop broadcasting rwho information is trivial, remove the lines that start it up from the /etc/rc (text) file. On suns for example the system is delivered with the lines commented out. Another compromise might be to reduce the frequency with which this info updated from one minute to, say, 5 or 10 minutes though this might render it useless to some. Unfortunately that at best just pushes the inevitable back further. Our users here seem to like the 'ruptime' command so much that people have hacked in little forwarders so it crosses from one local ethernet to another and all machines can be seen. I am not saying this is right or wrong, just that people do like the feature and frequent update is probably the only way to acheive it, if I have to order it shut down I bet people scream, but they always scream... Obviously we are running into a problem that is not at all peculiar to UNIX. Anyone could write a program that seems useful but generates lots of traffic on a net. Even if broadcast addresses are priviliged this could make things worse as the user circumvents this by looping through a hosts.txt file on each machine sending, say, udp packets to everyone. On the other hand, the danger of resource hogging has always been a problem, there is nothing new here EXCEPT that it used to be limited to the machines the culprits had accounts on. In other words, I suspect we are dealing with a purely administrative problem here (which *might* have some technical solutions, as usual.) -Barry Shein, Boston University P.S. Just a thought, perhaps the ultimate solution will be smart interfaces that can be told a little about what packets the host is interested in and drop all others, tho again ultimately the problem will be the bandwidth of the cable. sigh. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022409084900> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 12:05:16-PST Received: from bostonu by csnet-relay.csnet id ae29167; 24 Feb 86 14:41 EST Received: from BUCS20 by bu-cs.ARPA (3.0/4.7) id AA00179; Mon, 24 Feb 86 14:09:15 EST Date: Mon 24 Feb 86 14:08:49-EST From: Philip Budne Subject: Ethenet / Unix Rwhod To: tcp-ip%sri-nic@bu-cs.bunet Message-Id: <12185972975.24.BUDD@BUCS20> Regarding rwho haters; Rwhod is a single program that sends broadcast packets on a frequent basis, as well as listens for packets from other sites and writes the received packets to a spool directory. Ruptime and rwho just scan through this directory and type out the information. I have often wondered if the problem might be better solved using "multicast" ethernet addresses. This way only sites which care about the information ever see it on the host end of the ethernet. The problem is specifying how to map IP addresses into outgoing ethernet multicasts. I must confess that I am quite fond of user environment information programs, here we run RWHOD under Unix, TOPS-20, VMS, and on a 3b2. In my previous job inside DEC, I had to fight to install even a finger program and a passive server for it. The argument always involved WASTE OF RESOURCES. These people also frowned on EMACS as a hog, and never took me seriously because I worked on something as silly as a compiler (and one that was written in a high level language!). And then there were the people who frowned at attaching an ethernet to their precious system "causes interrupts" they told me... Philip Budne Boston University / Distributed Systems ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022410205300> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 18:23:58-PST Date: 24 Feb 1986 18:20:53 PST From: POSTEL@USC-ISIB.ARPA Subject: re: interesting ethernet/unix 4.2 observation -- icmp errors To: tcp-ip@SRI-NIC.ARPA See RFC-792 page 1 last paragraph, "To avoid the infinite regress of messages about messages etc., no ICMP messages are send about ICMP messages." --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022420000700> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Mon 24 Feb 86 21:56:42-PST Date: Tue 25 Feb 86 01:00:07-EST From: "J. Noel Chiappa" Subject: Re: workstation != gateway To: karels@MONET.BERKELEY.EDU cc: tcp-ip@SRI-NIC.ARPA, JNC@XX.LCS.MIT.EDU In-Reply-To: <8602250350.AA18567@monet.berkeley.edu> Message-ID: <12186091541.62.JNC@XX.LCS.MIT.EDU> Mike: I never intended to saddle Berkeley with the blame for EGP! I will also say in Berkeley's defense, that I'm not sure that *anyone* recognized that IGP's would have to cart around info as to the source of routes until long after Routed was done. Still, there's *no* upwardly compatible way to extend it that we could find. (Defining a whole new protocol with a different version doesn't count.) One issue that people over look with all these different broadcast addresses is that they can be fairly expensive to check for in gateways. I recognize all the same formats as you do, and in our (additedly hyper-optimized) gateway it's *expensive*! I have figured out some optimization recently, but it's still going to cost a fair chunk. Right now, routing is about 5-10% of fowarding costs. Was it wise to slow down basic packet forwarding, by e.g. 5%, to make broadcast (used on %.01 of packets) work? Unless you want to assume that broadcast packets are flagged by a hardware boardcast address (not a good assumption for a variety of reasons) checking for broadcast will be somewhat expensive. Depending on how multi-cast was added, it might also wind up as somewhat expensive. (BTW, I wish people wwould start using FFFFFFFF for 'local wire broadcast' like the spec recommends; it is so much easier to deal with, and you don't have to think about what parts to mask off and on.) I can't believe that BBN gateways discard input packets sent to the broadcast address. (My gateways discards packets sent to an address that happens to be the local broadcast address, unless specifically told to broadcast the packet, but don't do anything like that to an incoming packet.) What on earth do you gain? Any packet that algorithm would discard could have been sent directly to the gateway in any case, and it prevents some really useful functions. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022501400900> Received: from decwrl.DEC.COM by SRI-NIC.ARPA with TCP; Tue 25 Feb 86 15:49:14-PST Received: by decwrl.DEC.COM (4.22.03/4.7.34) id AA10862; Tue, 25 Feb 86 15:51:13 pst Message-Id: <8602252351.AA10862@decwrl.DEC.COM> Received: from apolling.IMAGEN (apollonet-e.ARPA) by imagen.UUCP; Tue, 25 Feb 86 09:42:47 pst Received: by apolling.IMAGEN; Tue, 25 Feb 86 09:40:09 pst Date: Tue, 25 Feb 86 09:40:09 pst From: imagen!geof@decwrl.DEC.COM (Geof Cooper) To: karels@monet.berkeley.edu.ARPANET Cc: JNC@xx.lcs.mit.edu.ARPANET, tcp-ip@sri-nic.arpa.ARPANET Reply-To: imagen!geof@decwrl.dec.com Phone: (408) 986-9400 (work) Postal-Address: IMAGEN, 2650 San Thomas Expressway, Santa Clara, CA 95052 Subject: Re: workstation != gateway -- CLANG CLANG CLANG > ... Which broadcast address? If the hardware > broadcast address, this can be handled easily on machines that support > only IP and 10Mb/s Ethernet. This is a bit more difficult in the 4.2 > architecture, which supports numerous types of network interfaces > as well as multiple protocol families. By the time IP or ICMP > receives the packet, the hardware sender address is not longer around, > and IP/ICMP neither do ****NOR SHOULD KNOW**** how to tell if a hardware > address is a broadcast. (emphasis added) Excuse me, my bogometer just went off with an almost audible clang. Perhaps you have devised an architecture whereby it is awkward to transmit the information that a packet was broadcast. It does not follow that this information SHOULD be obscured. The reason why it should NOT be obscured is exactly what you and Noel have been talking about -- sometimes a higher level protocol would like to know information available in the network header. For example, an ICMP router should probably flag the case where a packet is forwarded to the interface whence it came. And, as was just mentioned, various services such as ICMP want to make sure that they don't respond with an error packet to a request that was broadcast. Local net information can be thought of as an attribute of the packet, and passed across the network layer in a modular fashion. The multi-interface device layer that we use here at Imagen passes these attributes along with the packet to the higher layer. The format of the local network header is abstracted, and unknown to the higher layer. The attributes passed include the hardware address, which is tagged with the interface type, a la 4.2. A special set of "virtual addresses" is known to the interface. Some of these are things like Internet and XNS-IDP addresses, which are mostly used at higher levels. One is "NULL" -- no interface (black hole), and one is "BROADCAST". A packet sent to virtual address "BROADCAST" causes the interface to make a best effort at broadcasting the packet. Since the internet layer can get hold of the local address, it can have an interface to ARP that says: "by the way, here is a binding that I happen to know is true, please remember it." This greatly enhances ARP performance, and modularity is not violated. The ARP layer is handed two tagged addresses, one a virtual address and one a hardware address, and is told to associate the two. If ARP is not used for particular hardware, the ARP layer just discards the information about that hardware. In summary, you CAN pass broadcast and other network-layer information to higher level protocols, and you can do so in a way that is compatible with the principles of modularity and layering. What's more, higher level protocols SHOULD be able to find out this information; witness that I've given you some good uses for the it. Now, want to fix 4.3? :-) - Geof Cooper ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022509360000> Received: from su-navajo.arpa by SRI-NIC.ARPA with TCP; Tue 25 Feb 86 17:38:40-PST Received: by su-navajo.arpa with Sendmail; Tue, 25 Feb 86 17:36:24 pst Date: 25 Feb 1986 1736-PST (Tuesday) From: Jeff Mogul To: imagen!geof@decwrl.dec.com Cc: JNC@xx.lcs.mit.edu, tcp-ip@sri-nic.ARPA, karels@monet.berkeley.edu Subject: Re: workstation != gateway -- CLANG CLANG CLANG In-Reply-To: imagen!geof@decwrl.DEC.COM (Geof Cooper) / Tue, 25 Feb 86 09:40:09 pst. <8602252351.AA10862@decwrl.DEC.COM> Although I entirely agree with Geof that the 4.2 networking architecture got this part wrong, in fairness to the current crew at Berkeley it should be noted that 4.3 remembers which interface a packet arrived on. This should make it possible, finally, to implement ICMPs such as Address Mask and Information Request, perhaps even Host Redirect, and reverse-path forwarding of broadcasts (if anyone wants it.) Maybe the lesson that should be learned from Geof's message is that the incoming interface is not the only piece of information that should stay stuck onto a packet for its entire lifetime in a gateway. Whether it is reasonable given the current 4.2/4.3 networking architecture to track things such as packet source (data link layer address) was it sent as a broadcast? multicast? how long is it? [so that higher levels don't have to count it again] when it arrived [for accurate metering] etc. may depend on how committed people are to the current model, where only the "data" gets passed between layers. I think this stems from a basic confusion between networking and IPC in 4.2; there seems to me to be an attempt to shoehorn both kinds of communication into a single model. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022511124900> Received: from borax.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 25 Feb 86 13:42:14-PST Received: by borax.LCS.MIT.EDU (4.12/4.7); Tue, 25 Feb 86 16:12:49 est Date: Tue, 25 Feb 86 16:12:49 est From: dab@BORAX.LCS.MIT.EDU (David A. Bridgham) Message-Id: <8602252112.AA01022@borax.LCS.MIT.EDU> To: karels@monet.berkeley.edu Cc: tcp-ip@sri-nic.arpa In-Reply-To: karels@monet.berkeley.edu's message of Mon, 24 Feb 86 19:50:29 -0800 Subject: workstation != gateway When I said that machines should not forward broadcast packets I meant packets that were broadcast on the local net (i.e. addressed to the hardware broadcast address). Sorry for being unclear. I agree that the IP layer *shouldn't* have to know that a packet was broadcast, but until the IP broadcast spec (which is rather recent and most hosts still don't follow) that was the only reliable way to decide that a packet had been broadcast and therefore not forward it. (Gateways still might want to do that for general network robustness reasons.) Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022713504900> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Thu 27 Feb 86 15:48:10-PST Date: Thu, 27 Feb 86 18:50:49 EST From: Mike Muuss To: tcp-ip@sri-nic.arpa Subject: Poor mil/arpa performance As another data point, I offer the following two PING studies, conducted 1820-1840 EST from BRLNET3 (192.5.23.x): ----brl-tac.arpa PING Statistics---- 204 packets transmitted, 203 packets received, 0% packet loss round-trip (ms) min/avg/max = 60/230/4860 ----nosc.arpa PING Statistics---- 38 packets transmitted, 38 packets received, 0% packet loss round-trip (ms) min/avg/max = 320/434/840 ----seismo.css.gov PING Statistics---- 554 packets transmitted, 148 packets received, 73% packet loss round-trip (ms) min/avg/max = 2300/13914/28960 BRL-TAC is on the same MILNET IMP as our (two) Gateways. The max of 4,860ms implies that we are suffering some interface blocking (even though we do RFNM counting), but examining the PING log only showed one such packet. NOSC is on the West Coast (BRL is in Maryland) -- transcontinental MILNET bandwidth seems just fine. SEISMO is on the ARPANET in Washington DC, on the other side of the core from us, yet network performance to them is awful. I mention this because BRL has business (of significant volume) with a number of ARPANET sites, mainly Utah, Seismo, Berkeley, and BBN (yes, the Butterfly part of BBN seems to be on the ARPANET, and having them debug our Butterfly through the core drives them bonkers). DISCUSSION Given the difficulties in getting trunks installed (in understand, and you have my sympathies), I think DCA has done a bang-up job of keeping the MILNET in good, working order. It's effective to use at most any hour, and that is good. They deserve our congratulations! There exists this bottleneck called "the MIL/ARPA" bridges, and the additional complications of the "EGP extra hop" problem which causes up to 3 times as much IMP Trunk bandwitdh to be used for each packet. (ie, BRL-GATEWAY to our EGP-speaking core peer via MILNET, from him to the MIL/ARPA bridge via MILNET, then to the destination via ARPANET). The same sort of thing can happen on returning packets too (depends on whether there is a gateway involved on the ARPANET side, usually yes). CONCLUSIONS The MILNET is sound. Praise DCA! The MIL/ARPA bridges are teetering under the load. They are important. EGP makes it worse. What can we do? Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022719334900> Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Thu 27 Feb 86 21:31:07-PST Return-Path: Received: by seismo.CSS.GOV; Fri, 28 Feb 86 00:33:49 EST Date: Fri, 28 Feb 86 00:33:49 EST From: Rick Adams Message-Id: <8602280533.AA13683@seismo.CSS.GOV> To: mike@BRL.ARPA, tcp-ip@sri-nic.arpa Subject: Re: Poor mil/arpa performance seismo's darpa project admin is physically in the next building, but is connected to a milnet tac. seismo is on the arpanet. The response is SO BAD that we are actively trying to have her and her associates moved from arpa2-mil-tac to arpa3-tac in hopes of her getting characters echoed is less than geological time. It's really hard explaining that the only thing you can do for your "boss" is to run a dedicated line to her office; that her nifty dedicated port on the tac is almost useless. It's kind of scary thinking about how far the packets are really going to traverse that 100 yards seperating us physically. The arpa/milnet bridges are clearly inadequate. ---rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022804032300> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Fri 28 Feb 86 16:33:46-PST To: Rick Adams cc: tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA Subject: Re: Poor mil/arpa performance In-reply-to: Your message of Fri, 28 Feb 86 00:33:49 EST. <8602280533.AA13683@seismo.CSS.GOV> Date: 28 Feb 86 09:03:23 EST (Fri) From: Mike Brescia response is SO BAD that we are actively trying to have her and her associates moved from arpa2-mil-tac to arpa3-tac in hopes of her getting characters echoed is less than geological time. The idea of homing choice between mil- and arpa-net was to put users and hosts on the correct net, or the most used net for that host or person. What kind of terminal is she using, and is she telnet-ing to seismo (10.0.0.25) or going to one of your hosts on local nets? The terminal type would mainly govern what kind of applications she uses; video at 9600 baud would imply using a screen editor, and I find with emacs/pen that psychologically, I expect (DEMAND!) quick response. The TAC software version, and transmit mode effect how much the characters are accumulated above one keystroke per packet. (Is she a 5wpm typist, or 50 wpm?) What about your host and its approach to echo characters? Are you forcing the exchage of 8 packets for every keystroke? ((key + echo) * tcp-ack * rfnm) It's kind of scary thinking about how far the packets are really going to traverse that 100 yards seperating us physically. It's the smallest possible, since the connection is tac - milimp106 - gateway - arpaimp28 - arpaimp25 - seismo (However if the connection is to a local net at seismo, all bets are off. The route is guaranteed to be ++~good.) The arpa/milnet bridges are clearly inadequate. The fact that they are allowed to drop packets (because they have no handle to do flow control) means the end point TCP must make up for it. Lacking a commitment to deliver is a strange way to run a railroad. Let's fix it. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022806164900> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Fri 28 Feb 86 08:09:31-PST Received: by cu-arpa.cs.cornell.edu (5.31/4.30) id AA26657; Fri, 28 Feb 86 11:12:19 EST Date: Fri, 28 Feb 86 11:16:49 est From: swb@devvax.tn.cornell.edu (Scott Brim) Message-Id: <8602281616.AA01291@devvax.tn.cornell.edu> Received: by devvax.tn.cornell.edu (4.12/4.30) id AA01291; Fri, 28 Feb 86 11:16:49 est To: tcp-ip@sri-nic.arpa Subject: Microvax Ultrix version 1.2: Pronet driver that tolerates subnetting?? Does anyone have one or know where I might continue the search? Version 1.2 is the spanking brand new one. Thanks much, Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022809062100> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 28 Feb 86 11:05:52-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Fri, 28 Feb 86 14:06:21 est Date: Fri, 28 Feb 86 14:06:21 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8602281906.AA11127@BORAX.LCS.MIT.EDU> To: swb@devvax.tn.cornell.edu Cc: tcp-ip@sri-nic.arpa In-Reply-To: swb@devvax.tn.cornell.edu's message of Fri, 28 Feb 86 11:16:49 est Subject: Microvax Ultrix version 1.2: Pronet driver that tolerates subnetting?? You might try getting in touch with John Shriver (jas@proteon.arpa) or Mark Rosenstein (mar@proteon.arpa). They both read TCP/IP, so they might get in touch with you... - john romkey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986022809103400> Received: from proteon.arpa by SRI-NIC.ARPA with TCP; Fri 28 Feb 86 11:11:21-PST Date: Fri, 28 Feb 86 14:10:34 EST From: jas@proteon.arpa Subject: pronet driver To: tcp-ip@sri-nic.arpa I will get a Ultrix-32 and -32m V1.2 driver working as soon as DEC gets me a copy of the operating system. Proteon is on an MIT subnet, so we need subnets too. (We jury-rigged V1.1.) Is anyone at DEC Unix Engineering Group listening? I could use a copy soon--I'm paying $400 a month for software support... BTW: this is why v2lni-people@mc.lcs.mit.edu exists. Let's direct this discussion there. John Shriver Proteon ------- ----MESSAGE-END----