----MESSAGE-BEGIN---- <1985040102183500> Received: from USC-ISIF.ARPA by SRI-NIC.ARPA with TCP; Mon 1 Apr 85 10:20:57-PST Date: 1 Apr 1985 10:18:35 PST From: SUNSHINE@USC-ISIF.ARPA Subject: Reply to some NRC report flamers To: tcp-ip@SRI-NIC.ARPA cc: sunshine@USC-ISIF.ARPA I would like to reply to just a few of the most outrageous statments appearing in this bulletin board on the recently released National Research Council report on use of ISO protocols by DOD. First, to get my background up front, I was a member of the committee. For the past two years I have been with private industry in a small company (Sytek) that makes broadband local network equipment. Prior to that I spent three years at ISI, 4 years at Rand, and several years at Stanford with Vint Cerf, all working on the Arpa Internet, and helping desing TCP and IP, so I am probably considered biased toward DoD protocols. Provan at LLL-MFE asks "who are these people ... I don't recognize a single name as having practical knowledge of the Internet" I have already given my credentials. Other committee members were Larry Landweber of U. Wisconsin, a founder of CSNET, and Dave Farber of U. Delaware, a longtime user and contributor to internet. We were also advised by Jon Postel, Ed Cain, Phil Selvaggi, Col John Lane, and many others in DoD. I am sorry if Provan does not recognize any of these names. Provan also accuses ISO of ignoring the good work done in the Internet community. There are many complexities to this question, but part of the problem has been the Internet community's lack of enthusiasm to contribute and "sell" its work to ISO. Nonetheless, many of the ideas have indeed found there way. The best example is the ISO connectionless internet protocol which is nearly identical to the Internet IP. The clss 4 TP is another example. there are format and some mechanism differences dictated by need for consistency with other standards, later wisdome and experience, etc. (the DoD protocols are not perfect!) Bellcore!karn@umd5 asks "has anyone sat down and written a detaile, technical, side-by-side comparison of TP-4 vs TCP?" I can only conclude he has never seen the NRC report, since Chapter III is precisely that. Provan in his first note (22 March) asks if "someone could give him any good arguments for adopting TP-4 ...", and Postel seems toi whimsically echo this point. If the protocols are similar functionally, why indeed make any change? The main reason is the long term benefits to be obtained by using commercial standards that are widely supported by vendors in off-the-shelf equipment. Let me emphasize the long term phrase. No one is suggesting DoD throw out existing implementations of DoD protocols. We ARE suggesting that in future procurments for new systems and to replace or upgrade current systems, that equipment with the ISO standard protocols should be consdiered if there are indeed commercial implementations available. Gradually over the life cycle of DoD systems, there would be an adoption of standard equipment. To summarize the expected benefits of using standard protocols, I can best quote from the report's summary: "Costs to the DoD for development, production, and maintenance are significantly lower becaue (1) vendors spread the cost over a much larger user base, (2) commercial vendors are generally more efficient in their operations, and (3) vendors look for ways to improve their roduct to meet competition. The DoD generally gets more effective products because vendors integrate the protocol functions into their entire software and hardware line. Thus DoD may be able eventually to use commercial software products that are built on top of, and thereby take advantage of, the transport protocols. By depending on industry to manage the development and maintenance of products, the department can use its scarce management and technical resources on activities unique to its mission." Only time will tell whether the committee's expectations about vendor adoption of the ISo standard protocols will be true. To me, things do seem to be moving in that direction. DoD contractors need not feel threatened by this: there will still be plenty of pioneering work to do in advanced areas, or those unique to the military, to keep the research dollars flowing to the MITs, ISI,s, BBN's, Mitre's, and all the vendor Federal Systems Divisions now living comfortably on the DoD special system procurement and research system. I don't think that it is asking too much to let the areas that are pretty well understood, and that the commercial vendors seem eager to take over, pass on to other hands in the fullness of time. If you have questions on other parts of the report (after reading it, of course), I am willing to accept BRIEF phone calls. No net mail please. Carl Sunshine ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040103252100> Received: from USC-ISIF.ARPA by SRI-NIC.ARPA with TCP; Mon 1 Apr 85 11:27:10-PST Date: 1 Apr 1985 11:25:21 PST From: POSTEL@USC-ISIF.ARPA Subject: re: domain conversion To: TCP-IP@SRI-NIC.ARPA One can start using domain style names anytime after the following three conditions are met: (1) It is after 15=jan-85 (2) The domain style name has been registered with the NIC. That is the NIC has sent you back a notice saying it is ok to use the name you applied for. (3) The name is listed in the databases of some (i.e., more than one) domain name server. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040104060000> Received: from ACC.ARPA by SRI-NIC.ARPA with TCP; Mon 1 Apr 85 12:19:24-PST Date: 1 Apr 1985 12:06 PST From: Art Berggreen Subject: Common Carrier T1 To: TELECOM@BBNCCA Cc: TCP-IP@SRI-NIC Reply-To: ART@ACC I have been trying to get a handle on the bit stream framing requirements for using common carrier T1 circuits (DS1). There seems to be a feeling that, at least, 193 bit framing must be followed. My conversations with various people (including people inside various ATT companies and BELLCORE) lead me to the conclusion that the 193 bit framing has no technical basis and was rather a convention that ATT wanted to enforce before divestiture. Since divestiture, it appears possible to utilize common carrier T1 service without regard to framing (the ones density requirement will always be there). Any one have DEFINITE information to the contrary? Art Berggreen ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040109390200> Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Mon 1 Apr 85 11:47:15-PST Date: Mon, 1 Apr 85 14:39:02 EST From: Ron Natalie To: SUNSHINE@USC-ISIF.ARPA cc: tcp-ip@SRI-NIC.ARPA, sunshine@USC-ISIF.ARPA Subject: Re: Reply to some NRC report flamers > No one is suggesting DoD throw out existing implementations of DoD > protocols. We ARE suggesting that in future procurments for new systems > and to replace or upgrade current systems, that equipment with the ISO > standard protocols should be consdiered if there are indeed commercial > implementations available. Gradually over the life cycle of DoD systems, > there would be an adoption of standard equipment. But there's the rub isn't it. I must still specify the DOD protocols for all new systems because they must interface not only to the over 40 systems here but to the already TCP/IP interconnected MILNET. For the REAL long term, I agree with Noel, by the time TCP/IP is ready to be phased over to a something else, a new set of protocols, ISO or otherwise, will probably be the target. I think TP4 is a dead end proposition as far as DOD goes. > The DoD generally gets more effective products because vendors > integrate the protocol functions into their entire software and hardware > line. Thus DoD may be able eventually to use commercial software > products that are built on top of, and thereby take > advantage of, the transport protocols. Then we aren't talking TP4 here are we? If TP4 is so much the same as TCP, then the higher network levels ought to be the same. Even now there is a move to switch to the ISO protocols for mail. > No net mail please. I'm always skeptical about people who claim to be experts about a system and don't use it. It's sort of like a aviation instructor who never goes flying. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040203330800> Received: from USC-ISIF.ARPA by SRI-NIC.ARPA with TCP; Tue 2 Apr 85 11:46:19-PST Date: 2 Apr 1985 11:33:08 PST From: POSTEL@USC-ISIF.ARPA Subject: re: domain name resolvers To: tcp-ip@SRI-NIC.ARPA Anyone working on an implementation of the domain name system or interested in knowing the details that differ from the protocol described in RFCs 882 and 883 should contact Paul Mockapetris (MOCKAPETRIS@USC-ISIF.ARPA). --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040211460000> Received: from CMU-CS-A.ARPA by SRI-NIC.ARPA with TCP; Tue 2 Apr 85 13:48:02-PST Date: 2 Apr 85 16:46 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: POSTEL@USC-ISIF.ARPA Subject: Re: domain name resolvers CC: tcp-ip@SRI-NIC.ARPA In-Reply-To: "POSTEL@USC-ISIF.ARPA's message of 2 Apr 85 14:33-EST" Message-Id: <02Apr85.164626.EN0C@CMU-CS-A.ARPA> It would be a significant improvement if a document was written or the current one corrected instead of querying someone and piecing together the details from a few discussion files. It makes it hard to hand to a programmer and tell 'em to implement it. There are still significant bugs in the current TOPS-20 domain service. - SRI-NIC still sends UDP replies from a different address then it received it on. - Significant response delays and the first packet is dropped. - Asking for weird pieces of information like HINFO (to improve interactions by FTP) gets no information back other then the QNAME header. Clarification problems with the domain specification: - Given an address (128.5.6.7), how do you get the name in a heavily distributed domain enviroment? - Given a host name alias ("A" or "A.BC"), what is the correct procedure for resolving the name? What about the traling "." business? I am interested in a smooth transition from the current mechanisms to the domain based mechanisms. I assume SRI-NIC will be critical component and I find the server has certain bugs and the domain specification is missing certain clarifications that prevent such a smooth transition. Major modifications seem to be required for software and significant education costs for the users (4000+ people). The domain system is definitely a solution and has most of the problems solved but it seems to lean toward a general network database with everything in it...Too much too soon... -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040300373700> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 3 Apr 85 08:41:22-PST Date: 3 Apr 1985 08:37:37 PST Subject: Re: Common Carrier T1 From: COHEN@USC-ISIB.ARPA To: ART@ACC.ARPA cc: TELECOM@BBNCCA.ARPA, TCP-IP@SRI-NIC.ARPA, Cohen@USC-ISIB.ARPA In-Reply-To: (Message from "Art Berggreen " of 1 Apr 1985 12:06 PST) Art, I have to admit it: I nearly fell for it, until I noticed the date of your message. Really one of the cleverest and most subtle April-fools messages!!! Danny. P.S., In the remote case that this is a genuine inquiry: There is a LOT to the technical requirement for T1-framing. There are STRICT rules for the 193rd bit -- without it all the equipment of the carrier will indicate errors and would send warning messages to their NCC's which probably will result in discontinuing your service, unless special costly arrangements are made around it. There also others rules like the good old "no-consecutive-16-zeroes" and "at-least-3-ones-in-any-sequence-of-24-bits", and more. Some of these rules are no longer mandatory in Europe, and within N years they will not be needed here either, hopefully for a small N. The 193rd-bit will be in for LONG time. I bet. [] ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040305404800> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Tue 2 Apr 85 21:58:49-PST Received: FROM DCN6 BY USC-ISID.ARPA WITH TCP ; 3 Apr 85 00:57:29 EST Date: 03-Apr-85 05:40:48-UT From: mills@dcn6 Subject: Another domain-name server To: tcp-ip@nic Folks, A bared-bones domain-name server is up on several fuzzballs, including DCN1 (128.4.0.1). It does nothing fancy and is driven directly from a hash of the NIC HOSTS.TXT file. For convenience, it does an invert-thing if you give it an address in nn.nn.nn.nn format. It is not intended as a general-access service, but you may find it useful in testing. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040305450000> Received: from isi-vaxa.ARPA ([128.9.0.33]) by SRI-NIC.ARPA with TCP; Wed 3 Apr 85 13:43:25-PST Received: by isi-vaxa.ARPA (4.12/4.7) id AA17375; Wed, 3 Apr 85 13:45:49 pst From: holg@isi-vaxa Message-Id: <8504032145.AA17375@isi-vaxa.ARPA> Date: 3 Apr 1985 1345-PST (Wednesday) To: tcp-ip@nic Subject: Re: TCP vs TP4 By the way, some interesting comments on this controversy can be found in THE ELEMENTS OF NETWORKING STYLE, M. A. Padlipsky, Prentice-Hall, ISBN 0-13-2681129-3. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040306014600> Received: from sri-lanka.ARPA by SRI-NIC.ARPA with TCP; Wed 3 Apr 85 14:08:29-PST Received: by sri-lanka.ARPA at Wed, 3 Apr 85 14:01:46 pst Date: Wed, 3 Apr 85 14:01:46 pst From: E. Howard Alt Message-Id: <8504032201.AA00820@sri-lanka.ARPA> To: tcp-ip@nic Subject: rsx-11m tcp/ip Does anyone have TCP/IP for RSX-11? Howard. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040901470000> Received: from SU-AI.ARPA by SRI-NIC.ARPA with TCP; Tue 9 Apr 85 09:47:38-PST Date: 09 Apr 85 0947 PST From: Joe Weening Subject: Network printing protocols To: TCP-IP@SRI-NIC.ARPA Has anyone thought about a TCP-based protocol for sending files to printers accessed via the network? Right now the only facility I know about is that some printers take TCP connections on port 35 (the well-known port for "any printer server"), but the protocol depends on the specific printer, which seems like a bad idea. I'm looking for a general protocol that has the following features: > User identification and authentication > Indication of the format of the file being printed (e.g., text, Press, ImPress, DVI, etc.) > Options meaningful for any printer (number of copies, etc.) > Other options specific to the particular printer (fonts, page size and orientation, etc.) > Accounting information There are undoubtedly other necessary things that I haven't thought of. If such a protocol already exists, I'd be glad to hear about it. (I don't think there are any RFC's on it.) Otherwise, someone with the time and experience to do this could put together an RFC. Joe Weening ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040907283900> Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Tue 9 Apr 85 15:50:48-PST Date: Tue 9 Apr 85 15:28:39-PST From: Joseph I. Pallas Subject: Re: Network printing protocols To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "Charles Hedrick " of Tue 9 Apr 85 14:54:17-PST Unix has a remote spooling system built into its spooler (LPD). There is currently an LPD implementation of sorts for TOPS-20. We are doing a VMS implementation of the half that queues and sends files (i.e. a user end but not a server end). Surely it is an oxymoron to speak of a second implementation of an undocumented protocol. joe ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040909541700> Received: from RUTGERS.ARPA by SRI-NIC.ARPA with TCP; Tue 9 Apr 85 11:53:11-PST Date: 9 Apr 85 14:54:17 EST From: Charles Hedrick Subject: Re: Network printing protocols To: JJW@SU-AI.ARPA cc: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "Joe Weening " of 9 Apr 85 12:47:00 EST Unix has a remote spooling system built into its spooler (LPD). There is currently an LPD implementation of sorts for TOPS-20. We are doing a VMS implementation of the half that queues and sends files (i.e. a user end but not a server end). ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985040922214200> Received: from CU20B.ARPA by SRI-NIC.ARPA with TCP; Wed 10 Apr 85 00:20:45-PST Date: Wed 10 Apr 85 03:21:42-EST From: Ken Rossman Subject: Re: Network printing protocols To: JJW@SU-AI.ARPA, TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "Joe Weening " of Tue 9 Apr 85 09:47:00-EST Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 We're looking at nearly the same problem right now with our printers. Our situation currently differs from yours, Joe, mostly in that each printer we want to get on the air is "owned" by a mainframe, rather than having its own hardware interface to the network. We're looking at a couple of possibilities: - Running a printer spooler based on a Unix printer spooler. We have TOPS-20 systems as well as Unix system here talking TCP/IP, so we will probably use a TOPS-20 implementation by Chris Maio of the CS department here for those systems (was that the TOPS-20 version someone mentioned earlier?). - Inventing a "dumb" protocol based on file transfer, with two different file types: 1) Files to be printed, and 2) Control files indicating what to do with the files to be printed. This, I understand, is similar to what the Unix printer protocol does, though we'll probably do it using FTP directly. We're doing it this way right now because we need print services soon between our IBM and DEC systems, and we run the WISCVM TCP package in IBM-land, and want to use the tools that are there already. It sure would be nice if a "real" general network printer protocol were designed, so we'd all have some guidelines to code around. I'd add one item to Joe's "wish list" for the protocol, though. Since we run more than one type of printer per system, just being able to "address" a printer by some network host name isn't enough. Printer unit information would be helpful -- we do this here now by breaking down the destination into two logical chunks: system and unit (in our case, the unit is a name, not just a number). Other device-specific and print-format-specific control information is also passed along. I suspect there are a few printer hardware manufacturers out there (Imagen comes to my mind initially) who are implementing network hardware interfaces to put their printers directly on something like an Ethernet. Anyone from this group care to toss out some thoughts concerning protocol? /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041003421800> Received: from UMD5.ARPA by SRI-NIC.ARPA with TCP; Wed 10 Apr 85 05:42:08-PST Received: by UMD5.ARPA (4.9/a/4.7) id AA02435; Wed, 10 Apr 85 08:42:18 EST Date: Wed, 10 Apr 85 08:42:18 EST From: louie@umd5 (Louis Mamakos) Message-Id: <8504101342.AA02435@UMD5.ARPA> Organization: Univ. of Maryland, Computer Science Center To: JJW@SU-AI.ARPA, TCP-IP@SRI-NIC.ARPA, sy.Ken@CU20B.ARPA Subject: Re: Network printing protocols We use the MDQS package here on our UNIX hosts. It can handle multiple queues and multiple devices, with a very flexable mapping between devices and queues. It also spools across the network to other hosts with MDQS servers, and has access lists to specifiy which internet hosts can spool to a queue. It is an extermely flexable package, and was developed at BRL. Maybe someone there will provide some information on how to obtain a copy; I think that is comes as part of their System V emulation on 4.2BSD distribution. We've done an MDQS implementation for our Sperry mahines, and in fact use the high-speed line printers on the Sperry machine as the line printer for a small PDP11 system. Worth looking into. Louis A. Mamakos WA3YMH University of Maryland, Computer Science Center Internet: louie@umd5.arpa UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041009324100> Received: from UTAH-20.ARPA by SRI-NIC.ARPA with TCP; Wed 10 Apr 85 15:32:40-PST Date: Wed 10 Apr 85 16:32:41-MST From: The alleged mind of Walt Subject: Re: Network printing protocols To: TCP-IP@SRI-NIC.ARPA I have written a Unix-style LPD server for TOPS-20 if anybody wants it, however no support is available. It was announced a while ago on TOPS-20. Regards -- Walt ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041014450300> Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Wed 10 Apr 85 23:06:21-PST Date: Wed, 10 Apr 85 19:45:03 EST From: Mike Muuss To: Joe Weening cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Network printing protocols BRL's MDQS (Multi-Device Queueing System) has a TCP-based exchange protocol that handles shuffling requests (print request, batch requests, etc) from machine to machine. Authentication and audit trail issues are addressed. For more information, contact Doug Kingston Best, -Mike Muuss (301)-278-6678 AV 283-6678 FTS 939-6678 ArpaNet: Mike @ BRL UUCP: ...!{decvax,cbosgd}!brl-bmd!mike Postal: Mike Muuss Leader, Advanced Computer Systems Team Computer Science and Mathematics Branch Systems Engineering and Concepts Analysis Division U.S. Army Ballistic Research Laboratory Attn: AMXBR-SECAD (Muuss) APG, MD 21005 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041016312000> Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Thu 11 Apr 85 00:16:45-PST Date: Wed, 10 Apr 85 21:31:20 EST From: Doug Kingston To: Louis Mamakos cc: JJW@SU-AI.ARPA, TCP-IP@SRI-NIC.ARPA, sy.Ken@CU20B.ARPA Subject: Re: Network printing protocols The Multi-Device Queuing System (MDQS) is developed and maintained by US Army Ballistics Research Lab. It is in the public domain and available for anonymous FTP from BRL-VGR.ARPA. The only restriction is that the software cannot be resold, though it may be included in other systems free of charge. Documentation and manual pages are included in the distribution. We normally run it under 4.2BSD but it will also run on vanilla System V machines and a few other less known UNIX systems. Cheers, -Doug- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041110572600> Received: from USC-ISIF.ARPA by SRI-NIC.ARPA with TCP; Thu 11 Apr 85 22:30:04-PST Date: 11 Apr 1985 18:57:26 PST From: MOCKAPETRIS@USC-ISIF.ARPA Subject: Re: domain name resolvers To: Rudy.Nedved@CMU-CS-A.ARPA, POSTEL@USC-ISIF.ARPA cc: tcp-ip@SRI-NIC.ARPA, MOCKAPETRIS@USC-ISIF.ARPA In response to the message sent 2 Apr 85 16:46 EST from Rudy.Nedved@CMU-CS-A.ARPA You make some good points: ------------------------------------------------------------- It would be a significant improvement if a document was written or the current one corrected instead of querying someone and piecing together the details from a few discussion files. It makes it hard to hand to a programmer and tell 'em to implement it. ***> I am preparing an updated set of RFCs. I sollicit your suggestions for improving the present documents. In the mean time, all of the changes you need to the spec are contained in two messages in [ISIF]domain.changes. There are still significant bugs in the current TOPS-20 domain service. - SRI-NIC still sends UDP replies from a different address then it received it on. **> A fix for this problem will be installed in the distribution sources and at the NIC. - Significant response delays and the first packet is dropped. **> The NIC is running a prior release of the domain software. The new version is significantly faster, and additional improvements are being implemented. - Asking for weird pieces of information like HINFO (to improve interactions by FTP) gets no information back other then the QNAME header. **> Part of this problem is a bug in the compression algorithm which has been found. The major part is that the NIC is using tables of data which are derived by an automatic translation of HOSTS.TXT. The data for ports, OS, CPU etc in HOSTS.TXT is more often incorrect or badly formatted than not. The NIC is working on generation of correct tables from their internal database. Clarification problems with the domain specification: - Given an address (128.5.6.7), how do you get the name in a heavily distributed domain enviroment? **> The IN-ADDR mechanism is described in the RFCs. - Given a host name alias ("A" or "A.BC"), what is the correct procedure for resolving the name? What about the traling "." business? **> The RFCs don't define a standard shorthand for "local" names or whatever. Internally it isn't an issue: the name service always uses full domain names, and the CNAME mechanism allows for aliases. Prior discussion of suitable printed names didn't seem to converge; there was opposition to the trailing dot. In the TOPS-20 JSYS code, the assumption is that the name is fully qualified and the trailling dot is omitted; this approach is closest to current names. I am interested in a smooth transition from the current mechanisms to the domain based mechanisms. I assume SRI-NIC will be critical component and I find the server has certain bugs and the domain specification is missing certain clarifications that prevent such a smooth transition. Major modifications seem to be required for software and significant education costs for the users (4000+ people). The domain system is definitely a solution and has most of the problems solved but it seems to lean toward a general network database with everything in it...Too much too soon... -Rudy **> The GTDOM JSYS was designed to allow a simple replacement of GTHST with GTDOM for host addresses. The master file, refreshing, and other features were aimed at allowing a incremental implementation. I agree that it is a big change, but I'm not sure that the trauma would be worthwhile for lesser goals. I have certainly heard a lot of arguments that it doesn't go far enough, and that dynamic update, authentication, etc. should have been in it. paul ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041200360000> Received: from nprdc.ARPA by SRI-NIC.ARPA with TCP; Fri 12 Apr 85 08:36:37-PST Received: by nprdc.ARPA (4.12/4.7) id AA17416; Fri, 12 Apr 85 08:36:57 pst Message-Id: <8504121636.AA17416@nprdc.ARPA> Date: 12 April 1985 0836-PST (Friday) From: stanonik@nprdc Reply-To: stanonik@NPRDC To: tcp-ip@sri-nic Subject: long delay connections Cc: stanonik@nprdc We've always had problems connecting to ucl-cs (we're in california, ucl-cs is in london). The symptoms bounce between "host unreachable", "connection timed out", and "connection refused". Mail in particular seems to queue for at least a day before getting through. Is this response/reliability typical? I've assumed so, because the connection must hop through several gateways, including a slow(?) and congested(?) link over/under(?) the atlantic. We're running 4.2bsd on a vax 780. Back in the 4.1bsd days, we were running bbn's tcp/ip, and had gotten some modifications to help with long delay connections. Has any tuning been done on 4.2bsd for long delay connections? Or is this response/ reliability the norm? How about sites running something other than 4.2bsd? Fuzzballs? Dec 10's, 20's? Thanks, Ron Stanonik stanonik@nprdc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041211093800> Received: from lbl-csam.ARPA by SRI-NIC.ARPA with TCP; Fri 12 Apr 85 19:09:11-PST Return-Path: Received: by lbl-csam.ARPA ; Fri, 12 Apr 85 19:09:47 pst To: stanonik@nprdc.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: long delay connections In-Reply-To: Your message of 12 April 1985 0836-PST (Friday). Date: 12 Apr 85 19:09:38 PST (Fri) Message-Id: <1033.482209778@lbl-csam> From: Van Jacobson The problems you're seeing are probably due to mistakes in the round-trip-timer code of the distributed 4.2bsd. All of the bugs reported to Berkeley have been fixed in 4.3bsd (& the 4.3bsd release is immanent). If you have source & don't want to wait for 4.3, here's a slightly annotated diff listing of the fixes. The annotations are mine & may be neither correct nor comprehensible. The fixes are from various people around the country & seem to work (we've shipped a lot of mail through ucl-cs with no problems). The diff line numbers will probably bear no resemblance to your sources. - Van Jacobson, Lawrence Berkeley Lab -------------------------------- (these lines added to tcp_timer turn off the round trip timing when you re-transmit): *** tcp_timer.c *** 153,163 ***** TCPTV_MIN, TCPTV_MAX); } tp->snd_nxt = tp->snd_una; + /* + * If timing a segment in this window, stop the timer. + */ + if (tp->t_rtt && SEQ_GT(tp->t_rtseq, tp->snd_una)) + tp->t_rtt = 0; (void) tcp_output(tp); break; (deleting the following line prevents you from computing a bogus, too small rtt when you get a ack for less than all the outstanding data). *** tcp_input.c *** 503,509 else { TCPT_RANGESET(tp->t_timer[TCPT_REXMT], tcp_beta * tp->t_srtt, TCPTV_MIN, TCPTV_MAX); - tp->t_rtt = 1; tp->t_rxtshift = 0; } if (acked > so->so_snd.sb_cc) { (if a timeout was caused by the subnet getting overloaded & discarding packets, you don't want to retransmit everything because that will just make the problem worse. This change limits the sender to one MSS segment per timeout interval until packets start getting through without timeouts) *** tcp_output.c *** 60,70 ***** return (0); /* ??? */ /* past FIN */ if (len > tp->t_maxseg) { len = tp->t_maxseg; + /* + * Don't send more than one segment if retransmitting. + */ + if (tp->t_rxtshift == 0) + sendalot = 1; } flags = tcp_outflags[tp->t_state]; *************** (this line was just someone's mistake. It prevents you from ever computing the rtt on the first packet. In fact, it keeps you from computing the rtt on about half the packets). *** 271,277 tp->snd_nxt != tp->snd_una) { TCPT_RANGESET(tp->t_timer[TCPT_REXMT], tcp_beta * tp->t_srtt, TCPTV_MIN, TCPTV_MAX); - tp->t_rtt = 0; tp->t_rxtshift = 0; } tp->t_timer[TCPT_PERSIST] = 0; ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041211313000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Fri 12 Apr 85 13:32:41-PST Date: 12 Apr 1985 16:31:30 EST From: PADLIPSKY@USC-ISI.ARPA Subject: Another Perspective on the NRC Flap To: tcp-ip@SRI-NIC.ARPA I wrote the following with the intent of sending it to the NRC Chairman Fink and making it an RFC. Neither course seems worth the effort anymore (especially as I've since gotten a copy of the full report [though not from NBS] and am reluctant to waste time, energy, and spleen updating it in light of whatever else I'd find if I were willing to read, rather than the skimming I've already done, the full thing). Just so it doesn't go completely to waste, though, perhaps some of the readers here will find it of interest. [But first an Aside on Cheap Shots: I don't have any problems with Carl's not wanting netmail, myself--I just think it would have been more ... appropriate, somehow, if he'd included his phone number. On the other hand, I do have problems with his implying that our research community is against the commercial stuff because it will cost us research money; as I said in The Book--which I notice Chloe was kind enough to post a reference to--"It's NOT a Not Invented Here problem, it's a Not Reinvented Right one" (or words to that effect).] [One other prefatory comment: I haven't been following the deliberations here scrupulously, so if my stuff is duplicative I'm sorry for any waste of readers' time; it's just that I have trouble remembering to use BBOARD, much less remembering how to use it.] Comments on National Research Council Protocols Report M. A. Padlipsky Although my response is perforce based upon its Executive Summary, I find the conclusions of the report "Transport Protocols for Department of Defense Data Networks" extremely puzzling, for several reasons, and would like to register my comments with you as rapidly as possible, without waiting for either the full report or corporate coordination with my employer. (My request for a full copy has yet to be honored by the NBS representative to whom it was made last December.) On balance, the report strikes me as extremely flawed, both in its reasoning and in what it omits. President Kennedy is supposed to have said that the greatest enemy of Truth is not a lie, but a persistent, persuasive, unrealistic myth. The conviction that "vendor-supplied" intercomputer networking protocols (and, it must be noted, protocol interpreters) are, almost unequivocally, desirable, though apparently not ignobly motivated, may well be just such a myth. As I will attempt to suggest, the report amounts to recommending that we simply throw away (not even trade in) a working, late-model automobile in favor of a set of tires and a chassis because the latter will cost less to purchase now than the former did previously and will also cost less to maintain. That the money for the former has already been spent whereas the money for the latter is new, that the latter isn't even a complete automobile, and that the former doesn't require premium unleaded fuel are all subordinated to, apparently, the perceived "savings". (To push the analogy a little further, another motivation is that the new machine has a right- hand steering wheel, more suitable for use on certain foreign roads; I'll also attempt to show that the old machine can be made to behave as if had both left- and right-hand steering wheels.) My own reasoning (much of which can be found in my recent book, THE ELEMENTS OF NETWORKING STYLE, Prentice-Hall, 1985) is as follows: In the first place, although the Executive Summary acknowledges the importance of protocols "above" the "Transport" level, the recommendation to have the DoD adopt TP-4 appears to ignore both the current absence of and future cost of development and/or procurement and/or 1 conversion to such protocols (ISO Reference Model L5-7, ARPANET Reference Model L III; see also Chapter 5 of my book, "A Perspective on the ARPANET Reference Model") in their international standard manifestations. Clearly, if the report's reasoning as to the economic advantages of TP-4 is correct, similar considerations must apply to "the rest" of the protocol suite. Thus, emerging international standards must be intended to be adopted at levels above ISO L 4-3C (ARM L II). Yet these protocols will engender not only further delays in the waiting for them, but also further painful conversions in the deployment. As the report appears to acknowledge the position that even waiting for and deploying TP-4 are unattractive in the DoD context, surely weight should have been attached to the additional delays and conversions. (This contextual incompleteness is why I cite a "real" car vs. tires and chassis in my opening analogy. It might seem fanciful, but I submit it's extremely relevant: in a sense, the panel is opting for a few oranges over a bushel of apples if it does not assess the impact of acquiring the entire ISORM "SUITE"). In the second place, the Executive Summary's language suggests that weight was being attached to the "development" costs of TCP -- this despite the fact that TCP is already developed and, for that matter, procurable for a number of DoD operating systems. Indeed, the entire attempt at economic analysis seems questionable to me, for reasons discussed at some length in Chapter 8 of my book, "The Illusion of Vendor Support", which offers support not only for the higher fuel costs aspect of the automotive analogy but also for the notion that we'll have to go back to the dealer for a more powerful engine (i.e., that the ISORM suite's protocol interpreters in toto will necessitate upgrading of processors in order to leave enough CPU power to run the non-protocol software). In the third place, insufficient attention appears to have been paid to the "technicoaesthetic" merits, or lack of same, of the emerging international standards. These are dealt with passim in my book, but perhaps bear some treatment here. For example, Economy of Mechanism is a usually accepted technicoaesthetic canon. The ISORM's greater-than-seven layers obviously entail a more elaborate mechanism than the ARM's three, even without appealing to the greater number of headers and "overhead" bits engendered by the extra layers. A striking consideration not mentioned explicitly in the book which 2 appeals to essentially the same technicoaesthetic principle is that given the emerging international standards' approach to communications subnetworks (wherein, although not "official," X.25 is usually assumed to comprise L 3-1/L I), the very cost of communicating is necessarily elevated by factors of four or more due to the quite small packet sizes permitted/encouraged at the comm subnet level. That is, the ISORM leads to bigger messages' being transmitted in smaller chunks (each chunk charged for); hence, even if the procurement costs were lower -- which I don't stipulate -- the operational costs would arguably be higher. (Again, higher "fuel costs".) In the fourth place, the treatment of Security appears to be extremely cavalier. My understanding (as a member of the DoD Protocol Standards Technical Panel) is that those of us in the networking research community who are directly affiliated with or sponsored by the DoD are not even allowed under current doctrine to discuss our concerns in this area with those in the uncleared, commercial arena. As a matter of fact, it was extremely surprising that Ray Mcfarland of the DoD Computer Security Center was not listed as one of the expert witnesses whose testimony was taken by the panel, even if all he could have done was to enter this position on the record. (For that matter, even though Drs. Postel and Cerf are certainly outstanding advocates of the TCP cause, the absences of Dr. David Clark of M.I.T., the ARPA "Internet Architect", and Ed Cain of the Defense Communications Engineering Center, the chairman of the PSTP, in addition to them were also surprising to me.) The panel's blithe assertion that Security can be ladled on to TP-4 is probably contrary to fact and certainly oversanguine. Finally, although other arguments could be raised against the report's conclusions, I'd like to observe that a potentially quite attractive solution to the problem of "interoperating" with NATO without abandoning the in-place DoD protocol suite does not appear to have been taken into account. The approach (mentioned in Chapters 2 and 10, "What the Windmill Looks Like Up Close" and "Gateways, Architectures, and Heffalumps," respectively) is what I call parallel invocation of protocol suites. Very briefly, it argues that with a suitable Host-Front End Protocol (such as the one I've proposed in ARPANET "RFC's" 928 and 929) and Outboard 3 Processing Environment, one could invoke remote applications of interest via the protocol suites they "expect" to be invoked through without having to (over-) constrain oneself to a single protocol suite. (This, of course, deals with the steering wheel sidedness aspect of the automotive analogy.) Even the "Janus Host" tactic mentioned in Chapter 10 could potentially allow for sufficient interoperability with NATO to cast considerable doubt on the premise that the "automatic" ability to do so is a plus for the ISORM. (Further, as observed in Chapter 8, the likelihood of incompatible option choices casts a good deal of doubt on how "automatic" it would be -- until the fixes are paid for.) Please be assured that I am not attempting to suggest that the panel be reconvened and forced to study my book. (I did comply with a staff request to send the earlier versions of several of the chapters, but the book, of course, hadn't yet been published, so I'm not even carping about their "research" -- although the staffer did know the book was in progress, so perhaps my own absence from the witness list could also be faulted somewhat.) Rather, I am attempting to suggest that, if accepted, the report would lead to the DoD's wasting both money and time, neither of which it -- and the country -- can afford. I would, then, be so bold as to suggest that the report in question be reconsidered, since it appears to have failed to consider several significant factors -- including, I might add, the consideration that embellishing TP-4 to satisfy the stated "DoD Operational and Technical Needs" can scarcely be assumed to come for free, even if the additional "Needs" of Efficiency and Timeliness (of availability in general and of responses on a per-transmission basis in particular) were not to be accepted as missing members of the list ... and even if it were not my conviction that a state-of-the-art in the hand is worth more than seven promises in the bush. You Pay For What You Get. Perhaps in five years or so, when there will probably be a complete ISORM Suite and when vendor- implemented option mismatches have had a chance to be thrashed out and when holes in the Model such as "null layers" and "connectionless mode" and "management sublayers" have been plugged and when we have a chance to measure the impact all this mechanism will have on the containing Hosts, it might be reasonable to consider going over. Today, to do so is to buy a pig in utero 4 rather than even a pig in a poke. Just because the pig we already own comes from a family farm rather than an Agribusiness is no reason to be so incautious as that, I submit. 5 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041214244200> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Fri 12 Apr 85 16:24:26-PST Date: 12 Apr 1985 19:24:42 EST From: MILLS@USC-ISID.ARPA Subject: Re: long delay connections To: stanonik@NPRDC.ARPA, tcp-ip@SRI-NIC.ARPA cc: MILLS@USC-ISID.ARPA In response to the message sent 12 April 1985 0836-PST (Friday) from stanonik@NPRDC Ron, Your problems with 4.2 are well-known and documented. Fuzzballs have been specially built to handle long-delay paths and have several features designed to minimize the impact on intervening gateways of the type used on SATNET paths, such as the send-policy and ack-policy algorithms described to this list recently. According to Berkeley gurus, similar policies are planned for the next release. My experience has been that, with carefully engineered algorithms, SATNET performance can be quite satisfactory. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041403362200> Received: from UDel-Huey by SRI-NIC.ARPA with TCP; Sun 14 Apr 85 05:35:31-PST Received: From localhost.ARPA by UDel-Huey.ARPA id a002539 ;14 Apr 85 8:36 EST To: PADLIPSKY@USC-ISI.ARPA cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Another Perspective on the NRC Flap In-reply-to: Your message of 12 Apr 1985 16:31:30 EST. Date: 14 Apr 85 08:36:22 EST (Sun) Message-ID: <1012.482333782@udel-huey> From: Dave Farber I must respond very briefly to your comments on security. We were instructed as to the wording we could put in the report summerizing our rather non trivial exploration of the security issues of TCP and TP4. I am sure you can understand the lack of extensive verbage in this area. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041407174100> Received: from UDel-Huey by SRI-NIC.ARPA with TCP; Sun 14 Apr 85 09:16:49-PST Received: From localhost.ARPA by UDel-Huey.ARPA id a004712 ;14 Apr 85 12:17 EST To: PADLIPSKY@USC-ISI.ARPA cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Another Perspective on the NRC Flap In-reply-to: Your message of 12 Apr 1985 16:31:30 EST. Date: 14 Apr 85 12:17:41 EST (Sun) Message-ID: <1012.482347061@udel-huey> From: Dave Farber I will take your note as the venicle for again offering a limited number of reproductions of the full report Please send your Name and address to westog@udel-ee requesting a copy of the NRC report. I have about 15. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041409231400> Received: from Xerox.ARPA by SRI-NIC.ARPA with TCP; Sun 14 Apr 85 17:21:57-PST Received: from Flora.ms by ArpaGateway.ms ; 14 APR 85 17:22:24 PST From: DonWinter.pasa@Xerox.ARPA Date: 14 Apr 85 17:23:14 PST Subject: Re: Another Perspective on the NRC Flap In-reply-to: farber@UDel-Huey.ARPA's message of 14 Apr 85 12:17:41 EST (Sun), <1012.482347061@udel-huey> To: Dave Farber cc: PADLIPSKY@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA Isn't RFC 942 a reproduction of the complete report? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041417435000> Received: from UDel-Huey by SRI-NIC.ARPA with TCP; Sun 14 Apr 85 19:46:04-PST Received: From localhost.ARPA by UDel-Huey.ARPA id a011169 ;14 Apr 85 22:44 EST To: DonWinter.pasa@XEROX.ARPA cc: PADLIPSKY@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Another Perspective on the NRC Flap In-reply-to: Your message of 14 Apr 85 17:23:14 PST. Date: 14 Apr 85 22:43:50 EST (Sun) Message-ID: <1012.482384630@udel-huey> From: Dave Farber I just checked and it is indeed a full reporduction. I had not checked before. I assumed from the fact that people seemed to not have read the full document( from some of the comments they made) and assumed invalidly that the rfc was abbreviated. Anyway if there are any out there who like hard copy typset I will be happy to send one. BTW, the people who contracted to do the printing were a good example of lowest bid work. They did not know how to handle hypens when they reformatted. Most careless. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041504103900> Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Mon 15 Apr 85 12:10:23-PST Date: Mon 15 Apr 85 12:10:39-PST From: Greg Satz Subject: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] To: postmaster@UCI-ICSA.ARPA cc: tcp-ip@SRI-NIC.ARPA Phone: (415) 497-1004 This really stinks. SU-SIERRA just got a new Internet interface and the NIC hasn't yet put it in the host table. Why should Sierra users who want to mail to UCI get penalized? You probably have heard many complaints about this before. --------------- Date: Mon 15 Apr 85 12:05:55-PST From: The Mailer Daemon To: SATZ@SU-SIERRA.ARPA Subject: Message of 15-Apr-85 12:04:41 Message failed for the following: morgan@UCI-ICSA.ARPA: 521 Mail system claims 10.4.0.11 is an unknown host ------------ Date: Mon 15 Apr 85 12:04:41-PST From: Greg Satz [Rest of message deleted] ------- ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041505053100> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Mon 15 Apr 85 07:05:25-PST Date: 15 Apr 1985 10:05:31 EST From: PADLIPSKY@USC-ISI.ARPA Subject: Clarification To: tcp-ip@SRI-NIC.ARPA My thanks to the several people who wrote both publically and privately in re the availability of the full NRC report. Also, my apologies for any confusion I might inadvertantly have engendered. I'll try to be less subtle here: 1. I have a copy of the full report. 2. I decline to go through the exercise of studying the full report closely and updating the comments I wrote when I only had the Executive Summary because I don't believe it's worth the effort. (I.e., positions seem cast in concrete [to put it kindly]; I just didn't want my comments to go to waste; I don't think I'll manage to change anybody's mind by my wit and eloquence [unless they manage to change minds in what I take to be the wrong directon, of course].) 3. The point I find striking about distribution of the full report is that I was promised a copy by the NBS rep at the December PSTP meeting--which still hasn't happened. This is striking in that it gives me some faint reason to believe that somebody (other than myself) must have some grounds to think that perhaps my wit and eloquence might have the power to change some minds after all ... I mean, why else would they try to keep me out of it? 4. If there were a mark that meant "I'm only being about 49% facetious," I'd put it here. 5. In 3., "other than" does NOT mean "in addition to". cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041507283600> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Mon 15 Apr 85 09:30:09-PST Date: 15 Apr 1985 12:28:36 EST From: PADLIPSKY@USC-ISI.ARPA Subject: Re: Another Perspective on the NRC Flap To: farber@UDEL-HUEY.ARPA cc: tcp-ip@SRI-NIC.ARPA In response to your message sent 14 Apr 85 08:36:22 EST (Sun) Hi, Dave (and onlookers)-- Good to hear that the discussion of Security was more extensive than suggested by the report. However, the fact that I'm not even sure I could discuss it with you at length (if we both even wanted to-- which I for one don't, as a matter of fact) is a lot closer to what I think the crux is: namely, that Security is merely the most evident of the many areas in which the assumption (or even much-debated conclusion) that DoD-needed alterations to the emerging commercial standards can be achieved within reasonable time and cost limits strikes me as being extremely questionable. Indeed, I'd even go so far as to suggest that the very acknowledgment of the necessity of such changes calls the report's conclusion into question, since the "off-the-shelf" premise (which I take to be very major) is negated by it (unless you want to get into "a little bit pregnant" sorts of arguments as to just how many changes makes it no longer off-the-shelf--which won't be fruitful, since my position is "one"). At any rate, I really didn't mean to start off a new round of spleen- venting with my comments, so I'd better not indulge myself on the topic of how much many/most contractors charge the DoD even NOT to do things (that were "in the A-Spec," typically) and just settle for wondering what happens when the alterted realizations of the standards start getting mutually incompatible.... (I suggest, that is, that the power AND THE DANGER of standards both stem from the standards' being STANDARD--and don't even be tempted to try to see what my answer is to "backward compatibility" arguments.) Enough. I'm already getting sorry I rediscovered BBOARD, and I don't want everybody to be. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041508560200> Received: from RADC-TOPS20.ARPA by SRI-NIC.ARPA with TCP; Mon 15 Apr 85 10:54:44-PST Date: Mon 15 Apr 85 13:56:02-EST From: Mark McCall Subject: LAN TCP/IP implementations To: tcp-ip@SRI-NIC.ARPA I am working on a major DOD program which will be using TCP/IP outboarded in interface units on a network of heterogeneous hosts and workstations. The LAN will be based on a commercial broadband offering. One of the hosts currently supports a version of NCP which allows up to 128 logical connections to the host. The problem we have is how to carry over this capability when we convert to the outboarded TCP. We currently have specified interface units which will support 64 logical connections and plan to provide multiple paths to a host - if required. I am interested in opinions relative to the feasibility of our current plan, as stated above, and to the feasibility of supporting up to 128 logical connections in an interface unit. The interface unit is expected to be based on Intel 8086, 80186, 80286, or Motorola 68000 microprocessors. Any input will be appreciated. Please respond to "mccall@radc-tops20" or to this mailing list. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041511231700> Received: from UCI-ICSA by SRI-NIC.ARPA with TCP; Mon 15 Apr 85 19:24:36-PST To: Greg Satz cc: postmaster@uci-icsa.arpa, tcp-ip@sri-nic.arpa Subject: Re: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] In-reply-to: Your message of Mon 15 Apr 85 12:10:39-PST. Date: 15 Apr 85 19:23:17 PST (Mon) Message-ID: <309.482469797@uci-icsa> From: John Romine Received: from Localhost by UCI-ICSA; 15 Apr 85 19:24:25 PST (Mon) Well, I used to hear about it from time to time when I was the UCI PostMaster, but I'm not anymore so I don't. UCI took (takes?) the attitude that they don't want to accept mail that will be unreturnable (or unreplyable). Also, I seem to remember something about hosts not using a net address that wasn't registered with the NIC. (Does that mean in the NIC table?) At any rate, I'd say this falls into the category of UCI not being an extremely friendly neighbor. That is, not being liberal enough in what we accept, to allow mail from unregistered net addresses. At least we try to be conservative with what we send out. If we want to talk about deficiencies in various hosts' mailsystems (I don't), we can always discuss why certain TOPS-20 sites can't seem to generate a Date: field which adheres to the standard. I'd just as soon not complain about other people's mailsystems, and hope to not get too many complaints about mine. /JLR ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041511281600> Mail-From: ROODE created at 15-Apr-85 19:28:32 Date: Mon 15 Apr 85 19:28:16-PST From: David Roode Subject: Re: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] To: jromine@UCI-ICSA.ARPA, SATZ@SU-SCORE.ARPA cc: postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "John Romine " of Mon 15 Apr 85 19:23:17-PST Location: EJ286 Phone: (415) 859-2774 Well, hopefully the DDN PMO people will generate an ACTIVATE HOST form so the NIC can place the SIERRA ARPANET address in the host table. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041511434400> Mail-From: ROODE created at 15-Apr-85 19:44:08 Date: Mon 15 Apr 85 19:43:44-PST From: David Roode Subject: apologies To: tcp-ip@SRI-NIC.ARPA Location: EJ286 Phone: (415) 859-2774 You may get 2 copies of the last message sent to TCP-IP. The mail processing daemon here at SRI-NIC was inadvertently interrupted midway through the delivery cycle for the message from John Romine which will cause some people to receive an extra copy. I wanted to respond to John Romine's and Greg Satz's questions concerning the recognition of the SU-SIERRA Arpanet address by explaining that what is happening is that the IMP port is operational in a TEST status. Sierra must communicate the operational status of the port to their contact back at DCA, and at that time DCA will tell NIC to place the host in the official host table. It is not technically kosher to utilize the port for operational purposes in the meantime. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041602070000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Tue 16 Apr 85 04:08:04-PST Date: 16 Apr 1985 07:07-EST Sender: CERF@USC-ISI.ARPA Subject: Re: LAN TCP/IP implementations From: CERF@USC-ISI.ARPA To: MCCALL@RADC-TOPS20.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]16-Apr-85 07:07:27.CERF> In-Reply-To: The message of Mon 15 Apr 85 13:56:02-EST from Mark McCall You don't say what sorts of traffic these 128 connections might handle. There is certainly nothing about the TCP/IP which should prevent it from handling 128 simultaneous calls. And if you have MC68000 or 8086 capability microprocessors, they should be adequate in terms of CPU - the real limiting factor is probably packets/second and checksum calculations. If the applications are echoplex in nature and call for many small packets per second, you may have some problems with large numbers of concurrent connections. Another issue is memory space - because TCP uses a window/retransmission scheme, a long delay before receiving an acknowledgement from a corresponding party (ie.e the other end) can increase memory needs. This is exacerbated by high bandwidth file transfers. Of course, each connection requires some memory just to keep track of state. Perhaps some of the implementers of TCP in microprocessor environments can offer their experiences as to maximum number of and types of TCP connections they've been able to support? Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041605322300> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Tue 16 Apr 85 11:34:52-PST Date: Tue 16 Apr 85 12:32:23-MST From: Mark Crispin Subject: Re: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] To: jromine@UCI-ICSA.ARPA cc: SATZ@SU-SCORE.ARPA, postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "John Romine " of Mon 15 Apr 85 19:23:17-MST The problem with Date: fields in the TOPS-20 mailsystem is an old issue and has been hashed out ad nauseum on this and other lists. Basically, TOPS-20 has a system call which outputs formatted date/time fields, unlike most operating systems where you have to do the grunge work yourself. The transition from RFC 733 to RFC 822 somehow managed to pick one of the few human-readable date/time formats which this system call cannot output. I consider the problem an operating system problem/lack of feature and have had enough positive input from the operating system's vendor on the subject that I believe the support for RFC 822 format will be added to TOPS-20. The problem could, of course, be fixed with some work in the mail software, but I don't think it's worth it. There are several other issues about the RFC 822 date/time format and why in general it is a losing format. I don't wish to engage in long religious wars on the topic. I just wish I had caught it before RFC 822 was made official when I had a chance of getting something more ameniable to TOPS-20 (and for parsing in general). -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041605401600> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Tue 16 Apr 85 11:41:00-PST Date: Tue 16 Apr 85 12:40:16-MST From: Mark Crispin Subject: Re: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] To: jromine@UCI-ICSA.ARPA cc: SATZ@SU-SCORE.ARPA, postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "John Romine " of Mon 15 Apr 85 19:23:17-MST It is reprehensible to refuse electronic mail from an address which isn't in your host table. A large body of sites exists in which the site itself has no ARPA Internet business but certain of its users do. The organization management elects NOT to list that site with the NIC even though the site has Internet connectivity (for internal uses) but allows the users with ARPA Internet business to communicate with the ARPA Internet. Stanford University is one organzation operating with this model. It is completely possible to respond/return mail to a site which isn't registered -- go by the numbers! The syntax of dotted decimals is defined in RFC's 821 and 822. While the authors didn't envision its regular use for this purpose, the syntax does exist and can be used for this purpose. The much-maligned TOPS-20 mailsystem was carefully coded to consider the [a.b.c.d] syntax to be a "host name" string just like names in the NIC table and in fact is incapable of telling the difference except at the very lowest level. If your mailsystem can't support the dotted decimal syntax, maybe you might take a hint from an obsolete operating system and write the support in the low-level HostNameToAddress and AddressToHostName routines. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041608510000> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 16 Apr 85 16:52:14-PST Date: 16 Apr 1985 16:51-PST Sender: JGOLDBERGER@USC-ISIB.ARPA Subject: Rejection of hosts not in the NIC table From: Joel Goldberger To: MRC@SIMTEL20.ARPA Cc: jromine@UCI-ICSA.ARPA, SATZ@SU-SCORE.ARPA Cc: postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISIB.ARPA]16-Apr-85 16:51:38.JGOLDBERGER> In-Reply-To: The message of Tue 16 Apr 85 12:40:16-MST from Mark Crispin Berkeley Sendmail explicitly supports dotted decimal notation. I won't try to speculate on what software UCI is running, but they must have installed this less than helpful feature themselves. - Joel Goldberger - ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041611022600> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Tue 16 Apr 85 17:05:16-PST Date: Tue 16 Apr 85 18:02:26-MST From: Mark Crispin Subject: Re: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] To: MILLS@USC-ISID.ARPA cc: jromine@UCI-ICSA.ARPA, SATZ@SU-SCORE.ARPA, postmaster@UCI-ICSA.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "MILLS@USC-ISID.ARPA" of Tue 16 Apr 85 18:50:51-MST Dave - I still actively develop and maintain the TOPS-20 mailsystem, but that doesn't mean that every site runs the software as I distribute it. ISI in particular runs its own completely different SMTP server. Only software using the "HSTNAM module" for name/address parsing and translation will have the automatic [a.b.c.d] format handling that I described. Most versions of MM use this module (I don't know about ISI's), but I can't speak for Babyl, Msg, Hermes, or MS. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041613505100> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Tue 16 Apr 85 15:51:30-PST Date: 16 Apr 1985 18:50:51 EST From: MILLS@USC-ISID.ARPA Subject: Re: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] To: MRC@SIMTEL20.ARPA, jromine@UCI-ICSA.ARPA cc: SATZ@SU-SCORE.ARPA, postmaster@UCI-ICSA.ARPA, cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA In response to the message sent Tue 16 Apr 85 12:40:16-MST from MRC@SIMTEL20.ARPA Mark, Your "much-aligned TOPS-20 mailsystem" must have gone bum since you last had hooks in it - the ISI systems, at least, now punt with "[a.b.c.d]" formats, both for originating and answering mail. I agree with your point, however. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041709571700> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 17 Apr 85 14:55:58-PST Received: FROM ISI-ALFALFA.ARPA BY USC-ISIB.ARPA WITH TCP ; 17 Apr 85 14:53:22 PST Date: 17 Apr 85 14:57:17 Sender: Chase@ISIB From: Dale Chase To: MILLS@USC-ISID.ARPA Cc: tcp-ip@SRI-NIC.ARPA, MRC@SIMTEL20.ARPA Subject: Re: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] In-reply-to: Your message of 16 Apr 1985 18:50:51 EST Dave- Both MM and SMTP at ISI are happy to accept dotted decimal formats for hostnames. If you still think one of them doesn't, give me some more info (offline from this list) and I'll investigate. <>Dale ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041710140000> Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Wed 17 Apr 85 18:15:35-PST Date: 17 Apr 1985 18:14-PST Sender: BILLW@SU-SCORE.ARPA Subject: Re: [The Mailer Daemon : Message of 1... From: William "Chops" Westfield To: chris@COLUMBIA.ARPA Cc: Chase@USC-ISIB.ARPA, MILLS@USC-ISID.ARPA Cc: MRC@SIMTEL20.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <[SU-SCORE.ARPA]17-Apr-85 18:14:34.BILLW> In-Reply-To: The message of Wed, 17 Apr 85 20:12:03 est from chris@columbia.arpa (Chris Maio) That some of the tops-20 hosts at stanford send out mail FROM: user@HOST, where host is not in the NIC host table is not MRC's fault. Those people have carefully broken the feature where such hosts would be written as [a.b.c.d], on the basis that the latter form is ugly. I recently brought up CSD's new 20 (SU-SUSHI), and sure enough it sent out mail saying FROM: BILLW@[36.8.0.53] until I broke MM to cause it to to say BillW@Sushi... Of course this is partly MRC's fault, because MM should have gone on to discover that Sushi was a valid PUP name, and put that name there (at least for PUP speaking hosts!). However, if a host is ON the internet, then MRC's low level routines don't understand the concept of "not in the host table, try some othre host table" - the routine will ALWAYS return some host name, even if it is [36.8.0.53]... BillW PS: SU-Sushi is now in the NIC host table - I would not have felt justified in breaking MM if it hadn't been a temporary condition. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041715120300> Received: from columbia.arpa by SRI-NIC.ARPA with TCP; Wed 17 Apr 85 17:18:33-PST Received: by columbia.arpa; Wed, 17 Apr 85 20:12:03 est Date: Wed, 17 Apr 85 20:12:03 est From: chris@columbia.arpa (Chris Maio) To: Chase@ISIB, MILLS@USC-ISID.ARPA Subject: Re: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] Cc: MRC@SIMTEL20.ARPA, tcp-ip@SRI-NIC.ARPA I think there's a little confusion here - if a Stanford host is not in the NIC table but has a local host table with it's own name in it, then it will *not* generate dotted decimal notation in the From: header of outgoing messages - the sending mailer has no idea whether its name is known to other hosts, and this seems to be uci's motivation in not accepting mail from those sites. I find it somewhat annoying to get requests for help or info from somebody at Stanford and have to do detective work to figure out how to reply, and I don't think it's reasonable to expect the average user to read the RFCs to figure out that he can look in the Return-Path to get a dotted decimal address. One easy solution to making "hidden" hosts a little more socially acceptable is to route outgoing mail through a sendmail host which is in the NIC table to rewrite the sender's address, e.g. "user%hiddenhost@knownhost". However, the whole idea of hiding hosts from the NIC bothers me, since it's difficult to determine who the host administrator is. - Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041716503400> Received: from RUTGERS.ARPA by SRI-NIC.ARPA with TCP; Wed 17 Apr 85 18:50:17-PST Date: 17 Apr 85 21:50:34 EST From: Charles Hedrick Subject: request for a buddy To: tcp-ip@SRI-NIC.ARPA RUTGERS now has permission to be a domain. As you no doubt know, this involves establishing a duplicate server, preferably on some other IMP (so an IMP failure does not take both servers down). Is there anybody else out there who needs a duplicate server and would like to cooperate with us? I.e. we act as your backup and visa versa. My theory is that there should be a computer match-making service for this purpose, but if people who are interested would reply to me directly, I can keep a list and respond to anyone else who is interested. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041802520000> Received: from Shasta by SRI-NIC.ARPA with TCP; Thu 18 Apr 85 12:59:30-PST From: imagen!geof@Shasta Date: Thursday, 18 Apr 1985 10:52-PST To: shasta!tcp-ip@sri-nic Reply-To: imagen!geof@shasta Phone: (408) 986-9400 (work) Postal-Address: IMAGEN, 2650 San Thomas Expressway, Santa Clara, CA 95052 Real-Name: Geoffrey H. Cooper Subject: Routing capabilities of Berkeley 4.2 Unix Does 4.2 Unix have code in it to send ICMP redirects? I want to use a local 4.2 machine as a redirecting gateway to all our other hosts. The 4.2 machine is configured to know the `best route' that I want. When I send packets to it, it forwards them correctly, but doesn't send a redirect. Since I don't want to use the 4.2 host as a gateway, but only as a source of redirects, this is unacceptable. Perhaps some switch needs to be enabled to make this work right? - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041803141500> Received: from UCI-ICSA by SRI-NIC.ARPA with TCP; Thu 18 Apr 85 11:27:12-PST To: chris@columbia.arpa (Chris Maio) cc: Chase@usc-isib, MILLS@usc-isid.arpa, MRC@simtel20.arpa, tcp-ip@sri-nic.arpa, stef@uci-icsa Subject: Re: [The Mailer Daemon : Message of 15-Apr-85 12:04:41] In-reply-to: Your message of Wed, 17 Apr 85 20:12:03 est. Date: 18 Apr 85 11:14:15 PST (Thu) From: Einar Stefferud Received: from Localhost by UCI-ICSA; 18 Apr 85 11:19:33 PST (Thu) Thanks Chris for your lucid comments which explain our UCI position. Users on unregistered hosts should use a known relay to send mail. I also want to thank David Roode for pointing out that from the SRI-NIC and DCA perspective, hosts that are in test state and not yet approved for entry in the official NIC HOST TABLES are in fact not yet entitled to netwide recognition. They should use gateways and relays. As the Officially registered Host Administrator for UCI, I reaffirm that we do not plan to accept mail conections from hosts we do not find in our host tables, which we get from SRI-NIC on a most regular and punctual basis. Our reasons are simple and to the point. We very much believe in being friendly, but draw the line at being promiscuous. 1) We do not have the resources to chase down addressing addressing problems that would result. 2) We do not see any reason to trust just anybody that attempts an SMTP connection, no matter who you might be, if we cannot identify you. 3) A perfectly valid alterntative exists for you to use a gateway or relay if you are not registered with the NIC. 4) It is your responsibility to be known, not ours to sleuth you out. 5) Any competent mail transfer system should be able to automatically route all mail to the Internet via some known relay. 6) What does or does not run on TOPS-20 sites is of no relevance to UCI in this matter. Thank you all for your contributions to this discussion. I hope this will close it out. --- Stef ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041807020000> Received: from Navajo by SRI-NIC.ARPA with TCP; Thu 18 Apr 85 15:02:55-PST Date: 18 Apr 1985 1502-PST (Thursday) From: Jeff Mogul To: imagen!geof@shasta Cc: tcp-ip@sri-nic Cc: karels@ucbarpa Subject: Re: Routing capabilities of Berkeley 4.2 Unix In-Reply-To: Msg from imagen!geof@Shasta dated Thursday, 18 Apr 1985 10:52-PST. Geof asks: Does 4.2 Unix have code in it to send ICMP redirects? From a quick reading of the source code, the answer is "no". From a deeper understanding of the 4.2 networking implementation, the answer is "no way." The problem is that 4.2 does not track the physical source of a packet (i.e., which interface it arrived on); this information is thrown away in the device driver. So, by the time the IP layer makes a routing decision on a packet it is forwarding, it has no idea if the packet arrived on the same interface it is to be sent out on, which would be grounds for issuing a redirect. I suppose there might be other ways of determining that a redirect is in order, but I can't think of any that are as simple and foolproof as comparing the incoming and outgoing interfaces. Moreover, the lack of tracking means that it is impossible, under the 4.2 structure, to properly (safely) implement: o ICMP Information Request o ICMP Address Format Request (soon to be "Address Mask") o Reverse-path forwarding of broadcasts o Non-local broadcasts ("letter bombs") I spent a few days trying to construct a tagging system that would not require major changes to all of the 4.2 network code; the best I could do is still a kludge, so I gave up. I don't know if this will change in 4.3; perhaps someone at Berkeley could enlighten us? -Jeff P.S.: Or, maybe someone can prove me wrong ... I sure hope so! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041811554500> Received: from merlin.ARPA by SRI-NIC.ARPA with TCP; Thu 18 Apr 85 13:55:08-PST Message-Id: <8504182155.AA19950@merlin.ARPA> Received: by merlin.ARPA; Thu, 18 Apr 85 16:55:48 EST To: imagen!geof@shasta.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: Routing capabilities of Berkeley 4.2 Unix In-Reply-To: Your message of Thursday, 18 Apr 1985 10:52-PST. <8504182144.AA20697@purdue.ARPA> Date: 18 Apr 85 16:55:45 EST (Thu) From: Christopher A Kent Last time I looked, it wasn't there. Too bad. chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041812385400> Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Thu 18 Apr 85 15:07:43-PST Date: Thu, 18 Apr 85 17:38:54 EST From: Joe Pistritto To: Christopher A Kent cc: imagen!geof@SU-SHASTA.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Routing capabilities of Berkeley 4.2 Unix Actually, I do have a program that will adjust the default route under 4.2 among a number of possible gateways, using ICMP ECHOs to verify that the gateway is there, and selecting an alternate if its not. This doesn't, of course, have any relation to EGP. -JCP- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041817392600> Received: from UDel-Dewey by SRI-NIC.ARPA with TCP; Thu 18 Apr 85 19:38:36-PST Received: From localhost.ARPA by UDel-Dewey.ARPA id a013027 ;18 Apr 85 22:39 EST To: tcp-ip@SRI-NIC.ARPA Subject: satellite Date: 18 Apr 85 22:39:26 EST (Thu) From: dizio@UDel-Dewey.ARPA I'm currently writting a paper which deals with the effects a satellite communication network could have upon transport layer protocols. In particular flow control considerations. I've looked in some of IEEE's issues which deal with satellite communications but all the papers I've read are mainly concerned with setting up these types of network(physically) and sharing the communications channel. I would appreciate any information with regard to where I could look to find out more about this subject(ie. papers books, etc..). Thanks in advance Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041909590000> Received: from Navajo by SRI-NIC.ARPA with TCP; Fri 19 Apr 85 18:00:55-PST Date: 19 Apr 1985 1759-PST (Friday) From: Jeff Mogul To: bill%gvax@Cornell.ARPA (William A. Nesheim) Cc: TCP-IP@SRI-NIC.ARPA, xnsunix.pa@XEROX.ARPA Subject: Re: 4.2 routing ... In-Reply-To: bill%gvax@Cornell.ARPA (William A. Nesheim) / Fri, 19 Apr 85 15:30:48 est. <8504192030.AA11460@gvax.ARPA> Bill Nesheim writes: I've been working on implementing XNS routing and packet forwarding under 4.2. We want to have one of our vaxes act as an Internetwork Routing Service for the Xerox hardware on the net. Directed broadcast is used in the Xerox internet to locate Clearinghouse Servers, a fairly important activity, so we couldn't just leave it out. The only way to implement this safely is for the internet layer to be able to look at the lower level headers of the packets it recieves. I did this for the ethernet by tacking a mbuf with m_type == MT_HEADER onto the front of the mbuf data chain in the ethernet interface driver, and copying the ethernet header into it. The IDP input routine then can use this mbuf if it exists, or just not deliver "letter bombs" if it isn't. (eg, first mbuf m_type == MT_DATA). Actually, I stand by my original suggestion: you don't need the LAN header (as Bill notes, that causes a lot of kludgey code, anyway); you need a stamp showing which interface the packet arrived on. This can be any "unique ID" for the interface; the "struct if" address of the interface is sufficient, since you only need it for equality comparisons. This works for all protocols and local network technologies. In fact, I do not believe you can deduce this information from the LAN header, in the general case. In the case of the 10Mbaud EtherNet, you can (because the ether source host ID is universally unique), but on (say) the 3Mbaud ethernet the LAN header does not tell you which interface a packet arrived on, because each LAN has its own host number address space. I speak from some experience, having implemented directed broadcasting for Pup in two different gateways. By the way, I agree with you that directed broadcasting is important. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041910304800> Received: from Cornell.ARPA by SRI-NIC.ARPA with TCP; Fri 19 Apr 85 12:28:21-PST Received: from gvax.ARPA (gvax) by Cornell.ARPA (4.30/4.30) id AA00426; Fri, 19 Apr 85 15:29:58 est Date: Fri, 19 Apr 85 15:30:48 est From: bill%gvax@Cornell.ARPA (William A. Nesheim) Message-Id: <8504192030.AA11460@gvax.ARPA> Received: by gvax.ARPA (4.30/4.30) id AA11460; Fri, 19 Apr 85 15:30:48 est To: TCP-IP@SRI-NIC.ARPA, xnsunix.pa@XEROX.ARPA Subject: 4.2 routing ... Jeff Mogul writes: >Moreover, the lack of tracking means that it is impossible, >under the 4.2 structure, to properly (safely) implement: > >o ICMP Information Request >o ICMP Address Format Request (soon to be "Address Mask") >o Reverse-path forwarding of broadcasts >o Non-local broadcasts ("letter bombs") > I've been working on implementing XNS routing and packet forwarding under 4.2. We want to have one of our vaxes act as an Internetwork Routing Service for the Xerox hardware on the net. Directed broadcast is used in the Xerox internet to locate Clearinghouse Servers, a fairly important activity, so we couldn't just leave it out. The only way to implement this safely is for the internet layer to be able to look at the lower level headers of the packets it recieves. I did this for the ethernet by tacking a mbuf with m_type == MT_HEADER onto the front of the mbuf data chain in the ethernet interface driver, and copying the ethernet header into it. The IDP input routine then can use this mbuf if it exists, or just not deliver "letter bombs" if it isn't. (eg, first mbuf m_type == MT_DATA). This is really a kludge, as the lower level header depends on the network the packet was delivered on, so we have to put some knowledge of this lower level into the internet layer for this scheme to work. Question: Has anyone come up with a fairly generic template for a "Transmission Media Protocol" header that could deliver all the information needed for ICMP, Reverse-path forwarding of broadcasts, and Non-local broadcasts? -- Bill Nesheim Cornell U. Dept. of Computer Science ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041914124500> Received: from columbia.arpa by SRI-NIC.ARPA with TCP; Fri 19 Apr 85 16:12:29-PST Received: by columbia.arpa; Fri, 19 Apr 85 19:12:45 est Date: Fri, 19 Apr 85 19:12:45 est From: chris@columbia.arpa (Chris Maio) To: tcp-ip@sri-nic.arpa Subject: IP gateways Can someone recommend a good source for ethernet IP gateways, preferably something like a 68000 box with source code available for a reasonable cost? Columbia is looking to link several campus 10Mb ethernets together, and the simplest solution, using 4.2bsd hosts as gateways, would not provide for the use of non-IP-based protocols (e.g. LAT, DECnet) between ethernets. I'd like to find a gateway implementation that could be extended to handle these other protocols; either commercially or "homebrew" implementations would probably be fine as long as source is available. One possible alternative would be an ethernet store-and-forward gateway, but I have heard only vague information about two devices that might be useful: an very expensive box from Versalink (designed for linking ethernets which are physically far apart) and an as-yet-unannounced box (?) from DEC which I know little about. Does anyone have any more info on these or similar devices? - Chris P.S. I heard a rumor that MIT had developed store-and-forward gateway code for Bridge's hardware - if this is true, is it available? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985041916015500> Received: from cit-vax.ARPA by SRI-NIC.ARPA with TCP; Sat 20 Apr 85 00:12:52-PST Received: by cit-vax.ARPA id AA26664 at Sat, 20 Apr 85 00:01:55 pst Date: Sat, 20 Apr 85 00:01:55 pst From: engvax!KVC@cit-vax Message-Id: <8504200801.AA26664@cit-vax.ARPA> To: ."cit-vax!tcp-ip@sri-nic.ARPA"@__ENGVAX Subject: Re: Ethernet gateways.. I just had a meeting with the VITALINK people re: their ethernet bridge. What they've done is taken hardware from Bridge and built a completely protocol-independent gateway for linking ethernets. This is the same device that DEC is currently recommending. I have also heard that DEC is developing their own box, but don't know how true that really is. The VITALINK TransLAN (cute name, huh...) has a node on each ethernet that is going to be linked. The node listens to the traffic on the net and builds internal tables of known nodes as it sees traffic go by. The VITALINKs are also talking to each other, so the tables allow the box to map destination fields on one net to source fields on another. After whatever (configurable) learning period has gone by, the VITALINK boxes begin routing packets between one another based on the tables. They do continue to update tables after they start routing. The nice thing about this gateway is that it routes solely based on the ethernet packets. This avoids any dependency on higher level protocols. At the last DECUS symposium in Anaheim (southern california), they had a VITALINK link (via satellite) between ethernets in Anaheim, Boston (DECworld), and somewhere else in Mass. or New Hampshire. The had TCP/IP, LAT and DECnet all running on the one huge ethernet. I logged into a system in Boston using LAT without realizing at first where the system was. Of course the satellite delay gave things away, but it was still quite useable. It looks like the VITALINK bridges can be linked with just about any medium you care to name. I'm not exactly sure what interfaces the box has got on it, but we talked about leased phone lines (even as slow as 9600 baud), fiber optics, microwave, satellites, and T1. Currently the thing only supports a link up to 224kb, so full T1 is out. They are planning, however, to support up to full T1 speeds (1.something-or-other Mb), within a few months. Price seemed a little steep. I recall somewhere around $20,000 per box (and you need one per ethernet). It's so much more flexible than a 68000 doing IP routing, though, that we'd probably spring for it when the need comes up. Anyway, hope this helps someone out there. I've got phone numbers if someone wants to talk to VITALINK directly. Just drop me a message... /Kevin Carosso engvax!kvc @ CIT-VAX.ARPA Hughes Aircraft Co. ps. I have nothing whatever to do with VITALINK, beyond being interested in their product. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042004551500> Received: from DEC-MARLBORO.ARPA by SRI-NIC.ARPA with TCP; Sat 20 Apr 85 06:55:07-PST Date: Sat 20 Apr 85 09:55:15-EST From: Kevin Paetzold Subject: Re: IP gateways To: chris@COLUMBIA.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "chris@columbia.arpa (Chris Maio)" of Sat 20 Apr 85 09:28:36-EST Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 I agree with the recomendations for the VITALINK stuff. I spent a bit of time at the last DECUS playing with it and it seems to work really well. While I was playing with the VITALINK stuff something interesting happened. DECs engineering net got split in New England somewheres between a plant in Mass and a plant in New Hampshire. The network determined that the path through DECWORLD and DECUS and the rest of DEC was the optimal route and starting sending very huge amounts of traffic through the VITALINK stuff. It worked just fine. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042007570000> Received: from UCB-VAX.ARPA by SRI-NIC.ARPA with TCP; Sat 20 Apr 85 15:56:35-PST Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.24/4.45) id AA17096; Sat, 20 Apr 85 15:56:28 pst Received: by ucbarpa.ARPA (4.24/4.45) id AA05102; Sat, 20 Apr 85 15:57:13 pst From: medin%ucbarpa@Berkeley (Milo Medin) Message-Id: <8504202357.AA05102@ucbarpa.ARPA> Precedence: zap-mail Date: 20 Apr 1985 1557-PST (Saturday) To: chris@columbia.ARPA (Chris Maio) Cc: tcp-ip@sri-nic.ARPA Subject: Re: IP gateways In-Reply-To: Your message of Fri, 19 Apr 85 19:12:45 est. <8504200110.AA21047@ucbarpa.ARPA> The VITALINK box isn't really meant to do what you want to do, and its slow besides. We at NASA are using a box built by Applitek to build a backbone fiberoptic net to hook together various ethernets running different protocols. The box costs about 12K (this plugs into a CATV broadband cable, the details on the glass one escape me), and encapsulates the ethernet packet into a special protocol that is spoken on the backbone which doesnt have ethernet's distance and loading problems. Now, here's the best part, the sustained throughput from the ether to the backbone is 3 Mbits/sec. Thats a lot better than 224 kb or even T1. As usual, only outbound packets from the ethernets wind up on the backbone. This box doesnt deal with satellites like the vitalink does, so it can use less complex routing protocols inside. I think its based on a multi-68000 processor configuration. Check them out, its cheaper than Vitalink and is desiigned for what you want to do. Oh, you can hook more than 2 of these together to bridge several nets using one common backbone cable. Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042103474100> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Sun 21 Apr 85 05:47:27-PST Date: 21 Apr 1985 08:47:41 EST From: COINS@USC-ISI.ARPA Subject: HDLC TO DCP40 To: TCP-IP@SRI-NIC.ARPA cc: COINS@USC-ISI.ARPA ANYONE AT ALL HAS ANYONE INTERFACED AND HDLC IF11 TO A DCP40?? THE DCP40 WILL INTERFACE SPERRY EQUIPMENT AND THE IF11-HDLC WILL INTERFACE A DEC PDP1170 RUNNING UNIX 6.2. I GUESS THE REAL QUESTION IS HAS ANYONE WRITTEN AND HDLC INTERFACE TO RUN WITH UNIX 6.2 THKS,HAVE A NICE DAY RON SNITH ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042106335000> Received: from MIT-XX.ARPA by SRI-NIC.ARPA with TCP; Sun 21 Apr 85 08:34:30-PST Date: Sun 21 Apr 85 11:33:50-EST From: "J. Noel Chiappa" Subject: Re: 4.2 routing ... To: mogul@SU-NAVAJO.ARPA, bill%gvax@CORNELL.ARPA cc: TCP-IP@SRI-NIC.ARPA, xnsunix.pa@XEROX.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "Jeff Mogul " of Fri 19 Apr 85 20:59:00-EST Jeff is entirely on the mark. Passing LAN headers up is usually the wrong thing, unless you have a higher level protocol that depends on seeing them (like old NCP). The suggestion of having a 'Transmission Media Protocol' to convey information caused me to barf in my socks. It's true that you need this information, but inventing a protocol to do it is using a sledgehammer on a gnat. Packet nets are already under attack from people who say they are too complicated; let's try and keep it simple! The information about which interface a packet arrived on is one of a number of pieces of information that are properly associated with a packet but not part of it, and belong in the 'packet descriptor', along with obvious things like the address and length of the packet. This packet descriptor is almost inherently implementation dependant, although obviously they will all look pretty much alike. In the multi-protocol packet switch (i.e. gateway) that I did, the information about interfaces (both inbound and outbound) is kept as pointers to 'network structures'; the network structure is an abstraction that includes both data and code (as pointers to procedures), sort of like a CLU cluster. There is one structure for each network on the system, and they completely describe it to the upper levels of the network code. The other pieces of information that are kept in a packet descriptor are a pointer to the 'protocol structure' of the owning protocol (useful for things like informing the protocol layer if the network layer decides to discard the packet some time after it is given to the network layer), the destination address on the local network (kept here rather than in the packet for ease of access, since it is used for a variety of things, such as round-robining of output packets), the retransmit count (used on networks with low level flow control, since protocol performance degrades dramatically when packets get dropped, and you want to avoid doing that if at all possible), etc. In general, this is another case of the 'multiply-homed host versus packet switch' hassle. People think that because they have the former they have the latter. Not so; packet switches are much more complicated bits of mechanism. This is exactly why the IP architecture deliberately separates machines into hosts and gateways; the job of the gateways is much more complicated and will continue to change and get more sophisticated. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042206240000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Mon 22 Apr 85 08:27:30-PST Received: from SCRC-NEPONSET by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 219226; Mon 22-Apr-85 11:23:25-EST Date: Mon, 22 Apr 85 11:24 EST From: David C. Plummer in disguise Subject: 4.2 routing ... To: William A. Nesheim , TCP-IP@SRI-NIC.ARPA, xnsunix.pa@XEROX.ARPA In-Reply-To: <8504192030.AA11460@gvax.ARPA> Message-ID: <850422112419.1.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Fri, 19 Apr 85 15:30:48 est From: bill%gvax@Cornell.ARPA (William A. Nesheim) Question: Has anyone come up with a fairly generic template for a "Transmission Media Protocol" header that could deliver all the information needed for ICMP, Reverse-path forwarding of broadcasts, and Non-local broadcasts? One thing we did (Symbolics Lisp Machines) is to pass along the interface object that received the packet. What you then do is ask the interface "Hey, where'd this packet come from, anyway?" and give it the packet as a reference. It also passes in the protocol object (e.g., INTERNET, CHAOS, XNS). The query returns the hardware source of the packet, in the format specific to the interface, and (in the case of Ethernet if the address resolution cache has the entry) the software protocol address in the format specific to the protocol. From this the routing layer can do pretty arbitrary things and has all the necessary information to do so. I don't know how easy this is to backtranslate into more conventional programming languages and structures. I >am< convinced this is fairly generic (note it isn't a template). Also note that you only have to do this in not-too-frequent circumstances -- normal operation just processes the packet and sends it up to TCP (or whereever). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042211273800> Received: from MIT-XX.ARPA by SRI-NIC.ARPA with TCP; Mon 22 Apr 85 13:28:08-PST Date: Mon 22 Apr 85 16:27:38-EST From: "J. Noel Chiappa" Subject: Re: IP gateways To: chris@COLUMBIA.ARPA, tcp-ip@SRI-NIC.ARPA cc: JNC@MIT-XX.ARPA In-Reply-To: Message from "chris@columbia.arpa (Chris Maio)" of Fri 19 Apr 85 19:39:12-EST MIT does have a multi-protocol packet switch. It is called the C Gateway, and I developed it over the years 1980-1982 since I saw the need coming for what has since come to be called the 'multi-protocol spine' approach to networks. In this model, a single set of physical links and packet switches has layered on it a set of 'virtual' protocol networks, one for each transport protocol supported in the system. (Note that the protocol nets do not have to be congruent; in the MIT system some switches and nets are IP only, others are mixed, etc.) For people interested in more details to this approach, please send mail to Esther@MIT-XX asking for the "MIT Campus Network Implementation" planning document. The code was originally done for the PDP11. It has been ported to the 68K at MIT (this port should not be confused with the Portable C Gateway, which is a commercial deriviative I am working on); one of these ports was to the Bridge box. However, neither port was ever completed and put in service. The only service code at MIT is the PDP11 version. The code (both PDP11 and both 68K versions) is publicly available, however; people wanting it should contact Dave Bridgham, dab@mit-borax for more details. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042214520000> Received: from MIT-XX.ARPA by SRI-NIC.ARPA with TCP; Mon 22 Apr 85 16:52:19-PST Date: Mon 22 Apr 85 19:52:00-EST From: "J. Noel Chiappa" Subject: Re: Ethernet gateways.. To: engvax!KVC@CIT-VAX.ARPA cc: JNC@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "engvax!KVC@cit-vax" of Sat 20 Apr 85 03:22:33-EST Before everyone decides that digital filtering repeaters (i.e. what some people call bridges) are the answer to all the world's problems, let me point out a few disadvantages to that approach. The basic advantage of a bridge is that it operates at the network framing level (level 2 in the ISO model), so that the operation is invisible to the higher layers. The basic disadvantage of the bridge is that it operates at the network framing level, so that the operation is invisible to the higher layers. The key point here is that these boxes really are packet switches, and whenever you have packet switches, be they bridges (at level 2), or gateways (at level 3), you have the exact same set of issues and problems. However, while you may be able to deal with them at level 3 (the internetwork layer of the protocol), which is explicitly designed for this application, you usually can't at level 2. To begin with, an obvious problem is that you can't connect together networks with different level 2 formats via a bridge. Also, it has to be a network where hosts are uniquely identified. Finally, on networks that provide data reliability (checksums) and delivery acknowledgement as part of the network level, these can generally no longer be guaranteed in a system with bridges. This may cause problems with some application protocols. These are obvious, and are in fact not the worst problems. More serious ones come into play when you start to consider the effect of using different technologies in the links than in the networks on each end. An example would be a medium speed serial link between two bridges on Ethernets. Networks are all diferent, in obvious things like delay and bandwith as well as less obvious things like cost (X.25 links cost $$$) and authorization (most types of business traffic are not allowed on government data nets). These issues need to be considered in routing and other decisisions. For instance, a distributed algorithm running on a set of computers connected by a variety of links might adjust the communication protocol depending on the link type. On slow links, it might use a CPU-intensive method of exchanging data, whereas on a fast link it might use some simple approach that wastes bandwith. (Routing algorithms are a good example and some do vary their behaviour depending on the link type.) This sort of approach is clearly impossible in a system where the link characteristics vary if bridges are in use. Another example of problems in this regard are with what is called 'type of service' routing, where the user indicates to the network a particular type of service (e.g. low delay) and the gateways are expected to pick a route that minimizes delay. Clearly, if what the gateway thinks is an Ethernet includes satellite delays, it will not be able to route correctly. The IP system is starting to address the TOS routing issues now in the conext of satellite links, so this is not an unrealistic example. Finally, even if the bridges only operate over a homogenous set of links, there are still problems. Congestion control is one example. Switches can get overloaded. This is even true if the switch can operate at network speeds. Suppose you had two bridges (each of which can handle 10Mb/sec) into an Ethernet. If each of them is getting 6Mb/sec in, all of which must go into the single Ethernet, there is no way to do that, even though each switch is well below its performance limit. A lot of people think that bridges are also inherently faster. This is not so. Most of the work in packet switches of both types has to do with handling the network interfaces. Only a limited fraction has to do with parsing and constructing the level 2 headers and routing the packet. A little consideration will show that routing at level 2 is probably as expensive as routing at level 3, so the difference in performance is small. Based on extrapolation from measured performance on PDP11's, level 3 packets switches based on 12 MHz 68K's with no wait state memory should be over 4 Mb/sec, as fast as the best bridge figures given. I could go on for a while, but you get the idea. The basic problem is that these boxes are packet switches, just like gateways. Packet switches have a generic class of issues, and you don't solve thme by sweeping them under the level 2 rug. Bridges do have applications where they are the right thing, but they also have their limits. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042301170300> Received: from Xerox.ARPA by SRI-NIC.ARPA with TCP; Tue 23 Apr 85 09:17:19-PST Received: from Cabernet.MS by ArpaGateway.ms ; 23 APR 85 09:17:09 PST Date: 23 Apr 85 09:17:03 PST From: Murray.pa@Xerox.ARPA Subject: Re: Ethernet gateways.. In-reply-to: "JNC@MIT-XX.ARPA's message of Mon, 22 Apr 85 19:52:00 EST" To: "J. Noel Chiappa" Cc: engvax!KVC@CIT-VAX.ARPA, tcp-ip@SRI-NIC.ARPA Another problem with bridges.... It's harder to put bridges in parallel for greater reliability or more horsepower. If you use broadcasting to locate gateways, you even get some load sharing for free since the less loaded machine will probably respond first. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042306560000> Received: from CMU-CS-A.ARPA by SRI-NIC.ARPA with TCP; Tue 23 Apr 85 09:05:23-PST Date: Tue, 23 Apr 85 11:56 EST From: don.provan@CMU-CS-A.ARPA To: "J. Noel Chiappa" Subject: Re: Ethernet gateways.. CC: engvax!KVC@CIT-VAX.ARPA, JNC@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: "\"J. Noel Chiappa\"'s message of 22 Apr 85 19:52-EST" Message-Id: <23Apr85.115601.DP0N@CMU-CS-A.ARPA> I don't remember how we got on to this, but if I had two ethernets I wanted to talk to each other and nothing was commercially available, my first thought would be a level two router. It seems to sidestep several issues that would normally make coding such a beast a hassle. I wouldn't be very concerned about optimum routes or the gateway not being able to keep up with the networks. After all, anything would be better than the 0 baud link I started with. I'm not sure what I'm supposed to conclude from your observation that such a gateway is a level 2 packet switch. Aren't the ARPAnet IMPs level 2 packet switches? It's not really that different of an application in the simple situation. But then, I don't have any ethernets, so I may be full of it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042309575900> Received: from MIT-XX.ARPA by SRI-NIC.ARPA with TCP; Tue 23 Apr 85 11:56:47-PST Date: Tue 23 Apr 85 14:57:59-EST From: "J. Noel Chiappa" Subject: Re: Ethernet gateways.. To: don.provan@CMU-CS-A.ARPA cc: tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "don.provan@CMU-CS-A.ARPA" of Tue 23 Apr 85 12:07:18-EST Well, like I said, there are some cases where a bridge is useful. The one you mentioned (connected together two ISOLATED Ethernets) is such a case. However, in this day and age I think it is very unlikely (except in the commercial world) for networks to exist in isolation. As soon as you take those Ethernets and connect them to the Internet, you are better off with the interconnection being a gateway. I'm also dubious about the statement that it "seems to sidestep several issues that would normally make coding such a beast a hassle". To begin with, I don't think that most sites should be involved in building such things, just like you don't normally build CPU's or operating systems for support purposes (as opposed to research). You just go out and buy a box that does the right thing. Secondly, systems always grow, and things like loop detection (needed if you have redundancy, which is usually desirable) are problems in any packet switch system. See the papers on the DEC bridge, where they address these problems. In all but the most toy layouts generic packet switch problems appear. Since network systems tend to grow rapidly once available, toy installations soon become non-toy, and if you don't plan ahead for the problems they zap you. Yes, the ARPANet gateways are level 2 packet switches. They fact that they are, and that that fact is not visible at level 3, is becoming an immense drag. Consider; an FTP from Harvard to Stanford might profitably go over the ARPANet to BBN, over the high speed satellite net to SRI, and back over the ARPANet to Stanford. However, the fact that the ARPANet looks like a monolithic link at level 3 prevents this, since no information about connectivity and loading in the IMPs makes it up to the routing layer in level 3. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042311132600> Received: from SUMEX-AIM.ARPA by SRI-NIC.ARPA with TCP; Tue 23 Apr 85 19:12:52-PST Date: Tue 23 Apr 85 19:13:26-PST From: Mark Crispin Subject: NRC Report To: TCP-IP@SRI-NIC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 I have just finished reading the NRC report. I find myself feeling rather dissatisfied with it. It reads as if the NRC was charged to come up with an n-page justification as to why DoD should migrate from TCP to TP4 and that "if you can't dazzle them with brilliance, baffle them with bullsh-t." Given some of the names on the council, I wonder if this isn't far from the truth. Specifically, a great many issues are pushed aside quite casually with comments such as "it is expected that ISO will specify", "it is quite likely that...will [happen soon]", "a program of testing and development would minimize these risks", "the impact of this is uncertain...neither is better than the other". First the document acknowledges the great many TCP implementations in existance then it proceeds to state that all the vendors will rush to implement TP4 and ignore TCP. I may be willing to believe all these statements, but I am appalled by the lack of substantiation offered. I see no hard data for any of the several TCP => TP4 migration issues: . cost - what are the actual costs involved in converting DoD's networks over to TCP. It isn't enough to state that software will be available off the shelf -- what about machines that are operational now but don't have any commercial vendor developing software for them. What are the costs of retiring/replacing vs. DoD development of TP4 support software for them? . protocol operation - have any serious operational studies been made comparing TCP vs. TP4 in a production environment? I am not satisfied at all with the pat-on-the-head assurance that ISO will come up with suitable Internet layer specifications to provide the functionality of ICMP and EGP. I imagine it is too late to ask for any of this now (presumably a decision has already been made), but I really wish that more hard facts and figures had been presented instead of repeated assurances that all would be well and that the market sector would take care of DoD from now on. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042316112100> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Tue 23 Apr 85 22:10:52-PST Date: Tue 23 Apr 85 23:11:21-MST From: Mark Crispin Subject: NRC report To: TCP-IP@SRI-NIC.ARPA I don't want to be placed in the position of blindly saying the NRC's recommendations are blind/wrong or not well-thought-out. Now that I've read it, my main criticism is that it is not convincing. A rather vague set of promises and some rather sweeping statements are made with no hard data to back them. I am also concerned that if the NRC's proposal is adopted and TP4 does not pan out, the damage to the existing ongoing TCP development effort may be serious enough to be a major impact on the operational Internet. Whether or not TP4 is a "co-standard" as opposed to a "new standard", the fact remains that TP4 would be there to replace TCP. It's hard to imagine continued TCP development work in the face of such an impending migration. In order to support a migration from TCP to TP4, the Internet community is going to require better reasons than those the NRC report offers. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042318523000> Received: from MIT-XX.ARPA by SRI-NIC.ARPA with TCP; Tue 23 Apr 85 20:52:27-PST Date: Tue 23 Apr 85 23:52:30-EST From: "J. Noel Chiappa" Subject: Re: NRC Report To: Crispin@SUMEX-AIM.ARPA, TCP-IP@SRI-NIC.ARPA cc: JNC@MIT-XX.ARPA In-Reply-To: Message from "Mark Crispin " of Tue 23 Apr 85 23:29:05-EST I don't think I've heard from anyone (except the authors) who had nice things to say about this report. There are many substantial problems, some of which you noted, which have not been rebutted by those of the authors who defended the paper in this forum. Note that this report is in fact a recommendation, and is not necessarily binding on the DoD. Can anyone on this list (perhaps from DCEC or DCA or suchlike) tell us what the reaction is in those quarters to the substantive problems with the recommendation raised by Mark and others? Is the die in fact cast, or will the points raised by people in the Internet community be considered when the DoD makes its decision about what to do? Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042420461900> Received: from MIT-XX.ARPA by SRI-NIC.ARPA with TCP; Wed 24 Apr 85 22:44:23-PST Date: Thu 25 Apr 85 01:46:19-EST From: "J. Noel Chiappa" Subject: Info needed: TCP for VMS and MOS LHDH driver To: tcp-ip@SRI-NIC.ARPA cc: JNC@MIT-XX.ARPA I am looking for two pieces of information. First, does anyone know of TCP implementations for VMS? I know that there is one from Wollongong but don't know how good it is or how much it costs. Any others? Second, I need an LHDH driver for PDP11 MOS. Anybody have one? Thanks.. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042421570000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Wed 24 Apr 85 23:57:07-PST Date: 25 Apr 1985 02:57-EST Sender: CERF@USC-ISI.ARPA Subject: Re: Info needed: TCP for VMS and MOS LHDH driver From: CERF@USC-ISI.ARPA To: JNC@MIT-XX.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]25-Apr-85 02:57:15.CERF> In-Reply-To: The message of Thu 25 Apr 85 01:46:19-EST from "J. Noel Chiappa" Wollongong is reputed to be fairly good but buried pretty deep in the VMS kernel. NRC (the people who bring you hyperchannel) are doing one for VMS, but dunno the timeframe for delivery. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042504413700> Received: from cit-vax.ARPA by SRI-NIC.ARPA with TCP; Thu 25 Apr 85 12:46:12-PST Received: by cit-vax.ARPA id AA02808 at Thu, 25 Apr 85 12:41:37 pst Date: Thu, 25 Apr 85 12:41:37 pst From: engvax!KVC@cit-vax Message-Id: <8504252041.AA02808@cit-vax.ARPA> To: ."cit-vax!tcp-ip@SRI-NIC.ARPA"@__ENGVAX Subject: Re: TCP/IP for VMS There are (were) three implementations of TCP/IP for VAX/VMS that I know of. The most popular is probably the Wollongong one. As I understand it, it's a port of the UNIX kernel networking code to VMS in the form of a (large) device driver. Tektronix wrote a TCP/IP for VMS some time ago for their own internal use. They have been distributing it outside of Tek for a year or two now. It takes the form of an ACP (similar to the DECnet ACP). Advantages are that it's free and you get complete source. Disadvantages are that you cannot expect support from Tek. Informally, however, they've been pretty good to me about sending updates, etc. Also, the source is in BLISS, which could be a problem if you don't have a BLISS compiler. It probably isn't as complete as the Wollongong stuff. There used to be a TCP/IP from someone called COMPION. Distribution was taken over about a year ago by someone else I'd never heard of before called FlexComm. Don't know very much about this, except it looks fairly complete from their information packet. I heard rumours a long time ago that it was slow. That may not be true anymore. Since I have the Tek TCP/IP, that's the only one I know a lot about. The others are fairly expensive, but if you don't want to support it yourself that's probably worth paying for. Contacts for the three packages are: FlexComm Corporation - this address is a year old 15245 Pacific Highway South - product was called ACCESS Seattle, Wa. 98188 (206) 243-1641 The Wollongong Group - also a year old address 2103 El Camino Real Suite 104A Oceanside, Ca. 92054 (619) 439-5083 Tektronix: - this number worked a few weeks Noelan Olsen - ago (503) 627-5278 Hope this is useful to someone /Kevin Carosso engvax!kvc @ CIT-VAX.ARPA Hughes Aircraft Co. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042506273200> Mail-From: PERILLO created at 25-Apr-85 14:28:10 Date: Thu 25 Apr 85 14:27:32-PST From: Francine Perillo Subject: Re: Info needed: TCP for VMS and MOS LHDH driver To: don.provan@CMU-CS-A.ARPA, CERF@USC-ISI.ARPA cc: JNC@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "don.provan@CMU-CS-A.ARPA" of Thu 25 Apr 85 13:57:48-PST The April 1985 version of the TCP/IP Implementations and Vendors Guide has references to all the products mentioned in this list during the last few days. Please FTP a copy from the SRI-NIC host using pathname NETINFO:TCP-IP-IMPLEMENTATIONS.TXT -Francine ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042511450000> Received: from CMU-CS-A.ARPA by SRI-NIC.ARPA with TCP; Thu 25 Apr 85 13:56:49-PST Date: Thu, 25 Apr 85 16:45 EST From: don.provan@CMU-CS-A.ARPA To: CERF@USC-ISI.ARPA Subject: Re: Info needed: TCP for VMS and MOS LHDH driver CC: JNC@MIT-XX.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: <[USC-ISI.ARPA]25-Apr-85 02:57:15.CERF> Message-Id: <25Apr85.164552.DP0N@CMU-CS-A.ARPA> According to Hardcopy, NRC "is releasing" a network product called Fusion that supports IP/TCP. The article makes it sound pretty good, but then, all Hardcopy articles make their subjects look good. You can get more information, apparently, by writing them: Network Reseach Corp. 1101 Colorado Ave. Santa Monica, CA 90401 In case you want to look up the article, it's in the April, 1985 issue. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042517210000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Thu 25 Apr 85 21:18:15-PST Date: 25 Apr 1985 22:21-EST Sender: CERF@USC-ISI.ARPA Subject: Excelan From: CERF@USC-ISI.ARPA To: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]25-Apr-85 22:21:05.CERF> Has anyone had any experience with the EXCELAN TCP/IP? I have been asked about this but have not had any introduction or experience with it. thanks in advance. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042521500000> Received: from SU-AI.ARPA by SRI-NIC.ARPA with TCP; Fri 26 Apr 85 05:49:48-PST Date: 26 Apr 85 0550 PST From: Joe Weening Subject: Domain names To: tcp-ip@SRI-NIC.ARPA To allow a smooth transition to the new domain name system, I suggest that as hosts make the change to their new names, the NIC should update HOSTS.TXT with these names. (Keeping the old ones as nicknames, perhaps.) Otherwise when a host that does not yet query name servers tries to reply to mail containing a new domain name, it will fail. The point of adding the ".ARPA" names to HOSTS.TXT a while back was to make sure that everyone is able to parse domain-style names; hence there should be no technical problems in adding the new names. Joe ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042523170000> Received: from NOSC-TECR.ARPA by SRI-NIC.ARPA with TCP; Fri 26 Apr 85 07:18:50-PST Date: 26 Apr 1985 0717-PST From: Contr23 Subject: tcp etc for vms To: TCP-IP at SRI-NIC Reply-To: CONTR23 at NOSC-TECR Here at E-Systems we are currently implementing ip,tcp,ftp,telnet,smtp for the vax 11/780 vms. The work is a port of code we developed for an embedded m68000 system. It is written completely in Ada. We are now testing using our two vax's connected be ethernet. This is not a commercial product as such. The original code was developed using the telesoft compiler, and therefore contains many workarounds to accomidate that compilers limitations (it is a subset compiler). We are currently using the dec compiler, but since we are also supporting the 68000 version, we cannot make wholesale changes to the code until a more adequate compiler is also available for that micro. We are under contract to MIS JPMO for this effort, which is part of the 'nosc tools'; therefore the source code will be available to all who desire it. It currently is not on the net, but will be within the next month. We are also hoping that we will get the opportunity to further develop this code to result in a bone fide public domain highly useful portable implementation of the protocol suite. I will update this list on our progress and some preliminary results in the next few weeks. Paul Higgins E-Systems, ECI division. Correction: We are under contract to WIS JPMO. That acronym is misspelled above. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042603470000> Received: from Shasta by SRI-NIC.ARPA with TCP; Fri 26 Apr 85 13:04:39-PST From: imagen!geof@Shasta Date: Friday, 26 Apr 1985 11:47-PST To: shasta!CERF@USC-ISI.ARPA Cc: shasta!tcp-ip@SRI-NIC.ARPA Reply-To: imagen!geof@shasta Phone: (408) 986-9400 (work) Postal-Address: IMAGEN, 2650 San Thomas Expressway, Santa Clara, CA 95052 Real-Name: Geoffrey H. Cooper Subject: Re: Excelan In-Reply-To: Your message of 25 Apr 1985 22:21-EST. <[USC-ISI.ARPA]25-Apr-85 22:21:05.CERF> I can tell you something about them, although I have never actually held an excelan board in my hand, so to speak. Excelan has two multibus boards that contain front-end processors and Ethernet interfaces. The cheaper (older) board uses an 8088 and a state-machine based Ethernet interface. This is now deprecated in favor of a newer board that uses an 80186 and the Intel 82586 LAN controller. The boards can be purchased with "base" software, can boot software from the main host, or can be configured with TCP-IP ROM's. The TCP-IP is a port of the BBN code (I'm not sure if they took it direct from BBN or via Berkeley.). The board acts as a multibus master, and uses a message-passing protocol to communicate with the main processor. The TCP software appears to be "done right" -- it is possible to send and receive Ethernet, Internet, and UDP packets, as well as data from TCP connections. Last I saw, the boards implemented ARP, although you had to "enable" its use somewhere. I have seen connections between Excelan boards and SUN's and IMAGEN's and PYRAMID's, at the Usenix conference TCP demonstration last spring. The Excelan board thus appears to meet the specs sufficiently well to be useful. Excelan also has a Unix driver for their board that they will sell you. The driver implements a 4.1C socket interface (maybe they have 4.2 by now -- they are almost the same anyway) to TCP. They also have at least RLOGIN and RCP (don't snicker, I agree with you). I don't know about FTP, TELNET, and SMTP (although you can presumably port the berkeley sources very easily if you have access to them). The last I heard, the performance from the 8088 -- as expected -- was limited to about 80-100Kb/s total throughput (all connections). The 80186 and some software tuning apparently fix this problem. I don't think that they make claims anywhere near the 1 Mb/s FTP claims of CMC for THEIR board (10 MHz 68k + Lance chip). The price (I haven't a recent price list) I seem to remember as being around $1100 for the 8088-based board and around $1700 for the faster board. Maybe someone out there has better numbers than these. - Geof Cooepr Imagen ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042607480000> Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SRI-NIC.ARPA with TCP; Fri 26 Apr 85 09:48:25-PST Received: from HUDSON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 224711; Fri 26-Apr-85 12:48:19-EST Date: Fri, 26 Apr 85 12:48 EST From: Charles Hornig Subject: an experiment with domain names To: tcp-ip@SRI-NIC.ARPA cc: salex@RICE.ARPA, jnc@PROTEON.ARPA Message-ID: <850426124837.3.HORNIG@HUDSON.SCRC.Symbolics.COM> Since we at Symbolics have switched to using our domain name, we have had some trouble with other mailers not understanding them. To see how bad the problem was, I did a survey of the 1008 hosts advertising SMTP service in the NIC host table. I opened a connection to each of them from my machine and followed the following script for a simple mail relay from that host back to my mailbox. (220 Greeting message) HELO HUDSON.SCRC.SYMBOLICS.COM (250 Response) MAIL From:<@HUDSON.SCRC.SYMBOLICS.COM:Hornig@STONY-BROOK.SCRC.SYMBOLICS.COM> (250 Resonse) RCPT To:<@TARGET-HOST.ARPA:Hornig@STONY-BROOK.SCRC.SYMBOLICS.COM> (250 Response) DATA (354 Response) Test message to TARGET-HOST.ARPA. . (220 Response) QUIT (221 Response) The Symbolics.COM domain is registered with the NIC and both of its domain servers were running at the time of the test. Here are my results: 383 hosts were not up, not accessible, or refused the connection. 40 hosts refused to relay mail. 54 hosts complained about an unknown user name. 39 hosts complained about an unknown host name. 62 hosts complained about an unknown domain name. 43 hosts gave a variety of other errors or reset the connection. 387 hosts accepted the mail. Of the 387 hosts which accepted the mail, I have received the following responses: 5 from our local SCRC mailers. 1 piece of normal relayed mail. 2 notes from postmasters about strange conditions: --> a mail loop --> a host sending mail to itself I am not heartened by these results. Maybe we should go back to .ARPA, which people at least understand? Congratulations to PROTEON.ARPA, for being the only non-Symbolics mailer to relay the mail properly. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042609520000> Received: from EDN-VAX.ARPA by SRI-NIC.ARPA with TCP; Fri 26 Apr 85 11:50:17-PST Received: by EDN-VAX.ARPA (4.12/4.7) From: jrodrig@EDN-VAX (Jose Rodriguez) Date: 26 Apr 1985 1452-EST (Friday) To: CERF@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Excelan In-Reply-To: Your message of 25 Apr 1985 22:21-EST. <[USC-ISI.ARPA]25-Apr-85 22:21:05.CERF> A friend of mine integrated their outboard implementation (ethernet, I think) to a well known machine without a large effort. Considering that an inboard implementation of TCP is non-trivial I guess the Excelan product helped them a fair amount. I have seen the specs of their HFE protocol and they use a half reasonable scheme on top of dual ported memory. I have no figures on performance but at least it should not be too bad. (By the way I am talking about their TCP/IP/Ethernet Multibus product) Jose SDC McLean R&D jrodrig@edn-vax ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042612151500> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Fri 26 Apr 85 14:14:36-PST Date: 26 Apr 1985 17:15:15 EST From: MILLS@USC-ISID.ARPA Subject: On your experiment with domain names To: tcp-ip@SRI-NIC.ARPA Charles, I love your experiment. I quickly taught most of our fuzzballs how to tangle through the name-server jungle to get to your zoo. At the moment the fuzzy namesolvers can do that magic, but tcp connections to your stony-brook.scrc.symbolics.com host time out. On the other hand, ICMP echoes do work. Assuming your fe-mailer has temporary palsy, I left one fuzzy (dcn7.arpa) knocking on that door with an smtp greeting message. One of the troubles found here is that name service via the NIC is flaky due the multi-homing problem mentioned previously. Another seems to be that your name servers scrc-stony-brook.symbolics.com and friends do not return an authoritative "not found" for unknown hosts in the .symbolics.com domain. Rightly or not, our namesolvers report "server not responding" unless either an A record appears in the answer section or a "not found" is returned. Try tickling dcn1.arpa, dcn5.arpa, dcn6.arpa or dcn7.arpa with your script. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042910390000> Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Mon 29 Apr 85 18:49:51-PDT Date: 29 Apr 1985 1839 PST From: Ron Tencati Subject: Imminent Domains To: tcp-ip@sri-nic Reply-To: TENCATI@JPL-VLSI.ARPA I guess I'm a little confrused. In order to use the new domains, does my smtp program have to be rewritten, or can mail be forwarded to sites known to have domain servers, and will they route to the proper destination. I have not had time to read the latest RFC's, so I apologize for my ignorance until I do read them. Ron ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042911132400> Received: from MIT-MC by SRI-NIC.ARPA with TCP; Mon 29 Apr 85 12:11:38-PDT Date: Mon, 29 Apr 85 15:13:24 EDT From: Mark W. Terpin Subject: Excelan info To: tcp-ip@SRI-NIC Message-ID: <[MIT-MC].475211.850429.MWT> I've been using the Excelan board somewhat in conjunction with a TI NuMachine Unix running V7, and didn't have too much difficulty adapting the Excelan Unix driver to work. The only hard part was getting the nubus/multibus mapping to work. The Unix driver seems to have been culled from the 4.2 sources. It comes with servers and user programs for ftp, rlogin, rsh, and telnet. It doesn't have smtp, although they do provide a 'fake uucp' which uses tcp, that can be used to transmit mail, although I never installed it. ARP does sort of have to be enabled... basically, when you install it, you just have to give the '-e ARP' option to the netstart command in the /etc/rc file. This causes it to set a certain bit in the 8086 binary for TCP which gets downloaded to the Excelan board. The performance is decent, considering it's a model 101 with an 8088, and I'm using polling instead of interrupts -- it's been about as fast as the Chaos implementation on the NuMachine which uses a 3Com board. I could run some benchmarks if anyone is interested. (Excelan distributed some benchmarks with their latest software release a couple months ago, that were run on some Intel Unix workstation (whose processor is about twice as fast as the NuMachine's I've been told), and they reported to get 260 Kbits/second host-to-host throughput with the model 101 and 630 Kbits/second with the model 201, which has an 80186). /Mark (mwt@mit-mc) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985042917032600> Mail-From: MKL created at 30-Apr-85 00:03:45 Date: Tue 30 Apr 85 00:03:26-PDT From: Mark Lottor Subject: An extra bit To: tcp-ip@SRI-NIC.ARPA Disclaimer: This is a personal opinion based on the experiences of a few people. The contents of this message are not in any way connected with SRI International. We just spent 3 weeks debugging a problem with a 'homebrew' Ethernet interface. The problem was that we could talk to 3Com boards just fine, but we couldn't communicate with any Interlan boards. Well, to make a long packet short, we finally discovered the problem. We were transmitting ONE extra bit at the end of our packets. According to the Ethernet specs, this is acceptable and receivers should truncate excess bits to an even number of octets. The Interlan boards we used (about 10) did not do this and just threw the packets away, some of them never even reported seeing any packet go by. We therefore conclude that the Interlan board is in violation of the Ethernet spec. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985043004273700> Received: from USC-ISIF.ARPA by SRI-NIC.ARPA with TCP; Tue 30 Apr 85 11:26:19-PDT Date: 30 Apr 1985 11:27:37 PDT From: POSTEL@USC-ISIF.ARPA Subject: re: Imminent Domains To: TCP-IP@SRI-NIC.ARPA Ron Tencati: No and Yes. The first thing should be that funny names start appearing in the HOST.TXT file you copy from the NIC. Your SMTP should be able to handle that already -- if not, you better get to work right now. In a few months, many hosts will be using the domain service for listing their names and looking up other host names. You should have a plan for converting your SMTP to use the domain service by 15-July-85. You really should review RFC-921 (It is only 13 pages). --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985043004491500> Received: from UCB-VAX.ARPA by SRI-NIC.ARPA with TCP; Tue 30 Apr 85 11:49:22-PDT Received: by UCB-VAX.ARPA (4.24/4.46) id AA12066; Tue, 30 Apr 85 11:49:15 pdt Date: Tue, 30 Apr 85 11:49:15 pdt From: bellcore!sabre!martin@Berkeley Message-Id: <8504301849.AA12066@UCB-VAX.ARPA> To: tcp-ip@sri-nic.ARPA Subject: Re: Excelan Cc: bellcore!ucbvax!imagen!geof@Berkeley We have unibus excelan boards (exos/204) in some 5.0 vaxen's and they work well. the tcp/ip is a good implementation and we now have the code to deal with routing, so we can talk via gateways. they do have arp. we are talking to pyramids/suns/4.2vaxens/mit pc's. the library functions (to access files like /etc/hosts) are not the same as 4.2, but they claim they are changing that. i have got 4.2 programs to work without to much trouble. martin levy bellcore. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985043013270000> Received: from mitre-bedford by SRI-NIC.ARPA with TCP; Tue 30 Apr 85 14:35:05-PDT Date: Tuesday, 30 Apr 1985 17:27-EDT From: lfried@Mitre-Bedford To: tcp-ip@sri-nic Cc: lfried@mitre-bedford Subject: Performance of TCP-IP I am looking for data on the impact on system performance of using tcp/ip; also on the pros & cons of implementing these protocols in a FEP vs main processor. Any information on packet processing overhead due to the tcp and ip checksums would be useful. Personal experiences with these issues or references to publications dealing with them would be appreciated. L. Fried ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985043018452500> Received: from UDel-Huey by SRI-NIC.ARPA with TCP; Tue 30 Apr 85 19:44:25-PDT Received: From localhost.ARPA by UDel-Huey.ARPA id a027900 ;30 Apr 85 22:45 EDT To: lfried@MITRE-BEDFORD.ARPA cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Performance of TCP-IP In-reply-to: Your message of Tuesday, 30 Apr 1985 17:27-EDT. Date: 30 Apr 85 22:45:25 EDT (Tue) From: Mike Minnich The Computer Systems Research Group at Berkeley recently published a technical report on this topic that will give you some numbers on protocol processing overhead in UNIX 4.2BSD. Report No. UCB/CSD 84/217 ----MESSAGE-END----