----MESSAGE-BEGIN---- [17066.562734287@udel.edu] <1987110102050600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: farber@UDEL.EDU (Dave Farber) Newsgroups: comp.protocols.tcp-ip Subject: Re: supdup protocol Message-ID: <17066.562734287@udel.edu> Date: Sun, 1-Nov-87 07:05:06 EST Article-I.D.: udel.17066.562734287 Posted: Sun Nov 1 07:05:06 1987 Date-Received: Thu, 5-Nov-87 07:40:42 EST References: <8710311649.aa17385@Louie.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 The first notion I know of to separate the front end of an editor and the back end was at least 1963 (the one I know was at BTL back then). (Note the term AT LEAST) Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711011649.AA01017@athos.rutgers.edu] <1987110106494300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <8711011649.AA01017@athos.rutgers.edu> Date: Sun, 1-Nov-87 11:49:43 EST Article-I.D.: athos.8711011649.AA01017 Posted: Sun Nov 1 11:49:43 1987 Date-Received: Thu, 5-Nov-87 20:42:20 EST References: <7603@g.ms.uky.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Now that source routing is becoming accepted, IP gateways are no longer guaranteed to provide security. A host can pretend to be a host on a different subnet, but use source-routing in such a way that the other guy is told to route the packet back thru the bad guy's real address. The bad guy of course does not forward the packet. IP gateways are normally used because they provide isolation. This issue has been discussed so many times that I am reluctant to do it once more. In general, a LANbridge is more reasonable the fewer Ethernets you have (making provisions for future growth), the fewer different kinds of systems you have, and the better central control you have over the systems on your network. We have had disasters that made every VMS system on a network connected by level 2 routing unusable. The problem should not get thru an IP gateway. We have had several disasters that were confined to a single Ethernet only because of the use of IP gateways. However if you have good network monitoring and system management, a stable network/software environment, or a small network, a level 2 system can be made to work. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [278259.871101.JBVB@AI.AI.MIT.EDU] <1987110107075700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge, "equivalence" Message-ID: <278259.871101.JBVB@AI.AI.MIT.EDU> Date: Sun, 1-Nov-87 12:07:57 EST Article-I.D.: AI.278259.871101.JBVB Posted: Sun Nov 1 12:07:57 1987 Date-Received: Thu, 5-Nov-87 20:27:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 We emphasize the security issues involved in "equivalent" hosts in our manuals (it appears at least 3 different places). We advise anyone with security concerns just to "say no" to rsh and rcp, and use ftp or an rexec client we provide instead. However, there are still a lot of people distributing and using Unices derived from 4.2 which require that any host requesting printer services be "equivalent", and our package includes an lpr client... 4.3 fixes this. Are the guilty parties listening? James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [278267.871101.JBVB@AI.AI.MIT.EDU] <1987110107382100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <278267.871101.JBVB@AI.AI.MIT.EDU> Date: Sun, 1-Nov-87 12:38:21 EST Article-I.D.: AI.278267.871101.JBVB Posted: Sun Nov 1 12:38:21 1987 Date-Received: Thu, 5-Nov-87 21:25:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 If you mean Bridge Communications' IP routing products, there is at least one flavor and vintage of them out there which fragments all IP packets longer than 540 bytes. 4bsd and relatives send TCP segments of 512 (552 bytes IP length) bytes by default, and TFTP packets are just large enough to get caught, too. I don't know about the big-machine people, but it has a fairly horrendous effect on the older PC Ethernet cards, which aren't nearly fast enough to catch both fragments reliably. It is even worse when attempting to use one of the public domain software packages that doesn't support IP reassembly. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711011936.AA12106@nic.nyser.net] <1987110112403700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET ("Marty Schoffstall") Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <8711011936.AA12106@nic.nyser.net> Date: Sun, 1-Nov-87 17:40:37 EST Article-I.D.: nic.8711011936.AA12106 Posted: Sun Nov 1 17:40:37 1987 Date-Received: Thu, 5-Nov-87 21:06:32 EST References: <8711011649.AA01017@athos.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Now that source routing is becoming accepted, IP gateways are no longer guaranteed to provide security. A host can pretend to be a host on a different subnet, but use source-routing in such a way that the other guy is told to route the packet back thru the bad guy's real address. The bad guy of course does not forward the packet. Chuck, I don't need source routing to do that. I can do that right now. Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711020243.AA04703@BITSY.MIT.EDU] <1987110116435900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Newsgroups: comp.protocols.tcp-ip Subject: Separation of Layers Message-ID: <8711020243.AA04703@BITSY.MIT.EDU> Date: Sun, 1-Nov-87 21:43:59 EST Article-I.D.: BITSY.8711020243.AA04703 Posted: Sun Nov 1 21:43:59 1987 Date-Received: Fri, 6-Nov-87 22:03:21 EST References: <8710312107.AA14385@PARIS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 I should point out that at MIT we no longer use network addresses as a form of authenticity. We now use our encryption based "Kerberos" authentication service. The code you wrote to use the subnet as a means of determining authentication has long since been retired. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711062349.AA04106@ucbvax.Berkeley.EDU] <1987110203002500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: snorthc@NSWC-OAS.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <8711062349.AA04106@ucbvax.Berkeley.EDU> Date: Mon, 2-Nov-87 08:00:25 EST Article-I.D.: ucbvax.8711062349.AA04106 Posted: Mon Nov 2 08:00:25 1987 Date-Received: Sun, 8-Nov-87 22:43:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 OK, I'll bite. We have been looking at NFS as a UNIX/VMS server solution for PCs. From the begining of the investigation we were looking for things like the 'huge security holes'. Somehow I must have missed it. I certainly have heard Netters alluding to such a thing. Would you be willing to spell out the problem, perhaps even complete with recommended solutions or workarounds? I may just be a hopeless case. I had never considered using an IP gateway for security purposes either. When I read you message a tiny light went on in my head for just a second... then I started thinking about name/domain serving, additional levels of indirection, and so forth and the light went out. Do you encrypt your secure side? Stephen Northcutt (snorthc@nswc-g.arpa) (703) 663-7796 office, (703) 663-7191 lab ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711040945.AA17936@ucbvax.Berkeley.EDU] <1987110203383800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: snorthc@NSWC-OAS.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <8711040945.AA17936@ucbvax.Berkeley.EDU> Date: Mon, 2-Nov-87 08:38:38 EST Article-I.D.: ucbvax.8711040945.AA17936 Posted: Mon Nov 2 08:38:38 1987 Date-Received: Sat, 7-Nov-87 09:58:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 James, You have my complete attention. We have a growing investment in Bridge Communications' IP routing products. We also have a sizable, but static investment in older PC ethernet cards (3C500/1, NI5010 ). One such Bridge box that has served us well in the past is the GS-3. A box that may have a place in our future is the IB-1. You can probably guess which PCIP we are using. Most of our hosts are 4bsd. Are we in danger, I suspect we are running either the latest, or next to latest rev. of software for all products? We certainly haven't noticed a problem. The cable is monitered for problems with a lanalyser from time to time. Perhaps this fragmentation problem is limited to an older rev of Bridge s/w, at least I hope so. In the two years I have been here there has been a steady parade of s/w & ROM upgrades from Bridge. The only time we have ever noticed a problem was with a DEC DEMPER of all things. It got connected to the cable with an improperly-labeled- but-suspected-ver1-xceiver. The 3c500s connected by thin net started losing about every other packet. The 3c505s were fine. Changing the xceiver fixed things. In any case whose routing box do you recommend? Stephen Northcutt (snorthc@nswc-g.arpa) Disclaimer: I haven't had my coffee yet! Only relationship I have with companies explicitly/implicitly mentioned is as a happy customer. Bridge is asked to forgive me for mangling their part #'s (GS/3). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1408@aecom.YU.EDU] <1987110204511800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: naftoli@aecom.YU.EDU (Robert N. Berlinger) Newsgroups: comp.protocols.tcp-ip Subject: Subnetting: I'm not sure I understand Message-ID: <1408@aecom.YU.EDU> Date: Mon, 2-Nov-87 09:51:18 EST Article-I.D.: aecom.1408 Posted: Mon Nov 2 09:51:18 1987 Date-Received: Fri, 6-Nov-87 23:37:08 EST Organization: Albert Einstein College of Medicine, NY Lines: 8 I'm not sure I understand subnetting fully. Assuming you have a class C address -- will subnetting allow you to have more than 255 hosts on the network? -- Robert N. Berlinger naftoli@aecom.yu.edu Supervisor of Systems Support Albert Einstein College of Medicine Compuserve: 73047,741 UUCP: ...{philabs,cucard,pegasus,rocky2}!aecom!naftoli GEnie: R.Berlinger ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711021538.AA27877@ucbvax.Berkeley.EDU] <1987110205385900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: pmdf over tcp-ip Message-ID: <8711021538.AA27877@ucbvax.Berkeley.EDU> Date: Mon, 2-Nov-87 10:38:59 EST Article-I.D.: ucbvax.8711021538.AA27877 Posted: Mon Nov 2 10:38:59 1987 Date-Received: Thu, 5-Nov-87 23:36:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Ed, The answer is yes -- at least, recent versions of VMS PMDF can run SMTP over TCP. Craig PS: For those of you who don't know what PMDF is... There are several versions of PMDF (which in turn are based on MMDF). VMS PMDF is Ned Freed's version of PMDF which is loosely based on the original Unix PMDF by Ira Winston, which in turn is based on early versions of MMDF (by Dave Crocker). The 'P' stands for Pascal -- it was originally a simple mail system designed for use with CSNET's PhoneNet. The VMS version has grown to rival MMDF in size and complexity. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711021615.AA05254@ale.TRW.COM] <1987110206151200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geoffb@ALE.TRW.COM (G. Geoffrey Baehr) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet bridge Message-ID: <8711021615.AA05254@ale.TRW.COM> Date: Mon, 2-Nov-87 11:15:12 EST Article-I.D.: ale.8711021615.AA05254 Posted: Mon Nov 2 11:15:12 1987 Date-Received: Sat, 7-Nov-87 09:13:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Concerning Charles Hedrick's note about level 2 bridges, it is precisely the quality of bridge management software that allows one to depend on a level 2 solution. What information does exist from these bridges currently seems to be non-uniform and of questionable value. Is there some bridge out there which does have a specified reporting mechanism,or one which may be queried in some manner. I have in mind the RBMS (Remote Bridge Management Software) from DEC, but alas, this spec is not released by DEC to we common folk. Without a diagnostic/reporting mechanism, level 2 bridges appear to offer more potential for net-wide disaster. Geoffrey Baehr I would be interested in knowing whether any vendor intends to implement portions of the HEMS work in their current or future products. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711021615.AA00166@braden.isi.edu] <1987110206153400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ..."layering violations" Message-ID: <8711021615.AA00166@braden.isi.edu> Date: Mon, 2-Nov-87 11:15:34 EST Article-I.D.: braden.8711021615.AA00166 Posted: Mon Nov 2 11:15:34 1987 Date-Received: Sat, 7-Nov-87 08:54:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Yes, I know they're *supposed* to. I meant to say that I've seen many gateways use the destination IP address of the original datagram as the source address for the IP datagram containing the ICMP message, and this makes it impossible to discern where the problem is. One implementation around here returns every broadcast it sees with a "port unreachable" ICMP message and puts the IP broadcast address in the IP source field! Phil Phil, I wish you would name names. Being coy about whose box is screwing up isn't doing anyone a favor. Since there is no Internet Conformance testing service, we have to collaborate as a group to "encourage" conformance from the vendors. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711021135.aa07984@Huey.UDEL.EDU] <1987110206351600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: On broadcasts, congestion and gong Message-ID: <8711021135.aa07984@Huey.UDEL.EDU> Date: Mon, 2-Nov-87 11:35:16 EST Article-I.D.: Huey.8711021135.aa07984 Posted: Mon Nov 2 11:35:16 1987 Date-Received: Sun, 8-Nov-87 22:54:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Mike, Thanks very much for thie information. I (and Bob Braden, I'm sure) will be looking forward to your definitive statements on how 4.3+ conforms, as well as any comments you have on what should be changed for the next draft of the document. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12347435144.54.PADLIPSKY@A.ISI.EDU] <1987110207270000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: ..."layering violations" Message-ID: <12347435144.54.PADLIPSKY@A.ISI.EDU> Date: Mon, 2-Nov-87 12:27:00 EST Article-I.D.: A.12347435144.54.PADLIPSKY Posted: Mon Nov 2 12:27:00 1987 Date-Received: Fri, 6-Nov-87 22:48:21 EST References: <1505@faline.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Phil-- A sidelight on keeping connections open "forever" seems appropriate, just in case anybody doesn't attach enough strength to the quotation marks you rightly used: In the early days of the Multics "NCP" [sic], we discovered that we were sending "RST"s (the old Host-Host Protocol Reset command, which was sent whenever an NCP came back up, to "everybody" --well, you could do that sort of thing when there weren't four dozen Hosts in the world) without end to a particular Host. It turned out the problem was that we were getting "Incomplete Transmission" from our IMP, so we tried again, since that code was supposed to mean that a temporary problem had prevented successful transmission; however, the Host in question had somehow jumpered their IMP interface in such a fashion as to convince their IMP that they really were up when they weren't and so we got the code in a circumstance where we really shouldn't have. Naturally, we put a limit on the retransmisions after an Incomplete Transmission was encountered after that (and we probably should have had one in the first place). The moral does seem worth pointing out, though: keep connections open for appropriately small values of forever. (For example, if you happen to get a Host Down, you might as well close even if you're only a daemon, since the other side should come up again out of Sequence Number synch--shouldn't it?) cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711021732.AA04627@monk.proteon.com] <1987110207325200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: TCP and teaching bridges and routers about routes Message-ID: <8711021732.AA04627@monk.proteon.com> Date: Mon, 2-Nov-87 12:32:52 EST Article-I.D.: monk.8711021732.AA04627 Posted: Mon Nov 2 12:32:52 1987 Date-Received: Sat, 7-Nov-87 04:20:31 EST References: <8710271711.AA06964@opal.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 > Interestingly enough, this is an area where the source routing > scheme of IBM/ 802.5 is superior to the "proxy-ARP" routers (and maybe to > the TransLan ether bridge schemes). With the latter approaches, if a > bridge/router which is not within "local broadcast" range fails, then there > is no way for the local TCP to request that the path be redetermined. > In the source route (802.5 variety) scheme, the local TCP merely causes a > new route to be determined via a new "all rings broadcast" XID. It is correct that the TCP cannot ask a DEC LANbridge (or other equivalenly implemented learnig bridges) to try again on the route. That is because the management protocols they use will detect the failure before the TCP does, activate a new (previously backup) bridge, and dynamically rethread the route. The whole point of a LEARNING bridge is that you don't have to TEACH it. You do have to TEACH an IBM Token-Ring bridge. Of course, IP routers running dynamic routing protocols offer exactly the same advantages. They too will reconfigure faster than TCP can notice when one intermediate path fails. The host does not need to ask for any help, at most it will get an ICMP redirect. The only case where this advantage of routers will fail is in the ARP proxy subnet hack. This is why ARP proxy subnetting REQUIRES ARP cache aging, which pure ARP, used for its intended purpose, does not. That's why ARP proxy subnetting is a workaround, and not a standard. Oh yes, you lose all the advantages of the frame-copied and address-recognized bits in 802.5 when you use IBM bridges. All that frame copied means to the sender is that the first bridge copied it. A later bridge may have to drop it (congestion), or be dead. You don't lose these advantages with routers, because they try again if they don't get frame-copied. This is why a ring makes a good router backbone. So far as I can see, IBM Token-Ring source routing combines the bad aspects of routing and bridging into a big layering violation. It will persist, however, due to SNA's reliance on it. (These are my opinions, and have not been certified or blessed by Proteon.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [698@unmvax.unm.edu] <1987110209342700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcdermot@merlin.unm.edu (John McDermott) Newsgroups: comp.protocols.tcp-ip Subject: TCP/DECnet interchange router for VMesS Message-ID: <698@unmvax.unm.edu> Date: Mon, 2-Nov-87 14:34:27 EST Article-I.D.: unmvax.698 Posted: Mon Nov 2 14:34:27 1987 Date-Received: Fri, 6-Nov-87 03:39:52 EST Sender: news@unmvax.unm.edu Reply-To: mcdermot@merlin.UUCP (John McDermott) Lines: 17 Organization:Applied Technology Asociates I have a problem which I hope someone has already solved: I have a TCP/IP net and a large DECnet net both served by a common VAX (vms). Some hosts on the decnet network also run tcp/ip. All tcp is CMU/TEK for vms. Now the question: are there drivers to encapsulate ip packets, send them over the DECnet and then make them available for retransmission at the other end? I need this because my VAX with Decnet is connected to the rest of the DECnet network by a 56kb line and that line cannot be used for both decnet and tcp/ip (for political reasons at least). Any help would be really appreciated. Try afwl-vax.arpa!atavax.decnet!mcdermott or maybe there is enough interest here you should just post any results. Thanks. --john John McDermott ARPA: mcdermott%atavax.decnet@afwl-vax.arpa Applied Technology Assoc W (505) 247-8371 1900 Randolph SE Albuquerque, NM 87106 H (505) 255-7796 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1197@omepd] <1987110211425100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wire@iwarpj.intel.com (Wire Moore) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP Slang Glossary Message-ID: <1197@omepd> Date: Mon, 2-Nov-87 16:42:51 EST Article-I.D.: omepd.1197 Posted: Mon Nov 2 16:42:51 1987 Date-Received: Fri, 6-Nov-87 23:06:48 EST Sender: news@omepd Reply-To: wire@iwarp.intel.com (Wire Moore) Organization: Intel Corp., JF1, Hillsboro, Oregon Lines: 7 The reading getting a might thick for me, and others I suspect, who are green to this group. Would someone post a glossary of the slang this group favors? Thanks. [fuzzball? bogon? gong?] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711070425.AA10823@ucbvax.Berkeley.EDU] <1987110211491400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: david@E.MS.UKY.EDU (David Herron E-Mail Hack) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <8711070425.AA10823@ucbvax.Berkeley.EDU> Date: Mon, 2-Nov-87 16:49:14 EST Article-I.D.: ucbvax.8711070425.AA10823 Posted: Mon Nov 2 16:49:14 1987 Date-Received: Mon, 9-Nov-87 02:39:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 40 Well ... the only hole which I know by heart is the following situation. You have someone with a workstation and he has the root password for his workstation. He also has some local disk storage. He makes a setuid shell on his local disk. Then he goes over to another system and executes his shell, thus giving him root on that system. In our case we use equiv hosts to simplify a lot of things, but don't use fully transitive equivalancies in a lot of cases. The reason this is a hole has to do with Unix using a simple integer to encode the user id ... If there were some sort of indication of the host that the user id pertained to ... Oh, in the particular situation, the user MUST have root access to his own workstation so that he can properly do his research. Fortunately he's a nice guy ... :-) For a good time read section 2.2.2. of Suns NFS Protocol Specification. It talks about the above bug and others. As for using an IP gateway for security ... Well, consider me something of a beginner in TCP/IP issues. But I still have to manage the local end of our net, and give advice to the people around me. I understand enough that the idea of a gateway knowing that a certain class of IP numbers can only come from one side of the gateway makes sense. But this source routing stuff which someone mentioned is unfamiliar territory to me. I've been reading the discussion about source routing and know that it apparently only applies to token ring. However, it seems that if there is to be support for source routing in the kernal, then you could use it from any sort of network hardware. Is the idea with source routing to encapsulate an IP packet inside another one which is addressed to a gateway machine, and the encapsulating packet says where to send the encapsulated packet? The use of IP gateways to wall off sections of the net to contain IP storms makes sense ... We may set things up that way ... does anyone have any recommendations on a good IP gateway? -- <---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet <---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- "The market doesn't drop hundreds of points on a normal day..." -- <---- Fidelity Investments Co73D X473D ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110211491401> Received: from e.ms.uky.edu by SRI-NIC.ARPA with TCP; Mon 2 Nov 87 14:18:29-PST Date: Mon, 2 Nov 87 16:49:14 EST From: David Herron E-Mail Hack To: snorthc@NSWC-OAS.ARPA cc: tcp-ip@SRI-NIC.ARPA, david@a.ms.uky.edu Subject: Re: Ethernet Bridge Well ... the only hole which I know by heart is the following situation. You have someone with a workstation and he has the root password for his workstation. He also has some local disk storage. He makes a setuid shell on his local disk. Then he goes over to another system and executes his shell, thus giving him root on that system. In our case we use equiv hosts to simplify a lot of things, but don't use fully transitive equivalancies in a lot of cases. The reason this is a hole has to do with Unix using a simple integer to encode the user id ... If there were some sort of indication of the host that the user id pertained to ... Oh, in the particular situation, the user MUST have root access to his own workstation so that he can properly do his research. Fortunately he's a nice guy ... :-) For a good time read section 2.2.2. of Suns NFS Protocol Specification. It talks about the above bug and others. As for using an IP gateway for security ... Well, consider me something of a beginner in TCP/IP issues. But I still have to manage the local end of our net, and give advice to the people around me. I understand enough that the idea of a gateway knowing that a certain class of IP numbers can only come from one side of the gateway makes sense. But this source routing stuff which someone mentioned is unfamiliar territory to me. I've been reading the discussion about source routing and know that it apparently only applies to token ring. However, it seems that if there is to be support for source routing in the kernal, then you could use it from any sort of network hardware. Is the idea with source routing to encapsulate an IP packet inside another one which is addressed to a gateway machine, and the encapsulating packet says where to send the encapsulated packet? The use of IP gateways to wall off sections of the net to contain IP storms makes sense ... We may set things up that way ... does anyone have any recommendations on a good IP gateway? -- <---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet <---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- "The market doesn't drop hundreds of points on a normal day..." -- <---- Fidelity Investments Corporation ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711090631.AA18868@ucbvax.Berkeley.EDU] <1987110211550100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: RAF@NIHCU.BITNET ("Roger Fajman") Newsgroups: comp.protocols.tcp-ip Subject: Multiple subnets on one physical net Message-ID: <8711090631.AA18868@ucbvax.Berkeley.EDU> Date: Mon, 2-Nov-87 16:55:01 EST Article-I.D.: ucbvax.8711090631.AA18868 Posted: Mon Nov 2 16:55:01 1987 Date-Received: Wed, 11-Nov-87 04:17:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 MAIL FROM RAF SATURDAY 10/31/87 8:21:02 P.M. I guess that this may have been discussed before, but due to a problem with our mailer here I wasn't getting much mail from this list at the time. Anyway, we recently acquired a class B network number for our planned campus network and the issue arises about how to divide the 16-bit address space between subnet numbers and host numbers. If we make the subnet field small, we probably won't have enough subnet numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each) and a lot of address space is wasted on small subnets. If we make the subnet field large, we won't have enough host numbers for our largest subnet (an 8 bit subnet field gives 254 networks of 254 nodes each). This naturally leads to the question: can multiple subnet numbers be assigned to the same physical network? Since we plan to use Proteon p4200 Gateways for at least some things, I called Proteon and asked them. They told me that there is no problem, as each network interface can be assigned up to 16 IP addresses, thus allowing it to respond to an IP address for each of up to 16 subnets that reside on the same physical network. I was told that this was desirable because many hosts require that any gateway that they use be on their own subnet. Now I was recently shown a copy of a message from last July that said that in such a situation, a Unix system would receive Ethernet broadcast packets containing IP broadcast packets for other subnet numbers, not realize that they were broadcast packets for another subnet, and try to process (forward or redirect) them in some way. More recently, I received a message on this list that said that a Unix system would not try to perform gateway functions unless it had more than one network interface, regardless of how its parameters were set. Anyway, what is the truth? Can we assign multiple subnet numbers to the same physical network or not? What have others done about this problem? Roger Fajman RAF@NIHCU.BITNET National Institutes of Health ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110211550101> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 3 Nov 87 12:59:18-PST Received: from NIHCU.BITNET by wiscvm.wisc.edu ; Mon, 02 Nov 87 16:35:09 CDT To: TCP-IP@SRI-NIC.ARPA From: "Roger Fajman" Date: Mon, 02 Nov 87 16:55:01 EST Subject: Multiple subnets on one physical net MAIL FROM RAF SATURDAY 10/31/87 8:21:02 P.M. I guess that this may have been discussed before, but due to a problem with our mailer here I wasn't getting much mail from this list at the time. Anyway, we recently acquired a class B network number for our planned campus network and the issue arises about how to divide the 16-bit address space between subnet numbers and host numbers. If we make the subnet field small, we probably won't have enough subnet numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each) and a lot of address space is wasted on small subnets. If we make the subnet field large, we won't have enough host numbers for our largest subnet (an 8 bit subnet field gives 254 networks of 254 nodes each). This naturally leads to the question: can multiple subnet numbers be assigned to the same physical network? Since we plan to use Proteon p4200 Gateways for at least some things, I called Proteon and asked them. They told me that there is no problem, as each network interface can be assigned up to 16 IP addresses, thus allowing it to respond to an IP address for each of up to 16 subnets that reside on the same physical network. I was told that this was desirable because many hosts require that any gateway that they use be on their own subnet. Now I was recently shown a copy of a message from last July that said that in such a situation, a Unix system would receive Ethernet broadcast packets containing IP broadcast packets for other subnet numbers, not realize that they were broadcast packets for another subnet, and try to process (forward or redirect) them in some way. More recently, I received a message on this list that said that a Unix system would not try to perform gateway functions unless it had more than one network interface, regardless of how its parameters were set. Anyway, what is the truth? Can we assign multiple subnet numbers to the same physical network or not? What have others done about this problem? Roger Fajman RAF@NIHCU.BITNET National Institutes of Health ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3284@ames.arpa] <1987110211555800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rfox@amelia (Richard Fox) Newsgroups: comp.protocols.tcp-ip Subject: Re: my subscription Message-ID: <3284@ames.arpa> Date: Mon, 2-Nov-87 16:55:58 EST Article-I.D.: ames.3284 Posted: Mon Nov 2 16:55:58 1987 Date-Received: Fri, 6-Nov-87 03:26:00 EST References: <8710292039.AA12844@decwrl.dec.com> Sender: usenet@ames.arpa Reply-To: rfox@amelia.UUCP (Richard Fox) Organization: NASA Ames Research Center, Mountain View, CA Lines: 4 Please add me to the distribution list please. rfox@ames-amelia ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711022230.AA00742@orville.nas.nasa.gov] <1987110212302500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lekash@ORVILLE.NAS.NASA.GOV Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet - Hyperchannel Gateway Message-ID: <8711022230.AA00742@orville.nas.nasa.gov> Date: Mon, 2-Nov-87 17:30:25 EST Article-I.D.: orville.8711022230.AA00742 Posted: Mon Nov 2 17:30:25 1987 Date-Received: Mon, 9-Nov-87 04:32:16 EST References: <400@mn-at1.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 >From our experience, the actual sustained rate is 600/sec, assuming no associated data and no contention on a dedicated trunk. [Measured between two Crays on a one meter coax trunk.] Measured between two crays running what? We measured 5mbits/second effective data from silicon graphics workstations running unix to a cray2 running unix. Using a 4096 associated data, and a little arithmetic, this is 1220 packets/second. The cray2 has an A130, the workstation an A400 hyperchannel adapter. 17 mbit/sec was measured memory to memory on TCP on the same cray2, going out one adapter, and in another. I will admit that this is thus a somewhat suspect number, but we don't have a second cray2, yet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1511@faline.bellcore.com] <1987110213111600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@faline.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: ..."layering violations" Message-ID: <1511@faline.bellcore.com> Date: Mon, 2-Nov-87 18:11:16 EST Article-I.D.: faline.1511 Posted: Mon Nov 2 18:11:16 1987 Date-Received: Fri, 6-Nov-87 04:41:21 EST References: <8711010759.AA08856@okeeffe.Berkeley.EDU> Organization: Bell Communications Research, Inc Lines: 49 Summary: I still don't see the need for TCP keep-alives In article <8711010759.AA08856@okeeffe.Berkeley.EDU>, karels@OKEEFFE.BERKELEY.EDU (Mike Karels) writes: > Two comments on your recent message. First, about TCP behavior > when ICMP unreachables are received: I definitely agree that TCP > ought not to quit when it receives an unreachable. However, in Unix > and probably most other systems, it's hard to report "soft" errors > to a network client. In 4.3, I chose to return a single error > on the next send or receive, but the TCP connection remains open. > Unfortunately, most network applications carefully check for errors > on each send/receive, and they give up on the first error. > (4.2 aborted the connection when ICMP errors were received, > and thus the application had no chance to keep trying.) TCP doesn't return an error to the application when it retransmits, so why should it do so when it receives a sporadic ICMP unreachable message? I think a better approach would be for TCP to ignore these messages, except to keep the last one or two around in case the application specifically wanted to see them (e.g., by doing a special ioctl on the socket). > I also agree that you're right to distinguish between interactive > network users and automatic daemons. However, it's precisely for > the daemons that are willing to wait patiently forever that "keep alive" > messages are needed. Although the telnet client will give up and close > the connection manually, there needs to be a way to prevent systems > from accumulating useless, disconnected telnet servers and other such > trash. Most application-level programs don't have their own keep-alive > or are-you-there to detect network failure. For those reasons, we use > TCP-level keepalives (which are also not well provided-for at this level) > only on network servers that don't have their own time-out scheme. I strongly disagree that this should be done at the TCP level. I took keepalives out of most of our systems some time ago. It's really nice not to have to recreate a half dozen rlogin windows on my Sun each time my SLIP link drops and has to be redialed. It's also nice not to have a steady stream of useless traffic on my amateur packet radio channel when somebody logs in but remains idle for long periods. The only way you accumulate useless, disconnected telnet servers is when the client machines crash. If you *really* want to get rid of them, just have a shell script do a write to anybody idle for more than X days -- the data will trigger a TCP Reset which will close the connection for you. On the other hand, while they are aesthetically unpleasing, idle sessions really don't hurt anything -- main memory is cheap and paging memory even cheaper. A year or two ago I thought as you do on keepalives, but a discussion with Jon Postel turned me around. :-) Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1512@faline.bellcore.com] <1987110213543100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@faline.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: details on misbehaving IP implementations Message-ID: <1512@faline.bellcore.com> Date: Mon, 2-Nov-87 18:54:31 EST Article-I.D.: faline.1512 Posted: Mon Nov 2 18:54:31 1987 Date-Received: Fri, 6-Nov-87 07:13:19 EST Organization: Bell Communications Research, Inc Lines: 23 Keywords: broadcast funnies I've been asked to be less coy about mentioning misbehaving host implementations by name. Fine. Herewith is a brief summary of what I see on our own network after about 5 minutes of monitoring with a "bogon trap" of my own design: 1. A bunch of Excelan hosts emitting rwho/UDP broadcasts with 128.96.0.0 (our local broadcast address) in *both* the IP source and destination fields. 2. A Vax running 4.3BSD (or at least that's what the login banner says) that returns an ICMP Unreachable Port to the sender of each RIP packet it sees. 3. A Vax running MicroVMS V4.6 that's doing the same thing. 4. A big group of Symbolics LISP machines that return ICMP Unreachable Protocol messages in response to IP broadcasts with a locally-defined protocol field (255). None of these machines are under my administrative control so I cannot verify actual software version numbers, etc. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12347511851.23.AI.CLIVE@MCC.COM] <1987110214282200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AI.CLIVE@MCC.COM (Clive Dawson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Security and Access Restrictions Message-ID: <12347511851.23.AI.CLIVE@MCC.COM> Date: Mon, 2-Nov-87 19:28:22 EST Article-I.D.: MCC.12347511851.23.AI.CLIVE Posted: Mon Nov 2 19:28:22 1987 Date-Received: Sat, 7-Nov-87 10:24:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 If you have a serious interest in security then simply checking the IP addresses is not adequate because it is very easy to spoof IP addresses. Is it really THAT easy to spoof IP addresses? I agree that it's easy for me to put a bogus IP address on an outbound packet. But how do I get the remote host to send packets back to me instead of to the host I'm spoofing? Perhaps an improvement to the described security mechanism would be to match the various addresses appearing in the packet (IP header, TCP or UDP header, etc.) to see if there are disagreements. Clive ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711031325.AA22918@PARIS.MIT.EDU] <1987110303255600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: Security and Access Restrictions Message-ID: <8711031325.AA22918@PARIS.MIT.EDU> Date: Tue, 3-Nov-87 08:25:56 EST Article-I.D.: PARIS.8711031325.AA22918 Posted: Tue Nov 3 08:25:56 1987 Date-Received: Mon, 9-Nov-87 06:45:26 EST References: <8710302306.AA05217@rt234.usc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 I am interested in learning about Visa. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [279018.871103.JBVB@AI.AI.MIT.EDU] <1987110306462200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <279018.871103.JBVB@AI.AI.MIT.EDU> Date: Tue, 3-Nov-87 11:46:22 EST Article-I.D.: AI.279018.871103.JBVB Posted: Tue Nov 3 11:46:22 1987 Date-Received: Wed, 11-Nov-87 04:08:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 I checked, and the specific model which does the fragmentation is the Bridge GS/3. The guy who has this problem told me that his gateway gurus had done all they could to try to get this fixed, but that it hadn't been, at least the last time he checked (~60 days ago). He says they tell him the GS/7 fixes these problems, and his site is apparently converting. If your network monitoring doesn't reveal any fragmentation of 552-byte IP length datagrams (512 byte TCP segment + headers), then you must have gotten a fix, or else your configuration is enough different that it doesn't happen. Our code did not handle IP reassembly before version 1.16. James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12347713194.16.RTB@SEED.AMS.COM] <1987110308542200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: RTB@SEED.AMS.COM (Robert Baynes) Newsgroups: comp.protocols.tcp-ip Subject: TRANSLAN III Questions Message-ID: <12347713194.16.RTB@SEED.AMS.COM> Date: Tue, 3-Nov-87 13:54:22 EST Article-I.D.: SEED.12347713194.16.RTB Posted: Tue Nov 3 13:54:22 1987 Date-Received: Tue, 10-Nov-87 04:30:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 38 AMS is an organization with two geographically separate offices, one in Providence, RI and one in Ann Arbor, MI. We are in the process of upgrading the modems on the leased line between the two offices from 9.6 Kbaud to 19.2 Kbaud. We are also considering installing at both sites a product from Vitalink called Translan III. This would eliminate a multiplexor setup on both ends. At the Ann Arbor end, the Translan would be connected to an Ethernet on which Interlan NTS100 XNS terminal servers are primary hardware for connecting terminals. At the Providence end, the Translan would be connected to an Ethernet on which NTS100s are wired to DECserver 100 and 200 LAT terminal servers. This would permit Ann Arbor users to connect to systems in the Providence office which support only LAT. With this configuration, only XNS terminal server traffic and occasional TCP/IP file transfer traffic would be transferred over the leased line between Providence and Ann Arbor (i.e., no LAT traffic would need to be transferred). I would like to hear from anyone who is using a Translan III in a similar configuration. I would especially like to hear from people who are using the product to pass terminal server traffic between Ethernets using a leased line. Thanks for any information. Bob Baynes American Mathematical Society Internet: RTB@SEED.AMS.COM (RTB@[192.16.180.3]) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711061102.AA20140@ucbvax.Berkeley.EDU] <1987110310560400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: snorthc@NSWC-OAS.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <8711061102.AA20140@ucbvax.Berkeley.EDU> Date: Tue, 3-Nov-87 15:56:04 EST Article-I.D.: ucbvax.8711061102.AA20140 Posted: Tue Nov 3 15:56:04 1987 Date-Received: Sun, 8-Nov-87 14:54:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 James, Thank you for the follow up on the Bridge GS/3. It does seem that the GS/3 might be one of the weaker links in Bridge's Product suite. If FTP software did not support reassembly of packets before 1.16 that helps to explain why we could not discern any difference between its performance* and PCIPs (assuming any packets ever got fragmented). I do seem to remember FTP v. 1.11 or 1.12's SMTP used to make the GS/3s complain, 1.14 fixed that. While GS/3s on the whole (and at a time there were far less alternatives available) seemed to work quite well, I do have one war story. We had a T1 link connecting two remote geographic sites with a GS/3 at each end. Whenever the T1 link went down (often in the boonies) the GS/3s would go off into space and someone would have to press a black button on the front of each GS/3. However Bridge has long since delivered a s/w upgrade and the morning ritual of resetting the GS-3 has been retired. I wonder who makes the best gateway-in-a-box (this week). Stephen Northcutt (snorthc@nswc-g.arpa) * we have never benchmarked TFTP and rarely use it, another reason we may not have suffered too much. Disclaimer: Only relationship between Bridge, FTP s/w and me is I try to buy what they try to sell. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8215@oliveb.UUCP] <1987110312023000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jerry@oliveb.UUCP (Jerry Aguirre) Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip Subject: Can I print on a terminal server port Message-ID: <8215@oliveb.UUCP> Date: Tue, 3-Nov-87 17:02:30 EST Article-I.D.: oliveb.8215 Posted: Tue Nov 3 17:02:30 1987 Date-Received: Sat, 7-Nov-87 03:59:36 EST Organization: Olivetti ATC; Cupertino, Ca Lines: 11 Keywords: print server telnet I would like to be able print from a 4.3BSD Unix system on a printer connected to a TCP/IP terminal server. With the increasing use of terminal servers, some hosts being configured with no serial ports, this seems like a common enough problem that someone might have already done it. Please send me mail if you have tried this. I will summarize responses to the net. Jerry Aguirre Systems Administration Olivetti ATC ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1940@uwmacc.UUCP] <1987110315392600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ejnorman@uwmacc.UUCP (Eric Norman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <1940@uwmacc.UUCP> Date: Tue, 3-Nov-87 20:39:26 EST Article-I.D.: uwmacc.1940 Posted: Tue Nov 3 20:39:26 1987 Date-Received: Sat, 7-Nov-87 09:07:49 EST References: <8710302138.AA04810@ucbvax.Berkeley.EDU> <7603@g.ms.uky.edu> Reply-To: ejnorman@unix2.macc.wisc.edu Organization: UW-Madison Academic Computer Center Lines: 25 In article <7603@g.ms.uky.edu> david@ms.uky.edu (David Herron) asks: > > What do people think about the security issues? Right now, the > concern is someone creating a situation where one of our equiv > hosts is down, the bad-guy boots a machine that says he is > the now-down machine and creates an suid shell on another of Well let's see. Suppose I have hosts Bossie and Elsie here that trust each other and Bossie goes down and you're going to try to make Elsie think you're Bossie from the other side of a LAN-100. Now, what I'm gonna do is put a permanent entry in Elsie's ARP cache with Bossie's IP number and ethernet address. Well, I reckon you can get a packet to Elsie that she'll think came from Bossie, but I'd like to know how you're going to see the packets coming from Elsie destined for Bossie. Eric Norman Internet: ejnorman@unix2.macc.wisc.edu UUCP: ...{allegra,ihnp4,seismo}!uwvax!ejnorman Life: Detroit!Alexandria!Omaha!Indianapolis!Madison!Hyde "Tis far easier for a peacock to show his true colors than it is for a lion to swallow his pride." -- Arte Johnson -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711040111.aa00949@VMB.BRL.ARPA] <1987110320110400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kermit@BRL.ARPA (Chuck Kennedy) Newsgroups: comp.protocols.tcp-ip Subject: Wretched MIL/ARPA Gateway performance Message-ID: <8711040111.aa00949@VMB.BRL.ARPA> Date: Wed, 4-Nov-87 01:11:04 EST Article-I.D.: VMB.8711040111.aa00949 Posted: Wed Nov 4 01:11:04 1987 Date-Received: Wed, 11-Nov-87 04:28:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 58 This evening, network performance was somewhat less that "optimal". The results are shown in the table below and represent the results of running ping for at least 2 minutes to check out round-trip packet delay and packet loss to various selected hosts. All tests were run from the host brl-vmb.arpa. The first interesting finding is that performance on the Milnet is quite good. Even a cross-country connection from brl-vmb.arpa on the East coast to nprdc.arpa on the West coast had 0% packet loss, an average round-trip time of 348 ms and a maximum round-trip time of 1418 ms. By comparison, a cross-country connection to ucbvax.berkeley.edu exhibited a 61% packet loss, an average round-trip time of 9064 ms and a maximum round-trip time of 22514 ms. Why the large discrepancy between responses from these two hosts? One possibility that looms is the Arpa-Milnet gateway. Running simultaneous pings to both sides of dcec-milnet-gw.arpa (BRL's default Arpa-Milnet gateway) reveal large packet losses. Admittedly, the simultaneous pinging can influence the packet loss level. However, even non-simultaneous pings to the different addresses of the gateway indicated large packet losses. One other revealing test is a simultaneous ping to the Arpa side of the gateway and to ucbvax. Packet loss just to the gateway was 40%, increasing to just 44% for packet loss to ucbvax. Average round-trip time to the gateway was 5743 ms while round-trip time to ucbvax was 7448 ms, almost 2 seconds longer. This would seem to indicate that much of the problem is in the gateway. There is probably an additional problem between the gateway and ucbvax since average round-trip time cross-country via Milnet is only 348 ms. Sample time: 2315-2340 on November 3, 1987 Ping was run for at least 2 minutes to gather the results below: Internet # hostname min/avg/max loss ---------- --------------------- ------------- ---- 26.2.0.29 aberdeen-mil-tac.arpa 33/348/6566 1% 26.0.0.45 ardec-mil-tac.arpa 99/208/3614 0% 26.0.0.50 amc-hq.arpa 114/148/748 0% Non-simultaneous 26.0.0.104 dcec-milnet-gw.arpa 6651/19174/32842 76% 10.7.0.20 dcec-milnet-gw.arpa 518/4452/13966 30% 26.0.0.104 dcec-milnet-gw.arpa 433/3408/14547 41% Simultaneous 26.0.0.104 dcec-milnet-gw.arpa 433/4020/15399 36% 10.7.0.20 dcec-milnet-gw.arpa 599/4724/21784 50% 26.3.0.3 nprdc.arpa 333/442/1418 0% 10.2.0.78 ucbvax.berkeley.edu 1948/9064/22514 61% Simultaneous 10.7.0.20 dcec-milnet-gw.arpa 548/5743/24565 40% 10.2.0.78 ucbvax.berkeley.edu 933/7448/22865 44% ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711041523.AA01788@etn-wlv.eaton.com] <1987110405235300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Private/Public Ownership of Software Message-ID: <8711041523.AA01788@etn-wlv.eaton.com> Date: Wed, 4-Nov-87 10:23:53 EST Article-I.D.: etn-wlv.8711041523.AA01788 Posted: Wed Nov 4 10:23:53 1987 Date-Received: Tue, 10-Nov-87 05:18:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Early this summer, a comment was made in this forum concerning the ownership of software. As I recall the issue was raised concerning software developed by Mitre for a governmental agency. The gist of the statement was that the software in question was not in the public domain as it had not been develop- ed at the specific request of the agency but was developed to satisfy require- ments established by the agency. Can the author or anyone else provide me a copy of the comment? (I foolishly deleted the message after reading it the first time not realizing that it might have more importance than the disk space it was occupying.) Merton Campbell Crockett mcc@etn-wlv.eaton.com AN/GYQ-21(V) Program EATON Information Management Systems 31717 La Tienda Drive, Box 5009 Westlake Village, CA 91359 PS: After scrolling through two (2) months of messages that accumulated while I was in Germany, I see we have yet to decide what the behav- ior of terminal should be. Instead of TELNET appearing on the sub- ject line, we have SUPDUP or RTCE (?) appearing on the subject line. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [531@bpa.BELL-ATL.COM] <1987110407302300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: espo@bpa.BELL-ATL.COM (Bob Esposito) Newsgroups: comp.protocols.tcp-ip Subject: SGMP Message-ID: <531@bpa.BELL-ATL.COM> Date: Wed, 4-Nov-87 12:30:23 EST Article-I.D.: bpa.531 Posted: Wed Nov 4 12:30:23 1987 Date-Received: Sat, 7-Nov-87 16:57:35 EST Organization: Bell of Penna., Phila. Lines: 11 Does anyone know where I can get info concerning SGMP (Simple Gateway Mgmt. Protocol)? Anything would be helpful. Thanks in Advance, -- ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== Bob Esposito, Bell of Pennsylvania - espo@bpa.bell-atl.com - (215) 466-6831 ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711041745.AA20491@opal.berkeley.edu] <1987110407454900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall@OPAL.BERKELEY.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Separation of Layers Message-ID: <8711041745.AA20491@opal.berkeley.edu> Date: Wed, 4-Nov-87 12:45:49 EST Article-I.D.: opal.8711041745.AA20491 Posted: Wed Nov 4 12:45:49 1987 Date-Received: Tue, 10-Nov-87 06:05:42 EST References: <8710312107.AA14385@PARIS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Well, I've never been great on understanding which level is which. However, a TCP address is the two-ple . This is the TCP address. That is the way it is. The nice thing here is that the TCP address contains sufficient information to determine the IP address (and, the bad thing here is that...). Next, a TCP connection is defined by the two-ple . A TCP connection *cannot* be defined by the two-ple - port numbers only have significance when concatenated with an IP address (imagine telnet clients on two machines trying to connect to the telnet server, port 23 or whatever, on one server machine). If I understand the world of ISO correctly, *everything* has an address (or is it a name?) which is (maybe) globally unique. In that case what you are saying would make sense - ISO TCP shouldn't care about the ISO IP source address some packet of data came from. However, DARPA TCP/IP is not built that way. (It would, it is true, be nice if every host had exactly one "name"; then a TCP address could be .) Greg Minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711042010.AA06784@brillig.umd.edu] <1987110410102300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: steve@BRILLIG.UMD.EDU (Steve D. Miller) Newsgroups: comp.protocols.tcp-ip Subject: Fetching host tables from the NIC Message-ID: <8711042010.AA06784@brillig.umd.edu> Date: Wed, 4-Nov-87 15:10:23 EST Article-I.D.: brillig.8711042010.AA06784 Posted: Wed Nov 4 15:10:23 1987 Date-Received: Tue, 10-Nov-87 06:46:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 For a few days now, I've had problems in reaching the NIC. When I try to fetch HOSTS.TXT, do a whois lookup, or just to telnet in, I sometimes get TCP resets, and sometimes just get timeouts. When I last telnetted to the SMTP port on the NIC, though, it worked fine. If it was just timeouts, I wouldn't be so surprised, but it seems strange to me that the NIC would tell me to go away when I try to reach certain well-known ports and not others. Is something funny going on out there? I'd sure like to update my host tables, for those last few machines who need to use it... -Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12348010491.22.NIC@SRI-NIC.ARPA] <1987110412072800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NIC@SRI-NIC.ARPA (DDN Reference) Newsgroups: comp.protocols.tcp-ip Subject: ARPANET PSN 7.0 BETA TEST SCHEDULE Message-ID: <12348010491.22.NIC@SRI-NIC.ARPA> Date: Wed, 4-Nov-87 17:07:28 EST Article-I.D.: SRI-NIC.12348010491.22.NIC Posted: Wed Nov 4 17:07:28 1987 Date-Received: Tue, 10-Nov-87 07:22:03 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 ARPANET PSN 7.0 BETA TEST SCHEDULE The following is the current schedule for the new End-to-End cutover for all ARPANET nodes. This schedule has been approved by DCA and DARPA. It is requested that host administrators be aware of this test, but not take action to reduce traffic load during testing. All ARPANET nodes will be running PSN 7.0 on the following dates and times: Date Time 7 NOV 87 8:00-5:00 (EST) 14 NOV **thru** 15 NOV 8:00-5:00 (EST) 18 NOV 1:00-4:00 (EST) Hosts experiencing problems are asked to call the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992. Only by your notification can we know that you are encountering problems. Please call. There will be a follow-up meeting to discuss the status of the ARPANET beta testing of the new End-to-End protocols on November 20, 10:30 am at the Washington Building, Room 201, 7600 Old Springhouse Road, McLean, VA. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711050031.AA11673@PARIS.MIT.EDU] <1987110414312700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: Separation of Layers Message-ID: <8711050031.AA11673@PARIS.MIT.EDU> Date: Wed, 4-Nov-87 19:31:27 EST Article-I.D.: PARIS.8711050031.AA11673 Posted: Wed Nov 4 19:31:27 1987 Date-Received: Wed, 11-Nov-87 02:31:36 EST References: <8711041745.AA20491@opal.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Yes, it sounds like my interpretation won't work. I really was not trying to get TCP/IP to fit into the ISO model which I consider malformed at best. I have some Basic Rate and Primary Rate Interface cards for various machines, and I want to run TCP/IP over them. But I want the option of establishing point to point serial links between machines or X.31 connections to PSPDNs rather than just packet calls to my PBX or local switch which seem to have either miserable or non-existent packet handlers. In this environment I want to dynamically assign IP addresses to channels or groups of channels and I want to tear down links over which there is no traffic because I want to avoid phone bills which could be large in the case of point-to-point rather than packet billing. In such an environment I could anticipate the physical link for an rlogin session going away and then suddenly when there was activity over the TCP VC a new physical link on perhaps a different interface might be established which might end up with a new IP address. Alternatively if possible I would probably like to move calls off the ISDN medium onto the ethernet medium if a dead network suddenly became alive. But given that IP and TCP are apparently really only one layer it can't be done. In any case the problem probably isn't too important since ISDN is too slow to be useful for real networking. Of course for multihomed hosts the reliability issue might be important, but I guess it just can't be done. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19001@amdcad.AMD.COM] <1987110417430800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: phil@amdcad.AMD.COM (Phil Ngai) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <19001@amdcad.AMD.COM> Date: Wed, 4-Nov-87 22:43:08 EST Article-I.D.: amdcad.19001 Posted: Wed Nov 4 22:43:08 1987 Date-Received: Sat, 7-Nov-87 17:30:31 EST References: <8711040945.AA17936@ucbvax.Berkeley.EDU> Reply-To: phil@amdcad.UUCP (Phil Ngai) Organization: Advanced Micro Devices Lines: 12 In article <8711040945.AA17936@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes: >We have a growing investment in >Bridge Communications' IP routing products. >One such Bridge box that has served us well in the past is the GS-3. Now that Bridge Communications has been purchased by 3Com, I look forward to the day when we can refer to BCI's GS/3 IP routers as 3Com boxes instead of "bridge boxes". -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1527@faline.bellcore.com] <1987110418273200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@faline.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Internet routing problems Message-ID: <1527@faline.bellcore.com> Date: Wed, 4-Nov-87 23:27:32 EST Article-I.D.: faline.1527 Posted: Wed Nov 4 23:27:32 1987 Date-Received: Sun, 8-Nov-87 00:45:05 EST Organization: Bell Communications Research, Inc Lines: 23 Keywords: EGP table overflow Our gateway between bellcore-net and the ARPANET is ipswitch.bellcore.com, a Sun 3/160 running Sun Unix 3.4 and Sun Link DDN 5.0. We're running Kirton's EGP as distributed by Sun. Lately I've noticed some rather persistent routing connectivity problems in the Internet. Many destinations fail to respond to packets sent from hosts on bellcore-net (128.96) but are shown to be up when I initiate connections from ipswitch. A given host can be unresponsive for days. I know that ipswitch is sending the proper connectivity information to the core because I can see bellcore-net in another ARPANET machine's routing table. I suspect the problem is related to the inability of many gateways to handle ever-larger EGP updates. I noticed problems on ipswitch in that entries for outside sites would appear in the routing table shortly after booting, but after several minutes they would disappear leaving only the entry for network 10. Some sleuthing revealed that every incoming EGP update had a checksum error. I increased the size of MAXPACKETSIZE in defs.h from 1006 to 2048 and recompiled. The problem has not recurred. I suspect that there are many other gateways out there with the same problem; what can we do to get them fixed? Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM].5-Nov-87.09:58:35.CLYNN] <1987110504580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CLYNN@G.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: details on misbehaving IP implementations Message-ID: <[G.BBN.COM].5-Nov-87.09:58:35.CLYNN> Date: Thu, 5-Nov-87 09:58:00 EST Article-I.D.: <[G.BBN.COM].5-Nov-87.09:58:35.CLYNN> Posted: Thu Nov 5 09:58:00 1987 Date-Received: Tue, 10-Nov-87 03:01:46 EST References: <1512@faline.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Phil, I think that 2 and 3 (returning port unreachable) are not bugs but are actually doing what the spec says they should. 4 (returning protocol unreachable in response to broadcasts) is probably not a good idea, but the specs were written before broadcast were widely used. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110504580001> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Thu 5 Nov 87 07:03:27-PST Date: 5 Nov 1987 09:58-EST Sender: CLYNN@G.BBN.COM Subject: Re: details on misbehaving IP implementations From: CLYNN@G.BBN.COM To: faline!karn@BELLCORE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM] 5-Nov-87 09:58:35.CLYNN> In-Reply-To: <1512@faline.bellcore.com> Phil, I think that 2 and 3 (returning port unreachable) are not bugs but are actually doing what the spec says they should. 4 (returning protocol unreachable in response to broadcasts) is probably not a good idea, but the specs were written before broadcast were widely used. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110506144600> Received: from UDEL.EDU by SRI-NIC.ARPA with TCP; Thu 5 Nov 87 16:46:37-PST Received: from dewey.udel.edu by Louie.UDEL.EDU id aa00322; 5 Nov 87 14:57 EST Received: from localhost by Dewey.UDEL.EDU id aa02976; 5 Nov 87 14:35 EST To: system@UDEL.EDU, acm@UDEL.EDU, f-troup@UDEL.EDU, arpanet-bboards@mc.lcs.mit.edu, big-lan@suvm.acs.syr.edu, ibm-nets%bitnic.BITNET@wiscvm.wisc.edu, info-nets@think.com, protocols@rutgers.edu, tcp-ip@sri-nic.arpa, telecom@xx.lcs.mit.edu Subject: Robert Lucky Date: Thu, 05 Nov 87 14:34:46 -0500 From: M C Srivas Message-ID: <8711051435.aa02976@Dewey.UDEL.EDU> Does anyone know where I could access papers published by Rob Lucky? His papers will most probably deal with limitations, etc. of the various optical networking technologies. Thanks. Srivas. ______________________________________________________________________________ Network: ARPA: srivas@udel.edu BITNET: srivas@udel.edu CSNET: srivas%udel.edu@relay.cs.net UUCP: ...!ihnp4!berkeley -\ ...!allegra!berkeley -->!srivas@udel.edu ...!harvard -/ ______________________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711051708.AA22201@jvnca.csc.org] <1987110507082000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: heker@JVNCA.CSC.ORG.UUCP Newsgroups: comp.protocols.tcp-ip Subject: routing changes Message-ID: <8711051708.AA22201@jvnca.csc.org> Date: Thu, 5-Nov-87 12:08:20 EST Article-I.D.: jvnca.8711051708.AA22201 Posted: Thu Nov 5 12:08:20 1987 Date-Received: Tue, 10-Nov-87 02:53:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 We are experiencing a large number of routing changes in the kernel of one of our VAX8600 "gateways". The number of changes has increased dramatically due to some route instabilities (that are not the topic of this message). The question is how the number of changes can affect the performance of our system?. We see about 1000 route changes in the kernel in periods of 10 minutes. This is as you can see *extremely* high. But does this degrade the system performance at all?. I also want to point out that this route changes are then propagated to other systems (VAX750s). And all dance at the same rithm. Any comments about this will be greately appreciated. -- Sergio ----------------------------------------------------------------------------- Sergio Heker tel: (609) 520-2000 Internet: "heker@jvnca.csc.org" Bitnet: "heker@jvnc" JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110507372700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 5 Nov 87 02:19:41-PST Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA18070; Thu, 5 Nov 87 01:34:05 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Nov 87 07:37:27 GMT From: jbs@eddie.mit.edu (Jeff Siegal) Organization: MIT, EE/CS Computer Facilities, Cambridge, MA Subject: ARPANET<->MILNET problems Message-Id: <7353@eddie.MIT.EDU> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I've been trying to ftp some files from ECLA.USC.EDU (on MILNET) to MIT (on ARPANET) and have had no success for the past week. The Unix ping program reports round-trip-times of 20-40 seconds and packet loss rates varying between 70 and 100 percent. Is there some current problem that is likely to be corrected, or should we give up and resort to Federal Express and magtape? Jeff Siegal ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711051739.AA26748@opal.berkeley.edu] <1987110507385700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall@OPAL.BERKELEY.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Separation of Layers Message-ID: <8711051739.AA26748@opal.berkeley.edu> Date: Thu, 5-Nov-87 12:38:57 EST Article-I.D.: opal.8711051739.AA26748 Posted: Thu Nov 5 12:38:57 1987 Date-Received: Thu, 12-Nov-87 05:44:24 EST References: <8711050031.AA11673@PARIS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 47 >... > Alternatively if possible I would probably like to move calls off the > ISDN medium onto the ethernet medium if a dead network suddenly became > alive. > > But given that IP and TCP are apparently really only one layer it > can't be done. > > In any case the problem probably isn't too important since ISDN is too > slow to be useful for real networking. Of course for multihomed hosts > the reliability issue might be important, but I guess it just can't be > done. No, TCP and IP are not one layer. Back in the days of experimental ethernets, there were only 8 bits of addressing in the ethernet packets. The way of mapping an IP address to an ethernet address was to use the lower order 8 bits of the IP address as the ethernet address (though actually what really happened was that the ethernet address was assigned to the lower order 8 bits of the IP address). You wouldn't argue that the ethernet and IP were really one layer; however, the mapping between IP address and ethernet address was merely that of extracting - a projection. On current ethernet, a projection from the 32-bit IP address space won't work, since the map needs to be onto, and the ethernet address space is 48 bits. So, we have ARP. A TCP address is composed of two parts: a 32-bit IP address, and an 8-bit port identifier. To convert a TCP address into an IP address is, again, a projection. That this is so does not somehow merge the two layers into one. They are two layers. (By the way, a machine is certainly free to send a packet on an interface with address 128.32.13.4, and give it an IP source address of 10.0.3.4; this is even justified if that machine has an interface with "address" 10.0.3.4 and that interface is down and there is an already existing connection to a local port of 10.0.3.4. However, you are correct in assuming that in this situation, the connection partner will probably not survive the fact that the 10.0.3.4 interface has gone down - unless the sender uses IP source routing and the partner remembers the last source route received on the connection.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711051422.aa08546@Huey.UDEL.EDU] <1987110509221200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: routing changes Message-ID: <8711051422.aa08546@Huey.UDEL.EDU> Date: Thu, 5-Nov-87 14:22:12 EST Article-I.D.: Huey.8711051422.aa08546 Posted: Thu Nov 5 14:22:12 1987 Date-Received: Tue, 10-Nov-87 06:22:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Sergio, I'm not sure what you mean by "routing changes." There certainly are vast quantities of changes involving relatively small changes in delay and even uncomfortable quantites involving significant (factor of two) changes. Not many of these involve changes in route, however. While the situation is serious and must be fixed, I don't think the routing overhead itself is a significant factor in performance. Hellograms are rate-limited to no more than one every 400 ms in even the worst case. Let's hear it for all those gated's honking strange distances to the fuzzies. Can someone answer the questions I put out about their behavior? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [871105210734.397661@MIT-Multics.ARPA] <1987110511070000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Petty@MIT-MULTICS.ARPA Newsgroups: comp.protocols.tcp-ip Subject: ARP over FDDI Message-ID: <871105210734.397661@MIT-Multics.ARPA> Date: Thu, 5-Nov-87 16:07:00 EST Article-I.D.: MIT-Mult.871105210734.397661 Posted: Thu Nov 5 16:07:00 1987 Date-Received: Wed, 11-Nov-87 02:50:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Hello I am new to the network. If this topic has already been addressed, I aplologize in advance. I am curious if anyone has thought about using ARP over an FDDI network? It seems like a match made in UCBerkeley. The problem as I see it, is that FDDI can have either 16 or 48 bit addresses. If the gurus of FDDI who hand out the numbers would ensure that the first 32 bits of a 48 bit hardware address were non-zero, then life would be good. Thanks in advance. Jim Petty Spartacus Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12348272453.8.BILLW@MATHOM.CISCO.COM] <1987110512062800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <12348272453.8.BILLW@MATHOM.CISCO.COM> Date: Thu, 5-Nov-87 17:06:28 EST Article-I.D.: MATHOM.12348272453.8.BILLW Posted: Thu Nov 5 17:06:28 1987 Date-Received: Wed, 11-Nov-87 06:22:14 EST References: <1940@uwmacc.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Now, what I'm gonna do is put a permanent entry in Elsie's ARP cache with Bossie's IP number and ethernet address. Well, first of all, the idea of loading up your host with permanent ARP entries is pretty gross, and defeats the the purpose of ARP anyway. Second, and more important is that hardware ethernet addresses aren't any more imutable that IP addresses anyway - I can easilly change my hardware adrress to anything I want. DECNet does this sort of thing as a matter of course - setting the decnet host numbers into the hardware address. Thus having a permanant ARP entry doesn't buy you much additional security anyway. Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711121856.AA01687@ucbvax.Berkeley.EDU] <1987110513502900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: RAF@NIHCU.BITNET ("Roger Fajman") Newsgroups: comp.protocols.tcp-ip Subject: Multiple subnets on one physical network Message-ID: <8711121856.AA01687@ucbvax.Berkeley.EDU> Date: Thu, 5-Nov-87 18:50:29 EST Article-I.D.: ucbvax.8711121856.AA01687 Posted: Thu Nov 5 18:50:29 1987 Date-Received: Sat, 14-Nov-87 20:04:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 40 I guess that this may have been discussed before, but due to a problem with our mailer here I wasn't getting much mail from this list at the time. Anyway, we recently acquired a class B network number for our planned campus network and the issue arises about how to divide the 16-bit address space between subnet numbers and host numbers. If we make the subnet field small, we probably won't have enough subnet numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each) and a lot of address space is wasted on small subnets. If we make the subnet field large, we won't have enough host numbers for our largest subnet (an 8 bit subnet field gives 254 networks of 254 nodes each). This naturally leads to the question: can multiple subnet numbers be assigned to the same physical network? Since we plan to use Proteon p4200 Gateways for at least some things, I called Proteon and asked them. They told me that there is no problem, as each network interface can be assigned up to 16 IP addresses, thus allowing it to respond to an IP address for each of up to 16 subnets that reside on the same physical network. I was told that this was desirable because many hosts require that any gateway that they use be on their own subnet. Now I was recently shown a copy of a message from last July that said that in such a situation, a Unix system would receive Ethernet broadcast packets containing IP broadcast packets for other subnet numbers, not realize that they were broadcast packets for another subnet, and try to process (forward or redirect) them in some way. More recently, I received a message on this list that said that a Unix system would not try to perform gateway functions unless it had more than one network interface, regardless of how its parameters were set. Anyway, what is the truth? Can we assign multiple subnet numbers to the same physical network or not? What have others done about this problem? Roger Fajman RAF@NIHCU.BITNET National Institutes of Health ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110513502901> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sun 8 Nov 87 09:12:34-PST Received: from NIHCU.BITNET by wiscvm.wisc.edu ; Thu, 05 Nov 87 17:54:09 CDT To: TCP-IP@SRI-NIC.ARPA From: "Roger Fajman" Date: Thu, 05 Nov 87 18:50:29 EST Subject: Multiple subnets on one physical network I guess that this may have been discussed before, but due to a problem with our mailer here I wasn't getting much mail from this list at the time. Anyway, we recently acquired a class B network number for our planned campus network and the issue arises about how to divide the 16-bit address space between subnet numbers and host numbers. If we make the subnet field small, we probably won't have enough subnet numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each) and a lot of address space is wasted on small subnets. If we make the subnet field large, we won't have enough host numbers for our largest subnet (an 8 bit subnet field gives 254 networks of 254 nodes each). This naturally leads to the question: can multiple subnet numbers be assigned to the same physical network? Since we plan to use Proteon p4200 Gateways for at least some things, I called Proteon and asked them. They told me that there is no problem, as each network interface can be assigned up to 16 IP addresses, thus allowing it to respond to an IP address for each of up to 16 subnets that reside on the same physical network. I was told that this was desirable because many hosts require that any gateway that they use be on their own subnet. Now I was recently shown a copy of a message from last July that said that in such a situation, a Unix system would receive Ethernet broadcast packets containing IP broadcast packets for other subnet numbers, not realize that they were broadcast packets for another subnet, and try to process (forward or redirect) them in some way. More recently, I received a message on this list that said that a Unix system would not try to perform gateway functions unless it had more than one network interface, regardless of how its parameters were set. Anyway, what is the truth? Can we assign multiple subnet numbers to the same physical network or not? What have others done about this problem? Roger Fajman RAF@NIHCU.BITNET National Institutes of Health ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12348296366.8.BILLW@MATHOM.CISCO.COM] <1987110514175000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: Telephone Access Controllers (TACs) and SLIP... Message-ID: <12348296366.8.BILLW@MATHOM.CISCO.COM> Date: Thu, 5-Nov-87 19:17:50 EST Article-I.D.: MATHOM.12348296366.8.BILLW Posted: Thu Nov 5 19:17:50 1987 Date-Received: Thu, 12-Nov-87 05:28:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Is there any interest in a TAC like device capable of running SLIP (Serial Line IP) on its terminal interfaces ? As I currently envision this, each serial line could be a logical host when acting as an IP device, and just a normal port when acting as a terminal. This might provide some performance improvement over things like kermit for downloading/uploading files.... Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711060026.AA03844@ACC-SB-UNIX.ARPA] <1987110514265900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: satish@ACC-SB-UNIX.ARPA (Satish B. Joshi) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet/IP Testing/Monitoring Tools Message-ID: <8711060026.AA03844@ACC-SB-UNIX.ARPA> Date: Thu, 5-Nov-87 19:26:59 EST Article-I.D.: ACC-SB-U.8711060026.AA03844 Posted: Thu Nov 5 19:26:59 1987 Date-Received: Wed, 11-Nov-87 20:22:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Does anyone know of any tools for monitoring and/or testing networks in Ethernet, Unix-4.3BSD(VAX), and TCP/IP environment? I believe that some tools similar to SUN's "etherfind", and software to generate bogus IP datagrams were discussed here. I will appreciate any information about software to test protocols, specific interface boards or gateways, and to monitor Ethernets. Thanks. Satish ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110517101200> Received: from nic.nyser.net by SRI-NIC.ARPA with TCP; Fri 6 Nov 87 10:41:46-PST Received: by nic.nyser.net (5.54/1.14) id AA17545; Thu, 5 Nov 87 22:10:12 EST Date: Thu, 5 Nov 87 22:10:12 EST From: fedor@nic.nyser.net (Mark Fedor) Message-Id: <8711060310.AA17545@nic.nyser.net> To: Mills@udel.edu, heker@jvnca.csc.org Subject: Re: routing changes Cc: boyle@jvnca.csc.org, nsfnet@sh.cs.net, tcp-ip@sri-nic.arpa > >Date: Thu, 5 Nov 87 15:40:15 est >From: Sergio Heker > >Dave, > >What I mean by routing changes, are actual routing changes in the kernel >as per "gated". The following list is only a sample for one particular >network and over 10 minutes. It illustrates metric changes and not >route changes, but at some points, these metric changes, as observed from >our bunker translate into counting to infinity from neighboring gateways >(as we have observed for certain networks). The problem is two fold, >one is to determine how much this affects our systems, and second is to >determine the cause for this unstable information. > >-------- > >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 11102, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 11778, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 12446, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1647, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 2701 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1405, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1647 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 3615, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 2464, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 4242, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 7120, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 3512, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1647, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO >CHANGE dst 192.31.83.0, router 128.121.50.20, metric 1406, proto HELLO, flags UP|GATEWAY, state CHANGED|INTERIOR hwin_min 1402 fromproto HELLO > >------- > > -- Sergio > > >----------------------------------------------------------------------------- >Sergio Heker tel: (609) 520-2000 >Internet: "heker@jvnca.csc.org" Bitnet: "heker@jvnc" >JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager >----------------------------------------------------------------------------- > >>> Sergio, The excerpt from the log file shows no kernel route changes at all! The unix kernel only keeps info about the destination and gateway of a route (among other things), but not the metric. Notice that the gateway never changed so there was never a kernel change during the log above. Gated keeps the metric and the metric change was made by gated. Now that this is out of the way, when this metric changing occurs, it of course takes up more system time cause gated is working harder. When the gateway changes like mad is when you get kernel route table thrashing. Mark P.S. I don't know off hand why this is happening, although it is a midnet.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2.716@scarecrow.waisman.wisc.edu] <1987110517315400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ORCHARD/BRUC@SCARECROW.WAISMAN.WISC.EDU (Bruce Orchard) Newsgroups: comp.protocols.tcp-ip Subject: TCP maximum segment size determination Message-ID: <2.716@scarecrow.waisman.wisc.edu> Date: Thu, 5-Nov-87 22:31:54 EST Article-I.D.: scarecro.2.716 Posted: Thu Nov 5 22:31:54 1987 Date-Received: Thu, 12-Nov-87 06:36:16 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 51 Consider a TCP connection passing through 3 networks: An Ethernet, the ARPANET, and another Ethernet. There are gateways between each Ethernet and the ARPANET. At connection time, each host must choose a maximum segment size for the TCP segments it transmits. The selection algorithm is generally to take the minimum of the maximum size allowed by the receiver (given in the TCP maximum segment size option), the maximum size allowed by the network the host is connected to (in this case, an Ethernet), and the maximum the transmitting host can handle. Allowing integral multiples of the local network maximum would be reasonable too. All this has to allow enough space for headers. Now the maximum size allowed by an Ethernet is 1500 bytes, but the maximum allowed by the ARPANET is 1007 bytes. If a maximum segment size greater than 1007 is picked by the transmitting end, the gateway going into the ARPANET will fragment the message. A segment of 1500 bytes would get split into one of about 1000 bytes and another of about 500 bytes. One particularly poor choice I have seen used is a maximum segment size of 1024 bytes. Since the 1024 bytes excludes headers, this results in one fragment of 1007 bytes and another 77 bytes. The real problem is that the transmitting end has no knowledge of the limits of networks it is not connected to. Therefore, I propose adding a new option to the IP header. This option would give the minimum of the maximum transmission units of any network that handled the packet. The originating end would set it to a large value. Each node that transmitted the packet would compare the value given in the option to the maximum transmission unit of the outgoing network. If the network value were less, the value in the option would be reduced to the network value. This IP header option would be used by TCP on the packet that includes the TCP maximum segment size option. The receiving TCP would consider both the maximum allowed by its peer TCP (in the TCP option) and the maximum allowed by any network along the way. It would probably take the lessor of the two. One limitation of this proposal is that all packets of a TCP connection do not necessarily pass through the same networks. Actually, given the way the networks are connected, all packets usually go through the same networks. Also, if one packet takes a different route from an earlier packet, the second route could be on the same kind of network (for example, two parallel Ethernets). Regardless, the consequence of a poor choice is reduced throughput, not failure. Bruce Orchard University of Wisconsin-Madison P.S. Is the MTU of SATNET really 256 bytes, as given in IEN 192? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711052232.aa14448@Huey.UDEL.EDU] <1987110517320500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: routing changes Message-ID: <8711052232.aa14448@Huey.UDEL.EDU> Date: Thu, 5-Nov-87 22:32:05 EST Article-I.D.: Huey.8711052232.aa14448 Posted: Thu Nov 5 22:32:05 1987 Date-Received: Fri, 13-Nov-87 00:10:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Sergio, Ah yes, the infamous 192.31.x nets. These dudes have been bouncing all over t the map for some time now. The distance values for these nets are not provided by the fuzzballs, but by gated at some site or other. WHen they count to infinity they have in fact become unreachable. This is a classic example of what unstable metrics can do to a distributed Bellman-Ford algorithm. I have been working feversihly to harden the algorithm so that even these wild swings won't destabilize the algorithm, but when distances change from one sample to the next by over fifty percent, what can any algorithm do? I repeat my statement made at least a dozen times: where is the source of those violent delay excursions and what gated is generating them? Having said that, note that even these severe transients should not adversely affect the system throughput, at least for the nets not rocking to and fro, since the hello messages are rate-limited. On the other hand, traffic for nets counting to infinity can clearly gobble up dangerous levels of traffic. That's why I have been spending so much time trying to avoid the counting problem. THe only way to do that is to latch sudden increases in delay and prevent further decreases until the hold-down timer expires, which is what the present system does. I have had to experiment somewhat in order to gauge the sensitivity of the latch, which is presently set at a factor of two. The latch regularily snares at least some of the surges, but not all, as you can see from your data. I can't make the latch more sensitive without snaring a lot of benign wobbles, such as occasional retransmissions on UIUC - NCAR lines, for example. Nevertheless, I have tuned the algorithm a lot in the past month and, at least in the testing swamps, it seems to be working well. It has been suggested that JVNC has more trouble than most because that is the only spot running gated on two machines on the same Ether. I thought Maryland was doing that as well. While they seem to be having trouble of their own, destabilized routes do not seem to be a serious problem there. There are two things I would recommend (again): first, identify all those gated configurations where only a single path is available to the networks being squawked and set the squawked delay to zero, just plain zero. Second, where multiple paths to a net exist, pray to the metric-translation god and really, truly and verily conform to the rules I suggested in my earlier memo. In any case, the clock-offset fields associated with each net in the hello message should be set to zero and the date in the header should be marked invalid. This seems like a pretty simple thing to check. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711052235.aa14589@Huey.UDEL.EDU] <1987110517351300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: routing changes Message-ID: <8711052235.aa14589@Huey.UDEL.EDU> Date: Thu, 5-Nov-87 22:35:13 EST Article-I.D.: Huey.8711052235.aa14589 Posted: Thu Nov 5 22:35:13 1987 Date-Received: Fri, 13-Nov-87 03:56:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Folks, My apologies to the tcp-ip list for my recent reply to Sergio's message, which must have seemed rather esoteric to most of you. I overlooked the "tcp-ip" addressee in the return address list of the message. On the other hand, if someone wants to start that game, I would be happy to play. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711060340.AA17823@nic.nyser.net] <1987110517403100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: fedor@NIC.NYSER.NET (Mark Fedor) Newsgroups: comp.protocols.tcp-ip Subject: Re: routing changes Message-ID: <8711060340.AA17823@nic.nyser.net> Date: Thu, 5-Nov-87 22:40:31 EST Article-I.D.: nic.8711060340.AA17823 Posted: Thu Nov 5 22:40:31 1987 Date-Received: Wed, 11-Nov-87 04:48:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 >Date: Thu, 5 Nov 87 14:22:12 EST >From: Mills@udel.edu >Subject: Re: routing changes > [ DELETED TEXT - MF ] >Let's hear it for all those gated's honking strange distances to the >fuzzies. Can someone answer the questions I put out about their behavior? > >Dave > Dave, I must admit due to some traveling and moving, I have not read my mail too carefully. As soon as I catch up and find the questions you put out, I will be glad to answer them. Or you can send me a summary of your questions and I'll see what I can do..... Mark NYSERNet Inc. (this is the last time I specify this! Y'all should know I work there by now.) :^) P.S. can you elaborate "strange distances"? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711052338.aa15095@Huey.UDEL.EDU] <1987110518383500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: routing changes Message-ID: <8711052338.aa15095@Huey.UDEL.EDU> Date: Thu, 5-Nov-87 23:38:35 EST Article-I.D.: Huey.8711052338.aa15095 Posted: Thu Nov 5 23:38:35 1987 Date-Received: Fri, 13-Nov-87 04:11:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Mark, Yeah, I know who you work for now, but if I admitted that you might have an excuse to wiggle off the hook. The hook seems to have already impaled me, as you may have noticed. Strange distances mean anything from 100 ms to somewhere in the middle of Channel 4. Sergio's is a typical example. As for rounding up all the messages I sent on the topic, gimme a break. There must be a hundred of them last month alone. From reports by returning scouts to the INENG meeting, the likely cause may be (a) incompatible gated versions and/or configurations, (b) unstable ripspeakers behind gated or (c) metric conversion violations when more than a single access path is available. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711060720.AA24392@athos.rutgers.edu] <1987110521205400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: new Arpanet end to end protocol Message-ID: <8711060720.AA24392@athos.rutgers.edu> Date: Fri, 6-Nov-87 02:20:54 EST Article-I.D.: athos.8711060720.AA24392 Posted: Fri Nov 6 02:20:54 1987 Date-Received: Thu, 12-Nov-87 05:32:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 I have just heard from a reliable source a fairly interesting fact about the new end to end protocol implemented in PSN 7.0. (Note that my terminology is probably slightly off in this message. I don't know anything about the imp to host protocol, so I am almost certainly introducing some distortion in passing on this information.) Apparently one of the efficiency improvements in the new end to end protocol is that the IMP's will no longer attempt to return a RFNM for each packet. You will be expected to look at the ID number included in the RFNM's. Any outstanding RFNM's with ID numbers lower than the current one are also to be considered as acknowledged. Many implementations apparently simply count RFNM's. They assume that one acknowledgement is received per packet. This will no longer be true with the new end to end protocol, and so these implementations will break. I have some reason to think that most existing implementations fall into this category. Tests of the new end to end protocol are scheduled for Nov 7, 14-15, and 18. Implementors should be alert to misbehaviors during these test periods. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110605185700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun 8 Nov 87 19:43:38-PST Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA16575; Sun, 8 Nov 87 19:45:02 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Nov 87 05:18:57 GMT From: ihnp4!homxb!mtuxo!mtune!codas!ufcsv!beach!esj@ucbvax.Berkeley.EDU (Eric S. Johnson) Organization: UF CIS Department Subject: Re: ARPANET<->MILNET problems Message-Id: <8722@ufcsv.cis.ufl.EDU> References: <7353@eddie.MIT.EDU> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <7353@eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal) writes: >I've been trying to ftp some files from ECLA.USC.EDU (on MILNET) to >MIT (on ARPANET) and have had no success for the past week. The Unix >ping program reports round-trip-times of 20-40 seconds and packet >loss rates varying between 70 and 100 percent. > >Is there some current problem that is likely to be corrected, or >should we give up and resort to Federal Express and magtape? > >Jeff Siegal I have had a very similer problem making contact to a host inside of the berkeley network. Same horrible round trip times and loss rates. It puzzles me because our contact with ucbarpa and ucbvax (both arpa sites) is fine, but the contact with the site inside the berk-net is rotten. I had a clear steady connection on Friday (10-30) in the mid morning. But instead of making a large transfer then, I thought I would be a nice guy and wait till late that night. Sometime that day something snaped and I haven't been able to make a decent connection since. Perhaps related: I also have not been able to make contact with univ. of Wisc hosts, yet have easy contact with cs.wisc.edu. (again directly on the arpanet) As I understand it, some modifications are being made to the core Arpa/Milnet routers (and maybe NSF). Does someone know if this is the cause of my problems, and when/if things will clear up again? -- In Real Life: UUCP: ...{ihnp4,rutgers}!codas!ufcsv!ufcsg!esj Eric S. Johnson II Internet: esj@beach.cis.ufl.edu University of Florida Ignore headers, reply only to above! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12348462737.37.PADLIPSKY@A.ISI.EDU] <1987110605314400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: ..."layering violations" Message-ID: <12348462737.37.PADLIPSKY@A.ISI.EDU> Date: Fri, 6-Nov-87 10:31:44 EST Article-I.D.: A.12348462737.37.PADLIPSKY Posted: Fri Nov 6 10:31:44 1987 Date-Received: Wed, 11-Nov-87 05:46:14 EST References: <8711030915.AA00844@gumby.wisc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Although you probably make a valuable distinction (given confirmation that X.25 actually does have a "Host Down" return--I remember something like Virtual Circuit Failure, or the like, myself), I was not, of course, talking about X.25 explicitly. (Nor was I talking about daemons explicitly.) Always delighted to learn of still another X.25 faux pas, though. (I'd confirm the Host Down question myself, but I don't have an X.25 spec handy, even though I acknowdlege that it's a seminal fascicle.) Just so the principle doesn't get lost in the worrying over the example, let me rephrase: Just as there's no need to close connections before their time, there's no need to keep them open beyond their time. Good judgment is expected to be applied to the issue of what time it is in the life of given connections in given contexts. OK? cheers, map P.S. Maybe it's a quibble, but wouldn't X.25 call it DTE Down, anyway? (Or is it DCE? Well, DxE, at least.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711061746.AA09873@spdcc.COM] <1987110607271900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbvb@ftp.UUCP (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: ARCnet Message-ID: <8711061746.AA09873@spdcc.COM> Date: Fri, 6-Nov-87 12:27:19 EST Article-I.D.: spdcc.8711061746.AA09873 Posted: Fri Nov 6 12:27:19 1987 Date-Received: Wed, 11-Nov-87 19:41:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Is there any standard for ARCnet encapsulation of IP? Has anyone even done it? Given things I have heard from ARCnet manufacturers, example hardware drivers are available. The process looks like: 1. Locate or develop a standard for IP encapsulation and address resolution. I have been told that ARCnet has a 1-byte hardware address. This would seem to point at a convention like ProNET (map low byte of the hardware address to the low byte of the IP address), instead of a permutation of ARP. 2. Obtain an example hardware driver and some hardware. Starting with MIT's P1300 driver, I would imagine that one could get on-line in a month or less. I would probably have already done this if I had time, or felt sufficiently wizardly to promulgate an encapsulation scheme. James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12348508863.13.SATZ@MATHOM.CISCO.COM] <1987110609450700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SATZ@MATHOM.CISCO.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: EGP instability Message-ID: <12348508863.13.SATZ@MATHOM.CISCO.COM> Date: Fri, 6-Nov-87 14:45:07 EST Article-I.D.: MATHOM.12348508863.13.SATZ Posted: Fri Nov 6 14:45:07 1987 Date-Received: Thu, 12-Nov-87 02:53:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Is anyone else having trouble maintaining their peer relationships with the core? We are seeing excessive problems with high packet loss and eventually being dropped. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [897@ektools.UUCP] <1987110610025100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jim@ektools.UUCP (James Hugh Moore) Newsgroups: comp.protocols.tcp-ip Subject: TCP-IP in the Public Domain? Message-ID: <897@ektools.UUCP> Date: Fri, 6-Nov-87 15:02:51 EST Article-I.D.: ektools.897 Posted: Fri Nov 6 15:02:51 1987 Date-Received: Sun, 8-Nov-87 20:01:12 EST Organization: Eastman Kodak, Dept. 47, Rochester N.Y. Lines: 34 Keywords: public domain very basic question tcp-ip qnx arcnet ------------------------------------------------------------------------------ What part of tcp-ip is in the public domain? I understand that DARPA or some related government agency specified what tcp-ip is. Does anyone have the reference to the government document, or an english version of it? Is there source code for tcp-ip on anything (especially an implementation for arcnet would be nice) that is public domain? Does anyone know of an existing implementation under arcnet or qnx? If these questions seem kind rudimentary, I am a mathematician, and I am posting for a friend, and he needs the answers. I want to thank you in advance for all of your time and effort!!! May God Bless You, in Jesus Name Jim Moore - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James H. Moore, Software Tools Group Product Software Engineering Lab Eastman Kodak Co. Email: allegra!rochester!kodak!ektools!jim USMail: Dept 47, EP 5-2, Eastman Kodak Co., Rochester, NY 14650 Disclaimer: Opinions expressed are my own, and DO NOT represent the opinions or policies etc of Eastman Kodak Co. as a whole. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110611435800> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun 8 Nov 87 22:12:59-PST Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA18221; Sun, 8 Nov 87 21:54:06 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Nov 87 11:43:58 GMT From: steinmetz!vdsvax!barnett@uunet.uu.net (Bruce G Barnett) Organization: General Electric CRD, Schenectady, NY Subject: Is there an EGP that is available? Message-Id: <2916@vdsvax.steinmetz.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa If we wanted to run EGP (External Gateway Protocol) on an Internet/mail gateway for the purposes of dynamically finding routes to other machines, where do we get this program? Is the source available? I know that Sun sells it with their DDN SunLink product. What about Ultrix/4.3bsd? What are the other protocols available - and what do people recommend? Thanks, -- Bruce G. Barnett uunet!steinmetz!barnett ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110611565700> Received: from UDEL.EDU by SRI-NIC.ARPA with TCP; Fri 6 Nov 87 16:37:53-PST Received: from vax1.acs.udel.edu by Louie.UDEL.EDU id aa00315; 6 Nov 87 16:58 EST Received: by vax1.acs.udel.edu (5.51/1.14) id AA28332; Fri, 6 Nov 87 16:56:57 EST Date: Fri, 6 Nov 87 16:56:57 EST From: MORAN Message-Id: <8711062156.AA28332@vax1.acs.udel.edu> To: acm@UDEL.EDU, arpanet-bboards@mc.lcs.mit.edu, big-lan@suvm.acs.syr.edu, f-troup@UDEL.EDU, ibm-nets%bitnic.BITNET@wiscvm.wisc.edu, info-nets@think.com, protocols@rutgers.edu, srivas@UDEL.EDU, system@UDEL.EDU, tcp-ip@sri-nic.arpa, telecom@xx.lcs.mit.edu Subject: Re: Robert Lucky No. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [309@clan.UUCP] <1987110613283000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: eugen@clan.UUCP (Eugen Bacic) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wanted: TCP/IP source Message-ID: <309@clan.UUCP> Date: Fri, 6-Nov-87 18:28:30 EST Article-I.D.: clan.309 Posted: Fri Nov 6 18:28:30 1987 Date-Received: Thu, 12-Nov-87 00:51:19 EST References: <857@quacky.UUCP> Reply-To: eugen@clan.UUCP (Eugen Bacic) Organization: Systems Eng., Carleton Univ., Ottawa, Canada Lines: 5 I am also looking for the source for a complete PD TCP/IP implemention. I would appreciate any information anyone regarding their experiences with Phil Karns implentation. Eugen Bacic @ ..!utzoo!dciem!nrcaer!clan!eugen ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711030525.AA17964@nic.nyser.net] <1987110622172300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NIC.NYSER.NET ("Marty Schoffstall") Newsgroups: comp.protocols.tcp-ip Subject: Re: Separation of Layers Message-ID: <8711030525.AA17964@nic.nyser.net> Date: Sat, 7-Nov-87 03:17:23 EST Article-I.D.: nic.8711030525.AA17964 Posted: Sat Nov 7 03:17:23 1987 Date-Received: Mon, 9-Nov-87 04:47:34 EST References: <8711020243.AA04703@BITSY.MIT.EDU> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 I should point out that at MIT we no longer use network addresses as a form of authenticity. We now use our encryption based "Kerberos" authentication service. The code you wrote to use the subnet as a means of determining authentication has long since been retired. Is there going to be an RFC on the authentication service??? Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- [281178.871107.JBVB@AI.AI.MIT.EDU] <1987110707061700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP Slang Glossary Message-ID: <281178.871107.JBVB@AI.AI.MIT.EDU> Date: Sat, 7-Nov-87 12:06:17 EST Article-I.D.: AI.281178.871107.JBVB Posted: Sat Nov 7 12:06:17 1987 Date-Received: Sat, 14-Nov-87 15:21:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 A fuzzball is a gateway, or IP router, (running on PDP11s, I think) which Dave Mills authored. They are common, because the software is in the public domain, and they seem to have many desirable characteristics, particularly for tinkerers. A bogon is a particle (alias packet) that transmits bogosity. I guess it is also a happy accident that it rhymes with Vogon, because the bogus info is frequently offensive and/or destructive. Gong? I dunno. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1761@bloom-beacon.MIT.EDU] <1987110707153700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wesommer@athena.mit.edu (William Sommerfeld) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge (really: NFS "security") Message-ID: <1761@bloom-beacon.MIT.EDU> Date: Sat, 7-Nov-87 12:15:37 EST Article-I.D.: bloom-be.1761 Posted: Sat Nov 7 12:15:37 1987 Date-Received: Mon, 9-Nov-87 06:51:51 EST References: <8711062349.AA04106@ucbvax.Berkeley.EDU> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: wesommer@athena.mit.edu (William Sommerfeld) Organization: Massachusetts Institute of Technology Lines: 80 Summary: It's bad, folks (but there's hope) In article <8711062349.AA04106@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes: >OK, I'll bite. We have been looking at NFS as a UNIX/VMS server solution >for PCs. From the begining of the investigation we were looking for >things like the 'huge security holes'. Huge security holes is correct. [I won't even talk about vulnerability to malformed packets] At least in the implementations that I have seen (the "portable NFS release"), the NFS server daemon does not look at the client's IP address at all; thus, it will permit access to anyone who can send you UDP packets on port 2049. There is a minor complication, which is that to do anything meaningful, you need to know a "file handle" for a directory on one filesystem. Once you have the file handle, you can do anything you want to the file system, because you can claim an arbitrary user-id in the packet, and the server will trust you. The idea that you have to be "root" on the client to do this is incorrect. It is possible to write a user-level program, using the Sun RPC library, which talks directly to the NFS server of your choice (I know.. it took me about a day to do this, working from the NFS protocol spec). Anyway, back to the weak spot. You can get a file handle from the mount daemon (/usr/etc/rpc.mountd). It reads /etc/exports to find out which hosts it can give out file handles to. Unfortunately, in some versions, it trusts the client to name itself (there is a hostname in the request packet, filled in by the client). In addition, it is possible to make up a valid file handle from whole cloth. In the current implementations, the file handle is the tuple of {device_id, inode_number, generation_number}. The device_id is the UNIX major and minor device number of the device the partition is on. The inode number is just a simple index into the inode table of the filesystem (inode number 2 is the root of the partition, for historical reasons), and the generation number is there to ensure that if an inode is reused for a new file, the new file doesn't get confused with the old. These are initialized to all zero by the standard (non-NFS) newfs. There is a program, called "fsirand", which randomizes the generation numbers of all the inodes on a partition. It is important to run this for _all_ partitions mounted on the server, not just the ones which you want exported, because otherwise someone will be able to use the {device_id, 2, 0} file handle, and get at the root of one of your other filesystems. Thus, the generation numbers become almost as critical as the root password to the server. Is any effort exerted to keep them secret? No. They fly around on the ethernet in the clear. They can also be extracted if you have access to read kernel memory (/dev/kmem or /dev/mem) on the server (typically allowed on pre-4.3 BSD unix systems). There is light at the end of this tunnel, fortunately. Here at Athena, we implemented a very small patch to NFS which gets around this chain of security holes. We modified the NFS server to maintain a hash table which maps {client IP address, user_id} to {local uid, group set}. Map entries are controlled by a modified rpc.mountd which uses the Kerberos authentication system to verify the authenticity of the client. Rather than trusting the client machine to give the user id and group set of the user, the server instead looks for a mapping in the hash table. If no mapping is found, the request is either remapped to uid -2, or rejected immediately, depending on how the server is configured. This has been in use for about five or six months (and in heavy use since September), with very few problems. This is not as secure as Sun's experimental secure NFS system, which includes an authenticator on each request, but our approach involves a minimal performance overhead (when you use VAX 11/750's as servers, you need all the help you can get...), and requires no modifications to the client kernel, and also doesn't require any protocol changes to NFS itself. Bill Sommerfeld wesommer@athena.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [281182.871107.JBVB@AI.AI.MIT.EDU] <1987110707155700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Subnetting: I'm not sure I understand Message-ID: <281182.871107.JBVB@AI.AI.MIT.EDU> Date: Sat, 7-Nov-87 12:15:57 EST Article-I.D.: AI.281182.871107.JBVB Posted: Sat Nov 7 12:15:57 1987 Date-Received: Sat, 14-Nov-87 15:27:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Subnetting is explained best in RFC950. Most of what it is good for is allowing you to divide one of the larger types of network (Class A or Class B - 24 or 16 bits worth of host number) up into smaller administrative or cable-oriented networks. You are assumed to have IP routers (gateways) between them to handle internal forwarding, but to the rest of the world, you look monolithic (i.e. they send to net 128.127, and don't care that it has 254 subnets, each of the form 128.127.xxx, because your gateways hide that from the world). You can use it on class C addresses, but with only 254 hosts, there is less to divide. Almost all subnetting implementations allow you to do your division on bit boundaries, but there have been a few which could only do it by bytes. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [281189.871107.JBVB@AI.AI.MIT.EDU] <1987110707333500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple subnets on one physical net Message-ID: <281189.871107.JBVB@AI.AI.MIT.EDU> Date: Sat, 7-Nov-87 12:33:35 EST Article-I.D.: AI.281189.871107.JBVB Posted: Sat Nov 7 12:33:35 1987 Date-Received: Sat, 14-Nov-87 15:50:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 As usual, everyone was right, in the context. Mike Karels described the behaviour of his Unix, 4.3, which ought to work right in this situation. Other people have described *their* Unices, and other O/Ss, like Phil's LISPMs, which are going to give trouble. There are several problems you'll run into: The first is that some 4.2- derived systems believe in broadcast addresses of Net.0, and other systems believe in Net.255. The second is that some manufacturers leave their Unices believing that they are IP routers, even when they have only one network interface. The third is that some manufacturers don't include code to implement the law "don't reply to broadcast packets unless you're *really* *sure* you ought to". The fourth is that some manufacturers don't understand about subnets. The end result of this is that on one net I know, an Old-Broadcastian sends an rwho packet, and 29 (or more - my monitor was only an XT) Sun and Vax New-Broadcastians immediately attempt to either forward the packet (they think they're gateways), or send an ICMP Net Unreachable (gateway-ism partly disabled). Great fun. Also available between systems that do and don't grok subnets, and the two together are greater than the sum or the parts. Phil Karn cited some misbehavers. There are others. All can be fixed if you have source, most can be fixed through patience and vigilance on the part of a network administrator (watching and making people correct mis-configured systems). jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110709232900> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Sat 7 Nov 87 14:50:59-PST To: Greg Satz cc: tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM Subject: Re: EGP instability In-reply-to: Your message of Fri, 06 Nov 87 11:45:07 -0800. <12348508863.13.SATZ@MATHOM.CISCO.COM> Date: Sat, 07 Nov 87 17:43:29 -0500 From: Mike Brescia Is anyone else having trouble maintaining their peer relationships with the core? We are seeing excessive problems with high packet loss and eventually being dropped. Greg, There is an arpanet/internet 'event' happening which shows up as long queues in both directions between the PSNs and the core gateways. Also, the psn-gateway connection is broken frequently which causes all the queued packets to be discarded. Does your gateway on the arpanet get clogged also? One change that may have affected the system is the introduction of fragmented NR messages (EGP updates), which now take 2 arpanet messages each longer than 128 bytes; the fragments are about 1000 bytes and 200 bytes, and growing. Some facets of the problem that are being explored are the differences between the arpanet PSN software release 7 and the old release 6, speeding up the processors in the core systems (upgrade lsi-11/23 to /73), and checking the timing on the EGP implementations. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711072213.AA19075@athos.rutgers.edu] <1987110712133200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Slang Glossary Message-ID: <8711072213.AA19075@athos.rutgers.edu> Date: Sat, 7-Nov-87 17:13:32 EST Article-I.D.: athos.8711072213.AA19075 Posted: Sat Nov 7 17:13:32 1987 Date-Received: Sat, 14-Nov-87 04:17:29 EST References: <1197@omepd> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 fuzzball - the name of a kind of IP router. It is based on an LSI-11, and is used on the NSFnet backbone and various other critical places. The code is maintained by Dave Mills, and is often referred to by him as "fuzzware". swamp - a collection of networks. The implication is that they overall architecture is somewhat dubious (e.g. connected by a mixture of level 2 and level 3 things, with several networks numbers on a single cable). bogon - a bogus packet, often a packet that has escaped the net it is supposed to be on, e.g. a packet on the Arpanet addressed to 127.0.0.1 (the Unix loopback interface address), however it is also used to refer to packets with other kinds of errors. Martian - properly speaking, a packet addressed to net 126.0.0.0, which is reserved for the Central University of Mars. By extension, any packet addressed to an unallocated or reserved IP address, or to a broadcast address. (These packets could also be called bogons, of course.) A "Martian filter" is a pieces of code designed to discard Martians. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711072246.AA07908@ngp.utexas.edu] <1987110712462800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jones@NGP.UTEXAS.EDU (William L. Jones) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet - Hyperchannel Gateway Message-ID: <8711072246.AA07908@ngp.utexas.edu> Date: Sat, 7-Nov-87 17:46:28 EST Article-I.D.: ngp.8711072246.AA07908 Posted: Sat Nov 7 17:46:28 1987 Date-Received: Sat, 14-Nov-87 03:10:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 How much cray2 cpu was required to run the memory to memory TCP test at 17 mbit/sec? William L. Jones University of Texas System CHPC ----MESSAGE-END---- ----MESSAGE-BEGIN---- [281424.871107.PAP4@AI.AI.MIT.EDU] <1987110716091500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/DECnet interchange router for VMesS Message-ID: <281424.871107.PAP4@AI.AI.MIT.EDU> Date: Sat, 7-Nov-87 21:09:15 EST Article-I.D.: AI.281424.871107.PAP4 Posted: Sat Nov 7 21:09:15 1987 Date-Received: Sat, 14-Nov-87 04:28:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Date: 2 Nov 87 19:34:27 GMT From: unmvax!merlin!mcdermot@ucbvax.Berkeley.EDU (John McDermott) I have a problem which I hope someone has already solved: I have a TCP/IP net and a large DECnet net both served by a common VAX (vms). Some hosts on the decnet network also run tcp/ip. All tcp is CMU/TEK for vms. Now the question: are there drivers to encapsulate ip packets, send them over the DECnet and then make them available for retransmission at the other end? I need this because my VAX with Decnet is connected to the rest of the DECnet network by a 56kb line and that line cannot be used for both decnet and tcp/ip (for political reasons at least). Any help would be really appreciated. Well, you did say `any'. Mike Parker at McGill University (address musocs!mcgill-vision!mouse@eddie.mit.edu) wrote an IP over DECnet device driver for UNIX 4.3BSD. If you have any 4.3 hosts on your subnet, you could make it the IP gateway to the other side of that phone line. I believe that is what they do at McGill and it seems to work fairly well. I heard about someone doing the same for VMS, but I don't remember who (was it Lou Salkind at NYU?) Hope this helps, -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711080223.AA07353@uc.msc.umn.edu] <1987110716230000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: slevy@UMN-REI-UC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <8711080223.AA07353@uc.msc.umn.edu> Date: Sat, 7-Nov-87 21:23:00 EST Article-I.D.: uc.8711080223.AA07353 Posted: Sat Nov 7 21:23:00 1987 Date-Received: Sat, 14-Nov-87 11:53:26 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 64 On IP & Ethernet address spoofing -- If there's no LAN bridge between you and the target, it's easy. If there is, you may still be able to fool the bridge into passing stuff onto your side. If you want to look like host X (of IP address X.IP and MAC-level address X.MAC), it may suffice to send out some packets with MAC source address X.MAC. When the bridge sees those, it may well get confused about where X.MAC really is, and start routing X.MAC-destined packets onto your part of the wire. Presumably this depends on the bridge's design, and I've never actually tried it, but it does sound plausible. Another trick, not dependent on the bridge behavior, would be to send an ICMP host redirect to the target, telling it to route traffic to X via your own IP address (or some bogus one which you were willing to ARP for). That should work even when X is up. We're considering making our own hosts ignore ICMP redirects for this reason, despite the loss of functionality. We're also considering fixing our gateways in an unorthodox way -- to look at the IP -source- address of arriving packets. If a packet arrives from host Y, on an interface to which that gateway would never route packets to Y, the gateway discards the packet. If all the gateways in a system[*] act this way, a spoofer can pretend to be someone else on the same net, but not someone on another net. So IP gateways can be made to be firewalls in a way that MAC-layer bridges can't (unless the bridges get their routing tables from the net administrator rather than learning by listening). In this case the gateways, too, need to be careful about what ICMP redirects they believe... perhaps by having an administrator-supplied list of GW's, where redirects are believed only if they point to (not just come from!) a legitimate GW. [*]Well... the above sort of works. I think it only really is reliable if the structure of the "system" is a special one -- where all the gateways and all the paths between them are trustworthy, and all the untrusted nets are one GW away from the trusted backbone. Redundancy is still possible, and the backbone can have any structure, but rigid separation of trusted from untrusted hosts & wires still is a pretty severe restriction. Maybe this amounts to an argument for higher-level, end-to-end authentication. While I'm at this, how about NFS security. I think the fake setuid hole can be plugged: SUN's NFS at least has a "nosuid" mount option, and you can just arrange to mount all non-system file systems with it. Then only the server of system files needs to be secure. However, a local superuser can get access to any non-root user's files simply by setting his uid to the right thing. So can any Joe with a PC who goes to the trouble to write an NFS client, which can claim to be any IP address, Ethernet address, and uid it wishes. And as far as I know, NFS (unlike TCP) won't even turn a hair if multiple clients on a net claim to be the same machine -- each ignores responses to the others' requests. SUN's RPC authentication scheme, which derives keys from user passwords, distributes them with a public-key scheme, and uses DES to authenticate transactions after the keys are established, seems promising in this regard. (It was written up in a paper in Summer '86 Usenix, and was supposed to be released with Sun 4.0 the last I heard, along with an NFS that optionally uses it.) One thing I worry about, though. It appears secure enough that people might be willing to allow root access across NFS. But, if anyone finds a hole allowing them to be root -without rebooting the machine- they'll easily gain root access to everything sharing filesystems with them -- a hole bigger than the present one. Stuart Levy, Minn. Supercomputer Center slevy@uf.msc.umn.edu, 612-626-0211 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711030915.AA00844@gumby.wisc.edu] <1987110716461200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: g-tasman@GUMBY.WISC.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ..."layering violations" Message-ID: <8711030915.AA00844@gumby.wisc.edu> Date: Sat, 7-Nov-87 21:46:12 EST Article-I.D.: gumby.8711030915.AA00844 Posted: Sat Nov 7 21:46:12 1987 Date-Received: Tue, 10-Nov-87 04:49:37 EST References: <12347435144.54.PADLIPSKY@A.ISI.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 You suggest that if a "host down" indication is received, a daemon should immediately close the associated TCP connection. With an 1822 Distant Host connection to DDN, this may be a fairly reasonable approach. However, a typical DDN connection of late has been X.25 or HDH. Here, "host down" may have a more transitory meaning: simply that there was noise on the host access line. The remote host may well reappear with all TCP connections intact. Consider in particular the case of a Telnet server. If connections are cleared prematurely/incorrectly, extremely annoyed users will result. On the other hand, I understand all too well the importance of eventually detecting and closing "half-open" connections which result from an actual crash (since these will eventually inhibit new remote terminal sessions). The issue of distinguishing between a dead host and an "unhealthy" host access line is likely to become increasingly serious over time, as more DDN hosts switch to synchronous access protocols. For a network client, remote host status can simply be reported to the (human) user. For a server, however, I don't see a straightforward solution. Mitchell Tasman ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711072358.aa18196@Huey.UDEL.EDU] <1987110718583900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: INARC Workshop announcement Message-ID: <8711072358.aa18196@Huey.UDEL.EDU> Date: Sat, 7-Nov-87 23:58:39 EST Article-I.D.: Huey.8711072358.aa18196 Posted: Sat Nov 7 23:58:39 1987 Date-Received: Sat, 14-Nov-87 12:44:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 120 Folks, This is a repeat of last month's announcement on a planned meeting of the Internet Architecture Task Force. Please note the meeting dates have been changed from the original 17-18 November to 17-18 December. The meeting place is unchanged. Please note also the revised and clarified wording in the announcement itself. The Internet Architecture Task Force (INARC) studies technical issues in the evolution of the Internet from its present architectural model to new models appropriate for very large, very fast internets of the future. It is organized as a recurring workshop where researchers, designers and implementors can discuss novel ideas and experiences without limitation to the architecture and engineering of the present Internet. The output of this effort represents advance planning for a next-generation internet, as well as fresh insights into the problems of the current one. The INARC is planning a two-day retreat/workshop for 17-18 December at BBN to discuss a fresh start on advanced internet concepts and issues. The agenda for this meeting will be to explore architecture and engineering issues in the design of a next-generation internet system. The format will consist of invited presentations on selected topics followed by a general discussion on related issues. Written contributions of suitable format and content will be submitted for publication in the ACM Computer Communication Review. In order to have the most stimulating discussion possible, the INARC is expanding the list of invitees to include any researchers with agenda to plow, axe to grind, sword to wield or any other useful instrument for that matter. While not a precondition for admission, participants are encouraged to contribute concise presentations, either written or oral (fifteen to thirty minutes), in electronic form to mills@udel.edu or in hardcopy form to Dr. David L. Mills Electrical Engineering Department University of Delaware Newark, DE 19716 (302) 451-6534 or 737-9211 Speakers will be selected on the basis of quality, relevance and interest. Every effort will be made to accomodate all participants that wish to attend; however, participants are asked to contact the chairman by electronic mail or telephone at least a week in advance to confirm their intention to attend. Following is a list of possible areas and issues of interest to the community. Readers are invited to submit additions, deletions and amendments. 1. How should the next-generation internet be structured, as a network of internets, an internet of internets or both or neither? Do we need a hierarchy of internets? Can/must the present Internet become a component of this hierarchy? 2. What routing paradigms will be appropriate for the new internet? Will the use of thinly populated routing agents be preferred over pervasive routing data distribution? Can innovative object-oriented source routing mechanisms help in reducing the impact of huge, rapidly changing data bases? 3. Can we get a handle on the issues involved in policy-based routing? Can a set of standard route restrictions (socioecononic, technopolitic or bogonmetric) be developed at reasonable cost that fit an acceptable administrational framework (with help from the Autonomous Networks Task Force)? How can we rationalize these issues with network control and access-control issues? 4. How do we handle the expected profusion of routing data? Should it be hierarchical or flat? Should it be partitioned on the basis of use, service or administrative organization? Can it be made very dynamic, at least for some fraction of clients, to support mobile hosts? Can it be made very robust in the face of hackers, earthquakes and martians? 5. Should we make a new effort to erase intrinsic route-binding in the existing addressing mechanism of the Internet IP address and ISO NSAP address? Can we evolve extrinsic binding mechanisms that are fast enough, cheap enough and large enough to be useful on an internet basis? 6. Must constraints on the size and speed of the next-generation internet be imposed? What assumptions scale on the delay, bandwidth and cost of the network components (networks and gateways) and what assumptions do not? 7. What kind of techniques will be necessary to accellerate reliable transport service from present speeds in the low megabit range to speeds in the FDDI range (low hundreds of megabits)? Can present checksum, window and backward-correction (ARQ) schemes be evolved for this service, or should we shift emphasis to forward-correction (FEC) and streaming schemes. 8. What will the internet switch architecture be like? Where will the performance bottlenecks likely be? What constraints on physical, link and network-layer protocols will be advisable in order to support the fastest speeds? Is it possible to build a range of switches running from low-cost, low-performance to high-cost, high-performance? 9. What form should a comprehensive congestion-control mechanism take? Should it be based on explicit or implicit resource binding? Should it be global in scope? Should it operate on flows, volumes or some other traffic characteristic? 10. Do we understand the technical issues involved with service-oriented routing, such as schedule-to-deadline, multiple access/multiple destination, delay/throughput reservation and resource binding? How can these issues be coupled with effective congestion-control mechanisms? 11. What will be the relative importance of delay-based versus flow-based service specifications to the client population? How will this affect the architecture and design? Can the design be made flexible enough to provide a range of services at acceptable cost? If so, can the internet operation setpoint be varied, automatically or manually, to adapt to different regimes quickly and with acceptable thrashing? 12. What should the next-generation internet header look like? Should it have a variable-length format or fixed-length format? How should options, fragmentation and lifetime be structured? Should source routing or encapsulation be an intrinsic or derived feature of the architecture? 13. What advice can we give to other task forces on the impact of the next-generation internet in their areas of study? What research agenda, if any, should we propose to the various NSF, DARPA and other agencies? What advice can we give these agencies on the importance, level of effort and probablity of success of the agenda to their current missions? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4797@elroy.Jpl.Nasa.Gov] <1987110719513700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: david@elroy.Jpl.Nasa.Gov (David Robinson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge (really: NFS "security") Message-ID: <4797@elroy.Jpl.Nasa.Gov> Date: Sun, 8-Nov-87 00:51:37 EST Article-I.D.: elroy.4797 Posted: Sun Nov 8 00:51:37 1987 Date-Received: Tue, 10-Nov-87 01:02:02 EST References: <8711062349.AA04106@ucbvax.Berkeley.EDU> <1761@bloom-beacon.MIT.EDU> Organization: Image Analysis Systems Grp, JPL Lines: 49 In article <1761@bloom-beacon.MIT.EDU>, wesommer@athena.mit.edu (William Sommerfeld) writes: > In article <8711062349.AA04106@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes: > >OK, I'll bite. We have been looking at NFS as a UNIX/VMS server solution > >for PCs. From the begining of the investigation we were looking for > >things like the 'huge security holes'. > > Huge security holes is correct. [I won't even talk about vulnerability > to malformed packets] > ... > There is a minor complication, which is that to do anything > meaningful, you need to know a "file handle" for a directory on one > filesystem. Once you have the file handle, you can do anything you > want to the file system, because you can claim an arbitrary user-id in > the packet, and the server will trust you. > ... [More discussion of the file handle contents] It is very true that NFS is not very secure and it is doubtful that it ever will be VERY secure. As with most network protocols, someone with a little patience and a packet monitor can figure out the protocol. The best way to fight this is to have packet data that is not easy to spoof or even figure out. Using various encryption methods such as public/private key or DES etc helps. Your point about the file handle points out a current weak spot that does not have to exist. The file handle is created on the server and only it is required to know the contents. The client just blindly passes it back whenever it wants that file. You have described quite well the portable NFS file handle for Unix, but on machines such as VMS this doesn't hold, it's file handle is completely different and possibly somewhat strange. The server does not have to use a simple method such as placing the inode in the in the file handle, it could encrypt the inode number with DES first for example. In general to make a protocol such as NFS truly portable and easy to use you must make some sacrifices in security. It is possible to spoof RFS or DECNET but it is more difficult because the protocol is much tighter. But NFS has a lot of room to grow and I do forsee improvement. -David Robinson -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ames!elroy!david UUCP Disclaimer: No one listens to me anyway! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711081258.AA09379@nic.nyser.net] <1987110802585200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: yeongw@NISC.NYSER.NET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: SGMP Message-ID: <8711081258.AA09379@nic.nyser.net> Date: Sun, 8-Nov-87 07:58:52 EST Article-I.D.: nic.8711081258.AA09379 Posted: Sun Nov 8 07:58:52 1987 Date-Received: Sat, 14-Nov-87 14:58:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 > Does anyone know where I can get info concerning SGMP (Simple > Gateway Mgmt. Protocol)? Anything would be helpful. The RFC-to-be can be obtained by anonymous ftp from nisc.nyser.net 128.213.1.13 in pub/simple-mon.rfc. There is an sgmp mailing list, simple-umon@nisc.nyser.net for sgmp developers. Wengyik Yeong yeongw@nisc.nyser.net ..!rutgers!nysernic!yeongw ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711081702.AA14650@topaz.rutgers.edu] <1987110807025900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Security and Access Restrictions Message-ID: <8711081702.AA14650@topaz.rutgers.edu> Date: Sun, 8-Nov-87 12:02:59 EST Article-I.D.: topaz.8711081702.AA14650 Posted: Sun Nov 8 12:02:59 1987 Date-Received: Sat, 14-Nov-87 18:39:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 CISCO and other IP gateways have access control lists that allow you to restrict which packets can go to which hosts passing through a gateway. We use this primarily to keep students on our public terminal servers off the arpanet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711081712.AA14940@topaz.rutgers.edu] <1987110807121400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/DECnet interchange router for VMesS Message-ID: <8711081712.AA14940@topaz.rutgers.edu> Date: Sun, 8-Nov-87 12:12:14 EST Article-I.D.: topaz.8711081712.AA14940 Posted: Sun Nov 8 12:12:14 1987 Date-Received: Tue, 17-Nov-87 00:45:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Wollongong makes such a thing (I believe they call it dbridge). We used it for a while and although it worked just fine, it was real slow for the IP traffic. However, I talked to some people more recently and they say that it is much improved. We stopped running it because we put a more sophisticated serial line in place. Your only other alternative is to use one of the routers that does both IP and DECNET (Proteon, CISCO...) or something like a level-2 serial bridge (UB Data Link Bridge, Vegalink TRANSLan). -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711081715.AA14986@topaz.rutgers.edu] <1987110807151500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: can pmdf be run over tcp-ip? Message-ID: <8711081715.AA14986@topaz.rutgers.edu> Date: Sun, 8-Nov-87 12:15:15 EST Article-I.D.: topaz.8711081715.AA14986 Posted: Sun Nov 8 12:15:15 1987 Date-Received: Sat, 14-Nov-87 20:59:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 1 The P in PMDF stands not for phone but for PASCAL. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711081434.aa25516@Huey.UDEL.EDU] <1987110809344300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Life after source quench Message-ID: <8711081434.aa25516@Huey.UDEL.EDU> Date: Sun, 8-Nov-87 14:34:43 EST Article-I.D.: Huey.8711081434.aa25516 Posted: Sun Nov 8 14:34:43 1987 Date-Received: Sat, 14-Nov-87 14:56:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 139 Folks, Thanks to Hans-Werner Braun, who scrounged the log of the NCAR (National Center for Atmospheric Research) fuzzball gateway on the NSFNET Backbone net, we may have additional insight as to the effectiveness of its quench mechanism and the implications for TCP implementations. The NCAR fuzzball is seriously overloaded at times and, using the preemption and quench policies described previously to this group, can be quite vocal about it. ICMP Source Quench messages are sent when the mean queue length exceeds about 1.5 and at a rate depending on the number of 256-octet blocks queued for a selected host. Presently, only the host with the largest number of blocks is selected on the assumption that quenchable flows do not occur very often and are almost always due to a single host. See my previous messages for justification. The following data illustrates typical scenarios found at NCAR. Each line represents one quench message sent for traffic in the direction shown between the two hosts. The two three-digit numbers are the ICMP type and code fields (octal), where the code (second) field reveals the number of 256-octet blocks queued at the time the quench was sent. (This interpretation of the code field is at variance with the spec, but this is research, right?) As expected, quenchable flows are relatively infrequent and are characterized by large traffic surges lasting up to several minutes. For example, the code field for the first line shows 120 (170 octa1) 256-octet segments sent by host 128.6.4.7 to host 128.102.16.10 living on a single output queue! In the first surge the flow lasted about a minute during which six quenches were sent. It is not cear from these data what the preemption policy was doing, but it is likely that some quantity of packets were being dropped during this period. HOST : 128.6.4.7 : RUTGERS.EDU,RUTGERS.RUTGERS.EDU,RUTGERS.ARPA : SUN-3/180 18:25:45 ?TRAP-I-ICMP 004 170 [128.6.4.7] -> [128.102.16.10] 18:25:46 ?TRAP-I-ICMP 004 135 [128.6.4.7] -> [128.102.16.10] 18:25:47 ?TRAP-I-ICMP 004 105 [128.6.4.7] -> [128.102.16.10] 18:26:38 ?TRAP-I-ICMP 004 127 [128.6.4.7] -> [128.102.16.10] 18:26:42 ?TRAP-I-ICMP 004 140 [128.6.4.7] -> [128.102.16.10] 18:26:44 ?TRAP-I-ICMP 004 135 [128.6.4.7] -> [128.102.16.10] The next surge shows a seven-minute surge at the beginning and two shorter surges at the end, with only sporadic quenches between. HOST : 128.117.8.7 : (unlisted - who is this USAN dude?) 20:26:43 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] 20:26:45 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2] 20:26:46 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2] 20:27:16 ?TRAP-I-ICMP 004 101 [128.117.8.7] -> [128.118.28.2] 20:27:28 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] 20:27:30 ?TRAP-I-ICMP 004 151 [128.117.8.7] -> [128.118.28.2] 20:27:30 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] 20:27:45 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2] 20:28:11 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.118.28.2] 20:28:12 ?TRAP-I-ICMP 004 142 [128.117.8.7] -> [128.118.28.2] 20:28:32 ?TRAP-I-ICMP 004 142 [128.117.8.7] -> [128.118.28.2] 20:28:33 ?TRAP-I-ICMP 004 110 [128.117.8.7] -> [128.118.28.2] 20:28:48 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] 20:29:31 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] 20:29:31 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2] 20:30:27 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.118.28.2] 20:30:47 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2] 20:31:23 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] 20:31:24 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2] 20:31:36 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2] 20:31:37 ?TRAP-I-ICMP 004 151 [128.117.8.7] -> [128.118.28.2] 20:31:41 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2] 20:31:53 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] 20:32:06 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2] 20:32:07 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] 20:32:10 ?TRAP-I-ICMP 004 142 [128.117.8.7] -> [128.118.28.2] 20:32:27 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2] 20:32:33 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2] 20:32:34 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] 20:32:35 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2] 20:32:56 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2] 20:32:58 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2] 20:33:15 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.118.28.2] 20:48:14 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.118.28.2] 20:54:21 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.118.28.2] 21:46:50 ?TRAP-I-ICMP 004 104 [128.117.8.7] -> [128.118.28.2] 21:46:51 ?TRAP-I-ICMP 004 104 [128.117.8.7] -> [128.112.18.2] 21:58:30 ?TRAP-I-ICMP 004 124 [128.117.8.7] -> [128.112.18.2] 21:58:37 ?TRAP-I-ICMP 004 110 [128.117.8.7] -> [128.112.18.2] 23:28:31 ?TRAP-I-ICMP 004 112 [128.117.8.7] -> [128.112.18.2] 23:28:35 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.112.18.2] 23:28:36 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.112.18.2] 23:28:37 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.112.18.2] 23:28:40 ?TRAP-I-ICMP 004 115 [128.117.8.7] -> [128.112.18.2] 23:28:43 ?TRAP-I-ICMP 004 106 [128.117.8.7] -> [128.112.18.2] The next one is a real hotrod, with 17 quenches in 24 seconds. HOST : 129.93.1.3 : (unlisted) 22:04:31 ?TRAP-I-ICMP 004 113 [129.93.1.3] -> [128.84.252.18] 22:04:35 ?TRAP-I-ICMP 004 110 [129.93.1.3] -> [128.84.252.18] 22:04:36 ?TRAP-I-ICMP 004 116 [129.93.1.3] -> [128.84.252.18] 22:04:36 ?TRAP-I-ICMP 004 127 [129.93.1.3] -> [128.84.252.18] 22:04:37 ?TRAP-I-ICMP 004 140 [129.93.1.3] -> [128.84.252.18] 22:04:37 ?TRAP-I-ICMP 004 151 [129.93.1.3] -> [128.84.252.18] 22:04:38 ?TRAP-I-ICMP 004 146 [129.93.1.3] -> [128.84.252.18] 22:04:38 ?TRAP-I-ICMP 004 132 [129.93.1.3] -> [128.84.252.18] 22:04:39 ?TRAP-I-ICMP 004 105 [129.93.1.3] -> [128.84.252.18] 22:04:51 ?TRAP-I-ICMP 004 113 [129.93.1.3] -> [128.84.252.18] 22:04:52 ?TRAP-I-ICMP 004 143 [129.93.1.3] -> [128.84.252.18] 22:04:52 ?TRAP-I-ICMP 004 165 [129.93.1.3] -> [128.84.252.18] 22:04:53 ?TRAP-I-ICMP 004 170 [129.93.1.3] -> [128.84.252.18] 22:04:53 ?TRAP-I-ICMP 004 157 [129.93.1.3] -> [128.84.252.18] 22:04:54 ?TRAP-I-ICMP 004 140 [129.93.1.3] -> [128.84.252.18] 22:04:54 ?TRAP-I-ICMP 004 127 [129.93.1.3] -> [128.84.252.18] 22:04:55 ?TRAP-I-ICMP 004 102 [129.93.1.3] -> [128.84.252.18] I am told the Craymonsters do in fact something useful with ICMP Source Quench messages. There is some evidence for that in the following, which shows a surge lasting about a minute, but with the quenches mostly spread out at about thirty-second intervals (except the last one), not in terrible spasms like the above. If a Craymonster can be tamed with a quench every thirty seconds or so, they may be pussycats, not monsters, after all. HOST : 128.174.10.48 : NCSAD.ARPA : CRAY-X/MP : 22:15:30 ?TRAP-I-ICMP 004 102 [128.174.10.48] -> [128.84.252.18] 22:16:06 ?TRAP-I-ICMP 004 110 [128.174.10.48] -> [128.84.252.18] 22:16:36 ?TRAP-I-ICMP 004 110 [128.174.10.48] -> [128.84.252.18] 22:16:37 ?TRAP-I-ICMP 004 124 [128.174.10.48] -> [128.84.252.18] The data suggest that a quench policy operating with a relatively long integration time, such as the fuzzball policy and the policy suggested by Raj Jain (the so-called DEC-bit) can indeed be effective. However, it is not at all clear from the above data that the surges are due to a single TCP connection, unless that connection was using window sizes in the 26000-octet range. If multiple connections are involved, an effective quench strategy may need to operate over several simultaneous and concurrent connections and retain state over periods up to a minute or more. The operating system would then have to restrain individual connections as a function of environment variables independent of window modulation by the protocol itself. If it is true that single connections with humungus windows are most prevalent, then TCP window-drawdown strategies such as previously suggested would work peachy-keen. Comments from the host administrators of the above hosts would be welcome. Can somebody describe the Craykitten anti-monster implementation? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711082007.AA03691@ACC-SB-UNIX.ARPA] <1987110810075000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@ACC-SB-UNIX.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: distribution list Message-ID: <8711082007.AA03691@ACC-SB-UNIX.ARPA> Date: Sun, 8-Nov-87 15:07:50 EST Article-I.D.: ACC-SB-U.8711082007.AA03691 Posted: Sun Nov 8 15:07:50 1987 Date-Received: Sat, 14-Nov-87 18:27:15 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Can you please add me to the TCP-IP list. From what I've seen most correspondence is pertinent to what I've been doing at ACC. Thanks very much, Chris VandenBerg Applications Engineer (chris@acc-sb-unix.arpa) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [281795.871108.JBVB@AI.AI.MIT.EDU] <1987110812004100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <281795.871108.JBVB@AI.AI.MIT.EDU> Date: Sun, 8-Nov-87 17:00:41 EST Article-I.D.: AI.281795.871108.JBVB Posted: Sun Nov 8 17:00:41 1987 Date-Received: Sun, 15-Nov-87 06:19:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 ... Now, what I'm gonna do is put a permanent entry in Elsie's ARP cache with Bossie's IP number and ethernet address. Well, I reckon you can get a packet to Elsie that she'll think came from Bossie, but I'd like to know how you're going to see the packets coming from Elsie destined for Bossie. Eric Norman I haven't yet encountered an Ethernet interface that didn't allow you to program its hardware address at initialization time. DECnet relies on this to get by without ARP. With some software (ours, for instance), you must patch (or use a PROM burner) to change the Ether address, but a lot of other packages offer it as a configuration option, so don't count on a pre-loaded ARP cache to protect security where hosts are "equivalent". I'm not a big-time NFS hacker, but I've been told that in an environment where users can re-boot (or power cycle) their workstations and bring them up single-user, any file that is accessible by anyone over the network should be assumed to be accessible by everyone. James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [281907.871108.PAP4@AI.AI.MIT.EDU] <1987110816293800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: ARPANET<->MILNET problems Message-ID: <281907.871108.PAP4@AI.AI.MIT.EDU> Date: Sun, 8-Nov-87 21:29:38 EST Article-I.D.: AI.281907.871108.PAP4 Posted: Sun Nov 8 21:29:38 1987 Date-Received: Sun, 15-Nov-87 07:24:41 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Date: 5 Nov 87 07:37:27 GMT From: jbs@eddie.mit.edu (Jeff Siegal) I've been trying to ftp some files from ECLA.USC.EDU (on MILNET) to MIT (on ARPANET) and have had no success for the past week. The Unix ping program reports round-trip-times of 20-40 seconds and packet loss rates varying between 70 and 100 percent. Is there some current problem that is likely to be corrected, or should we give up and resort to Federal Express and magtape? Jeff Siegal I have been having similar problems to Jeff's. I have been trying to reach a couple of hosts at CMU, with little success. FTPs and TELNETs timeout before the connection is established. None of my pings have gotten through. On the few occasions (2 or 3 times in many hours) that my FTPs did connect, logging in took about 2 minutes, and getting a 14k file took more than 40 minutes, sometimes not even finishing... Reaching the NIC has not been a problem, though. Is this a side effect of 7.1 or isolated problems? I haven't been able to reach the NOC, but will call them Monday... -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [141@ncc.UUCP] <1987110819112600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lyndon@ncc.UUCP (Lyndon Nerenberg) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Microport TCP recommendations Message-ID: <141@ncc.UUCP> Date: Mon, 9-Nov-87 00:11:26 EST Article-I.D.: ncc.141 Posted: Mon Nov 9 00:11:26 1987 Date-Received: Tue, 10-Nov-87 06:47:52 EST Distribution: comp Organization: Nexus Computing Inc. Lines: 19 We have a 286/AT clone running Microport System V/AT and MSDOS 3.2. We're looking for a TCP/IP implementation to run under both OS's (preferably from the same vendor). The DOS side requires telnet and ftp. Under UNIX, we require telnet, ftp, rlogin, and something that runs SMTP and can talk to sendmail (native sendmail would be nice). The UNIX implementation must also support NFS. The environment consists of the AT, a Sun 3/280, and a mixture of Convergent hardware running on a thicknet. If you're running such a setup, please drop me a line describing your configuration. Thanks all, Lyndon Nerenberg Nexus Computing Inc. {alberta,pyramid,uwvax}!ncc!lyndon || lyndon%ncc.uucp@spool.wisc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4800@elroy.Jpl.Nasa.Gov] <1987110820051800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: david@elroy.Jpl.Nasa.Gov (David Robinson) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet versions Message-ID: <4800@elroy.Jpl.Nasa.Gov> Date: Mon, 9-Nov-87 01:05:18 EST Article-I.D.: elroy.4800 Posted: Mon Nov 9 01:05:18 1987 Date-Received: Wed, 11-Nov-87 02:40:45 EST Organization: Image Analysis Systems Grp, JPL Lines: 21 Keywords: info? As most people know their are a couple ethernet standards, Version 1, Version 2 and IEEE 803.2. When one installs a new ethernet board they must have the correct transeiver level to match the type that the board supports, fortunately a lot of modern boards have jumpers to support different versions. I have found that you can run both level 1 and level 2 transeivers on the same cable. The question: What is the difference between the versions and what effect is their on the physical wire to run two different types of transeivers? I have heard people say that it is best to have all the same type but no "real" evidence to base that comment on. Could someone mail me either a description of the differences or pointers to the available documentation that would answer these questions. As always if their is enough interest I will summarize to the net. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ames!elroy!david UUCP Disclaimer: No one listens to me anyway! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711090128.aa01865@Huey.UDEL.EDU] <1987110820285700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Slang Glossary Message-ID: <8711090128.aa01865@Huey.UDEL.EDU> Date: Mon, 9-Nov-87 01:28:57 EST Article-I.D.: Huey.8711090128.aa01865 Posted: Mon Nov 9 01:28:57 1987 Date-Received: Sun, 15-Nov-87 08:21:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Wire, You have a wonderful treat in store for you. Don't worry about the slang, since after all it changes warp and woof as the seasons do go by. After a few months of delicious indifference it will all come clear to you in a flash: bogons are alien invaders, gong is the stuff outhouses sit on and fuzzballs are what dry-cleaning establishments remove for a living. Do I lie? Ask anybody. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110901060000> Received: from twg.arpa by SRI-NIC.ARPA with TCP; Mon 9 Nov 87 09:12:48-PST Date: 9 Nov 87 09:06:00 PST From: "Jerry Scott" Subject: RE: TCP/DECnet interchange router for VMS To: "mcdermott%atavax.decnet" cc: Van Jacobson and Craig Leres implemented a IP over DECNET interface a few years back. Basically it allows IP to use DECNET as though it were a hardware interface. Wollongong and SRI both support this software in their standard products under the product name DBRIDGE. Jerry Scott ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711091137.AA13007@uxc.cso.uiuc.edu] <1987110901375700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: krol@UXC.CSO.UIUC.EDU (Ed Krol) Newsgroups: comp.protocols.tcp-ip Subject: Life after source quench Message-ID: <8711091137.AA13007@uxc.cso.uiuc.edu> Date: Mon, 9-Nov-87 06:37:57 EST Article-I.D.: uxc.8711091137.AA13007 Posted: Mon Nov 9 06:37:57 1987 Date-Received: Sun, 15-Nov-87 10:16:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 The following is an excerpt from a paper by Charlie Kline (kline@uxc.cso.uiuc.edu) given at this summers Sigcom in Stowe describing the Cray CTSS source quenched algorithm which Dave seems impressed by: CTSS TCP/IP treats quenches as IP events rather than TCP events. Berkeley responds to quenches by reducing the size of the TCP window. We respond, as suggested by Postel in a draft RFC, by introducing a delay between the sending of IP packets to the host which is producing the quenches. The delay increases linearly as more quenches are received. If no quenches are received in a certain interval, the interval is decreased exponentially. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711140024.AA08717@ucbvax.Berkeley.EDU] <1987110903473100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: pogran@CCQ.BBN.COM (Ken Pogran) Newsgroups: comp.protocols.tcp-ip Subject: Internet performance Message-ID: <8711140024.AA08717@ucbvax.Berkeley.EDU> Date: Mon, 9-Nov-87 08:47:31 EST Article-I.D.: ucbvax.8711140024.AA08717 Posted: Mon Nov 9 08:47:31 1987 Date-Received: Sun, 15-Nov-87 11:14:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 A note regarding Internet and ARPANET performance: Many users have noted a degradation in Internet and ARPANET performance over the past few weeks, especially in end-to-end round-trip delay. There've been a few messages to tcp-ip about it, especially over the past week. BBN has been investigating the situation; while we have a pretty good handle on what's been happening, we don't yet fully understand why. The problem seems to center around the three ARPANET EGP Server gateways. The amount of ARPANET traffic destined for these gateways has increased dramatically in recent weeks. Moreover, they seem to be slower in processing incoming traffic. This has led to severe but highly localized congestion in the ARPANET. ARPANET round-trip delays to these gateways have skyrocketed; some gateways may not be able to maintain their EGP "connections" with the servers, resulting in Internet connectivity problems. Current speculation is that this is all related to the recent increase in the size of EGP routing updates such that these must now be fragmented by the servers into two ARPANET messages -- i.e., EGP routing update traffic in the ARPANET has effectively doubled. It's also possible that there's some tie-in between this problem and the ARPANET PSN 7 upgrade. There's no evidence that points in this direction, but on the other hand we have not yet ruled it out. On a more general note, it's also worth pointing out that in recent months, traffic on the ARPANET has grown at annualized rate of 50%, and this growth shows no signs of letting up. ARPANET and Internet capacity and performance is going to continue to be an issue in the future. Ken Pogran BBN Communications ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110903473101> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Mon 9 Nov 87 06:09:31-PST Date: Mon, 9 Nov 87 08:47:31 EST From: Ken Pogran Subject: Internet performance To: tcp-ip@sri-nic.arpa Cc: pogran@ccq.bbn.com A note regarding Internet and ARPANET performance: Many users have noted a degradation in Internet and ARPANET performance over the past few weeks, especially in end-to-end round-trip delay. There've been a few messages to tcp-ip about it, especially over the past week. BBN has been investigating the situation; while we have a pretty good handle on what's been happening, we don't yet fully understand why. The problem seems to center around the three ARPANET EGP Server gateways. The amount of ARPANET traffic destined for these gateways has increased dramatically in recent weeks. Moreover, they seem to be slower in processing incoming traffic. This has led to severe but highly localized congestion in the ARPANET. ARPANET round-trip delays to these gateways have skyrocketed; some gateways may not be able to maintain their EGP "connections" with the servers, resulting in Internet connectivity problems. Current speculation is that this is all related to the recent increase in the size of EGP routing updates such that these must now be fragmented by the servers into two ARPANET messages -- i.e., EGP routing update traffic in the ARPANET has effectively doubled. It's also possible that there's some tie-in between this problem and the ARPANET PSN 7 upgrade. There's no evidence that points in this direction, but on the other hand we have not yet ruled it out. On a more general note, it's also worth pointing out that in recent months, traffic on the ARPANET has grown at annualized rate of 50%, and this growth shows no signs of letting up. ARPANET and Internet capacity and performance is going to continue to be an issue in the future. Ken Pogran BBN Communications ----MESSAGE-END---- ----MESSAGE-BEGIN---- [435@mrecvax.UUCP] <1987110906214100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tron@mrecvax.UUCP (Carlos Mendioroz) Newsgroups: comp.protocols.tcp-ip,comp.unix.questions,comp.unix.wizards Subject: ICMP redirect messages. How to send ? Message-ID: <435@mrecvax.UUCP> Date: Mon, 9-Nov-87 11:21:41 EST Article-I.D.: mrecvax.435 Posted: Mon Nov 9 11:21:41 1987 Date-Received: Thu, 12-Nov-87 03:10:11 EST Reply-To: tron@mrecvax.UUCP (Carlos Mendioroz) Organization: M.R.E. y C. Bs. As. Argentina Lines: 19 Keywords: IP ICMP gateway redirect Hi! We have just installed a second ethernet interface on a uVax II running ULTRIX 1.2m and we would like to use it as a gateway between them. So far, so good. The problem is that the rest of the machines on both nets don't support the route protocol (/etc/routed) but they understand ICMP redirect messages, so the solution would be that the uVax sends such messages for the machines to update their route tables. Has anybody done such a thing ? Is there any program that uses the raw socket interface from where I can start doing it ? Thanks in advance. -Carlos Mendioroz UUCP: {uunet|pyramid|utai}!atina!mrecvax!tron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711140332.AA12542@ucbvax.Berkeley.EDU] <1987110907060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jerry@TWG.ARPA ("Jerry Scott") Newsgroups: comp.protocols.tcp-ip Subject: RE: TCP/DECnet interchange router for VMS Message-ID: <8711140332.AA12542@ucbvax.Berkeley.EDU> Date: Mon, 9-Nov-87 12:06:00 EST Article-I.D.: ucbvax.8711140332.AA12542 Posted: Mon Nov 9 12:06:00 1987 Date-Received: Sun, 15-Nov-87 11:53:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Van Jacobson and Craig Leres implemented a IP over DECNET interface a few years back. Basically it allows IP to use DECNET as though it were a hardware interface. Wollongong and SRI both support this software in their standard products under the product name DBRIDGE. Jerry Scott ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711091758.AA00176@bel.isi.edu] <1987110907581100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: postel@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: SGMP Message-ID: <8711091758.AA00176@bel.isi.edu> Date: Mon, 9-Nov-87 12:58:11 EST Article-I.D.: bel.8711091758.AA00176 Posted: Mon Nov 9 12:58:11 1987 Date-Received: Sun, 15-Nov-87 15:54:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 SGMP = Simple Gateway Mgmt Protocol = RFC-1028 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711091808.AA03474@uc.msc.umn.edu] <1987110908082600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: slevy@UC.MSC.UMN.EDU (Stuart Levy) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <8711091808.AA03474@uc.msc.umn.edu> Date: Mon, 9-Nov-87 13:08:26 EST Article-I.D.: uc.8711091808.AA03474 Posted: Mon Nov 9 13:08:26 1987 Date-Received: Sun, 15-Nov-87 16:50:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 We have GS/3's, and I've never seen them exhibit this problem. I just ran an Ethernet trace to make sure. A pair of GS/3s running software version 11000 (connected by a 56Kb line, though that shouldn't matter) just passed a 1064-byte IP packet without fragmenting (or if it was fragmented over the line, the receiver reasssembled it before sending it on the Ethernet). The older software, version 10000, did have a different problem with IP fragmentation. It didn't -cause- any packets to be fragmented. However, if the original sender had already fragmented an IP message, the GS/3 would only -transmit- the first fragment. They made us a patched version of the software (called 10019, I think) to evade this problem. I don't think the current 11000 release does anything wrong in this regard. Stuart Levy, slevy@uf.msc.umn.edu Minn. Supercomputer Center, 612 626 0211 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711091811.AA23668@uxc.cso.uiuc.edu] <1987110908110200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kline@uxc.cso.uiuc.EDU (Charley Kline) Newsgroups: comp.protocols.tcp-ip Subject: Re: Life after source quench Message-ID: <8711091811.AA23668@uxc.cso.uiuc.edu> Date: Mon, 9-Nov-87 13:11:02 EST Article-I.D.: uxc.8711091811.AA23668 Posted: Mon Nov 9 13:11:02 1987 Date-Received: Sun, 15-Nov-87 19:57:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Gosh Professor Mills, you guys all yelled at me so much when I mentioned that d.ncsa.uiuc.edu didn't respond to quenches that I thought I'd better do it right. Do I get an A on my project? As Ed pointed out, the method that our "Craykitten" uses in response to a source quench is simply to shackle all packets in the IP output queue destined for the originator of the quench (I mean the ip_dst of the packet returned in the quench) such that there is a delay of X milliseconds before each is transmitted. X is initially zero, and the current parameter is to increase it by 500 milliseconds for each quench received. If no quenches are received for 30 seconds, X is halved. An X lower than 500 causes the quench reaction to stop. This all happens in the IP module, and TCP is unaware of the quenches. I'm sure that the reason that the fuzzball is issuing quenches every thirty seconds is because if only one quench is sent, IP throttles back to one packet every 500 milliseconds (which should keep the fuzzball happy), but when the 30 second quench reaction stops, IP starts vomiting the packets full blast again, which causes another quench. I'm pleased that the quench mechanism creates such effective data rate communication between an IP module and IP gateways. I can't take credit for the method, it's an implementation of Postel's proposal. I only messed with the parameters. ----- Charley Kline University of Illinois Computing Services kline@uxc.cso.uiuc.edu kline@uiucvmd.bitnet {ihnp4,uunet,pur-ee,convex}!uiucuxc!kline ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711091827.AA12028@topaz.rutgers.edu] <1987110908270900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple subnets on one physical net Message-ID: <8711091827.AA12028@topaz.rutgers.edu> Date: Mon, 9-Nov-87 13:27:09 EST Article-I.D.: topaz.8711091827.AA12028 Posted: Mon Nov 9 13:27:09 1987 Date-Received: Tue, 17-Nov-87 05:49:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 It is important for the general health of an complex IP network to keep hosts that are not supposed to be functioning as routers (gateways) from forwarding packets at all. This more than anything else has caused more problems, e.g.: Host receives broadcast packet with wrong type broadcast IP address and tries to ARP for it, sending host into tight loop (Old Wollongong VMS TCP/IP). Host receives packet for some host other than itself, tries to send an ICMP error packet and generates bogus ARP field causing other hosts to think that it was the host that sent the packet (Ungerman Bass TCP). -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711091829.AA12089@topaz.rutgers.edu] <1987110908290300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Can I print on a terminal server port Message-ID: <8711091829.AA12089@topaz.rutgers.edu> Date: Mon, 9-Nov-87 13:29:03 EST Article-I.D.: topaz.8711091829.AA12089 Posted: Mon Nov 9 13:29:03 1987 Date-Received: Tue, 17-Nov-87 05:58:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Roy Marantz here at Rutgers is working on this for lpd. The printcap has a terminal server name/ TCP port number entry for these printers. There is currently still some bug that prevents this from working. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711091847.AA12787@topaz.rutgers.edu] <1987110908470700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Bridge Message-ID: <8711091847.AA12787@topaz.rutgers.edu> Date: Mon, 9-Nov-87 13:47:07 EST Article-I.D.: topaz.8711091847.AA12787 Posted: Mon Nov 9 13:47:07 1987 Date-Received: Sun, 15-Nov-87 17:47:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 OK, since you've never heard anybody malign Bridge, I'll volunteer. Bridge makes nice reliable boxes, but they don't always get the protocls right. Their terminal servers are classic examples. They don't answer pings, they botch the Telnet options, etc. _Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711091910.AA13941@topaz.rutgers.edu] <1987110909102800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Fetching host tables from the NIC Message-ID: <8711091910.AA13941@topaz.rutgers.edu> Date: Mon, 9-Nov-87 14:10:28 EST Article-I.D.: topaz.8711091910.AA13941 Posted: Mon Nov 9 14:10:28 1987 Date-Received: Tue, 17-Nov-87 05:59:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 You ought to use the domain system rather than host tables, but since you are on MILNET you can ftp or use the port 101 server to pull the NIC host table off BRL-AOS. It is available in the file HOSTS.TXT ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110909543000> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Mon 9 Nov 87 16:42:55-PST To: "Phil R. Karn" cc: tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM Subject: Re: Internet routing problems In-reply-to: Your message of 05 Nov 87 04:27:32 +0000. <1527@faline.bellcore.com> Date: Mon, 09 Nov 87 18:14:30 -0500 From: Mike Brescia Phil, I recommend that you get on the EGP-PEOPLE mailing list. Send request to 'egp-people-request@bbn.com'. Your problem first had a fix announced there a year ago February (that's 1986). I would have restricted this note to a private answer, but I want to suggest that anyone else reading TCP-IP and operating an EGP gateway get on the EGP-PEOPLE list also. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [691@devvax.JPL.NASA.GOV] <1987110911482000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: timg@devvax.JPL.NASA.GOV (Tim Graham) Newsgroups: comp.protocols.tcp-ip Subject: guaranteed datagram protocols Message-ID: <691@devvax.JPL.NASA.GOV> Date: Mon, 9-Nov-87 16:48:20 EST Article-I.D.: devvax.691 Posted: Mon Nov 9 16:48:20 1987 Date-Received: Wed, 11-Nov-87 19:46:58 EST Reply-To: timg@jpl-devvax.JPL.NASA.GOV (Tim Graham) Distribution: na Organization: Jet Propulsion Laboratory, Pasadena, CA. Lines: 21 Keywords: datagram I have a query concerning the existence of tested and reliable guaranteed datagram protocols. By this I mean protocols which would sit "above" the UDP protocol in the TCP/UDP/IP suite, but which would guarantee ordered and reliable delivery of messages. I suppose that such a protocol would have to do appropriate sequencing and retransmitting to accomplish this. The problem which motivates this request is a desire to maintain "many-to-one" connections while guaranteeing that any segments sent will be received at the remote end, and that they will be received in the order in which they were sent. Any information concerning products which even remotely resemble this description would be greatly appreciated. Thanks in advance for any information you may have. -- Tim Graham Jet Propulsion Laboratory/California Institute of Technology ----------------------------------------------------------------------------- 4800 Oak Grove Drive Pasadena, CA. 91109 MS: 301-260A (818) 354-1448 UUCP: ...cit-vax!elroy!jpl-devvax!timg ARPA: elroy!timg@jpl-devvax ----MESSAGE-END---- ----MESSAGE-BEGIN---- [871109225730.962725@MIT-Multics.ARPA] <1987110912570000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Kastenholz@MIT-MULTICS.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: ARP on FDDI Message-ID: <871109225730.962725@MIT-Multics.ARPA> Date: Mon, 9-Nov-87 17:57:00 EST Article-I.D.: MIT-Mult.871109225730.962725 Posted: Mon Nov 9 17:57:00 1987 Date-Received: Sun, 15-Nov-87 17:52:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Jim, There is a rather simplistic solution to the 16 vs 48 bit FDDI address problem - assign two physical hardware types to FDDI - one for 16 bit addresses and one for 48 bit addresses. This may violate some underlying deep philosophical intent of ARP, but it looks like it should work. Frank Kastenholz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711160844.AA12880@ucbvax.Berkeley.EDU] <1987110912573400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: pogran@CCQ.BBN.COM (Ken Pogran) Newsgroups: comp.protocols.tcp-ip Subject: ARPANET/Internet performance investigation Message-ID: <8711160844.AA12880@ucbvax.Berkeley.EDU> Date: Mon, 9-Nov-87 17:57:34 EST Article-I.D.: ucbvax.8711160844.AA12880 Posted: Mon Nov 9 17:57:34 1987 Date-Received: Tue, 17-Nov-87 05:54:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 BBN has been investigating recent ARPANET and Internet performance problems. Here's a brief report. The biggest single problem has been the performance of key LSI-11 gateways, especially the three "EGP Server" Gateways on the ARPANET located at BBN, Purdue, and ISI. These gateways are LSI-11/23s, and they are flat out of cycles. As the Internet has grown, they have been spending more and more of their time preparing EGP routing updates, at the expense of other activities, such as servicing their I/O queues. One result of this has been the buildup of long queues of messages for these gateways in the PSNs to which they are attached. Frequently, messages have remained on the queues for more than 30 seconds -- which causes the PSN to declare the gateway "tardy" and reset its interface to that gateway, thereby flushing the queue (returning "Incomplete Transmission" messages to the originators) and starting the process over again. The short-term fix for this problem is to replace the processors in these gateways with the faster LSI-11/73s. This was done at BBN last Friday, with excellent results. BRL and U-Maryland have generously offered the loan of 11/73 processors which will be installed in the ARPANET EGP servers at Purdue and ISI. With these faster processors installed, the Internet should be back to "normal" -- for another 2-6 months, given the current rate of growth. The long-term fix is the installation of Butterfly Gateways to replace the LSI-11s that are the DDN Mailbridge Gateways. This will enable us to retire the LSI-11 EGP servers. The Butterfly Mailbridges will provide significantly better performance. Deployment of the Butterfly Mailbridges in the DDN is expected in the April timeframe. Ken Pogran BBN Communications ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987110912573401> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Mon 9 Nov 87 15:23:23-PST Date: Mon, 9 Nov 87 17:57:34 EST From: Ken Pogran Subject: ARPANET/Internet performance investigation To: tcp-ip@sri-nic.arpa Cc: pogran@ccq.bbn.com BBN has been investigating recent ARPANET and Internet performance problems. Here's a brief report. The biggest single problem has been the performance of key LSI-11 gateways, especially the three "EGP Server" Gateways on the ARPANET located at BBN, Purdue, and ISI. These gateways are LSI-11/23s, and they are flat out of cycles. As the Internet has grown, they have been spending more and more of their time preparing EGP routing updates, at the expense of other activities, such as servicing their I/O queues. One result of this has been the buildup of long queues of messages for these gateways in the PSNs to which they are attached. Frequently, messages have remained on the queues for more than 30 seconds -- which causes the PSN to declare the gateway "tardy" and reset its interface to that gateway, thereby flushing the queue (returning "Incomplete Transmission" messages to the originators) and starting the process over again. The short-term fix for this problem is to replace the processors in these gateways with the faster LSI-11/73s. This was done at BBN last Friday, with excellent results. BRL and U-Maryland have generously offered the loan of 11/73 processors which will be installed in the ARPANET EGP servers at Purdue and ISI. With these faster processors installed, the Internet should be back to "normal" -- for another 2-6 months, given the current rate of growth. The long-term fix is the installation of Butterfly Gateways to replace the LSI-11s that are the DDN Mailbridge Gateways. This will enable us to retire the LSI-11 EGP servers. The Butterfly Mailbridges will provide significantly better performance. Deployment of the Butterfly Mailbridges in the DDN is expected in the April timeframe. Ken Pogran BBN Communications ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711092206.aa10304@Huey.UDEL.EDU] <1987110917065600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Life after source quench Message-ID: <8711092206.aa10304@Huey.UDEL.EDU> Date: Mon, 9-Nov-87 22:06:56 EST Article-I.D.: Huey.8711092206.aa10304 Posted: Mon Nov 9 22:06:56 1987 Date-Received: Sun, 15-Nov-87 20:37:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Ed, Thanks for the info; however, to fully evaluate the Cray response I would need to know the parameters of the algorithm: what is the delay, the increment and the weighting constant for the decrease? How long does it wait for decrease? In order to set these properaly, it would be helpful for the Cray to know something about the overall path, such as path delay, estimated flow rate, packet loss rate, etc. At least on countermotivation for effecting the quench policy at the IP level is that this information is hard to come by. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711092241.aa10552@Huey.UDEL.EDU] <1987110917412800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Life after source quench Message-ID: <8711092241.aa10552@Huey.UDEL.EDU> Date: Mon, 9-Nov-87 22:41:28 EST Article-I.D.: Huey.8711092241.aa10552 Posted: Mon Nov 9 22:41:28 1987 Date-Received: Sun, 15-Nov-87 20:46:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Charley, Gee, you didn't say how mungus the packet is - 65K give/take fragments? An incremental delay of 500 ms is probably okay for the 56-Kbps Backbone or ARPANET, but certainly not for the ARPANET/MILNET gateways. To do it right, you should know something more about the path, such as overall delay, estimated flow rates and loss rates. TCP of course could give that to you, assuming TCP were involved. I doubt UDP or raw IP would generate the observed horsepower; on the other hand, a Craycreature may well be needed to supply the watts for tomorrow's domain-name server turbines. If your suggested scenario is correct and the quench needs nick only one every thirty seconds or so, that would be real swell news. However, Hans-Werner Braun reports finding quench gushers for the UIUC Craykiller at other times, which suggests additional testing and observation may be in order. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711100623.AA19378@opal.berkeley.edu] <1987110920234300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dlw@OPAL.BERKELEY.EDU (David Wasley) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telephone Access Controllers (TACs) and SLIP... Message-ID: <8711100623.AA19378@opal.berkeley.edu> Date: Tue, 10-Nov-87 01:23:43 EST Article-I.D.: opal.8711100623.AA19378 Posted: Tue Nov 10 01:23:43 1987 Date-Received: Sun, 15-Nov-87 22:39:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 I have a very strong interest in such a thing. I envision it as presenting host addresses on a single subnet to the various ports. The protocol would be to "log in" to the system (validation and all that) and be given an IP address & mask for the duration of the session. After that, it is all IP until carrier drops. Is there a well defined, documented protocol for this initial dialogue? How would you deal with dynamic name/address mapping? I can see dynamic registry with a DNS, and timeout/de-registry. But what about the email relay that wants to deliver to me and must be told that I've just connected? (This is one reason I want real, secure validation.) If such a thing existed, I can see supporting a "rotary" of 64 ports (min) for general campus network access here. They should run up to 64Kb/s. The line protocol should be SDLC with a well defined IP encapsulation so my PC, uVax, MAC-II, or SUN can implement it. Etc. It should have logging of course... Maybe all this is obvious. Maybe there is one out there?? I haven't seen it. (Yeah, we could make one, but I'd rather see a standard product :-) David Wasley U C Berkeley ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111001291700> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Tue 10 Nov 87 08:28:15-PST To: Charles Hedrick cc: tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM Subject: Re: new Arpanet end to end protocol In-reply-to: Your message of Fri, 06 Nov 87 02:20:54 -0500. <8711060720.AA24392@athos.rutgers.edu> Date: Tue, 10 Nov 87 09:49:17 -0500 From: Andy Malis Charles, Your message is quite wrong (I know - I designed the new End-to-End). I would be interested in knowing (in private) who your "reliable source" is, so that such rumors can be source quenched. After the recent messages on the tcp-ip list, I'm sure we all realize how important source quenching is. The truth of the matter is: PSN 7.0 has two different End-to-End protocols (old EE and new EE). Either one or the other runs at any particular time, and the two cannot interoperate. The ARPANET is currently using PSN 7.0 with the old EE. It is the new EE that will be tested on Nov. 7, 14-15, and 18. The old EE protocol explicitly returned, across the PSN subnet, a separate RFNM packet for each message delivered to a destination host. This RFNM packet was then converted, in the source PSN, into the 1822 RFNM for that message and delivered to the source host. This had the result that, depending on traffic mixes, roughly about 45% to 50% of the packets going through the subnet were RFNMs. Since the PSN does so much per-packet processing, even for these RFNMs, the network was passing much less host traffic than otherwise might be possible. We fixed this in the new EE by making it an explicitly windowed protocol IN THE SUBNET. The destination PSNs have the ability to aggregate ACKs (the new EE internal equivalent to RFNMs) and send multiple ACKs for the same connection in windowed ACK (by using an INTERNAL message sequence number). In addition, these ACKs can now be piggybacked on data traffic, and many ACKs for different EE connections can be shipped together in the same subnet packet to a source PSN. The important thing to note is that when the destination PSN receives an ACK for a connection, it generates, and sends to the source host, a separate 1822 RFNM for EACH and EVERY message submitted by the host and being acknowledged by the ACK. There are no host-visible sequence numbers; the 1822 protocol stays the same as before. What may have confused you is the fact that we at BBN are, concurrent with the PSN 7.0 testing, trying to track down which ARPANET hosts might be affected by a known BSD 4.2 network software problem that may cause RFNMs to be lost in the host itself (I believe it is related to the size of the message received PREVIOUS to the RFNM). This bug has been fixed in BSD 4.3, and I have been told that Lars Poulsen of ACC (lars@acc.arpa) has a patch for BSD 4.2-derived host software. By the way, we have measured in our internal BBNNET (which has been running PSN 7.0 with the new EE only for over five months now) that only about 14% of the packets through the network only contain ACKs - the rest of the ACKs are being piggybacked on the data traffic. We are very pleased with this result. Also, most of our BBNNET hosts (around 125 C/70s, VAXEN, TOPS-20s, TACs, and others) use 1822, and they have had no problems with the new EE. Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111001532200> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by SRI-NIC.ARPA with TCP; Tue 10 Nov 87 08:19:36-PST To: orchard/bruc@scarecrow.waisman.wisc.edu cc: tcp-ip@sri-nic.ARPA Subject: re: TCP maximum segment size determination Date: Tue, 10 Nov 87 10:13:22 -0500 From: Craig Partridge Bruce, Last week I volunteered at the IETF meeting to write a proposal for just such an IP option. You should see it within a couple of weeks (seeing it implemented may take a while longer...) By the way, the scheme is sound even if the path changes if you treat the IP option and the TCP MSS values as distinct. I.e. in the TCP MSS you should advertise the maximum segment size you wish to accept and the remote end should keep this value and separately keep track of what IP reports. You would use the minimum of the two MSS's reported when sending. Then if you get an indication that the route has changed (such as an ICMP redirect), you can send the IP option again, and update the effective MSS (up or down). There's still the problem of packets following different paths -- this may have a solution but I'm still looking for something that doesn't feel like a kludge of a three way handshake. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]10-Nov-87.11:57:32.CERF] <1987111006570000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Telephone Access Controllers (TACs) and SLIP... Message-ID: <[A.ISI.EDU]10-Nov-87.11:57:32.CERF> Date: Tue, 10-Nov-87 11:57:00 EST Article-I.D.: <[A.ISI.EDU]10-Nov-87.11:57:32.CERF> Posted: Tue Nov 10 11:57:00 1987 Date-Received: Tue, 17-Nov-87 07:37:10 EST References: <8711100623.AA19378@opal.berkeley.edu> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 I would be a little nervous about dynamic name/address binding so that the host could receive calls (mail, file transfer, etc), but comfortable with originating calls - assuming, of course, that this meant you could not masquerade as an arbitrary host name by using SGMP and asking for messages for that host. Apart from security concerns (which may be present regardless of ability to receive calls as well as originating them), getting the Internet to handle dynamic name/address binding, avoiding spoofing and dealing with the potential for multiple name servers to be out of sync, causing confusion, seems quite an ambitious chore. Perhaps Mr. Wasley has thought this through and can offer his view of the architectural considerations? Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [283116.871110.JBVB@AI.AI.MIT.EDU] <1987111007372500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP maximum segment size determination Message-ID: <283116.871110.JBVB@AI.AI.MIT.EDU> Date: Tue, 10-Nov-87 12:37:25 EST Article-I.D.: AI.283116.871110.JBVB Posted: Tue Nov 10 12:37:25 1987 Date-Received: Tue, 17-Nov-87 07:37:38 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 The lower the performance of your network interface, the more trouble *any* fragmentation means to you. On PCs, we try to eliminate fragmentation by specifying a small MSS when routing via any gateway (subnets-are-local would be nice to do, but we haven't yet). The IP option you propose would help, but not until all gateways handled it properly. If gateway gurus saw their way clear to do so, they might help some fraction of the world by arranging that IP fragments aren't transmitted consecutively (if there is other traffic to handle) or by inserting a little time delay if the Ether or other non-serial media is idle. Presently, fragmenting an IP datagram is the best simple way I know to determine how close together a given hardware/software combination can send packets. If the gateway goes faster than the host can handle, suddenly it is time for a TCP retransmit... I can't say when/where I heard this, but I always thought that SATNET had an MTU of 128 bytes. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [328@idacrd.UUCP] <1987111008532100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mac@idacrd.UUCP (Bob McGwier) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Microport TCP recommendations Message-ID: <328@idacrd.UUCP> Date: Tue, 10-Nov-87 13:53:21 EST Article-I.D.: idacrd.328 Posted: Tue Nov 10 13:53:21 1987 Date-Received: Thu, 12-Nov-87 22:33:00 EST References: <141@ncc.UUCP> Distribution: comp Organization: idacrd, princeton, nj Lines: 11 in article <141@ncc.UUCP>, lyndon@ncc.UUCP (Lyndon Nerenberg) says: > Xref: idacrd comp.protocols.tcp-ip:1594 comp.dcom.lans:885 > Lyndon: I would have thought you knew that Phil's stuff has been ported to system V. Contact Bdale Garbee. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [283133.871110.JBVB@AI.AI.MIT.EDU] <1987111009442300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet/IP Testing/Monitoring Tools Message-ID: <283133.871110.JBVB@AI.AI.MIT.EDU> Date: Tue, 10-Nov-87 14:44:23 EST Article-I.D.: AI.283133.871110.JBVB Posted: Tue Nov 10 14:44:23 1987 Date-Received: Tue, 17-Nov-87 07:37:25 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 FTP Software sells a low-cost network monitor called LANWatch. This is derived from the MIT freeware program NETWATCH, with many features added. Our symbolic filters and detailed packet examination mode understand most IP protocols and formats, from IP and ICMP to TCP. We sell the package as software-only, you supply the PC and the interface. We provide enough source so users can extend the symbolic filters and packet displays to include protocols we don't support. We also provide source for the off-line analysis programs that process packets dumped to disk. We support a number of different PC network cards, and our performance depends on which card and how fast a machine you put it in. Even with a fast one in a fast AT, our packet capture ratio is unlikely to match that of a network monitor with special hardware. However, we feel that our cost makes up for a good deal in that department. The present release, 1.0, only has symbolic breakdowns for IP & relatives. LANWatch 1.1 will have a much better understanding of XNS, DECNet and 802.2/IP protocols, and it should be available next month. We don't have any traffic generation tools in the package yet. James B. VanBokkelen FTP Software Inc. P.O. Box 150 Kendall Sq. Branch P.O. Boston, MA 02142 (617) 868-4878 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1801@geac.UUCP] <1987111009565200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: daveb@geac.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: host down (was ..."layering violations") Message-ID: <1801@geac.UUCP> Date: Tue, 10-Nov-87 14:56:52 EST Article-I.D.: geac.1801 Posted: Tue Nov 10 14:56:52 1987 Date-Received: Thu, 12-Nov-87 00:36:07 EST References: <12347435144.54.PADLIPSKY@A.ISI.EDU> <8711030915.AA00844@gumby.wisc.edu> Reply-To: daveb@geac.UUCP (Dave Collier-Brown) Organization: The little blue rock next to that twinkly star. Lines: 33 Summary: Two cases come to mind... In article <8711030915.AA00844@gumby.wisc.edu> Mitchell Tasman (g-tasman@GUMBY.WISC.EDU) writes: [discussion of the behavior on "host down"]... a daemon | should immediately close the associated TCP connection. | | With an 1822 Distant Host connection to DDN, this may be a fairly | reasonable approach. However, a typical DDN connection of late has been | X.25 or HDH. Here, "host down" may have a more transitory meaning: simply | that there was noise on the host access line. The remote host may well | reappear with all TCP connections intact. My experience with short-haul or secondary nets has been that there are two distinct kinds of events which TCP might regard as a "host down". One is a real host-down and the other is the aforementioned QRN (noise) on the line. The latter is particularly annoying on what is supposed to be a low-error medium... Methinks that TCP is being a bit pessimistic: IP is not supposed to be error-free, and I suggest that TCP may be misinterpreting the errors which a short-haul network seems to love to produce as a more serious and long-term event than it really should. Could map or someone comment? --dave (on the other hand, i could be biting my foot) c-b -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1198@itm.UUCP] <1987111010305200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: danny@itm.UUCP (Danny) Newsgroups: comp.protocols.tcp-ip Subject: Bridge Terminal Server Problems Message-ID: <1198@itm.UUCP> Date: Tue, 10-Nov-87 15:30:52 EST Article-I.D.: itm.1198 Posted: Tue Nov 10 15:30:52 1987 Date-Received: Fri, 13-Nov-87 06:36:24 EST Reply-To: danny@itm.UUCP (Danny) Distribution: na Organization: In Touch Ministries, Atlanta, GA Lines: 33 Summary: HELP! Hear me O ye wise ones! Incline thine ears, that ye may understand, and save thy humble servant! I've a problem (no it's not my English). We have a Bridge Communications Server (CS100) which is connected to our ethernet. Our computer is a Celerity C1230 running BSD4.3. Now, the Bridge box assigns a IP address to each port, e.g.: port 0 is "77.0.0.100", and the Celerity is "77.0.0.2". We just want to hang printers off of the Bridge box; so each printer has an address and host name of its own. Now, the problem. I can connect to (for example) necc using telnet. Everything's fine. What I type on the terminal, is printed on the Nec (5515). We also run MDQS from BRL. I wrote a short routine to open a socket, connect it to a host (necc), and dup2 it as stdout (which is what an MDQS server requires). When I submit a request to necc, the connection succeeds! Then, usually, the server immediatly dies with a SIGPIPE. That's kinda OK. FIRST, should the connection succeed? I don't think so. Then, after a few rounds of the server restarting itself, it will run to completion! Where does the data go? I thought that TCP garentees delivery, but to where you wanted it to go. So, why is the Bridge box accepting two connections to the same serial-port/address? Why does the second then mysteriously fail? Where does the data go when it succeeds? HELP! Danny -- Daniel S. Cox (seismo!gatech!itm!danny) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711102055.AA10425@zaphod.ncsa.uiuc.edu] <1987111010553200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: timk@ncsa.uiuc.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: NCSA Telnet source code -- free Message-ID: <8711102055.AA10425@zaphod.ncsa.uiuc.edu> Date: Tue, 10-Nov-87 15:55:32 EST Article-I.D.: zaphod.8711102055.AA10425 Posted: Tue Nov 10 15:55:32 1987 Date-Received: Thu, 19-Nov-87 06:35:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 174 NCSA Telnet source code is now available. The National Center for Supercomputing Applications announces our source code release of NCSA Telnet version 2.1. This message includes: Source Code pricing information Some changes from 2.0 to 2.1 (you may not need to upgrade) Mailing list for telnet related questions/bugs (telnet@ncsa.uiuc.edu) User/Developer forum at TCP/IP conference in December Source Code There are a variety of disk options if you don't want to spend all night transferring files (even compressed ones). See the price list at the end of this note for details. Note that the Anonymous FTP directories are available on one convenient tape and it contains all of the files from the other disks. Compilers: PC - Lattice C 3.1, Microsoft C 4.0 (MSC not debugged). Mac - Aztec C, there will be an MPW version soon. All of these files are available via anonymous FTP on NSFnet and ARPANET from host 128.174.20.50 (ftp.ncsa.uiuc.edu). Enhancements in version 2.1 For the PC, we have added a driver for the MICOM NI5210 (not the NI5010) board, and a driver for the IBM (Ungermann-Bass) NIC Ethernet board. You use the same configuration files for each board, but select a different .EXE file to run. For the Macintosh, we include support for Apple's new EtherTalk driver directly for use with the new EtherTalk Ethernet board. We also support the Kinetics' EtherSC and EtherPort SE products with their EtherTalk driver. Unless you have these hardware needs, you may not need to upgrade from 2.0 to 2.1. You should upgrade from anything pre-2.0 to version 2.1. Mailing list and conference meeting We are sponsoring a mailing list for people interested in keeping up with the NCSA Telnet distribution and the various groups taking part in future development. The address is telnet@ncsa.uiuc.edu. Send a message to telnet-request@ncsa.uiuc.edu to get on the list. There will be a meeting at Advanced Computing Environment's TCP/IP conference in December. We will discuss user problems and the status of various development projects. This will be a good time to ask technical questions. Thanks for your interest, some details follow the signature, Tim Krauskopf National Center for Supercomputing Applications (NCSA) University of Illinois timk@ncsa.uiuc.edu (ARPA) timk%newton@uxc.cso.uiuc.edu (alternate) 14013@ncsavmsa (BITNET) -------------------------------------------------------------------- Fact Sheet ---------- National Center for Supercomputing Applications presents: NCSA Telnet for the PC, version 2.1 NCSA Telnet for the Macintosh, version 2.1 These programs are copyrighted, but distributed with no license fee. Source code is available. Features included in version 2.1 of NCSA Telnet: ----------------------------------------------- DARPA standard telnet Built-in standard FTP server for file transfer VT102 emulation in multiple, simultaneous sessions Class A,B and C addressing with standard subnetting Tektronix 4014 graphics emulation Scrollback for each session Each session in a different window (Macintosh) Supports Croft gateway - KIP (Macintosh) Support for EtherTalk (Macintosh) Capture text to a file (PC) Full color support (PC) Support for 3COM, MICOM and IBM (Ungermann-Bass) boards (PC) How to obtain: ------------- 1) From a friend The disk, documentation and files may be copied freely and distributed in binary form, unmodified, with copyright notices intact. This distribution is free and no copies may be sold for profit. 2) Anonymous FTP from ftp.ncsa.uiuc.edu (128.174.20.50) You may want to ftp the README file to determine which files to transfer to your home machine. For the PC version, you have your choice of tar files which are individual for each type of Ethernet board. For each tar file, there is also a compressed tar file with the same contents. The documentation file goes with any type of Ethernet. After the files are extracted from the tar file, some transfer method (e.g. kermit, NCSA Telnet) should be used to download the files to the PC. The documentation is in line printer format. Remember to download .EXE files in binary mode. The Macintosh version consists of several files encoded with BinHex 4.0, Pack-It or Stuff-It. You may want to consult the README file to determine which files to transfer. Download them with a binary transfer method (kermit, NCSA Telnet) and extract the individual files. The documentation is in Microsoft Word 3.0 format. 3) Diskette On-disk copies, with a printed manual are available for a small fee, which covers materials, handling and postage. Orders can only be accepted if accompanied by a check made out to the University of Illinois. Send to: NCSA Telnet orders (specify PC or Macintosh and product) 152 Computing Applications Building 605 E. Springfield Ave. Champaign, IL 61820 Here is the price list: NCSA Telnet for the PC (2.1,2.1M,2.1IBM) $20.00 (three 360K disks, PC user/installation guide) NCSA Telnet for the Macintosh (2.1,2.1E) $20.00 (two 400K disks, Macintosh user/installation guide) NCSA Telnet for the PC source $20.00 (two 1.2M disks, Developer's guide) NCSA Telnet for the Macintosh source $20.00 (one 800K disk, Developer's guide) Anonymous FTP source reel tape $30.00 (recent contents of our anonymous ftp directory, 1600BPI 9track Sun-BSD tar format, Developer's guide) Anonymous FTP source cartridge tape $50.00 (recent contents of our anonymous ftp directory, 1/4 inch cartridge tape Sun tar format, Developer's guide) Hardware required: ----------------- PC: IBM PC,XT, AT or compatible. 3COM 3C501 Etherlink board. or IBM RT PC Baseband adapter. or Ungermann-Bass PC-NIC board. or MICOM NI5210 Ethernet board. Mac: Macintosh Plus, SE or Macintosh II. FastPath from Kinetics Inc. Walnut Creek, CA (415) 947-0998 and Kinetics gateway software or Stanford KIP (Croft) gateway software. or EtherSC or EtherportSE and EtherTalk software from Kinetics. or Apple EtherTalk board and software for the Macintosh II. Mailing List: ------------ Mail to telnet-request@ncsa.uiuc.edu to be added to the list of recipients. To post messages to the list, mail to telnet@ncsa.uiuc.edu. If your mailer cannot resolve ncsa.uiuc.edu (128.174.20.42), route mail through uxc.cso.uiuc.edu, also known as uiucuxc.arpa. Other questions: --------------- mail to telbug@ncsa.uiuc.edu (alternate: telbug%ncsa@uxc.cso.uiuc.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711102203.AA24154@tut.cis.ohio-state.edu] <1987111011552300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Welch%osu-20@OHIO-STATE.ARPA (Arun) Newsgroups: comp.protocols.tcp-ip Subject: Telnet options Message-ID: <8711102203.AA24154@tut.cis.ohio-state.edu> Date: Tue, 10-Nov-87 16:55:23 EST Article-I.D.: tut.8711102203.AA24154 Posted: Tue Nov 10 16:55:23 1987 Date-Received: Wed, 18-Nov-87 02:19:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Could someone tell me what telnet options 32 and 94 are, and which RFC's are associated with them? We've got a host (a dec-20 running tops) which is returning them, causing my workstatio (a xerox 1186) to lose... I couldn't find them anywhere in Assigned Numbers or in the DDN Handbook. ...arun ---------------------------------------------------------------------------- Arun Welch Systems Programmer, Lab for AI Research, Ohio State University. welch@ohio-state.{CSNET,ARPA} ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711102301.AA27622@beno.CSS.GOV] <1987111013012800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telephone Access Controllers (TACs) and SLIP... Message-ID: <8711102301.AA27622@beno.CSS.GOV> Date: Tue, 10-Nov-87 18:01:28 EST Article-I.D.: beno.8711102301.AA27622 Posted: Tue Nov 10 18:01:28 1987 Date-Received: Wed, 18-Nov-87 00:57:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 No, what pople REALLY want is a SLIP card on your gateway box so that they can connect a network via SLIP to the local ethernet. We have 6 such connections beating the hell out of a vax 780. ---rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4652@amd.AMD.COM] <1987111014461400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nguyen@amd.AMD.COM (Quinn Nguyen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet versions Message-ID: <4652@amd.AMD.COM> Date: Tue, 10-Nov-87 19:46:14 EST Article-I.D.: amd.4652 Posted: Tue Nov 10 19:46:14 1987 Date-Received: Fri, 13-Nov-87 06:15:18 EST References: <4800@elroy.Jpl.Nasa.Gov> Lines: 25 Keywords: info? Summary: Ver. 1 vs Ver. 2 and 802.3 In article <4800@elroy.Jpl.Nasa.Gov>, david@elroy.Jpl.Nasa.Gov (David Robinson) writes: > As most people know their are a couple ethernet standards, Version 1, > Version 2 and IEEE 803.2. When one installs a new ethernet board > ... > The question: What is the difference between the versions and what > effect is their on the physical wire to run two different types > of transeivers? I have heard people say that it is best to have all > the same type but no "real" evidence to base that comment on. > Ethernet version 2 and ANSI/IEEE 802.3 (10BASE5) signals are physically the same. Version 1 and 2 signals are the same in the coax. The main differences are on the Drop cable: - SQE (Signal Quality Error) generation after a packet transmission required for version 2 and 802.3 but not for version 1. - Half-step idle signal (differentially 0) with transformer isolation required for version 2 and 802.3 but not for version 1. If a MAU (transceiver) does not generate SQE and only accepts, generates full-step signals (Ver. 1), it may have problem connecting to a version 2 DTE or vice versa. Other issues are device to device line static isolation, ground, etc. which are not relevant to transceiver connection... in term of functionality. Hope this may help. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [QVYYb5y00UoJytM46V@andrew.cmu.edu] <1987111017585800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: Re: details on misbehaving IP implementations Message-ID: Date: Tue, 10-Nov-87 22:58:58 EST Article-I.D.: andrew.QVYYb5y00UoJytM46V Posted: Tue Nov 10 22:58:58 1987 Date-Received: Fri, 13-Nov-87 06:05:08 EST References: <[G.BBN.COM].5-Nov-87.09:58:35.CLYNN> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Phil's 2 and 3 (returning port unreachable), like his 4 (protocol unreachable) may not be bugs due to unclear specs, but are certainly not a good idea. A future spec for hosts (similar to rfc 1009 for gateways) being written by a group in the IETF will probably specifiy that ICMP error messages should not be sent due to IP broadcasts. ICMP echo requests may not be prohibited however, since they are not error messages. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- [283529.871110.PAP4@AI.AI.MIT.EDU] <1987111018521100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP maximum segment size determination Message-ID: <283529.871110.PAP4@AI.AI.MIT.EDU> Date: Tue, 10-Nov-87 23:52:11 EST Article-I.D.: AI.283529.871110.PAP4 Posted: Tue Nov 10 23:52:11 1987 Date-Received: Wed, 18-Nov-87 03:58:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 My apologies if someone has already thought of this, but mail to my site is being delayed by up to 5 days, and seems to arrive in random order. But, here goes anyway: Date: Thu, 05 Nov 87 21:31:54 CST From: Bruce Orchard Subject: TCP maximum segment size determination [ ... ] large value. Each node that transmitted the packet would compare the value given in the option to the maximum transmission unit of the outgoing network. If the network value were less, the value in the option would be reduced to the network value. [ ... ] One limitation of this proposal is that all packets of a TCP connection do not necessarily pass through the same networks. Actually, given the way the networks are connected, all packets usually go through the same networks. Also, if one packet takes a different route from an earlier packet, the second route could be on the same kind of network (for example, two parallel Ethernets). Regardless, the consequence of a poor choice is reduced throughput, not failure. What about the required overhead for gateways and routers to have to further inspect each packet? It could be optimized so that only TCP packets are inspected, but still, that would seem to add to the burden of possibly compute-bound gateways... P.S. Is the MTU of SATNET really 256 bytes, as given in IEN 192? Could be worse, could be the 128 byte MTU of most X.75 implementations... -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111019445800> Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 10 Nov 87 21:43:48-PST Date: Wed, 11 Nov 87 00:44:58 EST From: "Philip A. Prindeville" Subject: IP encapsulation over ARCnet To: tcp-ip@SRI-NIC.ARPA cc: pcip@LOUIE.UDEL.EDU Message-ID: <283564.871111.PAP4@AI.AI.MIT.EDU> I'm currently looking into the problem of a standard for IP over ARCnet. Some of the problems are trivial, such as mapping local IP addresses to 8-bit node numbers; others are more involved: ARCNet has an MTU of 508 bytes, and does not like packets between 253 and 256 bytes. Would all persons interested in such a standard or willing to lend their expertise please contact me. Sorry to bother everyone else, but I thought the Subject: was self-explanatory... Thanks, -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111019463300> Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 10 Nov 87 21:45:26-PST Date: Wed, 11 Nov 87 00:46:33 EST From: "Philip A. Prindeville" Subject: IP encapsulation over ARCnet To: tcp-ip@SRI-NIC.ARPA cc: pcip@LOUIE.UDEL.EDU Message-ID: <283565.871111.PAP4@AI.AI.MIT.EDU> I'm currently looking into the problem of a standard for IP over ARCnet. Some of the problems are trivial, such as mapping local IP addresses to 8-bit node numbers; others are more involved: ARCNet has an MTU of 508 bytes, and does not like packets between 253 and 256 bytes. Would all persons interested in such a standard or willing to lend their expertise please contact me. Sorry to bother everyone else, but I thought the Subject: was self-explanatory... Thanks, -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711162320.AA26698@ucbvax.Berkeley.EDU] <1987111104192600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: COINS@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: QUESTION Message-ID: <8711162320.AA26698@ucbvax.Berkeley.EDU> Date: Wed, 11-Nov-87 09:19:26 EST Article-I.D.: ucbvax.8711162320.AA26698 Posted: Wed Nov 11 09:19:26 1987 Date-Received: Thu, 19-Nov-87 00:03:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 ANYONE (I'M NOT PROUD) I'M RUNNING PWB ON A PDP1170. DOES ANYONE HAVE DET UP ON ANY VERSION OF UNIX? IF SO PLEASE DROP ME A NOTE. THKS. RON SMITH ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7080001@nucsrl.UUCP] <1987111104524500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ernie@nucsrl.UUCP (Ernest Woodward) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet routing problems Message-ID: <7080001@nucsrl.UUCP> Date: Wed, 11-Nov-87 09:52:45 EST Article-I.D.: nucsrl.7080001 Posted: Wed Nov 11 09:52:45 1987 Date-Received: Sun, 15-Nov-87 16:32:39 EST References: <1527@faline.bellcore.com> Organization: Northwestern U, Evanston IL, USA Lines: 36 > / nucsrl:comp.protocols.tcp-ip / karn@faline.bellcore.com (Phil R. Karn) > / 10:27 pm Nov 4, 1987 / > > Lately I've noticed some rather persistent routing connectivity problems > in the Internet. Many destinations fail to respond to packets sent from > hosts on bellcore-net (128.96) but are shown to be up when I initiate > connections from ipswitch. A given host can be unresponsive for days. > ... > I suspect the problem is related to the inability of many gateways to > handle ever-larger EGP updates. ... > > I increased the size of > MAXPACKETSIZE in defs.h from 1006 to 2048 and recompiled. The problem > has not recurred. I suspect that there are many other gateways out there > with the same problem; what can we do to get them fixed? > > Phil ---------- I have had routing problems for the last two weeks and failed to understand why my egp neighbors could not assist me in routing. I believe that the above information on my EGP implementation may be the problem. I am also trying to implement gated, and it may be important to check that it also uses an appropriate MAXPACKETSIZE. I am still testing routing daemons to determine if the MAXPACKETSIZE was the root of all my problems over the last two weeks. The moral of the story is that I would like to see information like that presented by Phil distributed in the same fashion as the updates on the SRI host tables. All ARPANET host administrators might need this information and I am not sure that all of the administrators have access to USENET or have registration on the comp.protocols.tcp-ip mailing lists. Or, those on the mailing lists/USENET might not get as lucky as I and notice this important information amongst several other articles. Ernie Woodward Northwestern University Academic Computing and Network Services ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711111510.AA14479@topaz.rutgers.edu] <1987111105101500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telephone Access Controllers (TACs) and SLIP... Message-ID: <8711111510.AA14479@topaz.rutgers.edu> Date: Wed, 11-Nov-87 10:10:15 EST Article-I.D.: topaz.8711111510.AA14479 Posted: Wed Nov 11 10:10:15 1987 Date-Received: Thu, 19-Nov-87 00:41:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 1 Of course, we want one, but then you knew that. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [109@abvax.UUCP] <1987111107160700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wrk@abvax.UUCP (William R. King) Newsgroups: comp.protocols.tcp-ip Subject: reverse arp implementation question Message-ID: <109@abvax.UUCP> Date: Wed, 11-Nov-87 12:16:07 EST Article-I.D.: abvax.109 Posted: Wed Nov 11 12:16:07 1987 Date-Received: Sun, 15-Nov-87 16:16:48 EST Organization: Allen-Bradley Company, Inc; Industrial Computer Division, Highland Heights, OH Lines: 14 Keywords: RARP RFC-903 In RFC 903 (Reverse Arp Protocol) the statement is made that if a reverse arp packet is received with a opcode of either 1 or 2 (arp request, arp reply) that this packet can be passed on to the normal arp code for processing. My question is, when the normal arp code processes this request and decides that a reply is necessary, does the data link layer protocol field contain the value for ARP or RARP? Or for that matter, does it matter? Thanks. Bill King Allen-Bradley Company, Inc !{decvax,pyramid,mandrill}!abvax!wrk ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6200002@hpindda.HP.COM] <1987111107374700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rohit@hpindda.HP.COM (Rohit Aggarwal) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet/IP Testing/Monitoring Tools Message-ID: <6200002@hpindda.HP.COM> Date: Wed, 11-Nov-87 12:37:47 EST Article-I.D.: hpindda.6200002 Posted: Wed Nov 11 12:37:47 1987 Date-Received: Sat, 14-Nov-87 15:33:04 EST References: <8711060026.AA03844@ACC-SB-UNIX.ARPA> Organization: Hewlett Packard, Cupertino Lines: 6 Hello Hewlett Packard and Excelan (San Jose) make Lan Analyzers. Both will do the job you have described. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [283853.871111.JBVB@AI.AI.MIT.EDU] <1987111107575000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP-IP in the Public Domain? Message-ID: <283853.871111.JBVB@AI.AI.MIT.EDU> Date: Wed, 11-Nov-87 12:57:50 EST Article-I.D.: AI.283853.871111.JBVB Posted: Wed Nov 11 12:57:50 1987 Date-Received: Thu, 19-Nov-87 05:36:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 The specifications are all public domain. There are implementations for a number of different machines and operating systems that are P/D. I don't know of anyone who is actually running IP on Arcnet, but I know someone who is trying to write a driver for one of the P/D IBM PC packages. He is pap4@ai.ai.mit.edu (Philip Prindeville). You can get the specs, and a list which includes almost all the P/D code and most commercial products, over the ARPAnet from the machine SRI-NIC.ARPA. Use FTP, login as "anonymous", the specifications are in RFC: and the Vendor's Guide is in NETINFO:. If you don't have ARPAnet access, the documents can be ordered on paper from SRI in Menlo Park, CA, or the Defense Technical Information Center in ?Alexandria? VA. For someone who doesn't know much about TCP/IP, get the "DDN Protocol Handbook", which costs a little over $100 (but is 6 - 8 inches high). Will someone who has the whole address and phone number handy post it? jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711111514.aa10891@Huey.UDEL.EDU] <1987111110144100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Slang Glossary Message-ID: <8711111514.aa10891@Huey.UDEL.EDU> Date: Wed, 11-Nov-87 15:14:41 EST Article-I.D.: Huey.8711111514.aa10891 Posted: Wed Nov 11 15:14:41 1987 Date-Received: Thu, 19-Nov-87 19:38:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 James, Gong (n). Medieval term for privvy, or what pased for them in that era. Today used whimsically to describe the aftermath of a bogon attack. Think of our community as the Galapagos of the English language. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [128@umn-d-ub.D.UMN.EDU] <1987111110390700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: fsimmons@umn-d-ub.D.UMN.EDU (Frank Simmons) Newsgroups: comp.protocols.tcp-ip Subject: CMU-TEK TCP/IP Message-ID: <128@umn-d-ub.D.UMN.EDU> Date: Wed, 11-Nov-87 15:39:07 EST Article-I.D.: umn-d-ub.128 Posted: Wed Nov 11 15:39:07 1987 Date-Received: Sat, 14-Nov-87 02:32:32 EST Organization: U. of Minnesota-Duluth, Computer Center Lines: 2 Keywords: TCP/IP DOes anyone have any experience with this product on a Micro-vax II? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711112236.AA08450@ucbvax.Berkeley.EDU] <1987111113030300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: EGP instability Message-ID: <8711112236.AA08450@ucbvax.Berkeley.EDU> Date: Wed, 11-Nov-87 18:03:03 EST Article-I.D.: ucbvax.8711112236.AA08450 Posted: Wed Nov 11 18:03:03 1987 Date-Received: Sat, 14-Nov-87 04:07:09 EST References: <12348508863.13.SATZ@MATHOM.CISCO.COM> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Is anyone else having trouble maintaining their peer relationships with the core? We are seeing excessive problems with high packet loss and eventually being dropped. Greg, There is an arpanet/internet 'event' happening which shows up as long queues in both directions between the PSNs and the core gateways. Also, the psn-gateway connection is broken frequently which causes all the queued packets to be discarded. Does your gateway on the arpanet get clogged also? One change that may have affected the system is the introduction of fragmented NR messages (EGP updates), which now take 2 arpanet messages each longer than 128 bytes; the fragments are about 1000 bytes and 200 bytes, and growing. Some facets of the problem that are being explored are the differences between the arpanet PSN software release 7 and the old release 6, speeding up the processors in the core systems (upgrade lsi-11/23 to /73), and checking the timing on the EGP implementations. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21726@ucbvax.BERKELEY.EDU] <1987111115592300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: spp@zion.Berkeley.EDU (Steve Pope) Newsgroups: comp.protocols.tcp-ip Subject: Reference to SLIP Message-ID: <21726@ucbvax.BERKELEY.EDU> Date: Wed, 11-Nov-87 20:59:23 EST Article-I.D.: ucbvax.21726 Posted: Wed Nov 11 20:59:23 1987 Date-Received: Sat, 14-Nov-87 04:30:48 EST Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: spp@zion (Steve Pope) Organization: Experimental Computing Facility, U.C. Berkeley Lines: 10 A while ago I put out a query asking for references to SLIP. There is a "SLIP" defined in RFC914, but I'm pretty sure this does not have anything to do with the SLIP protocol people are actually using. I've found several implementations, but no references, good descriptions, or claims as to origin. Can anybody help me on this one?? thanks much! steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711120215.AA02549@gyre.umd.edu] <1987111116152500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@GYRE.UMD.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP maximum segment size determination Message-ID: <8711120215.AA02549@gyre.umd.edu> Date: Wed, 11-Nov-87 21:15:25 EST Article-I.D.: gyre.8711120215.AA02549 Posted: Wed Nov 11 21:15:25 1987 Date-Received: Thu, 19-Nov-87 06:32:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 There is a good standard argument against setting the MSS via an IP option, and that is that the route the SYN packet takes is not necessarily the same as the route that other packets will take. (In practise, I think we see a fair number of routes that, diagrammatically, look like this: net1 /------>f1------------>f2-----\ | v X Y ^ | \-------g1<------------g2<----/ net2 where the return path is consistently different from the originating path. And of course, since the Internet does not rely on virtual circuits, it can reroute dynamically, invalidating MSSes on the fly.) 4.3BSD sets the MSS to 576 (which becomes 536 data bytes) when crossing a gateway. This is not necessarily ideal but is the official recommended practise. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711120631.AA05706@mimsy.umd.edu] <1987111120310700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@MIMSY.UMD.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: milarpa performance Message-ID: <8711120631.AA05706@mimsy.umd.edu> Date: Thu, 12-Nov-87 01:31:07 EST Article-I.D.: mimsy.8711120631.AA05706 Posted: Thu Nov 12 01:31:07 1987 Date-Received: Thu, 19-Nov-87 06:37:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 At around 0121 EST 12 Nov 1987 (i.e., this morning) the arpa-milnet gateway performance went from seriously awful to about 1/3 decent. Pinging sirius.caltech.edu (picked because we happened to be sending mail to them at the time) before and after produced a 92% packet loss with an average delay of 20 seconds before, and 67% packet loss with an average round trip delay of 2.88 seconds. What happened? Can we expect further improvements? Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [871112-071511-8766@Xerox] <1987111205144100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Hopper.XRCC-NS@XEROX.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: FTP for VMS from PSC Message-ID: <871112-071511-8766@Xerox> Date: Thu, 12-Nov-87 10:14:41 EST Article-I.D.: Xerox.871112-071511-8766 Posted: Thu Nov 12 10:14:41 1987 Date-Received: Thu, 19-Nov-87 06:43:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Hopper.XRCC-NS@Xerox.COM Organization: The ARPA Internet Lines: 8 Does anyone out there have experience with the Process Software Corporation's implementation of FTP in VMS? We need to set up a system to allow transfer of files from a VMS VAX to an ISI 68020 bsd UNIX system and am trying to find a cost effective solution, PSC's price list for a single VMS license is $1995 ( updates $595). Mike Hopper...............Hopper.XRCC-NS@XEROX.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [353@vilya.UUCP] <1987111205322200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rhk@vilya.UUCP Newsgroups: comp.protocols.tcp-ip Subject: smtp on Symbolics lisp machines Message-ID: <353@vilya.UUCP> Date: Thu, 12-Nov-87 10:32:22 EST Article-I.D.: vilya.353 Posted: Thu Nov 12 10:32:22 1987 Date-Received: Sat, 14-Nov-87 13:35:29 EST Organization: AT&T Bell Labs, Parsippany Lines: 21 Keywords: tcp smtp symbolics Does anyone have any expierence running tcp on Symbolics 3640's and 3675's ? We've installed an ethernet in our building and are using tcp to transfer files from unix (Wollygong tcp on a 3b2-400) to the Symbolics. We also have a AT&T 6300 using tcp from FTP Software. The problem is that while ftp works fine we can't get smtp to work. It seems that the Symbolics doesn't follow the format of smtp and usr a CR NL at the end of a line. We added a Sun 2 as a reference machine to clear up finger pointing at Wollygong. With this group of machines smtp works fine between the Sun, the 3b2, and the pc. To add to the confusion the smtp on the pc works to the Symbolics as well as to the others? Any thoughts would be appreciated. rich kensicki {attunix,ihnp4}!vilya!rhk 201-299-3005 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12350057841.43.PADLIPSKY@A.ISI.EDU] <1987111207335400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: host down (was ..."layering violations") Message-ID: <12350057841.43.PADLIPSKY@A.ISI.EDU> Date: Thu, 12-Nov-87 12:33:54 EST Article-I.D.: A.12350057841.43.PADLIPSKY Posted: Thu Nov 12 12:33:54 1987 Date-Received: Thu, 19-Nov-87 06:46:50 EST References: <1801@geac.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Since you asked.... "TCP", per se (or "TCP The Protocol"), doesn't take an explicit stand on when to give up that I recall. I emphatically agree with you (and Phil Karn, who started the subtopic off, and Mitchell Tasman, who pointed out that there are extra pitfalls in the X.25 environment [which I was not, repeat not, addressing in my first msg on the subtopic]) that it's contrary to the robustness goal of TCP to give up too easily. I still would hope that implementers to whom that view is a revelation don't swing too far the other way and keep "obviously" shot connections around needlessly, since in some contexts the storage shouldn't be wasted and in other contexts (perhaps even in all contexts) there's a waste of transmissions to get SNs back in synchrony. The call, however forlorn, is just to "do it right"--and when you get right down to it, the liabilities of taking too optimistic a view aren't all that severe... except, of course, if you're wasting transmissions for "liveness" checks, or needlesssly sending some latter-day analogue of the old NCP RST, or being charged by some comm subnet for the apparently open connection, or.... Oops, guess I still feel you oughta be prudent. Well, that's probably more than enough on the subtopic for/from me, so: cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111208300000> Mail-From: STJOHNS created at 12-Nov-87 16:31:14 Date: 12 Nov 1987 16:30-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: TACs and SLIP... From: STJOHNS@SRI-NIC.ARPA To: BILLW@MATHOM.CISCO.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]Thu, 12 Nov 87 16:30:20 PST.STJOHNS> In-Reply-To: <12350105889.11.BILLW@MATHOM.CISCO.COM> For a terminal server plugged into a class A c30 net, use the 3rd octet of the IP address to differentiate the SLIP ports. I.e. transparent gateways or port expander model. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [479@ucdavis.ucdavis.edu] <1987111208490900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ccruss@deneb.ucdavis.edu (0059;0000000000;230;9999;98;) Newsgroups: comp.protocols.tcp-ip Subject: Institution-wide whois Message-ID: <479@ucdavis.ucdavis.edu> Date: Thu, 12-Nov-87 13:49:09 EST Article-I.D.: ucdavis.479 Posted: Thu Nov 12 13:49:09 1987 Date-Received: Sat, 14-Nov-87 20:52:08 EST Sender: uucp@ucdavis.ucdavis.edu Reply-To: rdhobby@ucdavis.edu (Russ Hobby) Organization: University of California, Davis Lines: 119 As promised, here is the the list of organizations that have indicated that they have a central whois server and database. ---------------------------------------- SRI-NIC This is the original whois database for the DDN network and has grown over the years to be the central source of information for all of Internet. The database contains information on most of the networks and many of the people associated with the Internet world. SRI-NIC.ARPA is the default host for many whois programs. Sending a request with a target of "help" will return a help page. Whois at SRI-NIC is also available via electronic mail. Whois usage whois help Usage from electronic mail Send mail to service@sri-nic.arpa Enter "whois" and the target name on the "Subject:" line. The result will be sent via return email, assuming the "From:" line on the original message is a valid address. Example: To: service@sri-nic.arpa From: user@host.campus.edu Subject: whois help ---------------------------------------- CSNET and the NNSC (NSF Network Service Center) This database contains information on sites and people associated with the above networks. A help page is returned by specifying "help" as the target. Whois usage whois -h sh.cs.net help ---------------------------------------- STANFORD UNIVERSITY The Stanford whois database contains information for the 30,000 students and faculty associated with the Stanford campus. Help is not available. Multiple matches to a target returns a list of matches. Further information on a single person can be obtained by specifying the unique identifier returned by the list. Whois usage whois -h stanford.edu ________________________________________ UNIVERSITY OF CALIFORNIA, DAVIS The UC Davis whois database contains entries for the 15,000 faculty and staff on campus. The service can return information on an individual or return a list of people in a particular department. A help page is returned by specifying "help" as the target. The service is also available via electronic mail. Usage from whois whois -h ucdavis.edu help Usage from electronic mail Send mail to Internet: whois@ucdavis.edu Bitnet: whois@ucdavis UUCP: ...!ucbvax!ucdavis!whois Enter the whois target name on the "Subject:" line. The result will be sent via return email, assuming the "From:" line on the original message is a valid address. Example: To: whois@ucdavis.edu From: user@host.campus.edu Subject: help ---------------------------------------- I received several messages from sites indicating that they currently did not have a server or database. However, they were interested in setting one up and asked about our software. Here is the information. Our whois server and email interface run on a 4.3 bsd system. It is a combination of local code and a Unify database. The main reason for using Unify is because it was already on the system. If you are interested, the sources for the local code, which can be used with the Unify system or modified to work with another database, are available via anonymous ftp from ucdavis.edu and are in the directory dist/ucdwhois/. We also use this same database for the campus email delivery system. Included in the database is the actual usercode and host that mail for a MAILID is to be delivered. Details on the database structure are included in the tar file. Russ Russell Hobby Data Communications Manager U. C. Davis Computing Services BITNET: RDHOBBY@UCDAVIS Davis Ca 95616 UUCP: ...!ucbvax!ucdavis!rdhobby (916) 752-0236 INTERNET: rdhobby@ucdavis.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711122040.AA11870@athos.rutgers.edu] <1987111210403700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple subnets on one physical network Message-ID: <8711122040.AA11870@athos.rutgers.edu> Date: Thu, 12-Nov-87 15:40:37 EST Article-I.D.: athos.8711122040.AA11870 Posted: Thu Nov 12 15:40:37 1987 Date-Received: Thu, 19-Nov-87 20:31:33 EST References: <8711121908.AA09765@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 The truth is that every different implementation has its own quirks, and you're going to have to find a combination of features that works with the particular set of implementations that you have. The cleanest thing is probably to have each interface on the gateway have a single address. The Unix versions that I know of only require that the gateway be on a directly connected network. You can tell them that all the subnets are directly connected, by using "route add" with a zero metric. So there is no problem. It is true that many systems (not just Unix) will try to forward packets for addresses that they don't recognize. 4.3 can have this turned off. In a situation where there are multiple subnets on one cable, I would use a broadcast address of 255.255.255.255, rather than mentioning the specific net number. 4.3 lets you set the broadcast address to be used on an interface. So do some other systems. Whether all of yours do is anybody's guess. I'm afraid you're going to have to look in detail at each system you have and find a combination of things that works. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12350105889.11.BILLW@MATHOM.CISCO.COM] <1987111211575000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: TACs and SLIP... Message-ID: <12350105889.11.BILLW@MATHOM.CISCO.COM> Date: Thu, 12-Nov-87 16:57:50 EST Article-I.D.: MATHOM.12350105889.11.BILLW Posted: Thu Nov 12 16:57:50 1987 Date-Received: Thu, 19-Nov-87 20:32:38 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 53 Oops. My question was slightly misunderstood (But it did cause a lot of interesting responses). Perhaps a more detailed explanation is called for, if I can do it without getting overly commercial... There are essentially two models possible for doing a "slip server". At cisco, we refer to these as the "terminal server" model, and the "gateway" model. In the gateway model, each slip connection has its own subnet, possibly with another network on the other end of the link. Information about how to reach hosts on the other side is all exchanged via normal routing protocols, and the box is acting as a real gateway. The host can pick its own IP address by virtue of pretending to be a gateway between the SLIP link (whose address is fixed) and the host's network. In the terminal server model, each slip connection is mapped to a particular IP address, and the box ARPs for all of the resulting IP addresses - essentially acting as a giant, extra long, very slow, multi-port ethernet transceiver. Each slip speaking box gets assigned an IP address on the same subnet as the terminal server itself. Since no routing information is exchanged, only one IP address at the other end is possible, and the slip server gets to pick it. cisco has implemented the terminal server model of a slip server as part of our terminal server. If enabled, users could issue a SLIP command, and the exec prints out info telling them their IP address, and then it goes into a mode where only IP packets are transferred. (How to exchange this sort of information in a machine oriented fashion is an unresolved issue - we're interested in any suggestions). SLIP lines (actually, lines in general) can run up to 38.4Kbps, and of course lines can get configured permanently in SLIP mode too. Up to 96 terminal lines can be put on one box. We think that the gateway model is also implementable, though the idea of an 97 way gateway is somewhat mind-boggling. What may happen in this area is a SLIP driver for the serial (normally HDLC) cards we are currently using. Up to 6 lines per box would be possible. The original question I asked was meant to mean: Given that we have implemented SLIP on our ethernet terminal server, and that we also sell a DDN terminal server (a "TAC" with 1822 or X.25 interfaces), should be also attempt to have the DDN Terminal server ALSO support slip, by way of the logical host mechanism that exists in the DDN network world. Im still interested in the answer to that question, but the discussion on SLIP issues in general is interesting too, though it might be more appropriate for, say, the PCIP mailing list. Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711171539.AA13922@ucbvax.Berkeley.EDU] <1987111213320000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CF4A8X@IRISHMVS.BITNET ("Mark D. Eggers 239-7258", 219) Newsgroups: comp.protocols.tcp-ip Subject: Name Server for Ultrix 2.0 Message-ID: <8711171539.AA13922@ucbvax.Berkeley.EDU> Date: Thu, 12-Nov-87 18:32:00 EST Article-I.D.: ucbvax.8711171539.AA13922 Posted: Thu Nov 12 18:32:00 1987 Date-Received: Thu, 19-Nov-87 20:36:15 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Does anyone know of a name server implementation for Ultrix 2.0 ? I haven't seen it in the documentation . . . . Thanks for any information /mde/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111213320001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 12 Nov 87 15:44:26-PST Received: from IRISHMVS.BITNET by wiscvm.wisc.edu ; Thu, 12 Nov 87 17:33:53 CDT Date: Thu, 12 Nov 87 18:32 EST To: tcp-ip@sri-nic.arpa From: "Mark D. Eggers (219) 239-7258" Subject: Name Server for Ultrix 2.0 Does anyone know of a name server implementation for Ultrix 2.0 ? I haven't seen it in the documentation . . . . Thanks for any information /mde/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]Thu,.12.Nov.87.16:30:20.PST.STJOHNS] <1987111214300000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: TACs and SLIP... Message-ID: <[SRI-NIC.ARPA]Thu,.12.Nov.87.16:30:20.PST.STJOHNS> Date: Thu, 12-Nov-87 19:30:00 EST Article-I.D.: <[SRI-NIC.ARPA]Thu,.12.Nov.87.16:30:20.PST.STJOHNS> Posted: Thu Nov 12 19:30:00 1987 Date-Received: Thu, 19-Nov-87 21:34:10 EST References: <12350105889.11.BILLW@MATHOM.CISCO.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 For a terminal server plugged into a class A c30 net, use the 3rd octet of the IP address to differentiate the SLIP ports. I.e. transparent gateways or port expander model. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711081949.AA11473@nic.nyser.net] <1987111216562000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@NISC.NYSER.NET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: SGMP Message-ID: <8711081949.AA11473@nic.nyser.net> Date: Thu, 12-Nov-87 21:56:20 EST Article-I.D.: nic.8711081949.AA11473 Posted: Thu Nov 12 21:56:20 1987 Date-Received: Sat, 14-Nov-87 17:39:05 EST References: <531@bpa.BELL-ATL.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Does anyone know where I can get info concerning SGMP (Simple Gateway Mgmt. Protocol)? Anything would be helpful. Thanks in Advance, -- ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== -=== Bob Esposito, Bell of Pennsylvania - espo@bpa.bell-atl.com - (215) 466-68 31 ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=== -=== why don't you call the NYSERNet NISC at 518-283-8860 and ask for either Mark Fedor or myself, (we're two of the authors of the RFC). Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]13-Nov-87.06:48:17.CERF] <1987111301480000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Solicitation for comments Message-ID: <[A.ISI.EDU]13-Nov-87.06:48:17.CERF> Date: Fri, 13-Nov-87 06:48:00 EST Article-I.D.: <[A.ISI.EDU]13-Nov-87.06:48:17.CERF> Posted: Fri Nov 13 06:48:00 1987 Date-Received: Thu, 19-Nov-87 22:18:40 EST References: <111287.142523.yakov@ibm.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 In a large scale, highly heterogeneous internet, knowing the entire topology requires that a substantial amount of information be shared among a far-flung set of components. This is not easy - nor is the data necessarily very timely when it finally arrives. Basing routing on out-of-date information seems like an invitation to congestion - or are you discounting that on the basis of something you haven't mentioned yet? Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [0VZHony00UoJ07s0Tz@andrew.cmu.edu] <1987111301515300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: Re: ARP over FDDI Message-ID: <0VZHony00UoJ07s0Tz@andrew.cmu.edu> Date: Fri, 13-Nov-87 06:51:53 EST Article-I.D.: andrew.0VZHony00UoJ07s0Tz Posted: Fri Nov 13 06:51:53 1987 Date-Received: Sun, 15-Nov-87 07:34:22 EST References: <871105210734.397661@MIT-Multics.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 What's the problem with 16 or 48 bit addresses? All 802.x networks are like this. However, it is clearly specified that you can't have a particular network with both sizes in use at the same time. I'll bet FDDI is the same, though I don't have a spec in hand. In either case, the hardware length field in the ARP packet should be used to specify the size. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- [871113083833.1.GAVIN@DREA-BALROG.ARPA] <1987111302380000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Gavin@DREA-BALROG.ARPA (Gavin L. Hemphill) Newsgroups: comp.protocols.tcp-ip Subject: Re: MILNET <=> ARPANET problems Message-ID: <871113083833.1.GAVIN@DREA-BALROG.ARPA> Date: Fri, 13-Nov-87 07:38:00 EST Article-I.D.: DREA-BAL.871113083833.1.GAVIN Posted: Fri Nov 13 07:38:00 1987 Date-Received: Thu, 19-Nov-87 21:19:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 I also have been seeing the problems mentioned in previous messages when trying to establish connections between a host on DRENET (DREA-XX.ARPA) and hosts on the ARPANET (looooong round trip times many packets dropped etc.) but just to add some new information I seem to be able to make reasonably reliable connections between the same host and hosts on the MILNET. Now I know, given our network topology that the packets to/from the MILNET are flowing through the ARPANET so why can't I make connections to machines on the ARPANET? G++ ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1815@geac.UUCP] <1987111304134000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: daveb@geac.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Telephone Access Controllers (TACs) and SLIP... Message-ID: <1815@geac.UUCP> Date: Fri, 13-Nov-87 09:13:40 EST Article-I.D.: geac.1815 Posted: Fri Nov 13 09:13:40 1987 Date-Received: Sun, 15-Nov-87 03:52:28 EST References: <12348296366.8.BILLW@MATHOM.CISCO.COM> Reply-To: daveb@geac.UUCP (Dave Collier-Brown) Organization: The little blue rock next to that twinkly star. Lines: 30 Summary: And other things, too... In article <12348296366.8.BILLW@MATHOM.CISCO.COM> BILLW@MATHOM.CISCO.COM (William Westfield) writes: >Is there any interest in a TAC like device capable of running SLIP >(Serial Line IP) on its terminal interfaces ? As I currently >envision this, each serial line could be a logical host when acting >as an IP device, and just a normal port when acting as a terminal. >This might provide some performance improvement over things like >kermit for downloading/uploading files.... > >Bill Westfield >cisco Systems. This is a subset of the idea of an "async gateway processor", which is a small, general-purpose computer gutted to run several gateway programs. A plausable set might be: IP to ordinary ttys (ie, normal TACyness) IP to SLIP TCP/IP telnet/TACyness kermit (recent large-block kind) TCP/IP telnet/TACyness to MNP (a mostly-transparent modem protocol) TCP/IP telnet/TACyness to X.pc (if you feel masocistic) A good cantidate for such a machine might be one of the "unix-like" small realtime systems running on mas-market hardware. --dave -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4289@sdcsvax.UCSD.EDU] <1987111304503300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brian@sdcsvax.UCSD.EDU (Brian Kantor) Newsgroups: comp.protocols.tcp-ip Subject: MINFO, MAILA, MB, MR, MG usage Message-ID: <4289@sdcsvax.UCSD.EDU> Date: Fri, 13-Nov-87 09:50:33 EST Article-I.D.: sdcsvax.4289 Posted: Fri Nov 13 09:50:33 1987 Date-Received: Sun, 15-Nov-87 09:02:12 EST Organization: UCSD wombat breeding society Lines: 23 We've come to the conclusion here at UCSD that a few of our mailbox handling problems can be solved by using the nameserver system on campus as a method of maintaining and distributing a sort of global mailbox mapping table. Clearly something of this nature was intended when the MAILB, MB, MR, MG, and MINFO stuff was designed into the nameserver system. Yet I can find no solid suggestions for use, nor any mention of actual implementations of these features. The early domain RFCs mention the possible uses, but offer no practical suggestions nor do they really define the semantics of each of the possible mailbox RRs. RFC974 also denies any specification. Is this uncharted territory? Have others used these RRs? I'm in the process of hacking them into the Berkeley Unix MTA - sendmail. Any suggestions would be welcome. Brian Kantor UCSD Postmaster & Keeper of the News UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA brian@sdcsvax.ucsd.edu (619) 534-6865 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [284985.871113.JBVB@AI.AI.MIT.EDU] <1987111304580100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Networks & vendor upgrades/fixes Message-ID: <284985.871113.JBVB@AI.AI.MIT.EDU> Date: Fri, 13-Nov-87 09:58:01 EST Article-I.D.: AI.284985.871113.JBVB Posted: Fri Nov 13 09:58:01 1987 Date-Received: Fri, 20-Nov-87 22:03:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 .... If you are running an old release you should upgrade. -- WIN This is one of the problems faced by network managers and users. Upgrading them might be easy, if they were my machines, and their software was under maintenance. Not many manufacturers offer software upgrades on a "1 master per site" basis, and the fees I remember from my PDP-11 days are in the thousands of dollars a year. Most licenses allow users to copy the new software to many machines, but having only one set of current manuals breaks down if more than 5 or 6 people are using them, or they aren't close together. Regardless, there is a fair amount of effort involved in installing a new release, whatever the cost, and not many users of these machines are up to doing so themselves, even if they had time. Customization and O/S-version- dependent third-party software can make upgrading essentially impossible, even if attempted by the original installer. All of which is why many organizations which are setting up large networks want homogenous hardware, rigid version control, and source code. Perhaps the manufacturers should put on their thinking caps... jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [240@syntrex.uucp] <1987111304594700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: roytar@syntrex.uucp (Roy Tarantino) Newsgroups: comp.protocols.tcp-ip Subject: distribution list Message-ID: <240@syntrex.uucp> Date: Fri, 13-Nov-87 09:59:47 EST Article-I.D.: syntrex.240 Posted: Fri Nov 13 09:59:47 1987 Date-Received: Sun, 15-Nov-87 09:02:38 EST References: <8711082007.AA03691@ACC-SB-UNIX.ARPA> Reply-To: roytar@syntrex.UUCP (Roy Tarantino) Organization: Syntrex Inc., Eatontown, New Jersey Lines: 4 Please add me to the maillist for this group. Thanks, Roy Tarantino ...!rugters!pyrnj!syntrex!roytar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711131509.AA00541@nrl-thinksun.arpa] <1987111305092100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nemnich@NRL-CMF.ARPA Newsgroups: comp.protocols.tcp-ip Subject: ARPANET<->MILNET problems Message-ID: <8711131509.AA00541@nrl-thinksun.arpa> Date: Fri, 13-Nov-87 10:09:21 EST Article-I.D.: nrl-thin.8711131509.AA00541 Posted: Fri Nov 13 10:09:21 1987 Date-Received: Thu, 19-Nov-87 23:20:37 EST References: <281907.871108.PAP4@AI.AI.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 I have had the misfortune of having to cross the MILNET/ARPANET boundary for the past two months. I don't think the problems are related to the new PSN software, since I am not seeing that much of a difference since it was installed. Also, things are moving right along when I stay on the MILNET or the ARPANET. The gateways must be incredibly overloaded; I see lots of packet loss when pinging across the boundary. A question for those with the data: How evenly spread is the load among the ARPA/MILNET gateways? --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA Temporarily at NRL, Washington, DC: +1 202 767 9044 bruce@think.com, ihnp4!think!bruce, bjn@mitvma.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3083@psuvax1.psu.edu] <1987111305373900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ehrlich@psuvax1.psu.edu (Dan Ehrlich) Newsgroups: comp.protocols.tcp-ip Subject: Re: Life after source quench Message-ID: <3083@psuvax1.psu.edu> Date: Fri, 13-Nov-87 10:37:39 EST Article-I.D.: psuvax1.3083 Posted: Fri Nov 13 10:37:39 1987 Date-Received: Sun, 15-Nov-87 08:17:14 EST References: <8711081434.aa25516@Huey.UDEL.EDU> Reply-To: ehrlich@psuvax1.psu.edu (Dan Ehrlich) Organization: Department of Computer Science, Penn State University Lines: 19 In article <8711081434.aa25516@Huey.UDEL.EDU> Mills@UDEL.EDU writes: > ... >HOST : 128.117.8.7 : (unlisted - who is this USAN dude?) >20:26:43 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] I do not know who [128.117.8.7] is but [128.118.28.2] is psumeteo01.psu.edu, a MicroVAX II run by the meteorology department here at Penn State. I believe that they run VMS and are using an EXCELAN card to there TCP/IP. If I can be of more help get in touch. > ... >Dave -- Dan Ehrlich The Pennsylvania State University, Department of Computer Science 333 Whitmore Laboratory, University Park, PA 16802 +1 814 863 1142 or +1 814 865 9723 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [184@bnl.ARPA] <1987111305420600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gc@bnl.ARPA (Graham Campbell) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet versions Message-ID: <184@bnl.ARPA> Date: Fri, 13-Nov-87 10:42:06 EST Article-I.D.: bnl.184 Posted: Fri Nov 13 10:42:06 1987 Date-Received: Sun, 15-Nov-87 18:54:36 EST References: <4800@elroy.Jpl.Nasa.Gov> <4652@amd.AMD.COM> Reply-To: gc@bnl.UUCP (Graham Campbell) Organization: Brookhaven National Lab., Upton, N.Y. Lines: 25 Keywords: info? In article <4652@amd.AMD.COM> nguyen@amd.AMD.COM (Quinn Nguyen) writes: >In article <4800@elroy.Jpl.Nasa.Gov>, david@elroy.Jpl.Nasa.Gov (David Robinson) writes: >> As most people know their are a couple ethernet standards, Version 1, >> Version 2 and IEEE 803.2. When one installs a new ethernet board >> ... >> The question: What is the difference between the versions and what > ... >Other issues are device to device line static isolation, ground, >etc. which are not relevant to transceiver connection... >in term of functionality. However if you interpret "functionality" to include "does it function", then the other issues are very relevant. We have had the experience where a IEEE 803.2 transceiver would work, but a Version 2 transceiver would not work. The difference apparently was in the shielding and extra pins used in the connectors for the shielding. From my description you can tell that I do not understand the problem very well and would appreciate a reference to the complete differences (if it exists). Graham -- Graham Campbell (gc@bnl.arpa, gc@bnl.bitnet, ...!phillabs!sbcs!bnl!gc) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711131633.AA28236@monk.proteon.com] <1987111306331900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: ARP over FDDI Message-ID: <8711131633.AA28236@monk.proteon.com> Date: Fri, 13-Nov-87 11:33:19 EST Article-I.D.: monk.8711131633.AA28236 Posted: Fri Nov 13 11:33:19 1987 Date-Received: Fri, 20-Nov-87 22:39:26 EST References: <0VZHony00UoJ07s0Tz@andrew.cmu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Nope, FDDI is more clever. You can mix address sizes on the same ring. Why do architects of next-generation network whatevers keep insisting on variable-size everything? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [452@ra.rice.edu] <1987111306473800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: retrac@titan.rice.edu (John Carter) Newsgroups: comp.protocols.tcp-ip Subject: Results of my query on best TCP-IP performance Message-ID: <452@ra.rice.edu> Date: Fri, 13-Nov-87 11:47:38 EST Article-I.D.: ra.452 Posted: Fri Nov 13 11:47:38 1987 Date-Received: Sun, 15-Nov-87 09:43:48 EST Sender: usenet@rice.edu Reply-To: retrac@rice.edu (John Carter) Organization: Rice University, Houston Lines: 69 References: Hello, A couple of weeks ago I posted a query about what the absolute best case for tcp-ip throughput on a 10 Mbit/sec ethernet was. I didn't get many responses, but I'm very grateful for those that did reply (Thanks!). The numbers are pretty good, but for comparison purposes keep in mind that these are best case numbers and also make note of the processors on which the measurements were made (since processor speed is the dominant cost). ---- From: David Robinson The best I have personally seen is between two Sun-3/260's doing memory-memory transfers is 3.2Mbits/sec. Their UDP topped out at 5Mbits/sec. This was on a fairly quite net, rwhod and routed traffic only. From my experience excelan boards have been the worst, slower than my lowly Sun-2, but what can be expected from a 80186?? I do not know what the limiting factor of the Sun's is by I suspect that it is CPU bound, the e-net controllers each have large memmory buffers (256K?). -David Robinson david@elroy.jpl.nasa.gov ---- From: lekash@orville.nas.nasa.gov Better performance for ethernet is not that likely until someone builds a better interface card. Thats the current bottleneck. If you go to other media, say pronet-80, or hyperchannel, you can get much higher rates. we were seeing up to 17mbits/sec over hyperchanel, proteon claims over seven for their ring. I would guess with performance tuning, those numbers will increase. (We might even do some here.) john ---- From: nowicki%rose@sun.com (Bill Nowicki) Disclaimer: this is NOT an official number, just my latest test in an uncontrolled environment with an unannounced software configuration. But between a pair of Sun-4/260s I am able to transfer with TCP over an Ethernet at 5.0 Mbits/second. -- WIN ---- Thanks again to David, John and Bill! The next article should be a follow-up query. John Carter Rice University =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* * UUCP: {Backbone or Internet site}!rice!retrac oo = = ARPA: retrac@rice.edu < * * CSNET: retrac@rice.edu U - Bleh. = =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711131654.AA07454@orville.nas.nasa.gov] <1987111306543500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lekash@orville.nas.nasa.GOV.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Life after source quench Message-ID: <8711131654.AA07454@orville.nas.nasa.gov> Date: Fri, 13-Nov-87 11:54:35 EST Article-I.D.: orville.8711131654.AA07454 Posted: Fri Nov 13 11:54:35 1987 Date-Received: Fri, 20-Nov-87 21:50:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 I take care of 128.102.16.10. It's one of the '2nd-root-servers' Quite why someone at rutgers is sending such a stream of to it, I couldn't tell you. Maybe a broken server at their end, and they are cleverly using the wrong set of servers due to a leak somewhere. john ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711131156.aa10675@CAD.USNA.MIL] <1987111306565300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcs@USNA.MIL.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Tektronix 6130 bugs Message-ID: <8711131156.aa10675@CAD.USNA.MIL> Date: Fri, 13-Nov-87 11:56:53 EST Article-I.D.: CAD.8711131156.aa10675 Posted: Fri Nov 13 11:56:53 1987 Date-Received: Fri, 20-Nov-87 22:38:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Hi, We have a Tektronix 6130 here at the Naval Academy. Unfortunately, it seems to have some interoperability problems with regard to the ethernet. It has its own nameserver which doesn't seem to know about RFC 882 domain nameserver operation and domain style names. It falls back to reading /etc/hosts for systems not running the Tektronix nameserver. The manual states: Only the following characters are allowed in a hostname: letters (upper or lower), digits, underline _, or minus sign -. Does anyone know of a real fix for this? We have also had problems with rwho and ruptime, among others. Is anyone successfully using a Tek 6130 in an internet environment? Thanks, -tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [454@ra.rice.edu] <1987111307121900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: retrac@titan.rice.edu (John Carter) Newsgroups: comp.protocols.tcp-ip,comp.protocols.misc Subject: Query for best protocol performance on a 10 Mbit/sec ethernet Message-ID: <454@ra.rice.edu> Date: Fri, 13-Nov-87 12:12:19 EST Article-I.D.: ra.454 Posted: Fri Nov 13 12:12:19 1987 Date-Received: Sun, 15-Nov-87 09:48:21 EST Sender: usenet@rice.edu Followup-To: comp.protocols.misc Organization: Rice University, Houston Lines: 42 Keywords: Throughput Hello, I'm studying high throughput bulk data transfer protocols and am interested in finding out what the best performing current protocols can achieve. I'd like to know what are some best/average case times for various protocols to transmit 10 megabytes over a 10 Mbit/sec ethernet. To be more specific, what are the best or average times for your favorite bulk data transfer protocol (tcp-ip, etc.) to transfer 10 Mbytes from the main memory of one machine to the main memory of another machine (as measured from the time the sender invokes the protocol until the receiver receives the entire chunk of data and the sender is informed of this). I'm primarily interested in performance over a 10 Mbit/sec ethernet (which is pretty standard) but wouldn't mind hearing about other systems. An alternative performance measure is the best case throughput (megabits/sec) that your favorite protocol achieves - in this case mention how much data you transferred to get the result. Please include a short description of your configuration (e.g. a pair of Sun 3/180's on a 10 Mbit/sec ethernet running Sun Unix 3.2). Also mention any performance tuning hacks you may have done to the original protocol (if any). This should make it obvious what the bottleneck in the system is (usually the CPUs) and other things. If its an uncommon or special purpose protocol, a reference would be helpful. Mail your responses to me directly via e-mail. After the responses begin to taper off, I'll post the results to comp.protocols.misc. Thanks in advance for any time and effort you make on my behalf! John Carter Dept. of Computer Science Rice University P.S. I've posted the results of a similar query restricted to tcp-ip in comp.protocols.tcp-ip for anyone that's interested but doesn't normally read that newsgroup. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* * UUCP: {Backbone or Internet site}!rice!retrac oo = = ARPA: retrac@rice.edu < * * CSNET: retrac@rice.edu U - Bleh. = =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* ----MESSAGE-END---- ----MESSAGE-BEGIN---- [537@hqda-ai.UUCP] <1987111308173700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: merlin@hqda-ai.UUCP (David S. Hayes) Newsgroups: comp.protocols.tcp-ip Subject: Re: smtp on Symbolics lisp machines Message-ID: <537@hqda-ai.UUCP> Date: Fri, 13-Nov-87 13:17:37 EST Article-I.D.: hqda-ai.537 Posted: Fri Nov 13 13:17:37 1987 Date-Received: Sun, 15-Nov-87 09:45:56 EST References: <353@vilya.UUCP> Organization: Army AI Center, Pentagon Lines: 26 Keywords: tcp smtp symbolics Summary: SMTP on Symbolics works fine - the others are botched In article <353@vilya.UUCP>, rhk@vilya.UUCP (KENSICKI) writes: > > Does anyone have any expierence running tcp on Symbolics 3640's > and 3675's ? > It seems that the Symbolics doesn't follow the format of > smtp and usr a CR NL at the end of a line. I did this here. The SMTP works fine, but the Unix machines in general are botched. The Sun, in particular, sends newline (LF) at the end of line. The Symbolics obediently sat there and waited for a CR LF combination, which the Sun never sent. The fix was to add "E=\r\n" to the sendmail.cf on the Sun. Beware of the Symbolics store-and-forward mailer. This system believes that if you have a Symbolics user "chris", then every "chris" in the world is just another name for your local user. I could not get around this - I had to tell the Symbolics machines that they did not have store-and-forward, but the Sun did. I also set all-addresses-forward. The Symbolics then give everything to the Sun, which is smart enough to get it to the correct machine. -- David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900 UUCP: *!uunet!cos!hqda-ai!merlin ARPA: ai01@hios-pent.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [812@ge-dab.GE.COM] <1987111309032500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kelsen@ge-dab.GE.COM (Mike Kelsen) Newsgroups: comp.protocols.tcp-ip Subject: Re: smtp on Symbolics lisp machines Message-ID: <812@ge-dab.GE.COM> Date: Fri, 13-Nov-87 14:03:25 EST Article-I.D.: ge-dab.812 Posted: Fri Nov 13 14:03:25 1987 Date-Received: Sun, 15-Nov-87 11:46:41 EST References: <353@vilya.UUCP> Reply-To: kelsen@ge-dab.UUCP (Mike Kelsen) Organization: GE Simulation & Control Systems Dept., Daytona Beach, FL Lines: 14 Keywords: tcp smtp symbolics We experienced a similar problem with mail between a VAX 11/780 running ULTRIX 2.0 and our Symbolics. To correct the problem, we modified the /usr/lib/sendmail.cf file on the VAX to include the following line for mailing to the Symbolics: Mether, P=[IPC], F=msDFMuC, S=11, R=21, E=\r\n, A=IPC $h If this doesn't work as is, try to rearrange the items on the line. That's how we got ours to work! Good Luck! Michael S. Kelsen mcnc!ge-rtp!ge-dab!kelsen kelsen%ge-dab.GE.COM@mcnc.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- [208@scdpyr.UUCP] <1987111310210200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cruff@scdpyr.UUCP (Craig Ruff) Newsgroups: comp.protocols.tcp-ip Subject: Re: Life after source quench Message-ID: <208@scdpyr.UUCP> Date: Fri, 13-Nov-87 15:21:02 EST Article-I.D.: scdpyr.208 Posted: Fri Nov 13 15:21:02 1987 Date-Received: Sun, 15-Nov-87 16:40:56 EST References: <8711081434.aa25516@Huey.UDEL.EDU> <3083@psuvax1.psu.edu> Reply-To: cruff@scdpyr.UUCP (Craig Ruff) Organization: Natl Ctr Atmospheric Research, Boulder, CO Lines: 13 In article <3083@psuvax1.psu.edu> ehrlich@psuvax1.psu.edu (Dan Ehrlich) writes: >In article <8711081434.aa25516@Huey.UDEL.EDU> Mills@UDEL.EDU writes: >> ... >>HOST : 128.117.8.7 : (unlisted - who is this USAN dude?) >>20:26:43 ?TRAP-I-ICMP 004 133 [128.117.8.7] -> [128.118.28.2] > >I do not know who [128.117.8.7] is but [128.118.28.2] is 128.117.8.7 is an IBM 4381 here at NCAR running Spartacus KNET software. -- Craig Ruff NCAR INTERNET: cruff@scdpyr.UCAR.EDU (303) 497-1211 P.O. Box 3000 CSNET: cruff@ncar.CSNET Boulder, CO 80307 UUCP: cruff@scdpyr.UUCP ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12350362501.9.BILLW@MATHOM.CISCO.COM] <1987111311272700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BILLW@MATHOM.CISCO.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: ARP and various things other than ethernet.... Message-ID: <12350362501.9.BILLW@MATHOM.CISCO.COM> Date: Fri, 13-Nov-87 16:27:27 EST Article-I.D.: MATHOM.12350362501.9.BILLW Posted: Fri Nov 13 16:27:27 1987 Date-Received: Fri, 20-Nov-87 22:39:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Note that it is not necessary for the hardware address of a host to be larger than the software address in order for ARP to work. There isn't any reason why ARP can be used, more or less as-is, for any hardware network having a broadcast concept... Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10334@brl-adm.ARPA] <1987111311385600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: abc@brl-adm.ARPA (Brint Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Re: smtp on Symbolics lisp machines Message-ID: <10334@brl-adm.ARPA> Date: Fri, 13-Nov-87 16:38:56 EST Article-I.D.: brl-adm.10334 Posted: Fri Nov 13 16:38:56 1987 Date-Received: Sun, 15-Nov-87 10:14:54 EST References: <353@vilya.UUCP> Reply-To: abc@brl.arpa (Brint Cooper) Organization: Ballistic Research Laboratory Lines: 14 Keywords: tcp smtp symbolics In article <353@vilya.UUCP> rhk@vilya.UUCP (KENSICKI) writes: | Does anyone have any expierence running tcp on Symbolics 3640's | and 3675's ? | Any thoughts would be appreciated. Send a note to slug@r20.utexas.edu. Surely someone there can help you. _Brint -- Brint Cooper ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711132236.AA04413@athos.rutgers.edu] <1987111312364400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Life after source quench Message-ID: <8711132236.AA04413@athos.rutgers.edu> Date: Fri, 13-Nov-87 17:36:44 EST Article-I.D.: athos.8711132236.AA04413 Posted: Fri Nov 13 17:36:44 1987 Date-Received: Sat, 21-Nov-87 03:05:38 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 There can't really be two sets of root servers. The problem is that when a server doesn't know the answer to a question, it generally sends a response that refers the questioner to the root. Bind processes such responses by adding all the data they give to its cache, and then posing its question again. (The hope is that some of the data just added will let it find the answer this time.) So if the official root servers point to any other servers that even indirectly ever refer us to a server that lists the bogus root servers in a response, we will eventually end up with the bogus root servers in our cache. Furthermore, the problem is contagious, because now we will refer other people to talk to us to you as a root server. I don't doubt that there are still bugs in our named (although I think it is better than any of the released versions). But it doesn't dream up name servers out of whole cloth. I believe you are seeing a combination of a bug that causes unreasonably large rates of name server requests, with the fact that somebody has referred us to you as a root server. Thus you get caught in the crossfire between us and the roots. Tonight I'm going to spend some more time inside named. I have found a number of pieces of code in it already that are non-functional. I suspect I'll find another one or two tonight. (Definition: When I use the term "bogus root name server", I mean any name server that claims to be a root name server, which is not listed as one by SRI-NIC when we ask it who the root servers are.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [871114000654.914431@MIT-Multics.ARPA] <1987111314060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Kastenholz@MIT-MULTICS.ARPA Newsgroups: comp.protocols.tcp-ip Subject: RPC/NFS over IP Routers Message-ID: <871114000654.914431@MIT-Multics.ARPA> Date: Fri, 13-Nov-87 19:06:00 EST Article-I.D.: MIT-Mult.871114000654.914431 Posted: Fri Nov 13 19:06:00 1987 Date-Received: Sat, 5-Dec-87 17:36:37 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Does anybody have any experience, rules of thumb, guidelines, etc, about running the Sun NFS/RPC protocols over an IP gateway/router (e.g. Bridge GS/n) over a long haul line of any speed (T1, X.25, 9600Baud, 56Kb line, etc)? The configuration that I am dealing with is a large central site that is the main file store, with a number of PC's as work stations. Access to the file store (VAX 8xxx) will be by RPC/NFS. Some of the alternatives that we are looking at are using MAC level bridges to connect the Ethernets and using a *big* machine to act as a file stager at the remote Ethernet (e.g. a Sun) and doing some form of program driven file transfer from the VAX to the Sun and then RPC/NFS from pc to sun on the local net. Please send any replies to me. I will post a summary in a couple of days if there is enough. Thanks Frank Kastenholz ATEX Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711140153.AA09162@sccgate.scc.com] <1987111315533900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) Newsgroups: comp.protocols.tcp-ip Subject: Idle chatter about reference models Message-ID: <8711140153.AA09162@sccgate.scc.com> Date: Fri, 13-Nov-87 20:53:39 EST Article-I.D.: sccgate.8711140153.AA09162 Posted: Fri Nov 13 20:53:39 1987 Date-Received: Sat, 21-Nov-87 01:51:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 44 Caveat: Since this is idle chatter (see Subject:) the words martian, bogon, fuzzball, and playpen will not appear in the body of this message. My office-mate just received a colorful poster from CMC comparing a seven-layer DoD Internet reference model to the seven-layer ISORM. I've attatched a little chart comparing those two RMs to the old four-layer ARM [1] for the idly curious. The most glaring oddity (aside from typos and a cute phone number) is the depiction of EGP, GGP and HMP as Transport layer protocols. When I expressed my surprise at this to my office-mate he wanted to know where they did belong (magic-marker in hand). My instinctive answer was that EGP and GGP belonged in the Internetwork layer and that HMP belonged in Massachusetts. Since I'm just a hanger-on in this field, I was wondering to which layer the protocol police would assign EGP and GGP (and their descendants). I would also like to know if the aforementioned ARM has ever been supplanted. Mike 1. While displaying an affinity for M. Padlipsky's naming scheme (RFC871), the four-layer model to which I refer is the one described by B. Leiner, et. al. in "The DARPA Internet Protocol Suite". -------------------------------------------------------- ISORM CMCRM ARM -------------------------------------------------------- Application Application Application -------------------------------- Presentation Utility Session -------------------------------------------------------- Transport Transport Service -------------------------------------------------------- Internetwork Internetwork ------------------------ Network Network Network -------------------------------- Data Link Data Link -------------------------------- Physical Physical -------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711140229.AA23274@acetes.dec.com] <1987111316290000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP maximum segment size determination Message-ID: <8711140229.AA23274@acetes.dec.com> Date: Fri, 13-Nov-87 21:29:00 EST Article-I.D.: acetes.8711140229.AA23274 Posted: Fri Nov 13 21:29:00 1987 Date-Received: Sat, 21-Nov-87 01:54:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 ORCHARD/BRUC@SCARECROW.WAISMAN.WISC.EDU (Bruce Orchard) writes: I propose adding a new option to the IP header. This option would give the minimum of the maximum transmission units of any network that handled the packet. The originating end would set it to a large value. Each node that transmitted the packet would compare the value given in the option to the maximum transmission unit of the outgoing network. If the network value were less, the value in the option would be reduced to the network value. This is one of the several options proposed in "Fragmentation Considered Harmful", by Chris Kent and myself, presented at the SIGCOMM '87 Workshop this past August. I understood that the proceedings would be distributed to members of SIGCOMM, but so far I have not seen anything except the unpaginated version distributed at the workshop. Chris and I are preparing a slightly expanded version which should be available as a tech report sometime in the next few months. Although I think this is a great idea (and some day we'll take the proposal given in the paper and turn it into an RFC) it's not real likely that it is practical in the IP Internet, given the low likelihood of changing enough hosts and gateways to make it work. Instead, we recommend simply biting the bullet and using 576 bytes whenever you're not absolutely sure where a packet is going. 576 bytes isn't always fragmentation-proof, but it's a reasonable compromise. P.S. Is the MTU of SATNET really 256 bytes, as given in IEN 192? It's probably slightly less. I've had a hard time discovering the exact value. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [285345.871113.PAP4@AI.AI.MIT.EDU] <1987111317452500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: Is there an EGP that is available? Message-ID: <285345.871113.PAP4@AI.AI.MIT.EDU> Date: Fri, 13-Nov-87 22:45:25 EST Article-I.D.: AI.285345.871113.PAP4 Posted: Fri Nov 13 22:45:25 1987 Date-Received: Sat, 21-Nov-87 01:55:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Date: 6 Nov 87 11:43:58 GMT From: steinmetz!vdsvax!barnett@uunet.uu.net (Bruce G Barnett) Subject: Is there an EGP that is available? If we wanted to run EGP (External Gateway Protocol) on an Internet/mail gateway for the purposes of dynamically finding routes to other machines, where do we get this program? Is the source available? I know that Sun sells it with their DDN SunLink product. What about Ultrix/4.3bsd? What are the other protocols available - and what do people recommend? Thanks, -- Bruce G. Barnett uunet!steinmetz!barnett Bruce, EGP is not a routing protocol. It is a `reachability' protocol. There isn't sufficient information in EGP to avoid certain routing pitfalls, like looping... I believe it is FTP'ble either trantor.umd.edu. The archive is called "gated.tar", and is in the /pub directory. The source is in the public domain (I think). It should be the most current version. Also, Phil Karn recently found a minor patch for it that he claims avoids most of the ARPAnet trauma seen in the last few weeks, when EGP packets are fragmented and/or excessively delayed. His posting was also on TCP-IP. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711140701.AA06830@athos.rutgers.edu] <1987111321015200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: why Rutgers named has been attacking randomly selected net sites Message-ID: <8711140701.AA06830@athos.rutgers.edu> Date: Sat, 14-Nov-87 02:01:52 EST Article-I.D.: athos.8711140701.AA06830 Posted: Sat Nov 14 02:01:52 1987 Date-Received: Sat, 21-Nov-87 03:38:38 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 89 Rutgers has been running the beta test named 4.7. One very neat new features of 4.7 is that it implements a two-level caching scheme. That is, you can designate 2 or 3 machines as your primary servers. All other named's are set up to send requests through them. This lets you have a small number of well-populated caches, and avoids having every machine on your network have to interact with the Arpanet. This should be a great performance win for the net as a whole. Unfortunately, this causes a bug that was present as early as 4.4 (the earliest code we have around now) to have very serious effects. In ns_resp, rd is set instead of qr in a couple of places where responses are generated. (For those of you who don't have the bits memorized, rd is used in a query to mean that you are requesting the name server to handle the request recursively for you. qr must be set in all responses. It indicates that it is a response, rather than a query. There is no obvious meaning to rd in a response, though the spec does call for it to be copied from the original query.) The effect is that qr is not set in certain responses. With the two-level cache, interesting things result. The original host sends a query to the primary server. It eventually gives up, and sends a response back. But qr is not set. So the original server things that this is a query. It dutifully handles the query, by sending it back to the primary server. If you have more than one primary server, each request generates N more. The net effect is obvious. Apparently we have attacked various more or less innocent servers because of this bug. I believe it is what caused the high packet rates that Dave Mills saw to some otherwise innocent site at NASA. I just fixed the problem. Site running 4.7 should be very careful about this. I would think there might also be situations where this bug would cause trouble even in earlier releases, but I can't be sure. It is of course possible that I am misunderstanding what this code is supposed to do, and that I will end up with a very red face. (This has happened recently in other contexts.) But we have definitely seen the infinite packets, and the seriousness of the problem seemed to justify broadcasting a warning quickly. *** ns_resp.c.BAK Fri Nov 13 23:34:35 1987 --- ns_resp.c Sat Nov 14 01:09:50 1987 *************** *** 523,529 **** if (debug >= 3) fprintf(ddt,"resp: leaving, MAXCNAMES exceeded\n"); #endif ! hp->id = qp->q_id; hp->rd = hp->ra = 1; (void) send_msg(qp->q_msg, qp->q_msglen, qp); qremove(qp); return; --- 523,529 ---- if (debug >= 3) fprintf(ddt,"resp: leaving, MAXCNAMES exceeded\n"); #endif ! hp->id = qp->q_id; hp->qr = hp->ra = 1; (void) send_msg(qp->q_msg, qp->q_msglen, qp); qremove(qp); return; *************** *** 595,601 **** stats[S_RESPOK].cnt++; #endif /* The "standard" return code */ ! hp->id = qp->q_id; hp->rd = hp->ra = 1; (void) send_msg(msg, msglen, qp); qremove(qp); return; --- 595,601 ---- stats[S_RESPOK].cnt++; #endif /* The "standard" return code */ ! hp->id = qp->q_id; hp->qr = hp->ra = 1; (void) send_msg(msg, msglen, qp); qremove(qp); return; *************** *** 617,623 **** #endif hp = (HEADER *)(cname ? qp->q_cmsg : qp->q_msg); hp->rcode = SERVFAIL; ! hp->id = qp->q_id; hp->rd = hp->ra = 1; (void) send_msg((char *)hp, (cname ? qp->q_cmsglen : qp->q_msglen), qp); qremove(qp); return; --- 617,623 ---- #endif hp = (HEADER *)(cname ? qp->q_cmsg : qp->q_msg); hp->rcode = SERVFAIL; ! hp->id = qp->q_id; hp->qr = hp->ra = 1; (void) send_msg((char *)hp, (cname ? qp->q_cmsglen : qp->q_msglen), qp); qremove(qp); return; ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111403275700> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Sat 14 Nov 87 09:04:38-PST To: oconnor@sccgate.scc.com cc: tcp-ip@sri-nic.ARPA Subject: re: idle chatter about reference models Date: Sat, 14 Nov 87 11:47:57 -0500 From: Craig Partridge Mike, I'd say HMP belonged at the transport layer. It can be reasonably neatly dropped into a binary bsd kernel as a transport protocol, and it has the usual transport functions (transport user addressing, sequence numbers, etc). As for the four level ARM -- I recently argued to someone that we're approaching five levels: Application [Presentation] Transport Internetwork Network The argument being that while we have no standard Presentation layer, we are certainly using presentation schemes (XDR, Courier, ASN.1, multimedia formats, etc.) Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711141736.AA21062@topaz.rutgers.edu] <1987111407365400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet versions Message-ID: <8711141736.AA21062@topaz.rutgers.edu> Date: Sat, 14-Nov-87 12:36:54 EST Article-I.D.: topaz.8711141736.AA21062 Posted: Sat Nov 14 12:36:54 1987 Date-Received: Sat, 21-Nov-87 04:39:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 On the coax there is no differenece electrically between Version I Version II, and IEEE 802.3. There is an encoding difference in the bytes. The 802.3 uses the two bytes following the source address for a length field. The older Ethernet standards use this as a type field for determining what protocol to use for the rest of the packet. Most IP networks these days are constructed using the old Ethernet interpretation regardless of what kind of transceiver they use. The difference between the Version I transceiver and the version II is the presence of the so called "heartbeat" signal or SQE. What this does is blip the collision detect line after each transmission. This is an added protection for detecting broken transcievers and cabling that may be jabbering on the net. The IEEE 802.3 transciever is similar to the Version II transciever, but has one additional signal state on the collision detect line for something like MAU (that's what they call the transciever) not ready. I'm not sure what anybody does with this (if anything). Of course, as stated earlier, the various standards call for different sizes of conductors and grounding considerations, although the essential signals conductors are the same. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111408351000> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Sat 14 Nov 87 14:02:05-PST To: William Westfield cc: tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM Subject: Re: ARP and various things other than ethernet.... In-reply-to: Your message of Fri, 13 Nov 87 13:27:27 -0800. <12350362501.9.BILLW@MATHOM.CISCO.COM> Date: Sat, 14 Nov 87 16:55:10 -0500 From: Mike Brescia isn't any reason why ARP can be used, more or less as-is, for any hardware network having a broadcast concept... .. or even any network with a distinguished, well known address, by which you reach the server(s) that store the address information. There is no philosophical need to have the data base distributed to the level that each host stores only that part of the data base that pertains to it. However, it definitely is convenient to have the host in charge of its own data. I just wanted to make the point that address FFFFFFFFFFFF is not magic, nor is broadcast. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [128@boake2.UUCP] <1987111410223300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: scott@boake2.UUCP (Scott Boake) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wanted: TCP/IP source Message-ID: <128@boake2.UUCP> Date: Sat, 14-Nov-87 15:22:33 EST Article-I.D.: boake2.128 Posted: Sat Nov 14 15:22:33 1987 Date-Received: Tue, 17-Nov-87 06:47:20 EST References: <857@quacky.UUCP> <309@clan.UUCP> Organization: Small Systems Consulting Lines: 22 Summary: I too would like a copy In article <309@clan.UUCP>, eugen@clan.UUCP (Eugen Bacic) writes: > I am also looking for the source for a complete PD TCP/IP implemention. > I would appreciate any information anyone regarding their experiences > with Phil Karns implentation. > > Eugen Bacic @ ..!utzoo!dciem!nrcaer!clan!eugen I am VERY interested in getting this type of software also. I want to try to hook up some of the less expensive Ethernet boards (ie. Western Digital) to other machines running TCP/IP, RFS, NFS, etc. If you have any software / technical notes / books / RFCs / etc. to point me in the directions please mail them! Or tell me where / how I may obtain them. (If they are books and you have the ISBN # handy, please include it. That makes ordering books MUCH easier!) Scott ---------- Scott Boake Small Systems Consulting +1 813 544 - 8152 P.O. Box 2142 5030 - 78rd Ave North Suite 10 ..!peora!codas!usfvax2!jc3b21!boake2!scott Pinellas Park, FL 34665 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711142103.AA01972@gcylab] <1987111411033600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stan@gcylab.UUCP (Generally useless individual) Newsgroups: comp.protocols.tcp-ip Subject: STD BUS Ethernet Card Message-ID: <8711142103.AA01972@gcylab> Date: Sat, 14-Nov-87 16:03:36 EST Article-I.D.: gcylab.8711142103.AA01972 Posted: Sat Nov 14 16:03:36 1987 Date-Received: Sat, 21-Nov-87 12:44:19 EST Sender: uucp@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 From: rpics!gcylab!stan (Stanfield Smith) 516-294-7170 Sorry if this is the wrong net for this subject, but I need help to locate a manufacturer of an ethernet card (similar to the 3C501) for my standard bus system. If anyone knows of such a manufacturer, I would really appreciate the information. At this point I will even settle for the name of someone who is merely thinking about offering such a product. Stan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711150035.AA03417@ucbvax.Berkeley.EDU] <1987111414362700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet routing problems Message-ID: <8711150035.AA03417@ucbvax.Berkeley.EDU> Date: Sat, 14-Nov-87 19:36:27 EST Article-I.D.: ucbvax.8711150035.AA03417 Posted: Sat Nov 14 19:36:27 1987 Date-Received: Sun, 15-Nov-87 20:24:17 EST References: <1527@faline.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Phil, I recommend that you get on the EGP-PEOPLE mailing list. Send request to 'egp-people-request@bbn.com'. Your problem first had a fix announced there a year ago February (that's 1986). I would have restricted this note to a private answer, but I want to suggest that anyone else reading TCP-IP and operating an EGP gateway get on the EGP-PEOPLE list also. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711150720.AA04413@gyre.umd.edu] <1987111421204400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telephone Access Controllers (TACs) and SLIP... Message-ID: <8711150720.AA04413@gyre.umd.edu> Date: Sun, 15-Nov-87 02:20:44 EST Article-I.D.: gyre.8711150720.AA04413 Posted: Sun Nov 15 02:20:44 1987 Date-Received: Sun, 22-Nov-87 08:43:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 From: dlw%opal.Berkeley.EDU@violet.berkeley.edu (David Wasley) ... The protocol would be to "log in" to the system (validation and all that) and be given an IP address & mask for the duration of the session. After that, it is all IP until carrier drops. Is there a well defined, documented protocol for this initial dialogue? Not as far as I know; but I had something like this in mind when I rewired Rick Adams's version of SLIP for 4.3BSD. That is why slattach waits `forever' in a sigpause(): to find out about carrier loss. If you are a client of some dialup IP server, you might want to redial automatically. (Those of you with 4.3BSD source can look at /usr/src/etc/slattach.c to see how the attach works. It should be easy enough to write dialup and protocol code that would run first.) How would you deal with dynamic name/address mapping? I will leave this one for others. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111503153500> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Sun 15 Nov 87 14:35:08-PST To: tcp-ip@sri-nic.ARPA cc: dlw%opal.berkeley.edu@violet.berkeley.edu, billw@mathom.cisco.com Subject: dial-up SLIP Date: Sun, 15 Nov 87 11:35:35 -0500 From: Craig Partridge At CSNET we're experimenting with an idea which is close to this. The basic idea is that when an IP packet hits our gateway destined for a remote machine we make a phone call, establish the link, and keep it running as long as there is continued traffic. When the traffic stops, we shut down the line. There are lots of nasty little problems in this scheme: - The TCP SYN takes a huge hit for establishing the phone call. So the initial RTT estimate will be much too high. - Topology. That SYN probably can't take multiple hops in which the phone gets dialed. (We're using a star topology with gateway in the center). - How to maintain line quality. We know how variable long-distance connectivity is. Interestingly, keeping track of when the line is busy probably isn't a problem (we already had to handle that problem in X25Net). Also note that this system is designed to support more than IP. We want to be able to use more than IP over the interface (line control packets, ISO IP, XNS, etc). So we had to put leaders in. Finally, address mapping is fixed. Each address is assigned, and we do a deterministic IP address to phone # mapping to do the phone call. We then log in at the remote end, and start up the line protocol. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111503180900> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Sun 15 Nov 87 08:54:12-PST To: "Michael J. O'Connor" cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Idle chatter about reference models In-reply-to: Your message of Fri, 13 Nov 87 20:53:39 -0500. <8711140153.AA09162@sccgate.scc.com> Date: Sun, 15 Nov 87 11:38:09 -0500 From: Robert Hinden Mike, I enjoyed you reference to HMP being in the "Massachusetts" layer. It might be more accurate to say that it is in the Massachusetts "stack" :-). I do think it is correct that is should be shown as a transport layer protocol. EGP, GGP, and other similar internet protocols provide services normally thought of as in the transport [, presentation ?] and application layers. The output of these protocols are used to provide routing data for the internet layer. I don't think that this puts them in the internet layer. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [11721@orchid.waterloo.edu] <1987111504362200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mshiels@orchid.waterloo.edu (Michael A. Shiels) Newsgroups: comp.protocols.tcp-ip Subject: Gateway protocols and RFCs and uses for them Message-ID: <11721@orchid.waterloo.edu> Date: Sun, 15-Nov-87 09:36:22 EST Article-I.D.: orchid.11721 Posted: Sun Nov 15 09:36:22 1987 Date-Received: Mon, 16-Nov-87 05:54:22 EST Reply-To: mshiels@orchid.UUCP (Michael A. Shiels) Organization: U. of Waterloo, Ontario Lines: 16 Does anyone have a table of the different gateway protocols and the appropriate RFCs for them?? And also a list of whos hardware/software uses the different ones. If some one can send me the RFC table I can compile a list of the hardware/ software based upon e-mail to me. I am trying to get some PC gateway software running and would like to implement any gateway protocol that is needed to interact with most other software. Thanx. -- Michael A. Shiels (MaS Network Software) mshiels@orchid.waterloo.EDU UUCP: ...path...!watmath!orchid!mshiels ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711151624.AA26353@uc.msc.umn.edu] <1987111506244800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: slevy@UMN-REI-UC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Telephone Access Controllers (TACs) and SLIP... Message-ID: <8711151624.AA26353@uc.msc.umn.edu> Date: Sun, 15-Nov-87 11:24:48 EST Article-I.D.: uc.8711151624.AA26353 Posted: Sun Nov 15 11:24:48 1987 Date-Received: Sat, 21-Nov-87 17:02:31 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Is dynamic IP addressing necessary? Rather than having the dialled-into system pick an address for its caller, how about if the caller asks for a particular IP address and authenticates itself with, say, a password? That same calling host would always ask for the same address. The name-address association could be permanent, only the connections would be temporary. Stuart Levy, Minn. Supercomputer Center slevy@uc.msc.umn.edu, 612 626 0211 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111509271100> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Sun 15 Nov 87 14:53:11-PST To: Robert Hinden cc: "Michael J. O'Connor" , tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM Subject: Re: Idle chatter about reference models In-reply-to: Your message of Sun, 15 Nov 87 11:38:09 -0500. Date: Sun, 15 Nov 87 17:47:11 -0500 From: haverty@CCV.BBN.COM To throw mny two cents in... I think HMP isn't "in the stack" at all, in the sense that it is NOT part of a user data communications activity. HMP is an application top level protocol, between an entity at one end, i.e., the monitoring/management operation, and an entity at the other end, i.e., the piece of code down within some computer somewhere that is watching the activity within that computer and interacting with the management site. IN other words, the participants in HMP are just like any other network users such as FTP or a data query and retrieval system; it just happens to be the case that their activity is associated with the operational management of a communications system. Consider for example if an HMP-like protocol were used to monitor the CPU-load and disk-activity of a distributed collection of Unix systems, i.e., like a constantly running remote "dpy" or "ps". In this case it's pretty clear that the protocol between the players is an application in itself; HMP differs only in that it is looking at the operation of components of a data communications system. Jack PS to Dave Mills -- I do "read the mail" on the list all the time, just a little slow in diving in. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711200139.AA05593@ucbvax.Berkeley.EDU] <1987111514230000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: IO71241@MAINE.BITNET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: INFO Message-ID: <8711200139.AA05593@ucbvax.Berkeley.EDU> Date: Sun, 15-Nov-87 19:23:00 EST Article-I.D.: ucbvax.8711200139.AA05593 Posted: Sun Nov 15 19:23:00 1987 Date-Received: Sat, 21-Nov-87 18:29:49 EST Sender: uucp@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 1 PLEASE SEND ME INFO ON TCP/IP PROTOCOL ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111514230001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sun 15 Nov 87 21:37:31-PST Received: from MAINE.BITNET by wiscvm.wisc.edu ; Sun, 15 Nov 87 23:36:56 CDT Received: by MAINE (Mailer X1.24) id 9708; Sun, 15 Nov 87 19:25:45 EST Subject: INFO To: TCP-IP@SRI-NIC.ARPA From: MIKE BEAL Date: Sun, 15 Nov 1987 19:23 EST PLEASE SEND ME INFO ON TCP/IP PROTOCOL ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1135@saturn.ucsc.edu] <1987111515112600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: eshop@saturn.ucsc.edu (Jim Warner) Newsgroups: comp.protocols.tcp-ip Subject: Terminal server efficiency Message-ID: <1135@saturn.ucsc.edu> Date: Sun, 15-Nov-87 20:11:26 EST Article-I.D.: saturn.1135 Posted: Sun Nov 15 20:11:26 1987 Date-Received: Tue, 17-Nov-87 06:06:15 EST Organization: U.C. Santa Cruz, CIS/CE. Lines: 27 Keywords: Bridge, TCP-window, terminal server How important is the offered TCP window size for Ethernet terminal servers? Our Bridge LS1 terminal server offers a maximum window size of 164 bytes. Our Micom terminal server offers a 384 byte window. The small window forces our computers to send a full screen update as many small packets instead of fewer larger packets. It seems to me that this is expensive in terms of CPU bandwidth both for the connected computer and any intervening gateways. What do people think? Is this important? Here's some data. I logged in to a 4.3BSD computer, read a 7 screen file (154 line, 10430 byte) with unix 'more' and logged out. In all cases the terminal baud rate was 9600. "Total packets" includes those necessary to log in and give the commands. Terminal software Max Offered Total packets attached to version rcv window (both ways) Bridge LS1 13000 164 481 Micom NTS-100 V1.3-AC 384 241 VAX 750 4.3BSD 4096 159 Our Micom NTS-100 is running software that is still in beta test. The production software offers a 320 byte window. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111521524600> Received: from MATHOM.CISCO.COM by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 05:52:24-PST Date: Mon 16 Nov 87 05:52:46-PST From: Kirk Lougheed Subject: Re: Terminal server efficiency To: saturn!eshop@JADE.BERKELEY.EDU cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <1135@saturn.ucsc.edu> Message-ID: <12351066161.6.LOUGHEED@MATHOM.CISCO.COM> Jim - The TCP maximum segment size, the number of data bytes that can be sent in a single TCP segment, probably dominates the efficiency considerations of the terminal server test you describe. When sending large amounts of data to a terminal server (display editors, parallel and serial printers), you want to have each TCP segment to be as large as possible. Window size would be of secondary importance. A reasonable default maximum segment size is 536 bytes (IP's "minimum maximum" of 576 less 40 bytes of IP and TCP header). If the two hosts are on the same physical cable, it is reasonable to negotiate a maximum segment size closer to the MTU of the cable. Such extremely small maximum segment sizes and offered window sizes probably indicate a lack of memory in the terminal servers. The ability to piggy-back acknowledgements is an even more important efficiency consideration for terminal servers. If you use Telnet with remote echoing and don't do piggy-backing, sending a single character packet results into two packets being sent back (the echo and the acknowledgment) which in return generates a responding acknowledgement. Four packets. If you can do piggy-backing, you can get the number of packets per character down to three (slow typist) or even two (fast typist). That assumes of course that you aren't employing some strategy to put more than one character per packet. I recommend reading Clark's RFC 813, "Window and Acknowledgement Strategy in TCP" for more details on how TCP implementations can be more efficient. That will allow you to ask all sorts of potentially embarrassing questions of your vendors. Regards, Kirk Lougheed cisco Systems, Inc. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111600132300> Received: from SUMEX-AIM.STANFORD.EDU by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 09:35:59-PST Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 16 Nov 87 09:33:17 PST Date: Mon, 16 Nov 87 08:13:23 PST From: Mark Crispin Subject: Re: Telnet options To: Welch%OSU-20@OHIO-STATE.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <8711102203.AA24154@tut.cis.ohio-state.edu> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12351091758.6.MRC@PANDA.COM> Arun - I have never seen those Telnet options, but I may have an explanation. The DEC-20 Telnet service as distributed by DEC (and earlier versions from BBN) has a number of bugs including some which may cause incorrect Telnet protocol to be sent. I wrote a long series of fixes for these bugs, but to my knowledge only STL-HOST1, SIMTEL20, and DREA-XX are running the full set of fixes. Other sites are running earlier, half-assed versions of these fixes or none at all. Most unfortunately, the authors of certain programs have decided to exploit certain of these bugs to intentionally send Telnet protocol from an application without Telnet service being aware of it. It's partially because of this problem that I've been unable to convince Stanford TOPS-20's to adopt these fixes. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711161034.AA14189@ucbvax.Berkeley.EDU] <1987111600345400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: TCP maximum segment size determination Message-ID: <8711161034.AA14189@ucbvax.Berkeley.EDU> Date: Mon, 16-Nov-87 05:34:54 EST Article-I.D.: ucbvax.8711161034.AA14189 Posted: Mon Nov 16 05:34:54 1987 Date-Received: Tue, 17-Nov-87 06:28:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Bruce, Last week I volunteered at the IETF meeting to write a proposal for just such an IP option. You should see it within a couple of weeks (seeing it implemented may take a while longer...) By the way, the scheme is sound even if the path changes if you treat the IP option and the TCP MSS values as distinct. I.e. in the TCP MSS you should advertise the maximum segment size you wish to accept and the remote end should keep this value and separately keep track of what IP reports. You would use the minimum of the two MSS's reported when sending. Then if you get an indication that the route has changed (such as an ICMP redirect), you can send the IP option again, and update the effective MSS (up or down). There's still the problem of packets following different paths -- this may have a solution but I'm still looking for something that doesn't feel like a kludge of a three way handshake. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711161048.AA14354@ucbvax.Berkeley.EDU] <1987111600492000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: new Arpanet end to end protocol Message-ID: <8711161048.AA14354@ucbvax.Berkeley.EDU> Date: Mon, 16-Nov-87 05:49:20 EST Article-I.D.: ucbvax.8711161048.AA14354 Posted: Mon Nov 16 05:49:20 1987 Date-Received: Tue, 17-Nov-87 06:30:11 EST References: <8711060720.AA24392@athos.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 61 Charles, Your message is quite wrong (I know - I designed the new End-to-End). I would be interested in knowing (in private) who your "reliable source" is, so that such rumors can be source quenched. After the recent messages on the tcp-ip list, I'm sure we all realize how important source quenching is. The truth of the matter is: PSN 7.0 has two different End-to-End protocols (old EE and new EE). Either one or the other runs at any particular time, and the two cannot interoperate. The ARPANET is currently using PSN 7.0 with the old EE. It is the new EE that will be tested on Nov. 7, 14-15, and 18. The old EE protocol explicitly returned, across the PSN subnet, a separate RFNM packet for each message delivered to a destination host. This RFNM packet was then converted, in the source PSN, into the 1822 RFNM for that message and delivered to the source host. This had the result that, depending on traffic mixes, roughly about 45% to 50% of the packets going through the subnet were RFNMs. Since the PSN does so much per-packet processing, even for these RFNMs, the network was passing much less host traffic than otherwise might be possible. We fixed this in the new EE by making it an explicitly windowed protocol IN THE SUBNET. The destination PSNs have the ability to aggregate ACKs (the new EE internal equivalent to RFNMs) and send multiple ACKs for the same connection in windowed ACK (by using an INTERNAL message sequence number). In addition, these ACKs can now be piggybacked on data traffic, and many ACKs for different EE connections can be shipped together in the same subnet packet to a source PSN. The important thing to note is that when the destination PSN receives an ACK for a connection, it generates, and sends to the source host, a separate 1822 RFNM for EACH and EVERY message submitted by the host and being acknowledged by the ACK. There are no host-visible sequence numbers; the 1822 protocol stays the same as before. What may have confused you is the fact that we at BBN are, concurrent with the PSN 7.0 testing, trying to track down which ARPANET hosts might be affected by a known BSD 4.2 network software problem that may cause RFNMs to be lost in the host itself (I believe it is related to the size of the message received PREVIOUS to the RFNM). This bug has been fixed in BSD 4.3, and I have been told that Lars Poulsen of ACC (lars@acc.arpa) has a patch for BSD 4.2-derived host software. By the way, we have measured in our internal BBNNET (which has been running PSN 7.0 with the new EE only for over five months now) that only about 14% of the packets through the network only contain ACKs - the rest of the ACKs are being piggybacked on the data traffic. We are very pleased with this result. Also, most of our BBNNET hosts (around 125 C/70s, VAXEN, TOPS-20s, TACs, and others) use 1822, and they have had no problems with the new EE. Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111602064300> Received: from violet.berkeley.edu by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 10:08:59-PST Received: from localhost.ARPA by violet.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17l) id AA04336; Mon, 16 Nov 87 10:06:45 PST Message-Id: <8711161806.AA04336@violet.berkeley.edu> To: Arun Cc: tcp-ip@sri-nic.arpa Subject: Re: Telnet options In-Reply-To: Your message of Tue, 10 Nov 87 16:55:23 -0500. <8711102203.AA24154@tut.cis.ohio-state.edu> Date: Mon, 16 Nov 87 10:06:43 PST From: minshall@violet.Berkeley.EDU Arun Welch, I don't know what the options are. I suspect they were invented by your Dec box. That the Dec box would invent an option is a bit depressing; however, that your Xerox box should die when presented with an unknown option is even more depressing. The standard response to DO FOO (where FOO is unknown) is WONT FOO - and that should be the end of that. Greg Minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111602593100> Received: from nisc.nyser.net by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 08:20:06-PST Received: by nisc.nyser.net (5.54/1.14) id AA08883; Mon, 16 Nov 87 11:19:34 EST Message-Id: <8711161619.AA08883@nisc.nyser.net> To: Mark Fedor Cc: nsfnet@nnsc.nsf.net, tcp-ip@sri-nic.arpa, caloccia@nisc.nyser.net Subject: Re: Strange returned mail. In-Reply-To: Your message of Sat, 14 Nov 87 21:35:14 -0500. <8711150235.AA27649@nisc.nyser.net> Date: Mon, 16 Nov 87 11:19:31 -0500 From: caloccia@nisc.nyser.net my guess is that it is an expansion of some list that 's gone bad. the site looks like NTA in Norway (nta.no) -- my guess would be tcp-ip. --bill I just received about 7 messages like the one that follows. I'm clueless as to why I got them. I never tried to send to this place. Is this another one of those unsolved network mysteries? Any answers? clues? Thanks. Mark ------- Forwarded Message Return-Path: postmaster%odin.re.nta.uninett@TOR.NTA.NO Received: by nisc.nyser.net (5.54/1.14) id AA08642; Fri, 13 Nov 87 12:13:14 EST Date: Fri, 13 Nov 87 16:43:08 +0100 Posted-Date: Fri, 13 Nov 87 16:43:08 +0100 Message-Id: <8711131543.AA10354@tor.nta.no> Received: by tor.nta.no (5.54/3.21) id AA10354; Fri, 13 Nov 87 16:43:08 +0100 To: fedor@nisc.nyser.net From: UNINETT-ARPA Gateway Subject: EAN Mail Network -- failed mail Status: RO Mail Failure Diagnostics: Rejected-Message-id: <8711060340.AA17823@nic.nyser.net> Message Recipients: baard@vax.elab.unit.uninett: maximum time expired ------- End of Forwarded Message ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111603475200> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 06:49:37-PST Received: from UNLCDC3.BITNET by wiscvm.wisc.edu ; Mon, 16 Nov 87 08:48:41 CDT Message-ID: <871116084752.00002E3A.AGYK.AC@UNL3.CRC> (UMass-Mailer 4.03) Date: Mon, 16 Nov 87 08:47:52 CDT From: MARK%UNLCDC3.BITNET@wiscvm.wisc.edu (Mark Meyer, UNL Computing Resource Center (402)472-5434) Subject: Post offices for PCs in a network To: tcp-ip@sri-nic.arpa I am interested in solutions to the problem of have a bunch of PCs on our campus local net which want to send and receive mail. Obviously, they should send mail to some server (or post office) and receive mail back from it. I know that POP exists and there are some other ad hoc solutions. Can anyone write up a concise but systematic description of the current and most feasible solutions, please? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111604190000> Received: from MEAD.SCRC.Symbolics.COM ([128.81.41.234]) by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 06:20:48-PST Received: from SWAN.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110715; Mon 16-Nov-87 09:19:57 EST Date: Mon, 16 Nov 87 09:19 EST From: David C. Plummer Subject: Re: ARP on FDDI To: Kastenholz@MIT-MULTICS.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: <871109225730.962725@MIT-Multics.ARPA> Message-ID: <19871116141920.8.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 9 Nov 87 17:57 EST From: Kastenholz@MIT-Multics.ARPA There is a rather simplistic solution to the 16 vs 48 bit FDDI address problem - assign two physical hardware types to FDDI - one for 16 bit addresses and one for 48 bit addresses. This may violate some underlying deep philosophical intent of ARP, but it looks like it should work. If being the author of ARP means anything after four years... The type hardware types sounds completely reasonable to me. From the scant readings I've seen about FDDI, it seems that there are really two distinct versions (one with 16 bit addresses and one with 48) and they cannot coexist on the same cable, lest they confuse each other. Even if they do/could coexist, I see no reason they shouldn't be considered separate for the purposes of ARP hardware type. It is also possible and allowable to dispatch off of both the hardware type and the hardware length, provided there is only one possible semantics after the last dispatch. I suspect many implementations, including the ones I've written, only dispatch off of the hardware type and check the length for consistency. From this 5 minutes of thought, I would opt for two hardware types, perhaps called FDDI-16 and FDDI-48. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111605120000> Received: from MIT-Multics.ARPA by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 07:15:13-PST Date: Mon, 16 Nov 87 10:12 EST From: Kodinsky@MIT-Multics.ARPA Subject: Re: ARP on FDDI To: Kastenholz@MIT-Multics.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message of 9 Nov 87 17:57 EST from Kastenholz Message-ID: <871116151227.662343@MIT-Multics.ARPA> Hi Frank, I got some replies to my question. They reminded me that the ARP message uses variable length fields ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111605180000> Received: from MIT-Multics.ARPA by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 07:32:41-PST Date: Mon, 16 Nov 87 10:18 EST From: Kodinsky@MIT-Multics.ARPA Subject: Re: ARP on FDDI To: Kastenholz@MIT-Multics.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message of 9 Nov 87 17:57 EST from Kastenholz Message-ID: <871116151838.416189@MIT-Multics.ARPA> Hi Frank, My terminal died in the middle of the last attempt. What people told me was that there is a length field in the ARP message format. And that ethernet also has a 16 and 48 bit address length. Anyway I found out that ARP is an expected thing in the TCP world. Thanks for your note, Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111605324300> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 09:17:12-PST Received: from VTVM1.BITNET by wiscvm.wisc.edu ; Mon, 16 Nov 87 09:35:47 CDT Received: by VTVM1 (Mailer X1.24) id 8734; Mon, 16 Nov 87 10:36:14 EST Date: Mon, 16 Nov 87 10:32:43 EST From: John Owens Subject: Re: ARPANET<->MILNET problems To: TCP-IP Discussion List In-Reply-To: Message of 6 Nov 87 05:18:57 GMT from >I have had a very similer problem making contact to a host inside >of the berkeley network. Same horrible round trip times and >loss rates. It puzzles me because our contact with ucbarpa and >ucbvax (both arpa sites) is fine, but the contact with the site >inside the berk-net is rotten. >Perhaps related: I also have not been able to make contact with >univ. of Wisc hosts, yet have easy contact with cs.wisc.edu. >(again directly on the arpanet) It definitely looks like a routing problem, since the networks you can't reach (internal campus networks) have high numbers, and the hosts you can reach are on the low-numbered ARPANET (10). It's as if the core gateways are only keeping routes for a certain number of networks. (Possibly the ones you can't reach are in the new second fragment of the EGP update, as mentioned earlier....) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111605525600> Received: from IBM.COM by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 10:38:50-PST Date: 16 November 1987, 10:52:56 EST From: Jacob Rekhter To: tcp-ip@sri-nic.arpa Message-Id: <111687.105257.yakov@ibm.com> Subject: Node updates versus Link updates I'd like to solicit some comments on the following issue: "What are the advantages/disadvantages of using both Node State Updates and Link State Updates versus using just Link State Updates for Adaptive IP Routing ?" Notice, that I do not propose to completely ignore all metrics associated with a node, but rather to reflect conditions on the node in Link State metrics. Many thanks in advance for all who will reply. Jacob Rekhter (YAKOV@IBM.COM) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111606192200> Received: from d.NYSER.NET ([128.213.1.100]) by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 08:20:06-PST Date: Mon, 16 Nov 87 11:19:22 EST From: fedor@d.nyser.net (Mark Fedor) Received: by d.NYSER.NET (5.54/1.3-NYSERNet-NISC) id AA00976; Mon, 16 Nov 87 11:19:22 EST Message-Id: <8711161619.AA00976@d.NYSER.NET> To: atina!mrecvax!tron@uunet.uu.net, tcp-ip@sri-nic.arpa Subject: Re: ICMP redirect messages. How to send ? Hi. If I remember correctly, while poking through the Ultrix Networking code, there is no support for ULTRIX 1.2 (and I think 2.0) to SEND ICMP_REDIRECTS. Although you could hack it in, I suppose, but if you are going to do that you might as well go 4.3BSD.... Good Luck.... Mark Fedor NYSERNet, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7882@steinmetz.steinmetz.UUCP] <1987111606310400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: montnaro@sprite.steinmetz (Skip Montanaro) Newsgroups: comp.protocols.tcp-ip Subject: Re: Life after source quench Message-ID: <7882@steinmetz.steinmetz.UUCP> Date: Mon, 16-Nov-87 11:31:04 EST Article-I.D.: steinmet.7882 Posted: Mon Nov 16 11:31:04 1987 Date-Received: Wed, 18-Nov-87 04:29:36 EST References: <8711091811.AA23668@uxc.cso.uiuc.edu> Sender: root@steinmetz.steinmetz.UUCP Reply-To: montnaro@sprite.steinmetz (Skip Montanaro) Organization: General Electric CRD, Schenectady, NY Lines: 24 In article <8711091811.AA23668@uxc.cso.uiuc.edu> kline@uxc.cso.uiuc.EDU (Charley Kline) writes: >I'm sure that the reason that the fuzzball is issuing quenches every >thirty seconds is because if only one quench is sent, IP throttles back >to one packet every 500 milliseconds (which should keep the fuzzball >happy), but when the 30 second quench reaction stops, IP starts >vomiting the packets full blast again, which causes another quench. I'm >pleased that the quench mechanism creates such effective data rate >communication between an IP module and IP gateways. > >I can't take credit for the method, it's an implementation of Postel's >proposal. I only messed with the parameters. I'm no whiz at anything related to TCP/IP (although I find this group interesting, if not necessary, reading), but this seems like a situation that calls for either 1. Some hysteresis. Is it wise (correct?) to have the start quench and stop quench thresholds be the same? 2. Finer granularity. Given the rate at which most machines can spew out packets, 500 milliseconds sounds rather coarse. Skip (montanaro@ge-crd.arpa or uunet!steinmetz!sprite!montanaro) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [620@applix.UUCP] <1987111606313200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@applix.UUCP (Mark Fox) Newsgroups: comp.unix.questions,comp.protocols.tcp-ip,comp.dcom.lans Subject: STREAMS pipe driver Message-ID: <620@applix.UUCP> Date: Mon, 16-Nov-87 11:31:32 EST Article-I.D.: applix.620 Posted: Mon Nov 16 11:31:32 1987 Date-Received: Wed, 18-Nov-87 06:33:20 EST Distribution: na Organization: APPLiX Inc., Westboro MA Lines: 23 I just heard about this beast from someone with SVR3 sources. Apparently, AT&T implemented this as a replacement for FIFOs but in their wisdom decided not to document it. Since we have processes that communicate with other processes on the same machine as well as with others on remote machines, we need the equivalent of Unix-domain or loop-back sockets. As you might expect, we need to be able to multiplex input from local and remote processes. Now an idle process could pend reading its FIFO and field SIGPOLLs. But a "more elegant" approach, it would seem, is for a process to pend on a blocking select (er, poll :-) system call awaiting messages from any process, local or remote, that wants to talk to it. This is where a STREAMS pipe driver fits in. Is the latter approach reasonable? Are people porting the pipe driver? Is anybody willing to provide me with or post documentation on how to use it? I have the Streams Programmer's Guide but I don't have a Unix source license :-( Thanx! -- Mark Fox Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300 uucp: {ames,rutgers}!harvard!m2c!applix!mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111606514700> Received: from UDEL.EDU by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 09:24:32-PST Received: from huey.udel.edu by Louie.UDEL.EDU id aa11803; 16 Nov 87 11:57 EST Date: Mon, 16 Nov 87 11:51:47 EST From: Mills@UDEL.EDU To: "James B. VanBokkelen" cc: tcp-ip@sri-nic.arpa Subject: Re: TCP maximum segment size determination Message-ID: <8711161151.aa24800@Huey.UDEL.EDU> James, SATNET MTU = 256 octets last I heard. Some packet radio systems have MTU a few octets less than this. I know of no system with MTU of 128 octets. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111606562900> Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 14:56:48-PST Received: from bel.isi.edu by venera.isi.edu (5.54/5.51) id AA11439; Mon, 16 Nov 87 14:56:33 PST Date: Mon, 16 Nov 87 14:56:29 PST From: postel@venera.isi.edu Posted-Date: Mon, 16 Nov 87 14:56:29 PST Message-Id: <8711162256.AA00262@bel.isi.edu> Received: by bel.isi.edu (5.54/5.51) id AA00262; Mon, 16 Nov 87 14:56:29 PST To: tcp-ip@sri-nic.arpa Subject: re: telnet options ----- Begin Forwarded Message ----- Date: Tue 10 Nov 87 16:55:23-EST From: Arun Subject: Telnet options To: tcp-ip@sri-nic.arpa Could someone tell me what telnet options 32 and 94 are, and which RFC's are associated with them? We've got a host (a dec-20 running tops) which is returning them, causing my workstatio (a xerox 1186) to lose... I couldn't find them anywhere in Assigned Numbers or in the DDN Handbook. ...arun ----- End Forwarded Message ----- There is no authorized use of Telnet option codes 32 or 94. However, your workstation should not "lose". It should be able to decline any telnet option it does not understand, even if that option is not previously known. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111606575600> Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 14:58:18-PST Received: from bel.isi.edu by venera.isi.edu (5.54/5.51) id AA11476; Mon, 16 Nov 87 14:58:00 PST Date: Mon, 16 Nov 87 14:57:56 PST From: postel@venera.isi.edu Posted-Date: Mon, 16 Nov 87 14:57:56 PST Message-Id: <8711162257.AA00264@bel.isi.edu> Received: by bel.isi.edu (5.54/5.51) id AA00264; Mon, 16 Nov 87 14:57:56 PST To: tcp-ip@sri-nic.arpa Subject: datagram vs reliable By definition a "datagram" can not be reliable or guaranteed. See the Introduction section of the Internet Protocol specification, RFC-791. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111607003600> Received: from nswc-g.ARPA by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 09:01:14-PST Date: Mon, 16 Nov 87 12:00:36 est From: vwhite@nswc-g.ARPA To: BIG-LAN%SUVM.BITNET@wiscvm.wisc.edu, TCP-IP@sri-nic.arpa, cdaniel, cdjohns@k30b, dfutche, drose, snorthc Responses to Request for Information 13 November 1987 A couple of months ago, I sent out a request for information about PC networking software that would link IBM AT compatibles with Unix minicomputers over TCP/IP. Responses are still coming in to that request. However, here is a synopsis of the replies to date. Based on our research, to which these replies greatly contributed, we are leaning toward a NetBIOS solution, with 386s running Xenix and minicomputers running Unix variants as servers. We are looking at NetBIOS over TCP, but intend to investigate NetBIOS over OSI in the future. We now testing several products in house; should the test results prove unsatisfactory, we will probably recommend Sun's NFS as a fallback solution. We've heard several opinions, some of which we can't quote here, that NetBIOS has a highly questionable future. However, we have seen a great number of vendors providing NetBIOS based applications software and NetBIOS over TCP boards. Many vendors are working on RFC (1001, 1002) compliant versions of their products. We know that the Air Force ULANA procurement for Unix systems requires a NetBIOS interface be provided within one year of award. We know of both baseband and broadband boards which support NetBIOS, giving us greater latitude in our implementation. We've also heard opinions that users won't really be happy with a virtual drive, as they need the pure DOS environment for some applications and the pure Unix environment for others. Those who espouse this belief prefer to connect the environments with telnet and ftp. We agree that this might be the best for some situations, especially in scientific and engineering communities. In fact, most of those who liked this solution were operating in exactly that kind of environment. However, our community consists of a large number of business users who don't have much computer experience and don't have the time or inclination to learn a complex user interface. Our direction is to find something as transparent as possible for them. With that direction, we are continuing the quest for the virtual drive. We are also still following up on replies to our original posting and on other leads. We welcome further input and will post a second synopsis later if there is sufficient interest. Thanks to all who contributed. Vicky White vwhite@nswc-g.arpa 703-663-7745 ----------------------------------------------------------------------- From suneast!hinode!geoff@Sun.COM Thu Sep 10 13:38:53 1987 You need to talk to us about PC-NFS. It provides: Transparent file sharing using NFS, currently supported on Sun, Pyramid, VAX and many other systems. Transparent print service, including access from existing applications. Telnet, FTP, rsh and rcp utilities. Use of TCP/IP over IEEE802.3. Ethernet cards supported currently are the 3Com 3C501, U-B NIC and Micom-Interlan NI5010; others are to be added in the next release. There is also a Programmer's Toolkit which provides full emulation of the 4.2BSD network programming environment (TCP & UDP sockets) plus Sun RPC/XDR and Yellow Pages. Geoff Arnold PC-NFS Architect Sun Microsystems East Coast Division 2 Federal St. Billerica MA 01821 617-671-0317 ARPA: garnold@sun.com ----------------------------------------------------------------------- From usrey@gold.bacs.indiana.edu Fri Sep 11 16:14:28 1987 At indiana Unuversity we have a broadband cable plant that joins most of the buildings on a very large campus. We have an ethernet channel on that system that attaches mosts mainframe and mini's along with most PC LANs. The mini's are mostly vaxes with Ultrix or VMS and the PC LANS are mostly ethernet based running Novell. The PCs on the lans can access the hosts via tcpip programs OR attach to a Novell server but is isnt too smooth switching between the two applications. If you would like more detail regarding our network then feel free to contact me. Terry R. Usrey usrey@gold.bacs.indiana.edu ------ ----------------------------------------------------------------------- From @wiscvm.wisc.edu:TS0400@OHSTVMA.BITNET Thu Sep 10 16:20:24 1987 We are solving this problem as follows. Banyan servers are connected to PC Lans, via either ethernet or token ring (both are supported). The servers provide a very friendly user interface, and transparent file and print access. The internal Banyan mail is not smtp-compatible, but we have contracted with them to provide an smtp gateway function in the server that will act as a post office and hold all PC mail until needed. That will be available to us for testing in about 2 months, and after we accept it, Banyan will sell it to everyone. In the meantime, tcp/ip software from FTP, Inc can be put in the PCs which supports smtp,ftp and telnet directly to the PC, with the server acting as a passthru device. The server is connected to the existing tcp/ip ethernets we have, on a separate port from the PC LAN. FTP, inc software will be RFC compliant in the near future. Banyan will be integrating it into their product more in the future so that FTP and Telnet will also be transparent eventually and ftp, inc software will no longer be required on each PC. Bob Dixon Ohio State University ---------------------------------------------------------------------------- >From pcip-request@louie.udel.edu Thu Sep 17 16:37:54 1987 remote from nswc-g Banyan says that in a few months their server will provide tcp/ip functions to PC users on the LAN as if the users were on a mainframe. The server has a single IP address, and maps Banyan-style operations into tcp/ip operations when dealing with the outside world. For example, users create mail with the normal Banyan-specific menu syntax, etc but when required by its address, the mail is forwarded by the server to the internet as smtp. Incoming mail carries the internal Banyan address as the "user" portion and the server adress as the "host" portion of the internet mail address. The server acts as a post office and holds the mail until requested by a PC user. Bob Dixon Ohio State University ------------------------------------------------------------------------- From @WISCVM.WISC.EDU:TS0400@OHSTVMA.BITNET Fri Oct 2 16:02:36 1987 It is true that the Banyan server talks to the PCs using VINES protocol, over either ethernet or token ring. However, as seriees of developments will incorporate tcp/ip into that. 1. As of today ( I have it running in my own PC ) you can buy a version of FTP, Inc tcp/ip PC software which will coexist with VINES. That means that the server can be connected to an external tcp/ip network and the PC user can use the FTP, Inc software for telnet, ftp, etc just as if he were not in a Banyan network at all. It is not integrated into the Banyan menus, etc but it works fine. 2. You can buy (and we are, but don't have it yet) a program called LAN SHELL that enables the FTP stuff to be incorporated into the menus. 3. Banyan says they are incorporaring the FTP software into the server so that individual copies of FTP stuff would no longer be needed. Supposedly this year, but who knows for sure. A medium size Banyan supports about 25 users. They have 4 sizes for all needs. I have heard about the VAX plan and it sounds great, but nothing concrete yet. I can communicate fine with VAXes now with the tcp/ip software, but that does not give shared files, etc as the VINES thing would. Bob ---------------------------------------------------------------------------- From @wiscvm.wisc.edu:BEAME@MCMASTER.BITNET Wed Sep 16 11:54:21 1987 Hello, NetBios IS the way to go for current PCs, but I have been talking to IBM about the network interface in OS/2 and they responded that they still don't know what communications are going to look like in the extended OS/2. NetBios over TCP/IP is the way to go. Bridge Communications (now part of 3Com corporation) has a PC board (PCS-1) which has TCP/IP, TELNET and RFC1001, RFC1002 compliant NetBios. This solves everything but the mail problem. I beleive the RFC for PC mail can be easily implimented and interfaced to the TCP/IP available on the PCS-1 card as well as on a unix or Ultrix system. My firm is also working on an RFC compliant NetBios which uses the 3Com EtherLink board. If you have time to wait, several companies are currently working on compliant NetBioses. But as to an OS/2 version, only time (about 1 year) and IBM will tell. Carl Beame Development Analyst, McMaster University BEAME@MCMASTER.BITNET ---------------------------------------------------------------------------- I realize that this is long after the fact but maybe this will be useful. I manage end-user computing activities at DARPA and have (over the past two years) been through an evaluation and procurement process to put all DARPA personnel on a local net gatewayed to the Internet. The system we chose is currently being installed. We chose 3Com hardware and 3+ software although developments between the time the RFP was drafted (approx. one year ago) and now would lead me more towards something that I would expect to mature into a true NETBIOS over TCP/IP product. Deciding when to freeze specifications was the toughest part of the procurement, in retrospect it would have been better to have been more general in our specification to take advantage of developments that occurred during the procurement cycle. As part of the procurement we specified an optional 3Com <-> Internet gateway. This has been proposed but there is an associated development cycle, it should be delivered around Feb. 1988. The proposed solution looks like it might work (Wollongong on a Microvax) but I am withholding judgement until I see it. We chose 3Com primarily because of Mac support in addition to PC support and ethernet, we would have rather had something based on the DoD protocol suite, of course, but could not find any commercial offerings. Our user base is approximately 120 PC's and 50 Macs, the Macs population is growing faster than the PC population although we passed one workstation per user (some have both and we also have users who have machines at home) some time ago. We had an existing IEEE 802.3 cable plant and that influenced our decision heavily (it is already gatewayed to the Milnet and Arpanet). Also, money was not so much an issue as capabilities and speed. I would be happy to give you more details on the things we have found if you would like, I am not certain that a system the size of ours can be scaled to one twenty times its size but it seems like your objectives are similar to ours. Let me know if I can provide additional information. Glen Foster ---------------------------------------------------------------------------- From vwhite@nswc-g Thu Oct 1 10:11:14 1987 Glen, Thank you very much for your information. I think your situation is very similar to ours, despite the difference in scale, and you may be able to give us some useful advice. You said you wish you had something that would evolve into a NetBIOS over TCP implementation. Why do you want this instead of one of the nonNetBIOS products now available, like pcnfs or PC-Interface from Locus? Do your applications really need the NetBIOS interface? What are the advantages of NetBIOS? Do you think it is the up and coming standard and will win out over competitors like nfs or pc-interface? We just aren't very clear on these questions and would like to have the opinions of somebody else who's been there. I realize that pcnfs, at least, was not available when you made your purchase, but if you were doing it today, what would you do? Are your PCs clustered closely together or spread out over a wider geographical area? How many do you put on one 3com server? Do you just use the 3com mail program? Will your gateway transfer that to internet mail? We already have a lot of minicomputers using smtp and must have a way to get the PCs to talk mail to them from the outset. Thanks for the help; I think we can learn a lot from you. If it would be easier to talk about it over the phone you can give me a call or send me your number. Vicky White (703) 663-7745 vwhite@nswc-g.arpa ---------------------------------------------------------------------------- From gfoster@vax.darpa.mil Thu Oct 1 19:06:03 1987 Vicky, I hope I can remember your questions, my main mail box is on a.isi.edu but they are flakey and went down in the middle of my reply (twice!) I think NETBIOS will be big (if OS/2 is big), I have seen a couple of nice applications running on PC databases over NB (dBASE and Paradox). When NB servers become multi-tasking in a standard way (OS/2) I think we will see more developers writing applications that are truly distributed. 3Com has stated that they are moving in that direction, I met with them this morning and learned a good bit -- the bad news is that they are not going to do much with TCP/IP on PC's. I have PC-NFS on my desktop PC (actually an AST Premium 286) and have been using it more lately than 3+. I am becoming more and more UNIX oriented though and can not be considered an average user. It has some bugs that may make it difficult for non-technical users. We are all in one building, spread out between floors and have a thick cable ethernet running in the phone closets from the first floor to the twelfth (where the computer room is). (We actually have two running parallel but that is another story.) To hook up the PC's, we are using thin cable segments repeatered to the trunk, like: PC PC | | ----T------------------- | R | ======T======================T================================== | | R PC | | | ---------------------T-------- T = transceiver, R = repeaters, PC = you guessed it We hope to get away with no more than two thin segments per floor but are pushing it on the length spec. The servers will be cabled to the trunk with their own transceivers and xcvr cables so that if a user trashes his cable he doesn't take down the whole net. We have found some repeaters that will automagically isolate either side of the cable if it is shorted or open. (American Photonics) We have had some embarrassing outages using Xerox repeaters when the thin cable was accidentally opened. These were reasonably easy to diagnose and repair but we only had three segments, it would be a real pain if we had a lot of places to look. Ethernet attachment hardware is a joke, both thin cable and transceiver cable attachments are major headaches and can easily be detached by a vacuum cleaner or curious user. (I know how to handle this, it's just like my VCR!) We are figuring 10-12 users per 3Server (u/3S), we want very high performance and aren't as concerned about the cost. If we were worried about the cost I would go to 20-25 u/3S in our environment (mostly office automation -- word processing, spreadsheets and communications) and I think we could handle up to 40 u/3S if we had to and still have reasonable hard disk response. By reasonable I mean about as fast as an XT hard disk or maybe a little faster. If I were putting hefty dbms applications on, I would start at 4-6 u/3S and add them one at a time until we got a problem. I would definitely get the cache card with more than 15 u/3S (and probably will anyway). I would never, ever try to use a concurrent workstation/server, Ctrl-Alt-Del is too ingrained in PC users' minds. The mail gateway is supposed to take mail intended to go off-site and format it to RFC821/RFC822 etc. specs and then dump it back on the ethernet where it will be picked up by the gateway. Locally we will use 3+ mail and 3+Mac mail with hoped-for user transparency. Sure hope it works . . . I forget your other questions, give me a call if you want (703) 527-1451. If you ever get up to D. C. you are welcome to stop in and see how we have things laid out. The installation should progress now through Nov. 20th. We took a trip over to the Census Bureau early on in our evaluation and it was very enlightening. NSF is also scoping out PC nets and you might be able to get some pointers from them. Good luck, Glen ---------------------------------------------------------------------------- notes from phone coversation with Glen Foster 10/5/87: Reiterated that 3com was chosen primarily for Mac connection; also, they seemed most agreeable to customizing to Darpa's environment. He says Novell gave lip service this but wouldn't really get down to brass tacks; his opinion is "Novell is market driven company, 3Com is technology driven" (have we heard that somewhere before?) Says NFS and similar products which have come down to PCs from minis don't take advantage of all the features of a pc; tend to treat them like dumb terminals; ignore alt key, function keys; also require more knowledge and sophistication from user; products which originate from PC side are more PC user friendly, but don't always provide services desired (like ftp or smtp) Their vendor (Management Systems Designers of Vienna) is going to provide an smtp gateway for them (in 90 days); they'll use 3Com mail on the lan He suggested we talk to Census Bureau and NSF for further ideas. I attempted to contact both but have been unsuccessful so far. -vew ----------------------------------------------------------------------- From as-pln-bf@HUACHUCA-EM.ARPA Fri Oct 9 18:51:51 1987 You might be able to get the info you are looking for from the engineers that are at the Army Small Computer Engineering Center (SCEC). They are very sharp on networks etc. Their DDN address is USASCEC 'at' SIMTEL20.ARPA. ----------------------------------------------------------------------- From USASCEC@SIMTEL20.ARPA Wed Oct 28 12:42:56 1987 Sorry for the late response - most of our folks have been TDY. I'm afraid that we're not going to be able to provide much help to you, since we preach the use of OSI standards - right now we're using TP4 instead of TCP/IP, and we are not going back. If you want to know how to do what you intend to with TP4, we can tell you more. Basically, we support MS-NET protocols on 802.3 LANs, using PC hardware from either Ungermann-Bass or Intel. We have XENIX (Intel 310/320) and UNIX(Sperry 5000/80) based servers, implementing the Intel developed OpenNET protocols(compatible w/ MS-NET). Our servers have the capability to connect to the DDN (X.25) and SNA world. The most important detail is that all the above equipment is available from standard Army contracts. Also, the next major office automation procurement will be for systems that connect to that same LAN. The Navy and DLA are going in with us on that one, so although it will be an Army contract, it looks as if ALL DoD agencies might be able to order from it. In case you don't know about it, the AF tends to support TCP/IP protocols. You might check with them if you're stuck with that. -- CPT David Anselmi AV 879-8247/7450 -------------------------------------------------------------------------- notes from phone conversation with David Anselmi 9 Nov 87 They have Intel's OpenNet, which is Netb on iso; PCs can be file and print servers, though for performance not recommended; for servers they are using the Intel 310 (a 286 system) and 320 (a 386); says with their workload, he recommends no more than 8 users to a 386 server, though it's supposed to support 12. has virtual drive; virtual terminal service; file upload/download; can use menu interface for all interaction, including system administration; performance good except he doesn't like the menu interface and prefers to use direct commands for mail they log into the server over ethernet or rs232; mail available only to and from the servers; technically feasible to do it to PCs, but they didn't; no SMTP; OpenNet mail; have run network DBASE III over this and it's okay; hasn't tried other NetBIOS networks here (like IBM PC Net or Network OS) but thinks they ought to work no mac support They are hoping to buy minicomputers: Sperry 5000/880, to support up to 64 users; no advance info on actual performance; (note: requiring POSIX conformance there); will run Unix V.2 with OpenNet; not yet available. Minis should service PCs just like their Intels. award expected sometime 88 (June-Aug-Sept); other DoD may be able to buy off it. now have a Sperry 5000 which is their DDN gateway for ftp and telnet; working on mail interface; also have a tcp, ddn gateway on an Intel 320; this Intel can also support a tcp lan in addition to the iso lan; not going to specify x.400 yet; will do it later tcp to iso companies: 1)Retix, Santa Monica 2)Sydney, Vancouver ---------------------------------------------------------------------------- From mcc@etn-wlv.eaton.com Fri Sep 11 10:14:41 1987 Vicky, Dan, et. al.: If you can get access to the Request For Proposal (RFP) and the vendor propos- als for LONS, RAPIDE, UTAIN/MAIS, and ULANA; you may find some of the answers to the questions that you have raised. LONS and its predecessor LONEX (Local Office Network Experiment) are probably more in line with what you want to do. LONEX has been operational since the early 80's at Rome Air Development Center (RADC), Griffiss AFB and has links to and facilities at Hanscom Field and Wright-Patterson AFB. This message is being generated from home on a Tandy 2000 linked to the LONEX development and maintenance network at EATON IMSD in Westlake Village, CA which is also linked into RADC-LONEX.ARPA. LONEX was originally designed for a broadband with dedicated links to Hanscom and Wright-Patterson; however, the broadband has been replaced with Ethernet and the dedicated links are being replaced by the MILNET. The original plan was to support a large number of users using VT100 or VT100 compatible term- inals; however, that is also changing with many of the organisations using LONEX replacing them with PC's. PC's are not as fully integrated as you would like and generally use terminal emulation packages to interface with the network. I, personally, use the Softronic's SoftermPC package on which I have implemented a seamless disk capability so that disks on the network look like local hard disks to my PC. I can tell you from experience it can be painful--applications developed for MS-DOS choke if you have to use UNIX pathnames to get to your data. For some silly reason they attempt to parse switches whenever they see a "/". Anyway, the LONEX system runs on anything that can run on any processor that supports 2.9bsd or 4.3bsd. It goes "boom" on System Vanilla. It supports several of the more popular spreadsheet programs and databases and depending on the size of your spreadsheets moves the processing to more appropriate machines. Users in essence always execute from their home processor regard- less of where they may be and for the most part its transparent to the user. If you normally work at Hanscom but are temporarily at Wright Patterson, you may notice some latency. (This feature is probably the biggest reason why there hasn't been a stronger hue and cry for more fully integrating PCs into the system. As long as you can get to a TAC, you can work on your reports from anywhere in the world. You don't have to lug the PC along and if you're forced to fly commercial, you avoid the hassle at customs where they try to extract the import duties on your PC). Enough this. Request a tour and briefing from RADC to determine if it is useful and to find the pitfalls. Merton Campbell Crockett mcc@etn-wlv.eaton.com AN/GYQ-21(V) Program mcc%lonex@etn-wlv.eaton.com EATON Information Management Systems 31717 La Tienda Drive, Box 5009 Westlake Village, CA 91539 ---------------------------------------------------------------------------- From perry@vax.darpa.mil Fri Sep 11 15:46:42 1987 My understanding from the folks at RADC is the LONEX is going away, an no further enhancements are allowed to the system. I wonder what they are moving to? dennis ---------------------------------------------------------------------------- From sms@radc-lonex.arpa Sat Sep 12 17:22:05 1987 >My understanding from the folks at RADC is the LONEX is going away, an >no further enhancements are allowed to the system. I wonder what >they are moving to? > >dennis >------- > As a 'founding father' of the LONEX system here are my two (and a half) cents worth... The rumours do persist of LONEX's departure, primarily coming from those who are responsible for the successor system. The system that was supposed to have replaced LONEX is almost a year and a half behind schedule and does not even come close to providing the services and capabilities of the present system. This isn't the place i suspect to delve into the shortcomings/etc of the respective systems, if anyone wants my perspective drop me a line (obviously it leans towards the current system). The LONEX contract runs thru March 1988 at least, so we'll be here for a while yet. Enhancements are being quietly done, major changes are not allowed on a production system. Besides, as Jerry Pournelle says (loosely remembered) "Last year's state of the art is today's production system". Steven M. Schultz sms@radc-lonex.arpa (usually sms@etn-wlv.eaton.com) todays ---------------------------------------------------------------------------- From mcc@etn-wlv.eaton.com Sat Sep 12 17:46:20 1987 Dennis: The operational system to replace the experimental system is LONS and that is the official line; however, I think there is a great deal of resistance at the LONEX user level. I'm not sure what the final configuration of LONS is going to be; however, one component seems to be a single VAX system that provides the same user services provided by the array of PDP11/44, PDP11/70, and VAX systems used ithe LONEX system. While LONS is the "official" system, I doubt that LONEX will disappear in the near future. You have a large group of users that are familiar with the facilities of LONEX. Experience at EATON indicates that it is very easy to move secretaries whose primary use of the system to prepare letters and mem- orandae from one system to another but it is quite another to move people that use a system for preparing technical documentation and proposals part- icularly if these documents are going to be modified and reproduced over a period of time. In essence, the "old" system will not be replaced until a catastrophic event occurs--because no one wants to spend the money to con- vert all the data from the formats required by the "old" system to that re- quited by the "new" system. Merton Campbell Crockett ---------------------------------------------------------------------------- From perry@vax.darpa.mil Sat Sep 12 18:06:16 1987 Merton, I had heard the LONEX was going to go away because I had asked the RADC people to fix lonex so that, at least on there system, mail send to an individual would include who is on the 'cc' line. I wanted to make certain that eveyone involved in the discussion was being copied. Lonex apparently cannot do that. It sends out mail with blank cc lines and I do not know who else got the message, nor can I answer to everyone. If lonex is going to be around, this would be a good thing to fix. The RADC peole say that this would be a major change to the guts of the system and will not be done. dennis ---------------------------------------------------------------------------- From mcc@etn-wlv.eaton.com Sat Sep 12 18:58:53 1987 Dennis: I'm a little confused. The LONEX Mail Facility does indicate who the cc: recipients are on each message when you display the message. Of course, there may be some slight differences between the RADC and EATON versions. A definitive answer can be gotten from Steven M Schultz (sms@etn-wlv.eaton.com) currently on location (sms@radc-lonex.arpa) about any differences. Merton Campbell Crockett ---------------------------------------------------------------------------- From perry@vax.darpa.mil Sat Sep 12 19:14:14 1987 Merton, we made a test, and at least the RADC lonex does not include any names on the cc line. It does indeed send copies of the mail to those indicated on the cc lines of the lonex user who generates the mail, but the mail that is sent out does not include that information. Instead, lonex generates a mail message to everyone as if they were the only one getting the message. dennis ---------------------------------------------------------------------------- >From mcc@etn-wlv.eaton.com Sat Sep 12 22:10:03 1987 > >Dennis: > >I did a few tests in response to your last message. The behaviour of the >LONEX Mail Facility is very dependent upon where the mail originates. When >the mail is originated from the LONEX Mail Facility, all recipients of the >message will be displayed with the exception of the bcc: recipients. When >the mail is received from the in-house ELIS system, the bcc: recipients are >displayed as well--for some reason that system includes the bcc: in all >message headers. > >When the message originates on the DDN, only the addressee, originator, and >the individual forwarding the mail appears. If there are multiple address- >ees in the To: line or any recipients in the Cc: line, the information is >lost. The problem is at the transition between the two mail systems. The >problem is the mapping between the two header formats; however, I shouldn't >think it is that substantial a problem to fix. Steve Schultz probably can >give the best estimate of the changes required. > >Merton -------------------------------------------------------------------------- Merton, Dennis, Dan, Vicky, Guess it's about time i got in the act what with my name being mentioned (i felt my ears burning, so i figured someone was talking about me). RE: the '>'d stuff below: The 'problem' with the LONEX mail system not generating Cc: lines quite right was only brought to my attention a few weeks ago and since then there has been precious little time to look into it in detail. Now that i know 1) that there is a problem and 2) that somebody cares(?) i will attend to it. Don't hold your breath (people turn blue that way) but eventually i'll get it patched up. Steven M. Schultz (sms@etn-wlv.eaton.com normally right now i'm TDY at "sms@radc-lonex.arpa") P.S. Even with its problems, the LONEX mail system can send/receive mail from the DDN, something that LONS can not at the present do. ----------------------------------------------------------------------- >From mcc@etn-wlv.eaton.com Sat Sep 12 22:10:03 1987 > >Dennis: > > >When the message originates on the DDN, only the addressee, originator, and >the individual forwarding the mail appears. If there are multiple address- >ees in the To: line or any recipients in the Cc: line, the information is >lost. The problem is at the transition between the two mail systems. The >problem is the mapping between the two header formats; however, I shouldn't >think it is that substantial a problem to fix. Steve Schultz probably can >give the best estimate of the changes required. > >Merton -------------------------------------------------------------------------- 29 September 1987 Merton, Dennis, Steven: Thank you for responses about the LONEX system. We have some questions: It sounds as if the primary function of LONEX is keeping most of the processing on a larger system, away from the PCs, but is doing load balancing to share the work among several such larger systems. Are we on the right track? How about the supported spreadsheet and database programs; are they implemented on the server or the PCs? Where is the mail delivered? Do users have mailboxes on the server? (It doesn't sound like mail is delivered directly to the PC.) Can users send mail from the PC or must they do so directly from the server? How about printing? Must the user queue print jobs from the server or can he do so from the PC? Why are these terminals and PCs connected to your larger systems via an ethernet? Most of the implementations we've seen in which PCs accessed servers only as terminal emulators use asynchronous connections; it's cheaper and can handle the requirement. Is LONEX offering a service that makes the ethernet important? (perhaps those database programs are distributed database servers?) You said LONEX runs on 2.9bsd or 4.3. Did you mean, in addition, anything in the middle? How about vendor implementations of 4.2 such as those of Pyramid or CCI? What software is required on the PC? Do any of the other packages you mentioned (RAPIDE, UTAIN/MAIS, or ULANA) implement a file server? If you could describe them briefly we might know whether it was worthwhile to go looking for more information. Thanks for the help! We want to learn as much as we can from other people before we make any decisions. Vicky White Code K33 NSWC Dahlgren, VA 22448 (703) 663-7745 vwhite@nswc-g.arpa -------------------------------------------------------------------------- From sms@etn-wlv.eaton.com Tue Sep 29 19:48:32 1987 Vicky, Dennis, Good to hear from you again. I'm back from the East coast (not by choice, i think upstate NY is nicer than So. Cal.). I've bracketed my responses in lines of ===== below. steven m. schultz sms@etn-wlv.eaton.com ------------------------------------------------------------------------ > >It sounds as if the primary function of LONEX is >keeping most of the processing on a larger system, >away from the PCs, but is doing load balancing to share >the work among several such larger systems. Are we on the >right track? How about the supported spreadsheet and database >programs; are they implemented on the server or the PCs? ====== Correct, mostly. The 'system' at Griffiss AFB and Hanscom (Bedford MA) consists of 16 'mini'computers - 14 PDP-11/44s running 2.9BSD and two VAX-11/750s running 4.3BSD (the system in Westlake Village CA has two PDP-11/44s and 1 VAX-11/750). The QCALC spreadsheet program is a corehog, users on the PDP-11s run QCALC thru a servor over the ethernet. The database we have (although not too many users choose to learn it) is UNIFY and that runs directly on each processor (PDP-11s included). ====== > >Where is the mail delivered? Do users have mailboxes on the >server? (It doesn't sound like mail is delivered directly >to the PC.) Can users send mail from the PC or must they >do so directly from the server? How about printing? Must >the user queue print jobs from the server or can he do so from >the PC? ====== The mail is delivered to a users home processor (queued if need be until it comes up), i.e one of the PDP-11s or the VAX (at present only special users are allowed on the VAX). DDN mail (and yes, i've a fix to our incorrect mail headers due to be released Real Soon Now). I am a little confused at your mention of 'servor', perhaps it's a semantic nit, but i view them more as 'hosts' or 'home processors' since that's where the files, etc reside. Printing can be done from any processor to any printer in the network via the spooling system that runs on the hosts. ====== > >Why are these terminals and PCs connected to your larger systems >via an ethernet? Most of the implementations we've seen in >which PCs accessed servers only as terminal emulators use asynchronous >connections; it's cheaper and can handle the requirement. Is >LONEX offering a service that makes the ethernet important? (perhaps >those database programs are distributed database servers?) ====== Umm, sounds like something got mangled in transmission... You're quite right in that the terminals and any PCs present are connected via serial lines (DH11 or DMF32) and the PCs run terminal emulators. The ethernet is used for the hosts to communicate on, not for terminals. ====== > >You said LONEX runs on 2.9bsd or 4.3. Did you mean, in addition, >anything in the middle? How about vendor implementations of 4.2 such >as those of Pyramid or CCI? What software is required on the PC? ====== A qualified 'almost yes' to this one. If/when I can convert completely to TCP/IP as the communications package (perhaps possible with 2.10BSD) instead of the homerolled XNS variant presently in use THEN LONEX should run on any BSD (i've a low tolerance level for System Vanilla) originated Unix. The present system has much larger numbers of 16bit machines than 32bit machines, so the PDP-11s have been where the software was primarily written and tested before porting to the VAXen. All of the 'applications'/'user programs' in the LONEX system DO run with just recompilation on 4.3 or 2.9 as the sources are identical. I'm sure there are machine dependencies left even after running 'lint', but they should be fairly easy to squash. At present the placement of some of the local directories and files is hysterical (oops, historical) and should be changed, this would make for easier merging with other versions of Unix. The most commonly used software for the PC is a good VT1XX emulator with Kermit or Xmodem. ===== > >Do any of the other packages you mentioned (RAPIDE, UTAIN/MAIS, or ULANA) >implement a file server? If you could describe them briefly we might >know whether it was worthwhile to go looking for more information. > >Thanks for the help! We want to learn as much as we can >from other people before we make any decisions. ===== When Merton gets back from Germany he can try to answer this one, i'm not very knoweledgeable about the other programs you mentioned, keeping a network here and two back east hanging together plus whatever tweeks the software needs seems to be enough activity for me. It appears to me that you are looking for a system that is oriented around PCs rather than CRTs, or have i missed something? I think Merton mentioned in one of his items that PCs at present are not tightly integrated into LONEX (not too suprising, LONEX effectively predates PCs and the government did buy/lease an awful lot of VT1XX and VT2XX terminals), beyond file transfer capabilities. Hope this answers more questions than it raises, feel free to ask for clarification on any mud i wrote. Later... steven m. schultz EATON IMSD 31717 La Tienda Dr. MS 228 Westlake Village CA 91359 sms@etn-wlv.eaton.com ===== -------------------------------------------------------------------------- From timk@ncsa.ncsa.uiuc.edu Fri Sep 11 11:13:42 1987 Vicky, At the National Center for Supercomputing Applications, we are facing the same types of connection problems that you mentioned in the note which was forwarded to the ARPANET tcp-ip mailing list. We have looked at most of the alternatives you have, and have gone through several steps which you may want to learn from. We have Suns, Vaxes, Alliant, Silicon Graphics, and a Cray XMP. We access them from PCs and Macs with TCP/IP. 1. Transparent file systems to Suns and other minis are not as valuable to PC users as you might think. We use local hard disks and convenient ftp service. LANS, like Novell, which provide file services without involving the minis, would be more attractive, though we don't use any. (substitute "large workstation" for minicomputer if you like) 2. The most important thing for us has been powerful terminal access to the larger computers. We developed our own because the available ones were not powerful enough. File transfer is next most important. 3. Try our TCP/IP package for PCs and Macs. I am appending our old release information, the new version will support new Ethernet boards, have Tektronix graphics emulation and several more new features (October 1). 4. We have "rigged" solutions which I am willing to discuss, which cover the mail and printing parts of your requirement list. We are planning to work on "proper" solutions to these problems in the next year. 5. Most of the people I talk to lean toward PC-NFS when choosing the commercial versions. My personal opinion is that they are solving the wrong problem. Good luck in your search, give me a call if it will help (217)244-0638. Tim Krauskopf National Center for Supercomputing Applications (NCSA) University of Illinois timk%newton@uxc.cso.uiuc.edu (ARPA) 14013@ncsavmsa (BITNET) Fact Sheet ---------- National Center for Supercomputing Applications presents: NCSA Telnet for the PC, version 1.1 NCSA Telnet for the Macintosh, version 1.1 These programs are copyrighted, but distributed in binary form with no license fee. Source code is not available. We are exploring the possibility of distributing linkable libraries which support TCP/IP. Description: ----------- NCSA Telnet for the PC is an MS/DOS application which enhances communication with other computers over Ethernet. It uses the DARPA standard TCP/IP protocols, giving the PC access to all of the machines on the ARPANET and NSFnet. The basic framework consists of the standard telnet with an FTP server built-in. During a telnet session, you can initiate an FTP session from a remote host and transfer files to and from your PC, in the background. NCSA Telnet provides a virtual terminal, emulating a VT100, which can connect to any telnet host on the network. A unique multiple session capability makes this multiple virtual terminals by allowing you to log in to several machines at once, or one machine several times, with each session completely separate from the others. A simple keystroke switches the screen display from one session to the next. NCSA Telnet for the Macintosh takes these basic features and adds support for the user interface that Macintosh users expect from Mac applications. Each session is displayed in a different window, Macintosh menus are used throughout, desk accessories are supported, and text can be copied from a session window to the clipboard. With a large screen, such as the Macintosh II's displays or the Radius display, several simulataneous VT100 screens can be viewed at the same time without overlapping windows. Development of NCSA Telnet began in August of 1986 in an effort to improve microcomputer access to NCSA's Cray XMP supercomputer and the various other workstations connected to our local networks. Our local Ethernet supports VAXes, Sun workstations, and an Alliant FX/8, which can all be reached from a PC, using NCSA Telnet. Shortly after the original implementation on the PC, we decided to port the code to the Macintosh for use over Appletalk, through a Kinetics Appletalk to Ethernet gateway. These programs have been in constant use at NCSA since January, 1987 and are still undergoing improvements. Features included in version 1.1 of NCSA Telnet: ----------------------------------------------- DARPA standard telnet Built-in standard FTP server for file transfer VT102 emulation in multiple, simultaneous sessions Class A,B and C addressing with standard subnetting Each session in a different window (Macintosh) Tektronix 4010 graphics emulation (Macintosh) Supports Croft gateway, i.e. KIP (Macintosh) Capture text to a file (PC) Full color support (PC) How to obtain: ------------- 1) Anonymous FTP from uxc.cso.uiuc.edu in the NCSA subdirectory. The PC version is a tar file which contain binary files. After the files are extracted from the tar file, some binary transfer (e.g. kermit) should be used to download the files to the PC. The Macintosh version is several files encoded with BinHex 4.0. Download them with a similar transfer method (kermit) and use BinHex 4.0 to extract the files. Printable documentation is included with each version; the Mac documentation is in MacWrite format. After downloading, you may copy the files as often as you wish, unmodified, in binary form, with the copyright notices intact. 2) With appropriate communications software, the program and documentation can be downloaded over phone lines from the University of Illinois EXCEL bulletin board. The phone number is (217)333-8301 and it operates at 300,1200 and 2400 baud. For the Macintosh version your communications software must support the MacBinary protocol. Kermit or Xmodem can be used to download the PC version. (available 7/8/87) 3) On-disk copies, with a printed manual are available for $20 each, which covers handling and postage. Orders can only be accepted if accompanied by a check made out to the University of Illinois. Send to: NCSA Telnet orders (specify PC or Macintosh version) 152 Computing Applications Building 605 E. Springfield Ave. Champaign, IL 61820 Hardware required: ----------------- PC: IBM PC, AT or compatible. 3COM 3C501 Etherlink board. Support for other boards planned, which would you require? Upcoming: Ungermann-Bass, IBM, MICOM NI5210 Mac: Macintosh Plus, SE or Macintosh II. Kinetics, Inc. FastPath, EtherSC or the new SE Ethernet board. Kinetics gateway software or Stanford KIP (Croft) gateway software. The best source of information about Kinetics is directly from the company. Kinetics Inc. FastPath approx. $2500 Suite 110 EtherSC approx. $1250 2500 Camino Diablo educational and volume discounts Walnut Creek, CA 94596 (415) 947-0998 Other questions: --------------- mail to telbug%newton@uxc.cso.uiuc.edu ============================================================= notes from phone conversation with Tim Sept. 11 87: Tim's reasons for not wanting a pc-nfs like solution are: 1)their users don't want it; they have a heavy need to use the Cray directly and do the work there; converting these files from Unix to DOS or the other way around is just too much trouble. 2)It is not, in his opinion, good computer science. He says, if you really want an nfs-like environment, get something from a PC lan manufacturer like Novell. They can do it better because that's all they do; they aren't trying to do a bunch of other things in their operating system like Unix is. Therefore the design is cleaner and has fewer problems. If you just want file transfers without necessarily the tranparency of nfs, a telnet-like program is better. (same reasons: less overhead, less to do, cleaner design) He likes separating the worlds of big machines and pcs, and thinks you get better vendor support and happier users that way. By the way, I guess many of you knew this, but he says smtp has a retrieval facility (like the POP mail facility) but it isn't well known and isn't implemented in Berkeley. They have tried 3com and Unix on Suns. They wrote their own telnet application with a built in ftp which he actively promotes; try it/you'll like it. Why did they do that instead of using an existing implementation? Try it and we'll see how much better theirs is. They are moving toward POP. They want to avoid a simple smtp on a PC since it requires leaving the PC on overnight. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111607362000> Received: from etn-wlv.EATON.COM by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 15:55:11-PST Received: by etn-wlv.EATON.COM (5.54/1.14) id AA02326; Mon, 16 Nov 87 15:36:20 PST Date: Mon, 16 Nov 87 15:36:20 PST From: mcc@etn-wlv.EATON.COM (Merton Campbell Crockett) Message-Id: <8711162336.AA02326@etn-wlv.EATON.COM> To: PAP4@ai.ai.mit.edu, tcp-ip@sri-nic.arpa Subject: Re: IP encapsulation over ARCnet Cc: pcip@louie.udel.edu Saw the message once--didn't need to see it again. I don't know which is worse- -messages taking forever to traverse the network or receiving the same message twice. Why don't we make all message traffic slow (Electronic Snail) and then eliminate the redundancy feature. Perhaps I should "biff n" to avoid the "Noyed". Maybe we should add a new item to the TCP/IP jargon list: Noyed (n): duplicate message or packet. Annoyed (v): the feeling one gets when one receives a noyed. Merton Campbell Crockett ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111609040000> Received: from sonora.dec.com by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 17:04:55-PST Received: from acetes.dec.com by sonora.dec.com (5.54.4/4.7.34) id AA17160; Mon, 16 Nov 87 17:04:32 PST Received: by acetes.dec.com (5.54.3/4.7.34) id AA05566; Mon, 16 Nov 87 17:04:27 PST From: mogul@decwrl.dec.com (Jeffrey Mogul) Message-Id: <8711170104.AA05566@acetes.dec.com> Date: 16 Nov 1987 1704-PST (Monday) To: tcp-ip@sri-nic.ARPA Subject: re: TCP maximum segment size determination Craig Partridge writes (regarding the use of a "probe" mechanism to find out the real MTU of a path): By the way, the scheme is sound even if the path changes if you treat the IP option and the TCP MSS values as distinct. I would amplify this: any mechanism to discover MTUs should be viewed as an IP-level mechanism, available to all protocols (not just TCP). TCP, in turn, should already be asking the IP layer "what is the largest appropriate MTU for this connection/destination/path?" and then never sending anything larger. This can be done in the absence of any new protocol, and is in fact approximately what is done in 4.3BSD (except that there the layering is somewhat blurred, in that the TCP code goes and looks directly at the interface MTU, rather than asking IP via a nicely abstracted interface.) Craig is also right that if the MTU changes during a connection (e.g., because the route changes) then it should be possible to adapt. However, instead of using his proposed mechanism (as I understand it) of: TCP receives redirect TCP initiates new probe TCP updates MSS I would instead keep most of this at the IP level IP receives redirect (or "time to re-probe" timer expires) IP initiates new probe IP receives probe info and passes new MTU to TCP analogous to what it does with a source quench Thus, TCP only has to accept MTU values from IP, not manage the protocol of obtaining them. If packets are traveling along paths with different MTUs, and the rate at which paths change is faster than 2*RTT, then perhaps it should be possible to recognize this and simply stick with the lower (lowest) MTU rather than try to second-guess what is either an oscillating or load-balancing gateway. How often does this happen, though? I think it's important to realize that we should be able to obtain moderate improvements in the likely cases without having to try for optimal behaviour in the general case. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111609140000> Received: from sonora.dec.com by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 17:15:31-PST Received: from acetes.dec.com by sonora.dec.com (5.54.4/4.7.34) id AA17274; Mon, 16 Nov 87 17:15:07 PST Received: by acetes.dec.com (5.54.3/4.7.34) id AA05600; Mon, 16 Nov 87 17:15:00 PST From: mogul@decwrl.dec.com (Jeffrey Mogul) Message-Id: <8711170115.AA05600@acetes.dec.com> Date: 16 Nov 1987 1714-PST (Monday) To: tcp-ip@sri-nic.ARPA Subject: Re: TCP maximum segment size determination JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") writes that If gateway gurus saw their way clear to do so, they might help some fraction of the world by arranging that IP fragments aren't transmitted consecutively (if there is other traffic to handle) or by inserting a little time delay if the Ether or other non-serial media is idle. Alas, this doesn't work if there's another gateway further along the route, since that gateway has no practical way of knowing that two fragments arriving with a slight delay between them are fragments of the same datagram. This gateway will normally "iron out" the delays inserted previously, especially if there is any queueing delay (say because the first fragment is huge and the second is tiny). At Stanford we tried to play a similar game by fixing the gateway (which was actually one of JNC's prototypes for the Proteon gateway) between the ARPAnet and our ethernet to delay between any pair of packets to the same local-wire destination. If all the gateways did this, in theory it would work because then no matter what path the fragments took through the Internet, they would always be spaced out at the last step. Unfortunately, this didn't work 100% because delaying for any reasonable period of time can't guarantee that a timesharing system (with poor interrupt latency) will always have time to get ready for the next packet, and because it can always be distracted by local-net traffic (especially broadcasts and multicasts). -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111609255900> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 11:30:25-PST Received: from MARIST.BITNET by wiscvm.wisc.edu ; Mon, 16 Nov 87 13:28:02 CDT Received: by MARIST (Mailer X1.25) id 3757; Mon, 16 Nov 87 14:27:24 EST Date: Mon, 16 Nov 87 14:25:59 EST From: Bill Lee Subject: Removal from list To: TCP-IP@SRI-NIC.ARPA Tcp-ip has been very informative for me, but due to my schedule, I just don't have the time to read it anymore...so, please remove me from the mailing list.. Thanx much, Bill Lee ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111609260000> Received: from sonora.dec.com by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 18:06:06-PST Received: from acetes.dec.com by sonora.dec.com (5.54.4/4.7.34) id AA17361; Mon, 16 Nov 87 17:26:59 PST Received: by acetes.dec.com (5.54.3/4.7.34) id AA05728; Mon, 16 Nov 87 17:26:51 PST From: mogul@decwrl.dec.com (Jeffrey Mogul) Message-Id: <8711170126.AA05728@acetes.dec.com> Date: 16 Nov 1987 1726-PST (Monday) To: tcp-ip@sri-nic.ARPA Subject: Re: TCP maximum segment size determination PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") writes about the use of an IP header option to probe for MTUs: What about the required overhead for gateways and routers to have to further inspect each packet? (1) It should not be necessary to probe on every packet. All bets are off, though, if the gateways are (a) oscillating, or (b) doing loadsharing in a way that creates dramatically variable routes (a mistake anyway, in my opinion). (2) A well-designed probe protocol should not cost that much. Alas, with IP we are stuck using IP header options, and they aren't that cheap. If I were designing the next version of IP ... (3) Source route already requires such inspection. (This is not necessarily an argument in favor of a new IP option, but because of points #1 and #2 the load should be a lot lower than source routing). It could be optimized so that only TCP packets are inspected, but still, that would seem to add to the burden of possibly compute-bound gateways... Arggh! This sort of mechanism should NOT be TCP-specific ... that makes the gateway logic more complex that it needs to be, it fails to solve the equally pressing problem with other protocols (anyone out there having problems with NFS/UDP fragmentation?), and besides, it's not necessary ... because the source host is the one that decides when to add the IP header option, it only needs to send the option when necessary, and the gateways can tell quickly if any options are present. A final point: if I thought that the best we could do with path-probing is only "add only a little load to the gateways" then I would be against it. The whole point is to add a little per-packet overhead to avoid loading the network with retransmissions of lost packets and hope that the latter outweighs the former. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [243@casemo.UUCP] <1987111612270700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brian@casemo.UUCP (Brian Cuthie ) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Microport TCP recommendations Message-ID: <243@casemo.UUCP> Date: Mon, 16-Nov-87 17:27:07 EST Article-I.D.: casemo.243 Posted: Mon Nov 16 17:27:07 1987 Date-Received: Thu, 19-Nov-87 05:34:56 EST References: <141@ncc.UUCP> <328@idacrd.UUCP> Distribution: comp Organization: CASE Communications, Columbia, MD Lines: 21 In article <328@idacrd.UUCP>, mac@idacrd.UUCP (Bob McGwier) writes: > in article <141@ncc.UUCP>, lyndon@ncc.UUCP (Lyndon Nerenberg) says: > > Xref: idacrd comp.protocols.tcp-ip:1594 comp.dcom.lans:885 > > > > Lyndon: > > I would have thought you knew that Phil's stuff has been ported to > system V. Contact Bdale Garbee. > > Bob > How do we get the sys V version of the KA9Q stuff ?? I've been waiting for a while for a posting that would suggest that it's actually available. Last I had heard, it was still in beta test (so to speak). I'm dying to have it ! Cheers, brian ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111613181500> Received: from ACC-SB-UNIX.ARPA by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 15:19:56-PST Received: by ACC-SB-UNIX.ARPA (5.51/4.7) id AA17488; Mon, 16 Nov 87 15:19:41 PST Received: by columbia-pdn (5.51/5.17) id AA06930; Mon, 16 Nov 87 18:18:15 EST Date: Mon, 16 Nov 87 18:18:15 EST From: cam@columbia-pdn (Chris Markle acc_gnsc) Message-Id: <8711162318.AA06930@columbia-pdn> To: tcp-ip@sri-nic.arpa Subject: Who Has Implemented NVDET (RFC 732)? Folks, Which vendors, etc. have implemented the Telnet Data Entry Terminal (Network Virtual Data Entry Terminal or NVDET) per RFC 732? Chris Markle - cam%columbia-pdn@acc-sb-unix.arpa - (301)290-8100 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111613262200> Received: from omnigate.clarkson.edu by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 15:31:12-PST Received: from clutx.clarkson.edu by omnigate.clarkson.edu id aa15922; 16 Nov 87 18:27 EST Received: by clutx.clarkson.edu (5.52/5.17) id AA05585; Mon, 16 Nov 87 18:26:22 EST Date: Mon, 16 Nov 87 18:26:22 EST From: Brad Clements Message-Id: <8711162326.AA05585@clutx.clarkson.edu> To: PAP4@ai.ai.mit.edu, tcp-ip@sri-nic.arpa Subject: Re: IP encapsulation over ARCnet Cc: bkc@clutx.clarkson.edu Here are some thoughts on IP fragmentation, odd sizes and IP address resolution. One important thing to keep in mind is that not all ARCNet cards support long packets. Not all users will know their ARCnet hardware node ID. In talking to Billy Cox at Datapoint, we discussed wether or not to implement an 'arp like' system or simply to map the low byte of the IP address to the node ID. There are arguements for both options. Mr. Cox made a good point favoring the ARP style solution in that a particular user (with a given IP address) may need to move to another computer due to hardware problems but wish to retain his IP address. If hardware mapping was involved, he could not do this. Also, it would be nice for the driver to know which Nodes will accept long packets and which will not. I suggest something like this: 1) Implement a simple ARP system that allows a node to indicate wether it accepts long or short packets. 2) Keep the Hardware Node ID and IP address and long.short packet flag in a table with an appropriate time-to-live. 3) Use the table information to fragment (where necessary) packets and deliver to the appropriate hardware address. The table would be built from replies from broadcast packets (destination ID 0) If two or more nodes responded to an inquiry for a single IP address, a diagnostic could be passed up through the system and the IP addr completely ignored. For fragmentation and odd sizes, I suggest something like this (stolen ideas) The first byte after the packet type byte (packet types proposed are 240 for IP and 241 for ARP) would be a mode byte which indicates odd sizes and first/last packets in a fragmentation. Bit 7 6 5 4 3 2 1 0 First Last Size2 Size1 Size0 Bits 3 through 5 or don't cares. The size bits work as follows: Actual Packet Size Size2 Size1 Size0 Packetsize 0 0 0 253 0 0 1 254 0 1 0 255 0 1 1 256 1 0 0 The actual packet size INCLUDES the packet type and the mode byte. This gives a hardware maximum packet size of 506 bytes. If bits 0 - 2 are zero, the packet size is what is indicated by the packet size byte minus the bytes used by the destination ID/Source ID and packet length. This would be 3 or 4 bytes for short or long packets respectively. If the size bits are not zero, the size indicated in the table above is the datapacket size not counting destination ID/Source ID or packet length bytes. Fragmentation works as follows: If a packet does not need to be fragmented a) the destination packet size is big enough to receive the IP packet b) the first and last bits are set in the mode byte and the size bits are set accordingly. c) the packet is transmitted and if the TMA bit is set a SUCCESS response is passed up to IP. If a packet needs to be fragmented: a) the destination either can not accept the entire IP packet b) The first bit is set for the first packet, the last bit is set for the last packet and neither bits are set for middle packets. c) If the TMA status is not set on ANY of the packets, the entire IP packet is discarded and a FAILURE is returned to IP. This assumes a TMA timeout of some kind. d) The size bits are set accordingly for each packet transmitted. For the receiving ARC driver: If the first and last bits are set: A) a single IP packet is retrieved after decoding its size from the size bits. b) The ip packet is passed up the chain. If the first bit is set: a) an 'mbuf' chain is started, indicating which source ID the packets are going to be from. The first packet is copied into the mbuf. If neither the first nor the last bit is set: a) a search is made for an mbuf chain with the same source ID. If none is found the packet is discarded. b) Otherwise the packet is added to the appropriate mbuf chain. If the last bit is set: a) a search is made for an mbuf chain with the same source ID. If none is found the packet is discarded. b) Otherwise the packet is added to the mbuf chain and the entire IP packet is passed up to IP. c) The mbuf chain is cleared from memory. Some notes on how this works: The procedure assumes that an ARC driver which did fragment an IP packet will always transmit the fragments in the proper order before processing any other output. This allows for other ARC nodes to send IP fragments to the receiver while other fragmented packets are being received. This means that enough memory must be available for packet reconstruction. Finally this assumes that the receiving ARCnet driver will not enable receiving unless memory is available to receive the packet. An mbuf chain would have a time-to-live within which time the last packet must be received. If the last packet is not received the entire chain is discarded. One possible enhancement is to use bits 3 -5 to indicate the number of ARC packets remaining to be sent. This would allow the receiver to pre-allocate enough space when the first packet was received, keep track of sequencing, and ensure that each packet got through. No mechinism is defined for retransmitting a missing ARC packet, since the source assumes that once the TMA bit is set the receiver properly received the packet. Using bits 3 - 5 would allow an IP maximum size of 8 * 506 = 4048 bytes. This scheme suggested here was dreamed up in a few minutes and will probably need modification. I personally feel that some form of ARP should be support to allow for flexibility. Packet fragmentation and odd size handling would be easy to handle using the 'mode byte' concept. This fragmentation scheme relies on the features of ARCnet itself, in that the TMA must be looked at (with a timeout) and that a single ARC node will not transmit IP packet fragments out of sequence. This scheme can be easily implemented under both receive and transmit interupts. Brad Clements ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111613281100> Received: from ACC-SB-UNIX.ARPA by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 15:56:11-PST Received: by ACC-SB-UNIX.ARPA (5.51/4.7) id AA17675; Mon, 16 Nov 87 15:29:38 PST Received: by columbia-pdn (5.51/5.17) id AA06969; Mon, 16 Nov 87 18:28:11 EST Date: Mon, 16 Nov 87 18:28:11 EST From: cam@columbia-pdn (Chris Markle acc_gnsc) Message-Id: <8711162328.AA06969@columbia-pdn> To: tcp-ip@sri-nic.arpa Subject: Question on ICMP Parm Problem Messages Cc: rjs@columbia-pdn@acc-sb-unix Folks, In an ICMP parm problem message one is to return the Internet header and 64 bits of the orginal datagram's data. What is suggested when the parm problem is a corrupted (eg. 0) IP header length (IHL) field or IP total length field? RFC 792 doesn't seem to mention what to do in this case. In the case of 0 IP total length but good IP header length is just sending the IP header OK? In the case of 0 IP total length and 0 IP header length is just sending the minimum IP header length (ie. 20 bytes) OK? Chris Markle - cam%columbia-pdn@acc-sb-unix.arpa - (301)290-8100 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111613420100> Received: from tut.cis.ohio-state.edu (OHIO-STATE.ARPA) by SRI-NIC.ARPA with TCP; Mon 16 Nov 87 19:10:47-PST Return-Path: WELCH@OSU-20 Received: from osu-20 by tut.cis.ohio-state.edu (5.52/0.2) id AA15085; Mon, 16 Nov 87 18:44:46 EST Message-Id: <8711162344.AA15085@tut.cis.ohio-state.edu> Date: Mon 16 Nov 87 18:42:01-EST From: Arun Subject: Re: Telnet options To: minshall@violet.Berkeley.EDU Cc: tcp-ip@sri-nic.arpa In-Reply-To: Message from "minshall@violet.Berkeley.EDU" of Mon 16 Nov 87 16:55:08-EST Thanks to everyone who responded with info on the telnet options. It turns out that it was a combination of problems on both ends of the connection: 1) The tops-20 host was coming up with unknown options for it's own purposes (apparently a common problem with them). 2) The Xerox host was doing a table lookup on the options, and when it didn't find the option in it's table, it died. What it should have done was respond with a DONT or a WONT... It should be an easy fix to incorporate into the code. Ah well, these are the joys of networking on heterogenous machines, I guess. ...arun ---------------------------------------------------------------------------- Arun Welch Lisp Systems Programmer, Lab for AI Research, Ohio State University welch@ohio-state.{CSNET,ARPA} welch@red.rutgers.edu (a guest account, but mail gets to me eventually) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12351196238.16.OLE@CSLI.Stanford.EDU] <1987111615471800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: OLE@CSLI.STANFORD.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: NetBIOS Compatibility Demo Message-ID: <12351196238.16.OLE@CSLI.Stanford.EDU> Date: Mon, 16-Nov-87 20:47:18 EST Article-I.D.: CSLI.12351196238.16.OLE Posted: Mon Nov 16 20:47:18 1987 Date-Received: Mon, 23-Nov-87 00:12:42 EST Sender: cox@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 There will be a NetBIOS Compatibility Demonstration at the 2nd TCP/IP Interoperability Conference. Several vendors will demonstrate conformance to RFC 1001 and RFC 1002. The demo will be held on Thursday December 3rd from 6:30pm to 8:00pm at the Hyatt Regency Crystal City in Arlington, VA. This demo is open to the public. Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [102@umunhum.STANFORD.EDU] <1987111620162900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: paulf@umunhum.STANFORD.EDU (paulf) Newsgroups: comp.protocols.tcp-ip Subject: fuzzware wanted Message-ID: <102@umunhum.STANFORD.EDU> Date: Tue, 17-Nov-87 01:16:29 EST Article-I.D.: umunhum.102 Posted: Tue Nov 17 01:16:29 1987 Date-Received: Thu, 19-Nov-87 05:43:10 EST Reply-To: paulf@umunhum.STANFORD.EDU (Paul Flaherty) Organization: The Three Packeteers Lines: 7 Okay, where can I find a copy of the fuzzball code to play with? -=Paul Flaherty, N9FZX | "One Internet to rule them all, Computer Systems Laboratory | One Internet to find them, Stanford University | One Internet to bring them all Domain: paulf@shasta.Stanford.EDU| and in the ether bind them." -ToIH ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711112005.AA16892@tcgould.TN.CORNELL.EDU] <1987111623365100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Slang Glossary Message-ID: <8711112005.AA16892@tcgould.TN.CORNELL.EDU> Date: Tue, 17-Nov-87 04:36:51 EST Article-I.D.: tcgould.8711112005.AA16892 Posted: Tue Nov 17 04:36:51 1987 Date-Received: Thu, 19-Nov-87 19:51:24 EST References: <281178.871107.JBVB@AI.AI.MIT.EDU> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 >A bogon is a particle (alias packet) that transmits bogosity. I guess it is >also a happy accident that it rhymes with Vogon, because the bogus info is >frequently offensive and/or destructive. Happy accident? Absolutely intentional; the analogy with a particle came later. "Vogons may read you bad poetry, but bogons make you study obsolete RFCs." >Gong? I dunno. This is Dave Mills's, derived from "gongfermer". It's worth asking him to repost his explanation. Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MVaBFHy00UoJc7g1sn@andrew.cmu.edu] <1987111700041300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: new BOF Message-ID: Date: Tue, 17-Nov-87 05:04:13 EST Article-I.D.: andrew.MVaBFHy00UoJc7g1sn Posted: Tue Nov 17 05:04:13 1987 Date-Received: Thu, 19-Nov-87 19:53:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 I am conducting a BOF at the upcoming TCP/IP conference in Arlington VA called "Standard socket level interface for PC's". Many vendors now have or will soon have resident TCP/IP code for PC's, however, there is no standard interface. Many of these vendors also have socket-style libraries or resident code with no standard for which calls are supported or how one interfaces to them. The purpose of the BOF is to generate interest in standardizing a BSD socket style interface to TCP/IP for IBMPC MS/DOS applications. All are welcome to attend, especially PC TCP/IP vendor representatives. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111703334400> Received: from mitre.arpa by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 05:47:45-PST Full-Name: Steve Goldstein Message-Id: <8711171333.AA10245@mitre.arpa> Organization: The MITRE Corp., Washington, D.C. To: Mills@UDEL.EDU Cc: "James B. VanBokkelen" , amdcad!amd!intelca!mipos3!omepd!wire@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, goldstei@mitre.arpa Subject: Re: TCP/IP Slang Glossary In-Reply-To: Your message of Wed, 11 Nov 87 15:14:41 -0500. <8711111514.aa10891@Huey.UDEL.EDU> Date: Tue, 17 Nov 87 08:33:44 EST From: Steve Goldstein Makes sense, Dave, 'cause in the DECnet (you should pardon the expression!) world, gongs are called "Donikers". Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [111287.142523.yakov@ibm.com] <1987111704061200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: YAKOV@IBM.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Solicitation for comments Message-ID: <111287.142523.yakov@ibm.com> Date: Tue, 17-Nov-87 09:06:12 EST Article-I.D.: ibm.111287.142523.yakov Posted: Tue Nov 17 09:06:12 1987 Date-Received: Thu, 19-Nov-87 06:47:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 I'd like to solicit some comments on the following proposal for IP routing: Instead of computing routes on a hop-by-hop basis, the first gateway which receives packet from a host will compute complete route (like IP source routing) and all other gateways on the path to destination will route just based on that source routing. That assumes, that each gateway has complete topology of the network, and that it runs some sort of SPF (Shortest Path First) Algorithm which can generate complete path for a given destination. This idea (of source routing instead of hop-by-hop routing) is similar to what is used in MAC Layer IEEE 802.5 bridges. Both positive and negative comments are welcomed. Many thanks in advance to all who will reply. Jacob Rekhter (YAKOV@IBM.COM) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111705060000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 07:08:29-PST Date: 17 Nov 1987 10:06-EST Sender: CLYNN@G.BBN.COM Subject: Re: Question on ICMP Parm Problem Messages From: CLYNN@G.BBN.COM To: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]17-Nov-87 10:06:14.CLYNN> In-Reply-To: <8711162328.AA06969@columbia-pdn> Chris, If the IP header length is bad, I would send a parameter problem message with a pointer of 0 and include a worst-case IP header (60 octets) + 64 bits of data; if something is that bad, give as much help as possible. For a bad IP length the pointer should be 2 or 3, and include the IP header as specified in the IP Header Length field. Note that there is more than one possible IP length error: a) too small to include the IP header [I do not think I have ever seen a specification that the layer above IP HAS to have a non-zero length, although it seems rather unlikely], or b) that the length is too large for the datagram passed to the IP from below. (Maybe a convention could be [informally?] established that a pointer of 2 means the IP Length was too large and 3 that it was too small; all in the spirit of adding as much diagnostic information as possible.) PS: "columbia-pdn" is an interesting domain-style name. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111705063700> Received: from gateway.mitre.org by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 07:05:05-PST Return-Path: Received: by gateway.mitre.org (5.54/SMI-2.2) id AA19928; Tue, 17 Nov 87 10:06:37 EST Date: Tue, 17 Nov 87 10:06:37 EST From: tsuchiya@gateway.mitre.org (Paul Tsuchiya) Full-Name: Paul Tsuchiya Message-Id: <8711171506.AA19928@gateway.mitre.org> To: YAKOV@ibm.com, tcp-ip@SRI-NIC.ARPA Subject: Re: Solicitation for comments It is a little hard to comment on your proposal since you did not state what the advantages of doing source routing are. There have been several advantages put forth in the context of multi-path routing and TOS routing (BBN has worked on this). Some others believe that it is useful for threading ones way through a thicket of administrative restrictions on paths, but I have yet to see a solid proposal on the idea. Also, the similarity between what you propose and the 802.5 source routing seems to end at the simple fact that they both put source routes in their headers. Using SPF to calculate the headers and using what 802.5 are two completely different things. I don't understand all of the details of 802.5, but I understand it is really badly done. Ultimately, I don't have my mind made up one way or the other about source routing--I guess it rather depends on the specific proposal. So I put it back to you, what do you consider to be the advantage that causes you to propose it in the first place? _________________________________________________________________ Paul F. Tsuchiya The MITRE Corp. tsuchiya@gateway.mitre.org 7525 Colshire Dr. 703-883-7352 McLean, VA 22102 USA _________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111705260000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 07:28:50-PST Date: 17 Nov 1987 10:26-EST Sender: CLYNN@G.BBN.COM Subject: Re: TCP maximum segment size determination From: CLYNN@G.BBN.COM To: mogul@DECWRL.DEC.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]17-Nov-87 10:26:46.CLYNN> In-Reply-To: <8711170115.AA05600@acetes.dec.com> We implemented a variation of the delay scheme: never send two consecutive packets to the same next hop (on a single interface) if there was another packet in the queue for some other destination. It was easy to implement, at most delays a packet by one packet's transmission time, and does not suffer from the requeueing problem you described. It might even fit in well with recent interest in "fair queueing" (it brings to mind the days when I was reliably sending >20,000 byte datagrams across the ARPANET - the back to back problem was very clear when IP fragmented it into >20 consecutive full size ARPANET packets!). Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111705302000> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 07:31:25-PST Date: Tue 17 Nov 87 10:30:20-EST From: Lixia Zhang Subject: Re: Solicitation for comments To: YAKOV@ibm.com, tcp-ip@SRI-NIC.ARPA In-Reply-To: <111287.142523.yakov@ibm.com> Message-ID: <12351346066.28.LIXIA@XX.LCS.MIT.EDU> Jacob, The discussion of using source routing in an internet env. has been going on here and there for a long time. I used to joke with friends that my religion on internet routing is "source routing". (I also have religions on other network issues: the religions on congestion control, on protocol layering, etc.) I'd like to know more about what thought you have behind the proposal. Are you proposing for a short term fix, or for some long term goal? One should realize that employing source routing may imply fundamental changes to the IP network architecture. Besides that the whole current routing architecture will be changed, source-routing on every single datagram may also cause unbearable overhead. I believe the changes will eventually come; the question is when and in what form. One comment on your last sentence: the source routing idea in your msg is NOT very similar to MAC Layer 802.5 bridge routing proposal. In the latter, MAC Layer bridges have no topology info at all; every single host (in fact, its data link layer) is responsible to find out routes itself. Lixia ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111706240900> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 08:25:41-PST Date: Tue 17 Nov 87 11:24:09-EST From: Radia Perlman Subject: Re: Solicitation for comments To: YAKOV@ibm.com cc: tcp-ip@SRI-NIC.ARPA, .@XX.LCS.MIT.EDU In-Reply-To: <111287.142523.yakov@ibm.com> Message-ID: <12351355862.52.RADIA@XX.LCS.MIT.EDU> Source routing as Jacob Rekhter suggests (i.e. having the first gateway put the entire route in the header, which it computes based on a complete map of the network) should not be compared to the "source routing" advocated by 802.5. In the 802.5 scheme the route is not calculated by the gateways, but instead the burden of discovering and maintaining routes is placed on the end stations (maybe you guys use the word "hosts" -- I'm from a different culture). Discovery of a route in 802.5 is done by having the source end station emit a sort of virus packet that proliferates and travels over all the exponential possible routes throughout the network, each copy recording the route it has taken. Then the destination end station returns all the copies it receives to the source end station, which can then enjoy the task of selecting the "best route" based on any algorithm it likes. With anything but a very small and very sparsely connected network, the exponential overhead inherent in the route discovery process will make the 802.5 proposal impractical. I believe the January issue of IEEE Network Magazine will be a special issue on bridges, if people want more information on the subject. Anyway, that's not a criticism of Jacob Rekhter's scheme, just of his comment that his proposal was "similar to 802.5 bridges". There are lots of advantages to having the first gateway specify the route. The main disadvantages are: 1) the header gets larger of course -- the networking community has already been accused of offering a "headergram" rather than a "datagram" service. 2) the scheme gets more complex (though not impossible) when the network gets large enough to introduce an extra level of hierarchy. (So that the source gateway does not have a complete map of the network). Radia Perlman (Radia@XX.LCS.MIT.EDU) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111706380000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 08:40:15-PST Date: 17 Nov 1987 11:38-EST Sender: CLYNN@G.BBN.COM Subject: Re: TCP maximum segment size determination From: CLYNN@G.BBN.COM To: mogul@DECWRL.DEC.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]17-Nov-87 11:38:24.CLYNN> In-Reply-To: <8711170126.AA05728@acetes.dec.com> Jeff, If you want a low (as in zero) gateway overhead, no change(1) to gateway code, non-TCP specific, works with non-symmetric routes, easy to phase into use (e.g., where you really need it), backward compatible, way to do MTU probing, read on. In this scheme, every packet is a "probe" (no cost to originating system to invoke). The gateways do fragmentation, as they are required to do. I would suggest that the size of the first fragment be the MTU of the next hop - the suggested fragmentation algorithm has this property, and the last time the subject was discussed on this list, no vendors replied saying that they had implemented an algotithm which didn't have the property (but it isn't really required anyway). If all the fragments arrive at the destination and get reassembled(2), all is well and you didn't really need to probe. In the no-problem case, your additional cost is zero - seems good. If not all the fragments made it, some will be left in the IP reassembly queue and timeout. This is where the ICMP Time Exceeded message is used (as opposed to the spec which uses words like "may" and "need not"). Chances are pretty good (engineering over mathematics) that the first fragment made it and can be included in the message - it has the minimum-maximum MTU encoded in the IP Length. If "fragment zero" is not there, it should be easy to use a fragment with "the largest size"; this might require a little extra code in the hosts, but it only costs cycles when needed, and is in the hosts and not the gateways. The ICMP message is returned to the originating host; the route that it takes does not matter - symmetric or asymmetric. The datagram may get lost(1), but then any IP based technique has the same problem. If the problem is persistent, one should get through. The originating host receives the message and the ICMP routines use the very strong hint about the path MTU to update whatever table it uses to record such information (this may require some additional code in the hosts) before passing the message on to the higher level protocol involved. One can use any desired "filtering" algorithm to set thresholds for when to decide it is appropriate to change the MTU vs letting higher level reliability mechanisms deal with the problem. All of the mechanisms used in this technique are allowed by the current specifications, so phase-in and backward compatibility should not be a problem. It isn't perfect, but seems like an engineering compromise that has several advantages over other schemes. Notes: 1. I would suggest that control traffic, e.g., ICMP be given a little priority in gateways when deciding which packets to drop. Dropping control traffic doesn't sound like a good idea in general. 2. An IP entity can "force" a probe by forcing a reassembly timeout. It can construct, for example, a "large" ICMP echo request setting the more fragments bit (but never sending the "last" fragment) (and probably a low TTL). It would get the path MTU and, by definition, timeout and be returned. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12351362954.26.NIC@SRI-NIC.ARPA] <1987111707030600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NIC@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: REMINDER OF WEEKDAY ARPANET TESTING!! Message-ID: <12351362954.26.NIC@SRI-NIC.ARPA> Date: Tue, 17-Nov-87 12:03:06 EST Article-I.D.: SRI-NIC.12351362954.26.NIC Posted: Tue Nov 17 12:03:06 1987 Date-Received: Fri, 20-Nov-87 21:49:50 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ######################################################################### ************************************************************************* !!! REMINDER !!! *TOMORROW*, 18 November, between the hours of 13:00 and 16:00 EDT the entire ARPANET will be cutover to the new End-to-End protocol (PSN 7.0) for operational verification. At the end of this test period, the network will be returned to the old End-to-End protocol. Hosts experiencing problems are asked to call the the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992. ************************************************************************** ########################################################################## !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! There will be a follow-up meeting on November 20, 10:30 am to discuss the status of the ARPANET beta testing of the new End-to-End protocol at the Washington Building, Room 201, 7600 Old Springhouse Road, McLean, VA. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111707390000> Received: from MEAD.SCRC.Symbolics.COM ([128.81.41.234]) by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 09:40:19-PST Received: from SWAN.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 111279; Tue 17-Nov-87 12:40:07 EST Date: Tue, 17 Nov 87 12:39 EST From: David C. Plummer Subject: smtp on Symbolics lisp machines To: KENSICKI , tcp-ip@SRI-NIC.ARPA In-Reply-To: <353@vilya.UUCP> Message-ID: <19871117173931.3.DCP@SWAN.SCRC.Symbolics.COM> Date: 12 Nov 87 15:32:22 GMT From: clyde!motown!vilya!rhk@rutgers.edu (KENSICKI) Does anyone have any expierence running tcp on Symbolics 3640's and 3675's ? We've installed an ethernet in our building and are using tcp to transfer files from unix (Wollygong tcp on a 3b2-400) to the Symbolics. We also have a AT&T 6300 using tcp from FTP Software. The problem is that while ftp works fine we can't get smtp to work. It seems that the Symbolics doesn't follow the format of smtp and usr a CR NL at the end of a line. We added a Sun 2 as a reference machine to clear up finger pointing at Wollygong. With this group of machines smtp works fine between the Sun, the 3b2, and the pc. To add to the confusion the smtp on the pc works to the Symbolics as well as to the others? Any thoughts would be appreciated. As a reference, we send mail (such as this message) and receive mail (such as your message) from all sorts of the Internet hosts using SMTP using LispMs at our end. You don't say if SMTP works between the Sun and the Symbolics. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111708420000> Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 10:43:14-PST Received: from FLIGHTLESS-WATERFOWL.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 141417; Tue 17-Nov-87 13:42:17 EST Date: Tue, 17 Nov 87 13:42 EST From: Eric S. Crawley Subject: ARP hello packets To: tcp-ip@SRI-NIC.ARPA Message-ID: <19871117184200.5.CRAWLEY@FLIGHTLESS-WATERFOWL.SCRC.Symbolics.COM> I know this has been discussed on this list before, but I don't know if a consensus was reached. Are there any implementations out there that broadcast an ARP "hello" at boot time? A "hello" is an ARP reply packet that contains the hardware and protocol address of the machine being booted so that other machines can record its address resolution for future use. If anyone has done this, what values are put in the target protocol and hardware address fields of the packet? Do any implementations send such "hello"s before they send a broadcast for some specific service (eg. time)? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111709070300> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 11:02:57-PST Date: Tue, 17 Nov 87 14:07:03 EST From: Ross Callon To: yakov@IBM.COM cc: tcp-ip@SRI-NIC.ARPA, rcallon@PARK-STREET.BBN.COM Subject: re: Source Routing Jacob; The possibility of having the first gateway compute a complete source route and add the route to the packet is an interesting one, which has been discussed for quite a while now. The biggest problem with it is the computation involved with changing the IP header (at the first gateway) and parsing the header (at other gateways). This problem is a result of the way that the IP header is defined (and is at least as bad for the ISO IP), but could be solved by alternate encodings. The degree to which you care about processing depends upon the processing power of the gateway, relative to the bandwidth of its interfaces. In particular, do your gateways have processing power to spare? Inserting a source route at the first gateway requires recomputing the checksum, which kills the end-to-end nature of the checksum computation (I personally don't care that much about this). Also note that the ISO IP, with 20 octet addresses (maximum size) and a 254 octet maximum header size, does not leave room for all that many addresses in the source routing field (the exact number depends upon the actual address size used, whether the segmentation part of the header is there, and the presence of other options). In the case of multiple-autonomous systems, assuming some future inter-AS protocol, you probably don't want a gateway to have complete knowledge of the internals of other ASs. This implies that you would not be able to produce a complete source route (as you suggested), but still may use a similar idea with partial source routes (which may specify gateways, or may specify AS numbers or something else). One obvious question is why would you want to do this? There are several reasons that I can think of: (1) to avoid looping and other routing problems; (2) to relax the requirement of SPF that different gateways all have consistent databases; (3) to allow different sources to have different routing policies; (4) to allow the source to route different packets along different paths; or (5) for some different encoding, to minimize the work required of intermediate "transit" gateways along the path. I'm not convinced that avoiding looping is really the reason for using this scheme. Our experience is that, given well chosen metrics, SPF routing really works pretty well. The degree to which the NSF network is having trouble with routing is due to the particular routing algorithm that they are using, not due to any need for a previously unthought-of approach to routing. I think this is more or less why there is the beginning of an effort in IETF to develop a new (probably SPF-based) routing scheme that would be "public domain" and well specified via future RFCs. If you use source routing, you still must require that all gateways have databases which are correct in the sense that any link that they think is there really is. Thus link failures would still have to be reported very quickly. However, it would be possible to report other news (such as a new link coming up, or the change in "cost" of a link) more slowly. I'm still not sure that this is such a big deal because (1) I think that "costs" on operational links should not be allowed to change rapidly in any case; and (2) when new links come up, it should first be determined that the link is really stable up, and then all nodes will probably want to hear about this quickly. On the other hand, there may be some minor benefit in not needing to propagate most routing updates at quite so high a priority. The idea of allowing sources to have different routing policies is an important one in inter-AS routing, but I don't see it as very important in intra-AS routing. We (at BBN) have plans to use a sort of source routing in the Arpanet to allow multi-path routing for load splitting and congestion control purposes. Note that in order to do anything that resembles optimal multipath routing, you are required to do either (1) source and destination based routing (i.e., each node calcualtes and maintains a separate route for every source-destination pair, rather than just for every destination); or (2) source routing. Since we build all of the PSNs in the Arpanet, we are able to define a header encoding which makes source routing very efficient (actually more efficient than regular routing table lookups). Similarly, Butterfly gateways do something that resembles partial source routing in order to optimize the path lookup. As an IP datagram passes through an AS consisting of Butterfly gateways, the first gateway encodes the datagram in a "gateway to gateway header" which specifies the last gateway in the AS. The transit gateways only have to look at a very small exit gateway ID in the gateway to gateway header in order to route the packet. The exit gateway (the last gateway in the AS to deal with the packet) then removes the gateway to gateway header. This approach minimizes the processing required at intermediate gateways, and allows IP level routing to be separated into two logically separate steps (i) determining the exit gateway for a particular destination network or IP address; (2) determining the route to that particular exit gateway. If we were to extend routing to deal with partitioned networks, only step (1) would be effected. This may potentially be useful for other purposes as well. For example, the exit gateway may be chosen based on load sharing or other criteria. I think that if we are to use your suggestion and use source routing (whether partial or complete), we would need to either redefine the IP encoding, or do something similar and add a gateway to gateway header with a more efficient encoding. This latter approach would allow the hosts to remain unaffected by the change. Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111713052700> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 00:15:59-PST Received: from WEIZMANN.WEIZMANN.AC.IL by wiscvm.wisc.edu ; Tue, 17 Nov 87 02:15:17 CDT Received: by WEIZMANN (Mailer X1.25) id 8045; Tue, 17 Nov 87 09:58:48 +0200 Date: Tue, 17 Nov 87 09:45:27 +0200 From: raanan michael Subject: Re: Ethernet versions To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message of 11 Nov 87 00:46:14 GMT from ethernet , iee802.3 and trasceiver connector pin assingment. pin number ethernet function iee 802.3 function ------------------------------------------------------------------------ 1 chassis ground collission shield 2 collition presence + collition presence + 3 transmit + transmit + 4 unused receive shield 5 receive + receive + 6 power return power return 7 unused control out + 8 unused control out shield 9 collition presence collition presence 10 transmit - transmit - 11 unused transmit shield 12 receive - receive - 13 power power 14 unused power shield 15 unused control out + shell classis ground classis ground ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111715521600> Received: from athos.rutgers.edu ([128.6.5.46]) by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 17:54:37-PST Received: by athos.rutgers.edu (5.54/1.14) id AA18008; Tue, 17 Nov 87 20:52:16 EST Date: Tue, 17 Nov 87 20:52:16 EST From: hedrick@athos.rutgers.edu (Charles Hedrick) Message-Id: <8711180152.AA18008@athos.rutgers.edu> To: YAKOV@ibm.com Cc: tcp-ip@sri-nic.arpa In-Reply-To: <111287.142523.yakov@ibm.com> Subject: Re: Solicitation for comments In the NSFnet at least, we are moving towards segmented or hierarchical routing. It is unlikely that any gateway will know the whole route for a trans-continental packet. We do not know any routing technology that is currently up to handling the entire Internet as a single-level metric. Thus we expect each campus, each regional, and backbones such as Arpanet and NSFnet backbone, to be "autonomous systems". They will exchange mostly reachability information. Your own system will know a reasoanble exit gateway for each destination, but may not know the exact route that will be used to get to the final gateway. Thus a complete source route is not going to work. It may be that loose source routing might be useful, to specify which AS's are to be traversed. However I don't know of anyone involved in setting up IP routing that is anxious to get involved in this approach. If the gateways that go between the AS's can get their act together, there should be no need to do source routing. I see the primary disadvantage as being that the amount of data needed to do a source route is going to be larger than that required to do just the next hop. I think source routing may in fact be useful for specifying major routing policy decisions. That is, if a campus has a couple of major networks, one that is congested but free and another that is pay, the user may be asked to specify that he wants to pay by using a source route. That would probably be a loose source route with just one entry, the gateway between the campus and the pay network. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111716263800> Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 18:24:12-PST Date: Tue, 17 Nov 87 21:26:38 EST From: "James B. VanBokkelen" Subject: Re: smtp on Symbolics lisp machines To: clyde!motown!vilya!rhk@RUTGERS.EDU cc: tcp-ip@SRI-NIC.ARPA Message-ID: <287381.871117.JBVB@AI.AI.MIT.EDU> I would guess that they looked at what they were getting from a mis-configured 4.2 system when they designed their SMTP, and decided that that was right, rather than the RFC. 4.2 systems require an extra argument in sendmail.cf to cause a TCP mailer to use CR LF. This is essentially undocumented, and many amateur surgeons pruned the wrong mailer definition when adapting a distributed file, or left it out of a homebrew file. Our first parser only accepted CR LF, and we got burned by having numerous support calls, each requiring that we walk the customer through changing his sendmail.cf. In the next release, we accepted either form. Berkeley has accepted either form since 4.2, but the requirement for the extra argument makes me think that they started out not conforming... James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111716343200> Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 18:32:31-PST Date: Tue, 17 Nov 87 21:34:32 EST From: "James B. VanBokkelen" Subject: Re: Name Server for Ultrix 2.0 To: CF4A8X%IRISHMVS.BITNET@MITVMA.MIT.EDU cc: tcp-ip@SRI-NIC.ARPA Message-ID: <287386.871117.JBVB@AI.AI.MIT.EDU> I just built Berkeley bind v4.7.2 (current, I think) on my 2.0 Ultrix, and it runs just fine. All I had to do was modify the makefiles a little so that they would look at the distributed include directory first (which has 4.3 modifications in it), before the Ultrix /usr/include directory (which still uses the 4.2 netdb.h on 2.0). It was the first time I'd ever built bind, and it took about 2 hours work (of course, I didn't have to set up the configuration, we had been using 4.5 previously). jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111716463300> Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 18:44:09-PST Date: Tue, 17 Nov 87 21:46:33 EST From: "James B. VanBokkelen" Subject: Re: SMTP on Symbolics LISPMs To: tcp-ip@SRI-NIC.ARPA Message-ID: <287394.871117.JBVB@AI.AI.MIT.EDU> Something I did not make clear in my first posting is that the defintion of SMTP says that each command is terminated by a CR LF (or CR NL if you prefer). Anyone who sends text terminated by only LF is *wrong*. However, enough Berkeley-derived systems (Wollongong VMS is descended from Berkeley 4.1C) do so that most robust SMTP servers accept either. If TWG has retained the sendmail.cf, it may even be possible to re-configure it (and it may be local mis-configuration in the first place). jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111717380200> Received: from athos.rutgers.edu ([128.6.5.46]) by SRI-NIC.ARPA with TCP; Tue 17 Nov 87 19:47:43-PST Received: by athos.rutgers.edu (5.54/1.14) id AA19614; Tue, 17 Nov 87 22:38:02 EST Date: Tue, 17 Nov 87 22:38:02 EST From: hedrick@athos.rutgers.edu (Charles Hedrick) Message-Id: <8711180338.AA19614@athos.rutgers.edu> To: lekash@orville.nas.nasa.gov Cc: Mills@udel.edu, tcp-ip@sri-nic.arpa, ineng-interest@isi.edu In-Reply-To: <8711131654.AA07454@orville.nas.nasa.gov> (lekash@orville.nas.nasa.gov) Subject: Re: Life after source quench Over the weekend we found a bug in bind 4.7 that would lead to uncontrolled streams of requests to name servers. Indeed the same bug exists as far back as 4.4, but may not have quite the same drastic effect in earlier releases. The nature of the bug is that when bind sends a reply, it does not always have the bit turned on that declares it to be a response. To see why this has the effect, consider the two-level server configuration supported by 4.7. There are 3 primary name servers at Rutgers. All other name servers forward requests to one or more of them. Suppose a random server tries to do a lookup of a name that for some reason can't be resolved. It will forward the request to one or more of the primary servers. They will send requests to the appropriate servers, one of which is presumably yours. Once this times out (presumably because all of the servers for the domain are dead or something), the primary server will send a message back to the original one saying with no answer. However if the response bit is off, this will look like a request. The original name server will now send off requests to each of the 3 primary servers, and the cycle will restart. Note that one initial request has now led to 3 new queries, one triggered by the answer from each of the primary servers. Unfortunately, bind does not detect when it is being asked identical questions. (It does detect duplicates, in the sense of a query with the same query ID being issued several times. But in this case each new query will have a different ID.) Thus we have an explosion, which ultimately will be limited only by our name servers' CPU and the transmission line. The servers involved are a Sun 3, a Sun 4, and a Pyramid, and we feed into NSFnet with a T1 line. I believe we are capable of saturating the NSFnet backbone. I think this explains the observed results. We have fixed the bug in bind, and have not seen any storms such as this since. There was one additional problem. The reason we were attacking your server in the first place was because we had the wrong list of root servers. Unlike some earlier releases, bind 4.7 keeps track of root servers dynamically. It writes out the current state of its cache every hour. When the system is rebooted, it starts from the most recent cache state, not from a cold start. So if it once gets a bad root name server, and if that server lists itself as a root name server, this server will continue being used as a root forever. Furthermore, if the bad server is on NSFnet, it will have better response than the real root servers, and so will be used preferentially. So all it takes is for your server to get listed once as a root server. That is very easy to happen. Bind's basic algorithm is the following: send a request to an appropriate name server if there is an answer return it to the user and terminate put all data from the response into the cache, whether it is an answer, in the authority section, or additional data recompute the appropriate set of name servers to use Because it puts all data from the authority and additional data sections into the cache, all it needs is for one server to list you as a root server in the authority section of a response. We regard this as a bug, and have fixed it. We no longer accept root name server information unless it is in the answer section of the response. Unless there is a serious bug in somebody's code, root NS records will get into an answer section only if we ask explicitly who the root NS records are. We will only ask that question of an existing root server. Since we put that patch in, we have stopped seeing random hosts showing up as root name servers. While we have fixed these bugs, there are presumably many other sites out there that still have them. Both problems are present in all versions of bind that we know. I have posted these problems to the mailing list of 4.7 beta-testers. I have an annotated listing of all of our patches for anyone that wants to put them into their own copy of 4.7, or indeed an earlier release. Please tell me if you see any other misbehaviors caused by our name servers. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111721012600> Received: from sonora.dec.com by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 12:00:40-PST Received: from armagnac.dec.com by sonora.dec.com (5.54.4/4.7.34) id AA21172; Wed, 18 Nov 87 10:21:34 PST Received: from localhost by armagnac.DEC.COM (5.54.3/4.7.34) id AA19564; Wed, 18 Nov 87 10:21:30 PST Message-Id: <8711181821.AA19564@armagnac.DEC.COM> To: slevy@umn-rei-uc.ARPA (Stuart Levy) Cc: tcp-ip@sri-nic.ARPA Subject: Re: Telephone Access Controllers (TACs) and SLIP... In-Reply-To: slevy@umn-rei-uc.arpa's message of Sun, 15 Nov 87 10:24:48 -0600. <8711151624.AA26353@uc.msc.umn.edu> Date: Wed, 18 Nov 87 10:21:26 -0800 From: kent@decwrl.dec.com Methinks we should solve this once and for all, one way or another. Otherwise, we're doomed to resurrect the same problem set every six months until eternity. As I've said before, I believe in having fixed addresses attached to dialup clients. Password protection seems adequate authentication. The typical riposte comes from someone who wants to have lots of PCs attached, and doesn't want to have to pass out authentication and address information (and update it and manage it and so on). I sympathize, and haven't yet been inspired to find a middle ground (though I'm not convinced it's as big a problem as some would have me believe). People in this building are using dial up SLIP from home computers. At boot time, the home machine dials the IP server and logs it with a login name derived from the home machine's host name. The server now knows the client's name, and all is happy, with no real protocol added to SLIP itself. This seems to work just fine for our situation. Cheers, chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711181317.AA08570@ucbvax.Berkeley.EDU] <1987111803190900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: idle chatter about reference models Message-ID: <8711181317.AA08570@ucbvax.Berkeley.EDU> Date: Wed, 18-Nov-87 08:19:09 EST Article-I.D.: ucbvax.8711181317.AA08570 Posted: Wed Nov 18 08:19:09 1987 Date-Received: Sat, 21-Nov-87 04:38:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Mike, I'd say HMP belonged at the transport layer. It can be reasonably neatly dropped into a binary bsd kernel as a transport protocol, and it has the usual transport functions (transport user addressing, sequence numbers, etc). As for the four level ARM -- I recently argued to someone that we're approaching five levels: Application [Presentation] Transport Internetwork Network The argument being that while we have no standard Presentation layer, we are certainly using presentation schemes (XDR, Courier, ASN.1, multimedia formats, etc.) Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111803325900> Received: from icase.arpa by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 05:32:15-PST Received: from work15.icase by icase.arpa (3.2/SMI-3.0DEV3) id AA03945; Wed, 18 Nov 87 08:33:49 EST Notice: icase.arpa is at 128.102.23.51. Update host tables. Received: by work15.icase (3.2/SMI-3.0DEV3) id AA18151; Wed, 18 Nov 87 08:32:59 EST Date: Wed, 18 Nov 87 08:32:59 EST From: doug@icase.arpa (Doug Peterson) Message-Id: <8711181332.AA18151@work15.icase> To: tcp-ip@sri-nic.arpa Subject: nameserver on Suns Cc: doug@work15 Has anyone out there had any experience with Sun's nameserver? It would be useful to know things like: 1. Can I set this up and try it WITHOUT affecting the way things are done presently? There's no reason that the user community should suffer. 2. What can I expect to happen when I start up the deamons? (Whch daemons are necessary and sufficient?) 3. How can I tell if things are working (or not)? 4. Is it possible (advisable) to put up parts of this, or should it be done all at once? I envision something like "rlogin host" would query some designated nameserver for "host's" IP address. 5. What else is necessary to get sendmail to query the nameserver? Thanks in advance. Doug Peterson Systems Manager ICASE Mail Stop 132C NASA Langley Research Center Hampton, VA 23665-5225 (804) 865-4090 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111804100100> Received: from manta.nosc.mil by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 12:14:54-PST Received: by manta.nosc.mil (5.58/1.27) id AA04010; Wed, 18 Nov 87 12:10:01 PST Date: Wed, 18 Nov 87 12:10:01 PST From: ron@manta.nosc.mil (Ron Broersma) Message-Id: <8711182010.AA04010@manta.nosc.mil> To: BILLW@mathom.cisco.com, chris@gyre.umd.edu, dlw%opal.Berkeley.EDU@violet.berkeley.edu, tcp-ip@sri-nic.arpa Subject: Re: Telephone Access Controllers (TACs) and SLIP... We have implemented such a service locally. Our slip "server" (currently on a vax running 4.3) listens on a bunch of tty ports allocated to this service for slip requests. As soon as it gets carrier on one of the ports, it accepts various requests, one of which is "slip ". Then it sends back the IP address, netmask, and default gateway to be used by the caller. The caller can then send IP packets out its RS-232 port, packaged with slip. This is the way many of our PCs talk via our Sytek LAN if they don't have ethernet access. The reason we bypass getty/login is for speed reasons. In some cases the userid and password are optional which allows very quick setup of the SLIP link. It doesn't have to be done this way, most would want to implement this scheme by logging in through a login port and then issue a command to enter SLIP mode. The way we generate IP addresses is to have a specific address per port on the server. All these ports are on the same subnet. It doesn't really seem to matter that the PCs accessing the net via SLIP don't have fixed IP addresses. You only have to allocate one address per server port and you don't have to worry about setting up a new IP address every time somebody gets a new PC (and we already have over 3000 of 'em). Routing is easy since we put them all on a separate subnet. It would be very nice if we could agree on a "SLIP link establishment protocol" so we don't come up with multiple schemes for doing the same thing, all totally incompatible. My scheme works but could be improved. It solves the general problem for us but should allow the case where the client has a fixed IP address and/or hostname. --Ron ron@nosc.mil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111804145900> Received: from topaz.rutgers.edu by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 06:17:25-PST Received: by topaz.rutgers.edu (5.54/1.14) id AA19653; Wed, 18 Nov 87 09:14:59 EST Date: Wed, 18 Nov 87 09:14:59 EST From: ron@topaz.rutgers.edu (Ron Natalie) Message-Id: <8711181414.AA19653@topaz.rutgers.edu> To: Kastenholz@mit-multics.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: RPC/NFS over IP Routers Rutgers runs NFS file systems through I/P routers. The ones we are currently using are from cisco, but what I have to say should be true for any manufacturer. We bridge both Ethernet to Etherent and Ethernet through T1 line to Ethernet. The fileserver on the far side of the T1 line from the rest of the network has it's own local paging area and root and usr, but gets a lot of the users' home directories from NFS mounts. We limit our NFS configurations by the following parameters: 1. No paging or root access through the gateway. Every workstation either has local disk, or is on the same Ethernet as a file server providing these. 2. The rsize/wsize parameters in the NFS mount need to be cranked down a bit or else wierd (NFS Server not responding/OK) symptoms arrive. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111804191800> Received: from RUTGERS.EDU by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 15:15:04-PST Received: by RUTGERS.EDU (5.54/1.14) with UUCP id AA07520; Wed, 18 Nov 87 18:18:27 EST Received: by cmcl2.NYU.EDU (5.54/25-eef) id AA09539; Wed, 18 Nov 87 16:44:41 EST Received: by hp-pcd.HP.COM (5.51/4.7) id AA29860; Wed, 18 Nov 87 12:23:12 PST Received: from drizzle.uoregon.edu by mist.uoregon.edu; Wed, 18 Nov 87 12:19:29 PST Received: by drizzle.uoregon.edu; Wed, 18 Nov 87 12:19:18 PST Date: Wed, 18 Nov 87 12:19:18 PST From: JQ Johnson Message-Id: <8711182019.AA17629@drizzle.uoregon.edu> To: tcp-ip@sri-nic.arpa Subject: lieing about the subnet mask Cc: raf@nihcu.BITNET RAF@NIHCU.BITNET recently asked about multiple IP subnets on a single wire and similar permutations of the homogeneous one subnet per wire IP layout. A number of people responded to him by mail suggesting that he lie to some hosts about the subnet mask. To simplify the example, suppose that we have 2 connected Ethernet cables configured as two subnets of a class B net: subnet A, 128.223.8.0, whose hosts think the subnet mask is 255.255.255.0 (8-8); subnet B, 128.223.16.0, whose hosts think the subnet mask is 255.255.240.0 (4-12). Given most current subnetting implementations, hosts must think the class B network is homogeneous. Thus, hosts on A think that there are 15 8-bit subnets 128.223.16.0, 128.223.17.0 ...; hosts on B think that A is part of a 4-12 subnet. Note that hosts on B *must* route to subnet 128.223.9.0 (if it exists) through the same gateway as they route to subnet A [though redirects may change the routes to individual hosts on 128.223.9.0]; thus the physical topology should be hierarchical. And the gateway's RIP code needs to be hacked to advertise on A not just 128.223.16.0 but 128.223.16+x.0. OK, so if the connection topology is hierarchical and we have control over the gateway code, then the routing seems to work. But what happens with broadcast addresses? Suppose a host on A sends to 128.223.8.255. For the gateway to know this is a broadcast, its subnet mask must be the same as the host's. Similarly for B -- a local broadcast to 128.223.31.255 on cable B needs to be interpreted as a local broadcast by the gateway; if the gateway thinks it has 16 addresses on cable B and that the subnet mask on B is 8-8, it will interpret this as a letter bomb (aka directed broadcast) destined for subnet 128.223.31.0, and may well rebroadcast it on the same cable! That would lead to meltdown. Even if the gateway doesn't forward letter bombs, it needs to be able to generate broadcasts on B itself. So the gateways need to be smart and have different subnet masks for the two subnets. They can't fake it by considering the larger subnet to be several small subnets; they must have the same view as do the hosts on the subnet. Note that it is impossible for hosts to send directed broadcasts -- a host on A who wants to send a directed broadcast to B will send to 128.223.16.255 or something, which the gateway had better interpret as a host address on B. So we've made directed broadcasts impossible; bfd perhaps, but a violation of the RFCs. And I bet we can't run a stock 4.3BSD system as the gateway. The KA9Q code probably works (?). We'd better not allow any hosts on subnet B to have addresses of the form 128.223.16+x.255 (x={0,...,14} either, since that looks like a broadcast address from the viewpoint of a host on A. What else breaks? I dunno. None of the above is particularly disasterous, and a site trying it may get good enough performance and connectivity to think it's working even if there are hidden serious problems. However, it is complex enough that I'm worried that something else which IS disasterous will come along. The apparently innocuous suggestion has certainly increased the complexity of the protocol substantially! Am I being a nervous nellie? Has anyone analyzed this carefully? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111805135900> Received: from BITSY.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 07:31:49-PST Received: by BITSY.MIT.EDU (5.45/4.7) id AA00275; Wed, 18 Nov 87 10:13:59 EST Date: Wed, 18 Nov 87 10:13:59 EST From: Jeffrey I. Schiller Message-Id: <8711181513.AA00275@BITSY.MIT.EDU> To: hedrick@ATHOS.RUTGERS.EDU Cc: Mills@UDEL.EDU, lekash@orville.nas.nasa.gov, tcp-ip@SRI-NIC.ARPA, ineng-interest@VENERA.ISI.EDU In-Reply-To: Charles Hedrick's message of Fri, 13 Nov 87 17:36:44 EST <8711132236.AA04413@athos.rutgers.edu> Subject: Life after source quench Who says SRI-NIC knows who the root servers are. Below is the contents of a NS lookup of the root servers directed to SRI-NIC. Note that it lists itself, C.ISI.EDU (which is shutoff today), BRL-AOS.ARPA and A.ISI.EDU. However for additional records it only supplies an A record for SRI-NIC and BRL-AOS. C.ISI.EDU and A.ISI.EDU are not provided with A records. -Jeff Begin enclosure: E40-311B-2% bindtest -r 10.0.0.51 > n. res_mkquery(0, ., 1, 2) res_send() HEADER: opcode = QUERY, id = 1, rcode = NOERROR header flags: qdcount = 1, ancount = 0, nscount = 0, arcount = 0 QUESTIONS: ., type = NS, class = IN got answer: HEADER: opcode = QUERY, id = 1, rcode = NOERROR header flags: qr aa qdcount = 1, ancount = 4, nscount = 0, arcount = 4 QUESTIONS: ., type = NS, class = IN ANSWERS: . type = NS, class = IN, ttl = 604800, dlen = 14 domain name = SRI-NIC.ARPA . type = NS, class = IN, ttl = 604800, dlen = 11 domain name = C.ISI.EDU . type = NS, class = IN, ttl = 604800, dlen = 14 domain name = BRL-AOS.ARPA . type = NS, class = IN, ttl = 604800, dlen = 11 domain name = A.ISI.EDU ADDITIONAL RECORDS: SRI-NIC.ARPA type = A, class = IN, ttl = 604800, dlen = 4 internet address = 26.0.0.73 SRI-NIC.ARPA type = A, class = IN, ttl = 604800, dlen = 4 internet address = 10.0.0.51 BRL-AOS.ARPA type = A, class = IN, ttl = 604800, dlen = 4 internet address = 128.20.1.2 BRL-AOS.ARPA type = A, class = IN, ttl = 604800, dlen = 4 internet address = 192.5.25.82 > End Enclosure. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111806023900> Received: from UDEL.EDU by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 09:47:09-PST Received: from huey.udel.edu by Louie.UDEL.EDU id ac16471; 18 Nov 87 11:02 EST Date: Wed, 18 Nov 87 11:02:39 EST From: Mills@UDEL.EDU To: Craig Ruff cc: tcp-ip@sri-nic.arpa Subject: Re: Life after source quench Message-ID: <8711181102.aa10168@Huey.UDEL.EDU> Craig, Thanks for the info. You might do all of us a great favor by landing the issue on IBM's palm. That host is causing real pain on the NSFNET Backbone. Specifically, it would be just peachy if it responded to ICMP source-quench messages. Now, the only way we can deal with it is to further fine-tune the selective-preemption algorithm to discriminate against those hosts of heavy hand. Dave  ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711181455.AA09911@ucbvax.Berkeley.EDU] <1987111807195300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: ARP and various things other than ethernet.... Message-ID: <8711181455.AA09911@ucbvax.Berkeley.EDU> Date: Wed, 18-Nov-87 12:19:53 EST Article-I.D.: ucbvax.8711181455.AA09911 Posted: Wed Nov 18 12:19:53 1987 Date-Received: Sat, 21-Nov-87 09:43:29 EST References: <12350362501.9.BILLW@MATHOM.CISCO.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 isn't any reason why ARP can be used, more or less as-is, for any hardware network having a broadcast concept... .. or even any network with a distinguished, well known address, by which you reach the server(s) that store the address information. There is no philosophical need to have the data base distributed to the level that each host stores only that part of the data base that pertains to it. However, it definitely is convenient to have the host in charge of its own data. I just wanted to make the point that address FFFFFFFFFFFF is not magic, nor is broadcast. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111809435100> Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 11:44:20-PST Received: from beno.CSS.GOV by seismo.CSS.GOV (5.54/1.14) id AA03057; Wed, 18 Nov 87 14:43:53 EST Received: by beno.CSS.GOV (5.54/5.17) id AA10480; Wed, 18 Nov 87 14:43:51 EST Date: Wed, 18 Nov 87 14:43:51 EST From: rick@seismo.CSS.GOV (Rick Adams) Message-Id: <8711181943.AA10480@beno.CSS.GOV> To: craig@nnsc.nsf.net, tcp-ip@sri-nic.arpa Subject: Re: dial-up SLIP Cc: billw@mathom.cisco.com, dlw%opal.berkeley.edu@violet.berkeley.edu This has been done with pretty good success in Japan using Sun's and Unix. I'll try and dig up the paper that discusses it (an old SIGCOMM newsletter?) --rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19186@amdcad.AMD.COM] <1987111812494000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rpw3@amdcad.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet versions Message-ID: <19186@amdcad.AMD.COM> Date: Wed, 18-Nov-87 17:49:40 EST Article-I.D.: amdcad.19186 Posted: Wed Nov 18 17:49:40 1987 Date-Received: Sat, 21-Nov-87 06:55:05 EST References: <8711141736.AA21062@topaz.rutgers.edu> Reply-To: rpw3@amdcad.UUCP () Organization: [Consultant] San Mateo, CA Lines: 61 In article <8711141736.AA21062@topaz.rutgers.edu> Ron Natalie writes: +--------------- | On the coax there is no differenece electrically between Version I | Version II, and IEEE 802.3. +--------------- Weeeelll... almost. There WAS a teensy change in the electrical spec on the coax between Ethernet Version 1.0 (Sep'80) and Version 2.0 (Nov'82), having to to with tightening the specs on the drive current (or at least changing the way the A.C. versus D.C. components were specified). See Section 7.3.2 "Coaxial Cable Signaling" in each version (p.61 in ver 1.0, p.72 in ver 2.0). The net effect was to change the shape of the AC/DC schmoo slightly. Very slightly. There IS one significant change to that section in the 2.0 spec. The following sentence is added: "The transceiver shall be able to produce its specified output current onto the coaxial cable with at least one other transceiver transmitting simultaneously." That sentence made it official that receiver-based collision detection shall be possible, by requiring that the current source in a transceiver's transmitter not wimp out until the cable voltage was AT LEAST twice the normal max peak voltage. All practical "current sources" have a "maximum compliance voltage" above which they quit being true current sources. (A "perfect" current source would increase its voltage without limit, even to the point of arcing over if you tried to disconnect it!) All of the current sources in the popular Version 1.0 transceivers had plenty of compliance; the 2.0 spec just made it official. Why all the trouble? Well, if you are going to build a repeater, it's important that you be able to creat "carrier" on the "other" side of the repeater whenever you see carrier on "this" side (or a "jam" on the other side whenever you see "collision" on this side). But in the case of several transceivers transmitting at once, the current sources will saturate and all the A.C. signal will disappear in the large D.C. offset. It is important that this not happen at a voltage lower than the repeater could reliably detect as a collision, when it itself was not transmitting. Furthermore, I've been told that the tightening of the A.C. versus D.C specs I mentioned above helped solve a possible ambiguity: In the case where a repeater is at one end of a maximally-loaded cable and there is a collision between two wimpy transmitters at the far end, the tightened spec plus the tightened "voltage compliance" guaranteed that the repeater would see it as a collision, and not interpret it as a single nearby macho transmitter. Again, it's no big deal. All (?) of the 1.0 vendors' transceivers worked (and work) just fine on a mixed 1.0/2.0/IEEE_802.3 cable. It just needed to be said explicitly in the spec. Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711150235.AA27649@nisc.nyser.net] <1987111817144700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: fedor@NISC.NYSER.NET (Mark Fedor) Newsgroups: comp.protocols.tcp-ip Subject: Strange returned mail. Message-ID: <8711150235.AA27649@nisc.nyser.net> Date: Wed, 18-Nov-87 22:14:47 EST Article-I.D.: nisc.8711150235.AA27649 Posted: Wed Nov 18 22:14:47 1987 Date-Received: Sat, 21-Nov-87 12:53:15 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 I just received about 7 messages like the one that follows. I'm clueless as to why I got them. I never tried to send to this place. Is this another one of those unsolved network mysteries? Any answers? clues? Thanks. Mark ------- Forwarded Message Return-Path: postmaster%odin.re.nta.uninett@TOR.NTA.NO Received: by nisc.nyser.net (5.54/1.14) id AA08642; Fri, 13 Nov 87 12:13:14 EST Date: Fri, 13 Nov 87 16:43:08 +0100 Posted-Date: Fri, 13 Nov 87 16:43:08 +0100 Message-Id: <8711131543.AA10354@tor.nta.no> Received: by tor.nta.no (5.54/3.21) id AA10354; Fri, 13 Nov 87 16:43:08 +0100 To: fedor@nisc.nyser.net From: UNINETT-ARPA Gateway Subject: EAN Mail Network -- failed mail Status: RO Mail Failure Diagnostics: Rejected-Message-id: <8711060340.AA17823@nic.nyser.net> Message Recipients: baard@vax.elab.unit.uninett: maximum time expired ------- End of Forwarded Message ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19.NOV.1987.00:36:53.LAWS@RSRE] <1987111822360000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LAWS@rsre.mod.UK.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <19.NOV.1987.00:36:53.LAWS@RSRE> Date: Thu, 19-Nov-87 03:36:00 EST Article-I.D.: RSRE.19.NOV.1987.00:36:53.LAWS Posted: Thu Nov 19 03:36:00 1987 Date-Received: Sat, 21-Nov-87 16:11:41 EST References: <8711140153.AA09162@sccgate.scc.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Mike, I view EGP, GGP and HMP as Management protocols - for which await the Management Addendum etc to the OSI model now nearing draft standard status. The OSI model deals with issues for host-to-host open interworking. 10 years ago network providers were seen to be large public utilities that would resolve their internetworking problems in their private club (=CCITT). The world and technology has moved on, other (many) network providers are a reality. Hence the OSI model must now enbrace the concepts of management in a more public way. Your diagram might mislead the reader into thinking that internetworking is not an issue in ISORM. The network service is the Global Network Service and contains all conforming interconnected ISORM subnets. I do not consider it a sensible question to ask which layer a specific management protocol is in. Rather it stands off to one side as an application (maybe using the full stack of protocols for some part of its job - access to a directory service?) while supporting a layer in providing its service. ISORM may be applied recursively, direct or indirect. In my own work I have used the X25 VC service as a point-to-point link to connect an IP gateway to a host. The usage as an on-demand point-to-point link has considerable economic and time savings when that usage is infrequent. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111822560000> Received: from NSS.Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 19:42:12-PST Received: from rsre.mod.uk by NSS.Cs.Ucl.AC.UK via PSS with NIFTP id aa00420; 19 Nov 87 1:02 GMT To: "Michael J. O'Connor" <@NSS.Cs.Ucl.AC.UK:oconnor@sccgate.scc.com> Cc: tcp-ip <@NSS.Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa> From: John Laws (on UK.MOD.RSRE) Date: Thu, 19 Nov 87 00:36 In-reply-to: <8711140153.AA09162@sccgate.scc.com> Message-Id: <19 NOV 1987 00:36:53 LAWS@RSRE> Subject: Re: Idle chatter about reference models Mike, I view EGP, GGP and HMP as Management protocols - for which await the Management Addendum etc to the OSI model now nearing draft standard status. The OSI model deals with issues for host-to-host open interworking. 10 years ago network providers were seen to be large public utilities that would resolve their internetworking problems in their private club (=CCITT). The world and technology has moved on, other (many) network providers are a reality. Hence the OSI model must now enbrace the concepts of management in a more public way. Your diagram might mislead the reader into thinking that internetworking is not an issue in ISORM. The network service is the Global Network Service and contains all conforming interconnected ISORM subnets. I do not consider it a sensible question to ask which layer a specific management protocol is in. Rather it stands off to one side as an application (maybe using the full stack of protocols for some part of its job - access to a directory service?) while supporting a layer in providing its service. ISORM may be applied recursively, direct or indirect. In my own work I have used the X25 VC service as a point-to-point link to connect an IP gateway to a host. The usage as an on-demand point-to-point link has considerable economic and time savings when that usage is infrequent. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [135@tsdiag.UUCP] <1987111903382800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tom@tsdiag.UUCP Newsgroups: comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip Subject: Standard for Printers Message-ID: <135@tsdiag.UUCP> Date: Thu, 19-Nov-87 08:38:28 EST Article-I.D.: tsdiag.135 Posted: Thu Nov 19 08:38:28 1987 Date-Received: Fri, 27-Nov-87 23:47:19 EST Organization: Concurrent Computer Corp. Neptune, NJ Lines: 33 THIS IS A FORWARDED MESSAGE Follows is the *REAL* header: From: n2dsy@hou2d.UUCP (G.BEATTIE) Organization: AT&T Bell Laboratories, Holmdel Date: 12 Nov 87 21:09:05 GMT I have been looking around for something similar to the ANSI X3.64 Terminal Protocol Specification for printers or printing terminals. I guess that in some "ideal" world we would have something analogous to the Virtual Terminal Protocol for printers, but I am willing and seeking suggestions regarding printer standards for simple and medium-complexity printers. Please don't tell me about Centronics interfaces - that's hardware cabling. What I'm interested in is carriage control, carriage size, forward and backward vertical and horizontal tabs, etc... Any thoughts ? Thanks, J. Gordon Beattie, Jr. Unix: ihnp4!hou2d!n2dsy Voice: (201) 387-8896 Amateur: n2dsy @ kd6th/3100201 Home: (201) 615-4168 (FAX x4669) -- Thomas A. Moulton, W2VY Life is too short to be mad about things. Home: (201) 779-W2VY Packet: w2vy@kd6th Voice: 145.190 (r) Work: (201) 492-4880 x3226 FAX: (201) 493-9167 Concurrent Computer Corp. uucp: ...!ihnp4!hotps!ka2qhd!w2vy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111904280000> Received: from rvax.ccit.arizona.edu ([128.196.1.3]) by SRI-NIC.ARPA with TCP; Thu 19 Nov 87 11:03:01-PST Date: Thu, 19 Nov 87 11:28 MST From: ALMA_GRIJALVA Subject: RE: Re: TCP-IP in the Public Domain? To: TCP-IP@sri-nic.arpa X-VMS-To: IN%"TCP-IP@sri-nic.arpa" The complete address for SRI is: Stanford Research Inst. - Net. Info. Center Room EJ291 333 Ravenwood Avenue Menlo Park, CA 94025 Tele# 415-859-5539 alg. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711191433.AA23384@spam.istc.sri.com] <1987111904333300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kozel@SPAM.ISTC.SRI.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Slang Glossary Message-ID: <8711191433.AA23384@spam.istc.sri.com> Date: Thu, 19-Nov-87 09:33:33 EST Article-I.D.: spam.8711191433.AA23384 Posted: Thu Nov 19 09:33:33 1987 Date-Received: Sat, 21-Nov-87 15:42:12 EST References: <8711072213.AA19075@athos.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 (This note really pertains to AWKing cisco gateway output) In an earlier note you mentioned some AWK filters you have to parse the cisco statistics dumps; could these be made available or mailed to me? We want to do the same thing; your effort would certainly save some time. thanks, Ed Kozel SRI International ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]19-Nov-87.10:28:05.CERF] <1987111905280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <[A.ISI.EDU]19-Nov-87.10:28:05.CERF> Date: Thu, 19-Nov-87 10:28:00 EST Article-I.D.: <[A.ISI.EDU]19-Nov-87.10:28:05.CERF> Posted: Thu Nov 19 10:28:00 1987 Date-Received: Sun, 22-Nov-87 07:54:47 EST References: <8711140153.AA09162@sccgate.scc.com> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 The inter-gateway routing algorithms really do sit above the Internet Layer and thus occupy the same space as the Transport Layer - though their function is not specifically transport - that is one reason that I have always been a little uncomfortable with the ISO model with its apparently rigid specification of functionality at each layer. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111905280001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 19 Nov 87 08:44:31-PST Date: 19 Nov 1987 10:28-EST Sender: CERF@A.ISI.EDU Subject: Re: Idle chatter about reference models From: CERF@A.ISI.EDU To: oconnor@SCCGATE.SCC.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]19-Nov-87 10:28:05.CERF> In-Reply-To: <8711140153.AA09162@sccgate.scc.com> The inter-gateway routing algorithms really do sit above the Internet Layer and thus occupy the same space as the Transport Layer - though their function is not specifically transport - that is one reason that I have always been a little uncomfortable with the ISO model with its apparently rigid specification of functionality at each layer. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711191605.AA29043@vger] <1987111906053200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tucker%vger@GSWD-VMS.GOULD.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: 4.3BSD TCP problem Message-ID: <8711191605.AA29043@vger> Date: Thu, 19-Nov-87 11:05:32 EST Article-I.D.: vger.8711191605.AA29043 Posted: Thu Nov 19 11:05:32 1987 Date-Received: Sun, 22-Nov-87 07:11:43 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 We are having trouble using Berkeley 4.3 TCP over very slow network connections (9600 baud). Sometimes connections just get stuck. Both hosts are running the same Berkeley software. This happens even if the hosts are connected directly to each other by the slow network link. Below is a trace of the packets being sent back and forth. This continues forever. The connection is in the following state: local host connection says it is in: CLOSE_WAIT remote host says the connection is in: FIN_WAIT_2 here are the packets that bounce back and forth: sent: 45 0 0 29 6 fa 0 0 1e 6 79 4c a 1e 4 3b a 1e 4 13 2 2 3 f4 4 69 e2 2 4 4b 9c 50 50 10 10 0 f6 4c 0 0 0 ... (41 bytes) recv: 45 0 0 28 6 fe 0 0 1e 6 79 49 a 1e 4 13 a 1e 4 3b 3 f4 2 2 4 4b 9c 51 4 69 e2 3 50 10 10 0 f6 4b 0 0 ... (40 bytes) it just keeps going on forever (at least an hour) Does anyone have any idea what is happening? I would appreciate any comments! Thanks. Tim Tucker Gould CSD tucker@gswd-vms.gould.com. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2968@batcomputer.tn.cornell.edu] <1987111906344400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mqh@batcomputer.UUCP Newsgroups: comp.protocols.tcp-ip Subject: FIN problem in Berkeley 4.3? Message-ID: <2968@batcomputer.tn.cornell.edu> Date: Thu, 19-Nov-87 11:34:44 EST Article-I.D.: batcompu.2968 Posted: Thu Nov 19 11:34:44 1987 Date-Received: Sat, 21-Nov-87 14:50:19 EST Distribution: comp Organization: Theory Center, Cornell U., Ithaca NY Lines: 16 Keywords: TCP,FIN Hello, We're running a Gould here with Berkeley networking code. It would appear that when a TCP connection is closed, and the FIN is retransmitted for some reason, it's sequence number is one too low. The sequence number is correct on the first transmission. I've looked into "tcp_output.c", and it is marked as "7.2.1.1 ... 3/28/87". The code looks correct by casual inspection, at least. Can anyone shed some light on the problem before I spend time trying to debug this in UNIX? -- Mike Hojnowski (Hojo) {ihnp4,rochester}!cornell!batcomputer!mqh ICBM 042N 29 076W 27 mqh@batcomputer.tn.cornell.edu "With friends like that, who needs enemas?" - Max Headroom ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111907360000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Fri 20 Nov 87 13:27:43-PST Received: from UIAMVS.BITNET by wiscvm.wisc.edu ; Fri, 20 Nov 87 14:54:49 CDT Date: Thursday 19 Nov 87 12:36 PM CT From: Jay Ford (U of Iowa) To: TCP/IP mailing list Subject: help This is a request for network configuration suggestions. Any responses should be sent to me rather than to the list. Questions How have other sites approached and/or solved the problems associated with establishing and administering large campus networks? Is the topology outlined below feasible without having static, manually-entered routes for the entire campus? Will an ARP (or any) ethernet-level broadcast from a host on one ethernet make it through a gateway to a host on another ethernet? Will the ARP reply make it back to the broadcaster? Is it necessary to have something along the lines of proxy-ARP to make this work? Does existing software support proxy-ARP? Does anyone have suggestions addressing problems at any level which would alleviate some of the routing complexity? Notes We are new at this, and very well might have incorrect interpretations of the problems we face. By the same reasoning, we certainly are not aware of all the possible solutions to our problems. Any help would be appreciated. Thank you. Background The University of Iowa is in the process of establishing a campus network consisting of departmental LANs hung off of a broadband backbone. The departmental nets use various technologies including Ethernet/IEEE 802.3, proprietary token rings, and fiber. Some departments have multi-level networks (see figure below). Access to the broadband backbone is provided through ethernet bridges (Bridge IB/1 boxes), with each department having one IB/1. The IB/1 is a MAC-level bridge, so that a host on a baseband ethernet connected to an IB/1 in one department appears to be on the same physical cable as a host on a baseband ethernet connected to an IB/1 in another department. We have a mixture of machines and OSs, including VAXes running 4.2 & 4.3 BSD, VAXes running VMS, Encores running UMAX 4.2, Apollos, Suns, PCs, Primes, and IBMs running MVS; we also have a handful of Encore Annex terminal servers. The U of Iowa has been granted a class B Internet number of 128.255. We will soon activate a connection to MIDnet -> NSFnet -> world. Topology The current network topology (with only two departments connected) is: || Annex1 ---| || +------+ | ||---| IB/1 |-----(ethernet1)-----| || +------+ | || Encore1 ---| || |--- Encore2 (broadband) | || |--- Alliant || | +------+ || |-----(ethernet2)-----| IB/1 |---|| | +------+ || |--- VMSVax1 || +---------+ | ||---| Proteon |----> (MIDnet) |--- Apollo1 || +---------+ | --- / \ / \ (Apollo-ring) \ / \ / |--- BSDVax1 --- | | |--- BSDVax2 Apollo2 ----(ethernet3)----| |--- BSDVax3 We would like to assign a subnet number to each physical network. For example: network internet subnet ------- --------------- ethernet1 128.255.32 ethernet2 128.255.22 ethernet3 128.255.20 Apollo ring 128.255.21 Problems The presence of independently administered networks within the campus lends itself to a subnetting scheme, with each department receiving a block of subnet numbers from which to allocate numbers for the networks under the control of the department. We have encountered some routing problems which may be attributable to the coexistence of IP implementations which do support subnetting and those which do not. The broadband bridging makes ethernet1 and ethernet2 appear to be one physical network, so we end up with one network having more than one subnet number. This seems to cause problems with routing for the hosts which understand subnetting. They think the hosts on the other subnet should be on a different physical network and expect to have a gateway to get there. Since there is no gateway, they don't see a path to the other subnet. Disabling subnetting (by changing the netmask to 255.255.0.0 in the subnetting hosts) makes everybody think that the entire campus is one big physical (class B) network. This solves the problem just described, but it defeats the subnet-based routing required to access the networks which are actually subnetted, such as Apollo-ring and ethernet3. One proposed solution is to place a router between the IB/1 and the networks within each department. This has the advantage of making the broadband a separate subnet and providing the gateways (arguably) needed for subnet-based routing as described above. Disadvantages include the decrease in throughput (compared to just the bridge), the added cost of the router (or an additional ethernet interface for a host acting as a router), and the restriction on the protocols which may then cross the broadband. Furthermore, I am not convinced that such a configuration would solve all our problems without introducing new ones. Jay Ford Weeg Computing Center University of Iowa Iowa City, IA 52242 (319) 335-5555 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711200700.AA11193@ucbvax.Berkeley.EDU] <1987111908280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ALMA@RVAX.CCIT.ARIZONA.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: RE: Re: TCP-IP in the Public Domain? Message-ID: <8711200700.AA11193@ucbvax.Berkeley.EDU> Date: Thu, 19-Nov-87 13:28:00 EST Article-I.D.: ucbvax.8711200700.AA11193 Posted: Thu Nov 19 13:28:00 1987 Date-Received: Sun, 22-Nov-87 06:31:41 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 The complete address for SRI is: Stanford Research Inst. - Net. Info. Center Room EJ291 333 Ravenwood Avenue Menlo Park, CA 94025 Tele# 415-859-5539 alg. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711191851.AA13481@athos.rutgers.edu] <1987111908511200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ATHOS.RUTGERS.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Terminal server efficiency Message-ID: <8711191851.AA13481@athos.rutgers.edu> Date: Thu, 19-Nov-87 13:51:12 EST Article-I.D.: athos.8711191851.AA13481 Posted: Thu Nov 19 13:51:12 1987 Date-Received: Sun, 22-Nov-87 07:02:22 EST References: <1135@saturn.ucsc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Our tests also showed that a small window can significantly increase the CPU time on hosts that are talking to a terminal server. Thus I regard small windows as a significant problem. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [694@hubcap.UUCP] <1987111909144800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hubcap@gatech.UUCP Newsgroups: comp.protocols.tcp-ip Subject: perpetual connection Message-ID: <694@hubcap.UUCP> Date: Thu, 19-Nov-87 14:14:48 EST Article-I.D.: hubcap.694 Posted: Thu Nov 19 14:14:48 1987 Date-Received: Sat, 21-Nov-87 16:01:53 EST Organization: Clemson University, Clemson, SC Lines: 32 Keywords: florida down volume box millwright I wonder what's going on here? I am not sure how long this has been going on, but I have noticed the following connection between my machine and utah-arpa-gw.arpa for the last few days: (edited output of "netstat -a" follows...) ---------------------------------------------------------------------------- Active connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) . . . tcp 0 0 hubcap.clemson.e.2462 utah-arpa-gw.arp.telne FIN_WAIT_2 . . . ---------------------------------------------------------------------------- Note: sometimes the state is "ESTABLISHED", other times, FIN_WAIT_2... I was curious at first when I saw it, but there's lots of users here, and its none of my business where they telnet to... then I noticed that this connection was still present immediately after a reboot. So, to make a long story short, this connection has been here constantly for at least a week (probably longer). Does anyone want to hazard a guess as to what the deal might be? thanks... Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap ----MESSAGE-END---- ----MESSAGE-BEGIN---- [25@musky2.EDU] <1987111910025900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: terrell@musky2.UUCP Newsgroups: comp.protocols.tcp-ip,comp.sys.mac Subject: Does CMU TCP/IP work with MacIP? Message-ID: <25@musky2.EDU> Date: Thu, 19-Nov-87 15:02:59 EST Article-I.D.: musky2.25 Posted: Thu Nov 19 15:02:59 1987 Date-Received: Sun, 22-Nov-87 04:37:07 EST Reply-To: terrell@musky2.UUCP (Roger Terrell) Distribution: world Organization: Muskingum College, New Concord, OH Lines: 21 We are trying to get CMU's TCP/IP package to work with MacIP via ethernet with the Kinetics FastPath box. So far, all I have succeded in doing is causing the name server to die (ODD ADDRESS EXCEPTION) on the VAX end (where the CMU package is running). To begin with, are the two compatible at all? This is the first time we have experimented with networking, so no one here is very familiar with it. Any further info anyone might have on using either package would also be helpful. Please send responses by E-mail if possible. Thanks, Roger -- Roger Terrell Muskingum College ...cbosgd!musky2!terrell (UUCP) New Concord, OH 43762 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711192306.AA02695@ucbvax.Berkeley.EDU] <1987111914202800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hinden@PARK-STREET.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <8711192306.AA02695@ucbvax.Berkeley.EDU> Date: Thu, 19-Nov-87 19:20:28 EST Article-I.D.: ucbvax.8711192306.AA02695 Posted: Thu Nov 19 19:20:28 1987 Date-Received: Sat, 21-Nov-87 17:44:06 EST References: <8711140153.AA09162@sccgate.scc.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Mike, I enjoyed you reference to HMP being in the "Massachusetts" layer. It might be more accurate to say that it is in the Massachusetts "stack" :-). I do think it is correct that is should be shown as a transport layer protocol. EGP, GGP, and other similar internet protocols provide services normally thought of as in the transport [, presentation ?] and application layers. The output of these protocols are used to provide routing data for the internet layer. I don't think that this puts them in the internet layer. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711192329.AA03145@ucbvax.Berkeley.EDU] <1987111914270500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@NNSC.NSF.NET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: dial-up SLIP Message-ID: <8711192329.AA03145@ucbvax.Berkeley.EDU> Date: Thu, 19-Nov-87 19:27:05 EST Article-I.D.: ucbvax.8711192329.AA03145 Posted: Thu Nov 19 19:27:05 1987 Date-Received: Sat, 21-Nov-87 17:44:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 At CSNET we're experimenting with an idea which is close to this. The basic idea is that when an IP packet hits our gateway destined for a remote machine we make a phone call, establish the link, and keep it running as long as there is continued traffic. When the traffic stops, we shut down the line. There are lots of nasty little problems in this scheme: - The TCP SYN takes a huge hit for establishing the phone call. So the initial RTT estimate will be much too high. - Topology. That SYN probably can't take multiple hops in which the phone gets dialed. (We're using a star topology with gateway in the center). - How to maintain line quality. We know how variable long-distance connectivity is. Interestingly, keeping track of when the line is busy probably isn't a problem (we already had to handle that problem in X25Net). Also note that this system is designed to support more than IP. We want to be able to use more than IP over the interface (line control packets, ISO IP, XNS, etc). So we had to put leaders in. Finally, address mapping is fixed. Each address is assigned, and we do a deterministic IP address to phone # mapping to do the phone call. We then log in at the remote end, and start up the line protocol. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711200048.AA29552@cs.utah.edu] <1987111914481600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cetron@CS.UTAH.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: perpetual connection Message-ID: <8711200048.AA29552@cs.utah.edu> Date: Thu, 19-Nov-87 19:48:16 EST Article-I.D.: cs.8711200048.AA29552 Posted: Thu Nov 19 19:48:16 1987 Date-Received: Sun, 22-Nov-87 07:52:35 EST References: <694@hubcap.UUCP> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: cs.utah.edu!cetron@cs.utah.edu (Edward J Cetron) Organization: Center for Engineering Design, Univ of Utah Lines: 19 Keywords: florida down volume box millwright I just check out cisco box (utah-arpa-gw) and it had two idle incoming sessions from hubcap.clemson.edu showing idle for 3 days+ and originating at hubcap. It appears like somebody is telnetting to our gateway, and then into some other machine.... This may be because with the egp/ggp problems, the can't reach the 128.110.xx.xx addresses any other way. Given the load on our cisco, and assuming there is a legitimate user at clemson trying to telnet into our 128.110 net, I would think that a static route (oh how horrible :-) ) would be better then tying up band- width in the gateway. Any comments from the net at large? -ed cetron cetron@cs.utah.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [288670.871119.JBVB@AI.AI.MIT.EDU] <1987111918224600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Terminal server efficiency Message-ID: <288670.871119.JBVB@AI.AI.MIT.EDU> Date: Thu, 19-Nov-87 23:22:46 EST Article-I.D.: AI.288670.871119.JBVB Posted: Thu Nov 19 23:22:46 1987 Date-Received: Sun, 22-Nov-87 09:58:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 If the window is smaller than the MSS, the MSS doesn't matter much - you'll never see a packet bigger than the window. I have observed the 164-byte window feature in Bridge, and the fact that at least one of their products only sends 82 bytes (I hesitate to guess why..) in a packet, no matter how much output is pending. This is a box that serves as a milking machine, attached to a host via async lines. I think window (or MSS, whichever is the limiting factor) is an important consideration. I have found that it affects throughput a lot, even in telnet output situations. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711200414.AA08439@ucbvax.Berkeley.EDU] <1987111919083800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haverty@CCV.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <8711200414.AA08439@ucbvax.Berkeley.EDU> Date: Fri, 20-Nov-87 00:08:38 EST Article-I.D.: ucbvax.8711200414.AA08439 Posted: Fri Nov 20 00:08:38 1987 Date-Received: Sat, 21-Nov-87 18:22:33 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 To throw mny two cents in... I think HMP isn't "in the stack" at all, in the sense that it is NOT part of a user data communications activity. HMP is an application top level protocol, between an entity at one end, i.e., the monitoring/management operation, and an entity at the other end, i.e., the piece of code down within some computer somewhere that is watching the activity within that computer and interacting with the management site. IN other words, the participants in HMP are just like any other network users such as FTP or a data query and retrieval system; it just happens to be the case that their activity is associated with the operational management of a communications system. Consider for example if an HMP-like protocol were used to monitor the CPU-load and disk-activity of a distributed collection of Unix systems, i.e., like a constantly running remote "dpy" or "ps". In this case it's pretty clear that the protocol between the players is an application in itself; HMP differs only in that it is looking at the operation of components of a data communications system. Jack PS to Dave Mills -- I do "read the mail" on the list all the time, just a little slow in diving in. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [20.NOV.1987.00:32:44.LAWS@RSRE] <1987111922320000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LAWS@rsre.mod.UK.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <20.NOV.1987.00:32:44.LAWS@RSRE> Date: Fri, 20-Nov-87 03:32:00 EST Article-I.D.: RSRE.20.NOV.1987.00:32:44.LAWS Posted: Fri Nov 20 03:32:00 1987 Date-Received: Sun, 22-Nov-87 09:53:47 EST References: <[A.ISI.EDU]19-Nov-87.10:28:05.CERF> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 47 Vint, I have a different view about the ISO model. Its apparent rigid specification of functionality is only on issues that were seen to be needed to have open systems - any vendor host to any vendor host via any network provider. That said there is in fact enough protocol choice in the layers that communities of interest are selecting 'protocol stacks' to limit the number of protocols required in a single host. When networks were seen by the standards makers as being just the public utility of CCITT there was no need to make ISO standards for how to build or manage the network. CCITT would do that. It is now accepted that other network providers will exist in great number (well at least in the UK and US). Hence public standards must be stated for the management of this internet. Note: the assumption is still that a single vendor will provide the subnet and hence we do not require public standards for that internal issue. I agree its probably the case that my view is not the common one stated by ISO experts. But look at the selling problem they had. If you and I are to have choice in our vendors and still communicate then standards are required. The scale on which this has/had to be done is very large relative to run-of-the-mill standards. (By-the-by I happen to think the OSI work has been done in double quick time; checkout the timescale for standards on slings and hooks.) Just as in politics, large market, complex issues, limited time = keep the message simple. Now there are two sorts of OSI experts - those who really are and often have dirty hands and scars from past experience, and those who have read the 'books' from their armchair. The first may cut corners to put the message across in a few minutes but know its more complex. The second only know what is in the 'books'. My experience of standards committees UK BSI and ISO is that most members working on OSI are the first. And just so that there is no mis-understanding between us I do see you as being dead centre (center - I'm bilingual) in the first. (That goes for Mike Padlipsky as well - who if on form is composing a refutation of all I've said.) (To all you other readers - this makes a change to reading how the Internet is being RIPped apart.) Does the US State Dept read this list? Will my A-2 VISA be revoked? John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111922321300> Received: from devvax.TN.CORNELL.EDU ([128.84.253.200]) by SRI-NIC.ARPA with TCP; Fri 20 Nov 87 03:52:45-PST Received: by devvax.TN.CORNELL.EDU (5.54/1.3-Cornell-Theory-Center) id AA16534; Fri, 20 Nov 87 06:52:16 EST Message-Id: <8711201152.AA16534@devvax.TN.CORNELL.EDU> To: mqh@tcgould.tn.cornell.edu (Mike Hojnowski) Cc: tcp-ip@sri-nic.arpa Subject: Re: FIN problem in Berkeley 4.3? In-Reply-To: Your message of 19 Nov 87 16:34:44 +0000. <2968@batcomputer.tn.cornell.edu> Date: Fri, 20 Nov 87 06:52:13 -0500 From: Jeffrey C Honig >We're running a Gould here with Berkeley networking code. It would appear >that when a TCP connection is closed, and the FIN is retransmitted for some >reason, it's sequence number is one too low. The sequence number is correct >on the first transmission. >I've looked into "tcp_output.c", and it is marked as "7.2.1.1 ... 3/28/87". >The code looks correct by casual inspection, at least. >Can anyone shed some light on the problem before I spend time trying to >debug this in UNIX? Applying the following fix (in Mike Karel's form) fixed many symptoms of this problem on a uVAX running 4.3. Jeff ---------------- >From cpw Tue Sep 1 09:00:12 1987 >To: tcp-ip@sri-nic.arpa >Subject: Help with broken TCP >What follows is a TCP scenario observed on our local ethernet. The ftp >application (A) has just pushed out the last data block to (B) and is >closing the connection. The first FIN from (A) is lost. An ACK from (B) >for the last data block arrives. Then there begins a conversation of FIN(A) >then ACK(B) with longer and longer time intervals between each set of >FIN(A)/ACK(B) as if the ACK is being dropped and a retransmit timer is >backing off, firing and a FIN being sent. Notice that the sequence number >set in the retransmitted FIN packets is one less than that set in the lost >FIN packet. Are both peers broken or just the sender of the FINs? >This is a tcpdump. I added an * to indicate the lost packet. (In case >your curious, the packet is lost because of an inability to handle back >to back packets on the part of B) >15:31:36.86 A > B: S -1063845887:-1063845887(0) win 4096 >15:31:36.86 B > A: S 253698321:253698321(0) ack -1063845886 win 384 >15:31:36.86 A > B: . ack 1 win 4096 >15:31:37.12 A > B: P 1:146(145) ack 1 win 4096 >15:31:37.12 A >* B: F 146:146(0) ack 1 win 4096 >15:31:37.38 B > A: . ack 146 win 384 >15:31:39.12 A > B: F 145:145(0) ack 1 win 4096 >15:31:39.14 B > A: . ack 146 win 384 >15:31:41.12 A > B: F 145:145(0) ack 1 win 4096 urg 1 >15:31:41.14 B > A: . ack 146 win 384 >15:31:45.12 A > B: F 145:145(0) ack 1 win 4096 urg 1 >15:31:45.14 B > A: . ack 146 win 384 >15:31:53.12 A > B: F 145:145(0) ack 1 win 4096 urg 1 >and so on... >Phil Wood (cpw@lanl.gov) -------- >From cpw Tue Sep 1 14:28:46 1987 >To: tcp-ip@sri-nic.arpa >Subject: Re: Help with broken TCP >Status: RO >4.3BSD network bug (#9, tcp_output) had a fix for an undetected data >loss during connection closing. This may well have fixed the data loss >due to lost data segments, but, apparently it will cause the symptom >I reported if the data segment with FIN is lost. If the test: > if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && len == 0) >succeeds the #9 code decremented tp->sndnxt by one. Instead, I set >tp->snd_nxt = tp->snd_una, and the symptom went away. I'm not saying >this is a fix, but it may point more to the problem. >Phil Wood (cpw@lanl.gov) Here is a partial diff of the fix I have to tcp_output.c. *** tcp_output.c.orig Fri Apr 24 12:29:11 1987 --- tcp_output.c Wed Sep 2 12:29:09 1987 *** 231,237 **** * If resending a FIN, be sure not to use a new sequence number. */ ! if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && ! tp->snd_nxt != tp->snd_una) tp->snd_nxt--; ti->ti_seq = htonl(tp->snd_nxt); ti->ti_ack = htonl(tp->rcv_nxt); --- 237,246 ---- * If resending a FIN, be sure not to use a new sequence number. */ ! if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && len == 0) ! tp->snd_nxt = tp->snd_una; ti->ti_seq = htonl(tp->snd_nxt); ti->ti_ack = htonl(tp->rcv_nxt); *************** ------------------- >From: Mike Karels >To: "C. Philip Wood" >Cc: tcp-ip@sri-nic.arpa >Subject: Re: Help with broken TCP >Date: Tue, 01 Sep 87 15:33:38 PDT >Right you are! I knew that we had such a problem at one time, but didn't >think it had made it out of Berkeley. Your fix is fine; our current version >does: > if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && > tp->snd_nxt == tp->snd_max) > tp->snd_nxt--; >which should be equivalent. > Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987111922520000> Received: from NSS.Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Thu 19 Nov 87 17:34:10-PST Received: from rsre.mod.uk by NSS.Cs.Ucl.AC.UK via PSS with NIFTP id aa00598; 20 Nov 87 1:27 GMT To: CERF <@NSS.Cs.Ucl.AC.UK:CERF@a.isi.edu> Cc: tcp-ip <@NSS.Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa>, oconnor <@NSS.Cs.Ucl.AC.UK:oconnor@sccgate.scc.com> From: John Laws (on UK.MOD.RSRE) Date: Fri, 20 Nov 87 00:32 In-reply-to: <[A.ISI.EDU]19-Nov-87 10:28:05.CERF> Message-Id: <20 NOV 1987 00:32:44 LAWS@RSRE> Subject: Re: Idle chatter about reference models Vint, I have a different view about the ISO model. Its apparent rigid specification of functionality is only on issues that were seen to be needed to have open systems - any vendor host to any vendor host via any network provider. That said there is in fact enough protocol choice in the layers that communities of interest are selecting 'protocol stacks' to limit the number of protocols required in a single host. When networks were seen by the standards makers as being just the public utility of CCITT there was no need to make ISO standards for how to build or manage the network. CCITT would do that. It is now accepted that other network providers will exist in great number (well at least in the UK and US). Hence public standards must be stated for the management of this internet. Note: the assumption is still that a single vendor will provide the subnet and hence we do not require public standards for that internal issue. I agree its probably the case that my view is not the common one stated by ISO experts. But look at the selling problem they had. If you and I are to have choice in our vendors and still communicate then standards are required. The scale on which this has/had to be done is very large relative to run-of-the-mill standards. (By-the-by I happen to think the OSI work has been done in double quick time; checkout the timescale for standards on slings and hooks.) Just as in politics, large market, complex issues, limited time = keep the message simple. Now there are two sorts of OSI experts - those who really are and often have dirty hands and scars from past experience, and those who have read the 'books' from their armchair. The first may cut corners to put the message across in a few minutes but know its more complex. The second only know what is in the 'books'. My experience of standards committees UK BSI and ISO is that most members working on OSI are the first. And just so that there is no mis-understanding between us I do see you as being dead centre (center - I'm bilingual) in the first. (That goes for Mike Padlipsky as well - who if on form is composing a refutation of all I've said.) (To all you other readers - this makes a change to reading how the Internet is being RIPped apart.) Does the US State Dept read this list? Will my A-2 VISA be revoked? John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2458.564342605@limbo.uci.edu] <1987112000493100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: raj@limbo.uci.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet versions Message-ID: <2458.564342605@limbo.uci.edu> Date: Fri, 20-Nov-87 05:49:31 EST Article-I.D.: limbo.2458.564342605 Posted: Fri Nov 20 05:49:31 1987 Date-Received: Sun, 22-Nov-87 10:07:54 EST References: <184@bnl.ARPA> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 59 I got this from the little booklet that comes with our ST-500 transceivers that we bought from Cabletron. (Cute, each one comes with a really complete book telling all sorts of things about transceivers and such.) We always make sure our transceiver cables have pin 1 connected to ground. (Our Computing Facility used to connect pin 4 to ground to agree with 802.3 but then they couldn't be used on V2.0 so we always get pin 1 as ground now.) We've used the same transceiver cables on V1.0, V2.0, and 802.3. We have mixtures of all versions on the same ethernet with no problems although we're now trying to always go with 802.3 in the future. Hope all of this helps. V1.0 V2.0 IEEE 802.3 ----------------------------------------------------------------------- Transceiver (3) 22 AWG pairs (4) 20 AWG pairs (4) 20 AWG cable (1) 20 AWG inner Inner & outer pairs & outer shield shield common Inner & outer common at at backshell shield isolated backshell and and pin 1 from each other pin 1 Outer shield at backshell, inside at pin 4 Indented male connector for better electrical connection. Transceiver Full step Half step Half step No heartbeat Heartbeat Heartbeat (SQE) Grounding Pin 1 Pin 1 Pin 1, 4, 11 & 14 Ground indents on male connector. Jabber latching Repeater No requirements No requirements Redundant collision protection using Jam sequence, Segments excessive collision segment from network. Vendors Xerox, U-B, DEC U-B, 3COM, DEC, Gould, Harrris, Cabletron HP, Xerox, Cabletron Micom-Interlan, Intergraph, Cabletron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3362@hoptoad.uucp] <1987112002461300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gnu@hoptoad.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: dial-up SLIP Message-ID: <3362@hoptoad.uucp> Date: Fri, 20-Nov-87 07:46:13 EST Article-I.D.: hoptoad.3362 Posted: Fri Nov 20 07:46:13 1987 Date-Received: Sun, 22-Nov-87 06:42:44 EST References: <8711192329.AA03145@ucbvax.Berkeley.EDU> Organization: Nebula Consultants in San Francisco Lines: 92 UC Davis was doing a summer project with dialup slip. Their software is available on ucdavis.ucdavis.edu in the "pub/dialslip" directory, as I recall (don't you hate it how NOBODY gives a full and correct path for stuff available by anonymous ftp?). I haven't tried any of it yet. John Here's the README from ucdavis: This directory contains the first distribution of software used at UC Davis for dialin SLIP connections for the UCD Network. The complete system is a combination of patches for 4.3bsd and the CMU/IP software, plus new software for the dialin capability. The software comes in five tar files. Here is a description of what is in each tar file. 1. tiocgetu.tar This file contains patches and a new function for the 4.3bsd IO. A problem existed with 4.3 in the linkage of a SLIP interface and the actual device. The problem was this: The normal procedure to set up a SLIP was to ifconfig the interface to the desired parameters then slattach the device to this interface, BUT the slattach just grabs the first available interface which may or may not be the one that you just ifconfig'ed. This really becomes a problem when multiple SLIPs are comming and going randomly. To solve this problem, a patch was added to slattach to return the interface to which the device was connected. The returned interface can then be ifconfig'ed AFTER slattach has been connected to it. This makes sure that the associated device and interface are coordinated. To make things even easier, there is a new function included in this tar that does the the whole process, slattach and ifconfig, in one call. 2. dialslip.tar This file contains the software necessary to manage the dialin SLIP connections. The procedure for establishing a SLIP connection is to logon to the 4.3 computer and enter the slip command. After the command has been issued, the line becomes a SLIP connection. Disconnection is accomplished when the serial connection is lost (no carrier detect) and the line is then reset to a normal login line. Address assignment and security is provided by a file that associates an IP address with the usercode. A connection for a given IP address can only be made from the usercode to which that address is assigned in the configuration file. Of course the computer dialing in must also be configured for this address. The software also maintains a file of current connections that can be displayed to see wht SLIP connections are currently logged in. This file is also used by the system to make sure that the IP address is not already connected before making a new connection. If a person logs in on the same usercode twice at the same time, only the first SLIP connection will succeed. NOTE: the patches in tiocgetu.tar must be installed before the software in this tar will work. 3. cmuslip.tar These are patches to the CMU/IP software that do two things. One, makes the com port on the pc setable from the CUSTOM program, and two, fixes a bug that would briefly drop DTR on the com port during a SLIP connection. (for us that caused immediate disconnection :-}) 4. sterm.tar This is the CMU/IP terminal program with a script capability added. The script can be setup to allow connection to the network by automatically sending the sequence needed to dial the modem, logon, and send commands to connect to SLIP. The script can also wait for given strings to return to allow testing, timing out, and branching depending on what response is returned. 5. cmumakes.tar This file contains a new set of MAKE files for the CMU/IP software that are better (or at least different) than the standard ones. This tar also contains a new tarread program that allows extraction so subsets of the files in a tar file. The abbreviated IP packet software working but still has a couple of bugs we want to get out before releasing it. It should be ready in another week or so, but we wanted to make this available for those that want to get started. Russell Hobby Data Communications Manager U. C. Davis Computing Services BITNET: RDHOBBY@UCDAVIS Davis Ca 95616 UUCP: ...!ucbvax!ucdavis!rdhobby (916) 752-0236 INTERNET: rdhobby@ucdavis.edu -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com Love your country but never trust its government. -- from a hand-painted road sign in central Pennsylvania ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3363@hoptoad.uucp] <1987112002541200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gnu@hoptoad.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Instructions for creating a SLIP link Message-ID: <3363@hoptoad.uucp> Date: Fri, 20-Nov-87 07:54:12 EST Article-I.D.: hoptoad.3363 Posted: Fri Nov 20 07:54:12 1987 Date-Received: Sun, 22-Nov-87 06:44:28 EST References: <8711192329.AA03145@ucbvax.Berkeley.EDU> Organization: Nebula Consultants in San Francisco Lines: 148 {I wrote these as an addendum to Mark Weiser's instructions for installing slip into a binary Sun kernel, since he forgot to mention anything but the kernel modification. Mark's SLIP is available on mimsy.umd.edu.} The SIOCIFDETACH definition above should use a number that is not already in use; more recent Sun releases have already used ioctl (i, 23), so just pick a number beyond the last one they used. Also, make sure that both /usr/include/sys/ioctl.h and /usr/sys/h/ioctl.h are updated. They may be links or symbolic links, or may be separate files. The code I use has a fix from Chris Torek folded in, which improves the handling of when to start and stop the serial port. It also has the "sldetach" routine added to the end of the source, though I believe it is not called from the right place(s), or is not right, since you still end up burning an interface every time you lose a SLIP connection. The above description assumes you know how to configure a Sun or BSD kernel. If you don't, look in the system installation manual, it gives detailed instructions on this. You will have to make the changes specified above by Mark, (except the "pseudo-device" line), then do the kernel configuration process as documented in the manual, inserting the "pseudo-device" line into your custom config file. Run "/etc/config" then "make" then move the new kernel into the root directory, as e.g. "/vmunix.new". You will also have to allocate a bunch more "character lists (clists)" which are buffers for the serial ports -- you are driving these ports heavier than usual. Easiest way to do this is by patching your new kernel with adb before booting it. Do something like: adb -w /vmunix.new << FOO nclist?D -- display old value nclist?W 0t500 -- change to decimal 500 FOO Shut down the system with /etc/fasthalt, then boot it from the new kernel (b /vmunix.new). If it comes up and doesn't crash, things are in pretty good shape. Now to set up the slip link, compile "slattach" on both ends, then make sure the serial line between the machines is working (e.g. using "tip" on both ends, you should be able to type back and forth to each other). You will need to assign a network number (or subnet number, if your machines are using subnets) for the serial link itself; it is treated as a network with two hosts on it. Update /etc/networks on both systems with this number, and create new names for your two hosts (typically the original hostname plus a suffix like "-slip", e.g. "hoptoad-slip") in /etc/hosts, which have addresses on this new network. For example: /etc/networks: sun-ether 192.9.200 sunether ethernet localnet sliplink 192.33.33 srinet 128.18 /etc/hosts: # The Ethernet at one end 192.9.200.1 hoptoad hop toad loghost mailhost 192.9.200.2 polliwog polli wog 192.9.200.3 tadpole tad pole # The SLIP link 192.33.33.1 polli-slip 192.33.33.2 ws1-slip # The Ethernet at the other end 128.18.523 fs1 128.18.533 ws1 128.18.534 ws2 128.18.535 ws3 After updating these files at both ends, if you use the Bellow Pages, remake the database with (cd /usr/etc/yp; make hosts networks). Then run "slttach" on both ends, specifying the tty line, YOUR machine's name on the SLIP network, the other guy's name on the SLIP network, and the baud rate, e.g.: polliwog# slattach ttyb polli-slip ws1-slip 19200 ws1# slattach tty04 ws1-slip polli-slip 19200 You don't have to do these at the same instant. At this point you probably have an IP connection going; you should be able to see it by doing a "netstat -i". Next, try it with "ping". Watch the modem lights if you can, while it pings. On polliwog you would ping "ws1-slip". On ws1 you would ping "polli-slip". If that works, you can try an rlogin, telnet, or ftp. If it doesn't work, you should be able to see the packets go out over the modem "SD" (send data) light, but nothing will probably be coming back in on RD. That means the other end is not answering, so look there -- try netstat -i, ping from that end, etc. Be sure you specified the right parameters on both ends. You can pass packets now, but hven't figured out routing. If you are running "routed" on both machines, routed should figure out the routing for you. Within a minute or two of when the link comes up, a "netstat -r" should show a route to the remote Ethernet via the "sl0" interface on your machine. If you aren't running routed, you'll need to do "route add" commands. If one end is on the Arpa Internet, there are further complications. If any of your network numbers aren't known to the core gateways, other hosts will not be able to route packets to you. The main Internet gateways *do not* automagically notice new networks and figure out the routes, like Berkeley "routed" does. Somebody with the authority to tell them, has to tell them that you exist. If your SLIP network and your remote Ethernet, if any, are both subnets, then the normal Internet routing will get your packets back to your subnet, and you just have to make sure that the gateways inside your subnet know how to get to you. If all your gateways run "routed" this should happen automatically. You may want to add a "default route" on your remote Ethernet hosts which routes packets for any random network through the host on the Arpanet end of the SLIP link; this way you won't have to run a routing daemon to be able to talk to any network on the Internet. If the link goes down, you will probably have to reboot both systems to get them back in sync. The slip drivers are not robust enough, and can crash the system if you try to re-establish a link after you had one running. I think it'd be great if you fixed this...I don't know enough about what is going on to do so. I have tried running NFS over a SLIP link with Telebit 18,000 baud modems. It hung or crashed my systems until I allocated a bunch more "clists" (character queues for serial ports), as described under kernel configuration above. I did get NFS to work over the SLIP link though. It was not very fast, it didn't feel much like a disk, but if you are careful what you touch, it can be better than FTP and rcp for moving things around. I recommend unmounting things when not in use, lest people stumble on them and create immense amounts of traffic inadvertently. For example, most peoples' systems run a "find" command that scans the whole file system once a night. I recommend mounting file systems "intr" and with small blocks (512 bytes) and long timeouts; see the "mount" command man page. Good luck! This has been typed at about a month's remove from the last time I did it, so there may be errors in the procedures. If so, please send me email (gnu@toad.com, or hoptoad!gnu). Feel free to pass it on to other people. Mark owns the code and allows it to be distributed; and this description, by me, is in the public domain. Also, let me know if you successfully set up a SLIP link with these instructions -- or, even better, figure out how to let dialin users set up and tear down SLIP links on demand. John Gilmore -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com Love your country but never trust its government. -- from a hand-painted road sign in central Pennsylvania ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711201348.AA29943@monk.proteon.com] <1987112003482900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mac@MONK.PROTEON.COM (Michael A. Curtis) Newsgroups: comp.protocols.tcp-ip Subject: in.routed dying Message-ID: <8711201348.AA29943@monk.proteon.com> Date: Fri, 20-Nov-87 08:48:29 EST Article-I.D.: monk.8711201348.AA29943 Posted: Fri Nov 20 08:48:29 1987 Date-Received: Sun, 22-Nov-87 15:46:37 EST References: <8709291210.AA02469@work1.icase> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Doug, I was going through my old messages and came across this one from you. Are you still having problems with routed dying in your Sun machines? Mike Curtis Proteon, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112004250000> Received: from twg.arpa by SRI-NIC.ARPA with TCP; Fri 20 Nov 87 12:31:54-PST Date: 20 Nov 87 12:25:00 PST From: "Keith McCloghrie" Subject: Re: new BOF To: "ddp+" cc: , Drew, You say : > I am conducting a BOF at the upcoming TCP/IP conference in Arlington VA > called "Standard socket level interface for PC's". Are you specifically entitling the BOF such that discussion of interfaces other than socket-style, are out of order ? There have been some alternative suggestions which I think are worthy of discussion (eg. TLI, a standard driver interface). Keith McCloghrie The Wollongong Group. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12352127564.23.RADIA@XX.LCS.MIT.EDU] <1987112005031400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: radia@XX.LCS.MIT.EDU (Radia Perlman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <12352127564.23.RADIA@XX.LCS.MIT.EDU> Date: Fri, 20-Nov-87 10:03:14 EST Article-I.D.: XX.12352127564.23.RADIA Posted: Fri Nov 20 10:03:14 1987 Date-Received: Sun, 22-Nov-87 16:12:43 EST References: <[A.ISI.EDU]19-Nov-87.10:28:05.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 The Network Layer in ISO already has lots of sublayers, with catchy names like "Subnetwork Independent Convergence Protocol". With hierarchical routing, there's really a Network Layer sublayer dealing with each level of hierarchy. When you (according to ARPA terminology, I think) interconnect networks into an internetwork, I'd say you're just forming another layer of hierarchy on your network. That extra layer does involve adding a protocol layer onto what used to be your Network Layer. But it certainly doesn't go into the Transport Layer. It just makes your Network Layer fatter (makes a Network Layer that used to have k sublayers now have k+1 sublayers.) In general I agree that trying to take the ISO Reference Model too seriously leads to nonproductive metaphysical discussions, but I don't think hierarchical routing at the ISO Network layer breaks the model. Radia ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [408@cayman.UUCP] <1987112008012100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brad@cayman.UUCP (Brad Parker) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Lawrence Livermore IGP project? Message-ID: <408@cayman.UUCP> Date: Fri, 20-Nov-87 13:01:21 EST Article-I.D.: cayman.408 Posted: Fri Nov 20 13:01:21 1987 Date-Received: Sun, 22-Nov-87 22:15:26 EST Organization: Cayman Systems Inc., Cambridge Ma Lines: 21 References: Does anyone have any information on the Lawrence Livermore Lab Intelligent Gateway Processor (IGP) project? I have an abstract called "Gateway Technology as a Tool for Interoperability in the DAITC Information Network" and I'd like to get more information on this. Thanks. ps: when I was a kid we called it the "rad-lab"! I guess LLNL sounds better... -brad Brad Parker Cayman Systems harvard!cayman!brad -- Brad Parker Cayman Systems "Mama's little baby likes violent sex..." harvard!cayman!brad - from a song I heard on the radio. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711201833.AA25671@mitre.arpa] <1987112008332000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes Message-ID: <8711201833.AA25671@mitre.arpa> Date: Fri, 20-Nov-87 13:33:20 EST Article-I.D.: mitre.8711201833.AA25671 Posted: Fri Nov 20 13:33:20 1987 Date-Received: Sun, 22-Nov-87 17:23:40 EST References: <284985.871113.JBVB@AI.AI.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 27 In your note to nowicki@sun.com you described the difficulty of installing a new release and concluded with: >All of which is why many organizations which are setting up large networks >want homogenous hardware, rigid version control, and source code. Perhaps >the manufacturers should put on their thinking caps... I would like to understand the underlying rationale for your recommendations concerning source code, rigid version control, and homogenous hardware. I offer my speculations below and would like you to confirm/revise. Source Code: So that an organization can fix/improve the code themselves, or by a third party, and not have to depend on the original vendor. Does your recommendation change if software maintenance is in effect? Rigid Version Control: This has more to do with the organization's network than with vendors. The organization doesn't want two different versions of the same process to be in use. Homogenous Hardware: This one troubles me - I would like to think that through the use of standard protocols an organization could achieve interoperability among different hardware suites. What is your view of the matter? Regards - Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711202000.AA00513@apolling.imagen.uucp] <1987112010002900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: BSD 4.3 Sends data after FIN? Message-ID: <8711202000.AA00513@apolling.imagen.uucp> Date: Fri, 20-Nov-87 15:00:29 EST Article-I.D.: apolling.8711202000.AA00513 Posted: Fri Nov 20 15:00:29 1987 Date-Received: Sun, 22-Nov-87 22:38:25 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 I have a bug report from France (so it's not as clear as I'd like) that looks like 4.3 is sending data past a FIN. There is some error condition being exercised relating to a zero window, and the connection is terminated. A FIN appears with data in the packet. It is acked. Later, another packet is received with the same length (I don't know whether it is the same data), with the updated sequence number, and still with a FIN. Thus the data is logically after the first FIN. Can someone check this out? - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711220109.AA01621@ucbvax.Berkeley.EDU] <1987112010040900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BOARD@BITNIC.BITNET (BITNET Board of Trustees) Newsgroups: comp.protocols.tcp-ip Subject: BITNET-Internet Gateway Message-ID: <8711220109.AA01621@ucbvax.Berkeley.EDU> Date: Fri, 20-Nov-87 15:04:09 EST Article-I.D.: ucbvax.8711220109.AA01621 Posted: Fri Nov 20 15:04:09 1987 Date-Received: Mon, 23-Nov-87 05:46:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 The City University of New York, Princeton University, Cornell University, and Massachusetts Institute of Technology have each committed to provide gateway service for electronic mail between the BITNET network and the Internet. Current gateway services provided by the University of Wisconsin (WISCVM) will end on December 15, 1987. Prior to that date, at least two of the above announced gateways will be in operation in parallel with WISCVM - there will be no interruption in gateway services. Prior to a regionalization plan and significant coordination with the Internet, the most expeditious approach is to name the first few gateways the same, namely, INTERBIT. That would mean that any gateway-destined mail that landed at any INTERBIT node would be appropriately handled. This change will be reflected in the December DOMAIN NAMES file which is used for MAILER generation; users need not do anything - mail will go automatically to the closest gateway. This is a transition measure necessitated by the time frame, by the complexity of more desirable solutions, and by the need to coordinate more with the Internet. Plans are to regionalize gateway service between the networks in order to balance traffic flow and increase reliability. Several other institutions are seriously considering functioning as gateways. An analysis of topologically best locations for such gateways will be conducted under the auspices of the BITNET Board of Trustees' Technical Committee; and the BITNET Network Information Center will coordinate regionalization plans and associated software modifications. (Please note reference to Internet, rather than ARPANet, and Internet's inclusion of ARPANet, NSFNet, NYSERNET and the other regional networks.) BITNET Board of Trustees ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711202013.AA00515@apolling.imagen.uucp] <1987112010135900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: BSD 4.3 Terminates zero window connection Message-ID: <8711202013.AA00515@apolling.imagen.uucp> Date: Fri, 20-Nov-87 15:13:59 EST Article-I.D.: apolling.8711202013.AA00515 Posted: Fri Nov 20 15:13:59 1987 Date-Received: Sun, 22-Nov-87 22:37:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 A customer has reported that BSD4.3, if it is presented with a zero window, tries ONCE to push data through the window. If it receives no response, it closes the connection. There is a language problem between me the customer and the manuals, so maybe I don't understand what they are saying. Does this match 4.3 behavior? - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711210116.AA08826@ucbvax.Berkeley.EDU] <1987112010250000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kzm@TWG.ARPA ("Keith McCloghrie") Newsgroups: comp.protocols.tcp-ip Subject: Re: new BOF Message-ID: <8711210116.AA08826@ucbvax.Berkeley.EDU> Date: Fri, 20-Nov-87 15:25:00 EST Article-I.D.: ucbvax.8711210116.AA08826 Posted: Fri Nov 20 15:25:00 1987 Date-Received: Sun, 22-Nov-87 20:39:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Drew, You say : > I am conducting a BOF at the upcoming TCP/IP conference in Arlington VA > called "Standard socket level interface for PC's". Are you specifically entitling the BOF such that discussion of interfaces other than socket-style, are out of order ? There have been some alternative suggestions which I think are worthy of discussion (eg. TLI, a standard driver interface). Keith McCloghrie The Wollongong Group. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12352198711.24.NIC@SRI-NIC.ARPA] <1987112011340300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NIC@SRI-NIC.ARPA (DDN Reference) Newsgroups: comp.protocols.tcp-ip Subject: RE: Re: TCP-IP in the Public Domain? Message-ID: <12352198711.24.NIC@SRI-NIC.ARPA> Date: Fri, 20-Nov-87 16:34:03 EST Article-I.D.: SRI-NIC.12352198711.24.NIC Posted: Fri Nov 20 16:34:03 1987 Date-Received: Sun, 22-Nov-87 22:21:14 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 I would like to correct Alma's previous message regarding the complete address for the Network Information Center at SRI International. Our address is: DDN Network Information Center SRI International Room EJ291 333 Ravenswood Avenue Menlo Park, Ca. 94025 Our telephone numbers are: (800) 235-3155 (415) 859-3695 Nan/NIC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112012040900> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sat 21 Nov 87 16:12:32-PST Received: from BITNIC.BITNET by wiscvm.wisc.edu ; Sat, 21 Nov 87 18:11:38 CDT Received: by BITNIC (Mailer X1.24) id 0024; Fri, 20 Nov 87 16:04:40 EDT Date: Fri, 20 Nov 87 16:04:09 EDT From: BITNET Board of Trustees Subject: BITNET-Internet Gateway To: TCP-IP@SRI-NIC.ARPA The City University of New York, Princeton University, Cornell University, and Massachusetts Institute of Technology have each committed to provide gateway service for electronic mail between the BITNET network and the Internet. Current gateway services provided by the University of Wisconsin (WISCVM) will end on December 15, 1987. Prior to that date, at least two of the above announced gateways will be in operation in parallel with WISCVM - there will be no interruption in gateway services. Prior to a regionalization plan and significant coordination with the Internet, the most expeditious approach is to name the first few gateways the same, namely, INTERBIT. That would mean that any gateway-destined mail that landed at any INTERBIT node would be appropriately handled. This change will be reflected in the December DOMAIN NAMES file which is used for MAILER generation; users need not do anything - mail will go automatically to the closest gateway. This is a transition measure necessitated by the time frame, by the complexity of more desirable solutions, and by the need to coordinate more with the Internet. Plans are to regionalize gateway service between the networks in order to balance traffic flow and increase reliability. Several other institutions are seriously considering functioning as gateways. An analysis of topologically best locations for such gateways will be conducted under the auspices of the BITNET Board of Trustees' Technical Committee; and the BITNET Network Information Center will coordinate regionalization plans and associated software modifications. (Please note reference to Internet, rather than ARPANet, and Internet's inclusion of ARPANet, NSFNet, NYSERNET and the other regional networks.) BITNET Board of Trustees ----MESSAGE-END---- ----MESSAGE-BEGIN---- [269@mitisft.Convergent.COM] <1987112012331000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: andrew@mitisft.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: dial-up SLIP Message-ID: <269@mitisft.Convergent.COM> Date: Fri, 20-Nov-87 17:33:10 EST Article-I.D.: mitisft.269 Posted: Fri Nov 20 17:33:10 1987 Date-Received: Sun, 22-Nov-87 16:52:17 EST References: <8711192329.AA03145@ucbvax.Berkeley.EDU> Organization: Convergent Technologies, San Jose, CA Lines: 40 in article <8711192329.AA03145@ucbvax.Berkeley.EDU>, craig@NNSC.NSF.NET (Craig Partridge) says: > > > At CSNET we're experimenting with an idea which is close to this. > > The basic idea is that when an IP packet hits our gateway destined > for a remote machine we make a phone call, establish the link, and > keep it running as long as there is continued traffic. When the > traffic stops, we shut down the line. > We've had dial-up SLIP running for over a year internally here at Convergent, initially on a more-or-less straight 4.3 port and currently on a Streams port. It works, basically, by having a deamon which is woken up when the routing code chooses a "dialed" (more generally, switched) route. It then calls into a bunch of UUCP code to establish the connection, and logs in to an account which runs the daemon in "server mode". The "client" then informs the "server" of who he is (ascii), his numeric address, and what he thinks the server's numeric address is. The server checks his host and authentication files, they synchronize and slattach, and the deferred packets are sent. After that its peer-peer, until a timeout occurs with active TCP or carrier loss. I still consider this to be in the experimental phase, primarily in the routing area. Currently the system uses the "gateway" model; no net number is assigned to the link itself, an each system sort of thinks it has an interface on the nets connected to the remote. The inital connection protocol is pretty crude -- just an exchange of cute little text messages. Eventually I'd like to add some simple error checking, though the problems there have been minimal so far. We use it over our PBX to comminiacte between biuldings here regularly, at 19200 baud. Andrew Knutsen (408) 435-3623 I'm also planning on testing with the new high speed modems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [723@hsi.UUCP] <1987112012334400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stevens@hsi.UUCP (Richard Stevens) Newsgroups: comp.protocols.tcp-ip Subject: tn3270 and IBM's TCP/IP for VM/CMS Message-ID: <723@hsi.UUCP> Date: Fri, 20-Nov-87 17:33:44 EST Article-I.D.: hsi.723 Posted: Fri Nov 20 17:33:44 1987 Date-Received: Sun, 22-Nov-87 16:10:26 EST Organization: Health Systems Intl., New Haven, CT Lines: 25 Keywords: IBM 9370, VM/CMS We're a VAX 4.3 BSD site with an existing TCP/IP LAN between three VAX'es and a bunch of PCs. We're about to get an IBM 9370 that will run VM and are interested in IBM's TCP/IP for VM product. It looks like we could use the 4.3 BSD tn3270 software for something like an rlogin access to VM from a VAX, depending on the IBM software. The tn3270 README file refers to it being originally developed at Univ. of Wisconsin and IBM selling it to commercial sites, but reference is also made to other, non-compatible TCP/IP implementations for IBM mainframes. Does anyone know if the current IBM product (which has been available only since July 87) is really compatible with tn3270 ?? The IBM Product Sheet that I have also refers to a C language interface to allow program access directly to the TCP and UDP protocol boundary. Does anyone have any experience with this ?? I'd assume a program under VM using this could communicate with a program on the VAX that was using a BSD socket ?? Finally, the Product Sheet lists the one-time license charges (from $4k to $16k, depending on processor group) but then indicates that the source code for this can be obtained for another $350. This low charge makes me think the code was developed elsewhere. Richard Stevens Health Systems International, New Haven, CT { uunet | ihnp4 } ! hsi ! stevens ----MESSAGE-END---- ----MESSAGE-BEGIN---- [20.NOV.1987.17:08:13.LAWS@RSRE] <1987112015080000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LAWS@rsre.mod.UK.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <20.NOV.1987.17:08:13.LAWS@RSRE> Date: Fri, 20-Nov-87 20:08:00 EST Article-I.D.: RSRE.20.NOV.1987.17:08:13.LAWS Posted: Fri Nov 20 20:08:00 1987 Date-Received: Sun, 22-Nov-87 17:55:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: John Laws Organization: The ARPA Internet Lines: 20 ---- Start of forwarded message. To: haverty%com.bbn.ccv@NSS Cc: "Michael J. O'Connor" ,haverty%com.bbn.ccv@NSSRobert Hinden tcp-ip%arpa.sri-nic@NSS,, From: John Laws (on UK.MOD.RSRE) Date: Fri, 20 Nov 87 17:04 Message-Id: <20 NOV 1987 17:04:24 LAWS@RSRE> Subject: Re: Idle chatter about reference models Jack, It must be clear from my previous msgs that you and I are as one on this. I defer to your clearer statement of where HMP is. John ---- End of forwarded message. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112015280000> Received: from relay.MOD.UK by SRI-NIC.ARPA with TCP; Fri 20 Nov 87 09:11:20-PST Received: from rsre.mod.uk by relay.MOD.UK via PSS with NIFTP id aa00895; 20 Nov 87 16:58 WET To: haverty <@relay.MOD.UK:haverty@ccv.bbn.com> From: John Laws (on UK.MOD.RSRE) Reply-to: John Laws Date: Fri, 20 Nov 87 17:08 Subject: Re: Idle chatter about reference models Cc: oconnor <@relay.MOD.UK:oconnor@sccgate.scc.com>, hinden <@relay.MOD.UK:hinden@park-street.bbn.com>, tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa> Message-Id: <20 NOV 1987 17:08:13 LAWS@RSRE> Comments: ...smashed up Cc header.. ---- Start of forwarded message. To: haverty%com.bbn.ccv@NSS Cc: "Michael J. O'Connor" ,haverty%com.bbn.ccv@NSSRobert Hinden tcp-ip%arpa.sri-nic@NSS,, From: John Laws (on UK.MOD.RSRE) Date: Fri, 20 Nov 87 17:04 Message-Id: <20 NOV 1987 17:04:24 LAWS@RSRE> Subject: Re: Idle chatter about reference models Jack, It must be clear from my previous msgs that you and I are as one on this. I defer to your clearer statement of where HMP is. John ---- End of forwarded message. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [964@deepthot.UUCP] <1987112016342300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: terry@deepthot.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: INFO Message-ID: <964@deepthot.UUCP> Date: Fri, 20-Nov-87 21:34:23 EST Article-I.D.: deepthot.964 Posted: Fri Nov 20 21:34:23 1987 Date-Received: Sun, 22-Nov-87 07:37:01 EST References: <8711200139.AA05593@ucbvax.Berkeley.EDU> Reply-To: terry@deepthot.UUCP (Terry Cudney) Organization: UWO CS, London Canada Lines: 15 In article <8711200139.AA05593@ucbvax.Berkeley.EDU> IO71241@MAINE.BITNET.UUCP writes: >PLEASE SEND ME INFO ON TCP/IP PROTOCOL Please send same to me, and any Amiga-specific things on networking too? Thanx, Terry email: terry@deepthot.UUCP terry@deepthot.UWO.CDN terry@deepthot.UWO.NETNORTH post: Terry Cudney 4 - 746 Richmond Street, LONDON, Ontario Canada N6A 3H3 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [933@vsedev.VSE.COM] <1987112017431800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@vsedev.VSE.COM (Ron Flax) Newsgroups: comp.protocols.tcp-ip Subject: Connecting remote Ethernets? Message-ID: <933@vsedev.VSE.COM> Date: Fri, 20-Nov-87 22:43:18 EST Article-I.D.: vsedev.933 Posted: Fri Nov 20 22:43:18 1987 Date-Received: Sun, 22-Nov-87 22:47:36 EST Reply-To: ron@vsedev.VSE.COM (Ron Flax) Organization: VSE Software Development Lab Lines: 13 We need to find the best (best=least expensive & has reasonable performance...) way to connect two, possibly several, remote Ethernets. 1) What hardware is available that can be used to extend the TCP/IP based Ethernet over a 56kbps leased line? 2) Or possibly a faster/slower telephone circuit? -- ron@vsedev.vse.com (Ron Flax) uucp: ..!uunet!vsedev!ron inet: vsedev!ron@uunet.uu.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711210311.AA10698@ucbvax.Berkeley.EDU] <1987112017465600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNFORDPB@UIAMVS.BITNET (Jay Ford, U of Iowa) Newsgroups: comp.protocols.tcp-ip Subject: help Message-ID: <8711210311.AA10698@ucbvax.Berkeley.EDU> Date: Fri, 20-Nov-87 22:46:56 EST Article-I.D.: ucbvax.8711210311.AA10698 Posted: Fri Nov 20 22:46:56 1987 Date-Received: Sun, 22-Nov-87 22:10:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 137 This is a request for network configuration suggestions. Any responses should be sent to me rather than to the list. Questions How have other sites approached and/or solved the problems associated with establishing and administering large campus networks? Is the topology outlined below feasible without having static, manually-entered routes for the entire campus? Will an ARP (or any) ethernet-level broadcast from a host on one ethernet make it through a gateway to a host on another ethernet? Will the ARP reply make it back to the broadcaster? Is it necessary to have something along the lines of proxy-ARP to make this work? Does existing software support proxy-ARP? Does anyone have suggestions addressing problems at any level which would alleviate some of the routing complexity? Notes We are new at this, and very well might have incorrect interpretations of the problems we face. By the same reasoning, we certainly are not aware of all the possible solutions to our problems. Any help would be appreciated. Thank you. Background The University of Iowa is in the process of establishing a campus network consisting of departmental LANs hung off of a broadband backbone. The departmental nets use various technologies including Ethernet/IEEE 802.3, proprietary token rings, and fiber. Some departments have multi-level networks (see figure below). Access to the broadband backbone is provided through ethernet bridges (Bridge IB/1 boxes), with each department having one IB/1. The IB/1 is a MAC-level bridge, so that a host on a baseband ethernet connected to an IB/1 in one department appears to be on the same physical cable as a host on a baseband ethernet connected to an IB/1 in another department. We have a mixture of machines and OSs, including VAXes running 4.2 & 4.3 BSD, VAXes running VMS, Encores running UMAX 4.2, Apollos, Suns, PCs, Primes, and IBMs running MVS; we also have a handful of Encore Annex terminal servers. The U of Iowa has been granted a class B Internet number of 128.255. We will soon activate a connection to MIDnet -> NSFnet -> world. Topology The current network topology (with only two departments connected) is: || Annex1 ---| || +------+ | ||---| IB/1 |-----(ethernet1)-----| || +------+ | || Encore1 ---| || |--- Encore2 (broadband) | || |--- Alliant || | +------+ || |-----(ethernet2)-----| IB/1 |---|| | +------+ || |--- VMSVax1 || +---------+ | ||---| Proteon |----> (MIDnet) |--- Apollo1 || +---------+ | --- / \ / \ (Apollo-ring) \ / \ / |--- BSDVax1 --- | | |--- BSDVax2 Apollo2 ----(ethernet3)----| |--- BSDVax3 We would like to assign a subnet number to each physical network. For example: network internet subnet ------- --------------- ethernet1 128.255.32 ethernet2 128.255.22 ethernet3 128.255.20 Apollo ring 128.255.21 Problems The presence of independently administered networks within the campus lends itself to a subnetting scheme, with each department receiving a block of subnet numbers from which to allocate numbers for the networks under the control of the department. We have encountered some routing problems which may be attributable to the coexistence of IP implementations which do support subnetting and those which do not. The broadband bridging makes ethernet1 and ethernet2 appear to be one physical network, so we end up with one network having more than one subnet number. This seems to cause problems with routing for the hosts which understand subnetting. They think the hosts on the other subnet should be on a different physical network and expect to have a gateway to get there. Since there is no gateway, they don't see a path to the other subnet. Disabling subnetting (by changing the netmask to 255.255.0.0 in the subnetting hosts) makes everybody think that the entire campus is one big physical (class B) network. This solves the problem just described, but it defeats the subnet-based routing required to access the networks which are actually subnetted, such as Apollo-ring and ethernet3. One proposed solution is to place a router between the IB/1 and the networks within each department. This has the advantage of making the broadband a separate subnet and providing the gateways (arguably) needed for subnet-based routing as described above. Disadvantages include the decrease in throughput (compared to just the bridge), the added cost of the router (or an additional ethernet interface for a host acting as a router), and the restriction on the protocols which may then cross the broadband. Furthermore, I am not convinced that such a configuration would solve all our problems without introducing new ones. Jay Ford Weeg Computing Center University of Iowa Iowa City, IA 52242 (319) 335-5555 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [289206.871120.JBVB@AI.AI.MIT.EDU] <1987112018035200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes Message-ID: <289206.871120.JBVB@AI.AI.MIT.EDU> Date: Fri, 20-Nov-87 23:03:52 EST Article-I.D.: AI.289206.871120.JBVB Posted: Fri Nov 20 23:03:52 1987 Date-Received: Sun, 22-Nov-87 22:54:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 72 ... I offer my speculations below and would like you to confirm/revise. Source Code: So that an organization can fix/improve the code themselves, or by a third party, and not have to depend on the original vendor. Does your recommendation change if software maintenance is in effect? Depends on the situation. A university I know of has a couple hundred PCs off line waiting for software maintainers at one of two vendors to solve a TCP problem. Everybody is acting in good faith, and both sides are partly at fault. One vendor has delivered what they think is a fix, but it took 4 months. The other vendor had a new release, and that had to be tested to see if the problem went away, etc, etc. There are dozens of Unix vendors who are shipping 4.2's buggy, non-standard TFTP. How long will it be till they supply nameservers? Consider the vendors who spent years getting subnets working. Some of these long-standing problems may be helped by a host version of the "how to be a good gateway RFC" (1009?), and the Non-Interoperability questionaire which is supposed to get some attention at the conference in December, but I can't predict anything. Rigid Version Control: This has more to do with the organization's network than with vendors. The organization doesn't want two different versions of the same process to be in use. Correct. There is also an element of "we don't want anyone to modify it". Identifying which version is in use is simply one more step in identifying a problem, whether or not it has been encountered before. Homogenous Hardware: This one troubles me - I would like to think that through the use of standard protocols an organization could achieve interoperability ... It is generally true that via TCP/IP, two different hosts can communicate. Significant TCP bugs are getting pretty rare, although interpretations for things like urgent differ. Except for the Unix XPWD incompatibility, FTP does pretty well. SMTP has one widespread problem, discussed last week. Most Telnets interoperate well, until you start playing with options, or wondering why you are receiving parity (excuse my hobbyhorse). However, this is fairly nuts-and-bolts compared to what you can do between homogeneous systems. There are a number of essentially Unix-Unix protocols that add functionality to the basic ARPA suite, but they aren't well documented, and non-Unix implementations are extremely rare. Network printing, to take a prosaic example. Furthermore, most organizations have finite numbers of maintainers. For any number of maintainers, it appears that the tinkerers employed by the vendors can tinker at least as fast as the maintainers can learn/code/upgrade. The more vendors, the more high-level people you need, and high-level techies are the non-technical manager's nightmare. Whole sectors of the software industry are founded on the absolute un- willingness of many companies to employ permanently any techies more qualified than a computer operator, or application program maintainer. DEC has been moving VMS in their direction for years but few vendors have even begun on "Unix for the masses", and that represents more than half (vigorous hand-waving) of all TCP/IP hosts. Anyone who's ever hacked on sendmail.cf knows what a vale of tears a complex software system whose implementer is unavailable can be. So, the managers have mostly learned to keep things simple, generic where possible, but ultimately maintainable. The net I described in my first posting is still useable, so the maintainers and their managers are sticking to the problems they can solve, and relying on the influx of new, uniform machines to eventually eliminate the off-maintenance bad actors. I'm not saying I prefer this, but it looks pretty likely. Regards - Craig jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711210034.aa05838@VMB.BRL.ARPA] <1987112019341900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kermit@BRL.ARPA (Chuck Kennedy) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet versions Message-ID: <8711210034.aa05838@VMB.BRL.ARPA> Date: Sat, 21-Nov-87 00:34:19 EST Article-I.D.: VMB.8711210034.aa05838 Posted: Sat Nov 21 00:34:19 1987 Date-Received: Mon, 23-Nov-87 03:45:53 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Here are the appropriate references for anyone that's interested: The Ethernet: A Local Area Network: Data Link Layer and Physical Layer Specifications, DEC, Intel, and Xerox Corporations, 1980. The Ethernet: A Local Area Network: Data Link Layer and Physical Layer Specifications, Version 2.0, DEC, Intel, and Xerox Corporations, 1982. Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications (Standard 802.3-1985/International Standard 8802/3), The Institute of Electrical and Electronics Engineers, Inc., 1985. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711210806.AA16639@wuccrc.UUCP] <1987112022064800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: guru@wuccrc.UUCP (Guru Parulkar) Newsgroups: comp.protocols.tcp-ip Subject: A couple of simple questions. Message-ID: <8711210806.AA16639@wuccrc.UUCP> Date: Sat, 21-Nov-87 03:06:48 EST Article-I.D.: wuccrc.8711210806.AA16639 Posted: Sat Nov 21 03:06:48 1987 Date-Received: Mon, 23-Nov-87 06:58:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 In the last few weeks, there has been a number of messages about PSN version 7 release and a new end-to-end ARPAnet protocol. However, I haven't seen any reference or RFC announcement which describes this protocol. Maybe, I missed it. Could somebody tell me if there is any reference on that. Or is this protocol BBN's proprietrary. One question that I wanted to ask for a while is about the "connection oriented" nature of ARPAnet's link level (or PSN - PSN protocol). I believe this protocol is essentially a connection oriented which means we have a situation where a connection less internet protocol IP sits on the top of a connection oriented protocol. Is it possible that in this situation the overhead of connection management does not have good "payoffs" at IP level or layers above that ? I remember Dr. Dave Mills saying something on similar lines in one of his classes at Delaware. (Maybe, I misunderstood what he was trying to convey.) I need to understand this issue better, and I would appreciate if somebody could help me with this. Thanks! -guru parulkar wuccrc!guru@uunet.uu.net or Dept of CS parulkar@udel.edu Washington Univ St. Louis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [289322.871121.PAP4@AI.AI.MIT.EDU] <1987112100131600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: Institution-wide whois Message-ID: <289322.871121.PAP4@AI.AI.MIT.EDU> Date: Sat, 21-Nov-87 05:13:16 EST Article-I.D.: AI.289322.871121.PAP4 Posted: Sat Nov 21 05:13:16 1987 Date-Received: Mon, 23-Nov-87 03:46:57 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 44 I agree that most sites should maintain current whois database information. I think that the whois database structure is perhaps past due, and a more appropriate form is needed. For the host information, perhaps a new record type could be added, such as ADMIN. This would tell you something about the organization behind a domain. Ie: MIT.EDU Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 (617) 253-1000 (as the ADMIN info) Nameservers: W20NS.MIT.EDU (18....) BITSY.MIT.EDU (18....) ... (via NS queries for MIT.EDU) And... LCS.MIT.EDU M.I.T. Laboratory for Computer Science 5 Cambridge Centre (NE-43) Cambridge, MA 02139 (617) 253-6001 (more ADMIN info) Nameservers: XX.LCS.MIT.EDU (10....) (NS records) and information for hosts could also be specified, where the ADMIN record would tell you who the responsible person for a host is, including phone number, address, and mailbox. These wouldn't be necessary for all hosts, maybe just gateways and nameservers... For the user information, each host in the desired subdomain (or the host itself, if it were named) could be 'fingered' for the desired information about a user. Ideas, comments? -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [433@ncc.UUCP] <1987112115152400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lyndon@ncc.UUCP (Lyndon Nerenberg) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: KA9Q NET.EXE software Message-ID: <433@ncc.UUCP> Date: Sat, 21-Nov-87 20:15:24 EST Article-I.D.: ncc.433 Posted: Sat Nov 21 20:15:24 1987 Date-Received: Mon, 23-Nov-87 07:08:17 EST References: <141@ncc.UUCP> <328@idacrd.UUCP> <243@casemo.UUCP> Distribution: comp Organization: Nexus Computing Inc. Lines: 16 Summary: Here's how to get it... There are a couple of sites that have the code available. Ours is one of them. To retrieve the distribution, add one of the following lines to your L.sys/Systems file: ncc Any ACU 2400 14034250342 "" \r ogin:--ogin: nuucp ncc Any ACU 1200 14034250342 "" BREAK ogin:-BREAK-ogin: nuucp Next, say 'uucp ncc!~/pub/ka9q_all.tar.Z /usr/spool/uucppublic' and wait for it to transfer. *********** PLEASE NOTE ************ This is NOT the LATEST version of the code!!!! The version currently on line is 870829.0. I should have the new version in a few days, so you might want to hang off. I will post again in a few days when it's online. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3370@hoptoad.uucp] <1987112116072800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP maximum segment size determination Message-ID: <3370@hoptoad.uucp> Date: Sat, 21-Nov-87 21:07:28 EST Article-I.D.: hoptoad.3370 Posted: Sat Nov 21 21:07:28 1987 Date-Received: Mon, 23-Nov-87 06:59:36 EST References: <283116.871110.JBVB@AI.AI.MIT.EDU> Organization: Nebula Consultants in San Francisco Lines: 22 JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") wrote: > If gateway gurus saw their way clear to do so, they might help some fraction > of the world by arranging that IP fragments aren't transmitted consecutively > (if there is other traffic to handle) or by inserting a little time delay > if the Ether or other non-serial media is idle. It's hard to believe that in this age of utterly cheap dense RAM, otherwise sane people are proposing inserting artificial delays between Ethernet packets because a lowball vendor wouldn't put, say, TWO buffers on their card! The free market has a clear solution to this problem... [I admit I'm prejudiced, since I worked on Suns, which currently seem to have the highest Ethernet thruput, but they were built out of standard Ethernet chips and DRAMs available to everyone. You too can handle infinite back to back packets, if you just design with that in mind as Sun did.] -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com Love your country but never trust its government. -- from a hand-painted road sign in central Pennsylvania ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711212315.aa14738@Huey.UDEL.EDU] <1987112118155200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: A couple of simple questions. Message-ID: <8711212315.aa14738@Huey.UDEL.EDU> Date: Sat, 21-Nov-87 23:15:52 EST Article-I.D.: Huey.8711212315.aa14738 Posted: Sat Nov 21 23:15:52 1987 Date-Received: Mon, 23-Nov-87 07:19:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Guru, Yes, ARPANET is now and has been a connection-oriented network, but with dynamics and route-binding mechanisms usually friendly to frisky datagram service. Sometimes, like in the recent case of an X.25 access problem which resulted in destructive virtual-circuit thrashing, the more liberal of us buzzards may grumble a bit or two, but not because virtual circuits, route binding or flow mechanisms are inherently bad. Sometimes, however, the choice of resource allocation and binding strategies in ARPANET (and public packet nets) suggest the designers had in mind a few number of large flows between hosts attached to the network, rather than a large number of small flows between gateways, which seems to be what the ARPANET is evolving to. Andy Malis described the new End-End Protocol in RFC-979. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711220435.AA08947@okeeffe.Berkeley.EDU] <1987112118351700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels@OKEEFFE.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: BSD 4.3 Terminates zero window connection Message-ID: <8711220435.AA08947@okeeffe.Berkeley.EDU> Date: Sat, 21-Nov-87 23:35:17 EST Article-I.D.: okeeffe.8711220435.AA08947 Posted: Sat Nov 21 23:35:17 1987 Date-Received: Tue, 24-Nov-87 01:22:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Re: > A customer has reported that BSD4.3, if it is presented with a zero window, > tries ONCE to push data through the window. If it receives no response, > it closes the connection. There is a language problem between me the > customer and the manuals, so maybe I don't understand what they are > saying. Does this match 4.3 behavior? > > - Geof This is not true in general, and I don't know of any bugs in this area that cause connections to close when the window closes. There was a bug in 4.2 that could cause connections to close if the window was retracted after data had been sent into it; I believe that this is fixed in 4.3BSD as well, although I didn't take the time to set up a situation in which to test that. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711220436.AA08957@okeeffe.Berkeley.EDU] <1987112118355800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels@OKEEFFE.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: BSD 4.3 Sends data after FIN? Message-ID: <8711220436.AA08957@okeeffe.Berkeley.EDU> Date: Sat, 21-Nov-87 23:35:58 EST Article-I.D.: okeeffe.8711220436.AA08957 Posted: Sat Nov 21 23:35:58 1987 Date-Received: Tue, 24-Nov-87 01:29:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 This was a bug in 4.3 alpha or beta, I forget which; it's not in the released version of 4.3. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711220444.AA10224@aramis.rutgers.edu] <1987112118445500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes Message-ID: <8711220444.AA10224@aramis.rutgers.edu> Date: Sat, 21-Nov-87 23:44:55 EST Article-I.D.: aramis.8711220444.AA10224 Posted: Sat Nov 21 23:44:55 1987 Date-Received: Tue, 24-Nov-87 04:40:59 EST References: <8711201833.AA25671@mitre.arpa> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 > Source Code: So that an organization can fix/improve the code > themselves, or by a third party, and not have to depend on the original > vendor. Does your recommendation change if software maintenance is in > effect? We have yet to see an organization that fixes things fast enough to cope with our situation. When a problem shows up, it shows up in spades. Like suddenly we are using the whole bandwidth of a T1 line sending bogus name requests. Now and then we'll call an organization and have them say "oh yes, we know about this. What is your UUCP phone number?" But otherwise, it is "fixed in the next release" or at best fixed in a few days. That are situations where we would have to disable a crucial function during the interim. So I consider it crucial to have source for as much as possible. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711220500.AA10549@aramis.rutgers.edu] <1987112119002800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: help Message-ID: <8711220500.AA10549@aramis.rutgers.edu> Date: Sun, 22-Nov-87 00:00:28 EST Article-I.D.: aramis.8711220500.AA10549 Posted: Sun Nov 22 00:00:28 1987 Date-Received: Tue, 24-Nov-87 04:42:01 EST References: <8711210325.AA28823@topaz.rutgers.edu> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 The author describes a configuration having a mix of vendors, administrators, and network technologies, and asks how to make a level-2 bridge work within it. My recommendation would be: 1) not to do it. I think it is a big mistake to let level 2 technology cross administrative boundaries. Personally I prefer level 3 technology everywhere, but there are good arguments on both sides. But I see nothing in favor of leve 2 technology connecting networks where different people are going to be responsible for diagnosing problems. Since this issue has come up so many times, I now have a canned response which I will mail to the original poster under separate cover (to avoid boring the rest of you). We believe that the next generation of gateways (based on 68020 processors instead of 68000), which should be available in December or January from at least cisco and Proteon, will have throughput close to that of a bridge. The primary performance limitation will then be on long back-to-back strings of packets. That will be resolved by new Ethernet controllers, which should also be available shortly. Even in the current generation, throughput with gateways is enough for most networks. From your description, I believe you would see no performance problems from using routers instead of bridges. 2) if you must do it, I would set the subnet mask to 255.255.255.0 on those machines were you can have multiple subnets on one interface. All BSD-based systems allow this, and I think many others as well. On a BSD system, you say route add x.y.z.0 youraddress 0 for each subnet that you want to add as being local. For systems where this is not possible, I would set the subnet mask to 255.255.0.0. If you have any such systems, then any actual level 3 gateways that may be present in your configuration (Apollo?) will have to be able to do proxy ARP. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9353@shemp.UCLA.EDU] <1987112121241300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tamir@CS.UCLA.EDU Newsgroups: comp.protocols.tcp-ip,comp.dcom.modems Subject: dialup SLIP using split speed modems ? Message-ID: <9353@shemp.UCLA.EDU> Date: Sun, 22-Nov-87 02:24:13 EST Article-I.D.: shemp.9353 Posted: Sun Nov 22 02:24:13 1987 Date-Received: Tue, 24-Nov-87 06:40:19 EST Sender: root@CS.UCLA.EDU Reply-To: tamir@CS.UCLA.EDU (Yuval Tamir) Organization: UCLA Computer Science Department Lines: 11 Has anybody tried running SLIP over a dialup line using a split speed (9600 / 300 baud) modem such as the US Robotics HST9600 ? How well can this be expected to work compared with full duplex 9600 baud (both directions) modems or with half duplex 9600 baud modems ? Yuval Tamir Internet: tamir@cs.ucla.edu UUCP: ...!{ihnp4,ucbvax,sdcrdcf,trwspp,randvax,ism780}!ucla-cs!tamir ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12352652943.15.LIXIA@XX.LCS.MIT.EDU] <1987112205091300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Lixia@XX.LCS.MIT.EDU (Lixia Zhang) Newsgroups: comp.protocols.tcp-ip Subject: Re: A couple of simple questions. Message-ID: <12352652943.15.LIXIA@XX.LCS.MIT.EDU> Date: Sun, 22-Nov-87 10:09:13 EST Article-I.D.: XX.12352652943.15.LIXIA Posted: Sun Nov 22 10:09:13 1987 Date-Received: Tue, 24-Nov-87 06:48:43 EST References: <8711210806.AA16639@wuccrc.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 I'll leave the version-7 description to BBN people, and only say a few words about your second question (about the PSN-PSN protocol, or IMP-IMP protocol as it used to be called). It is a link layer protocol providing reliable datagram deliveries (i.e. every packet will be delivered, but possibly out-of-order). It has nothing to do with connection concept at the network layer. ARAPNET runs a DATAGRAM protocol internally, but provides a virtual-circuit interface to the host by a reliable network end-to-end (i.e. between entry-exit IMPs) protocol. Therefore some of your words are still correct -- unreliable IP runs on top of the reliable ARPANET, and indeed causes high overhead in many cases. ARPANET opens an end-to-end connection to deliver data between two hosts (which can be IP gateways), and blocks the interface to the host whenever the PSN(IMP) runs out of the resources (buffers, control table entries, whatever). And that is why packets always get lost at the gateways: the IP gateway has no mechanism to stop incoming packets, so it has to drop them when they can't be forwarded. Lixia ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711221729.AA22619@bu-cs.BU.EDU] <1987112207294200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Networks & vendor upgrades/fixes Message-ID: <8711221729.AA22619@bu-cs.BU.EDU> Date: Sun, 22-Nov-87 12:29:42 EST Article-I.D.: bu-cs.8711221729.AA22619 Posted: Sun Nov 22 12:29:42 1987 Date-Received: Tue, 24-Nov-87 07:01:25 EST References: <8711220444.AA10224@aramis.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Source code: I'd like to add that the critical need for source code, besides functional fixes, is security. It's one area where it's nearly impossible to find a vendor who provides what you need. Unfortunately needs are very often a customized affair, and security bugs often an outright emergency. It's can also be a moving target, something no one thought of yesterday suddenly, after one irate phone call, becomes first priority. Software "maintenance" is utterly the wrong concept for this sort of situation. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711222013.AA13624@ARES.MIT.EDU] <1987112210134300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: A couple of simple questions. Message-ID: <8711222013.AA13624@ARES.MIT.EDU> Date: Sun, 22-Nov-87 15:13:43 EST Article-I.D.: ARES.8711222013.AA13624 Posted: Sun Nov 22 15:13:43 1987 Date-Received: Tue, 24-Nov-87 06:44:00 EST References: <12352652943.15.LIXIA@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Hi, my wife and I and a friend (Diane Rahe who is a hardware engineer in my group at Prime) are going out to dinner (probably in Chinatown) sometime between 6 and 7. Would you be interested? Just send me mail. I cannot be reached by phone. Yakim Martillo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711222104.AA11940@etn-wlv.EATON.COM] <1987112211043100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes Message-ID: <8711222104.AA11940@etn-wlv.EATON.COM> Date: Sun, 22-Nov-87 16:04:31 EST Article-I.D.: etn-wlv.8711222104.AA11940 Posted: Sun Nov 22 16:04:31 1987 Date-Received: Tue, 24-Nov-87 06:45:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Distributing source code seems to be inconsistent with the desire to enforce version controls. The availability of source code seems to be an attraction to the "tinkerer" much like a flame is to a moth--one's version control be- comes a historical artifact when the "tinkerer" gets access to the code. If the source is distributed on a media other than electronic as "documentat- tion", it is extremely useful and it is relatively easy to maintain version control of the software. Merton Campbell Crockett ----MESSAGE-END---- ----MESSAGE-BEGIN---- [11788@orchid.waterloo.edu] <1987112211240300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mshiels@orchid.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: NetBIOS Compatibility Demo Message-ID: <11788@orchid.waterloo.edu> Date: Sun, 22-Nov-87 16:24:03 EST Article-I.D.: orchid.11788 Posted: Sun Nov 22 16:24:03 1987 Date-Received: Wed, 25-Nov-87 03:44:00 EST References: <12351196238.16.OLE@CSLI.Stanford.EDU> Reply-To: mshiels@orchid.waterloo.edu (Michael A. Shiels) Distribution: world Organization: U. of Waterloo, Ontario Lines: 14 One thing to test in all NETBIOS on TCP/IP implementations is the ability to do the following. IBM TOKEN RING NETBIOS allows it but alot of vendors of clone NETBIOSs don't seem to handle this well. Make an open/listen call and then post a receive on this session. (before any connections are made!). Just thought I'd poass along some of the problems I have run into. -- Michael A. Shiels (MaS Network Software) mshiels@orchid.waterloo.EDU UUCP: ...path...!watmath!orchid!mshiels ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711222136.AA25270@bu-cs.BU.EDU] <1987112211361900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Networks & vendor upgrades/fixes Message-ID: <8711222136.AA25270@bu-cs.BU.EDU> Date: Sun, 22-Nov-87 16:36:19 EST Article-I.D.: bu-cs.8711222136.AA25270 Posted: Sun Nov 22 16:36:19 1987 Date-Received: Wed, 25-Nov-87 03:26:56 EST References: <8711222104.AA11940@etn-wlv.EATON.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 50 >Distributing source code seems to be inconsistent with the desire to enforce >version controls. The availability of source code seems to be an attraction >to the "tinkerer" much like a flame is to a moth--one's version control be- >comes a historical artifact when the "tinkerer" gets access to the code. > >If the source is distributed on a media other than electronic as "documentat- >tion", it is extremely useful and it is relatively easy to maintain version >control of the software. > >Merton Campbell Crockett There are certainly better ways to do version control than to withold the sources. I've heard this argument for years and I still don't believe that the solution is OCO distributions, I don't even believe this is ever the real reason (vague fears of losing the technology are probably the real reason, either de facto [falling into a competitor's hands] or de jure [a court deciding you gave away the store], some of these fears have no rational basis, some do, but the conservative choice is obvious (even if it loses sales?!)) For example, one could simply demand, as with all warrantees, that software will not be maintained if monkeyed with (tho patches could be supplied everyone and they can do what they like with them.) To settle disputes it would be easy enough to provide a simple checksum program on the source. Whatever, but witholding the source has to be the worst possible solution to this (undisputed) problem. One thing I hate is vendors who won't even sell any source support (that is, you don't get the source patches for minor releases, so either you live with the bugs, obsolete your sources or guess how to fix the problem.) Vendors could also get more aggressive about these problems instead of sitting around getting into trouble (I have no doubt they do with large customers who get the sources, tinker, then demand support anyhow, money talks...) Usually when I get a source release I pays my money and that's that, a tape shows up, even if I already have maintenance on the software. I could see being asked to sign something which clearly states the new responsibilities now that you have sources. Heck, to trade options on the CBOE you have to sign a form acknowledging your lack of good sense. Seriously, how do you know they haven't mucked with the rest of the O/S, binary patched your sw, etc. Same problem. Microfiched source is not the answer either, unless you get some sort of satisfaction at merely looking at the buggy code that's bringing your system to its knees. Blechh. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711222235.AA13789@ARES.MIT.EDU] <1987112212350100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: Apologies and Arcnet Message-ID: <8711222235.AA13789@ARES.MIT.EDU> Date: Sun, 22-Nov-87 17:35:01 EST Article-I.D.: ARES.8711222235.AA13789 Posted: Sun Nov 22 17:35:01 1987 Date-Received: Wed, 25-Nov-87 19:47:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Before I receive hundreds of letters about my faux pas with the mailer, I am aware of the mistake and apologize for it. Since I am mailing out this letter, I may as well may it somewhat useful. I noticed arcnet being discussed here. Now my friends at Clearpoint use arcnet networking cards with vme bus interfaces for some sort of distributed memory testing. After seeing arcnet mentioned in this newsgroup, I have become curious. Where does arcnet come from? Who uses it and why (instead of some other networking scheme)? What are the achievable data rates? Where can I get literature on arcnet? Yakim Martillo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711230409.AA00663@sluggo.sun.com] <1987112218091100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM (Bill Melohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes Message-ID: <8711230409.AA00663@sluggo.sun.com> Date: Sun, 22-Nov-87 23:09:11 EST Article-I.D.: sluggo.8711230409.AA00663 Posted: Sun Nov 22 23:09:11 1987 Date-Received: Wed, 25-Nov-87 21:01:14 EST References: <8711222104.AA11940@etn-wlv.EATON.COM> <8711222136.AA25270@bu-cs.BU.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: melohn@Sun.COM (Bill Melohn) Organization: Sun Microsystems, Mountain View Lines: 15 I feel it is bogus for a vendor to NOT offer source to those customers who have the local expertise to make use of it, and are willing to pay for the extra cost of its distribution. However, many if not most end users either do not want to do their own software maintenance or don't have a local support staff, and would rather pay the vendor for a turn key solution and phone line customer support. Within each organization, this is usually an economic rather than technical issue. Unix certainly represents the only real attempt to free the end user from vendor dependence on a particular operating system or machine architecture. It is far from perfect, but it does run on different machines from PCs to Crays, and goes farther than any other vendor implementation in providing an application and system interface that is offered by a wide range of computer vendors on widely different hardware. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12352810149.10.SY.KEN@CU20B.COLUMBIA.EDU] <1987112219324700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: A couple of simple questions. Message-ID: <12352810149.10.SY.KEN@CU20B.COLUMBIA.EDU> Date: Mon, 23-Nov-87 00:32:47 EST Article-I.D.: CU20B.12352810149.10.SY.KEN Posted: Mon Nov 23 00:32:47 1987 Date-Received: Wed, 25-Nov-87 21:46:14 EST References: <8711222013.AA13624@ARES.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Hi, my wife and I and a friend (Diane Rahe who is a hardware engineer in my group at Prime) are going out to dinner (probably in Chinatown) sometime between 6 and 7. Would you be interested?... You're going to need a reservation for several thousand at least... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112301501100> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Mon 23 Nov 87 07:17:40-PST To: wucs1!wuccrc!guru@UUNET.UU.NET, Lixia Zhang , Mills@LOUIE.UDEL.EDU, martillo@ATHENA.MIT.EDU cc: tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM Subject: Re: A couple of simple questions. In-reply-to: Your message of Sun, 22 Nov 87 10:09:13 -0500. <12352652943.15.LIXIA@XX.LCS.MIT.EDU> Date: Mon, 23 Nov 87 10:10:11 -0500 From: Andy Malis I would like to add a few comments to the "simple questions" messages, in the order that I received them. From: Guru Parulkar In the last few weeks, there has been a number of messages about PSN version 7 release and a new end-to-end ARPAnet protocol. ... As Dave Mills has already pointed out (thanks, Dave) I wrote RFC 979 in March of '86 to describe the external functionality of the new EE in PSN 7.0. It's still accurate for PSN 7.0, but please read anything in there concerning future PSN releases with a grain of salt. This was written some time ago, and plans have a way of changing, as I'm sure you're all aware. One question that I wanted to ask for a while is about the "connection oriented" nature of ARPAnet's link level (or PSN - PSN protocol). ... You are absolutely correct - IP datagrams are being sent over internal connections between endpoint PSNs (and, in the case of IP over X.25, the connections go all the way back to the hosts). There are a number of reasons that this is done (including history - the predecessor to TCP, NCP, depended upon this reliable service from the subnet), but the most important is that imposing per-connection restrictions on the host traffic is currently the only way the PSNs have to protect themselves and the network (without dropping packets) from being completely overwhelmed by offered load. Whether the PSNs SHOULD drop packets or not when supporting TCP/IP-based applications is another question altogether (and one I would rather not get into right now). As an aside, there are many non-TCP/IP based applications that run on BBNCC PSN networks, and these require the reliable connection-based service provided by the PSN. Even the per-connection restrictions aren't enough to allow the PSNs to push back, when necessary, on source hosts. Because of this, we have been working on congestion control for the PSNs. Only after congestion control has been deployed can we start thinking about implementing some sort of non-connection-based service for the ARPANET and other TCP/IP nets. From: Mills@LOUIE.UDEL.EDU Sometimes, however, the choice of resource allocation and binding strategies in ARPANET (and public packet nets) suggest the designers had in mind a few number of large flows between hosts attached to the network, rather than a large number of small flows between gateways, which seems to be what the ARPANET is evolving to. You are mostly correct. In the "good old days" of small IMPs, when we only had on the order of 64 connection blocks on an IMP, we really hadn't designed for the sort of traffic that you now see on the ARPANET between gateways. However, we tried to adjust our algorithms somewhat to make the new EE more general for the different sorts of applications we see now see running on PSN networks. As a result, the new EE can support up to 2000 simultaneous connections on a C/300 (which are becoming more common on the ARPANET) and 512 on a C/30 (which has less memory and CPU horsepower). From: Lixia Zhang ARPANET runs a DATAGRAM protocol internally, but provides a virtual-circuit interface to the host by a reliable network end-to-end (i.e. between entry-exit IMPs) protocol. You are correct, except for one small point - your use of the word DATAGRAM may suggest to some that PSNs may be willing to drop packets if necessary. This is not the case - the only time packets are lost in the subnet is if a PSN crashes or, because of network congestion, a PSN cannot accept a packet from its neighbor in 32 transmission attempts from the neighbor. The old EE could not recover from such packet lossages. The new EE has source retransmissions, and can recover from such internal packet loss. Therefore some of your words are still correct -- unreliable IP runs on top of the reliable ARPANET, and indeed causes high overhead in many cases. We've also worked hard on the new EE to reduce this necessary overhead. For example, we've cut down on the packet header size and can send the data for the first message over a connection as a part of the connection open request. From: martillo@ATHENA.MIT.EDU Hi, my wife and I and a friend ... are going out to dinner (probably in Chinatown) sometime between 6 and 7. Would you be interested? Sounds good. I'm partial to Carl's Pogoda and the Golden Palace. Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711231258.AA00964@ucbvax.Berkeley.EDU] <1987112302332600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: COINS@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: QUESTION Message-ID: <8711231258.AA00964@ucbvax.Berkeley.EDU> Date: Mon, 23-Nov-87 07:33:26 EST Article-I.D.: ucbvax.8711231258.AA00964 Posted: Mon Nov 23 07:33:26 1987 Date-Received: Wed, 25-Nov-87 23:53:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 ANYONE I'M RUNNING PWB UNIX ON A PDP1170. DOES ANYONE HAVE DATA ENTRY TERMINAL OPTIONS TO/FOR TELNET UP ON ANY VERSION OFUNIX? IF SO PLEASE DROP ME A NOTE. THKS RON SMITH ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711231559.AA02850@ucbvax.Berkeley.EDU] <1987112306012700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: A couple of simple questions. Message-ID: <8711231559.AA02850@ucbvax.Berkeley.EDU> Date: Mon, 23-Nov-87 11:01:27 EST Article-I.D.: ucbvax.8711231559.AA02850 Posted: Mon Nov 23 11:01:27 1987 Date-Received: Thu, 26-Nov-87 01:51:23 EST References: <12352652943.15.LIXIA@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 102 I would like to add a few comments to the "simple questions" messages, in the order that I received them. From: Guru Parulkar In the last few weeks, there has been a number of messages about PSN version 7 release and a new end-to-end ARPAnet protocol. ... As Dave Mills has already pointed out (thanks, Dave) I wrote RFC 979 in March of '86 to describe the external functionality of the new EE in PSN 7.0. It's still accurate for PSN 7.0, but please read anything in there concerning future PSN releases with a grain of salt. This was written some time ago, and plans have a way of changing, as I'm sure you're all aware. One question that I wanted to ask for a while is about the "connection oriented" nature of ARPAnet's link level (or PSN - PSN protocol). ... You are absolutely correct - IP datagrams are being sent over internal connections between endpoint PSNs (and, in the case of IP over X.25, the connections go all the way back to the hosts). There are a number of reasons that this is done (including history - the predecessor to TCP, NCP, depended upon this reliable service from the subnet), but the most important is that imposing per-connection restrictions on the host traffic is currently the only way the PSNs have to protect themselves and the network (without dropping packets) from being completely overwhelmed by offered load. Whether the PSNs SHOULD drop packets or not when supporting TCP/IP-based applications is another question altogether (and one I would rather not get into right now). As an aside, there are many non-TCP/IP based applications that run on BBNCC PSN networks, and these require the reliable connection-based service provided by the PSN. Even the per-connection restrictions aren't enough to allow the PSNs to push back, when necessary, on source hosts. Because of this, we have been working on congestion control for the PSNs. Only after congestion control has been deployed can we start thinking about implementing some sort of non-connection-based service for the ARPANET and other TCP/IP nets. From: Mills@LOUIE.UDEL.EDU Sometimes, however, the choice of resource allocation and binding strategies in ARPANET (and public packet nets) suggest the designers had in mind a few number of large flows between hosts attached to the network, rather than a large number of small flows between gateways, which seems to be what the ARPANET is evolving to. You are mostly correct. In the "good old days" of small IMPs, when we only had on the order of 64 connection blocks on an IMP, we really hadn't designed for the sort of traffic that you now see on the ARPANET between gateways. However, we tried to adjust our algorithms somewhat to make the new EE more general for the different sorts of applications we see now see running on PSN networks. As a result, the new EE can support up to 2000 simultaneous connections on a C/300 (which are becoming more common on the ARPANET) and 512 on a C/30 (which has less memory and CPU horsepower). From: Lixia Zhang ARPANET runs a DATAGRAM protocol internally, but provides a virtual-circuit interface to the host by a reliable network end-to-end (i.e. between entry-exit IMPs) protocol. You are correct, except for one small point - your use of the word DATAGRAM may suggest to some that PSNs may be willing to drop packets if necessary. This is not the case - the only time packets are lost in the subnet is if a PSN crashes or, because of network congestion, a PSN cannot accept a packet from its neighbor in 32 transmission attempts from the neighbor. The old EE could not recover from such packet lossages. The new EE has source retransmissions, and can recover from such internal packet loss. Therefore some of your words are still correct -- unreliable IP runs on top of the reliable ARPANET, and indeed causes high overhead in many cases. We've also worked hard on the new EE to reduce this necessary overhead. For example, we've cut down on the packet header size and can send the data for the first message over a connection as a part of the connection open request. From: martillo@ATHENA.MIT.EDU Hi, my wife and I and a friend ... are going out to dinner (probably in Chinatown) sometime between 6 and 7. Would you be interested? Sounds good. I'm partial to Carl's Pogoda and the Golden Palace. Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [266@cunixc.columbia.edu] <1987112306100800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: alan@cunixc.columbia.edu (Alan Crosswell) Newsgroups: comp.protocols.tcp-ip Subject: Re: tn3270 and IBM's TCP/IP for VM/CMS Message-ID: <266@cunixc.columbia.edu> Date: Mon, 23-Nov-87 11:10:08 EST Article-I.D.: cunixc.266 Posted: Mon Nov 23 11:10:08 1987 Date-Received: Thu, 26-Nov-87 03:12:30 EST References: <723@hsi.UUCP> Reply-To: alan@cunixc.columbia.edu (Alan Crosswell) Organization: Columbia University Lines: 58 Keywords: IBM 9370, VM/CMS In article <723@hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >.... Does anyone know if the current IBM product (which has >been available only since July 87) is really compatible with tn3270 ?? Yes. In fact, the PC implementation is quite good and includes a nice utility for selecting your favorite 3270 to PC keyboard mapping. It also does colors the same way the Yale ASCII IUP (Series-1 stuff which is these days done by 7171's) does. It doesn't do 3279, but assigns a different color to each combination of attributes like hilight, protected, etc. Nobody has done 3279 (yet) since it wasn't until VM/SP 5 that the "Logical Device Facility" was extended to support the so-called 3279 extended data streams. >The IBM Product Sheet that I have also refers to a C language interface >to allow program access directly to the TCP and UDP protocol boundary. >Does anyone have any experience with this ?? I'd assume a program >under VM using this could communicate with a program on the VAX that >was using a BSD socket ?? They provide a means to roll your own TCP/IP programs. The C library is simply a stub interface to the VS Pascal library. You get source, so you can use it as a model for your own program (since everyone knows you can't write a program just from the docs :-). Vace Kundakci, the Academic Systems Manager here, has written (and modified) several clients and servers for things like LPD, Imagen spooling, FINGER, SMTP/SEND interactive messaging, etc. Join the IBMTCP-L list distributed by CUNY. Send mail to LISTSERV@CUNYVM with this as the body: "SUBSCRIBE IBMTCP-L My Name". >Finally, the Product Sheet lists the one-time license charges (from $4k >to $16k, depending on processor group) but then indicates that the >source code for this can be obtained for another $350. This low charge >makes me think the code was developed elsewhere. > You are partially right. The PC stuff is based on MIT PCIP with additional work done by joint studies with CMU and Maryland. The VM stuff is based on Wiscnet, which was an IBM-funded project at Wisconsin. Parts of the VM stuff have been adapted from Wiscnet. Other parts have been totally rewritten (SMTP for example). The "product" is provided (and supported) by a group within IBM's Research Division at Yorktown Heights -- not one of the usual product divisions -- in conjunction with IBM's ACIS (Academic Information Systems) Independent Business Unit. ACIS is the group that runs the Advanced Education Program, AEP, which many schools are beneficiaries of. > Richard Stevens > Health Systems International, New Haven, CT > { uunet | ihnp4 } ! hsi ! stevens Alan Crosswell Columbia University PS: We (have) run Wiscnet, PCIP, TCP/IP for VM and the PC (using both the DACU and the new LAN Channel Station) but have no experience with the 9370. Don't let them sell you a 9370 just to be a network front-end for a larger VM machine -- get a LAN Channel Station instead. It's just a tweaked AT with a channel cable! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711231800.AA05007@ucbvax.Berkeley.EDU] <1987112306114400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jleddy@VAX.BBN.COM (John Leddy) Newsgroups: comp.protocols.tcp-ip Subject: SATNET MTU Message-ID: <8711231800.AA05007@ucbvax.Berkeley.EDU> Date: Mon, 23-Nov-87 11:11:44 EST Article-I.D.: ucbvax.8711231800.AA05007 Posted: Mon Nov 23 11:11:44 1987 Date-Received: Thu, 26-Nov-87 06:38:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Folks, My name is John Leddy and I work at BBN on the SATNET project. I noticed several messages questioning the maximum packet size on the SATNET. To clear things up, the SATNET has a maximum packet size of 256 bytes but because of a 6 byte gateway to gateway header the maximum IP packet size is 250 bytes. John Leddy jleddy@vax.bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112306114401> Received: from VAX.BBN.COM by SRI-NIC.ARPA with TCP; Mon 23 Nov 87 08:16:25-PST Date: Mon, 23 Nov 87 11:11:44 EST From: John Leddy To: tcp-ip@SRI-NIC.ARPA cc: jleddy@VAX.BBN.COM Subject: SATNET MTU Folks, My name is John Leddy and I work at BBN on the SATNET project. I noticed several messages questioning the maximum packet size on the SATNET. To clear things up, the SATNET has a maximum packet size of 256 bytes but because of a 6 byte gateway to gateway header the maximum IP packet size is 250 bytes. John Leddy jleddy@vax.bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3488@ames.arpa] <1987112307190500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lamaster@pioneer.arpa (Hugh LaMaster) Newsgroups: comp.protocols.tcp-ip Subject: Re: Terminal server efficiency Message-ID: <3488@ames.arpa> Date: Mon, 23-Nov-87 12:19:05 EST Article-I.D.: ames.3488 Posted: Mon Nov 23 12:19:05 1987 Date-Received: Thu, 26-Nov-87 01:26:59 EST References: <1135@saturn.ucsc.edu> <8711191851.AA13481@athos.rutgers.edu> Sender: usenet@ames.arpa Reply-To: lamaster@ames.UUCP (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 16 In article <8711191851.AA13481@athos.rutgers.edu> hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) writes: >regard small windows as a significant problem. Does anyone know how the Encore Annex behaves? Hugh LaMaster, m/s 233-9, UUCP {topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov (Disclaimer: "All opinions solely the author's responsibility") ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711231234.aa14194@Huey.UDEL.EDU] <1987112307343700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: A couple of simple questions. Message-ID: <8711231234.aa14194@Huey.UDEL.EDU> Date: Mon, 23-Nov-87 12:34:37 EST Article-I.D.: Huey.8711231234.aa14194 Posted: Mon Nov 23 12:34:37 1987 Date-Received: Thu, 26-Nov-87 22:20:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Andy, Did someone say Chinese? If you an Mr. Martillo can wait until the INARC Workshop at BBN on 17-18 December, we can bring the whole gang. Our advertising department couldn't pass that one up. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711231457.aa17621@Huey.UDEL.EDU] <1987112309574600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: SATNET MTU Message-ID: <8711231457.aa17621@Huey.UDEL.EDU> Date: Mon, 23-Nov-87 14:57:46 EST Article-I.D.: Huey.8711231457.aa17621 Posted: Mon Nov 23 14:57:46 1987 Date-Received: Thu, 26-Nov-87 23:45:17 EST Sender: mayo@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 John, Eeek. What is in that six-octet gateway-gateway header? Is this for the b'rflies? Please tell me it aint so. In fact, it would be a wonderful thing to explain in detail how the buttergates manage their intergateway routing and what expectations it places on the underlying networks. Is the six octets required in every network through which a butter flutters? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12352990858.5.VAF@C.CS.CMU.EDU] <1987112312052700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Vince.Fuller@C.CS.CMU.EDU Newsgroups: comp.protocols.tcp-ip Subject: [Dale.Moore@PS1.CS.CMU.EDU: ] Message-ID: <12352990858.5.VAF@C.CS.CMU.EDU> Date: Mon, 23-Nov-87 17:05:27 EST Article-I.D.: C.12352990858.5.VAF Posted: Mon Nov 23 17:05:27 1987 Date-Received: Fri, 27-Nov-87 22:50:49 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 120 Some people might be interested in the latest status of our VMS TCP/IP package. Vince Fuller, CMU-CSD --------------- Return-Path: Received: from PS1.CS.CMU.EDU by C.CS.CMU.EDU with TCP; Mon 23 Nov 87 16:59:10-EST Date: 23 Nov 1987 17:00:19 EST From: Dale.Moore@PS1.CS.CMU.EDU To: cmu-tek-tcp@C.CS.CMU.EDU Subject: I thought that some of you might appreciate hearing what is going on here at CMU-TEK IP/TCP world headquarters. I figured I'd take some time and write you all a note. A Christmas Card sort'of. The current release of the software is V6.2. If you don't have it, you probably want to get it. V6.2 has some unique problems of its own, but it is in a bit better health than the old V6.0. To get the V6.2 of the software, please send snail mail to CMU-TEK IP/TCP Requests 4910 Forbes Av. Computation Center Carnegie Mellon University Pittsburgh PA 15213 USA Last week, we had over 450 sites liscensed for this software. We do not keep track of how many machines at each site. Many of the requests we receive come from Europe, New Zeland and Australia. Perhaps someday, we'll have to see if we can get some travel out of this. We personally get many requests for help. Some of it quite difficult and some easy. Since this is not a real product, almost everyone is absolutely delighted with any help we can find the time to give them. The best collection of information and help is a mailing list we've set up called "CMU-TEK-TCP-Requests@C.CS.CMU.EDU". Actually that's the address you use to get added/removed from the list. The actual mailing is something else, but too many folks send mail to the mailing list, when they really want added to it. Since we can't spend to much time hand holding with the users, the other folks who are on the mailing list can often add their own insight to your views and problems. Some folks expect us at CMU to do extensive answer/question sessions. We get phone calls that go like "We got our first VAX last week and we couldn't get your stuff to work and my boss told me to call you." and "Ok, push down the Control button. Got it pushed down? Now type C." Some consultants earn over $300 per day. Good ones are probably worth it. If you need more than just a little help, I recommend that you purchase a supported IP/TCP, or get some professional help. Currently, there are three of us at the CMU-TEK IP/TCP world headquarters. Two of us are working on the software. Actually, we are only working on it part time. I know of no plans of increasing the amount of technical support that CMU is giving this software. We have other responsibilities and commitments that we must take care of here. We have a clerical and administrative staff of one, really one half. He has other responsibilities also. We will probably this to one full time position, to better respond to the increasing load. Vince Fuller, one of the two member technical staff, will soon be leaving CMU for the better weather of California. Vince has done a wonderful job with all the work to the ACP and lately NAMSRV. Whether Vince will find time, at his new position, to continue to do development and maintenance remains to be seen. We will miss him and wish him the best at his new job. We hope to get the V6.3 release into beta test sometime in the next few months. If you have - excellent communication and technical skills, - are on the Arpa/Internet, - have a liscense for Bliss-32, - have a variety of Vax hardware, - are already running V6.2 of the software, and - are running VMS V4.6. we might appreciate it if you'd be a beta test site. If you only have 5 of the 6 above we still might appreciate it. Please don't volunteer because you want the latest greatest version with the whizziest functions. Do it because you want to help us get something out that has many fewer problems that the last release. This time we hope to do a more extensive beta - testing in order to avoid some of the problems that we had on the last release. Some of the things that we are working to put into the V6.3 beta release are - a telnet server that is part of the ACP. This will reduce traffic and improve performance. - many fixes to Namsrv. - FTP's ability to handle arbitrary RMS file formats. To my knowledge, no other IP/TCP product for VMS does this! - User manuals for the various user utilities. - More documentation on how to configure your machine. We have done this software for our own use. It is not our intention of supporting it as a commercial product. Many have asked us about implementing other network mediums besides the DEC ethernet interface, such as Serial Line and X.25. Our access to such testing is limited. We hope, that by distributing the sources, if others need such functionality that they'll add it. And if they add it, they'll return the improvements. If they return the improvements to us, we'll try to give the improvements to the rest of you. I'd like to thank the very few of you who have had the time to return your bug fixes and improvements. We all appreciate it. The software is popular. It is becoming more popular. We are working on improving it, but we are limited in the amount of time that we can spend on it. Some external funding that we were hoping for did not work out. I think that even though this may not be the best supported IP/TCP for VMS, it certainly is the best per dollar. Dale Moore Research Systems Programmer Computer Science Department Carnegie Mellon University ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1482@tymix.UUCP] <1987112313175000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: feldman@tymix.UUCP (Steve Feldman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Connecting remote Ethernets? Message-ID: <1482@tymix.UUCP> Date: Mon, 23-Nov-87 18:17:50 EST Article-I.D.: tymix.1482 Posted: Mon Nov 23 18:17:50 1987 Date-Received: Thu, 26-Nov-87 21:55:01 EST References: <933@vsedev.VSE.COM> Reply-To: feldman@tymix.UUCP (Steve Feldman) Organization: Tymnet NTD, Cupertino CA Lines: 17 I too would like information about connecting Ethernets. Specifically, we have two buildings with Ethernets in our campus, with fiber optic cables between the them. If we're lucky, we might get a dedicated fiber pair, otherwise we should be able to get at least a 56Kb link. (We're not allowed to run Ethernet or any other cables. We're stuck with what they gave us.) I believe I've read here that Cisco and Bridge make IP routers which might do what I want. Please mail me any information you might have on these and any other vendors. I'd also like to hear of experiences with these routers, positive and negative. Thanks for your time, Steve Feldman Tymnet McDonnell Douglas uucp: sun!oliveb!tymix!feldman arpa: feldman%tymix.tymnet@office-1.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12353015644.15.BILLW@MATHOM.CISCO.COM] <1987112314213600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BILLW@MATHOM.CISCO.COM (William Westfield) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telephone Access Controllers (TACs) and SLIP... Message-ID: <12353015644.15.BILLW@MATHOM.CISCO.COM> Date: Mon, 23-Nov-87 19:21:36 EST Article-I.D.: MATHOM.12353015644.15.BILLW Posted: Mon Nov 23 19:21:36 1987 Date-Received: Fri, 27-Nov-87 22:50:15 EST References: <8711151624.AA26353@uc.msc.umn.edu> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Rather than having the dialled-into system pick an address for its caller, how about if the caller asks for a particular IP address and authenticates itself with, say, a password? That same calling host would always ask for the same address. The name-address association could be permanent, only the connections would be temporary. This makes routing a big problem (although routing protocols are already dynamic in nature, it isn't clear that they are \that/ dynamic, and are quite likely to have problems with the huge number of routes that may suddenly appear). You would also then have the requirment that each and every PC have its own (sub)net number, which results in quite an address assignment problem if you have (as someone mentioned) 3000+ PCs. A compromise might be to have each SLIP server serve a number of IP addresses on a particular subnet, and then when a PC dials in, it can pick its own address from that pool... It is NOT clear to me that SLIP will primarilly be used by dialin users, and for hardwired connections to PCs, things are a lot easier. Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112315440000> Received: from miasma.stanford.edu ([36.22.0.152]) by SRI-NIC.ARPA with TCP; Mon 23 Nov 87 23:51:36-PST Received: by miasma.stanford.edu; Mon, 23 Nov 87 23:44:53 PST Date: 23 Nov 1987 2344-PST (Monday) From: Glenn Trewitt To: Dan Lynch Cc: tcp-ip@sri-nic.arpa, netman@amadeus.stanford.edu, gwmon@sh.cs.net, Glenn Trewitt Subject: Re: Network Management In-Reply-To: Dan Lynch / Tue 24 Nov 87 00:16:35-EST. <12353069343.24.LYNCH@A.ISI.EDU> [Sorry about the long note, but I've been waiting to hear a statement from the NetMan vendors subgroup to hear just what it is that's going on. Now I've heard, so now I have something to comment on.] Fascinating. All of this talk about what CMIP privides. When listening to the two main proponents of CMIP in the Network Management meetings (up until the last one, of course, which I did not attend), I have heard a lot of statements about what "CMIP Provides". Yet the proposals about what CMIP is to do are constantly changing. At the last meeting in Tokyo, where CMIP was to be voted up from its current "Draft Proposal" status, it was rejected. My understanding is that this was the second time it was rejected, and that there is considerable dissent about just what CMIP will do, and how will it do it. Nowhere else but at the NetMan meetings have I heard such definite statements about what CMIP "is" and "does" and "provides". In talking to some people at Sydney University, I heard estimates of 3-4 years until the ISO monitoring effort produces anything concrete. Surely they aren't TCP/IP lackeys? I do know them to be very practical, however. While I understand the vendors' concerns, I don't agree with the way these concerns color their outlook on ISO migration and short- to medium-term managment solutions. The only thing that ISO management offers that is not included in monitoring proposals such as HEMS or SGMP is an overall architectural definition. This architecture defines the framework that monitoring protocols (such as CMIP or HEMP) operate within. There is no reason that HEMS can't fit into the ISO framework. Many hours were spent discussing how that could be done. Some members of the committee refused to accept the notion that HEMS could conform to the architecture, even though the protocol looks quite different than CMIP. Or, I should say, "what CMIP currently looks like". Architecture aside, the two protocols provide similar services (HEMS offers some not in CMIS). Both will require two major implementation efforts, and each of these efforts will require far more effort than the implementation of HEMS, and probably even more than CMIP. 1) Servers for extracting data from protocol implementations (kernel data structures, etc). Interfaces between protocol modules and the server will be at a very low level and likely will be peculiar to the OS primitives available. There is far more dependency upon environment here than upon the querying mechanism (HEMP or CMIP). 2) Application programs for manipulating this virtual data base. These include programs to keep track of what's going on in the network, systems to produce coherent summaries of network activity from many points of view, specialized "assistants" to help ferret out problems, and finally, programs to do high-level control operations, rather than mucking around down in the dirt. None of these applications depends in the slightest upon the underlying monitoring protocol, except at the very lowest subroutine call level. This is all a lot of work, and it completely overshadows the cost of implementing either of these protocols, much less migrating from one to the other. But there is one difference between the two systems. HEMS is specified now, and CMIS isn't. Plus, CMIS may not be recognizable as CMIS by the time it is nailed down. Defining a network management on the basis of a protocol that changes several times a year simply means that the Network Management WG will end up defining yet another protocol, something that was NOT in its original charter. Please note that I have not touched upon the technical merits (or lack thereof) of either system. As one of the authors of HEMS, I am quite biased about which one I prefer. I do, however, feel that the decisions that Craig and I made in designing HEMS have been validated by Craig's implementation experience. This is something that can't be said of CMIS, which is strictly a paper design right now. If anybody is interested in a discussion of the technical aspects of the two systems, I would be happy to oblige. Another issue I would like to see explored is the apparent domination of the Network Management WG by the "vendors", to the exclusion of the "non-vendors". My impression is that there is a lot of writing going on right now, none of which I am seeing discussed in the open forums available for it (such as netman@amadeus or gwmon@sh.cs.net). I never heard a word about the meeting, except second hand, by accident. What I did hear is that it specifically excluded non-vendors. Now, I suppose that it's fine for vendors to share their concerns with each other, but it seems like a rather dramatic change of course happened at that meeting. Several of the people in attendance had never attended a NetMan meeting before, and several people (including myself) who had attended the meetings from the beginning were excluded. Since when have vendors been in charge of (pre-)defining Internet standards? - Glenn Trewitt P.S. I'll probably regret this in the morning. :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1316@lll-lcc.aRpA] <1987112316301000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chapman@lll-lcc.aRpA (Carol Chapman) Newsgroups: comp.dcom.lans,comp.os.vms,comp.protocols.tcp-ip Subject: networking Message-ID: <1316@lll-lcc.aRpA> Date: Mon, 23-Nov-87 21:30:10 EST Article-I.D.: lll-lcc.1316 Posted: Mon Nov 23 21:30:10 1987 Date-Received: Thu, 26-Nov-87 21:20:16 EST Organization: Livermore National Laboratory Lines: 27 Keywords: TCP/IP, sockets, VMS, UNIX, Wollongong I am looking for advice, suggestions, etc. on how to implement the following: I have a C program which is sitting on a VAX that runs VMS. The program expects a user to sit by 2 terminals, one of which is actually a SUN workstation, and the other is a Tektronix graphics terminal. The user logs onto the VAX via the Tektronix terminal and starts up the program. While the user is working merrily away on the one terminal, my code will occasionally send a character array over a network to the SUN (which is running UNIX). The SUN receives this array which contains the name of an image file stored on that SUN. The SUN displays that image on its screen. This process keeps repeating with the VAX sending arrays and the SUN displaying the corresponding images (a client-server situation). ** END OF "I-DON'T-THINK-IT'S-AS-EASY-AS-IT-SOUNDS" SITUATION ** I have never done any network programming before, so I would love to hear from people who have written code using sockets, which is what I believe is needed for this situation. We have Wollongong's flavor of TCP/IP on the VAX. I don't normally read this newsgroup, so please send replies directly to me (chapman@lll-lcc.arpa, or if .arpa is no longer working then it's chapman@lll-lcc.llnl.gov). Thank you!! carol chapman ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711232038.AA07532@phun.riacs.edu] <1987112316593400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leiner@riacs.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <8711232038.AA07532@phun.riacs.edu> Date: Mon, 23-Nov-87 21:59:34 EST Article-I.D.: phun.8711232038.AA07532 Posted: Mon Nov 23 21:59:34 1987 Date-Received: Thu, 26-Nov-87 22:12:58 EST References: <[A.ISI.EDU]19-Nov-87.10:28:05.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Vint, I thought ISO viewed the management protocols (including gateway routing algorithms) as kind of a blob sitting off to the side of the "stack". Did I get it wrong (again)? Barry ----MESSAGE-END---- ----MESSAGE-BEGIN---- [290492.871124.JBVB@AI.AI.MIT.EDU] <1987112319104400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: tn3270 and IBM's TCP/IP for VM/CMS Message-ID: <290492.871124.JBVB@AI.AI.MIT.EDU> Date: Tue, 24-Nov-87 00:10:44 EST Article-I.D.: AI.290492.871124.JBVB Posted: Tue Nov 24 00:10:44 1987 Date-Received: Fri, 27-Nov-87 23:03:26 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 As far as I know, their stuff has WISCNET ancestry, and functions with Greg Minshall's Unix TN3270 (and IBM's PC version, and ours). One thing to note is that TN3270 burns up a lot of a Unix box. Our PC code on an XT is considerably faster than TN3270 was on a Sun with one user, when I saw Greg using it last spring. I assume IBM's is, too. Of course, Greg may have fixed this. The alternative, Spartacus's translation of full-screen 3270 to VT100 escape sequences, is easy on the Unix box, but hard on the mainframe. You pay your penny, and you take your choices. You might want to look at both, if possible. James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12353069343.24.LYNCH@A.ISI.EDU] <1987112319163500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Network Management Message-ID: <12353069343.24.LYNCH@A.ISI.EDU> Date: Tue, 24-Nov-87 00:16:35 EST Article-I.D.: A.12353069343.24.LYNCH Posted: Tue Nov 24 00:16:35 1987 Date-Received: Fri, 27-Nov-87 23:51:51 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 173 To facilitate information spread on some current network management protocol developments, I am forwarding this set of "minutes" of a recent meeting. Dan *********** Vendors Position Statement on TCP/IP Network Management Standards Working Document - 11/20/87 A lot of email has been exchanged recently, speculating on the TCP/IP network vendors intentions with respect to Network Management standards. It is time for the vendors themselves to explain their position on this topic. On 11/4/87, a group of vendors actively involved with the effort of the Network Management Working Group of the IETF met for the purpose of: 1) assessing the current status of the network management standards efforts with respect to the goals that they had agreed to in May 1987. 2) discussing plans to implement the proposed standards and incorporate them in vendor products. 3) discussing plans to demonstrate interoperability of network management among vendor products. The participants to the meeting included the following vendors: Bridge Communications CMC Data General Excelan Hewlett-Packard Sun Microsystems Sytek 3Com Ungermann-Bass These participants represent a substantial and representative subset of the TCP/IP vendor community at large and are collectively referred to as "the vendors" in the rest of this document. In the course of the discussion on the agenda items listed above, a consensus was reached on five major points: 1) The vendors cannot endorse or implement the recently circulated RFCs describing the HEMS system in their current form for the following reasons: - The HEMS approach does not satisfy a key goal of the Network Management Working Group goals statement [1] which is to provide a "clear migration path to OSI network management." - The services definition RFC [2] authored by Lee Lebarre is a major element in the strategy of providing a clear migration path to OSI and protecting major network management application investments. The ability to deliver these services is a key requirement for choosing a management protocol. The HEMP/Query protocols do not provide this capability while CMIP does. - While the HEMS project provides significant insight into the technical issues of TCP/IP network management, it has not been driven by the same charter as the vendors adopted for the Network Management Group [1]. The requirements for delivering early implementations of HEMS for the gateway monitoring needs of the NSFNet have made discussions and compromises very difficult, and have prevented the HEMS developers from taking into account the vendors key technical concerns and strategic requirement. 2) The vendors continue to treat the Network Management Working Group Goals and Scope document [1] as their common objective statement. In particular, they recognize that the transition from TCP/IP to OSI is inevitable. 3) The vendors agree that the Service Definition RFC BBBB [1] and the HEMS definition of the Management Information can be used as a solid working base on which to build a network managment system for TCP/IP environments. 4) The vendors favor a network management standard approach based upon the CMIP/TCP/IP stack which meets the overall objective of easing the migration to the OSI environment. In particular, it preserves the vendors investment in network management applications and makes the management of hybrid (TCP/IP and OSI) networks significantly easier. They intend to submit concrete proposals to substantiate this approach to the IETF. Alternatively, the vendors would also agree to consider enhancements to HEMP that preserve the integrity of the Management Services interface as defined by RFC BBBB. 5) The vendors remain committed to completing the development of TCP/IP network management standards in an aggressive time frame and take as a goal to demonstrate interoperability of network management in the fall of 1988. In summary, a strong consensus has emerged in the vendor community in favor of a CMIS-based approach. While the quality of the work produced for HEMS is not in question, the vendors are driven by different motivations. They are ultimately responsible for investing considerable development resources to engineer the network management products that will truly create the standard. In network management as well as other areas, the vendors must make choices that maximaze their return on investment of development resources over time. They intend to work within the Network Management Working Group structure of the IETF to pursue these goals. References: [1] TCP/IP Network Management Working Group: Goals and Scope - Revision 3 - 6/18/87 [2] RFC BBBB: Management Services for TCP/IP Network Management, Lee Labarre - 10/87 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [290522.871124.JBVB@AI.AI.MIT.EDU] <1987112320071300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes Message-ID: <290522.871124.JBVB@AI.AI.MIT.EDU> Date: Tue, 24-Nov-87 01:07:13 EST Article-I.D.: AI.290522.871124.JBVB Posted: Tue Nov 24 01:07:13 1987 Date-Received: Sat, 28-Nov-87 00:24:25 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 In my own judgement, a vendor might be justified in restricting distribution of the source code for "version control" only under the following circumstances: 1. Vendor support personnel have access to source code themselves, and the skills and tools to use it. These people don't have to answer the phone, but you need to be able to get a call back in a day or two, at most. 2. These vendor support personnel work in an environment in which most or all customer problems can be conveniently duplicated. The 2nd condition rules out restrictions on most network source code, since not even IBM can maintain a current copy of *every* vendor's TCP/IP hardware and software, and thus there are many problems that can't be duplicated at the vendor's site. Maybe TCP/IP sites are exceptional, but the large TCP users we've sold source to have been quite well equipped with competent personnel, and I've found working with them to be quite productive. We have had to teach some of our OEMs quite a bit, but they weren't users when they started out. James B. VanBokkelen FTP Software Inc. PS: I've realized that I'm talking from sort of a vendor/management perspective. If this bothers a mostly (?) engineering list, tell me and I'll shut up except for technical issues. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6449.8711240343@wrtfac.cdc.com] <1987112320433600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hassler@wrtfac.UUCP (Barry D. Hassler) Newsgroups: comp.protocols.tcp-ip Subject: Re: Lawrence Livermore IGP project? Message-ID: <6449.8711240343@wrtfac.cdc.com> Date: Tue, 24-Nov-87 01:43:36 EST Article-I.D.: wrtfac.6449.8711240343 Posted: Tue Nov 24 01:43:36 1987 Date-Received: Fri, 27-Nov-87 22:52:06 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 48 Brad, The Intelligent Gateway Processor is a generic term for software originally developed at LLNL, and now commercially marketed by Control Data Corporation's Professional Services Division as ASCENT. The software comprising this system was developed as a generic front-end to heterogeneous systems for scientists at the Lab. It consists of two major pieces of software, the Network Access Machine, and a menu- oriented user interface. Without going into a great deal of detail, NAM uses an interpretive language to initiate and manage "connections" over a wide variety of "communication methods": direct RS-232, TCP/IP networks, X.25, dial-up phones, etc. This software strictly resides on a UNIX (or perversion thereof) host, and requires no additional hardware or software on the attached hosts. Basically, the software is used to insulate users from the complexities of various network configurations, intermediate devices (dataswitches, network interface units for broadband LANs, protocol converts, etc) and connection procedures in large, heterogeneous computing environments. Additionally, it has the capability for handling portions of, or entire, sessions with a host on behalf of a user. In a current commercial implementation, we use this technology to support connections to DEC VAXES, CDC Cybers, NAS 5000 & 7000s, and Data General Workcenters over TCP/IP and X.25 networks from users coming into the IGP via dial-up, DDN telnet, broadband LANS, and Fiber-Optic muxes. The IGP is being used currently by various DoD agencies, mostly the Air Force, Department of Energy, and the Defense Logistics Agency, among others. Over the past several years there have been several papers published or presented concerning this technology. Although I don't have my copies here at home, I'd be happy to supply a list of references to them and where you can get copies if interested. I just recently (Friday) completed the latest such paper (which is why I'm finally getting to my EM now) entitled "Connectivity and Beyond." I feel (somewhat biased naturally) this paper gives a good overview of the reasons for this technology, and how it works in heterogeneous environments. As soon as it has complete being cleared for public dissemination (since it references a military project), I will be happy to provide copies of it. Barry D. Hassler ARPA/DDN: hassler@lognet2.arpa System Software Analyst Control Data Corporation Professional Services Division Integrated Information Services ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711242024.AA03586@ucbvax.Berkeley.EDU] <1987112321440000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: trewitt@MIASMA.STANFORD.EDU (Glenn Trewitt) Newsgroups: comp.protocols.tcp-ip Subject: Re: Network Management Message-ID: <8711242024.AA03586@ucbvax.Berkeley.EDU> Date: Tue, 24-Nov-87 02:44:00 EST Article-I.D.: ucbvax.8711242024.AA03586 Posted: Tue Nov 24 02:44:00 1987 Date-Received: Sat, 28-Nov-87 05:49:02 EST References: <12353069343.24.LYNCH@A.ISI.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 100 [Sorry about the long note, but I've been waiting to hear a statement from the NetMan vendors subgroup to hear just what it is that's going on. Now I've heard, so now I have something to comment on.] Fascinating. All of this talk about what CMIP privides. When listening to the two main proponents of CMIP in the Network Management meetings (up until the last one, of course, which I did not attend), I have heard a lot of statements about what "CMIP Provides". Yet the proposals about what CMIP is to do are constantly changing. At the last meeting in Tokyo, where CMIP was to be voted up from its current "Draft Proposal" status, it was rejected. My understanding is that this was the second time it was rejected, and that there is considerable dissent about just what CMIP will do, and how will it do it. Nowhere else but at the NetMan meetings have I heard such definite statements about what CMIP "is" and "does" and "provides". In talking to some people at Sydney University, I heard estimates of 3-4 years until the ISO monitoring effort produces anything concrete. Surely they aren't TCP/IP lackeys? I do know them to be very practical, however. While I understand the vendors' concerns, I don't agree with the way these concerns color their outlook on ISO migration and short- to medium-term managment solutions. The only thing that ISO management offers that is not included in monitoring proposals such as HEMS or SGMP is an overall architectural definition. This architecture defines the framework that monitoring protocols (such as CMIP or HEMP) operate within. There is no reason that HEMS can't fit into the ISO framework. Many hours were spent discussing how that could be done. Some members of the committee refused to accept the notion that HEMS could conform to the architecture, even though the protocol looks quite different than CMIP. Or, I should say, "what CMIP currently looks like". Architecture aside, the two protocols provide similar services (HEMS offers some not in CMIS). Both will require two major implementation efforts, and each of these efforts will require far more effort than the implementation of HEMS, and probably even more than CMIP. 1) Servers for extracting data from protocol implementations (kernel data structures, etc). Interfaces between protocol modules and the server will be at a very low level and likely will be peculiar to the OS primitives available. There is far more dependency upon environment here than upon the querying mechanism (HEMP or CMIP). 2) Application programs for manipulating this virtual data base. These include programs to keep track of what's going on in the network, systems to produce coherent summaries of network activity from many points of view, specialized "assistants" to help ferret out problems, and finally, programs to do high-level control operations, rather than mucking around down in the dirt. None of these applications depends in the slightest upon the underlying monitoring protocol, except at the very lowest subroutine call level. This is all a lot of work, and it completely overshadows the cost of implementing either of these protocols, much less migrating from one to the other. But there is one difference between the two systems. HEMS is specified now, and CMIS isn't. Plus, CMIS may not be recognizable as CMIS by the time it is nailed down. Defining a network management on the basis of a protocol that changes several times a year simply means that the Network Management WG will end up defining yet another protocol, something that was NOT in its original charter. Please note that I have not touched upon the technical merits (or lack thereof) of either system. As one of the authors of HEMS, I am quite biased about which one I prefer. I do, however, feel that the decisions that Craig and I made in designing HEMS have been validated by Craig's implementation experience. This is something that can't be said of CMIS, which is strictly a paper design right now. If anybody is interested in a discussion of the technical aspects of the two systems, I would be happy to oblige. Another issue I would like to see explored is the apparent domination of the Network Management WG by the "vendors", to the exclusion of the "non-vendors". My impression is that there is a lot of writing going on right now, none of which I am seeing discussed in the open forums available for it (such as netman@amadeus or gwmon@sh.cs.net). I never heard a word about the meeting, except second hand, by accident. What I did hear is that it specifically excluded non-vendors. Now, I suppose that it's fine for vendors to share their concerns with each other, but it seems like a rather dramatic change of course happened at that meeting. Several of the people in attendance had never attended a NetMan meeting before, and several people (including myself) who had attended the meetings from the beginning were excluded. Since when have vendors been in charge of (pre-)defining Internet standards? - Glenn Trewitt P.S. I'll probably regret this in the morning. :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]24-Nov-87.04:23:46.CERF] <1987112323230000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <[A.ISI.EDU]24-Nov-87.04:23:46.CERF> Date: Tue, 24-Nov-87 04:23:00 EST Article-I.D.: <[A.ISI.EDU]24-Nov-87.04:23:46.CERF> Posted: Tue Nov 24 04:23:00 1987 Date-Received: Sat, 28-Nov-87 05:56:59 EST References: <8711232038.AA07532@phun.riacs.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Barry, ISO does put the management protocols off to the side with comb-like projections into the various layers - rather like DECNET in that regard. The gateway routing protocols all showed up just above IP in the DoD Internet. At other layers, there was network management, too, but not integrated into a common architecture. There were network level management systems (e.g. ARPANET NOC), Internet management systems (INOC, HMP - host monitoring protocol, GGP/IGP,EGP, etc.). It still isn't entirely clear to me how integrated you can get and still deal with separation of administrative control, etc. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112323230001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 24 Nov 87 01:25:50-PST Date: 24 Nov 1987 04:23-EST Sender: CERF@A.ISI.EDU Subject: Re: Idle chatter about reference models From: CERF@A.ISI.EDU To: leiner@ICARUS.RIACS.EDU Cc: oconnor@SCCGATE.SCC.COM, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]24-Nov-87 04:23:46.CERF> In-Reply-To: <8711232038.AA07532@phun.riacs.edu> Barry, ISO does put the management protocols off to the side with comb-like projections into the various layers - rather like DECNET in that regard. The gateway routing protocols all showed up just above IP in the DoD Internet. At other layers, there was network management, too, but not integrated into a common architecture. There were network level management systems (e.g. ARPANET NOC), Internet management systems (INOC, HMP - host monitoring protocol, GGP/IGP,EGP, etc.). It still isn't entirely clear to me how integrated you can get and still deal with separation of administrative control, etc. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112323250000> Received: from MIT-Multics.ARPA by SRI-NIC.ARPA with TCP; Tue 24 Nov 87 16:23:57-PST Received: from UBC.MAILNET by MIT-Multics.ARPA with Mailnet id <2742250557914989@MIT-Multics.ARPA>; 24 Nov 1987 19:15:57 est Received: from SFU(MAILER) by UBCMTSG(MAILER) via BITNET with RM id <210744@UBCMTSG.BITNET>; Tue, 24 Nov 87 15:21:05 PST Date: Tue, 24 Nov 87 07:25:00 PST From: "tcp-ip-RELAY%SRI-NIC.ARPA" <@MIT-Multics.ARPA,@UBC.MAILNET,@SFU,@UM.CC.UMICH.EDU:tcp-ip-RELAY@SRI-NIC.ARPA> Subject: Re: Idle chatter about reference models To: Tcp-ip-dist: userID=DUM1@SFU.BITNET, My_Hangout@SFU.BITNET, Userid=Q73X@UBC.Mailnet, userID=TCP@SFU.BITNET, ubc-tcp-ip@UBCMTSG.BITNET;, CERF@A.ISI.EDU, oconnor@SCCGATE.SCC.COM, tcp-ip@SRI-NIC.ARPA Date: Tue, 24 Nov 87 07:25:00 PST To: userID=DUM1@SFU.MAILNET, CERF@A.ISI.EDU, oconnor@SCCGATE.SCC.COM, tcp-ip@SRI-NIC.ARPA Subject: Re: Idle chatter about reference models Vint, Couldn't GGP and EGP be viewed as application (or management or somesuch) protocols that just happen to have transport functionality built into them? Using such a view in Mike's diagram, GGP/EGP might be vertical rectangles that spanned several of the corresponding layers in the ISO model. My own favorite is to view them as management protocols of the IP layer (that happen to provide their own transport). After all, their purpose is to update an IP MIB (that's ISOese for routing table). Phill ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112401474000> Received: from MIT-Multics.ARPA by SRI-NIC.ARPA with TCP; Wed 25 Nov 87 00:39:53-PST Received: from UBC.MAILNET by MIT-Multics.ARPA with Mailnet id <2742280292848155@MIT-Multics.ARPA>; 25 Nov 1987 03:31:32 est Received: from SFU(MAILER) by UBCMTSG(MAILER) via BITNET with RM id <211358@UBCMTSG.BITNET>; Tue, 24 Nov 87 17:04:56 PST Date: Tue, 24 Nov 87 09:47:40 PST From: "tcp-ip-RELAY%SRI-NIC.ARPA" <@MIT-Multics.ARPA,@UBC.MAILNET,@SFU,@UM.CC.UMICH.EDU:tcp-ip-RELAY@SRI-NIC.ARPA> Subject: Re: Idle chatter about reference models To: Tcp-ip-dist: userID=DUM1@SFU.BITNET, My_Hangout@SFU.BITNET, Userid=Q73X@UBC.Mailnet, userID=TCP@SFU.BITNET, tcp-ip@UBCMTSG.BITNET;, LAWS%rsre.mod.uk@NSS.CS.UCL.AC.UK, CERF@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA, oconnor@SCCGATE.SCC.COM Date: Tue, 24 Nov 87 09:47:40 PST To: userID=DUM1@SFU.MAILNET, LAWS%rsre.mod.uk@NSS.CS.UCL.AC.UK, CERF@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA, oconnor@SCCGATE.SCC.COM Subject: Re: Idle chatter about reference models Sorry to have kept you waiting; I have been off form as it happens, and off to the Left Coast to boot. Rather than succumb to the temptation of trying to see how many epicycles the ISORM has these days (though I must confess I had been convinced at one point in time that the party line was that each layer could/did have a management sublayer--but never found out if that also applied to each sublayer, so wasn't sure if L3 was four or six epicycles deep), let's go back to the initiating question. As I recall, it was something like where things like GGP, EGP, and HMP went in the layering. Although I have a great deal of sympathy for those who didn't bite and in essence placed such things orthogonal to the layering, I would like to observe that there's an alternative for those who find that view unsatisfying: If you believe that the layers are Applications/Process, Host-Host, and Network (Interface)--i.e., the old simple as I, II, III ARM I've always espoused--then the answer ought to be easy to derive for any of the three (or other, like protocols). If they have to do with doing things in common for the users' processes to get the bits to go from Host to Host, then they're L II is one approach. If they're clearly not part of the interface to the proximate comm subnet processor and also fairly clearly not directly germane to the Applications/Process Layer, then they're L II is the other approach. (Note to the original question- raiser: you're of course welcome to use my Form, but it works better if you use my Content too.) (Note to John Laws: as you well know, my main problem with the ISORMites is that they seem to me to be attempting to substitute Form for Content almost all the time.) Hope that's not too characteristically cryptic; if it is, I'll cop a plea based on an imminent cold on top of the jetlag. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711241525.AA04839@gateway.mitre.org] <1987112405250000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <8711241525.AA04839@gateway.mitre.org> Date: Tue, 24-Nov-87 10:25:00 EST Article-I.D.: gateway.8711241525.AA04839 Posted: Tue Nov 24 10:25:00 1987 Date-Received: Sat, 28-Nov-87 06:04:04 EST Sender: fair@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Vint, Couldn't GGP and EGP be viewed as application (or management or somesuch) protocols that just happen to have transport functionality built into them? Using such a view in Mike's diagram, GGP/EGP might be vertical rectangles that spanned several of the corresponding layers in the ISO model. My own favorite is to view them as management protocols of the IP layer (that happen to provide their own transport). After all, their purpose is to update an IP MIB (that's ISOese for routing table). Phill ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711241638.AA29138@cs.utah.edu] <1987112406382300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cetron@CS.UTAH.EDU (Edward J Cetron) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP maximum segment size determination Message-ID: <8711241638.AA29138@cs.utah.edu> Date: Tue, 24-Nov-87 11:38:23 EST Article-I.D.: cs.8711241638.AA29138 Posted: Tue Nov 24 11:38:23 1987 Date-Received: Sat, 28-Nov-87 06:08:35 EST References: <283116.871110.JBVB@AI.AI.MIT.EDU> <3370@hoptoad.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: cs.utah.edu!cetron@cs.utah.edu (Edward J Cetron) Organization: Center for Engineering Design, Univ of Utah Lines: 11 In article <3370@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >standard Ethernet chips and DRAMs available to everyone. You too can >handle infinite back to back packets, if you just design with that in >mind as Sun did.] Is this the same sun that, when it receives two or more back to back rarp packets, simply discards all but the last??? I guess the hardware can catch the packets, the software just can't keep up.... -ed cetron cetron@cs.utah.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12353206078.19.PADLIPSKY@A.ISI.EDU] <1987112407474100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <12353206078.19.PADLIPSKY@A.ISI.EDU> Date: Tue, 24-Nov-87 12:47:41 EST Article-I.D.: A.12353206078.19.PADLIPSKY Posted: Tue Nov 24 12:47:41 1987 Date-Received: Sat, 28-Nov-87 07:17:20 EST References: <20.NOV.1987.00:32:44.LAWS@RSRE> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Sorry to have kept you waiting; I have been off form as it happens, and off to the Left Coast to boot. Rather than succumb to the temptation of trying to see how many epicycles the ISORM has these days (though I must confess I had been convinced at one point in time that the party line was that each layer could/did have a management sublayer--but never found out if that also applied to each sublayer, so wasn't sure if L3 was four or six epicycles deep), let's go back to the initiating question. As I recall, it was something like where things like GGP, EGP, and HMP went in the layering. Although I have a great deal of sympathy for those who didn't bite and in essence placed such things orthogonal to the layering, I would like to observe that there's an alternative for those who find that view unsatisfying: If you believe that the layers are Applications/Process, Host-Host, and Network (Interface)--i.e., the old simple as I, II, III ARM I've always espoused--then the answer ought to be easy to derive for any of the three (or other, like protocols). If they have to do with doing things in common for the users' processes to get the bits to go from Host to Host, then they're L II is one approach. If they're clearly not part of the interface to the proximate comm subnet processor and also fairly clearly not directly germane to the Applications/Process Layer, then they're L II is the other approach. (Note to the original question- raiser: you're of course welcome to use my Form, but it works better if you use my Content too.) (Note to John Laws: as you well know, my main problem with the ISORMites is that they seem to me to be attempting to substitute Form for Content almost all the time.) Hope that's not too characteristically cryptic; if it is, I'll cop a plea based on an imminent cold on top of the jetlag. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711251036.AA13537@umix.cc.umich.edu] <1987112408151800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcp-ip-RELAY@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8711251036.AA13537@umix.cc.umich.edu> Date: Tue, 24-Nov-87 13:15:18 EST Article-I.D.: umix.8711251036.AA13537 Posted: Tue Nov 24 13:15:18 1987 Date-Received: Sun, 29-Nov-87 00:52:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 , tcp-ip@SRI-NIC.ARPA, ARPANETMGR@DDN1.ARPA, BOWERS@A.ISI.EDU, SCCMGR@DDN1.ARPA, SNIVELY@DDN1.ARPAARPANET-BBOARDS Date: Tue, 24 Nov 87 10:15:18 PST To: userID=DUM1@SFU.MAILNET, tcp-ip@SRI-NIC.ARPA, ARPANETMGR@DDN1.ARPA, BOWERS@A.ISI.EDU, SCCMGR@DDN1.ARPA, SNIVE Subject: Status of ARPANET Upgrade As a result of a meeting held on 20 November to discuss the status of the new ARPANET End-to-End protocol (PSN 7.0), it was determined that the protocol requires more testing. The tentative schedule is to cut over to the new End-to-End on Saturday, 5 December. Should no problems arise, the new End-to-End will remain running throughout the week. Hosts experiencing problems during this test period are asked to call the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12353211109.39.NIC@SRI-NIC.ARPA] <1987112408151900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NIC@SRI-NIC.ARPA (DDN Reference) Newsgroups: comp.protocols.tcp-ip Subject: Status of ARPANET Upgrade Message-ID: <12353211109.39.NIC@SRI-NIC.ARPA> Date: Tue, 24-Nov-87 13:15:19 EST Article-I.D.: SRI-NIC.12353211109.39.NIC Posted: Tue Nov 24 13:15:19 1987 Date-Received: Sat, 28-Nov-87 07:18:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 As a result of a meeting held on 20 November to discuss the status of the new ARPANET End-to-End protocol (PSN 7.0), it was determined that the protocol requires more testing. The tentative schedule is to cut over to the new End-to-End on Saturday, 5 December. Should no problems arise, the new End-to-End will remain running throughout the week. Hosts experiencing problems during this test period are asked to call the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2756@drivax.UUCP] <1987112408340900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: socha@drivax.UUCP (Henri J. Socha (7-x6628)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Apologies and Arcnet Message-ID: <2756@drivax.UUCP> Date: Tue, 24-Nov-87 13:34:09 EST Article-I.D.: drivax.2756 Posted: Tue Nov 24 13:34:09 1987 Date-Received: Sun, 29-Nov-87 16:20:11 EST References: <8711222235.AA13789@ARES.MIT.EDU> Reply-To: socha@drivax.UUCP (Henri J. Socha (7-x6628)) Organization: Digital Research, Monterey, CA Lines: 100 Answering your questions even as I read them: In article <8711222235.AA13789@ARES.MIT.EDU> martillo@ATHENA.MIT.EDU writes: >I noticed arcnet being discussed here. Now my friends at Clearpoint >use arcnet networking cards with vme bus interfaces for some sort of >distributed memory testing. After seeing arcnet mentioned in this >newsgroup, I have become curious. > >Where does arcnet come from? It was developed at Datapoint Corp. of San Antinio Texas in 1976 by members of the Advanced Product Development (R&D) group I was a memeber. Datapoint (and people in this group) also architected the "Intel 8008", the first dBase type of programme (that I know of), the 2nd PC (IBM's 5100 was first), one of the first glass TTYs, etc. (But enough of this.) The ARCnet hardware and protocol was designed by one Engineer with the help of two techs. and about 3 other people who discussed it and gave advice/suggestions. The limitations of board (TTL MSI) space generated some of its idiocyncracies for example the DID is transmitted twice on the wire. The changes to Datapoint's DOS similar to what happens/happened when you go from PC-DOS 2.x to 3.x was done by one individual. This DOS used a similar similar system to the NET USE of PC-DOS call MOUNT. By the way, remember that we are talking about a networking OS in 1976! >Who uses it and why (instead of some other networking scheme)? It was first used inhouse to connect multiple Datapoint machines together so that production/purchasing/etc. could access common databases and allow more that 10 DataShare users access to one database. The only other network known (by us in R&D) was Ethernet (the original 3MegaBaud XEROX one). It was decided (demanded) that a system be used where assured transmission within a maximum time be used. The concept of CSMA/CD (Ethernet, etc.) still is revolting to me. ARC has very simple installation using what I call a connected star configuration. And is VERY robust in that most anything that happens to the cable (connections/disconnections/wiring changes) can be done on a live system with reconfiguration handled automatically by the hardware. I.E. as long as your node doesn't need something now disconnected, your node does not even know that the break occured. The robustness, its reasonable speed, etc. have put it in I hear over 400,000 installations (said so in some magazine in an article about OTHER networks!) I know of users in the * Business industry (Datapoint customers like the local city government with all departments on an ARCnet of many nodes.) * factory floor (large German manufacturer) * Actually anywhere you see nets, you'll see ARCnet. Remember, It was one of the first high speed commercial PC machine nets. And is still up there performance-wise against all newcommers in this market. (OK, not 50MegaBaud Hyperchannel but we're talking PCs here!) >What are the achievable data rates? Ask anyone about effective rates and you get down to issues of OS performance as well (how well/much can the OS handle). But let me mention some interesting facts even if not quite what you requested. * The system is defined as 2.5MBaud but because it uses an isocronous(sp?) transmission scheme (resync on each character in a message) to send 8 data bits you must send 11 baud (3 sync bits preceed each data bit) therefore the effective data rate is about 1.8MegaBit per second. * When one person was testing some (bad?) hardware on a live network while many REAL users were using it, the response time degraded. The network of course still operated correctly but was loaded down by over 400 (256 byte) messages per second. * A live ARC system (at Datapoint again) had over 200 nodes on it (max is 255). About 150+ were active on the net and the message rate was about 200 per second. (And yes, I saw this myself.) Response time was good enough that all engineering nodes in R&D were diskless (not even diskettes). And, many/most other nodes were diskless too. Dedicated files servers were used but the OS, a newer one written in '80 called RMS, considered any node a requestor or server so you could go to the Server and use it like any other machine. They were just used as Servers so that all of memory could be a disk cache (fully dynamic, run an App. and cache shrinks). Response time? OK, not as good as a local disk but good enough that it was not an issue. In fact, in one test a copy from file server to file server by a user machine was slightly faster than a local copy! Why? the caching! The file server could pre-read and post-write whole tracks to/from the disk optimally servicing requests from the network. Meanwhile the programme in the local machine was being handed BIG buffers of data that it just "wrote" back out over the net back to a file server. >Where can I get literature on arcnet? Try: Standard Micro Systems (they make the chip and sell a PC board) Datapoint (of course) (They may have an 800 number) Radio Shack (UGH!) Does sell some ARC hardware. Novell puts its LAN on ARCnet (and one of the fastest implementations) >Yakim Martillo Shalom v'litraot Yakim -- UUCP:...!amdahl!drivax!socha WAT Iron'75 "Everything should be made as simple as possible but not simpler." A. Einstein ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711251036.AA13544@umix.cc.umich.edu] <1987112409083000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcp-ip-RELAY@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8711251036.AA13544@umix.cc.umich.edu> Date: Tue, 24-Nov-87 14:08:30 EST Article-I.D.: umix.8711251036.AA13544 Posted: Tue Nov 24 14:08:30 1987 Date-Received: Sat, 28-Nov-87 15:44:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 53 , lynch@A.ISI.EDU, trewitt%miasma.stanford.edu@PARK-STREET.BBN.COM, rcallon@PARK-STREET.BBN.COM, tcp-ip@SRI-NIC.ARP Date: Tue, 24 Nov 87 11:08:30 PST To: userID=DUM1@SFU.MAILNET, lynch@A.ISI.EDU, trewitt%miasma.stanford.edu@PARK-STREET.BBN.COM, rcallon@PARK-STREET.BBN. Subject: re: Network Management The goal of a protocol which can be implemented in a reasonably short time frame (one of the goals of HEMS) seems inconsistent with the goal of being consistent with ISO network management protocols. If you want to be consistent with the ISO protocols, then you should wait until they are done. If you want something now (or within 6 months), then you are going to have to use something that is available now (or can be developed in 6 months). I don't understand why it is useful to have something which is sort of vaguely like what we think CMIP is going to look like when it is done. Either you are compatible with an ISO standard or you're not. Being sort of close doesn't seem to buy all that much. (This assumes that it is not possible to get "close enough" to interoperate with the eventual ISO International Standard without changes, which I think is a fairly safe assumption). I think it would be easier to implement HEMS (or SGMP or HMP), and accept that we will need to change at some time in the future, than to argue at great length as to how to define a protocol which resembles CMIP as much as possible, which will still need to be implemented and then changed at some time in the future. There is a lot of talk about being protocol consistent, but relatively little about other aspects of building a network management system. A network management system which want to manage multiple vendor's equipment in an Internet is going to have to speak more than one network management protocol whether you like it or not. If the slowness of ISO doesn't assure this, then the large amount of existing equipment and/or IBM is going to assure it instead. What is more difficult is to deal with incompatible data sets returned from different devices, inconsistencies in the way that the database is stored in different network management systems, etc. Thus if you are worried about the eventual transition from TCP/IP to ISO, you should, for example, be worried about the differences between the set of network management metrics defined by HEMS and that being worked on for gateways in ANSI X3S33, and you should think about what you intend to do with either set of data when you get it into your system. [Note: My reference to the slowness of ISO should NOT in any way be interpreted as a complaint. The process of developing an international standard is of necessity a very slow and laborious process. The complexity of network management make the CMIP development even harder. However, we have to accept that this process is not likely to speed up.] Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711250154.AA10390@ucbvax.Berkeley.EDU] <1987112409083100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rcallon@PARK-STREET.BBN.COM (Ross Callon) Newsgroups: comp.protocols.tcp-ip Subject: re: Network Management Message-ID: <8711250154.AA10390@ucbvax.Berkeley.EDU> Date: Tue, 24-Nov-87 14:08:31 EST Article-I.D.: ucbvax.8711250154.AA10390 Posted: Tue Nov 24 14:08:31 1987 Date-Received: Sat, 28-Nov-87 07:25:48 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 48 The goal of a protocol which can be implemented in a reasonably short time frame (one of the goals of HEMS) seems inconsistent with the goal of being consistent with ISO network management protocols. If you want to be consistent with the ISO protocols, then you should wait until they are done. If you want something now (or within 6 months), then you are going to have to use something that is available now (or can be developed in 6 months). I don't understand why it is useful to have something which is sort of vaguely like what we think CMIP is going to look like when it is done. Either you are compatible with an ISO standard or you're not. Being sort of close doesn't seem to buy all that much. (This assumes that it is not possible to get "close enough" to interoperate with the eventual ISO International Standard without changes, which I think is a fairly safe assumption). I think it would be easier to implement HEMS (or SGMP or HMP), and accept that we will need to change at some time in the future, than to argue at great length as to how to define a protocol which resembles CMIP as much as possible, which will still need to be implemented and then changed at some time in the future. There is a lot of talk about being protocol consistent, but relatively little about other aspects of building a network management system. A network management system which want to manage multiple vendor's equipment in an Internet is going to have to speak more than one network management protocol whether you like it or not. If the slowness of ISO doesn't assure this, then the large amount of existing equipment and/or IBM is going to assure it instead. What is more difficult is to deal with incompatible data sets returned from different devices, inconsistencies in the way that the database is stored in different network management systems, etc. Thus if you are worried about the eventual transition from TCP/IP to ISO, you should, for example, be worried about the differences between the set of network management metrics defined by HEMS and that being worked on for gateways in ANSI X3S33, and you should think about what you intend to do with either set of data when you get it into your system. [Note: My reference to the slowness of ISO should NOT in any way be interpreted as a complaint. The process of developing an international standard is of necessity a very slow and laborious process. The complexity of network management make the CMIP development even harder. However, we have to accept that this process is not likely to speed up.] Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112409083101> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Tue 24 Nov 87 11:11:41-PST Date: Tue, 24 Nov 87 14:08:31 EST From: Ross Callon To: lynch@A.ISI.EDU, trewitt%miasma.stanford.edu@PARK-STREET.BBN.COM cc: rcallon@PARK-STREET.BBN.COM, tcp-ip@SRI-NIC.ARPA, gwmon@SH.CS.NET, netman@AMADEUS.STANFORD.EDU Subject: re: Network Management The goal of a protocol which can be implemented in a reasonably short time frame (one of the goals of HEMS) seems inconsistent with the goal of being consistent with ISO network management protocols. If you want to be consistent with the ISO protocols, then you should wait until they are done. If you want something now (or within 6 months), then you are going to have to use something that is available now (or can be developed in 6 months). I don't understand why it is useful to have something which is sort of vaguely like what we think CMIP is going to look like when it is done. Either you are compatible with an ISO standard or you're not. Being sort of close doesn't seem to buy all that much. (This assumes that it is not possible to get "close enough" to interoperate with the eventual ISO International Standard without changes, which I think is a fairly safe assumption). I think it would be easier to implement HEMS (or SGMP or HMP), and accept that we will need to change at some time in the future, than to argue at great length as to how to define a protocol which resembles CMIP as much as possible, which will still need to be implemented and then changed at some time in the future. There is a lot of talk about being protocol consistent, but relatively little about other aspects of building a network management system. A network management system which want to manage multiple vendor's equipment in an Internet is going to have to speak more than one network management protocol whether you like it or not. If the slowness of ISO doesn't assure this, then the large amount of existing equipment and/or IBM is going to assure it instead. What is more difficult is to deal with incompatible data sets returned from different devices, inconsistencies in the way that the database is stored in different network management systems, etc. Thus if you are worried about the eventual transition from TCP/IP to ISO, you should, for example, be worried about the differences between the set of network management metrics defined by HEMS and that being worked on for gateways in ANSI X3S33, and you should think about what you intend to do with either set of data when you get it into your system. [Note: My reference to the slowness of ISO should NOT in any way be interpreted as a complaint. The process of developing an international standard is of necessity a very slow and laborious process. The complexity of network management make the CMIP development even harder. However, we have to accept that this process is not likely to speed up.] Ross ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711251933.AA25816@umix.cc.umich.edu] <1987112409410600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcp-ip-RELAY@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8711251933.AA25816@umix.cc.umich.edu> Date: Tue, 24-Nov-87 14:41:06 EST Article-I.D.: umix.8711251933.AA25816 Posted: Tue Nov 24 14:41:06 1987 Date-Received: Sun, 29-Nov-87 06:19:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 , LAWS%rsre.mod.uk@NSS.CS.UCL.AC.UK, CERF@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA, oconnor@SCCGATE.SCC.COM Date: Tue, 24 Nov 87 11:41:06 PST To: userID=DUM1@SFU.MAILNET, LAWS%rsre.mod.uk@NSS.CS.UCL.AC.UK, CERF@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA, oconnor@SCCGATE Subject: Re: Idle chatter about reference models Ooops. More off form than I'd realized [/realised]: Belatedly occurred to me that the Layer, Layer, Who's Got the Layer context is a good one for remembering that even if the ISORMites still think you've got to traverse every layer every time, I never did (and they might not any more, if one thinks things like "MAP" [which, of course, should be "MAPS" to begin with, since it's a Suite, not just A protocol] are ISORMitic, since it blithely skips a layer or two on its way). So I'd refine my answer to the original question to include something like "They sure seem to me to be operating at L II WHEN THEY'RE OPERATING." That might somehow subsume the notion that a few people had that they're not really "in" the "stack"--or perhaps subvert it, if not subsume it. (And I guess it's also worth pointing out that is assumes HMP, which I haven't looked at, doesn't muddy the waters and operate over TCP connections, which would almost make it have to be L III by my insistently non-rigorous definitions.) fuzzy cheers, map p.s. So as not to generate a new Glossary call, for the benefit of those who haven't been around long enough, "ISORM" = ISO Reference Model; ISORMite = follower of the ISORM who I feel is of dubious worth (as opp. to ISORMist, which is one I feel to be sound in other respects but wrong about the RM issue). (The reason why I don't use "OSI" is that I feel it begs the question; i.e., they may say they're doing Open System Interconnection in their name, but are they in their RM ... or their standard protocols? Besides, I like the sound of ISORM.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12353226727.40.PADLIPSKY@A.ISI.EDU] <1987112409410700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Idle chatter about reference models Message-ID: <12353226727.40.PADLIPSKY@A.ISI.EDU> Date: Tue, 24-Nov-87 14:41:07 EST Article-I.D.: A.12353226727.40.PADLIPSKY Posted: Tue Nov 24 14:41:07 1987 Date-Received: Sat, 28-Nov-87 07:28:11 EST References: <20.NOV.1987.00:32:44.LAWS@RSRE> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Ooops. More off form than I'd realized [/realised]: Belatedly occurred to me that the Layer, Layer, Who's Got the Layer context is a good one for remembering that even if the ISORMites still think you've got to traverse every layer every time, I never did (and they might not any more, if one thinks things like "MAP" [which, of course, should be "MAPS" to begin with, since it's a Suite, not just A protocol] are ISORMitic, since it blithely skips a layer or two on its way). So I'd refine my answer to the original question to include something like "They sure seem to me to be operating at L II WHEN THEY'RE OPERATING." That might somehow subsume the notion that a few people had that they're not really "in" the "stack"--or perhaps subvert it, if not subsume it. (And I guess it's also worth pointing out that is assumes HMP, which I haven't looked at, doesn't muddy the waters and operate over TCP connections, which would almost make it have to be L III by my insistently non-rigorous definitions.) fuzzy cheers, map p.s. So as not to generate a new Glossary call, for the benefit of those who haven't been around long enough, "ISORM" = ISO Reference Model; ISORMite = follower of the ISORM who I feel is of dubious worth (as opp. to ISORMist, which is one I feel to be sound in other respects but wrong about the RM issue). (The reason why I don't use "OSI" is that I feel it begs the question; i.e., they may say they're doing Open System Interconnection in their name, but are they in their RM ... or their standard protocols? Besides, I like the sound of ISORM.) te: 2ybo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711251046.AA13662@umix.cc.umich.edu] <1987112409542400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcp-ip-RELAY@SRI-NIC.ARPA ("tcp-ip-RELAY%SRI-NIC.ARPA") Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8711251046.AA13662@umix.cc.umich.edu> Date: Tue, 24-Nov-87 14:54:24 EST Article-I.D.: umix.8711251046.AA13662 Posted: Tue Nov 24 14:54:24 1987 Date-Received: Sat, 28-Nov-87 18:23:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 , nsfnet@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA, steve@note.nsf.gov Date: Tue, 24 Nov 87 11:54:24 PST To: userID=DUM1@SFU.MAILNET, nsfnet@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA, steve@NOTE.NSF.GOV Subject: Award The National Science Foundation today announced a five-year, $14 million grant to MERIT, Inc., for the upgrading, operation and management of the NSFNET transcontinental backbone network. (MERIT currently operates the Merit Computer Network, Michigan's statewide higher education network.) In addition to the NSF support, the state of Michigan will contribute $5 million to the effort, International Business Machines Corp. will contribute hardware and software worth more than $10 million, and MCI Communications Corp. will provide communications lines and support services. The agreement provides for communication on the backbone at 1.544 mb/s ("T1"), a Network Operations Center staffed around the clock, and comprehensive information services, including an Information Center and a Technical Support Staff. NSF has agreements with other Federal agencies that operate networks to support scientific research. The upgraded NSF backbone is expected to play a major role in the emerging Interagency Research Internet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112409542401> Received: from note.nsf.gov by SRI-NIC.ARPA with TCP; Tue 24 Nov 87 12:26:25-PST Date: Tue, 24 Nov 87 14:54:24 EST From: steve@note.nsf.gov Subject: Award To: nsfnet@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA cc: steve@note.nsf.gov Message-ID: <8711241454.aa05628@note.nsf.gov> The National Science Foundation today announced a five-year, $14 million grant to MERIT, Inc., for the upgrading, operation and management of the NSFNET transcontinental backbone network. (MERIT currently operates the Merit Computer Network, Michigan's statewide higher education network.) In addition to the NSF support, the state of Michigan will contribute $5 million to the effort, International Business Machines Corp. will contribute hardware and software worth more than $10 million, and MCI Communications Corp. will provide communications lines and support services. The agreement provides for communication on the backbone at 1.544 mb/s ("T1"), a Network Operations Center staffed around the clock, and comprehensive information services, including an Information Center and a Technical Support Staff. NSF has agreements with other Federal agencies that operate networks to support scientific research. The upgraded NSF backbone is expected to play a major role in the emerging Interagency Research Internet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1211@phoenix.Princeton.EDU] <1987112410280800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: asjoshi@phoenix.Princeton.EDU (Amit S. Joshi) Newsgroups: comp.protocols.tcp-ip Subject: Turbo C TCP/IP Message-ID: <1211@phoenix.Princeton.EDU> Date: Tue, 24-Nov-87 15:28:08 EST Article-I.D.: phoenix.1211 Posted: Tue Nov 24 15:28:08 1987 Date-Received: Sat, 28-Nov-87 06:47:45 EST Reply-To: asjoshi@phoenix.Princeton.EDU (Amit S. Joshi) Distribution: na Organization: Princeton University, NJ Lines: 16 Hello, This is to apologize to the people whom I promised to send the Turbo C version. I was about to send it when I realized that my 3 Com board seems to have undergone a crash. It no longer talks to some machines. It seems to work fine with some however. I don't know if the problem is with the ported version but to preclude any grief to anybody I am NOT mailing the code unless somebody is willing to risk his/her board. Once again I'm sorry. -- Amit Joshi | BITNET : Q3696@PUCC.BITNET | USENET : ...{seismo, rutgers}!princeton!phoenix!asjoshi "There's a pleasure in being mad ...which none but madmen know!" St.Dryden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2758@drivax.UUCP] <1987112411051100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: socha@drivax.UUCP (Henri J. Socha (7-x6628)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Apologies and Arcnet Message-ID: <2758@drivax.UUCP> Date: Tue, 24-Nov-87 16:05:11 EST Article-I.D.: drivax.2758 Posted: Tue Nov 24 16:05:11 1987 Date-Received: Sun, 29-Nov-87 16:20:40 EST References: <8711222235.AA13789@ARES.MIT.EDU> <2756@drivax.UUCP> Reply-To: socha@drivax.UUCP (Henri J. Socha (7-x6628)) Organization: Digital Research, Monterey, CA Lines: 22 OOPS, I made a typo in the previous message (and an important one) please 'n' if you 'n'd the ARCnet discussion. In article <2756@drivax.UUCP> socha@drivax.UUCP (Henri J. Socha (7-x6628)) writes: > I know of users in the > * Business industry (Datapoint customers like the local city government with > all departments on an ARCnet of many nodes.) **** That was: The local city govt. uses a Datapoint ARCnet system and they are very happy with it (including the programmers) last time I talked with them. > * The system is defined as 2.5MBaud but because it uses an isocronous(sp?) > transmission scheme (resync on each character in a message) to send > 8 data bits you must send 11 baud (3 sync bits preceed each data bit) **** OOPS that's 3 re-sync bits per BYTE! > therefore the effective data rate is about 1.8MegaBit per second. (2.5 * 8/11) -- UUCP:...!amdahl!drivax!socha WAT Iron'75 "Everything should be made as simple as possible but not simpler." A. Einstein ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711251050.AA13731@umix.cc.umich.edu] <1987112412441600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcp-ip-RELAY@SRI-NIC.ARPA ("tcp-ip-RELAY%SRI-NIC.ARPA") Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8711251050.AA13731@umix.cc.umich.edu> Date: Tue, 24-Nov-87 17:44:16 EST Article-I.D.: umix.8711251050.AA13731 Posted: Tue Nov 24 17:44:16 1987 Date-Received: Sun, 29-Nov-87 08:43:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 , trewitt@miasma.stanford.edu, LYNCH@a.isi.edu, tcp-ip@sri-nic.arpa, netman@amadeus.stanford.edu, gwmon@sh.cs.net Date: Tue, 24 Nov 87 14:44:16 PST To: userID=DUM1@SFU.MAILNET, trewitt@MIASMA.STANFORD.EDU, LYNCH@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA, netman@AMADEUS.STANF Subject: Re: Network Management My concern is rather the opposite of the others that I have heard. I am concerned that participants in the closed Netman meeting have made a decision which, although plausible, will have no effect other than excluding them from the IP community. It is clear that HEMS and SGMP will be implemented by the major gateway vendors, and on Unix. (I wish we could pick one or the other, but I have a feeling we will end up with both HEMS and SGMP everywhere.) This will happen by January. The hope had been that we could avoid completely separate IP and ISO implementations by the work of the Netman group. If this has really failed, the result will be separate IP and ISO work, not CMIS over IP. Experience is very clear that a few months delay in this business is fatal. It is probably not too late to make extensions to HEMS if necessary to allow the Netman group to meet its goals. In my view it is too late to come up with another protocol. I am hoping that all of the participants in Netman can somehow be persuaded to try again. I think we need to find a way to make things proceed according to the original gameplan. In this context it is important to avoid seeing the issue as somehow "the vendors" against the IP community. Not all vendors were present at the meeting. Indeed the purveyors of the major gateway implementations were noticable by their absence. So I'd like to see us avoid using "the vendors" as if there were one such entity, and they all adopted the same position. I am in fact avoiding assigning any term to those who participated in the meeting in question, since I am unable to find any term that is not emotionally loaded. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711242244.AA02845@aramis.rutgers.edu] <1987112412441700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Network Management Message-ID: <8711242244.AA02845@aramis.rutgers.edu> Date: Tue, 24-Nov-87 17:44:17 EST Article-I.D.: aramis.8711242244.AA02845 Posted: Tue Nov 24 17:44:17 1987 Date-Received: Sat, 28-Nov-87 08:16:30 EST References: <8711242036.AA01909@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 My concern is rather the opposite of the others that I have heard. I am concerned that participants in the closed Netman meeting have made a decision which, although plausible, will have no effect other than excluding them from the IP community. It is clear that HEMS and SGMP will be implemented by the major gateway vendors, and on Unix. (I wish we could pick one or the other, but I have a feeling we will end up with both HEMS and SGMP everywhere.) This will happen by January. The hope had been that we could avoid completely separate IP and ISO implementations by the work of the Netman group. If this has really failed, the result will be separate IP and ISO work, not CMIS over IP. Experience is very clear that a few months delay in this business is fatal. It is probably not too late to make extensions to HEMS if necessary to allow the Netman group to meet its goals. In my view it is too late to come up with another protocol. I am hoping that all of the participants in Netman can somehow be persuaded to try again. I think we need to find a way to make things proceed according to the original gameplan. In this context it is important to avoid seeing the issue as somehow "the vendors" against the IP community. Not all vendors were present at the meeting. Indeed the purveyors of the major gateway implementations were noticable by their absence. So I'd like to see us avoid using "the vendors" as if there were one such entity, and they all adopted the same position. I am in fact avoiding assigning any term to those who participated in the meeting in question, since I am unable to find any term that is not emotionally loaded. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1039@hp-sdd.HP.COM] <1987112413205700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: andrea@hp-sdd.HP.COM (Andrea K. Frankel) Newsgroups: comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: Standard for Printers Message-ID: <1039@hp-sdd.HP.COM> Date: Tue, 24-Nov-87 18:20:57 EST Article-I.D.: hp-sdd.1039 Posted: Tue Nov 24 18:20:57 1987 Date-Received: Sat, 28-Nov-87 06:00:38 EST References: <135@tsdiag.UUCP> Reply-To: andrea@hp-sdd.UUCP (Andrea K. Frankel) Organization: Hewlett-Packard, San Diego Division Lines: 35 In article <135@tsdiag.UUCP> tom@tsdiag.UUCP writes: > >THIS IS A FORWARDED MESSAGE Follows is the *REAL* header: >From: n2dsy@hou2d.UUCP (G.BEATTIE) > >I have been looking around for something similar to the >ANSI X3.64 Terminal Protocol Specification for printers >or printing terminals. I guess that in some "ideal" >world we would have something analogous to the Virtual >Terminal Protocol for printers, but I am willing and >seeking suggestions regarding printer standards for >simple and medium-complexity printers. ECMA has a task group working on printer formats; their current proposal is called a "Standard Page Description Language" which can be translated to actual PDL's such as Postscript or printer languages such as PCL. Presumably a "standard PDL" could be implemented directly in a printer in the future. The ISO committee TC97/SC18 (and the corresponding ANSC X3V1) are also working in this area. You can contact ANSI in New York to get a contact for X3V1 committee work; that should give you an in to the other groups as well. Andrea Frankel, Hewlett-Packard (San Diego Division) (619) 592-4664 "...like a song that's born to soar the sky" ______________________________________________________________________________ UUCP : ...hplabs!hp-sdd!andrea from {ihnp4|cbosgd|allegra|decvax|gatech|sun|tektronix} or ...hp-sdd!andrea from {hp-pcd|hpfcla|hpda|noscvax|gould9|sdcsvax} Internet : andrea%hp-sdd@ {nosc.mil | sdcsvax.ucsd.edu | hplabs.HP.com} CSNET : andrea%hp-sdd@hplabs.csnet USnail : 16399 W. Bernardo Drive, San Diego CA 92127-1899 USA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112416390000> Received: from umix.cc.umich.edu by SRI-NIC.ARPA with TCP; Wed 25 Nov 87 16:25:24-PST Received: by umix.cc.umich.edu (5.54/umix-2.0) id AA25810; Wed, 25 Nov 87 14:33:19 EST Message-Id: <8711251933.AA25810@umix.cc.umich.edu> Received: from UBCMTSG.BITNET by um.cc.umich.edu via MTS-Net; Wed, 25 Nov 87 14:19:52 EST Received: from SFU by UBCMTSG via BITNET with RM id <213710@UBCMTSG.BITNET>; Wed, 25 Nov 87 11:19:43 PST Date: Wed, 25 Nov 87 00:39:00 PST From: "tcp-ip-RELAY%SRI-NIC.ARPA" <@um.cc.umich.edu,@SFU:@UM.CC.UMICH.EDU:tcp-ip-RELAY@SRI-NIC.ARPA> To: Tcp-ip-dist:userID=DUM1%SFU.BITNET@umix.cc.umich.edu, My_Hangout%SFU.BITNET@umix.cc.umich.edu, Userid=Q73X%UBC.Mailnet@umix.cc.umich.edu, userID=TCP%SFU.BITNET@umix.cc.umich.edu, tcp-ip%UBCMTSG.B@umix.cc.umich.edu , tcp-ip@sri-nic.arpa Date: Wed, 25 Nov 87 00:39:00 PST To: userID=DUM1@SFU.MAILNET, tcp-ip@SRI-NIC.ARPA Subject: TCP/IP software Greetings, I need to get ahold of some information, and this seems like the best place to look for it. I'm looking for: (1) TCP/IP software for PC's: I know of MICOM/Interlan, Excelan, FTP Software and WIN/PC, and have been in contact with each of them. I've heard tell of flavors from CMU, MIT (I believe FTP Software's is based on MIT's), Stanford, UMD, and even IBM. Are there any others to add to this list? Any good/bad points to watch for on any of them? What addresses/ contacts should I use to get ahold of people at the universities about their software? Do any of the above have the capability to gateway IP packets from Tolkien ring to Easternet (external of something like Netware)? For that matter, do any of the above have Token ring drivers? (2) TCP/IP software for PS/2's: Does it exist or does anyone make an Ethernet card for the PS/2 compatible with PC cards on the driver level? Anyone have any word yet on networking under OS/2? (3) Does anyone know what (if any) PC Ethernet cards from different vendor are compatible with each other (eg, maybe NI5010 vs 3C501)? Please respond personally, and I'll summarize to the list. To any and all, thanks in advance for any information that I'm sure will save me hours of time giving phone... L. Stuart Vance Network Systems Specialist UT System Office of Telecommunication Services THEnet: UTCHPC::S.VANCE BITNET: S.VANCE@UTCHPC Internet: S.VANCE@CHPC.BRC.UTEXAS.EDU Ma Bell: (512) 471-2416 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12353308680.30.LYNCH@A.ISI.EDU] <1987112417111800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Network Management Message-ID: <12353308680.30.LYNCH@A.ISI.EDU> Date: Tue, 24-Nov-87 22:11:18 EST Article-I.D.: A.12353308680.30.LYNCH Posted: Tue Nov 24 22:11:18 1987 Date-Received: Sat, 28-Nov-87 15:43:36 EST References: <8711242244.AA02845@aramis.rutgers.edu> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Charles, Thank you for clearly stating your views. I agree that any path is going to take a lot of work. It would be best if we all could get on with the "work" to be done. The characterization of the vendors who are favoring the CMIS approach is best described as "end system vendors" as opposed to "gateway vendors". They see their customers as drowning in network "administration" details in addition to netowrk "management" details. A few years back you (and I) were running timesharing systems and we did that with a ton of software and human procedures that were tightly integrated (evefn if by dint of hard work and numerous kludges that remained invisible to our customers). The joy of networking has stripped managers of that tight integration of administrative tools. Dealing with routing protocol misbehaviour is only the tip of the iceberg (even if that tip will still sink the largest ship someday). So, end users need to have their entire "computing facilities" managed. I think that is what this group of vendors is wrestling with. I hope all parties can find a way to combine efforts for the benefit of all users. After all, satisfied users are the lifeblood of us all. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4537@pyr.gatech.EDU] <1987112418010800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: robert@pyr.gatech.EDU (Robert Viduya) Newsgroups: comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: Standard for Printers Message-ID: <4537@pyr.gatech.EDU> Date: Tue, 24-Nov-87 23:01:08 EST Article-I.D.: pyr.4537 Posted: Tue Nov 24 23:01:08 1987 Date-Received: Sat, 28-Nov-87 18:30:31 EST References: <135@tsdiag.UUCP> Reply-To: robert@pyr.UUCP (Robert Viduya) Organization: Office of Computing Services, Georgia Tech Lines: 20 > From: n2dsy@hou2d.UUCP (G.BEATTIE) > > I have been looking around for something similar to the > ANSI X3.64 Terminal Protocol Specification for printers > or printing terminals. The ANSI X3.64 (or it's international equivalent ISO 6429) standard is general enough to be applied to printers. Neither standard ties itself to just CRTs. Using both ANSI X3.4 (ISO 646) and ANSI X3.64 (ISO 6429) should give you enough functions for ordinary printing terminals. You'll have to trim them a bit, obviously (insert/delete-line/char would be a bit difficult to implement), but the standards don't require you to implement everything. robert -- Robert Viduya robert@pyr.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-4660 Atlanta, Georgia 30332 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711251547.AA20015@umix.cc.umich.edu] <1987112420090200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcp-ip-RELAY@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8711251547.AA20015@umix.cc.umich.edu> Date: Wed, 25-Nov-87 01:09:02 EST Article-I.D.: umix.8711251547.AA20015 Posted: Wed Nov 25 01:09:02 1987 Date-Received: Sun, 29-Nov-87 05:07:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 , tcp-ip@SRI-NIC.ARPA Date: Tue, 24 Nov 87 22:09:02 PST To: userID=DUM1@SFU.MAILNET, tcp-ip@SRI-NIC.ARPA Subject: TN3270 speeds Greg pointed out to me that what I saw was actually running on an RT, not a Sun, and that a Sun is faster, but still not as fast as a PC. Yakov confirmed this re: the IBM PC TN3270 (DOS coders can write directly to the display, and curses costs a lot). jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [291107.871125.JBVB@AI.AI.MIT.EDU] <1987112420090300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: TN3270 speeds Message-ID: <291107.871125.JBVB@AI.AI.MIT.EDU> Date: Wed, 25-Nov-87 01:09:03 EST Article-I.D.: AI.291107.871125.JBVB Posted: Wed Nov 25 01:09:03 1987 Date-Received: Sat, 28-Nov-87 18:12:45 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Greg pointed out to me that what I saw was actually running on an RT, not a Sun, and that a Sun is faster, but still not as fast as a PC. Yakov confirmed this re: the IBM PC TN3270 (DOS coders can write directly to the display, and curses costs a lot). jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711251026.AA20451@ucbvax.Berkeley.EDU] <1987112422390000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: xxss520@CHPC.BRC.UTEXAS.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP software Message-ID: <8711251026.AA20451@ucbvax.Berkeley.EDU> Date: Wed, 25-Nov-87 03:39:00 EST Article-I.D.: ucbvax.8711251026.AA20451 Posted: Wed Nov 25 03:39:00 1987 Date-Received: Sat, 28-Nov-87 14:25:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "L. Stuart Vance" Organization: The ARPA Internet Lines: 33 Greetings, I need to get ahold of some information, and this seems like the best place to look for it. I'm looking for: (1) TCP/IP software for PC's: I know of MICOM/Interlan, Excelan, FTP Software and WIN/PC, and have been in contact with each of them. I've heard tell of flavors from CMU, MIT (I believe FTP Software's is based on MIT's), Stanford, UMD, and even IBM. Are there any others to add to this list? Any good/bad points to watch for on any of them? What addresses/ contacts should I use to get ahold of people at the universities about their software? Do any of the above have the capability to gateway IP packets from Tolkien ring to Easternet (external of something like Netware)? For that matter, do any of the above have Token ring drivers? (2) TCP/IP software for PS/2's: Does it exist or does anyone make an Ethernet card for the PS/2 compatible with PC cards on the driver level? Anyone have any word yet on networking under OS/2? (3) Does anyone know what (if any) PC Ethernet cards from different vendor are compatible with each other (eg, maybe NI5010 vs 3C501)? Please respond personally, and I'll summarize to the list. To any and all, thanks in advance for any information that I'm sure will save me hours of time giving phone... L. Stuart Vance Network Systems Specialist UT System Office of Telecommunication Services THEnet: UTCHPC::S.VANCE BITNET: S.VANCE@UTCHPC Internet: S.VANCE@CHPC.BRC.UTEXAS.EDU Ma Bell: (512) 471-2416 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112422390001> Received: from chpc.brc.utexas.edu by SRI-NIC.ARPA with TCP; Wed 25 Nov 87 01:39:33-PST Date: 25 Nov 87 03:39:00 CDT From: "L. Stuart Vance" Subject: TCP/IP software To: "tcp-ip" Reply-To: "L. Stuart Vance" Greetings, I need to get ahold of some information, and this seems like the best place to look for it. I'm looking for: (1) TCP/IP software for PC's: I know of MICOM/Interlan, Excelan, FTP Software and WIN/PC, and have been in contact with each of them. I've heard tell of flavors from CMU, MIT (I believe FTP Software's is based on MIT's), Stanford, UMD, and even IBM. Are there any others to add to this list? Any good/bad points to watch for on any of them? What addresses/ contacts should I use to get ahold of people at the universities about their software? Do any of the above have the capability to gateway IP packets from Tolkien ring to Easternet (external of something like Netware)? For that matter, do any of the above have Token ring drivers? (2) TCP/IP software for PS/2's: Does it exist or does anyone make an Ethernet card for the PS/2 compatible with PC cards on the driver level? Anyone have any word yet on networking under OS/2? (3) Does anyone know what (if any) PC Ethernet cards from different vendor are compatible with each other (eg, maybe NI5010 vs 3C501)? Please respond personally, and I'll summarize to the list. To any and all, thanks in advance for any information that I'm sure will save me hours of time giving phone... L. Stuart Vance Network Systems Specialist UT System Office of Telecommunication Services THEnet: UTCHPC::S.VANCE BITNET: S.VANCE@UTCHPC Internet: S.VANCE@CHPC.BRC.UTEXAS.EDU Ma Bell: (512) 471-2416 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3564@xanth.UUCP] <1987112501431300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kent@xanth.UUCP (Kent Paul Dolan) Newsgroups: comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: Standard for Printers Message-ID: <3564@xanth.UUCP> Date: Wed, 25-Nov-87 06:43:13 EST Article-I.D.: xanth.3564 Posted: Wed Nov 25 06:43:13 1987 Date-Received: Sun, 29-Nov-87 11:32:12 EST References: <135@tsdiag.UUCP> Reply-To: kent@xanth.UUCP (Kent Paul Dolan) Organization: Old Dominion University, Norfolk Va. Lines: 33 Keywords: very useful, allows printr independent appolications programs Summary: Check out the one used by the Amiga Gorden, I don't know how much of a standard you want, but if you are looking for something that works well in practice, look into the method used by Commmodore in their Amiga line of computers. They have chosen or designed a device neutral language for printing commands that all adhering programs use to "talk printer". Then, for each printer type, the vendor designs a printer driver that reads this device neutral format printer code and converts it to the commands for that specific printer. The device neutral language seems quite powerful, and it covers both character mode and (for raster printers) graphics mode commands. The details are in: Amiga Rom Kernal Reference Manual, Libraries and Devices, Commodore Business Machines, Inc., Addison Wesley Publishing Company, Inc., ISBN 0-201-11078-4, US$34.95. See especially the table of commands beginning on page e-38 and the one on e-41. The "standard" seems to be a mix of ANSII x3.64 and DEC usages, plus some stuff home brewed by Commodore. As I say, it works VERY well, and I wish more micro manufacturers would adopt it, because it uncouples applications programs from the printer drivers, making all programs usable with (almost) all printers. I know it has allowed a mix of Daisy Wheel, 9 pin raster, 24 pin raster, laser, and ink-jet printers for the Amiga with no change to applications programs. Kent, the man from xanth. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711251203.AA15151@umix.cc.umich.edu] <1987112502034600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcp-ip-RELAY@SRI-NIC.ARPA ("tcp-ip-RELAY%SRI-NIC.ARPA") Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8711251203.AA15151@umix.cc.umich.edu> Date: Wed, 25-Nov-87 07:03:46 EST Article-I.D.: umix.8711251203.AA15151 Posted: Wed Nov 25 07:03:46 1987 Date-Received: Sat, 28-Nov-87 18:38:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 , tcp-ip@sri-nic.arpa Date: Wed, 25 Nov 87 02:55:15 PST To: userID=DUM1@SFU.MAILNET, tcp-ip@SRI-NIC.ARPA Subject: Turbo C TCP/IP Hello, This is to apologize to the people whom I promised to send the Turbo C version. I was about to send it when I realized that my 3 Com board seems to have undergone a crash. It no longer talks to some machines. It seems to work fine with some however. I don't know if the problem is with the ported version but to preclude any grief to anybody I am NOT mailing the code unless somebody is willing to risk his/her board. Once again I'm sorry. -- Amit Joshi | BITNET : Q3696@PUCC.BITNET | USENET : ...{seismo, rutgers}!princeton!phoenix!asjoshi "There's a pleasure in being mad ...which none but madmen know!" St.Dryden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [514@interlan.UUCP] <1987112503090500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: backman@interlan.UUCP (Larry Backman) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP maximum segment size determination Message-ID: <514@interlan.UUCP> Date: Wed, 25-Nov-87 08:09:05 EST Article-I.D.: interlan.514 Posted: Wed Nov 25 08:09:05 1987 Date-Received: Sun, 29-Nov-87 01:06:11 EST References: <283116.871110.JBVB@AI.AI.MIT.EDU> <3370@hoptoad.uucp> Reply-To: backman@interlan.UUCP (Larry Backman) Organization: MICOM-Interlan, Boxborough, MA (1-800-LAN-TALK) Lines: 24 >It's hard to believe that in this age of utterly cheap dense RAM, >otherwise sane people are proposing inserting artificial delays between >Ethernet packets because a lowball vendor wouldn't put, say, TWO >buffers on their card! > >[I admit I'm prejudiced, since I worked on Suns, which currently seem >to have the highest Ethernet thruput, but they were built out of >standard Ethernet chips and DRAMs available to everyone. You too can >handle infinite back to back packets, if you just design with that in >mind as Sun did.] > But whhhat about all those old, old Suns, the ones without back to back capacity. What about the tens of thousands of NI5010's or 3C501's. People bought them, have them, are working with them daily even though no double buffering is available. Its not just a querstion of being a lowball vendor, reality is the fact that old outmode hardware is out there and used! Software must be cognizent that it will not always run in ideal situations. In fact, I define good softwarre as that which can perform adaquately under less than ideal environmental situations. Larry Backman Micom - Interlan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1322@lll-lcc.aRpA] <1987112507241200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gp@lll-lcc.aRpA (George Pavel) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Lawrence Livermore IGP project? Message-ID: <1322@lll-lcc.aRpA> Date: Wed, 25-Nov-87 12:24:12 EST Article-I.D.: lll-lcc.1322 Posted: Wed Nov 25 12:24:12 1987 Date-Received: Sun, 29-Nov-87 02:09:23 EST References: <408@cayman.UUCP> Organization: Lawrence Livermore Labs, Livermore Ca Lines: 17 in article <408@cayman.UUCP>, brad@cayman.UUCP (Brad Parker) says: > Does anyone have any information on the Lawrence Livermore Lab > Intelligent Gateway Processor (IGP) project? > > Brad Parker > Cayman Systems This software is now being marketed commercially by Control Data Corp (CDC). Non-commercial inquiries should probably be addressed to the Technology Information Systems (TIS) Program at LLNL. I don't know the specific person to contact, but a message to postmaster@lll-tis.arpa or root@lll-tis.arpa will probably get you some information. George Pavel (I am not involved with the TIS Project) Lawrence Livermore National Laboratory P.O. Box 808 L-68 Internet: gp@lll-lcc.arpa Livermore, CA 94550 gp@lll-lcc.llnl.gov after 12/1/87 (415)422-4262 UUCP: ihnp4!lll-lcc!gp ----MESSAGE-END---- ----MESSAGE-BEGIN---- [573@ucdavis.ucdavis.edu] <1987112510531200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ccruss@deneb.ucdavis.edu.UUCP Newsgroups: comp.protocols.tcp-ip Subject: SLIP software available Message-ID: <573@ucdavis.ucdavis.edu> Date: Wed, 25-Nov-87 15:53:12 EST Article-I.D.: ucdavis.573 Posted: Wed Nov 25 15:53:12 1987 Date-Received: Sun, 29-Nov-87 05:01:30 EST Sender: uucp@ucdavis.ucdavis.edu Reply-To: rdhobby@ucdavis.edu (Russ Hobby) Organization: University of California, Davis Lines: 72 Yes, we have a SLIP server implementation now ready. The reason I have not posted it sooner is because we have been working with the Sun NFS people on the method of establishing a dialin slip connection and have been refitting some of their suggestions into our version. The software allows PCs to make dialup SLIP connections to the campus IP network. We are also have worked out a method of abbreviated serial line IP (ASLIP) packeting that makes dialup IP networks more efficient. The ASLIP software is new to this version and Sun has not seen it yet. Here is how the system works. The user logs on to the host that is acting as the gateway, a 4.3 bsd system. He then types in the command "slip" and he becomes a host on the network. He can then use all the programs that come with the CMU/MIT PC/IP or Phil Karn's system. To make connecting to the network a little easier, we have written a program that will do the complete login automatically. The program has a user configurable script file that specifies a sequence of strings to send out the serial line and responses to wait for coming back. It has its own simple language with branching depending on if the correct response came back. The net result is that after the script has been set up, the user types in one command on the PC to connect to the network. Unlike some PC/IPs, our system assumes that each PC (or actually each user) has its own, permanent IP address. Security is provided by logon security on the gateway host. The IP address of the PC is associated with the usercode on the gateway host. The network connection for that PC's IP address can only be started from a user logged in with the correct usercode. The system also makes sure that the IP address is not already connected before making a new connection. The way we have set up IP address for the PCs is to have a separate subnet that contains all the PCs. This way the gateway host needs only to advertise that it is a route to that subnet and all the PCs are covered. In essence the gateway host is the network for all SLIP connections on that subnet. The abbreviated packets work on the assumption that the connecting computer is an endnode and will not be doing any routing. In this case many of the fields in the IP packet are unnecessary. ASLIP uses the minimum header size based on this assumption. With ASLIP the header size is either 8 or 4 bytes, much smaller than the standard 40 bytes. The host that is acting as the ASLIP gateway rebuilds the outgoing packets to legal IP packets before sending them out the network and abbreviates the incoming packets from the network. The same server software handles both SLIP and ASLIP. It only goes into ASLIP mode once it has received an ASLIP packet from the PC, thus if only SLIP packets are sent, it will stay in regular SLIP mode. I will post more details on the ASLIP protocol later. Also there have been some terminal server vendors interested in this project. It should not be much work to turn a terminal server into an ASLIP or SLIP server and that would make it cheaper than using a VAX as the gateway. Plus there would not be as much maintenance and downtime with a simple server box. The software is available via anonymous FTP from ucdavis.edu and is in the directory dist/slip/. This includes all software to run the SLIP/ASLIP server on a 4.3 bsd system, and the modifications to CMU PC/IP software to implement ASLIP and the auto-login program, plus fix a couple bugs. See the README file in this directory for a discription of what the various tar files give you. The next thing we want to add to the system is BOOTP so that the PC software does not have to be configured for IP address, but rather get it from the server. Russell Hobby Data Communications Manager U. C. Davis Computing Services BITNET: RDHOBBY@UCDAVIS Davis Ca 95616 UUCP: ...!ucbvax!ucdavis!rdhobby (916) 752-0236 INTERNET: rdhobby@ucdavis.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711252112.AA02345@nprdc.arpa] <1987112511100000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stanonik@NPRDC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: pop Message-ID: <8711252112.AA02345@nprdc.arpa> Date: Wed, 25-Nov-87 16:10:00 EST Article-I.D.: nprdc.8711252112.AA02345 Posted: Wed Nov 25 16:10:00 1987 Date-Received: Sun, 29-Nov-87 06:29:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: stanonik@nprdc.arpa Distribution: world Organization: The ARPA Internet Lines: 7 Are there any pop (post office protocol) implementations for VAXs and SUNs? Thanks, Ron Stanonik stanonik@nprdc.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [272@cunixc.columbia.edu] <1987112512172400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: alan@cunixc.columbia.edu (Alan Crosswell) Newsgroups: comp.protocols.tcp-ip Subject: Wanted: BSD UNIX HMP (RFC869) implementation Message-ID: <272@cunixc.columbia.edu> Date: Wed, 25-Nov-87 17:17:24 EST Article-I.D.: cunixc.272 Posted: Wed Nov 25 17:17:24 1987 Date-Received: Sun, 29-Nov-87 11:46:49 EST Reply-To: alan@cunixc.columbia.edu (Alan Crosswell) Organization: Columbia University Lines: 10 Does anybody have a Berkeley UNIX implementation of a RFC869 Host Monitoring Protocol (HMP) client that I could have? I believe that the "HMP" that you get with the IBM "PCIP" (5798-FAL) is the same as RFC869 HMP. Anybody who knows for sure please correct me if I'm wrong. Thanks. Alan Crosswell Columbia University alan@columbia.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711252309.AA05871@gateway.mitre.org] <1987112513093700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@gateway.mitre.ORG (Phill Gross) Newsgroups: comp.protocols.tcp-ip Subject: re: Network Management Message-ID: <8711252309.AA05871@gateway.mitre.org> Date: Wed, 25-Nov-87 18:09:37 EST Article-I.D.: gateway.8711252309.AA05871 Posted: Wed Nov 25 18:09:37 1987 Date-Received: Sun, 29-Nov-87 14:46:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 > I don't understand why it is useful to have something which is sort > of vaguely like what we think CMIP is going to look like when it is > done. Either you are compatible with an ISO standard or you're not. > Being sort of close doesn't seem to buy all that much. Ross, I have been informed in private that these days it is a wise business decision to at least give the appearance of conforming to OSI standards. Utilizing TCP and IP is fine because it is already here, but for something that needs to implemented from scratch, I've been told that many vendors feel contrained to an OSI solution. The argument about avoiding development costs by not implementing twice may not be as important as soothing nervous customers about multi-vendor OSI interoperability. If vendors were only concerned with not implementing twice, they might have taken a harder look at the Simple Gateway Monitoring Protocol (SGMP) effort. SGMP is yet a third network management consortium effort that started about the same time as (and has drawn from) HEMS and Netman. At the Boulder IETF meeting, a very impressive real-time demo was given of a PC based SGMP package (with whizbang color graphics) monitoring a real state-wide regional network. My understanding is that C source code is available for tested, interoperable implementations under BSD Unix, MS-DOS and two other platforms. SGMP has been documented in a recent RFC and I think there are plans for it be discussed at the upcoming Interoperability conference. For vendors whose goal is to minimize development costs, perhaps SGMP deserves a closer look. Phill Gross ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112516420000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Wed 25 Nov 87 18:45:53-PST Date: 25 Nov 87 21:42:00 EST From: "GBURG::ENGER" Subject: Unbuffered Ethernet boards for PCs To: "tcp-ip" cc: enger Gentlemen wrote recently of their concern that unbuffered Ethernet adapter cards for PCs were dropping packets. Atleast for TCP based traffic, some relief may be coming. Messrs. Jacobsen and Karels have been testing an improved TCP that may help to some extent by keeping the window small (due to the recurring losses). Should this not prove sufficient, I vote for sending the unbuffered cards to the Smithsonian. :-) Hope everyone had a nice Thanksgiving Day, Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711261901.AA25392@ucbvax.Berkeley.EDU] <1987112608321900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: zwang@CS.UCL.AC.UK ("Zheng.Wang") Newsgroups: comp.protocols.tcp-ip Subject: Network faults Message-ID: <8711261901.AA25392@ucbvax.Berkeley.EDU> Date: Thu, 26-Nov-87 13:32:19 EST Article-I.D.: ucbvax.8711261901.AA25392 Posted: Thu Nov 26 13:32:19 1987 Date-Received: Sun, 29-Nov-87 16:45:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 I am doing some research on network faults now. Help wanted from network experts: 1) According to your experience, which components are more likely to be the trouble-makers in the networks? 2) Where can I find reports or case studies about network failures in the past years? Thanks in advance Zheng zwang@cs.ucl.ac.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- [292@otc.oz] <1987112612444000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: anido@otc.oz (Gary Anido) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: FDDI interfaces and bridges Message-ID: <292@otc.oz> Date: Thu, 26-Nov-87 17:44:40 EST Article-I.D.: otc.292 Posted: Thu Nov 26 17:44:40 1987 Date-Received: Sun, 29-Nov-87 20:54:40 EST Organization: OTC Development Unit, Australia Lines: 23 Keywords: bridges, gateways, LAN, FDDI, Ethernet We are interested in implementing an FDDI ring. The ring is intended primarily as a research vehicle to which we would be looking to connect Ethernet and Token-ring LANs. While I am aware that there is at least one FDDI chipset available (from AMD according to the Sept 17 issue of Electronic Design) I am unaware of any board-level implementations and software. I would therefore be grateful if those with knowledge of FDDI-Ethernet, FDDI-Token Ring etc, implementations and software could share that information with me. This naturally includes anyone who has actually designed an FDDI interface based on the AMD (or other?) chipset. Replies should be sent to me, and I will summarise and release to the net. Gary Anido Systems Development |||| OTC || UUCP: {uunet,mcvax}!otc.oz!anido ACSnet:anido@otc.oz Postal Address: Systems Development Phone :(02) 2874849 OTC Intl :+612 2874849 GPO Box 7000 Fax :(02) 2874990 Sydney NSW AUSTRALIA 2001 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112618321900> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Thu 26 Nov 87 10:36:04-PST Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id ab02878; 26 Nov 87 18:32 GMT Date: Thu, 26 Nov 87 18:32:19 GMT From: "Zheng.Wang" To: tcp-ip@sri-nic.arpa cc: zwang@Cs.Ucl.AC.UK Subject: Network faults I am doing some research on network faults now. Help wanted from network experts: 1) According to your experience, which components are more likely to be the trouble-makers in the networks? 2) Where can I find reports or case studies about network failures in the past years? Thanks in advance Zheng zwang@cs.ucl.ac.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711271557.AA14469@trantor.UMD.EDU] <1987112705573600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") Newsgroups: comp.protocols.tcp-ip Subject: Re: Network Management Message-ID: <8711271557.AA14469@trantor.UMD.EDU> Date: Fri, 27-Nov-87 10:57:36 EST Article-I.D.: trantor.8711271557.AA14469 Posted: Fri Nov 27 10:57:36 1987 Date-Received: Sun, 29-Nov-87 22:04:05 EST References: <8711252309.AA05871@gateway.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Date: Wed, 25 Nov 87 18:09:37 EST From: gross@gateway.mitre.org (Phill Gross) Message-Id: <8711252309.AA05871@gateway.mitre.org> Subject: re: Network Management > I don't understand why it is useful to have something which is sort > of vaguely like what we think CMIP is going to look like when it is > done. Either you are compatible with an ISO standard or you're not. > Being sort of close doesn't seem to buy all that much. Ross, I have been informed in private that these days it is a wise business decision to at least give the appearance of conforming to OSI standards. Utilizing TCP and IP is fine because it is already here, but for something that needs to implemented from scratch, I've been told that many vendors feel contrained to an OSI solution. The argument about avoiding development costs by not implementing twice may not be as important as soothing nervous customers about multi-vendor OSI interoperability. If vendors were only concerned with not implementing twice, they might have taken a harder look at the Simple Gateway Monitoring Protocol (SGMP) effort. As a customer of network products, I'm not interested in the "appearance" of a product in anyway; just what it does. It seems that products developed to "soothe" customers and as useful as those developed to actually solve my problems. I was kinda glad that the vendors I buy products from weren't listed as being part of the group that made this decision. If I can't buy it, I'll have to build it myself. The vendor that builds it for me gets my business. The appearence of ISO compatibility is not something that I'd go out and build. Just wanted to give you another "customer's" perspective. Louis A. Mamakos University of Maryland Computer Science Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711271629.AA15316@manta.nosc.mil] <1987112706290700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@MANTA.NOSC.MIL (Ron Broersma) Newsgroups: comp.protocols.tcp-ip Subject: Re: pop Message-ID: <8711271629.AA15316@manta.nosc.mil> Date: Fri, 27-Nov-87 11:29:07 EST Article-I.D.: manta.8711271629.AA15316 Posted: Fri Nov 27 11:29:07 1987 Date-Received: Sun, 29-Nov-87 22:22:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 > Are there any pop (post office protocol) implementations > for VAXs and SUNs? We have a full implementation of pop2 service here running on both VAXen and SUNs. If there is interest, I'll stick it in a public FTP directory so you can grab it. --Ron ron@nosc.mil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711280003.AA08389@orville.nas.nasa.gov] <1987112714034700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) Newsgroups: comp.protocols.tcp-ip Subject: pop Message-ID: <8711280003.AA08389@orville.nas.nasa.gov> Date: Fri, 27-Nov-87 19:03:47 EST Article-I.D.: orville.8711280003.AA08389 Posted: Fri Nov 27 19:03:47 1987 Date-Received: Mon, 30-Nov-87 00:26:55 EST References: <8711271629.AA15316@manta.nosc.mil> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Hi. I'll express interest in a pop2 implementation. We're busy considering how best to send all mail here to frob@nas.nasa.gov, and that might be a useful way. john ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7706.565074456@gremlin.nrtc.northrop.com] <1987112719284800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@GREMLIN.NRTC.NORTHROP.COM (Marshall Rose) Newsgroups: comp.protocols.tcp-ip Subject: Re: pop Message-ID: <7706.565074456@gremlin.nrtc.northrop.com> Date: Sat, 28-Nov-87 00:28:48 EST Article-I.D.: gremlin.7706.565074456 Posted: Sat Nov 28 00:28:48 1987 Date-Received: Mon, 30-Nov-87 01:23:28 EST References: <8711280003.AA08389@orville.nas.nasa.gov> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 You might also consider looking at the POP implementation (client and server) in MH. It was done at roughly the same time as the POP2 specification, but for reasons not worth going into, never got issued as an official rfc. The Stanford mailsystem for the PC uses this POP to great advantage. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711281726.AA22280@ucbvax.Berkeley.EDU] <1987112806425900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: zwang@CS.UCL.AC.UK ("Zheng.Wang") Newsgroups: comp.protocols.tcp-ip Subject: tcp-ip archives Message-ID: <8711281726.AA22280@ucbvax.Berkeley.EDU> Date: Sat, 28-Nov-87 11:42:59 EST Article-I.D.: ucbvax.8711281726.AA22280 Posted: Sat Nov 28 11:42:59 1987 Date-Received: Mon, 30-Nov-87 03:53:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Help wanted: Where can I find the tcp-ip archives for the recent years? Zheng. zwang@uk.ac.ucl.cs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3018@umn-cs.cs.umn.edu] <1987112807572700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: smiller@umn-cs.cs.umn.edu (Steven M. Miller) Newsgroups: comp.protocols.tcp-ip Subject: Authentication Protocols Message-ID: <3018@umn-cs.cs.umn.edu> Date: Sat, 28-Nov-87 12:57:27 EST Article-I.D.: umn-cs.3018 Posted: Sat Nov 28 12:57:27 1987 Date-Received: Mon, 30-Nov-87 03:43:43 EST Organization: University of Minnesota, Computer Science Lines: 20 Keywords: Visa, Kerberos I heard brief mentions of existing authentication protocols a while back on this list. I tried to contact the authors of the messages that mentioned the Visa and Kerberos protocols but didn't get any response. If anyone can give me pointers to documentation on these protocols it would be greatly appreciated. (p.s If you know of any other protocols please point me to them too) (p.p.s. I already have the Sun paper from Summer '86 Usenix) smiller@umn-cs.cs.umn.edu steve@cs-gw.d.umn.edu -- -Steve Miller, U of MN ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112816425900> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Sat 28 Nov 87 08:46:38-PST Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id aa03019; 28 Nov 87 16:44 GMT Date: Sat, 28 Nov 87 16:42:59 GMT From: "Zheng.Wang" To: postmaster@sri-nic.arpa cc: tcp-ip@sri-nic.arpa Subject: tcp-ip archives Help wanted: Where can I find the tcp-ip archives for the recent years? Zheng. zwang@uk.ac.ucl.cs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1162@homxb.UUCP] <1987112818440600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hrs@homxb.UUCP Newsgroups: comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: Standard for Printers Message-ID: <1162@homxb.UUCP> Date: Sat, 28-Nov-87 23:44:06 EST Article-I.D.: homxb.1162 Posted: Sat Nov 28 23:44:06 1987 Date-Received: Tue, 1-Dec-87 07:14:05 EST References: <135@tsdiag.UUCP> <1039@hp-sdd.HP.COM> Organization: AT&T Bell Laboratories, Holmdel Lines: 55 Summary: Page description languages In article <1039@hp-sdd.HP.COM>, andrea@hp-sdd.HP.COM (Andrea K. Frankel) writes: > In article <135@tsdiag.UUCP> tom@tsdiag.UUCP writes: > > > >THIS IS A FORWARDED MESSAGE Follows is the *REAL* header: > >From: n2dsy@hou2d.UUCP (G.BEATTIE) > > > >I have been looking around for something similar to the > >ANSI X3.64 Terminal Protocol Specification for printers > >or printing terminals. I guess that in some "ideal" > >world we would have something analogous to the Virtual > >Terminal Protocol for printers, but I am willing and > >seeking suggestions regarding printer standards for > >simple and medium-complexity printers. > > ECMA has a task group working on printer formats; their current > proposal is called a "Standard Page Description Language" which > can be translated to actual PDL's such as Postscript or printer > languages such as PCL. Presumably a "standard PDL" could be > implemented directly in a printer in the future. > > The ISO committee TC97/SC18 (and the corresponding ANSC X3V1) > are also working in this area. > > You can contact ANSI in New York to get a contact for X3V1 > committee work; that should give you an in to the other groups > as well. > > Andrea Frankel, Hewlett-Packard (San Diego Division) (619) 592-4664 > "...like a song that's born to soar the sky" > ______________________________________________________________________________ > UUCP : ...hplabs!hp-sdd!andrea from > {ihnp4|cbosgd|allegra|decvax|gatech|sun|tektronix} > or ...hp-sdd!andrea from {hp-pcd|hpfcla|hpda|noscvax|gould9|sdcsvax} > Internet : andrea%hp-sdd@ {nosc.mil | sdcsvax.ucsd.edu | hplabs.HP.com} > CSNET : andrea%hp-sdd@hplabs.csnet > USnail : 16399 W. Bernardo Drive, San Diego CA 92127-1899 USA ANSI X3V1, Text, Office, and Publishing Systems has jurisdiction in the US over printer driver standard, and is the US counterpart of ISO JTC1/SC18. Postscript, (Xerox) Interpress, and DDL are al being proposed as sources for the Standard Page Description Language. As a "de facto standard" Postscript is likely to be influential, although it currently is seen as having some drawbracks in the large size of its files. The standard will have binary (ASN.1) and SGML versions as well as cleartext versions. X3V1 will meet December 7-11 in OakRidge, TN. Interested people are invited to participate. If you want more information, call or send email. Herman Silbiger ...!ihnp4!homxb!hrs 201 949 3193 Chair, X3V1.3 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711291926.AA04530@rt234.usc.edu] <1987112909265600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: estrin@OBERON.USC.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Authentication Protocols Message-ID: <8711291926.AA04530@rt234.usc.edu> Date: Sun, 29-Nov-87 14:26:56 EST Article-I.D.: rt234.8711291926.AA04530 Posted: Sun Nov 29 14:26:56 1987 Date-Received: Wed, 2-Dec-87 19:37:52 EST References: <3018@umn-cs.cs.umn.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Sorry for the delay in getting back to those who asked for documentation on our Visa protocol. I was stalling to send you the most up to date description and as usual things have taken longer; in part because it is a jointly authored document and requires coordination.. If you want a copy of an old Visa document, let me know. Otherwise I saved all the requests and should be sending something out shortly. Deborah Estrin ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711292142.AA09625@ucbvax.Berkeley.EDU] <1987112911130000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: enger%gburg.DECnet@BLUTO.SCC.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: The Adopt-A-Mailbridge foster parent program. Message-ID: <8711292142.AA09625@ucbvax.Berkeley.EDU> Date: Sun, 29-Nov-87 16:13:00 EST Article-I.D.: ucbvax.8711292142.AA09625 Posted: Sun Nov 29 16:13:00 1987 Date-Received: Wed, 2-Dec-87 20:01:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 69 Gentlepersons: CONTEL Federal Systems became the first foster parent in the Adopt-A- Mailbridge campaign. This campaign is an outgrowth of the suggestion to upgrade the EGP core gateways which was made at the recent IETF meeting. The EGP upgrade appears to have been very successful, reducing delays and packet loss by up to two orders of magnitude while the network load increased. The Adopt-A-Mailbridge program, as I've coined it, encourages members of the Internet community to improve service for all by making a temporary loan of equipment to upgrade a mailbridge gateway. Contel loaned an 11/73 processor to DCEC-MILNET-GW.ARPA. This note lists the results of some informal ping testing of the upgraded DCEC-MILNET-GW.ARPA (10.7.0.20), in comparison to concurrent tests of some of the other mailbridge gateways, and against a few tests of 10.7.0.20 taken before the upgrade. I do not have access to a net-26 host with which I could have performed throughput testing, so ping echo results are all I can provide. When comparing the performance of the upgraded DCEC to the other mailbridges keep in mind that more PSN hops must be traversed on net-10 to get to the other mailbridges. The host that I performed the testing from is connected to PSN DCEC20, as is DCEC-Milnet-GW.arpa. The "testing" consisted of pinging the net-10 interface address of the various mailbridge gateways and recording the average echo delay. Most measurements are based on receiving approximately 100 replies. One measurement of the original DCEC mailbridge received only 47 replies. For the purpose of removing the net-10 delay involved in opening a connection to the distant end, each test was preceded by a separate ping session of sufficient duration to see a few responses come back. Comparing the longest average delay measured from DCEC mailbridge (347ms) to the shortest average from any of the others (682ms), the improvement is a factor of 2. Comparing the average of all the upgraded DCEC measurements (279), to the average of the average measurements from all the others (1034), the improvement is a factor of 3.7. It would be useful if the effects of the extra net-10 PSN hops could be removed. Perhaps a conservative way to take a swag at this is to subtract off the afternoon net-10 average end to end delay (422ms) from the average delay figure for the remote mailbridges. This yields a corrected (??) delay figure for the remote mailbridges of 612ms, and an improvement factor of 2.2. My only data for the old DCEC was taken on the weekday test of the new PSN end to end software. Four measurements were taken. The longest of these received 129 packets, and lost 31%. It had an average delay of 14479ms. I am not considering this measurement. The average of the remaining three average delay measurements is 803ms. Based on this, the upgraded DCEC running on the old end to end is 2.88 times quicker. While the improvement is not as dramatic as that seen on the Arpanet EGP core gateways, it is still significant. I think we should try to locate Foster Parents for the rest of the mailbridges. Steve Atlas also reminds me that the EGP core gateways on the Milnet are still "un-sponsored". Finally, I wonder if the EGP core gateways would benefit from an even faster processor? Does anyone know if we can drop in an 11/83 cpu as easily as we dropped in the 11/73s? Has anyone got one to loan out? I hope all of you had a nice Thanksgiving Day, Bob Enger Contel Federal Systems enger@bluto.scc.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987112911130001> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Sun 29 Nov 87 13:15:16-PST Date: 29 Nov 87 16:13:00 EST From: "GBURG::ENGER" Subject: The Adopt-A-Mailbridge foster parent program. To: "abauman" cc: gross@gateway.mitre.org,petry@trantor.umd.edu, satlas@bbn.com,tcp-ip@sri-nic.arpa, enger Gentlepersons: CONTEL Federal Systems became the first foster parent in the Adopt-A- Mailbridge campaign. This campaign is an outgrowth of the suggestion to upgrade the EGP core gateways which was made at the recent IETF meeting. The EGP upgrade appears to have been very successful, reducing delays and packet loss by up to two orders of magnitude while the network load increased. The Adopt-A-Mailbridge program, as I've coined it, encourages members of the Internet community to improve service for all by making a temporary loan of equipment to upgrade a mailbridge gateway. Contel loaned an 11/73 processor to DCEC-MILNET-GW.ARPA. This note lists the results of some informal ping testing of the upgraded DCEC-MILNET-GW.ARPA (10.7.0.20), in comparison to concurrent tests of some of the other mailbridge gateways, and against a few tests of 10.7.0.20 taken before the upgrade. I do not have access to a net-26 host with which I could have performed throughput testing, so ping echo results are all I can provide. When comparing the performance of the upgraded DCEC to the other mailbridges keep in mind that more PSN hops must be traversed on net-10 to get to the other mailbridges. The host that I performed the testing from is connected to PSN DCEC20, as is DCEC-Milnet-GW.arpa. The "testing" consisted of pinging the net-10 interface address of the various mailbridge gateways and recording the average echo delay. Most measurements are based on receiving approximately 100 replies. One measurement of the original DCEC mailbridge received only 47 replies. For the purpose of removing the net-10 delay involved in opening a connection to the distant end, each test was preceded by a separate ping session of sufficient duration to see a few responses come back. Comparing the longest average delay measured from DCEC mailbridge (347ms) to the shortest average from any of the others (682ms), the improvement is a factor of 2. Comparing the average of all the upgraded DCEC measurements (279), to the average of the average measurements from all the others (1034), the improvement is a factor of 3.7. It would be useful if the effects of the extra net-10 PSN hops could be removed. Perhaps a conservative way to take a swag at this is to subtract off the afternoon net-10 average end to end delay (422ms) from the average delay figure for the remote mailbridges. This yields a corrected (??) delay figure for the remote mailbridges of 612ms, and an improvement factor of 2.2. My only data for the old DCEC was taken on the weekday test of the new PSN end to end software. Four measurements were taken. The longest of these received 129 packets, and lost 31%. It had an average delay of 14479ms. I am not considering this measurement. The average of the remaining three average delay measurements is 803ms. Based on this, the upgraded DCEC running on the old end to end is 2.88 times quicker. While the improvement is not as dramatic as that seen on the Arpanet EGP core gateways, it is still significant. I think we should try to locate Foster Parents for the rest of the mailbridges. Steve Atlas also reminds me that the EGP core gateways on the Milnet are still "un-sponsored". Finally, I wonder if the EGP core gateways would benefit from an even faster processor? Does anyone know if we can drop in an 11/83 cpu as easily as we dropped in the 11/73s? Has anyone got one to loan out? I hope all of you had a nice Thanksgiving Day, Bob Enger Contel Federal Systems enger@bluto.scc.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3044@phri.UUCP] <1987112915175800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.protocols.tcp-ip,comp.protocols.appletalk Subject: Using kboxes as an etherbridge Message-ID: <3044@phri.UUCP> Date: Sun, 29-Nov-87 20:17:58 EST Article-I.D.: phri.3044 Posted: Sun Nov 29 20:17:58 1987 Date-Received: Wed, 2-Dec-87 21:43:57 EST Organization: Public Health Research Institute, NYC, NY Lines: 27 We're in the process of planning an IP link to a campus-wide ethernet. Our first step will be to get a LADC line run from our building to the other side of the street; initially we will run 9600 bps slip, with plans to upgrade to an 56 kbps Ungermann-Bass etherbridge, or something similar when we can scrape up the funds (about $15k for the two ends, I'm told). I had an idea which might save us a lot of money, with greater bandwidth to boot. I figure it's about 2000 feet from here to there, as the crow flies. Since phone lines aren't as direct as crows, I really don't know how long it will be, but I hope under 4000 feet. You can run AppleTalk (using Farallon PhoneNet hardware) over that much regular twisted pair phone wire, or so they claim. It seems to me, a cheap way to get an etherbridge going would be to get two Kinetics KFPS boxes (with appropriate software downloaded), hook the AppleTalk sides up to the ends of the LADC circuit, and plug into the local ethernets on each end; a 230 kbps etherbridge for under $5000 total hardware cost (a $2000 kbox, $300 xciver, and $50 PhoneNet connector at each end, not counting the wire). You even have the added advantage that the AppleTalk only uses one pair of the 4-wire LADC, leaving the other pair for whatever you want to do with it. Any chance this will work? -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8711292131.aa12041@Huey.UDEL.EDU] <1987112916314900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: The Adopt-A-Mailbridge foster parent program. Message-ID: <8711292131.aa12041@Huey.UDEL.EDU> Date: Sun, 29-Nov-87 21:31:49 EST Article-I.D.: Huey.8711292131.aa12041 Posted: Sun Nov 29 21:31:49 1987 Date-Received: Wed, 2-Dec-87 22:55:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Bob, I love your foster-gateway program. Turns out 11/83s would require special memory boards and backplanes, so would probably not make good orphans. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [292358.871129.JBVB@AI.AI.MIT.EDU] <1987112917130100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Fragments and Interface Speeds Message-ID: <292358.871129.JBVB@AI.AI.MIT.EDU> Date: Sun, 29-Nov-87 22:13:01 EST Article-I.D.: AI.292358.871129.JBVB Posted: Sun Nov 29 22:13:01 1987 Date-Received: Wed, 2-Dec-87 22:18:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 45 >It's hard to believe that in this age of utterly cheap dense RAM, >otherwise sane people are proposing inserting artificial delays between >Ethernet packets because a lowball vendor wouldn't put, say, TWO >buffers on their card! > >[I admit I'm prejudiced, since I worked on Suns, which currently seem >to have the highest Ethernet thruput, but they were built out of >standard Ethernet chips and DRAMs available to everyone. You too can >handle infinite back to back packets, if you just design with that in >mind as Sun did.] > But whhhat about all those old, old Suns, the ones without back to back capacity. What about the tens of thousands of NI5010's or 3C501's. People bought them, have them, are working with them daily even though no double buffering is available. Its not just a querstion of being a lowball vendor, reality is the fact that old outmode hardware is out there and used! ... Larry Backman One point that may not be well known is that it is not just the single- buffered PC interfaces that drop packets. I have observed a DEQNA dropping packets that arrived too close together (or when it had a resource crunch, or something), sent from a PC. There is also considerable variation in the performance of different device drivers for the same interface. I've observed a VMS TCP/IP sending packets (with DEC's driver) much closer together than Ultrix manages to. Another point is that even the newest PC interface cards apparently can't always handle back-to-back packets (I haven't yet met the LAN controller chip that is as good as its salesmen imply). Presumably other controllers based on similar chips will have some susceptibility to overrun, also. So, don't just dismiss the problem: The closer two IP fragments are, the more likely it is that any arbitrary receiver will drop the second, requiring a high-level retransmit. Fragments are expensive to deal with in most environments, and almost everyone does their best to avoid them entirely. The exceptions I know of (NFS, routing protocols on big networks) that send fragments deliberately are very much special cases. I wasn't asking that the gateway people go to enormous lengths to insert delays, just to do so when convenient, in order to make the best of an already bad situation. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [418@trlluna.trl.oz] <1987112919400300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tyers@trlluna.trl.oz (P Tyers) Newsgroups: misc.wanted,comp.protocols.tcp-ip Subject: Connexions - Magazine (defunct ??) Message-ID: <418@trlluna.trl.oz> Date: Mon, 30-Nov-87 00:40:03 EST Article-I.D.: trlluna.418 Posted: Mon Nov 30 00:40:03 1987 Date-Received: Fri, 4-Dec-87 03:29:03 EST Organization: Computer Facilities, Telecom Australia Research Lines: 22 Keywords: TCP-IP , journal, info sought Can anyone assist me? Around May of this year I picked up a reference to a new journal from a net group (since forgotten hence the shotgun approach) Connexions - the Interoperability Report Editor - Ole J Jacobson Publisher Advanced Computing Environments 21370 Vai Avenue Cupertino Our library has attempted to order it but all Australian agents deny its existance and searches on Lockheed Dialog et al also don't find it. Does it still exist? Did it ever get off the ground? Can anyone give me a fuller citation. Ideally a fax/telex number and/or the name of an Australian agent who can be persuaded of its existance. Thanx in advance -- P Tyers, JANET tyers%trlluna.oz@uk.ac.ucl.cs ACSnet tyers@trlluna.oz UUCP {uunet,hplabs,ukc}!munnari!trlluna.oz!tyers CSnet tyers@trlluna.oz ARPAnet tyers%trlluna.oz@uunet.uu.net MAIL: Telecom Australia (Research), P.O. Box 249, Clayton, VICTORIA 3168,AUST D D Dp58 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [871030114019.20600227.DSTEVENS] <1987113006401800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DSTEVENS@VAXC.STEVENS-TECH.EDU (David L. Stevens) Newsgroups: comp.protocols.tcp-ip Subject: Question on mail headers Message-ID: <871030114019.20600227.DSTEVENS> Date: Mon, 30-Nov-87 11:40:18 EST Article-I.D.: <871030114019.20600227.DSTEVENS> Posted: Mon Nov 30 11:40:18 1987 Date-Received: Thu, 3-Dec-87 04:54:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 I thought that RFC822 didn't allow multiple TO:, SUBJECT:, DATE: lines in the header section of a mail message. For the last few weeks we've been getting messages that have this, anyone know why??? dave stevens Senior Systems Programmer Stevens Institute of Technology Internet: DSTEVENS@VAXC.STEVENS-TECH.EDU Bitnet: DSTEVENS@SITVXA "I was thinking of Socrates when he said "I drank what ?"" -Real Genius ------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712010256.AA07110@ucbvax.Berkeley.EDU] <1987113007125200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jlunny@NSWC-G.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Authentication Protocols Message-ID: <8712010256.AA07110@ucbvax.Berkeley.EDU> Date: Mon, 30-Nov-87 12:12:52 EST Article-I.D.: ucbvax.8712010256.AA07110 Posted: Mon Nov 30 12:12:52 1987 Date-Received: Fri, 4-Dec-87 00:51:44 EST References: <8711291926.AA04530@rt234.usc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 i am interested in an old document on your VISA protocol. All i need for now is general info on VISA. thanks john lunny NSWC ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1080@trotter.usma.edu] <1987113007411900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bill@trotter.usma.edu (Bill Gunshannon) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: TCP-IP on top of NETBIOS Message-ID: <1080@trotter.usma.edu> Date: Mon, 30-Nov-87 12:41:19 EST Article-I.D.: trotter.1080 Posted: Mon Nov 30 12:41:19 1987 Date-Received: Fri, 4-Dec-87 04:35:59 EST Organization: US Military Academy, West Point, NY Lines: 16 A short time ago someone posted a message saying they had made Phil Karn's TCP-IP run on top of NETBIOS. I would like to get in touch with the person who accomplished this as I have an interface using NETBIOS that I would like to try and run TCP-IP on. Any assistance would be greatly appreciated. bill gunshannon UUCP: {philabs}\ US SNAIL: Martin Marietta Data Systems {phri } >!trotter.usma.edu!bill USMA, Bldg 600, Room 26 {sunybcs}/ West Point, NY 10996 RADIO: KB3YV PHONE: WORK (914)446-7747 AX.25: KB3YV @ K3RLI PHONE: HOME (914)565-5256 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12354784493.6.MRC@PANDA.COM] <1987113008181100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@PANDA.COM (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Question on mail headers Message-ID: <12354784493.6.MRC@PANDA.COM> Date: Mon, 30-Nov-87 13:18:11 EST Article-I.D.: PANDA.12354784493.6.MRC Posted: Mon Nov 30 13:18:11 1987 Date-Received: Fri, 4-Dec-87 03:14:09 EST References: <871030114019.20600227.DSTEVENS> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 David Stevens - I reviewed RFC 822 briefly. The BNF suggests that a multiple "Date:" line shouldn't happen, but I could find no restriction on multiple "To:" or "Subject:" lines. If there is something in RFC 822 that you believe imposes such a restriction, please cite the reference by paragraph and page number. I would think that a reasonable RFC 822 implementation would simply ignore extraneous Date: and Subject: lines. Multiple To: lines are easy; just append the new data to the old data. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12354925894.6.MRC@PANDA.COM] <1987113021145500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@PANDA.COM (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: NFS over ARPANET Message-ID: <12354925894.6.MRC@PANDA.COM> Date: Tue, 1-Dec-87 02:14:55 EST Article-I.D.: PANDA.12354925894.6.MRC Posted: Tue Dec 1 02:14:55 1987 Date-Received: Fri, 4-Dec-87 06:35:27 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 I might note that a certain PDP-10 operating system at MIT had a working NFS over the ARPANET over 10 (15?) years ago. It was called MLDEV, and supported all the same operations as the local disk including disk-to-memory mapping. Someday, perhaps in the 90's, Unix will evolve to the point that we can once again enjoy the level of functionality we had in the 70's. :-( ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [UVgYdcy00UoJyPo2Yv@andrew.cmu.edu] <1987113023373000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: Fwd: NFS over arpanet? Message-ID: Date: Tue, 1-Dec-87 04:37:30 EST Article-I.D.: andrew.UVgYdcy00UoJyPo2Yv Posted: Tue Dec 1 04:37:30 1987 Date-Received: Fri, 4-Dec-87 06:30:54 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 It has been joked about for a while now, but it had to happen sooner or later.... Drew X-Digest-From: William LeFebvre X-Digest-Subject: Sun-Spots Digest, v5n64 X-Digest-To: Sun-Spots@rice.edu Message-Id: <1987.11.25.15.11.24.758.14837@rice.edu> Date: Fri, 13 Nov 87 15:28:12 PST From: ho@tis-w.arpa (Hilarie K. Orman) Subject: NFS over arpanet? I would like to hear from anyone who has tried to use NFS between Arpanet sites. I am advised that it would be painfully slow and awkward, but I would like to try. However, I cannot get "mount" to complete between the two test sites, so I cannot even begin to experience the pain. I have been in daily communication with Sun Support for two weeks about the following experiment between two arpanet machines: Both sites have NFS mounts running on their LAN's, so we know that the basic capability is there. The sites can rlogin to each, run FTP and Telnet, so we know the arpanet connectivity and addressing are OK. However, the command /etc/mount machine1:/glkspl /mnt results in an RPC timeout message after 20 seconds. Using the options "timeo=20000,rsize=512,wsize=512" doesn't alter anything at all, despite what you might think from reading the documentation. I think these options are only in effect after mount completes successfully, and the 20 second timeout is an unalterable parameter. I cannot see any evidence that machine1 ever sees the mount request. Does anyone know how to check this? Is rpcinfo definitive? Any help would be appreciated. Also any interest other sites might have in this capability should be expressed, since Sun's official opinion is "not supported". ----MESSAGE-END----