----MESSAGE-BEGIN---- [8512030128.AA26652%40ucbvax.berkeley.edu] <1985120213364200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: name servers Message-ID: <8512030128.AA26652@ucbvax.berkeley.edu> Date: Mon, 2-Dec-85 18:36:42 EST Article-I.D.: ucbvax.8512030128.AA26652 Posted: Mon Dec 2 18:36:42 1985 Date-Received: Tue, 3-Dec-85 01:12:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa The Berkeley BIND domain server is distributed by Kevin Dunlap, or . Contact him for information. It runs on 4.2 and 4.3 BSD UNIX systems. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985120213364201> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Mon 2 Dec 85 16:41:03-PST Date: Mon, 2 Dec 85 18:36:42 EST From: Mike Muuss To: Nat Howard cc: tcp-ip@sri-nic.arpa Subject: Re: name servers The Berkeley BIND domain server is distributed by Kevin Dunlap, or . Contact him for information. It runs on 4.2 and 4.3 BSD UNIX systems. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512030019.AA09271%40mitre-bedford.ARPA] <1985120214194200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: sra@MITRE-BEDFORD.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Network Management Softwore Message-ID: <8512030019.AA09271@mitre-bedford.ARPA> Date: Mon, 2-Dec-85 19:19:42 EST Article-I.D.: mitre-be.8512030019.AA09271 Posted: Mon Dec 2 19:19:42 1985 Date-Received: Wed, 4-Dec-85 20:53:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 19 Approved: tcp-ip@sri-nic.arpa I am interested in Management software for TCP/IP LANS, especially 802 compatible LANS. Of particular interest are Initializing and reconfiguring network resources from a central location Providing reports on performance and operational status Providing accounting information regarding the use of network services Detecting and resolving network operation problems Any information concerning the availability of such software would be greatly appreciated. Stan Ames sra at MITRE-BEDFORD.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12164214311.50.JNC%40MIT-XX.ARPA] <1985120309045400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Musical routing table slots Message-ID: <12164214311.50.JNC@MIT-XX.ARPA> Date: Tue, 3-Dec-85 14:04:54 EST Article-I.D.: MIT-XX.12164214311.50.JNC Posted: Tue Dec 3 14:04:54 1985 Date-Received: Wed, 4-Dec-85 20:43:19 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa I thought I'd warn everyone that we are in for a spell of musical chairs with the routing tables in the BBN core gateways again. Apparently we are up over 120 networks in the system, which is more networks than the core gateways have routing table slots, so if your gateway crashes you may find yourself out in the cold when you try and get back in. I don't know exactly when relief is coming; I spoke to someone at BBN and they are preparing to bring out a new release with more slots, but there's no definite timeline. In the interim, I appeal to all sites with more than one network number to please convert to using subnets. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12164338479.50.JNC%40MIT-XX.ARPA] <1985120320265900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Space wars Message-ID: <12164338479.50.JNC@MIT-XX.ARPA> Date: Wed, 4-Dec-85 01:26:59 EST Article-I.D.: MIT-XX.12164338479.50.JNC Posted: Wed Dec 4 01:26:59 1985 Date-Received: Wed, 4-Dec-85 21:11:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Actually, I'm a little bit puzzled by this space issue. In the CGW, a route takes up 14 bytes while an EGP neighbour takes up about 50. Admittedly, some of the fields in the EGP block aren't use simultaneously, and could be overlapped, but it's still not small. What I find curious is that the core gateways will apparently happily take many neighbours, but don't have room for routing entries. Why are the routing entries in the BBN gateways so large? Can someone from BBN explain what's going on here? Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512050021.AA17933%40ucbvax.berkeley.edu] <1985120411353200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: brescia@BBNCCV.ARPA (Mike Brescia) Newsgroups: mod.protocols.tcp-ip Subject: Re: Space wars Message-ID: <8512050021.AA17933@ucbvax.berkeley.edu> Date: Wed, 4-Dec-85 16:35:32 EST Article-I.D.: ucbvax.8512050021.AA17933 Posted: Wed Dec 4 16:35:32 1985 Date-Received: Thu, 5-Dec-85 19:42:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa The BBN gateways current version does not use memory mapping in the lsi11. (There are even some of the machines which are 11/02 without mapping hardware.) The tradeoff in memory is between packet buffers and routing table entries. Currently, the buffer capacity at some sites is just enough to absorb a bunch of packets from an ethernet (fast) sending out to an arpanet (slow) for a single ftp connection. In those cases, losing one buffer causes the probability of packet dropping to increase dramatically. Just ask the people at ISI. Memory mapping is included in a new version of software which is now running on a machine between bbnnet and arpanet and a local ethernet (which is to say that it is beyond debugging and into testing). In a couple of weeks, it should be released to some sites which have memory mapping hardware (11/23 processors). The arpanet-milnet gateways are being placed under configuration management, and should be ready for release with memory mapping in a couple of months. Memory mapping will allow extra memory to be used for buffering and allow more networks to be listed. Mike Brescia ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985120411353201> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Wed 4 Dec 85 13:47:37-PST To: egp-people@BBNCCV.ARPA, tcp-ip@sri-nic.ARPA Subject: Re: Space wars Date: 04 Dec 85 16:35:32 EST (Wed) From: Mike Brescia The BBN gateways current version does not use memory mapping in the lsi11. (There are even some of the machines which are 11/02 without mapping hardware.) The tradeoff in memory is between packet buffers and routing table entries. Currently, the buffer capacity at some sites is just enough to absorb a bunch of packets from an ethernet (fast) sending out to an arpanet (slow) for a single ftp connection. In those cases, losing one buffer causes the probability of packet dropping to increase dramatically. Just ask the people at ISI. Memory mapping is included in a new version of software which is now running on a machine between bbnnet and arpanet and a local ethernet (which is to say that it is beyond debugging and into testing). In a couple of weeks, it should be released to some sites which have memory mapping hardware (11/23 processors). The arpanet-milnet gateways are being placed under configuration management, and should be ready for release with memory mapping in a couple of months. Memory mapping will allow extra memory to be used for buffering and allow more networks to be listed. Mike Brescia ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985120411440700> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 4 Dec 85 19:47:44-PST Date: 4 Dec 1985 19:44:07 PST Subject: Re: Space wars From: Dan Lynch To: Mike Brescia cc: egp-people@BBNCCV.ARPA, tcp-ip@SRI-NIC.ARPA, LYNCH@USC-ISIB.ARPA In-Reply-To: (Message from "Mike Brescia " of 04 Dec 85 16:35:32 EST (Wed)) When I saw the first message on this topic I thought the issue was one of an outdated algorithm for routing table maintenance and not one of just increasing the table size to get over the current hump. Since some of the gateways will never have much memory (when is there ever "enough"?) it would appear that a name server model for gateways is in order. Hosts already have to deal with this issue (if they are playing it "honestly"). Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512050358.AA22192%40ucbvax.berkeley.edu] <1985120417440700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: LYNCH@USC-ISIB.ARPA (Dan Lynch) Newsgroups: mod.protocols.tcp-ip Subject: Re: Space wars Message-ID: <8512050358.AA22192@ucbvax.berkeley.edu> Date: Wed, 4-Dec-85 22:44:07 EST Article-I.D.: ucbvax.8512050358.AA22192 Posted: Wed Dec 4 22:44:07 1985 Date-Received: Thu, 5-Dec-85 20:00:59 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa When I saw the first message on this topic I thought the issue was one of an outdated algorithm for routing table maintenance and not one of just increasing the table size to get over the current hump. Since some of the gateways will never have much memory (when is there ever "enough"?) it would appear that a name server model for gateways is in order. Hosts already have to deal with this issue (if they are playing it "honestly"). Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512050735.AA26273%40ucbvax.berkeley.edu] <1985120420593300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Space wars Message-ID: <8512050735.AA26273@ucbvax.berkeley.edu> Date: Thu, 5-Dec-85 01:59:33 EST Article-I.D.: ucbvax.8512050735.AA26273 Posted: Thu Dec 5 01:59:33 1985 Date-Received: Thu, 5-Dec-85 20:16:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa In response to the message sent 04 Dec 85 16:35:32 EST (Wed) from brescia@BBNCCV.ARPA Mike, While more memory might provide a few more nets, my comment on packet-size limitations presumably remains valid. Last we talked, I think something like 130-odd networks was expected to break, depending upon the exact mix of class A/B/C nets. I got a taste today myself, when our beloved gateway winced and we had to recompete the table entries. Do not bury the port-expander nets just yet... Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512051344.AA03870%40mitre-bedford.ARPA] <1985120503435600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: sra@MITRE-BEDFORD.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Network Security Message-ID: <8512051344.AA03870@mitre-bedford.ARPA> Date: Thu, 5-Dec-85 08:43:56 EST Article-I.D.: mitre-be.8512051344.AA03870 Posted: Thu Dec 5 08:43:56 1985 Date-Received: Fri, 6-Dec-85 00:35:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 17 Approved: tcp-ip@sri-nic.arpa I would like to start a dialogue on network security. We currently have one host on the Milnet and are about to hook up our Ethernet subnet through a gateway. The problem is that upper level management is deathly afraid of hackers rummaging around throughout our network. It seems that one host on the network is almost acceptable but many may open up Pandoras box. What types of controls could be placed within the gateway to limit our access to random telnets and what arguments could we use to convince management that connecting our subnet to the Milnet does not increase our exposure to random attacks. Stan Ames sra at MITRE-Bedford ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512051549.AA04058%40ucbvax.berkeley.edu] <1985120504470100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: PADLIPSKY@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Creative Typo (?) Message-ID: <8512051549.AA04058@ucbvax.berkeley.edu> Date: Thu, 5-Dec-85 09:47:01 EST Article-I.D.: ucbvax.8512051549.AA04058 Posted: Thu Dec 5 09:47:01 1985 Date-Received: Thu, 5-Dec-85 20:22:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa I imagine Dave meant "recompute" (or even maybe "recomplete") rather than "recompete" the table entries, but if not, does this mean he's already doing something along the lines of Dan's suggested name server trick (by letting the available entry slots get filled in dynamically--and hence "competing" for them)? cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985120507110000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Thu 5 Dec 85 15:11:21-PST Date: 5 Dec 85 15:11:00 PST From: Subject: performance using IBM front-ends To: "tcp-ip" Reply-To: ACC would be interested in knowing some perfromance figures for the various IBM front-end systems currently installed. Of particular interest would be end-to-end sustained data rates between two hosts. That and various implemention considerations would also be useful. So as not to clutter the network please address your responses to me and I will summarize for the community. Regards, Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512051736.AA05863%40ucbvax.berkeley.edu] <1985120507125700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Creative Typo (?) Message-ID: <8512051736.AA05863@ucbvax.berkeley.edu> Date: Thu, 5-Dec-85 12:12:57 EST Article-I.D.: ucbvax.8512051736.AA05863 Posted: Thu Dec 5 12:12:57 1985 Date-Received: Thu, 5-Dec-85 20:57:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa In response to the message sent 5 Dec 1985 09:47:01 EST from PADLIPSKY@USC-ISI.ARPA Mike, My choice of word was deliberate and, I believe, accurate. I have had to take drastic action here, since congestion has sometimes toppled our gateway and broken EGP connectivity. Specifically, I intend to limit the number of nets per site in our backlot to one. I expect that may precipitate a headlong dash for 4.3bsd for its subnet code. Apollo and Sun, please take note. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12164728567.28.JNC%40MIT-XX.ARPA] <1985120508094800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: Network Security Message-ID: <12164728567.28.JNC@MIT-XX.ARPA> Date: Thu, 5-Dec-85 13:09:48 EST Article-I.D.: MIT-XX.12164728567.28.JNC Posted: Thu Dec 5 13:09:48 1985 Date-Received: Sat, 7-Dec-85 01:42:46 EST References: <8512051344.AA03870@mitre-bedford.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Various potential users of C Gateways have requested similar capabilities, and we had set up a mailing list to discuss exactly what mechanisms would be useful. However, due to lack of time on my part nothing has happened there yet. I would caution that the TCP-IP mailing list is a little big to conduct a discussion on; unfortunately I don't know of a good substitute. I would suggest that you contact your gateway vendor and see if he has any plans, or is setting up a customer discussion group. If you built your own gateway, then you're out in the cold; as far as I know, nobody has built any fancy access control mechanisms into any gateways yet. I'm not sure I see any necessity for standardization here; creating standards takes energy, of which there is a limited amount, and there are more important things needing to be standardized. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12164774430.27.OLE%40SRI-NIC.ARPA] <1985120512214400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen) Newsgroups: mod.protocols.tcp-ip Subject: My Christmas Wish Message-ID: <12164774430.27.OLE@SRI-NIC.ARPA> Date: Thu, 5-Dec-85 17:21:44 EST Article-I.D.: SRI-NIC.12164774430.27.OLE Posted: Thu Dec 5 17:21:44 1985 Date-Received: Fri, 6-Dec-85 00:37:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Hi folks, I am doing my best to keep the entries in the TCP/IP Vendor's Guide as up-to-date as possible. If you know of any information which is either missing, wrong, out-of-date and so on, please let me know so that we can make this document as useful as possible. The most recent version is always kept in: [SRI-NIC.ARPA]TCP-IP-IMPLEMENTATIONS.TXT We are planning to produce hard copy versions every 6 months starting in January 1986. Cheers, <370> ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12164781066.27.OLE%40SRI-NIC.ARPA] <1985120512581100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen) Newsgroups: mod.protocols.tcp-ip Subject: OOOOOOPS!!! Message-ID: <12164781066.27.OLE@SRI-NIC.ARPA> Date: Thu, 5-Dec-85 17:58:11 EST Article-I.D.: SRI-NIC.12164781066.27.OLE Posted: Thu Dec 5 17:58:11 1985 Date-Received: Sat, 7-Dec-85 01:59:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Forgot to give you the directory name, so that line should read: [SRI-NIC.ARPA]TCP-IP-IMPLEMENTATIONS.TXT Sorry! Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512052323.AA13049%40ucbvax.berkeley.edu] <1985120513110000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: gary@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: performance using IBM front-ends Message-ID: <8512052323.AA13049@ucbvax.berkeley.edu> Date: Thu, 5-Dec-85 18:11:00 EST Article-I.D.: ucbvax.8512052323.AA13049 Posted: Thu Dec 5 18:11:00 1985 Date-Received: Fri, 6-Dec-85 00:38:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa ACC would be interested in knowing some perfromance figures for the various IBM front-end systems currently installed. Of particular interest would be end-to-end sustained data rates between two hosts. That and various implemention considerations would also be useful. So as not to clutter the network please address your responses to me and I will summarize for the community. Regards, Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512060224.AA16360%40ucbvax.berkeley.edu] <1985120514095600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: Network Security Message-ID: <8512060224.AA16360@ucbvax.berkeley.edu> Date: Thu, 5-Dec-85 19:09:56 EST Article-I.D.: ucbvax.8512060224.AA16360 Posted: Thu Dec 5 19:09:56 1985 Date-Received: Fri, 6-Dec-85 08:07:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa If any of your hosts have dialups, then they are not any worse off being gatewayed to the MILNET. In any case, you can't depend on the network to provide reasonable security -- responsibility for security rests firmly on the host machine. For Army machines, this policy is well articulated by AR 380-380. BRL's machines implement minimum 6 char passwords, logging of all login attempts, both good and bad, plus operator notification of EVERY bad login attempt, plus connection disconnect after 3 tries. We have found these measures to adequately protect our machines at BRL. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985120514095601> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Thu 5 Dec 85 18:11:43-PST Date: Thu, 5 Dec 85 19:09:56 EST From: Mike Muuss To: sra@mitre-bedford.arpa cc: egp-people@bbnccv.arpa, tcp-ip@sri-nic.arpa, sra@mitre-bedford.arpa Subject: Re: Network Security If any of your hosts have dialups, then they are not any worse off being gatewayed to the MILNET. In any case, you can't depend on the network to provide reasonable security -- responsibility for security rests firmly on the host machine. For Army machines, this policy is well articulated by AR 380-380. BRL's machines implement minimum 6 char passwords, logging of all login attempts, both good and bad, plus operator notification of EVERY bad login attempt, plus connection disconnect after 3 tries. We have found these measures to adequately protect our machines at BRL. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512061404.AA01247%40aplvax.ARPA] <1985120604043200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: steve@APLVAX.ARPA (Steven Kahn) Newsgroups: mod.protocols.tcp-ip Subject: TCP-IP mailing list Message-ID: <8512061404.AA01247@aplvax.ARPA> Date: Fri, 6-Dec-85 09:04:32 EST Article-I.D.: aplvax.8512061404.AA01247 Posted: Fri Dec 6 09:04:32 1985 Date-Received: Sat, 7-Dec-85 02:23:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Could you please put me on the TCP-IP mailing list. Also, I understand that you maintain a file of previous correspondence. How could I obtain such a file, particular correspondence dealing with 4.2BSD UNIX issues? Thanks very much, Steve Kahn Johns Hopkins U. Applied Physics Lab Laurel, MD 20707 (312) 953-6812 Milnet: steve@aplvax.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512061605.AA00650%40ucbvax.berkeley.edu] <1985120605232800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: PADLIPSKY@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Slot Mechanics Message-ID: <8512061605.AA00650@ucbvax.berkeley.edu> Date: Fri, 6-Dec-85 10:23:28 EST Article-I.D.: ucbvax.8512061605.AA00650 Posted: Fri Dec 6 10:23:28 1985 Date-Received: Sat, 7-Dec-85 02:25:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Hmmm. I don't know about you, but I saw Dave Mills' answer to my comment on his non-typo before the comment came out in the Digest. There must be something funny about competing for slots here, too. Since he did really mean "recompeting", the Conditions of Contest would presumably be of interest to others than myself and Dan Lynch. How about it, David? What DO you mean by "recompeting"? (Don't need/want a Documentation Algol version of the algorithm [unless that's the easiest thing for you to do], but more than the cryptic-to-me reference to one net per site in the backlot would be most helpful.) cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512091413.AA14972%40ulysses.UUCP] <1985120605394900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Moderated newsgroup Message-ID: <8512091413.AA14972@ulysses.UUCP> Date: Fri, 6-Dec-85 10:39:49 EST Article-I.D.: ulysses.8512091413.AA14972 Posted: Fri Dec 6 10:39:49 1985 Date-Received: Fri, 13-Dec-85 02:02:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10.2 9/17/84; site mhuxh.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: mhuxh!mhuxv!mhuxt!mhuxr!ulysses!cbosgd!ucbvax!tcp-ip From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: Network Security Message-ID: <8512060224.AA16360@ucbvax.berkeley.edu> Date: 6 Dec 85 00:09:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 17 Organization; The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa If any of your hosts have dialups, then they are not any worse off being gatewayed to the MILNET. In any case, you can't depend on the network to provide reasonable security -- responsibility for security rests firmly on the host machine. For Army machines, this policy is well articulated by AR 380-380. BRL's machines implement minimum 6 char passwords, logging of all login attempts, both good and bad, plus operator notification of EVERY bad login attempt, plus connection disconnect after 3 tries. We have found these measures to adequately protect our machines at BRL. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512061835.AA03116%40ucbvax.berkeley.edu] <1985120607520500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Slot Mechanics Message-ID: <8512061835.AA03116@ucbvax.berkeley.edu> Date: Fri, 6-Dec-85 12:52:05 EST Article-I.D.: ucbvax.8512061835.AA03116 Posted: Fri Dec 6 12:52:05 1985 Date-Received: Sat, 7-Dec-85 05:58:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa In response to the message sent 6 Dec 1985 10:23:28 EST from PADLIPSKY@USC-ISI.ARPA cheers, Our gateway has several customers scattered from Maryland to California, all of which have extensive subnet networks in order to reduce the demand for core slots. One of our customers is using a class-C number because his Apollos cannot the subnet thing do. My comment was to suggest to him those Apollos either learn that trick or go babble only with themselves. There is nothing mysterious about competing for slots. All slots are normally occupied, so a new player must wait for an old gateway to crash, then grab a slot before anyone else can. Exactly like hunting for parking spaces during the Christmas rush. An agressive new player can always send a kiss-of-death packet to another gateway to increase the odds, of course. I will not describe what a kod packet is or might be. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512062328.AA24214%40blade.UUCP] <1985120613282200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: martin%blade@MOUTON.ARPA (Martin J Levy) Newsgroups: mod.protocols.tcp-ip Subject: Re: Slot Mechanics Message-ID: <8512062328.AA24214@blade.UUCP> Date: Fri, 6-Dec-85 18:28:22 EST Article-I.D.: blade.8512062328.AA24214 Posted: Fri Dec 6 18:28:22 1985 Date-Received: Sat, 7-Dec-85 05:57:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa people may be interested to note that when Bell Communications Research Joined CSNET and also got connectivity to the ARPANET, we asked that our ~23 Class C networks be added to the Core Gateways routing tables. you can guess the reply we got. hence work underway to convert too a class B subnet scheme. martin levy stuck on one of those non connected networks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851209131105.0.DCP%40NEPONSET.SCRC.Symbolics.COM] <1985120908110000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: DCP@SCRC-QUABBIN.ARPA (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: Zero window probes Message-ID: <851209131105.0.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 9-Dec-85 13:11:00 EST Article-I.D.: NEPONSET.851209131105.0.DCP Posted: Mon Dec 9 13:11:00 1985 Date-Received: Fri, 13-Dec-85 01:41:54 EST References: <851108205728.000456@CISL-SERVICE-MU Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa (Sorry for the slow comment, I've been off the net for a month.) I agree with the philosophical basis as stated by CERF. TCP allows the sending of one byte beyond the window for the purposes of probing. Since the byte is outside the window, the receiver MUST send an ACK. This shows that both TCP's are alive, and it is up to the higher level protocols to decide that the connection is worthless, even though the connection still validly exists. Therefore, I believe TOPS-20 and Unix (whichever version somebody mentioned) are in error by having TCP do the timeout. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512101110.AA12546%40ucbvax.berkeley.edu] <1985121000490000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Vshank@WEIZMANN.BITNET (Henry Nussbacher) Newsgroups: mod.protocols.tcp-ip Subject: Tim Fallon Message-ID: <8512101110.AA12546@ucbvax.berkeley.edu> Date: Tue, 10-Dec-85 05:49:00 EST Article-I.D.: ucbvax.8512101110.AA12546 Posted: Tue Dec 10 05:49:00 1985 Date-Received: Tue, 10-Dec-85 21:48:19 EST Sender: kennish@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors Guide lists him as timf%tek@rand-relay.arpa. I tried timf%tektronix@csnet-relay.arpa but that didn't help. Can someone please send me his network address (I am trying to track down the VMS Tcp/Ip program distributed by Tektronix). Sorry for bothering the list, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121016190000> Received: from WISCVM.ARPA by SRI-NIC.ARPA with TCP; Tue 10 Dec 85 02:52:08-PST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 12/10/85 at 04:52:08 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 9809; Tue, 10 Dec 85 12:52:52 O Date: Tue, 10 Dec 1985 12:49 O From: Henry Nussbacher Subject: Tim Fallon To: I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors Guide lists him as timf%tek@rand-relay.arpa. I tried timf%tektronix@csnet-relay.arpa but that didn't help. Can someone please send me his network address (I am trying to track down the VMS Tcp/Ip program distributed by Tektronix). Sorry for bothering the list, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512111649.AA16820%40shell.UUCP] <1985121106493500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Spartacus Knet and Wisconsin Wiscnet Message-ID: <8512111649.AA16820@shell.UUCP> Date: Wed, 11-Dec-85 11:49:35 EST Article-I.D.: shell.8512111649.AA16820 Posted: Wed Dec 11 11:49:35 1985 Date-Received: Sun, 15-Dec-85 05:31:21 EST References: <8512032328.AA21073@ucbvax.berkeley.edu> Sender: bloom@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa How about Spartacus Knet and IBM VM support for TCP/IP (basically Wiscnet)? Tom Webb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512120559.AA10948%40ucbvax.berkeley.edu] <1985121116084300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Gateway Slots Message-ID: <8512120559.AA10948@ucbvax.berkeley.edu> Date: Wed, 11-Dec-85 21:08:43 EST Article-I.D.: ucbvax.8512120559.AA10948 Posted: Wed Dec 11 21:08:43 1985 Date-Received: Fri, 13-Dec-85 02:13:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 124 Approved: tcp-ip@sri-nic.arpa Sirs - I am writing this letter to bring to your attention a serious operational problem with the CORE gateway system which provides routing connectivity between the ARPANET, MILNET, SATNET, and all LANs within the InterNet system. Briefly stated, the problem is that the current core gateway software only has room for a fixed number of routes between networks, currently about 100. (I'll call these routing table entries "slots"). Within the past few weeks, the number of networks (mostly LANs) connected to the InterNet system has exceeded the number of slots, resulting in a shortage of slots. Attempts to provide routing information to the core system are processed only as slots become available -- on a first-come, first-served basis. Some gateway somewhere has to crash to relinquish a slot for another gateway to gain connectivity. MAJOR FAILURE IN OPERATIONAL SYSTEM. This past weekend, due to an extensive power outage, both of BRL's gateways were down, relinquishing the slots we had been using. BRL's IMP resumed operating Sunday night, and BRL's 2 Gateways resumed operation Monday morning, but BRL was completely without network connectivity throughout the day Monday as we waited for slots to become available within the core gateway system. Lack of slots prevented any access to or from the MILNET, blocking mail flow between BRL and AMC-HQ, USNA, ARDC, WSMR, and the numerous other hosts we do regular business with. Fortunately, other gateways went down through the day, and by Monday evening BRL had reacquired routing slots. A one-day network outage was no disaster, and we survived. However, if we loose network connectivity for a day or more every time our gateways or IMP go down, BRL has a major operational problem. Unless corrective action is taken, this problem will steadily become worse, because more and more MILNET sites will be operating attached LANs, and traffic is shifting from directly attached hosts to LAN-attached hosts. BRL feels the effect of this problem more keenly because BRL hosts are exclusively LAN-attached. However, all LAN-attached hosts within the InterNet system are affected by this problem! This problem was also encountered a few months ago, and BBN responded promptly by increasing the number of slots to the current limit. BBN is aware of the current problem, and is investigating solutions. However, they may not be able to increase the table sizes this time, due to limited memory in the core gateways. The medium-term solution to this problem would be to replace all LSI-11/03 core gateways with LSI-11/23 gateways, which have 4 times as much memory. I am under the impression that BBN has already developed software which takes advantage of the extra memory in the 11/23. The long-term solution is, of course, to replace the core gateway system with Butterfly gateways, but that is a long time away. SHORT-TERM SOLUTION NEEDED. There are several options. 1) Take administrative action. Insist that the most recent N new networks connected to the InterNet system immediately disconnect, until the number of available slots can be increased. 2) Provide a technological response. Instituting emergency measures, rapidly replace the core gateway system with 11/23 systems. 2a) Have BBN immediately upgrade all 11/03 systems withing the GGP core. 2b) If BBN does not have necessary equipment on hand, or en route, additional 11/23 system could be borrowed. For example, BRL has an 11/23 system which is temporarily not being used. BRL would be willing to loan it to DCA on a short term basis until BBN could procure the necessary 11/23 hardware. Certainly there are enough unused 11/23 systems throughout the combined Services that an immediate hardware solution could be implemented using loaned equipment. 3) Apply software magic, and increase the current table size without changing any hardware. This may be easy, but more likely it will be costly in time, costly in manpower, or simply impossible. MEDIUM-TERM DISASTER AWAITS. Even assuming that the current difficulty can be overcome, this problem will reappear again soon in another form. Indeed, the second stage of this problem is almost upon us. Here, the difficulty is again a growth limitation in the core gateway software. The core exchanges routing information between it's gateways using GGP (Gateway-to-Gateway Protocol). There exists an upper limit on the length of a GGP packet, and GGP is currently defined so as to contain information about the total InterNet system in a single packet. Thus, when the number of gateways increases beyond the number that can fit in a GGP packet, we will again experience competition for "slots" -- this time GGP packet "slots". Again, several solutions exist: 1) Administratively prohibit connecting more LANs than the GGP protocol can support. 2) Modify or extend the GGP protocol and the supporting core gateway software to ease or eliminate the current limits. 3) Replace the GGP protocol with something else (no finished design for a replacement exists yet, although it is being thought about). 3a) Replace GGP within the existing 11/23 systems with the new protocol. 3b) Replace all the 11/23 systems with Butterfly systems and the new protocol. Current plans for GGP replacement are being formed within BBN and the GADS Task Force (chaired by the able Dave Mills). I would like to suggest that the priority of this task be elevated, and that it's funding be increased. Investing in an extra man-year now might give us a long-term solution to this problem before disaster strikes. (I might also point out that the GADS Task Force is presently operating with little or no funding). Either GADS or BBN must get switched into "high gear" to solve this problem. SUMMARY. The "lack of slots" problem is upon us. Serious operational failures have already been experienced, and the problem will be getting worse. A short term solution is needed. Several options are available, none expensive. Worse, a secondary form of the problem will strike soon, even if we weather the current storm. Solutions can be found, but all will require effort and money. Spending money takes time, so we need to worry now. Sincerely, Mike Muuss Leader, Advanced Computer Systems Team U. S. Army Ballistic Research Lab ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121116084301> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Wed 11 Dec 85 18:10:44-PST Date: Wed, 11 Dec 85 21:08:43 EST From: Mike Muuss To: Col Maybaum , Baker@isi.arpa cc: TCP-IP@sri-nic.arpa, Bloom@monet.berkeley.edu, dca-pgs@ddn1.arpa Subject: Gateway Slots Sirs - I am writing this letter to bring to your attention a serious operational problem with the CORE gateway system which provides routing connectivity between the ARPANET, MILNET, SATNET, and all LANs within the InterNet system. Briefly stated, the problem is that the current core gateway software only has room for a fixed number of routes between networks, currently about 100. (I'll call these routing table entries "slots"). Within the past few weeks, the number of networks (mostly LANs) connected to the InterNet system has exceeded the number of slots, resulting in a shortage of slots. Attempts to provide routing information to the core system are processed only as slots become available -- on a first-come, first-served basis. Some gateway somewhere has to crash to relinquish a slot for another gateway to gain connectivity. MAJOR FAILURE IN OPERATIONAL SYSTEM. This past weekend, due to an extensive power outage, both of BRL's gateways were down, relinquishing the slots we had been using. BRL's IMP resumed operating Sunday night, and BRL's 2 Gateways resumed operation Monday morning, but BRL was completely without network connectivity throughout the day Monday as we waited for slots to become available within the core gateway system. Lack of slots prevented any access to or from the MILNET, blocking mail flow between BRL and AMC-HQ, USNA, ARDC, WSMR, and the numerous other hosts we do regular business with. Fortunately, other gateways went down through the day, and by Monday evening BRL had reacquired routing slots. A one-day network outage was no disaster, and we survived. However, if we loose network connectivity for a day or more every time our gateways or IMP go down, BRL has a major operational problem. Unless corrective action is taken, this problem will steadily become worse, because more and more MILNET sites will be operating attached LANs, and traffic is shifting from directly attached hosts to LAN-attached hosts. BRL feels the effect of this problem more keenly because BRL hosts are exclusively LAN-attached. However, all LAN-attached hosts within the InterNet system are affected by this problem! This problem was also encountered a few months ago, and BBN responded promptly by increasing the number of slots to the current limit. BBN is aware of the current problem, and is investigating solutions. However, they may not be able to increase the table sizes this time, due to limited memory in the core gateways. The medium-term solution to this problem would be to replace all LSI-11/03 core gateways with LSI-11/23 gateways, which have 4 times as much memory. I am under the impression that BBN has already developed software which takes advantage of the extra memory in the 11/23. The long-term solution is, of course, to replace the core gateway system with Butterfly gateways, but that is a long time away. SHORT-TERM SOLUTION NEEDED. There are several options. 1) Take administrative action. Insist that the most recent N new networks connected to the InterNet system immediately disconnect, until the number of available slots can be increased. 2) Provide a technological response. Instituting emergency measures, rapidly replace the core gateway system with 11/23 systems. 2a) Have BBN immediately upgrade all 11/03 systems withing the GGP core. 2b) If BBN does not have necessary equipment on hand, or en route, additional 11/23 system could be borrowed. For example, BRL has an 11/23 system which is temporarily not being used. BRL would be willing to loan it to DCA on a short term basis until BBN could procure the necessary 11/23 hardware. Certainly there are enough unused 11/23 systems throughout the combined Services that an immediate hardware solution could be implemented using loaned equipment. 3) Apply software magic, and increase the current table size without changing any hardware. This may be easy, but more likely it will be costly in time, costly in manpower, or simply impossible. MEDIUM-TERM DISASTER AWAITS. Even assuming that the current difficulty can be overcome, this problem will reappear again soon in another form. Indeed, the second stage of this problem is almost upon us. Here, the difficulty is again a growth limitation in the core gateway software. The core exchanges routing information between it's gateways using GGP (Gateway-to-Gateway Protocol). There exists an upper limit on the length of a GGP packet, and GGP is currently defined so as to contain information about the total InterNet system in a single packet. Thus, when the number of gateways increases beyond the number that can fit in a GGP packet, we will again experience competition for "slots" -- this time GGP packet "slots". Again, several solutions exist: 1) Administratively prohibit connecting more LANs than the GGP protocol can support. 2) Modify or extend the GGP protocol and the supporting core gateway software to ease or eliminate the current limits. 3) Replace the GGP protocol with something else (no finished design for a replacement exists yet, although it is being thought about). 3a) Replace GGP within the existing 11/23 systems with the new protocol. 3b) Replace all the 11/23 systems with Butterfly systems and the new protocol. Current plans for GGP replacement are being formed within BBN and the GADS Task Force (chaired by the able Dave Mills). I would like to suggest that the priority of this task be elevated, and that it's funding be increased. Investing in an extra man-year now might give us a long-term solution to this problem before disaster strikes. (I might also point out that the GADS Task Force is presently operating with little or no funding). Either GADS or BBN must get switched into "high gear" to solve this problem. SUMMARY. The "lack of slots" problem is upon us. Serious operational failures have already been experienced, and the problem will be getting worse. A short term solution is needed. Several options are available, none expensive. Worse, a secondary form of the problem will strike soon, even if we weather the current storm. Solutions can be found, but all will require effort and money. Spending money takes time, so we need to worry now. Sincerely, Mike Muuss Leader, Advanced Computer Systems Team U. S. Army Ballistic Research Lab ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121203113900> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 12 Dec 85 15:55:46-PST Received: from tektronix by csnet-relay.csnet id ae26497; 12 Dec 85 18:41 EST Date: Thursday, 12 Dec 85 11:11:39 PST From: Jeff Mulick To: ucbvax!tcp-ip%tektronix.csnet@CSNET-RELAY.ARPA Cc: tcp-ip@sri-nic.ARPA Fcc: inbox Subject: Re: Tim Fallon < > Tim Fallon is no longer with Tektronix, and I have replaced him. Requests for the tcp/ip VMS software should be sent to jeffm%tektronix@csnet-relay.arpa Thanks, Jeff Mulick Computer Resource Department DS 50/454 Tektronix, Inc. P.O. Box 500 Beaverton, OR 97077 UUCP: ...decvax!tektronix!jeffm ARPA: jeffm%tektronix@csnet-relay.arpa CSnet: jeffm@tektronix.csnet MaBell: (503) 627-5007 ------------------------------------------------ In reference to : Article 116 of mod.protocols.tcp-ip: Relay-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tektronix.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: tektronix!uw-beaver!cornell!vax135!houxm!mhuxt!mhuxr!ulysses!cbosgd!ucbvax!tcp-ip >From: Vshank@WEIZMANN.BITNET (Henry Nussbacher) Newsgroups: mod.protocols.tcp-ip Subject: Tim Fallon Message-ID: <8512101110.AA12546@ucbvax.berkeley.edu> Date: 10 Dec 85 10:49:00 GMT Date-Received: 12 Dec 85 02:24:17 GMT Sender: kennish@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors Guide lists him as timf%tek@rand-relay.arpa. I tried timf%tektronix@csnet-relay.arpa but that didn't help. Can someone please send me his network address (I am trying to track down the VMS Tcp/Ip program distributed by Tektronix). Sorry for bothering the list, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121205124900> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Thu 12 Dec 85 13:15:01-PST Date: 12 Dec 1985 13:12:49 PST Subject: Subnetting and gateways From: Dan Lynch To: MILLS@USC-ISID.ARPA cc: mike@BRL.ARPA, lmaybaum@DDN1.ARPA, tcp-ip@SRI-NIC.ARPA, Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA, gateway-tf@USC-ISIB.ARPA, lynch@USC-ISIB.ARPA In-Reply-To: (Message from "MILLS@USC-ISID.ARPA" of 12 Dec 1985 12:41:53 EST) Dave, Your last line was a whopper: that new procurements have subnetting support written into them! That is a rathr drastic measure and only pushes off the day when gateways will have to get smart anyway. I would vote for putting the most intelligence (and hairy algorithms) in the fewest possible places. That says to make gateways smart and let the hosts play dumb. Let there be a big database in the sky somewhere (known only to gateways?) that knows all routes and connectivity gory details. Then the gateways should just act as a cache for that monster database and feed their clients (hosts) info on a demand basis. This principle harkens from the days of early radio design when someone called a halt to the (then) impending decision to make the "protocol" between transmitters and receivers well "balanced" by spreading the implementation costs equally. The observation was made that when things got going hot and heavy there would be millions of receivers and only thousands of transmitters, so put the hair in the transmitters and make the receivers as simple as possible. (I am indebted to Dave Boggs for this story.) So, I argue for making life as simple as possbile for the multitude of hosts and put the hair in the gateways. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121207110000> Received: from su-navajo.arpa by SRI-NIC.ARPA with TCP; Thu 12 Dec 85 15:16:41-PST Received: by su-navajo.arpa with Sendmail; Thu, 12 Dec 85 15:12:00 pst Date: 12 Dec 1985 1511-PST (Thursday) From: Jeff Mogul To: Dan Lynch Cc: mike@BRL.ARPA, lmaybaum@DDN1.ARPA, tcp-ip@SRI-NIC.ARPA, Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA, gateway-tf@USC-ISIB.ARPA Subject: Re: Subnetting and gateways In-Reply-To: Dan Lynch / 12 Dec 1985 13:12:49 PST. I disagree that requiring RFC950-style subnet support is a bad idea. If implemented reasonably, using address masks, it insulates a host entirely from the addressing format (i.e., subnets? and if so, what bits specify the subnet?) So, rather than moving the smarts into the hosts, RFC950 goes in the opposite direction - put a simple mechanism into each host that allows it to offload all the smarts onto the gateways. Of course, even this much change is probably too much for some of our vendors. But the internet is too big to pretend that subnets are unnecessary. -Jeff P.S.: I believe Noel Chiappa has consistently advocated the position that non-gateway hosts should not even have routing tables; just a large enough redirect table (with host redirects only) and the address of one or more neighbor gateways. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512121830.AA14973%40ucbvax.berkeley.edu] <1985121207415300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8512121830.AA14973@ucbvax.berkeley.edu> Date: Thu, 12-Dec-85 12:41:53 EST Article-I.D.: ucbvax.8512121830.AA14973 Posted: Thu Dec 12 12:41:53 1985 Date-Received: Sat, 14-Dec-85 03:51:06 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa Folks, The issue is prominent on the agenda for the next GADS meeting on 16-17 January. It should be emphasized that immediate short-term relief can also result from an agressive campaign to use subnets, as described in RFC940 and RFC950. Subnets allow the internal structure of large communities of LANs, such as in use at MIT, CMU, Stanford and here, to be hidden from the Internet system at large. However, not all software implementations support a subnet feature, in particular Berkeley Unix 4.2bsd ex box. It would obviously be to great advantage either to retrofit subnet code in the 4.2bsd systems or to upgrade to 4.3bsd, which has that code. However, in the case of some popular workstations, including Sun and Apollo, this is not possible without the manufacturer's committment and support. Casual inspection of the gateway tables reveals several instances where a gateway to a LAN community lists a single class-B network together with up to several class-C networks, lending weight to the conjecture that the primary reason for the proliferation in class-C networks is to support just those workstations. I conclude that an effective way to manage at least the short-term problem is to actively encourage the upgrade of LAN software to support subnets. It should be possible to do this via the various user groups in response to administrative directives. I also conclude support for subnets be written into any new procurements. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121207415301> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Thu 12 Dec 85 09:43:32-PST Date: 12 Dec 1985 12:41:53 EST From: MILLS@USC-ISID.ARPA To: mike@BRL.ARPA, lmaybaum@DDN1.ARPA, TCP-IP@SRI-NIC.ARPA, To: Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA, To: MILLS@USC-ISID.ARPA, gateway-tf@USC-ISIB.ARPA cc: Re: ;, 11 Dec 85 21: ;, 08: ; Folks, The issue is prominent on the agenda for the next GADS meeting on 16-17 January. It should be emphasized that immediate short-term relief can also result from an agressive campaign to use subnets, as described in RFC940 and RFC950. Subnets allow the internal structure of large communities of LANs, such as in use at MIT, CMU, Stanford and here, to be hidden from the Internet system at large. However, not all software implementations support a subnet feature, in particular Berkeley Unix 4.2bsd ex box. It would obviously be to great advantage either to retrofit subnet code in the 4.2bsd systems or to upgrade to 4.3bsd, which has that code. However, in the case of some popular workstations, including Sun and Apollo, this is not possible without the manufacturer's committment and support. Casual inspection of the gateway tables reveals several instances where a gateway to a LAN community lists a single class-B network together with up to several class-C networks, lending weight to the conjecture that the primary reason for the proliferation in class-C networks is to support just those workstations. I conclude that an effective way to manage at least the short-term problem is to actively encourage the upgrade of LAN software to support subnets. It should be possible to do this via the various user groups in response to administrative directives. I also conclude support for subnets be written into any new procurements. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12166561526.31.JNC%40MIT-XX.ARPA] <1985121207583200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <12166561526.31.JNC@MIT-XX.ARPA> Date: Thu, 12-Dec-85 12:58:32 EST Article-I.D.: MIT-XX.12166561526.31.JNC Posted: Thu Dec 12 12:58:32 1985 Date-Received: Sat, 14-Dec-85 03:51:32 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Don't forget that as a temporary measure, subnets which are Ethernets can use the 'ARP subnet' strategy, which does not need any changes to host software. That approach is in use both at MIT and Stanford to support hosts which don't support subnets in our subnetted environment. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512130129.AA06160%40ucbvax.berkeley.edu] <1985121209113900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jeffm@TEKTRONIX.CSNET (Jeff Mulick) Newsgroups: mod.protocols.tcp-ip Subject: Re: Tim Fallon Message-ID: <8512130129.AA06160@ucbvax.berkeley.edu> Date: Thu, 12-Dec-85 14:11:39 EST Article-I.D.: ucbvax.8512130129.AA06160 Posted: Thu Dec 12 14:11:39 1985 Date-Received: Sat, 14-Dec-85 13:30:30 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 44 Approved: tcp-ip@sri-nic.arpa < > Tim Fallon is no longer with Tektronix, and I have replaced him. Requests for the tcp/ip VMS software should be sent to jeffm%tektronix@csnet-relay.arpa Thanks, Jeff Mulick Computer Resource Department DS 50/454 Tektronix, Inc. P.O. Box 500 Beaverton, OR 97077 UUCP: ...decvax!tektronix!jeffm ARPA: jeffm%tektronix@csnet-relay.arpa CSnet: jeffm@tektronix.csnet MaBell: (503) 627-5007 ------------------------------------------------ In reference to : Article 116 of mod.protocols.tcp-ip: Relay-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tektronix.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: tektronix!uw-beaver!cornell!vax135!houxm!mhuxt!mhuxr!ulysses!cbosgd!ucbvax!tcp-ip >From: Vshank@WEIZMANN.BITNET (Henry Nussbacher) Newsgroups: mod.protocols.tcp-ip Subject: Tim Fallon Message-ID: <8512101110.AA12546@ucbvax.berkeley.edu> Date: 10 Dec 85 10:49:00 GMT Date-Received: 12 Dec 85 02:24:17 GMT Sender: kennish@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors Guide lists him as timf%tek@rand-relay.arpa. I tried timf%tektronix@csnet-relay.arpa but that didn't help. Can someone please send me his network address (I am trying to track down the VMS Tcp/Ip program distributed by Tektronix). Sorry for bothering the list, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512122201.AA02067%40ucbvax.berkeley.edu] <1985121211124900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: LYNCH@USC-ISIB.ARPA (Dan Lynch) Newsgroups: mod.protocols.tcp-ip Subject: Subnetting and gateways Message-ID: <8512122201.AA02067@ucbvax.berkeley.edu> Date: Thu, 12-Dec-85 16:12:49 EST Article-I.D.: ucbvax.8512122201.AA02067 Posted: Thu Dec 12 16:12:49 1985 Date-Received: Fri, 13-Dec-85 09:18:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Dave, Your last line was a whopper: that new procurements have subnetting support written into them! That is a rathr drastic measure and only pushes off the day when gateways will have to get smart anyway. I would vote for putting the most intelligence (and hairy algorithms) in the fewest possible places. That says to make gateways smart and let the hosts play dumb. Let there be a big database in the sky somewhere (known only to gateways?) that knows all routes and connectivity gory details. Then the gateways should just act as a cache for that monster database and feed their clients (hosts) info on a demand basis. This principle harkens from the days of early radio design when someone called a halt to the (then) impending decision to make the "protocol" between transmitters and receivers well "balanced" by spreading the implementation costs equally. The observation was made that when things got going hot and heavy there would be millions of receivers and only thousands of transmitters, so put the hair in the transmitters and make the receivers as simple as possible. (I am indebted to Dave Boggs for this story.) So, I argue for making life as simple as possbile for the multitude of hosts and put the hair in the gateways. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512122318.AA03850%40ucbvax.berkeley.edu] <1985121212155800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Subnetting and gateways Message-ID: <8512122318.AA03850@ucbvax.berkeley.edu> Date: Thu, 12-Dec-85 17:15:58 EST Article-I.D.: ucbvax.8512122318.AA03850 Posted: Thu Dec 12 17:15:58 1985 Date-Received: Sat, 14-Dec-85 07:13:14 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa In response to your message sent 12 Dec 1985 13:12:49 PST Dan, I've never heard of Dave Bogg's story, but it probably would not apply to the non-consumer radio community today anyway. I'm not sure I understand what the gateways can do to ameliorate the the problem that (some) hosts do not understand subnets, other than in the special, but common, case of Ethernets, where Noel's suggestion might in fact be incorporated in the present gateways without too much trouble. His technique, which I have called "promiscuous ARP" is used in our gateways as well. As for advanced models, you may wish to see the document NEWMOD.DOC in the MILLS directory on ISID, which describes one possible scenario supporting mobile hosts, multiple-destination, multiple-path routing and serves ice cream for dessert. I suggest further discussion on this topic be switched to the tcp-ip repeater or direct. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512122228.AA03723%40tekcbi] <1985121212280100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tim Fallon Message-ID: <8512122228.AA03723@tekcbi> Date: Thu, 12-Dec-85 17:28:01 EST Article-I.D.: tekcbi.8512122228.AA03723 Posted: Thu Dec 12 17:28:01 1985 Date-Received: Fri, 13-Dec-85 20:50:46 EST References: <8512101110.AA12546@ucbvax.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: Tektronix, Inc., Beaverton, OR. Lines: 22 Approved: tcp-ip@sri-nic.arpa In article <8512101110.AA12546@ucbvax.berkeley.edu> you write: >I am trying to contact Tim Fallon of Tektronix and the Tcpip Implementors >Guide lists him as timf%tek@rand-relay.arpa. I tried >timf%tektronix@csnet-relay.arpa but that didn't help. Can someone please >send me his network address (I am trying to track down the VMS Tcp/Ip >program distributed by Tektronix). > >Sorry for bothering the list, >Hank Tim Fallon has left Tektronix. Noelan Olson is the person at Tek who knows most about the VMS TCP/IP implementation, but you have to catch him before he leaves Tek on 12/20 - he is following Tim to a new job. I don't know if Noelan is on the UNIX network. You can call him at (503) 627-5278. Jeff Thomson, a fellow in Noelan's group, is available at tektronix!tnet. Please do not post these names and phone numbers on the net unless Noelan or Jeff say it is okay. Linda Todd ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512130034.AA05222%40ucbvax.berkeley.edu] <1985121213110000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mogul@SU-NAVAJO.ARPA (Jeff Mogul) Newsgroups: mod.protocols.tcp-ip Subject: Re: Subnetting and gateways Message-ID: <8512130034.AA05222@ucbvax.berkeley.edu> Date: Thu, 12-Dec-85 18:11:00 EST Article-I.D.: ucbvax.8512130034.AA05222 Posted: Thu Dec 12 18:11:00 1985 Date-Received: Fri, 13-Dec-85 20:02:00 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa I disagree that requiring RFC950-style subnet support is a bad idea. If implemented reasonably, using address masks, it insulates a host entirely from the addressing format (i.e., subnets? and if so, what bits specify the subnet?) So, rather than moving the smarts into the hosts, RFC950 goes in the opposite direction - put a simple mechanism into each host that allows it to offload all the smarts onto the gateways. Of course, even this much change is probably too much for some of our vendors. But the internet is too big to pretend that subnets are unnecessary. -Jeff P.S.: I believe Noel Chiappa has consistently advocated the position that non-gateway hosts should not even have routing tables; just a large enough redirect table (with host redirects only) and the address of one or more neighbor gateways. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12166679970.31.JNC%40MIT-XX.ARPA] <1985121218491000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: Subnetting and gateways Message-ID: <12166679970.31.JNC@MIT-XX.ARPA> Date: Thu, 12-Dec-85 23:49:10 EST Article-I.D.: MIT-XX.12166679970.31.JNC Posted: Thu Dec 12 23:49:10 1985 Date-Received: Sat, 14-Dec-85 03:48:52 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Dan, the suggested modification to the host IP layer (to support subnetting), and other changes in gateways that the Gateway Committee are contemplating, are supposed to make the host IP layer simpler, not more complicated. The whole idea is precisely to put all the smarts in the gateway, with only the simplest possible cache in the host, and to attempt insulate the host IP layers from any further changes to the basic system architecture. Once all hosts use the mask technique, and get (and use) only per-host Redirects, it will be possible for the gateways to play arbitrary games with the layout of the system without the host IP layers noticing. The sooner this change is installed everywhere the better. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121301353300> Received: from SRI-KL.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Dec 85 09:37:07-PST Date: Fri 13 Dec 85 09:35:33-PST From: Mathis@SRI-KL.ARPA To: MILLS@USC-ISID.ARPA cc: mike@BRL.ARPA, lmaybaum@DDN1.ARPA, TCP-IP@SRI-NIC.ARPA, Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA, gateway-tf@USC-ISIB.ARPA, Mathis@SRI-KL.ARPA In-Reply-To: Message from "MILLS@USC-ISID.ARPA" of Thu 12 Dec 85 12:41:53-PST Dave, (Flame on -- better put on your fire suit) Of course you have chairman's perogative, but I would hate to see the gateway task force bogged down by what, in the short term, is such a truely operational concern that the people involved (both DCA and BBN) should be embarrassed that this issue has surfaced and we (as users) should be concerned that no solution has been forthcoming. Where is this great INOC that BBN requires implementers to discover that the routing table is full; where is the butterfly gateway to save us, and where is the management controls that let any random site fill up the MILNET (core) gateways with networks without DCA approval. On this last point, I don't mean that DCA should "bless" every network before it can be put on the internet; but in a situation of scare resources (table slots) some management direction must be supplied for the good of the MILNET/ARPANET community. Besides, filling up a gateways routing table with bogus networks is a great way to attack a network (hope the Russians don't have EGP yet). I'm sure some back-pressure could reduce the number of networks. (For example, SRI has 3 class-B Ethernets. Early on, the reason for 3 Ethernet cables in the same building were political & traffic density concerns; in retrospect we could survive with 1 network number if appropriate back-pressure had been applied.) If all the people that have asked for network numbers gets their acts together and buy gateways, the core will be in big problems. The main issues appear to be proper technical guidance and operational management; for that we need the "fire fighting" task force with proper funding and not the GADS which survives by skimming money from research contracts. I don't even know what more the GADS or the IAB can do; the direction has been clear: build/install more capable gateways (butterflys), improve the routing algorithms (SPF and son of GGP) and implement subnets. The GADS should spend its limited time and energies on new internet architectures. with 20/20 hindsight and apologies to the unjustly roasted, Jim ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121306210000> Received: from SRI-CSL.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Dec 85 14:22:57-PST Date: 13 Dec 1985 14:21-PST Sender: GEOFF@SRI-CSL.ARPA Subject: Re: Gateway Slots From: the tty of Geoffrey S. Goodfellow To: mike@BRL.ARPA Cc: lmaybaum@DDN1.ARPA, TCP-IP@SRI-NIC.ARPA Cc: Bloom@MONET.BERKELEY.EDU, dca-pgs@DDN1.ARPA Cc: Baker@USC-ISI.ARPA Message-ID: <[SRI-CSL.ARPA]13-Dec-85 14:21:50.GEOFF> In-Reply-To: The message of Wed, 11 Dec 85 21:08:43 EST from Mike Muuss With respect to gateway slots filling up, can anyone explain, why in this day and age of endless approvals and OK's from upon high for the trivialest of things, such as controlling net access down to the RS-232 terminal port level on TACs its possible for anyone to just "plug a gateway in" and your up? it's my impression that to join in the internet club these days you just find a friendly site that lets you plug into their local net and you then EGP your existence out to the world. None of this paper work "stuff" like you need to do now on enabling a TAC ports to connect a simple terminal up to! Can anyone explain why there is such control over hooking terminals onto TAC's when there is no control over hooking gateways onto the Internet? Has anyone dumped the gateway routing tables just to see what the difference between "who is out there" and "who is authorized to be connected out there is"? What prevents anyone else from adding on? g ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512140133.AA00386%40ucbvax.berkeley.edu] <1985121306390000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JOHNSON@NORTHEASTERN.CSNET (Chris Johnson) Newsgroups: mod.protocols.tcp-ip Subject: Info request. Message-ID: <8512140133.AA00386@ucbvax.berkeley.edu> Date: Fri, 13-Dec-85 11:39:00 EST Article-I.D.: ucbvax.8512140133.AA00386 Posted: Fri Dec 13 11:39:00 1985 Date-Received: Sat, 14-Dec-85 07:14:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Hello! At Northeastern University we are building an ethernet LAN with a still somewhat amorphous topology. I am considering buying various vendor's implementations of TCP-IP Two that come to mind are The Wollongong Group's for VAX/VMS and Data General's for AOS/VS. Data General's seems to be somewhat limited in that they don't provide an SMTP (among other things) that I can find. Are there any users for these out there? I'm interested in bug reports, functionality reports, ease of use (all kinds) reports, or reasonable rumors if there are any. Do these two implementations talk to each other (I should hope) and Berkeley 4.2 or higher? Any and all information or experience will be much appreciated. The list in general may be interested but my address is below. Thank you. Chris Johnson johnson@northeastern (CSNet) johnson%northeastern@csnet-relay (ARPAnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512131806.AA22622%40ucbvax.berkeley.edu] <1985121307353300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Mathis@SRI-KL.ARPA Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8512131806.AA22622@ucbvax.berkeley.edu> Date: Fri, 13-Dec-85 12:35:33 EST Article-I.D.: ucbvax.8512131806.AA22622 Posted: Fri Dec 13 12:35:33 1985 Date-Received: Fri, 13-Dec-85 20:57:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa Dave, (Flame on -- better put on your fire suit) Of course you have chairman's perogative, but I would hate to see the gateway task force bogged down by what, in the short term, is such a truely operational concern that the people involved (both DCA and BBN) should be embarrassed that this issue has surfaced and we (as users) should be concerned that no solution has been forthcoming. Where is this great INOC that BBN requires implementers to discover that the routing table is full; where is the butterfly gateway to save us, and where is the management controls that let any random site fill up the MILNET (core) gateways with networks without DCA approval. On this last point, I don't mean that DCA should "bless" every network before it can be put on the internet; but in a situation of scare resources (table slots) some management direction must be supplied for the good of the MILNET/ARPANET community. Besides, filling up a gateways routing table with bogus networks is a great way to attack a network (hope the Russians don't have EGP yet). I'm sure some back-pressure could reduce the number of networks. (For example, SRI has 3 class-B Ethernets. Early on, the reason for 3 Ethernet cables in the same building were political & traffic density concerns; in retrospect we could survive with 1 network number if appropriate back-pressure had been applied.) If all the people that have asked for network numbers gets their acts together and buy gateways, the core will be in big problems. The main issues appear to be proper technical guidance and operational management; for that we need the "fire fighting" task force with proper funding and not the GADS which survives by skimming money from research contracts. I don't even know what more the GADS or the IAB can do; the direction has been clear: build/install more capable gateways (butterflys), improve the routing algorithms (SPF and son of GGP) and implement subnets. The GADS should spend its limited time and energies on new internet architectures. with 20/20 hindsight and apologies to the unjustly roasted, Jim ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121308390000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Dec 85 16:40:32-PST Received: from northeastern by csnet-relay.csnet id ac09623; 13 Dec 85 19:21 EST Date: Fri, 13 Dec 85 12:39 EDT From: Chris Johnson To: tcp-ip@sri-nic.arpa, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: Info request. Hello! At Northeastern University we are building an ethernet LAN with a still somewhat amorphous topology. I am considering buying various vendor's implementations of TCP-IP Two that come to mind are The Wollongong Group's for VAX/VMS and Data General's for AOS/VS. Data General's seems to be somewhat limited in that they don't provide an SMTP (among other things) that I can find. Are there any users for these out there? I'm interested in bug reports, functionality reports, ease of use (all kinds) reports, or reasonable rumors if there are any. Do these two implementations talk to each other (I should hope) and Berkeley 4.2 or higher? Any and all information or experience will be much appreciated. The list in general may be interested but my address is below. Thank you. Chris Johnson johnson@northeastern (CSNet) johnson%northeastern@csnet-relay (ARPAnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BSRI-CSL.ARPA%5D13-Dec-85.14:21:50.GEOFF] <1985121312210000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Geoff@SRI-CSL.ARPA (the tty of Geoffrey S. Goodfellow) Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Slots Message-ID: <[SRI-CSL.ARPA]13-Dec-85.14:21:50.GEOFF> Date: Fri, 13-Dec-85 17:21:00 EST Article-I.D.: <[SRI-CSL.ARPA]13-Dec-85.14:21:50.GEOFF> Posted: Fri Dec 13 17:21:00 1985 Date-Received: Sat, 14-Dec-85 03:38:03 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa With respect to gateway slots filling up, can anyone explain, why in this day and age of endless approvals and OK's from upon high for the trivialest of things, such as controlling net access down to the RS-232 terminal port level on TACs its possible for anyone to just "plug a gateway in" and your up? it's my impression that to join in the internet club these days you just find a friendly site that lets you plug into their local net and you then EGP your existence out to the world. None of this paper work "stuff" like you need to do now on enabling a TAC ports to connect a simple terminal up to! Can anyone explain why there is such control over hooking terminals onto TAC's when there is no control over hooking gateways onto the Internet? Has anyone dumped the gateway routing tables just to see what the difference between "who is out there" and "who is authorized to be connected out there is"? What prevents anyone else from adding on? g ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512140012.AA29166%40ucbvax.berkeley.edu] <1985121312481900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: (Response to message) Message-ID: <8512140012.AA29166@ucbvax.berkeley.edu> Date: Fri, 13-Dec-85 17:48:19 EST Article-I.D.: ucbvax.8512140012.AA29166 Posted: Fri Dec 13 17:48:19 1985 Date-Received: Sun, 15-Dec-85 12:27:36 EST Sender: bloom@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa In response to your message sent Fri 13 Dec 85 09:35:33-PST Jim, I'm very glad to hear you say that. As you know, I have been hammering for a "Technology Transfer Task Force" which could more properly hack the operational issues than GADS. It would seem that Mitre, as staff to DDN PMO, would be the ideal focal point for that. Meanwhile, the buck keeps landing at our airport. Perhaps we should continue this via the GADS repeater or direct. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512140357.AA02784%40ucbvax.berkeley.edu] <1985121316452900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Slots Message-ID: <8512140357.AA02784@ucbvax.berkeley.edu> Date: Fri, 13-Dec-85 21:45:29 EST Article-I.D.: ucbvax.8512140357.AA02784 Posted: Fri Dec 13 21:45:29 1985 Date-Received: Sat, 14-Dec-85 07:11:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa The the response form issued with a new network number includes a statement about how your network can not be connected to the core without prior approval from the NIC, and that you also need to become part of a registered Autonomous System. However, there is presently no room for either the code or data needed to validate A.S. numbers in the core gateways, so there is nothing which prevents people from just plugging in. The source of the current problem is that now that 4.2BSD UNIX is capable of being a full EGP gateway, lots of people are getting LANs and connecting them. Indeed, the single most common gateway system on the InterNet these days is 4.2BSD, somewhat to the surprise of the original networking folks. Implementing subnets will take some of the strain off (if we can do it fast enough), but converting to subnet numbers requires a massive change in all local host addresses. Also, for those of us who purchase TCP-speaking devices (like laser printers, LISP machines, etc) from random vendors, we must depend on the vendor to implement subnet support. As the RFC documenting the subnet strategy is fairly recent, not all vendors have taken notice yet. Some vendors (most notably Excelan) are still struggling with things like IP routing and ICMP (sigh), and their boards are found in many current "off the shelf" products. We at BRL are working towards reducing the number of network numbers we require, but currently I expect it to take us another month or two to really make progress in this direction; others will need similar time to undertake implementing subnet routing within their gateways, and then convert their hosts. I would wager that the subnet tide will not turn until 4.3BSD is in widespread use. Even if 4.3 tapes were to teleport out to all 4.2 sites tomorrow, it would take most sites a month or two to switch, so 4.3 is not the cure to our immediate woes. I predict that if everything goes well, and all the core gateways are enhanced to 11/23 systems, and most sites drop back to using just one or two net numbers, that we might just barely survive the continued InterNet growth until the GGP replacement (core IGP, really) is designed and implemented. Maybe. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121316452901> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Dec 85 18:51:41-PST Date: Fri, 13 Dec 85 21:45:29 EST From: Mike Muuss To: GEOFF@sri-csl.arpa cc: mike@BRL.ARPA, LMaybaum@ddn1.arpa, tcp-ip@sri-nic.arpa, Bloom@monet.berkeley.edu, dca-pgs@ddn1.arpa, Baker@usc-isi.arpa, Perry@ipto.arpa Subject: Re: Gateway Slots The the response form issued with a new network number includes a statement about how your network can not be connected to the core without prior approval from the NIC, and that you also need to become part of a registered Autonomous System. However, there is presently no room for either the code or data needed to validate A.S. numbers in the core gateways, so there is nothing which prevents people from just plugging in. The source of the current problem is that now that 4.2BSD UNIX is capable of being a full EGP gateway, lots of people are getting LANs and connecting them. Indeed, the single most common gateway system on the InterNet these days is 4.2BSD, somewhat to the surprise of the original networking folks. Implementing subnets will take some of the strain off (if we can do it fast enough), but converting to subnet numbers requires a massive change in all local host addresses. Also, for those of us who purchase TCP-speaking devices (like laser printers, LISP machines, etc) from random vendors, we must depend on the vendor to implement subnet support. As the RFC documenting the subnet strategy is fairly recent, not all vendors have taken notice yet. Some vendors (most notably Excelan) are still struggling with things like IP routing and ICMP (sigh), and their boards are found in many current "off the shelf" products. We at BRL are working towards reducing the number of network numbers we require, but currently I expect it to take us another month or two to really make progress in this direction; others will need similar time to undertake implementing subnet routing within their gateways, and then convert their hosts. I would wager that the subnet tide will not turn until 4.3BSD is in widespread use. Even if 4.3 tapes were to teleport out to all 4.2 sites tomorrow, it would take most sites a month or two to switch, so 4.3 is not the cure to our immediate woes. I predict that if everything goes well, and all the core gateways are enhanced to 11/23 systems, and most sites drop back to using just one or two net numbers, that we might just barely survive the continued InterNet growth until the GGP replacement (core IGP, really) is designed and implemented. Maybe. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512141645.AA29480%40blade.UUCP] <1985121406453500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: martin%blade@MOUTON.ARPA (Martin J Levy) Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Slots Message-ID: <8512141645.AA29480@blade.UUCP> Date: Sat, 14-Dec-85 11:45:35 EST Article-I.D.: blade.8512141645.AA29480 Posted: Sat Dec 14 11:45:35 1985 Date-Received: Sat, 14-Dec-85 16:35:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa as an extra note to the one about TAC terminal connections and gateways connections being respectively both hard and easy, i would also like to ask the question: "why are core gateways still 11/03's and not 11/23's or even 73's?" in these days, with the reduced cost of these processors and memory, and even with the software knowledge of how to program the memory mapping registers of these processors why is there still a restriction on the numbers of network numbers that can be held in the gateways memory. if i remember correct the C-GATE and the BRL gateways both use memory mapped code. please don't take this as a vote against subnetting, but more of a note that is worried about what will happen later, what the number of networks goes up. the subnet solution will help big sites (like us), but not with lots of small sites, where one cable is all they have anyway. martin levy. bellcore, nj. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12167535074.50.HEDRICK%40RED.RUTGERS.EDU] <1985121601062400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Slots Message-ID: <12167535074.50.HEDRICK@RED.RUTGERS.EDU> Date: Mon, 16-Dec-85 06:06:24 EST Article-I.D.: RED.12167535074.50.HEDRICK Posted: Mon Dec 16 06:06:24 1985 Date-Received: Mon, 16-Dec-85 23:00:30 EST References: <[SRI-CSL.ARPA]13-Dec-85.14:21:50.GEOFF> Sender: serge@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa There have been a couple of messages implying that you can just plug into the Internet. We connected a gateway a few months ago. At that time, it was necessary to get approval to connect a network to the Internet. It was also necessary to get approval to change which machine acted as a gateway. As you probably know, there is a separate process to apply for an Internet network number. It is interesting in the context of this discussion that the application implies that the authorities would rather give you a class C address or a range of class C addresses than a single class B address. In fact an industrial group which I have been working with did get a range of class C addresses. (They have no immediate plans to connect to the Internet.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512161315.AA01112%40epsilon.UUCP] <1985121603153900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tim Fallon Message-ID: <8512161315.AA01112@epsilon.UUCP> Date: Mon, 16-Dec-85 08:15:39 EST Article-I.D.: epsilon.8512161315.AA01112 Posted: Mon Dec 16 08:15:39 1985 Date-Received: Mon, 16-Dec-85 23:13:11 EST References: <8512130258.AA07439@ucbvax.berkeley.edu> Sender: serge@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Good ! and at last... the address i wanted. Could you please send the appropriate paperwork to me for tcp/ip (vms) at the following ??? Ron Tribble Ford Motor Company p/o Box 6010 D.P.T.C. Building E.E.D. Room B206 Dearborn, Michigan 48124 We are looking for a good link between Vax and *ix machines. We also need the dope for tcp on *ix machines. Thanks Much in advance ron tribble mb2c!eed092!ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121607310000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Mon 16 Dec 85 15:49:31-PST Date: 16 Dec 85 15:31:00 PST From: Subject: ARPAnet Users' Forum at DECUS To: "tcp-ip" cc: lars Reply-To: In the hope of seeing the faces that go with the names familiar to readers of the INFO-VAX bulletin board, I called a BOF session at DECUS, titled "ARPAnet User's Forum". Probably the title was misleading, for none of the people I had expected to see showed up; instead there were a number of people interested in the politics of ARPAnet, foremost among these Dr Dennis Perry from Los Alamos Natl Labs, who is the head of DARPA/IPTO, and thus chief of ARPAnet. Dr Perry gave a very interesting overview of the questions facing DARPA, including the following (this is typed from my personal notes; my apologies for any inaccuracies and misunderstandings): - how long will the core gateways survive politically ? - how long will the core gateways survive technically, and how can the technical problems be resolved (Domain-severs for IP routing, anyone ?) ? - if ARPAnet were gone tomorrow, would anyone miss it ? (the current net is no longer a "research net" but a production network; the days when you could take the network down for a day to test a new routing algorithm are long gone). The issues in the net today are engineering problems, not research problems. - if we could provide giga-bit links, could anyone think of something useful to do with them, other than slice them into smaller pieces ? Discussions are underway about merging the various research networks into a new joint administration, encompassing DARPA, NASA, NSF etc. It is hoped that this can raise 20 million dollars of new funding. - - - Next year, it would be interesting to have three different sessions: - one like this one - one for TCP-IP readers - and the INFO-VAX one. / Lars Poulsen Advanced Computer Communications ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512170021.AA07063%40ucbvax.berkeley.edu] <1985121613310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: lars@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: ARPAnet Users' Forum at DECUS Message-ID: <8512170021.AA07063@ucbvax.berkeley.edu> Date: Mon, 16-Dec-85 18:31:00 EST Article-I.D.: ucbvax.8512170021.AA07063 Posted: Mon Dec 16 18:31:00 1985 Date-Received: Tue, 17-Dec-85 06:09:52 EST Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 46 Approved: tcp-ip@sri-nic.arpa In the hope of seeing the faces that go with the names familiar to readers of the INFO-VAX bulletin board, I called a BOF session at DECUS, titled "ARPAnet User's Forum". Probably the title was misleading, for none of the people I had expected to see showed up; instead there were a number of people interested in the politics of ARPAnet, foremost among these Dr Dennis Perry from Los Alamos Natl Labs, who is the head of DARPA/IPTO, and thus chief of ARPAnet. Dr Perry gave a very interesting overview of the questions facing DARPA, including the following (this is typed from my personal notes; my apologies for any inaccuracies and misunderstandings): - how long will the core gateways survive politically ? - how long will the core gateways survive technically, and how can the technical problems be resolved (Domain-severs for IP routing, anyone ?) ? - if ARPAnet were gone tomorrow, would anyone miss it ? (the current net is no longer a "research net" but a production network; the days when you could take the network down for a day to test a new routing algorithm are long gone). The issues in the net today are engineering problems, not research problems. - if we could provide giga-bit links, could anyone think of something useful to do with them, other than slice them into smaller pieces ? Discussions are underway about merging the various research networks into a new joint administration, encompassing DARPA, NASA, NSF etc. It is hoped that this can raise 20 million dollars of new funding. - - - Next year, it would be interesting to have three different sessions: - one like this one - one for TCP-IP readers - and the INFO-VAX one. / Lars Poulsen Advanced Computer Communications ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D16-Dec-85.22:32:59.CERF] <1985121617320000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CERF@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Christmas Thoughts Message-ID: <[USC-ISI.ARPA]16-Dec-85.22:32:59.CERF> Date: Mon, 16-Dec-85 22:32:00 EST Article-I.D.: <[USC-ISI.ARPA]16-Dec-85.22:32:59.CERF> Posted: Mon Dec 16 22:32:00 1985 Date-Received: Wed, 18-Dec-85 00:12:57 EST Sender: serge@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 48 Approved: tcp-ip@sri-nic.arpa 'Twas the Night Before Start-up 'Twas the night before start-up and all through the net, not a packet was moving; no bit nor octet. The engineers rattled their cards in despair, hoping a bad chip would blow with a flare. The salesmen were nestled all snug in their beds, while visions of data nets danced in their heads. And I with my datascope tracings and dumps prepared for some pretty bad bruises and lumps. When out in the hall there arose such a clatter, I sprang from my desk to see what was the matter. There stood at the threshold with PC in tow, An ARPANET hacker, all ready to go. I could see from the creases that covered his brow, he'd conquer the crisis confronting him now. More rapid than eagles, he checked each alarm and scrutinized each for its potential harm. On LAPB, on OSI, X.25! TCP, SNA, V.35! His eyes were afire with the strength of his gaze; no bug could hide long; not for hours or days. A wink of his eye and a twitch of his head, soon gave me to know I had little to dread. He spoke not a word, but went straight to his work, fixing a net that had gone plumb berserk; And laying a finger on one suspect line, he entered a patch and the net came up fine! The packets flowed neatly and protocols matched; the hosts interfaced and shift-registers latched. He tested the system from Gateway to PAD; not one bit was dropped; no checksum was bad. At last he was finished and wearily sighed and turned to explain why the system had died. I twisted my fingers and counted to ten; an off-by-one index had done it again... -Vint Cerf December 1985 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512171923.AA01763%40ucbvax.berkeley.edu] <1985121700410000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Vshank@WEIZMANN.BITNET (Henry Nussbacher) Newsgroups: mod.protocols.tcp-ip Subject: New disussion forum Message-ID: <8512171923.AA01763@ucbvax.berkeley.edu> Date: Tue, 17-Dec-85 05:41:00 EST Article-I.D.: ucbvax.8512171923.AA01763 Posted: Tue Dec 17 05:41:00 1985 Date-Received: Wed, 18-Dec-85 00:52:30 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa This is to announce a new discussion forum group: Ibm-Nets. Anything relating to IBM mainframes and networking is valid for this discussion group. Examples: Tcp/Ip and VM or MVS Wisconson Wiscnet Spartacus Knet X.25 Ethernet Pronet SNA Vnet Bitnet NJE protocols or anything else that is related to IBM mainframes and networking. To subscribe to this list send mail to: Bitnet: Info@Bitnic Internet: Info%Bitnic.Bitnet@Wiscvm.Wisc.Edu Please specify that you wish to be subscribed/unsubscribed to Ibm-Nets. To send contributions to this list (it is an immediate redistribution list with no filtering or digesting), send mail to: Bitnet: Ibm-Nets@Bitnic Internet: Ibm-Nets%Bitnic.Bitnet@Wiscvm.Wisc.Edu Coordinator: Henry Nussbacher (Hank@Bitnic or Hank%Bitnic.Bitnet@Wiscvm.Wisc.Edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512171925.AA13339%40merlin.Purdue.EDU] <1985121709250400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: narten@PURDUE.EDU ("Thomas Narten") Newsgroups: mod.protocols.tcp-ip Subject: wanted: TCP retransmission timer calculation info Message-ID: <8512171925.AA13339@merlin.Purdue.EDU> Date: Tue, 17-Dec-85 14:25:04 EST Article-I.D.: merlin.8512171925.AA13339 Posted: Tue Dec 17 14:25:04 1985 Date-Received: Thu, 19-Dec-85 05:33:49 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa I am doing some work with TCP running on slow speed (9600 baud) full duplex lines. Hosts may be directly connected, or be separated by several hops. Measurements show round trip times exceeding 4-5 seconds. Throughput is severely degraded, due to TCP retransmissions. I am looking for algorithms (and references to them) for computing retransmission timer values. I have had no luck so far in finding references to any. Can someone point me to references for the one used under 4.2 UNIX or any other system? Please respond by mail, as I am not on this mailing list (yet). Thanks, Thomas Narten narten@purdue.EDU ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512200446.AA09163%40ucbvax.berkeley.edu] <1985121709374900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mckenzie@BBNH.ARPA (Alex McKenzie) Newsgroups: mod.protocols.tcp-ip Subject: Re: ARPAnet Users' Forum at DECUS Message-ID: <8512200446.AA09163@ucbvax.berkeley.edu> Date: Tue, 17-Dec-85 14:37:49 EST Article-I.D.: ucbvax.8512200446.AA09163 Posted: Tue Dec 17 14:37:49 1985 Date-Received: Sat, 21-Dec-85 00:18:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I don't know when it was true that "you could take the network down for a day to test a new routing algorithm," but it certainly wasn't true by 1972, when I became responsible for Network Operations. It was true that we had a 2-hour/week time slot reserved for testing, but the users in those days would never have accepted a one-day outage. Alex McKenzie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121709374901> Received: from bbnh by SRI-NIC.ARPA with TCP; Tue 17 Dec 85 11:47:54-PST Date: Tue, 17 Dec 85 14:37:49 EST From: Alex McKenzie Subject: Re: ARPAnet Users' Forum at DECUS In-Reply-To: Your message of 16 Dec 85 15:31:00 PST To: Cc: "tcp-ip" I don't know when it was true that "you could take the network down for a day to test a new routing algorithm," but it certainly wasn't true by 1972, when I became responsible for Network Operations. It was true that we had a 2-hour/week time slot reserved for testing, but the users in those days would never have accepted a one-day outage. Alex McKenzie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121711283800> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 17 Dec 85 19:27:47-PST Date: 17 Dec 1985 19:28:38 PST From: POSTEL@USC-ISIB.ARPA Subject: re: retransmission time out calculations To: tcp-ip@SRI-NIC.ARPA Thomas Narten: Try page 41 of RFC-793, and RFC-813. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121716110000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Tue 17 Dec 85 09:38:35-PST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.WISC.EDU on 12/17/85 at 04:40:58 CST Return-path: VSHANK@WEIZMANN.BITNET Received: by WEIZMANN (Mailer X1.20) id 2509; Tue, 17 Dec 85 12:42:02 O Date: Tue, 17 Dec 1985 12:41 O From: Henry Nussbacher Subject: New disussion forum To: This is to announce a new discussion forum group: Ibm-Nets. Anything relating to IBM mainframes and networking is valid for this discussion group. Examples: Tcp/Ip and VM or MVS Wisconson Wiscnet Spartacus Knet X.25 Ethernet Pronet SNA Vnet Bitnet NJE protocols or anything else that is related to IBM mainframes and networking. To subscribe to this list send mail to: Bitnet: Info@Bitnic Internet: Info%Bitnic.Bitnet@Wiscvm.Wisc.Edu Please specify that you wish to be subscribed/unsubscribed to Ibm-Nets. To send contributions to this list (it is an immediate redistribution list with no filtering or digesting), send mail to: Bitnet: Ibm-Nets@Bitnic Internet: Ibm-Nets%Bitnic.Bitnet@Wiscvm.Wisc.Edu Coordinator: Henry Nussbacher (Hank@Bitnic or Hank%Bitnic.Bitnet@Wiscvm.Wisc.Edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512181444.AA26033%40ucbvax.berkeley.edu] <1985121717283800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: POSTEL@USC-ISIB.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: retransmission time out calculations Message-ID: <8512181444.AA26033@ucbvax.berkeley.edu> Date: Tue, 17-Dec-85 22:28:38 EST Article-I.D.: ucbvax.8512181444.AA26033 Posted: Tue Dec 17 22:28:38 1985 Date-Received: Thu, 19-Dec-85 05:33:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Thomas Narten: Try page 41 of RFC-793, and RFC-813. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121723370000> Received: from ucbvax.berkeley.edu by SRI-NIC.ARPA with TCP; Thu 19 Dec 85 02:33:03-PST Received: by ucbvax.berkeley.edu (5.31/1.7) id AA13930; Thu, 19 Dec 85 00:19:01 PST From: decwrl!pyramid!nsc!csi!ggere@ucbvax.berkeley.edu Received: by decwrl.DEC.COM (4.22.01/4.7.34) id AA09882; Wed, 18 Dec 85 20:36:48 pst Received: by pyramid (4.12/3.14) id AA01860; Wed, 18 Dec 85 18:36:27 pst Received: by nsc.UUCP (4.12/4.7) id AA01477; Wed, 18 Dec 85 07:40:01 pst Message-Id: <8512181540.AA01477@nsc.UUCP> Date: Wednesday, 18 Dec 1985 07:37-PST To: nsc!tcp-ip To: nsc!pyramid!decwrl!ucbvax!tcp-ip Subject: Re: New disussion forum Newsgroups: mod.protocols.tcp-ip In-Reply-To: <8512171923.AA01763@ucbvax.berkeley.edu> Organization: Communications Solutions Inc. 992 S.Saratoga-Sunnyvale Rd, San Jose, CA 95129 Cc: -------- Hi: I wish to subscribe to the ibm-net discussion group. Since I am not on the BITNET or INTERNET, I am replying directly to the soliciting message. =============================================================================== Communications Solutions 992 S. Saratoga-Sunnyvale Road San Jose, Calif 95129 Gary M. Gere {bnrmtv,fortune,unisoft,nsc,dual}!csi!ggere 4087251568 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512181741.AA28349%40ucbvax.berkeley.edu] <1985121804550000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Vshank@WEIZMANN.BITNET (Henry Nussbacher) Newsgroups: mod.protocols.tcp-ip Subject: Ibm-nets revision Message-ID: <8512181741.AA28349@ucbvax.berkeley.edu> Date: Wed, 18-Dec-85 09:55:00 EST Article-I.D.: ucbvax.8512181741.AA28349 Posted: Wed Dec 18 09:55:00 1985 Date-Received: Thu, 19-Dec-85 05:34:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa If you haven't subscribed yet but intend to do not send your request to Info@Bitnic.Bitnet but rather to Hank@Bitnic.Bitnet. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851218122218.7.DCP%40NEPONSET.SCRC.Symbolics.COM] <1985121807220000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: DCP@SCRC-QUABBIN.ARPA (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: wanted: TCP retransmission timer calculation info Message-ID: <851218122218.7.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 18-Dec-85 12:22:00 EST Article-I.D.: NEPONSET.851218122218.7.DCP Posted: Wed Dec 18 12:22:00 1985 Date-Received: Sat, 21-Dec-85 01:31:23 EST References: <8512171925.AA13339@merlin.Purdue.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa Date: 17 Dec 85 14:25:04 EST (Tue) From: "Thomas Narten" I am doing some work with TCP running on slow speed (9600 baud) full duplex lines. Hosts may be directly connected, or be separated by several hops. Measurements show round trip times exceeding 4-5 seconds. Throughput is severely degraded, due to TCP retransmissions. I am looking for algorithms (and references to them) for computing retransmission timer values. I have had no luck so far in finding references to any. Can someone point me to references for the one used under 4.2 UNIX or any other system? Please respond by mail, as I am not on this mailing list (yet). Thanks, Thomas Narten narten@purdue.EDU I'll repeat something I've claimed for 2 years: The simple adapative retransmission algorithms (one of which I think is actually in the TCP spec) are all meta-stable. If you start retransmitting too fast, you will continue to retransmit too fast and you will actually start going faster. If you retransmit too slow, you will start retransmitting slower. I suggest NOT looking at the Unix code. (Aside from strong personal biases against Unix...) As I recall from experience, Unix does well over fast links, but on slow links it isn't bad; it is pessimal. It tries to adapt but loses until it bottoms out at a retransmission interval of 10 seconds. Even if the link becomes instantaneous, Unix will never notice. Segue into JNC describing research at MIT regarding non-simple adaptive retransmission algorithms that may work... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512200544.AA10273%40ucbvax.berkeley.edu] <1985121808383700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: retransmission time out calculations Message-ID: <8512200544.AA10273@ucbvax.berkeley.edu> Date: Wed, 18-Dec-85 13:38:37 EST Article-I.D.: ucbvax.8512200544.AA10273 Posted: Wed Dec 18 13:38:37 1985 Date-Received: Sat, 21-Dec-85 00:19:11 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa In response to the message sent 17 Dec 1985 19:28:38 PST from POSTEL@USC-ISIB.ARPA Thomas, See also page 10 et seq of RFC-889 for refinements to the algorithm. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512200633.AA11025%40ucbvax.berkeley.edu] <1985121810430700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: kjl@BBN-CLXX.ARPA (Ken Lebowitz) Newsgroups: mod.protocols.tcp-ip Subject: off-board TCP/IP processors Message-ID: <8512200633.AA11025@ucbvax.berkeley.edu> Date: Wed, 18-Dec-85 15:43:07 EST Article-I.D.: ucbvax.8512200633.AA11025 Posted: Wed Dec 18 15:43:07 1985 Date-Received: Sat, 21-Dec-85 00:18:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa [I don't know if anyone has previously asked for this but I'll try anyway] Has somebody ever compared the performance of the various off-board TCP/IP processors available for the multibus (Excelan, CMC, Interlan...)? Actually, I'm interested in any experience(s) that people have had with these devices (good, bad or whatever). Please direct your replies to me since I'm not a member of the TCP-IP mailing list. Many thanks, Ken Lebowitz BBN Laboratories Cambridge, MA ARPA: kjl@bbn-clxx.arpa CSNET: kjl%bbn-clxx.arpa@csnet-relay UUCP: ...!{ihnp4,decvax}!bbncca!kjl DOMAIN: kjl@clxx.bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121810430701> Received: from bbn-clxx.arpa by SRI-NIC.ARPA with TCP; Wed 18 Dec 85 12:55:08-PST Date: Wed, 18 Dec 85 15:43:07 EST From: Ken Lebowitz Subject: off-board TCP/IP processors To: tcp-ip@nic [I don't know if anyone has previously asked for this but I'll try anyway] Has somebody ever compared the performance of the various off-board TCP/IP processors available for the multibus (Excelan, CMC, Interlan...)? Actually, I'm interested in any experience(s) that people have had with these devices (good, bad or whatever). Please direct your replies to me since I'm not a member of the TCP-IP mailing list. Many thanks, Ken Lebowitz BBN Laboratories Cambridge, MA ARPA: kjl@bbn-clxx.arpa CSNET: kjl%bbn-clxx.arpa@csnet-relay UUCP: ...!{ihnp4,decvax}!bbncca!kjl DOMAIN: kjl@clxx.bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121811230700> Received: from gyre.umd.edu by SRI-NIC.ARPA with TCP; Thu 19 Dec 85 02:49:05-PST Received: by gyre.umd.edu (5.9/4.7) id AA00767; Wed, 18 Dec 85 16:23:07 EST Date: Wed, 18 Dec 85 16:23:07 EST From: Chris Torek Message-Id: <8512182123.AA00767@gyre.umd.edu> To: narten@Purdue.EDU Subject: Re: wanted: TCP retransmission timer calculation info Cc: tcp-ip@sri-nic.ARPA You do not want to use the 4.2 retransmission timer algorithm. It throws out timing data that appears to be `too long'. The criterion for determining whether a packet has taken too long to be counted in retransmission delay adjustment is whether it has been retransmitted. Thus with a very slow link, *every* packet is retransmitted; and none are counted, so the time never gets adjusted. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121820250000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Wed 18 Dec 85 06:52:06-PST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.WISC.EDU on 12/18/85 at 08:54:18 CST Return-path: VSHANK@WEIZMANN.BITNET Received: by WEIZMANN (Mailer X1.20) id 2136; Wed, 18 Dec 85 16:55:50 O Date: Wed, 18 Dec 1985 16:55 O From: Henry Nussbacher Subject: Ibm-nets revision To: Ibm-nets revision If you haven't subscribed yet but intend to do not send your request to Info@Bitnic.Bitnet but rather to Hank@Bitnic.Bitnet. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121905592700> Received: from cit-vax.ARPA by SRI-NIC.ARPA with TCP; Thu 19 Dec 85 14:22:10-PST Received: from cit-vlsi.ARPA by cit-vax.ARPA id AA04285 at Thu, 19 Dec 85 14:06:38 pst Received: by cit-vlsi.ARPA (4.12/1.0) id AA11510; Thu, 19 Dec 85 13:59:27 pst Date: Thu, 19 Dec 85 13:59:27 pst From: michael@cit-vlsi.ARPA (Michael Lichter) Message-Id: <8512192159.AA11510@cit-vlsi.ARPA> To: tcp-ip@sri-nic.arpa Subject: excelan 3.1 Does anybody have a version of excelan 3.1 tcp/ip for Xenix on the iNTEL 286/310 patched so that it doesn't die continually with icmp-related panics? Thanks. Michael ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985121908480000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Thu 19 Dec 85 18:46:47-PST Date: 19 Dec 85 16:48:00 PST From: Subject: Corrigendum: ARPAnet Users' Forum at DECUS To: "tcp-ip" cc: info-vax@sri-kl,perry@ipto, lars Reply-To: I have received numerous notes pointing out errors in my submission about the ARPAnet user meeting at DECUS, and I hope the following note from Dr. Perry will serve to set the record straight. I hope my errors have not caused too many problems. / Lars Poulsen Advanced Computer Communications --------------------- Forwarded mail follows --------------------------- Date: Thu 19 Dec 85 08:40:59-EST From: Dennis G. Perry Subject: Re: Did I get it right ? To: lars@ACC.ARPA Lars, a few notes to help you out. I am from Los Alamos National Lab on exchange to DARPA. In DARPA I am a program manager in charge of most of the network programs, including the Arpanet. I am in the Information Processing Techniques Office of DARPA. Our office director is Dr. Saul Amarel, from Rutgers University. Some of my comments as I noted were designed to get some sort of feed back from attendees at the meeting and did not imply any actual activity to implement any of the discussion topics. In particular, I did not mean to imply that research is not warrented in the Arpanet, but that many of the issues that need to be resolved appear to be shorter term issues, along the lines of advanced engineering or short term research. To properly address the research issues, DARPA wants to look at much longer term issues, hence the interest in very high speed networking. The discussion about merging the various research networks is a little misleading. The idea here was to formalize the Arpa-Internet to provide a more active participation of its development by other agencies. The amount of money mentioned was pure speculation, since the discussions are very, very preliminary. Thanks for the opportunity to make a few comments, both here and at DECUS. dennis ------- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512200736.AA14673%40mouton.ARPA] <1985121921364200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: karn@MOUTON.ARPA (Phil R. Karn at mouton.ARPA) Newsgroups: mod.protocols.tcp-ip Subject: TCP retransmissions in 4.2BSD UNIX Message-ID: <8512200736.AA14673@mouton.ARPA> Date: Fri, 20-Dec-85 02:36:42 EST Article-I.D.: mouton.8512200736.AA14673 Posted: Fri Dec 20 02:36:42 1985 Date-Received: Sat, 21-Dec-85 01:28:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa I believe the behavior you describe is the fault of the 4.2BSD implementation, not the adaptive algorithm in RFC-793 (although it could be improved; see Mills' RFC-889 on Internet delay experiments). The version we had (which admittedly had been hacked extensively before we got it) restarted the round trip timer whenever a retransmission timeout occurred. If the retransmission is caused by a low RTT estimate rather than a dropped packet, resetting the timer causes it to measure the time between the second (or later) transmission attempt and the arrival of the first transmission's ack. Obviously this results in an erroneously low round trip estimate, thus perpetuating the problem. Since the initial RTT estimate was far too short to begin with (.5 sec), this guarantees lousy performance over a slow link, with little or no chance for adaptation. I've hacked our version to leave the round trip timer alone during retransmissions. This does compute an erroneously LONG estimate of RTT when the path is lossy, but since network congestion is probably the single biggest cause for dropped packets anyway it seems better to err in this direction. An initial estimate of 5 seconds seems to work well over our (very slow) X.25/CSNET connection to the Internet. I also highly recommend the Nagle tinygram-avoidance technique (RFC896). It makes a world of difference when running across slow links. Phil Karn ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BMC.LCS.MIT.EDU%5D.762099.851220.GJC] <1985122003264000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: GJC@MIT-MC.ARPA ("George J. Carrette") Newsgroups: mod.protocols.tcp-ip Subject: excelan 3.1 Message-ID: <[MC.LCS.MIT.EDU].762099.851220.GJC> Date: Fri, 20-Dec-85 08:26:40 EST Article-I.D.: <[MC.LCS.MIT.EDU].762099.851220.GJC> Posted: Fri Dec 20 08:26:40 1985 Date-Received: Sat, 21-Dec-85 10:46:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa I think you better go to version 3.2, since I never got 3.1 to do anything reasonable related to icmp. But what do you mean by patch? Actually patch the binary downloaded software? Could everybody using Excelan stuff send me a note so we could have a subdiscussion about related issues? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512221405.AA00473%40tut.uucp] <1985122214513800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Bridge CS/100 and 4.2BSD Message-ID: <8512221405.AA00473@tut.uucp> Date: Sun, 22-Dec-85 19:51:38 EST Article-I.D.: tut.8512221405.AA00473 Posted: Sun Dec 22 19:51:38 1985 Date-Received: Mon, 23-Dec-85 19:52:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa We are considering a Bridge CS/100 TCP/IP terminal server as an alternative for a regular Sun line multiplexer. It seems fine for terminals but what about lines attached to printers and dial-out modems? Is it possible to configure a 4.2bsd printer spooler and uucp so that the device (printer or auto-caller) is attached to CS/100? Generally, can the computer make a CS/100 line look like an ordinary (pseudo) terminal device? Juha Heinanen (jh@utacs.uucp or jh%utacs.uucp@seismo) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985122222014200> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Mon 23 Dec 85 06:07:27-PST Date: 23 Dec 1985 06:01:42 PST Sender: INTERMAIL@USC-ISIB.ARPA Subject: Network Christmas Carols From: "Vinton G. Cerf / MCI ID: 105-0002" To: TCP-IP@SRI-NIC.ARPA, Postel@USC-ISID.ARPA Date: Mon Dec 23, 1985 4:57 am PDT From: Vinton G. Cerf / MCI ID: 105-0002 TO: * Intermail / MCI ID: 107-8239 Subject: Network Christmas Carols Oh OSI, oh OSI (to the tune of O Tannenbaum) Oh OSI, oh OSI, Your rules are always changing. Oh OSI, oh OSI, Your rules are always changing. Each year you bring new protocols, More overhead and service calls. Oh OSI, oh OSI Your rules are always changing. Oh OSI, oh OSI, With seven layers burdened. Oh OSI, oh OSI, With seven layers burdened. Perhaps one day I'll live to see A multi-vendor community! Oh OSI, oh OSI, With endless promise laden. Oh OSI, oh OSI, Your rules are ever changing. Oh OSI, oh OSI, Your rules are ever changing. - Vint Cerf December 1985 -------------------------------------------------------------------- DEC the Halls DEC the halls with stuff from Reading! Fa la la la la, la la la la. Where the hell is DECNET heading? Fa la la la la, la la la la. IBM confuses matters. Fa la la, la la la, la, la, la. SNA is Chutes and Ladders! (tm) Fa la la la la, la, la, la, la. BBN is here to help me! Fa la la, la la la, la, la, la. Where's my gosh darn X.PC? [pronounced "X dot PC"] Fa la la la la, la, la, la, la. Never fear, here's eager HP! Fa la la la la, la la la la. Full of DS, linking lightly. Fa la la la la, la la la la. NT works in bits and snatches; Fa la la, la la la, la, la, la. Service data rarely matches! Fa la la la la, la, la, la, la. What a dizzy zoo before us! Fa la la la la, la la la la. Tune the net and join the chorus! Fa la la la la, la, la, la, la! - Vint Cerf December 1985 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985122301382700> Received: from SRI-KL.ARPA by SRI-NIC.ARPA with TCP; Mon 23 Dec 85 09:37:57-PST Date: Mon 23 Dec 85 09:38:27-PST From: NADIA@SRI-KL.ARPA Subject: ADDITION TO MAILING LIST To: TCP-IP@SRI-NIC.ARPA cc: HAMID@SRI-KL.ARPA PLEASE ADD HAMID TO YOUR MAILING LIST FOR TCP-IP GROUP. THANKS TAREK ABDEL-HAMID HAMID@SRI-KL ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512231433.AA17409%40ucbvax.berkeley.edu] <1985122304014200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: INTERMAIL@USC-ISIF.ARPA ("Vinton G. Cerf / MCI ID: 105-0002") Newsgroups: mod.protocols.tcp-ip Subject: Network Christmas Carols Message-ID: <8512231433.AA17409@ucbvax.berkeley.edu> Date: Mon, 23-Dec-85 09:01:42 EST Article-I.D.: ucbvax.8512231433.AA17409 Posted: Mon Dec 23 09:01:42 1985 Date-Received: Mon, 23-Dec-85 19:59:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 84 Approved: tcp-ip@sri-nic.arpa Date: Mon Dec 23, 1985 4:57 am PDT From: Vinton G. Cerf / MCI ID: 105-0002 TO: * Intermail / MCI ID: 107-8239 Subject: Network Christmas Carols Oh OSI, oh OSI (to the tune of O Tannenbaum) Oh OSI, oh OSI, Your rules are always changing. Oh OSI, oh OSI, Your rules are always changing. Each year you bring new protocols, More overhead and service calls. Oh OSI, oh OSI Your rules are always changing. Oh OSI, oh OSI, With seven layers burdened. Oh OSI, oh OSI, With seven layers burdened. Perhaps one day I'll live to see A multi-vendor community! Oh OSI, oh OSI, With endless promise laden. Oh OSI, oh OSI, Your rules are ever changing. Oh OSI, oh OSI, Your rules are ever changing. - Vint Cerf December 1985 -------------------------------------------------------------------- DEC the Halls DEC the halls with stuff from Reading! Fa la la la la, la la la la. Where the hell is DECNET heading? Fa la la la la, la la la la. IBM confuses matters. Fa la la, la la la, la, la, la. SNA is Chutes and Ladders! (tm) Fa la la la la, la, la, la, la. BBN is here to help me! Fa la la, la la la, la, la, la. Where's my gosh darn X.PC? [pronounced "X dot PC"] Fa la la la la, la, la, la, la. Never fear, here's eager HP! Fa la la la la, la la la la. Full of DS, linking lightly. Fa la la la la, la la la la. NT works in bits and snatches; Fa la la, la la la, la, la, la. Service data rarely matches! Fa la la la la, la, la, la, la. What a dizzy zoo before us! Fa la la la la, la la la la. Tune the net and join the chorus! Fa la la la la, la, la, la, la! - Vint Cerf December 1985 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512231839.AA21103%40ucbvax.berkeley.edu] <1985122307382700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: NADIA@SRI-KL.ARPA Newsgroups: mod.protocols.tcp-ip Subject: ADDITION TO MAILING LIST Message-ID: <8512231839.AA21103@ucbvax.berkeley.edu> Date: Mon, 23-Dec-85 12:38:27 EST Article-I.D.: ucbvax.8512231839.AA21103 Posted: Mon Dec 23 12:38:27 1985 Date-Received: Mon, 23-Dec-85 19:59:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa PLEASE ADD HAMID TO YOUR MAILING LIST FOR TCP-IP GROUP. THANKS TAREK ABDEL-HAMID HAMID@SRI-KL ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512231447.AA04360%40lognet2.ARPA] <1985122307470300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hassler@LOGNET2.ARPA (Barry D. Hassler) Newsgroups: mod.protocols.tcp-ip Subject: Addition to Mailing List Message-ID: <8512231447.AA04360@lognet2.ARPA> Date: Mon, 23-Dec-85 12:47:03 EST Article-I.D.: lognet2.8512231447.AA04360 Posted: Mon Dec 23 12:47:03 1985 Date-Received: Mon, 23-Dec-85 23:03:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Please add me to the mailing list for the TCP-IP group. Thanks. Barry D. Hassler hassler@lognet2 Systems Software Analyst Control Data Corp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985122319034900> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 24 Dec 85 03:10:48-PST Date: 24 Dec 1985 03:03:49 PST Sender: INTERMAIL@USC-ISIB.ARPA Subject: Revision of OSI Carol From: "Vinton G. Cerf / MCI ID: 105-0002" To: TCP-IP@SRI-NIC.ARPA, Postel@USC-ISID.ARPA Date: Tue Dec 24, 1985 3:46 am PDT From: Vinton G. Cerf / MCI ID: 105-0002 TO: * Intermail / MCI ID: 107-8239 Subject: Revision of OSI Carol I added some verses: Oh OSI, oh OSI (to the tune of O Tannenbaum) Oh OSI, oh OSI, Your rules are always changing. Oh OSI, oh OSI, Your rules are always changing. Each year you bring new protocols, More overhead and service calls. Oh OSI, oh OSI Your rules are always changing. Oh OSI, oh OSI, With seven layers burdened. Oh OSI, oh OSI, With seven layers burdened. No matter where I turn to look, There comes another colored book! Oh OSI, oh OSI, With variation, sagging! Oh OSI, oh OSI, The source of my frustration! Oh OSI, oh OSI, The source of my frustration! A plebescite in 92 Will split a layer into two; Oh OSI, oh OSI, Amoebic reproduction! Oh OSI, oh OSI, Eternally unfolding. Oh OSI, oh OSI, Eternally unfolding Oh, can the C C I T T and I S O at last agree On OSI, on OSI, The final net solution? Oh OSI, oh OSI, Ever in negotiation! Oh OSI, oh OSI, Ever in negotiation! Perhaps one day I'll live to see A multi-vendor community! Oh OSI, oh OSI, With endless promise laden. Oh OSI, oh OSI, Your rules are ever changing. Oh OSI, oh OSI, Your rules are ever changing. - Vint Cerf December 1985 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512241121.AA03271%40ucbvax.berkeley.edu] <1985122401034900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: INTERMAIL@USC-ISIF.ARPA ("Vinton G. Cerf / MCI ID: 105-0002") Newsgroups: mod.protocols.tcp-ip Subject: Revision of OSI Carol Message-ID: <8512241121.AA03271@ucbvax.berkeley.edu> Date: Tue, 24-Dec-85 06:03:49 EST Article-I.D.: ucbvax.8512241121.AA03271 Posted: Tue Dec 24 06:03:49 1985 Date-Received: Tue, 24-Dec-85 22:15:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 74 Approved: tcp-ip@sri-nic.arpa Date: Tue Dec 24, 1985 3:46 am PDT From: Vinton G. Cerf / MCI ID: 105-0002 TO: * Intermail / MCI ID: 107-8239 Subject: Revision of OSI Carol I added some verses: Oh OSI, oh OSI (to the tune of O Tannenbaum) Oh OSI, oh OSI, Your rules are always changing. Oh OSI, oh OSI, Your rules are always changing. Each year you bring new protocols, More overhead and service calls. Oh OSI, oh OSI Your rules are always changing. Oh OSI, oh OSI, With seven layers burdened. Oh OSI, oh OSI, With seven layers burdened. No matter where I turn to look, There comes another colored book! Oh OSI, oh OSI, With variation, sagging! Oh OSI, oh OSI, The source of my frustration! Oh OSI, oh OSI, The source of my frustration! A plebescite in 92 Will split a layer into two; Oh OSI, oh OSI, Amoebic reproduction! Oh OSI, oh OSI, Eternally unfolding. Oh OSI, oh OSI, Eternally unfolding Oh, can the C C I T T and I S O at last agree On OSI, on OSI, The final net solution? Oh OSI, oh OSI, Ever in negotiation! Oh OSI, oh OSI, Ever in negotiation! Perhaps one day I'll live to see A multi-vendor community! Oh OSI, oh OSI, With endless promise laden. Oh OSI, oh OSI, Your rules are ever changing. Oh OSI, oh OSI, Your rules are ever changing. - Vint Cerf December 1985 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512271533.AA29624%40a.ARPA] <1985122705331700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: dfs%a@LANL.ARPA (Don Shafer) Newsgroups: mod.protocols.tcp-ip Subject: Drop from Mailing List Message-ID: <8512271533.AA29624@a.ARPA> Date: Fri, 27-Dec-85 10:33:17 EST Article-I.D.: a.8512271533.AA29624 Posted: Fri Dec 27 10:33:17 1985 Date-Received: Fri, 27-Dec-85 18:47:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Please drop me from your mailing list. Thanks, dfs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512271728.AA10191%40cod.ARPA] <1985122707281800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: walker%cod@NOSC.ARPA (Janet M. Walker) Newsgroups: mod.protocols.tcp-ip Subject: Drop from Mailing List Message-ID: <8512271728.AA10191@cod.ARPA> Date: Fri, 27-Dec-85 12:28:18 EST Article-I.D.: cod.8512271728.AA10191 Posted: Fri Dec 27 12:28:18 1985 Date-Received: Fri, 27-Dec-85 18:41:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa Please drop me from your mailing list. Thanks, walker@nosc ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12170534883.17.G.ROODE%40SU-SCORE.ARPA] <1985122711445000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: G.ROODE@SU-SCORE.ARPA (David Roode) Newsgroups: mod.protocols.tcp-ip Subject: Re: Drop from Mailing List Message-ID: <12170534883.17.G.ROODE@SU-SCORE.ARPA> Date: Fri, 27-Dec-85 16:44:50 EST Article-I.D.: SU-SCORE.12170534883.17.G.ROODE Posted: Fri Dec 27 16:44:50 1985 Date-Received: Fri, 27-Dec-85 20:16:27 EST References: <8512271728.AA10191@cod.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Please send drop requests to TCP-IP-REQUEST@SRI-NIC.ARPA ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512290442.AA12458%40uw-beaver.arpa] <1985122814000400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ip fragmentation follies Message-ID: <8512290442.AA12458@uw-beaver.arpa> Date: Sat, 28-Dec-85 19:00:04 EST Article-I.D.: uw-beave.8512290442.AA12458 Posted: Sat Dec 28 19:00:04 1985 Date-Received: Tue, 7-Jan-86 01:39:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 55 Approved: tcp-ip@sri-nic.arpa I've been playing with IP fragmentation/reassembly and have discovered a major crock in the Berkeley way of doing things. This may have been noticed by someone before, but I hadn't really thought about it. What caused me to notice this was claims by some people (namely Sun) that using very large IP packets and using IP-level fragmentation makes protocols like NFS run faster. This makes some sense (less context-switching, etc), so we decided to try it. We quickly noticed a problem, though: if a fragmented packet has to be retransmitted (eg because one of the fragments was dropped somewhere) the fragments of the retransmitted packet are not and can not be merged with those of the original packet! Why? Because the Berkeley code has no notion of IP-level retransmission, and hence assigns a new IP-level packet identifier to each and every IP packet it transmits! And since the IP-level identifier is the only way the receiver can tell whether two fragments belong to the same packet, this means that the fragments of a retransmitted packet can never be combined with those of the original. What all this means in practice is this: for a fragmented IP packet to get through to its receiver, all the fragments resulting from a single transmission of that packet must get through. If a single fragment is lost, all the other fragments resulting from that transmission of the packet are useless and will never be recombined with fragments from past or future transmissions of the same packet. This all explains (or at least provides a partial explanation) for why people running 4.2 TCP connections across the Arpanet using 1024-byte packets were losing so badly. If the probability of fragment lossage is even moderately high, it will often take three or more tries to get a fragmented packet across the net. Meanwhile, of course, the useless fragments from previous transmissions are sitting on reassembly queues in the receiver (for 15 seconds, I think?), tying up buffering resources and increasing the chances that fragments will be dropped in the future! In the current Berkeley code, it's possible to imagine workarounds for this problem for TCP: because TCP is in the kernel, it could have a side hook into the IP layer to tell it "this packet is a retransmission, don't give it a new IP identifier". For protocols like UDP, however, the acknowledgment and retransmission functions are done outside of the kernel, and the only kernel interface that's available is Berkeley's socket calls (sendto, recvfrom, etc). Needless to say, the socket interface gives you 1) no way to find out what IP identifier a packet was sent with; 2) No way to specify the IP identifier to use on an outgoing packet. I don't really have any idea what to do about this problem. And, it's not entirely Berkeley's fault; the BBN TCP/IP for 4.1bsd did the same thing... In any case, until there's a fix I don't think using IP fragmentation/reassembly when talking to 4.2bsd systems is a very good idea. -Larry ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851229144542.2.GREENWALD%40SWALLOW.SCRC.Symbolics.COM] <1985122909450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Greenwald@SCRC-STONY-BROOK.ARPA (Michael Greenwald) Newsgroups: mod.protocols.tcp-ip Subject: ip fragmentation follies Message-ID: <851229144542.2.GREENWALD@SWALLOW.SCRC.Symbolics.COM> Date: Sun, 29-Dec-85 14:45:00 EST Article-I.D.: SWALLOW.851229144542.2.GREENWALD Posted: Sun Dec 29 14:45:00 1985 Date-Received: Wed, 8-Jan-86 01:59:23 EST References: <8512290442.AA12446@uw-beaver.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Yeah, it's been noticed. I thought Dave had even commented on it in his "implementation notes", but I can't find my copies, so I didn't check it up. I noticed this in multics (it hadn't actually happened, but if you remember I was trying to decide when you'd rather have *large* ip packets, and when you'd rather restrict ip packets to the max network size. IP reassembly was cheaper than TCP reassembly. (fewer packet headers to process.) I thought the only drawback was that in case of a lost fragment, you had to retransmit the entire packet, but when I thought about it, I made the same realization that you did.) My (minimal) solution is mentioned below. My multics code had foo$retransmit_packet, foo$forward_packet, and foo$send_packet for each datagram protocol named "foo". (IP, UDP, GGP, and ICMP, as far as I can remember.) Not only did it keep the same ID, but it eliminated a certain category of error checking and checksum generation, where possible. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512311002.AA08758%40ngp.UTEXAS.EDU] <1985123012145600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: New disussion forum Message-ID: <8512311002.AA08758@ngp.UTEXAS.EDU> Date: Mon, 30-Dec-85 17:14:56 EST Article-I.D.: ngp.8512311002.AA08758 Posted: Mon Dec 30 17:14:56 1985 Date-Received: Wed, 1-Jan-86 23:35:25 EST References: <8512171923.AA01763@ucbvax.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa I wish to describe to the IBM-nets discussion but I am not sure how to reply. Tom Webb at Shell ----MESSAGE-END----