----MESSAGE-BEGIN---- <1983060602360000> Return-path: Received: from USC-ISIF by SRI-NIC via DDN; 6 Jun 83 09:39:50-PDT Date: 6 Jun 1983 0936-PDT From: POSTEL at USC-ISIF Subject: SMTP use of TCP & impact of SATNET To: TCP-IP at SRI-NIC Mail-From: SMTP created at 6-Jun-83 09:16:20 Received: FROM [128.16.3.4] BY USC-ISIF.ARPA WITH TCP ; 6 Jun 83 09:16:32 PDT Date: 2 Jun 83 12:52:13 BST (Thu) From: Steve Kille (44a) To: knutsen @ sri-unix, dpk @ brl, mike @ brl cc: robert @ UCL-CS, steve @ UCL-CS, postel @ isif Subject: TCP performance across the Sattelite After finding the thoughputs we have been getting across the sattelite, we ran a packet trace. By some conicidence we caught a letter from SRI-KL running familiar code. There are two points on the way the SMTP uses the TCP as a transport: 1. The command line is split into two parts, the command and a pair. Both parts are pushed (delivered with an EOL marker), this is ineficient for the receiving TCP/host. 2. The data part is sent on 40 byte pieces, with an ACK required for each piece before sending the next. Each 40 bytes is pushed (EOL bit set). Thus on a call to the UK (3 sec approx round trip time) you get about 10 bytes/sec. IT IS possible to put more than 40 bytes of data into a TCP packet, and IT IS NOT necesary to push every packet. Robert Cole + Steve Kille ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983060604350000> Return-path: Received: from USC-ISIF by SRI-NIC via DDN; 6 Jun 83 11:37:27-PDT Date: 6 Jun 1983 1135-PDT From: POSTEL at USC-ISIF Subject: re: smtp use of tcp & impact of satnet To: TCP-IP at SRI-NIC Small segments may help in some situations, and setting the push bit on every segment may help is some situations, but it is hard to see how sending the command in one segment and the line ending CR-LF in the next segment helps anybody. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983060604535900> Return-path: Received: from SU-SCORE by SRI-NIC via DDN; 6 Jun 83 13:04:57-PDT Date: Mon 6 Jun 83 11:53:59-PDT From: Mark Crispin Subject: Re: SMTP use of TCP & impact of SATNET To: POSTEL@USC-ISIF.ARPA, steve@UCL-CS.ARPA, knutsen@SRI-UNIX.ARPA, dpk@BRL.ARPA, Mike@BRL.ARPA cc: TCP-IP@SRI-NIC.ARPA, robert@UCL-CS.ARPA In-Reply-To: Message from "POSTEL at USC-ISIF" of Mon 6 Jun 83 09:36:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It sounds very much like you're running into an SMTP sender using the interim TCP I/O routines I devised for the BBN system call interface on TOPS-20. I'm sorry for your difficulties; you are quite correct that Push is set every 40 bytes. Your claim that a Push is done before the CR/LF surprises me but it's possible you're right. This was done in January and February out of operational necessity. I discovered that any number of SMTP receivers simply would not work unless you did a Push quite often. The problem occurred with a wide range of systems. To coddle the systems and enable communication to work at all, I went to some trouble to guarantee a Push every 40 bytes. In April, I tested it again. I found that while the problem was by no means as widespread as it once was, a number of sites still exhibited it. I felt it was advisable to be as conservative as possible and to continue frequent Push'ing. It is now June and supposed the long-overdue DEC system call interface is going to be released shortly. As the present Push-every-40-byte implementation has been shown to work (albeit inefficiently), I'm unwilling to change it this late in the game. I fully intend to try running the DEC interface with Push set only when dictated by the protocols and see if I can get away with it today. Again, I apologize for any inconvenience this has caused you. You have run up against a piece of interim software that is (or until very recently was) compelled to do the behavior you exhibited to coddle hosts with faulty implementations. The penalty for not doing so is (was) not getting your mail through. Regards, Mark Crispin ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983060605500700> Return-path: Received: from SU-SCORE by SRI-NIC via DDN; 6 Jun 83 12:49:55-PDT Date: Mon 6 Jun 83 12:50:07-PDT From: Mark Crispin Subject: re: smtp use of tcp & impact of satnet To: POSTEL@USC-ISIF.ARPA cc: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "POSTEL at USC-ISIF" of Mon 6 Jun 83 11:35:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I can think of one scenario in which the command in one segment and the CR/LF in another segment could occur, and that is if the command is exactly 40 bytes. The algorithm is 40 byte segments or an explicit Push from the higher level software, whichever comes first. The message from UCL implied that the CR/LF separation was something separate; I'd appreciate hearing (offline from TCP-IP) where in the SMTP transactions this has been observed, e.g. "after HELO and DATA, but not RCPT or MAIL", etc. This is a real bug, albeit relatively minor; however, I will be pleased to fix it. When DEC's new release of TCP comes out, I intend to start fresh by sending full-sized segments and only setting Push where it is required by SMTP. I will collect some more formal observations than was possible in the hurried days of January. If I still feel there is a need for smaller segments I will publish my observations for general discussion and consideration of the list. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983060614035300> Return-path: Received: from CMU-CS-C by SRI-NIC via DDN; 6 Jun 83 15:05:51-PDT Received: ID ; 6 Jun 83 18:03:53 EDT Date: 6 Jun 83 18:03:53 EDT From: Vince Fuller Subject: FTP server lossage on TOPS-20 and Tenex sites To: TCP-IP@SRI-NIC It would appear that the Tenex/TOPS-20 FTP server does not correctly implement the CWD command. There are two different problems: 1. CWD on Tenex gives an invalid directory error. It does, however, accept CWD directory (e.g. w/o <>'s). Is this the correct thing to do for Tenex directory names? 2. The FTP server always tries to connect to the directory specified. If the logged-in user does not have connect access, it sends back a 331 - send password. If the user process then seds a password, it gets a 503 - already logged in error. Since I don't know much about Tenex, it remains for someone else to answer the first question. As for the second: according to the RFC, this is a violation of the protocol - a CWD isn't supposed to get a 331 back. Perhaps the server should implement CWD by redefining DSK: to be the specified path? This would be an easy change, and would implement CWD basically the same way that Unix does. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983060619000000> Return-path: Mail-From: SMTP created at 7-Jun-83 09:47:43 Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 7 Jun 83 09:48:06 PDT Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 7 Jun 83 7:05 EDT Sender: Mike Muuss From: TCP-IP@brl To: TCP-IP@brl Date: 7 June 1983 00:00 EST Subject: TCP-IP Digest, Vol 2 #8 TCP/IP Digest Tuesday, 7 June 1983 Volume 2 : Issue 8 Today's Topics: Digest Numbering Mixup on V2#06 Comments on Host-Table RFC InterNet -vs- SubNet Routing More on SubNet Routing Network Humor: C/30 Power Wiring ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- Date: 7 Jun 83 6:11:27 EDT (Tue) From: Mike Muuss (TCP-IP Digest) To: tcp-ip@brl Subject: TCP-IP Digest Numbering Error The 24-May issue was incorrectly marked as being V2#05 when it was in fact V2#06. V2#05 was published on 26-Apr V2#06 was published on 24-May and V2#07 was published on 25-May. My thanks to the many people who pointed out this error. Best, -Mike ------------------------------ Date: 6 Jun 83 5:20:18 EDT (Mon) From: Ron Natalie To: tcp-ip@brl-bmd Subject: Host table RFC Since M. Crispin put out a real request for comments, I'm commenting. He has many good points, but I don't feel that his preferred solution is optimal. He points out that the NIC is not always careful of notifying users of host table updates. He suggests that the NIC send out the individual updates to the hosts as the database is modified. My observation is that the NIC is very reliably mailing me letters about the tables being modified, but they batch up the submissions before entering them in the database. Every day I load up the host list using the provided server. It generally is identical every time except for the biweekly (or whatever) event when they put in the new entries. If this mode of operation is to be continued, I suggest that Mark's suggestion #2 is better. This allows a host to query version number of the hosts database as many times per day as he feels necessary and only transfer the entire file when it has been changed. This can easily be done without altering any of the existing or creating any new protocols by adding a "VERSION" keyword to the RFC811 hostnames server. This will return some string that is guaranteed to be different for each revision of the database. In this way a majority of the inquiries are very short TCP connections rather than the time it takes to retrieve an entire copy of the table. VERSION --> To nic host server VERSION : 1234 <-- Back to host. -Ron ------------------------------ Date: Thu, 26 May 83 17:38 PDT From: Taft.PA@PARC-MAXC.ARPA Subject: Internet vs. subnet routing To: TCP-IP@Brl.ARPA This has been a most interesting and constructive discussion. I would like to compliment the participants for their careful, well thought-out presentations, and to offer a somewhat different approach to the problem. There are good arguments on both sides of the issue of Internet vs. subnet routing: -- Assigning each local network its own IP network number has the virtues of simplicity and of taking maximum advantage of the Internet routing algorithm, but the disadvantage of propagating excessively large amounts of detailed routing information to all parts of the Internet. -- Adopting a hierarchical structure, with each cluster of local networks treated as a single IP network, reduces the spread of irrelevant routing information, but has the disadvantages of requiring duplication of routing mechanisms and of making poor routing decisions when clusters are interconnected in more than one way. In the design of the Pup Internet protocols, we used the first approach (which I believe is still used in the Xerox NS protocols). We regularly have over 100 networks up at a time, and the distribution of routing information is still manageable. However, if we had an opportunity to do the design over again, we would likely try to combine the best features of both approaches. The main problem with simple "area routing" strategies is that, in the absence of knowledge about the internal structure of an area, they can't know how to select the correct gateway into it. If the area in fact has a rich internal structure and has many gateways into it, the routing algorithm will make bad choices and the resulting performance will be very poor. Suppose, for example, we carried DOD IP traffic in the Xerox Internet (we don't, but there's no reason in principal that we couldn't). And suppose the DOD and Xerox internets were interconnected not just in Palo Alto, California but also in Webster, New York. It would clearly matter a great deal which of the two gateways you chose to route packets to when sending to a destination within Xerox. This means that some aspects of the internal structure of the Xerox Internet would have to be distinguishable from the rest of the DOD Internet, which in turn means that it would have to be assigned more than one IP network number. Well, how many? Two? Ten? A number that varies as the topology changes? You see the problem. An alternative way of approaching this is not to adopt a hierarchical structure for network addressing as a whole, but only for the propagation of routing information. That is, routing information flows only along the branches of the hierarchy, but the routes computed for transport of IP packets are not so constrained. Each network in a "cluster" gets its own unique network number, addressable from anywhere within the Internet. The normal IP routing algorithms are used for communication within the cluster. However, detailed routing information about individual networks in this cluster is NOT automatically propagated throughout the Internet. What is instead propagated everywhere is a route to some gateway (or more precisely, some routing information server) that has enough local knowledge to compute a good route to the precise desired network. This information is cached by the gateways along the route, maintained until it falls into disuse or stops working, and then forgotten. In this way we decouple the structure of the routing information hierarchy from the actual structure of the Internet as embodied in IP addresses. This is just as well, since "clusters" may often represent administrative entities that bear little relation to the overall Internet topology. Of course, there are many details I haven't discussed here (indeed, I haven't worked them out), and much careful design work would have to be done to make such a scheme work smoothly. However, it does seem promising as a way of combining most of the good features of the two approaches previously discussed. Additionally, it is entirely transparent to host software and requires new routing update algorithms to be implemented only in gateways. By the way, as someone pointed out, the parallels between this and the domain naming issue are striking. Much confusion may be avoided if we maintain a clean separation between names, addresses, and routes. I highly recommend John Shoch's paper, "Internetwork naming, addressing, and routing", which appeared in the 1978 IEEE CompCon proceedings. It was also distributed as IEN-019; I haven't been able to find it on-line anywhere, but I expect Jon can. Ed Taft ------------------------------ Date: 27 May 1983 0857-EDT (Friday) From: Thomas Rodeheffer@cmu-cs-a To: TCP-IP@brl Subject: subnet routing Well, I'm real glad to see subnet routing get some air time, because there are a lot of tricky issues involved and I'd like to see some of them sorted out before we at CMU have to plunge into building our own implementation (which is imminent). In TCP-IP 2(7) Larry Allen and Mike O'Dell described what is happenning at MIT and LBL, respectively. I'll call these the MIT and LBL schemes. Since I like to rehash the issues, I'll summarize both of these schemes and state what I see as their advantages and disadvantages. The MIT scheme can be summarized as postulating a function ExtractNetworkNumber: IPaddress -> IPaddress that is used in the internet module everywhere that network numbers are contemplated: principally, during IP routing. The MIT scheme requires that this function be changed so that, when in the context of MIT, addresses that refer to MIT's particular network are treated specially, in that some of the "rest" bits, which everywhere else in the world would be ignored as not relevant, are treated as part of the network number. Although gateways between MIT and the rest of the world have to be moderately schizoid (because "the context of MIT" changes from one side to the other), everybody completely inside or outside of MIT can just swim right along, and everything will work perfectly. This is essentially the same scheme as propounded by Chris Kent of Purdue. It has the advantage that within MIT all of the routing mechanisms of IP are applied to the problem of moving a datagram from one place to another. You don't need to implement any local routing mechanisms. Indeed, assuming that the gateway-to-gateway protocol sent around routing updates without attempting to compress the data based on "knowing" what class A, B, and C network numbers looked like, internal gateways at MIT could be identical to their brethern everywhere else in the world. The disadvantage is that because the special treatment of MIT addresses is not part of the IP standard, all code that is imported to MIT has to be "upgraded" before it will work at MIT. Because the necessary change may require rooting around all through the internet module to find the places where network numbers are used (not necessarily so nicely modularized as an ExtractNetworkNumber function), even when source code is available it may be quite difficult to carry out. The LBL scheme can be summarized as postulating an external mechanism for translating IP addresses to local network addresses (the address resolution protocol) and a local system of gateways that "transparently" route packets around between various subnets so as to give the impression to the internet module that it's looking at a flat, completely connected network. The gateways respond to address resolution requests on behalf of hosts on other subnets, giving the local network address of the best first-hop gateway. Thus packets destined for other subnets get sent right to the appropriate gateway without the host even having to know what is going on. Because some sort of address resolution protocol is needed anyway in order to do anything intelligent with IP packets on the popular 10mb Ethernet, there is a good chance that the LBL scheme will not require modifying the software of any host that is to be plugged into it. This is a major advantage. The major disadvantage is that you have to your own local gateway code and routing update algorithms. This may not be so hard if you have friends at other sites who have already done exactly the same thing. A second disadvantage is the presence of a very subtle violation of the Internet Protocol specification. The problem arises in connection with the separation between the internet layer and the local network layer. The way I read RFC 791, the internet module has the responsibility of deciding for each datagram what address inside the network it should be sent to and the local network interface has the responsibility of getting it there. This is not quite what happens in the LBL scheme. An example should help illustrate the situation. Suppose that A1, C1, and D1 are stations on network 1, and D2 and Z2 stations on network 2. D1 and D2 are two halves of an internet gateway. Network 1 is actually divided into two subnets, connected by B1a and B1b. I will denote the physical network's address corresponding to an internet address X as @X. ====+======+========+=== ==+==========+===== | | | | | A1 C1 B1a~~~~~~~~B1b D1 * * C3 D2 Z2 | | | ==+== ====+=========+== Suppose that A1 wants to send a datagram to Z2. Noticing the different network number, A1 consults its routing tables and decides that D1 is an appropriate gateway. A1's internet module calls up its local network interface, and says: Send "SRC=A1,DEST=Z2,DATA=xxx" to D1 A1's local network interface does address resolution on D1 and gets @B1a. So off goes the packet: To: @B1a, From: @A1, Type: DoDIP, Data: "SRC=A1,DEST=Z2,DATA=xxx" Observe that at this point all knowledge of D1 has been lost. What B1a has to do is peek inside the datagram and recompute the IP routing for Z2. With any luck, it will come up with the same answer that A1 did. Of course, it might come up with C1 instead. That would be unfortunate, especially if C1 were an ordinary internet gateway that didn't understand about the fancy subnet routing that was going on. You might see a whole slew of ICMP redirect messages come piling into A1 as C1 valiantly tried to push the datagram through B1a. At the IP level the problem would be characterized as a persistent delivery error in the local network. The problem is that the local network interface isn't acting as a transparent delivery mechanism for the internet layer. It is usurping some of the routing responsibility that according to the specification ought to be performed by the internet module. The IP specification assumes that if a datagram is wandering off course inside the same network as the datagram's source, then it's the fault of the source, who was supposed to route the datagram properly in the first place. This is the position taken by the ICMP redirect message, whose purpose is to correct such misroutings. As my example shows, it wouldn't be safe to use ordinary internet gateways with the LBL scheme because the responsibility for routing errors is not always vested where the gateway would expect. I should note that if you only have one external gateway the misrouting problem never comes up (at the IP level). As a side issue, if subnet routers are going to have to perform IP routing anyway in order to second guess where packets are supposed to go, why not go the whole hog and punt IP routing from hosts entirely. Let the address resolution take any random IP address and return an appropriate physical network address. Of course, the host software wouldn't be complete IP implementations any more. I'm not saying this is bad, but it is not an implementation of IP according to the full specification. There are two ways one could modify the LBL scheme in order to make the local network delivery transparent to the internet layer. Neither of these are very attractive. The first way is to change the encapsulation of IP packets by adding a field to the physical packet to carry the local network destination address through the subnets. In my example, this would mean arranging for A1's local network interface to transmit the packet: To: @B1a, From: @A1, Type: DoDIPx, DeliverTo: D1, Data: "SRC=A1,DEST=Z2,DATA=xxx" This of course means changing all local network interfaces everywhere on the local network, which erases the major advantage of the LBL scheme of not requiring any host software modifications. Back when I gave my example, I sneaked the issue of packet encapsulation past you, assuming an encapsulation that was similar to those used by all implementations I am familiar with, one which is indeed the obvious encapsulation to use under the assumption that the local area network implements an entire IP network. I am not aware of any formal specifications of IP packet encapsulations, although of course such specifications are necessary if IP implementations are ever really going to be compatible. The second way is to require that the address resolution function be one-to-one instead of many-to-one. In other words, address resolution must produce a physical local network address that uniquely identifies the desired IP address, at least when considered within the subnet in which the address resolution was performed. In this situation, the subnet gateways could rederive the local network destination address by inverting the address resolution on the physical destination address of the packet. The physical address space of the 10mb Ethernet is so large that imbedding an entire IP network within it is no problem, but this could be impossible on other kinds of local area networks. Of course, subnet gateways would have to attend to some potentially very large set of addresses to which packets could be sent. The question remains whether the original LBL scheme is suitable, even though it violates the separation between the internet and local network layers. It might be that the benefit from being able to attach hosts with software written according to the existing IP specification and common-law packet encapsulations overweighs the disadvantage of having slightly illegal routing behaviour. -Tom Rodeheffer ------------------------------ [ While this message does indeed detail an error in the C/30 documentation, it is published here because of the humorous nature of the mixup. -Mike ] Date: 6 Jun 83 5:34:02 EDT (Mon) From: Ron Natalie To: tcp-ip@brl-bmd cc: romash@bbn-unix, brescia@bbn-unix, taccers@bbn-unix Subject: C-30 Site Preparation BRL has taken delivery of eight C-30 processors to act as IMPs and TACs on our CAN [Campus Area Network -Mike]. While reading the site preparation guide provided by BBN, I came across some unusal problems that I had not planned for. The first line in section 2.2 (page 2-3) states that "The receptacle MUST be wired as shown in figure 2.2." Figure 2.2 (same page, labeled "Wiring of Power Receptacle) indicates some interesting power considerations to which I was unacustomed. I had no problem figuring out what to do with contact number 1 labled "frame ground", and I assume that I can jumper "request to send" to "clear to send", since I always want power flowing, but contacts 2 and 3 for "received data" and "transmitted data" really have me confused. Figure 2.2, although labeled "Wiring of Power Receptacle", depicts how to turn two DB-25's into an RS-232 null modem. Interesting, since the only other place that this figure appears is on page 3-9 where it is identified as Figure 3.6 and again as "Wiring of Power Receptacle", this time for the C-60 and C-70 processors. I suggest that BBN would be better off if they adopted the more standard three wire (hot, neutral, and ground) system of power. -Ron ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983060712280000> Return-path: Received: from KESTREL by SRI-NIC via DDN; 7 Jun 83 22:09:56-PDT Date: 7 Jun 1983 1928-PDT From: Lynn Gold Subject: Re: FTP server lossage on TOPS-20 and Tenex sites To: VAF at CMU-CS-C, TCP-IP at SRI-NIC Address: Kestrel Institute, 1801 Page Mill Rd., Palo Alto, CA 94304 Phone: (415) 494-2233 In-Reply-To: Your message of 6-Jun-83 1803-PDT On Tenex, one connects to directories without typing in angle-brackets. The CWD command on Tenex sites DOES do the right thing How does Unix implement CWD? --Lynn ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061419000000> Return-path: Mail-From: SMTP created at 14-Jun-83 21:52:47 Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 14 Jun 83 21:52:56 PDT Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 14 Jun 83 23:28 EDT Sender: Mike Muuss From: TCP-IP@brl To: TCP-IP@brl Date: 15 June 1983 00:00 EST Subject: TCP-IP Digest, Vol 2 #9 TCP/IP Digest Wednesday, 15 June 1983 Volume 2 : Issue 9 Today's Topics: Pointer to Naming, Addressing, & Routing Memo Routing of Routing Messages -vs- Data Messages Fix for BBN VAX TCP Problem Comments on SMTP Design Flaw + Discussion Request for TCP/IP Implementations on Micros Wanted: Spooled FTP for BBN UNIX TCP ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- Date: 7 Jun 1983 1419-PDT From: POSTEL@usc-isif Subject: IEN-19: Names, Addresses, and Routes To: TCP-IP@brl The memo by John Shoch titled "Inter-Network Naming, Addressing, and Routing", issued as IEN 19 was produced using some fancy formating and printing facilities at Xerox PARC and was distributed only in hardcopy. The later (and improved) version of this memo with the same title was presented at COMPCON Fall 1987. The order number from the IEEE Computer Society is CH1388-8/78-0000-0072. --jon. ------------------------------ Date: 7 Jun 1983 1435-PDT From: POSTEL@usc-isif Subject: Routing Messages vs. Data Messages To: tcp-ip@brl Ed Taft's comments on routing information exchange being distinct from the actual routes that data traffic moves on are well taken. One aspect of the development of the Exterior Gateway Protocol (RFC 827) is to allow testing of different routing procedures in subsets of gateways without interfering with the actual transmission of data datagrams. The logical systems of gateways in EGP are independent of the actual network topology. --jon. ------------------------------ Date: 8 Jun 1983 9:32:11 EDT (Wednesday) From: Dennis Rockwell Subject: TCP problem To: Rob Gurwitz , dpk@brl-vgr [ This message was forwarded to the Digest by Doug Kingston, and details a particularly insidious bug in the BBN VAX TCP. Hopefully, if any site using that code has not heard of this problem yet, this message will have served a purpose. Note that Berkeley 4.1a and 4.1c code does not have this bug. -Mike ] The fix for this bug is as follows: (I'm afraid I have no familiarity whatsoever with the TCP variants, but the code should be fairly easy to find) In the routine rcv_text (in tcp_procs.c in our code), the routine that does the resequencing, there is the following code: /* new overlaps at beginning of successor frags */ q = savq->t_next; while ((q != (struct th *)tp) && (t->t_len != 0) && SEQ_LEQ(q->t_seq, last)) /* complete cover */ if (SEQ_LEQ(t_end(q), last)) { p = q->t_next; tcp_deq(q); m_freem(dtom(q)); q = p; } else { /* overlap */ In your code, the first SEQ_LEQ is probably a SEQ_LT. This is the bug. There is an analogous bug in ip_input.c: /* new overlaps at beginning of successor frags */ q = savq->ip_next; while ((q != (struct ip *)fp) && (ip->ip_len != 0) && (q->ip_off <= ip->ip_end)) /* complete cover */ if (q->ip_end <= ip->ip_end) { p = q->ip_next; ip_deq(q); m_freem(dtom(q)); q = p; Again, in your code the first <= is probably a <. This fix was made just last week, and is slowly percolating out to the other local BBN sites. We are trying to spread this fix around, but that's difficult. Please tell everybody you know who is running this code about the fix. Good luck! Feel free to write or call me at (617) 497-2643. ------------------------------ Date: 8 Jun 83 5:39:10 EDT (Wed) From: Doug Kingston To: tcp-ip@BRL-VGR Subject: SMTP Design Flaw SMTP as it currently stands has a serious flaw from the point of view of fault-tolerant software. The crux of the problem is that the reply codes reuse certain values in different contexts. This opens the possibility of of mis-interpreting replies in the case where the user-smtp or the transmission channel is generating spurious data. A similiar problem exists if the smtp server generates spurious responses. If both sides are bug-free, there will be no problems. But, the world of software is seldom if ever bug-free. A prudent implementer plans for the inevitable error to be made by the hardware, his own software, or someone else's software. Spurious commands or spurious responses can cause the server/user pair to get out of sync without either being able to conclusively detect the situation. The worst problem exists for the 250 reply which is the affirmative reply from HELO, MAIL, RCPT, "final dot", and RSET to name only the most commonly used commands. The 500, 501, and 503 commands are also dangerously overloaded. Senarios: RCPT --> unknown to sender junk --> <-- 250 DATA --> <-- 500 (actually reply to junk) Result: Mail is returned wrongfully. ******************** RCPT --> unknown to sender junk1 --> junk2 --> (we are now off by two...) <-- 250 RCPT --> <-- 500 (actually reply to junk1) DATA --> <-- 500 (actually reply to junk2) we detect problem RSET --> <-- 250 (actually reply to second RCPT !!!) MAIL --> <-- 354 (bletch.) (Protocol errror) RSET --> <-- 250 (reply to first RSET!!!!!) MAIL --> <-- 250 (reply to first MAIL... RCPT --> <-- 250 (reply to second RSET... RCPT --> <-- 250 (reply to second MAIL... ... until we get to the DATA command again. Result: Mail is returned wrongfully. ******************** RCPT --> unknown to sender junk --> <-- 250 RCPT --> <-- 500 (response to junk) RCPT --> <-- 250 (response to SECOND rcpt command!!!) ******************** RCPT --> unknown to sender RCPT --> <-- 250 RCPT --> <-- 250 (response to Second RCPT !!!) RCPT --> <-- 250 (response to Third RCPT !!!) DATA --> <-- 250 (response to Fourth RCPT !!!) *********************** As I see it, there are two things that can be done done to help out this situation. First, the reply codes should be unique for each command. This would give the USER SMTP the ability to detect sequencing errors from syntax or argument errors which some hosts give on hosts they don't know how to reach, but I wont drag the offenders out into public here. They know who they are. Second, and perhaps more radical, is to add a sequence number each command/reply pair. Each command would be sent with a sequence number. The reply to that command would have to contain the same sequence number. This would allow both the server and user SMTP to detect sequenceing errors. I feel that this would be the most prudent and reliable mechanism for detecting these faults. This problem is not just a figment of my imagination. This very problem has plagued mail between out sites and sites running BBN based TCP implementations for about a month now. The spurious input was probably induced by a bug in the BBN TCP's handling of the sequenceing and/or retransmission or large numbers of incoming 1 character packets due to a bug in my mailer that caused it not to buffer its output. Comments and Discussion are Welcomed -Doug- ------------------------------ Date: 8 Jun 1983 1445-PDT From: POSTEL at USC-ISIF Subject: Re: SMTP Design Flaw To: dpk at BRL-VGR, tcp-ip at BRL-VGR Doug: SMTP explicitly requires that it be operated on a reliable channel (such as provided by TCP). The situation you suggest does not arise because of "junk" being inserted in the channel unknown to the sender. There was (still is?) a totally bogus "implementation" of SMTP that sent several commands in succession without even looking at the replies. I suggest that it is better to assume a reliable channel than to reimplement TCP inside of SMTP, and to stomp out bad implementations of SMTP as soon as we see them. --jon. ------------------------------ Date: 8 Jun 83 18:13:50 EDT (Wed) From: Doug Kingston To: POSTEL@Usc-Isif cc: dpk@BRL-VGR, tcp-ip@BRL-VGR Subject: Re: SMTP Design Flaw Jon, I do not dispute that the problem is induced by a faulty SMTP or channel. I am arguing for cheap enhancements the buy us a great deal of fault tolerance. Obviously we're not going to change SMTP, but I think this should be kept in mind for later incarnations. Faults will occur. Mail software should make every effort to detect and deal with errors. We need to give it a mechanism, and it doesn't have to be complicated. The problem with bugs is that is they're so ingenious, -Doug- ------------------------------ Date: 9 Jun 1983 17:53:43-PST From: ram.arizona@rand-relay Subject: TCP/IP on Micros? To: tcp-ip-request.brl@rand-relay [ Anybody having information about micro implementations, please feel free to either contact Ralph directly, or to submit a message to the digest for all to see. -Mike ] I am interested in locating information on tcp/ip implementations on microcomputer systems. Specifically, on the LSI-11/23, 68000, and 8086. I would like to know the language, operating system, and availability of such implementations (costs). Thanks for passing on this request. ----Ralph Martinez (ram.arizona@rand-relay) University of Arizona ------------------------------ Date: 9 Jun 1983 8:36-PDT (Thursday) From: Jim Rees Subject: Want spooled FTP for BBN Unix TCP To: tcp-ip@brl, bbn-tcp@bbn-vax I am running BBN's TCP on a Vax with 4.1bsd. I want a spooled FTP, something like uucp, to run over the net between Unix machines. Has anyone already done this? Does anyone have bright ideas? ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [579%40brl-bmd.UUCP] <1983061419410100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: TCP-IP%brl@brl-bmd.UUCP Newsgroups: fa.tcp-ip Subject: TCP-IP Digest, Vol 2 #9 Message-ID: <579@brl-bmd.UUCP> Date: Tue, 14-Jun-83 23:41:01 EDT Article-I.D.: brl-bmd.579 Posted: Tue Jun 14 23:41:01 1983 Date-Received: Thu, 16-Jun-83 18:55:47 EDT Lines: 300 TCP/IP Digest Wednesday, 15 June 1983 Volume 2 : Issue 9 Today's Topics: Pointer to Naming, Addressing, & Routing Memo Routing of Routing Messages -vs- Data Messages Fix for BBN VAX TCP Problem Comments on SMTP Design Flaw + Discussion Request for TCP/IP Implementations on Micros Wanted: Spooled FTP for BBN UNIX TCP ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- Date: 7 Jun 1983 1419-PDT From: POSTEL@usc-isif Subject: IEN-19: Names, Addresses, and Routes To: TCP-IP@brl The memo by John Shoch titled "Inter-Network Naming, Addressing, and Routing", issued as IEN 19 was produced using some fancy formating and printing facilities at Xerox PARC and was distributed only in hardcopy. The later (and improved) version of this memo with the same title was presented at COMPCON Fall 1987. The order number from the IEEE Computer Society is CH1388-8/78-0000-0072. --jon. ------------------------------ Date: 7 Jun 1983 1435-PDT From: POSTEL@usc-isif Subject: Routing Messages vs. Data Messages To: tcp-ip@brl Ed Taft's comments on routing information exchange being distinct from the actual routes that data traffic moves on are well taken. One aspect of the development of the Exterior Gateway Protocol (RFC 827) is to allow testing of different routing procedures in subsets of gateways without interfering with the actual transmission of data datagrams. The logical systems of gateways in EGP are independent of the actual network topology. --jon. ------------------------------ Date: 8 Jun 1983 9:32:11 EDT (Wednesday) From: Dennis Rockwell Subject: TCP problem To: Rob Gurwitz , dpk@brl-vgr [ This message was forwarded to the Digest by Doug Kingston, and details a particularly insidious bug in the BBN VAX TCP. Hopefully, if any site using that code has not heard of this problem yet, this message will have served a purpose. Note that Berkeley 4.1a and 4.1c code does not have this bug. -Mike ] The fix for this bug is as follows: (I'm afraid I have no familiarity whatsoever with the TCP variants, but the code should be fairly easy to find) In the routine rcv_text (in tcp_procs.c in our code), the routine that does the resequencing, there is the following code: /* new overlaps at beginning of successor frags */ q = savq->t_next; while ((q != (struct th *)tp) && (t->t_len != 0) && SEQ_LEQ(q->t_seq, last)) /* complete cover */ if (SEQ_LEQ(t_end(q), last)) { p = q->t_next; tcp_deq(q); m_freem(dtom(q)); q = p; } else { /* overlap */ In your code, the first SEQ_LEQ is probably a SEQ_LT. This is the bug. There is an analogous bug in ip_input.c: /* new overlaps at beginning of successor frags */ q = savq->ip_next; while ((q != (struct ip *)fp) && (ip->ip_len != 0) && (q->ip_off <= ip->ip_end)) /* complete cover */ if (q->ip_end <= ip->ip_end) { p = q->ip_next; ip_deq(q); m_freem(dtom(q)); q = p; Again, in your code the first <= is probably a <. This fix was made just last week, and is slowly percolating out to the other local BBN sites. We are trying to spread this fix around, but that's difficult. Please tell everybody you know who is running this code about the fix. Good luck! Feel free to write or call me at (617) 497-2643. ------------------------------ Date: 8 Jun 83 5:39:10 EDT (Wed) From: Doug Kingston To: tcp-ip@BRL-VGR Subject: SMTP Design Flaw SMTP as it currently stands has a serious flaw from the point of view of fault-tolerant software. The crux of the problem is that the reply codes reuse certain values in different contexts. This opens the possibility of of mis-interpreting replies in the case where the user-smtp or the transmission channel is generating spurious data. A similiar problem exists if the smtp server generates spurious responses. If both sides are bug-free, there will be no problems. But, the world of software is seldom if ever bug-free. A prudent implementer plans for the inevitable error to be made by the hardware, his own software, or someone else's software. Spurious commands or spurious responses can cause the server/user pair to get out of sync without either being able to conclusively detect the situation. The worst problem exists for the 250 reply which is the affirmative reply from HELO, MAIL, RCPT, "final dot", and RSET to name only the most commonly used commands. The 500, 501, and 503 commands are also dangerously overloaded. Senarios: RCPT --> unknown to sender junk --> <-- 250 DATA --> <-- 500 (actually reply to junk) Result: Mail is returned wrongfully. ******************** RCPT --> unknown to sender junk1 --> junk2 --> (we are now off by two...) <-- 250 RCPT --> <-- 500 (actually reply to junk1) DATA --> <-- 500 (actually reply to junk2) we detect problem RSET --> <-- 250 (actually reply to second RCPT !!!) MAIL --> <-- 354 (bletch.) (Protocol errror) RSET --> <-- 250 (reply to first RSET!!!!!) MAIL --> <-- 250 (reply to first MAIL... RCPT --> <-- 250 (reply to second RSET... RCPT --> <-- 250 (reply to second MAIL... ... until we get to the DATA command again. Result: Mail is returned wrongfully. ******************** RCPT --> unknown to sender junk --> <-- 250 RCPT --> <-- 500 (response to junk) RCPT --> <-- 250 (response to SECOND rcpt command!!!) ******************** RCPT --> unknown to sender RCPT --> <-- 250 RCPT --> <-- 250 (response to Second RCPT !!!) RCPT --> <-- 250 (response to Third RCPT !!!) DATA --> <-- 250 (response to Fourth RCPT !!!) *********************** As I see it, there are two things that can be done done to help out this situation. First, the reply codes should be unique for each command. This would give the USER SMTP the ability to detect sequencing errors from syntax or argument errors which some hosts give on hosts they don't know how to reach, but I wont drag the offenders out into public here. They know who they are. Second, and perhaps more radical, is to add a sequence number each command/reply pair. Each command would be sent with a sequence number. The reply to that command would have to contain the same sequence number. This would allow both the server and user SMTP to detect sequenceing errors. I feel that this would be the most prudent and reliable mechanism for detecting these faults. This problem is not just a figment of my imagination. This very problem has plagued mail between out sites and sites running BBN based TCP implementations for about a month now. The spurious input was probably induced by a bug in the BBN TCP's handling of the sequenceing and/or retransmission or large numbers of incoming 1 character packets due to a bug in my mailer that caused it not to buffer its output. Comments and Discussion are Welcomed -Doug- ------------------------------ Date: 8 Jun 1983 1445-PDT From: POSTEL at USC-ISIF Subject: Re: SMTP Design Flaw To: dpk at BRL-VGR, tcp-ip at BRL-VGR Doug: SMTP explicitly requires that it be operated on a reliable channel (such as provided by TCP). The situation you suggest does not arise because of "junk" being inserted in the channel unknown to the sender. There was (still is?) a totally bogus "implementation" of SMTP that sent several commands in succession without even looking at the replies. I suggest that it is better to assume a reliable channel than to reimplement TCP inside of SMTP, and to stomp out bad implementations of SMTP as soon as we see them. --jon. ------------------------------ Date: 8 Jun 83 18:13:50 EDT (Wed) From: Doug Kingston To: POSTEL@Usc-Isif cc: dpk@BRL-VGR, tcp-ip@BRL-VGR Subject: Re: SMTP Design Flaw Jon, I do not dispute that the problem is induced by a faulty SMTP or channel. I am arguing for cheap enhancements the buy us a great deal of fault tolerance. Obviously we're not going to change SMTP, but I think this should be kept in mind for later incarnations. Faults will occur. Mail software should make every effort to detect and deal with errors. We need to give it a mechanism, and it doesn't have to be complicated. The problem with bugs is that is they're so ingenious, -Doug- ------------------------------ Date: 9 Jun 1983 17:53:43-PST From: ram.arizona@rand-relay Subject: TCP/IP on Micros? To: tcp-ip-request.brl@rand-relay [ Anybody having information about micro implementations, please feel free to either contact Ralph directly, or to submit a message to the digest for all to see. -Mike ] I am interested in locating information on tcp/ip implementations on microcomputer systems. Specifically, on the LSI-11/23, 68000, and 8086. I would like to know the language, operating system, and availability of such implementations (costs). Thanks for passing on this request. ----Ralph Martinez (ram.arizona@rand-relay) University of Arizona ------------------------------ Date: 9 Jun 1983 8:36-PDT (Thursday) From: Jim Rees Subject: Want spooled FTP for BBN Unix TCP To: tcp-ip@brl, bbn-tcp@bbn-vax I am running BBN's TCP on a Vax with 4.1bsd. I want a spooled FTP, something like uucp, to run over the net between Unix machines. Has anyone already done this? Does anyone have bright ideas? ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061600572100> Return-path: Received: from NPRDC by SRI-NIC via DDN; 16 Jun 83 08:03:26-PDT Date: 16 Jun 1983 07:57:21-PDT From: bierma@NPRDC Reply-To: bierma To: tcp-ip@sri-nic Subject: looking for a TCP/IP implementation for a IBM 4341. Cc: bierma@NPRDC, buckingh@NPRDC I am trying to set up a full service communications link between my VAX and an IBM 4341 that is about 400 feet away in another building. The 4341 is running VM/370 and the VAX is running 4.1 UNIX (with BBN TCP/IP). Ideally I am looking for an implementation of TCP/IP that runs under VM/370 and network hardware that is compatible with both the VAX and the 4341 (ethernet?). When I asked the IBM rep her answer was "What's TCP/IP?". Oh, Well so much for "No. 1". --Larry Bierma ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061610400000> Return-path: Received: from USC-ISI by SRI-NIC via DDN; 16 Jun 83 17:40:59-PDT Date: 16 Jun 1983 1740-PDT From: BRADEN at USC-ISI Subject: Re: looking for a TCP/IP implementation for a IBM 4341. To: bierma at NPRDC, tcp-ip at SRI-NIC cc: buckingh at NPRDC, BRADEN at USC-ISI In response to the message sent 16 Jun 1983 07:57:21-PDT from bierma Larry, Actually, IBM corporate is getting concerned about TCP/IP, since the govt is starting to wave the DDN stick at them. The prospect of not being able to bid on contracts for 20 CPUs at once has them at least concerned. We at UCLA have a TCP/IP for OS/MVS, driving an 1822 interface to the ARPANET. One will soon be able to buy a Series 1 that has an HDH interface, also. For VM software, I suggest you talk to Doug McKay at IBM FSD. (301) 921 1914. We are quite concerned about local network interface hardware... Ethernet, Pronet, ... I would be interested in any leads you get on this. A number of other IBM sites are also interested. Bob Braden ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061611150000> Return-path: Received: from CIT-20 by SRI-NIC via DDN; 16 Jun 83 18:15:13-PDT Date: 16 Jun 1983 1815-PDT Subject: TCP for an IBM 4341 From: Dan Whelan To: bierma@NPRDC, braden@USC-ISI, tcp-ip@SRI-NIC We at Caltech are also concerned about TCP for a 4341 since IBM is upstairs right now installing one. We have a systems programmer who is interested in implementing TCP/IP under VM/CMS. Of course, we would rather port an exisiting implementation. We plan to connect our 4341 to our local Ethernet through its UNIBUS. Thats right, our 4341 has a UNIBUS. It appears IBM is now manufacturing a device called a DACU which is an IBM PC with a UNIBUS that attaches to a channel. Like the others, we'd welcome any suggestions. Dan Whelan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061616074900> Return-path: Received: from SRI-KL by SRI-NIC via DDN; 16 Jun 83 23:14:35-PDT Date: Thu 16 Jun 83 23:07:49-PDT From: Richard R. Cower Subject: Re: TCP for an IBM 4341 To: DAN@CIT-20.ARPA, bierma@NPRDC.ARPA, braden@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA cc: COWER@SRI-KL.ARPA In-Reply-To: Your message of Thu 16 Jun 83 18:15:00-PDT Where can one get information on the PC with a Unibus on the channel? Stanford hung an 11 on a channel - wonder if it is a similar device? .Thanks..Rich Cower ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061702460000> Return-path: Received: from USC-ISID by SRI-NIC via DDN; 17 Jun 83 09:48:39-PDT Date: 17 Jun 1983 0946-PDT From: MILLS at USC-ISID Subject: Re: TCP for an IBM 4341 To: COWER at SRI-KL, DAN at CIT-20, bierma at NPRDC, To: braden at ISI, tcp-ip at SRI-NIC cc: MILLS at USC-ISID, Mike at UMD2, Louie at UMD2 In response to the message sent Thu 16 Jun 83 23:07:49-PDT from COWER@SRI-KL.ARPA Folks, Several years ago I designed an interface to the IBM multiplexor channel when I was at the University of Michigan. After I left they updated that interface, which is still in use, for a number of PDP11s used for data concentration and distribution. Call Mr. Dave Flower at the U of M Computing Center in Ann Arbor for further details. The interface was capable of emulating a 270x controller, as well as more exciting devices and also supported a two-channel switch. Regards, Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061715040000> Return-path: Received: from MIT-XX by SRI-NIC via DDN; 17 Jun 83 16:07:23-PDT Date: 17 Jun 1983 1904-EDT From: Chris Ryland Subject: Re: looking for a TCP/IP implementation for a IBM 4341. To: bierma@NPRDC, tcp-ip@SRI-NIC cc: buckingh@NPRDC In-Reply-To: Your message of 16-Jun-83 1057-EDT Try Larry Landweber at U Wisc: 608-262-14, for info about an IBM VM TCP/IP implementation supposedly finished in August. /Chris ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061722310000> Return-path: Received: from MIT-MC by SRI-NIC via DDN; 17 Jun 83 23:30:44-PDT Date: 18 June 1983 02:31 EDT From: Ken Harrenstien Subject: Possible ISIB TCP bug To: tcp-ip @ SRI-NIC I have fairly good proof that ISIB's TCP (or its FTP server) is not working properly, as documented in the following message. I have not received any comments from the original addressees and so am forwarding it to a wider distribution in the hope that it will reach someone who may be able to shed more light on the problem. It still exists; I reproduced it again just now. ------------------ Date: 2 June 1983 21:19 EDT From: Ken Harrenstien Subject: Possible ISIB TCP problem To: postel @ USC-ISIF, clynn @ BBNA, clements @ BBNA, jgoldberger @ USC-ISIB cc: BUG-TCP @ MIT-MC, ELLEN @ MIT-MC, BDB @ MIT-MC A user here has managed to isolate a reproducible problem that at first glance appears to be the fault of the ISIB TCP or FTP server. The file CRASH2;ISIB FTP contains a photo-like log of the session which ran into the problem. Briefly, an attempt to make an ASCII transfer of the file kermit.protocol from ISIB (server) to MIT-MC (user) fails near the end; the data connection hangs for a couple of minutes and is then aborted by ISIB. The server claims that the transfer was completed, however. This appears to be completely reproducible. I made a packet log of one such instance, which can be found in the files CRASH2;TCPB X1 CRASH2;TCPB X2 CRASH2;TCPB X3 The first one shows the data connection being established and the last file shows the terminating RST coming from ISIB. The middle one is just plain data transfer stuff. I have not attempted to edit them down to a smaller size since I am not sure what you might find significant. Also, the files CRASH2;KERMIT TRUNC and CRASH2;KERMIT PROTO contain copies of the truncated and complete transfers respectively. (the latter file was obtained by FTP'ing it to LLL-MFE and thence to MIT-MC). Some comments on the last few datagrams in the log: From what I can see, MIT-MC is not doing anything wrong. The last data segment from ISIB is ACKed properly; after this there is a long pause (note the timestamps -- about 1.5 minutes!) and the RST comes in out of the blue. The log shows everything that MIT-MC sent to or received from ISIB for the period that the log was active - as long as the IP address matches ISIB, the datagram is logged whether or not it is illegal in any way. (obviously I had to wait until no one else on MC was talking to ISIB!) Thus, ANYTHING wrong with the TCP headers/data would have appeared in the log (even if the datagram wasn't identifiable as a TCP datagram!) Nothing like that appears. Possibly it is a FTP server problem wherein the data fork is being killed (thus resetting the data connection) prematurely. But why is the problem apparently specific to requests from MIT-MC? (I haven't tried it from other places actually; maybe LLL-MFE was just lucky or something). Let me know if there is anything more I can do to help track this down. --Ken --------------- Postscript: My current theory is that MIT-MC's window updates just happen to come in the right sizes to tickle a bug in the TOPS-20 TCP code, which in the past has been found to be sensitive to datagram/buffer sizes. Or there may be a bug in the ISI code which takes ACK'd segments off the retransmission queue; transmissions to MC may exercise this more frequently since MC does not retain out-of-order segments (a slower, but perfectly legal tactic). Again, the log is convincing proof that ISIB is spazzing. I am hoping that someone out there will have an idea why, and perhaps be able to suggest a fix. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061806260000> Return-path: Received: from CMU-CS-A by SRI-NIC via DDN; 18 Jun 83 07:43:40-PDT Date: 18 June 1983 1026-EDT From: Rudy.Nedved@CMU-CS-A To: Ken Harrenstien Subject: Re: Possible ISIB TCP bug CC: tcp-ip@SRI-NIC In-Reply-To: "Ken Harrenstien's message of 18 Jun 83 01:31-EST" Message-Id: <18Jun83.102650.EN0C@CMU-CS-A> Ken, I suspect ISIB FTP server uses TCPSIM and that TCPSIM just aborts the data transfer connection. If I remember correctly, Vince Fuller said that the PAGED ASCII data connections are never closed and that he could not get non-PAGED ASCII transfers to work "correctly". The user process used a timeout to determine the eof instead of actual EOF signal from the TCP JSYS. When we did change the user process to wait and do closes on the TCP JCNs...we got BUGxxxs..sso we added a abort after the close and that did the trick. TOPS-20 people should get from Vince Fuller (VAF@CMU-CS-C) his version of TCPSIM...he also has an excellent user FTP that uses COMND% (this is CMU-CS-C system FTP). -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061807190000> Return-path: Received: from MIT-MC by SRI-NIC via DDN; 18 Jun 83 08:19:32-PDT Date: 18 June 1983 11:19 EDT From: David C. Plummer Subject: Re: Possible ISIB TCP bug To: tcp-ip @ SRI-NIC cc: KLH @ MIT-MC, Rudy.Nedved @ CMU-CS-A I suspect ISIB FTP server uses TCPSIM and that TCPSIM just aborts the data transfer connection. If I remember correctly, Vince Fuller said that the PAGED ASCII data connections are never closed and that he could not get non-PAGED ASCII transfers to work "correctly". The user process used a timeout to determine the eof instead of actual EOF signal from the TCP JSYS. When we did change the user process to wait and do closes on the TCP JCNs...we got BUGxxxs..sso we added a abort after the close and that did the trick. What ever happened to the Completeness, Correctness, Cleanness (??) and Robustness principles? It is messages like the above pointing out implementation deficiencies (for whatever reason) in a major operating system that require kludges to bypass (not implementaion corrections) that convince me TCP/IP is not as sound as it should be 6 months after enforcement. Sometimes it is amazing we can even send mail to each other... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061807535500> Return-path: Received: from SU-SCORE by SRI-NIC via DDN; 18 Jun 83 14:51:50-PDT Date: Sat 18 Jun 83 14:53:55-PDT From: Mark Crispin Subject: Re: Possible ISIB TCP bug To: Rudy.Nedved@CMU-CS-A.ARPA cc: KLH@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "Rudy.Nedved@CMU-CS-A" of Sat 18 Jun 83 07:26:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Rudy - This is why I didn't use TCPSIM in MMailr (the TOPS-20 mail delivery process) or in Telnet. In Telnet I foolishyy used the TCP jsi directly without benefit of any packages to assist. When I did the mailsystem I had learned my lesson and wrote the TCPIO package. I spent a significant amount of time reading through TCPSIM and the monitor's TCPTCP module in developing TCPIO. I suspect that the unknown author of TCPSIM (1) never finished it, (2) never looked at the actual monitor code and relied only the sketchy documentation, or (3) wrote TCPSIM for an earlier version of TCP. I suspect (3) is what actually hapened. TCPSIM fails to consider a number of cases of transient errors which happen an alarming percentage of the time. In overall reliability, I suspect that TCPIO is superior to TCPSIM. It does have two drawbacks; it was primarily written for the mailsystem and hence didn't go to much effort to support multiple simultaneous connections. Some hooks are there but it isn't complete. Also, the sending logic isn't as efficiently-coded as it should be; it was optimized for small bursts of data rather tha large data streams. I would do it differently today. However, if anybody wants it, it is on MRC:TCPIO.MAC at Score. It is written in "TOPS-20" (also known as "creole"), a structured programming language using machine instructions as part of its non-control primitives. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061809253000> Return-path: Received: from SU-SCORE by SRI-NIC via DDN; 18 Jun 83 16:23:31-PDT Date: Sat 18 Jun 83 16:25:30-PDT From: Mark Crispin Subject: Re: Possible ISIB TCP bug To: DCP@MIT-MC.ARPA cc: tcp-ip@SRI-NIC.ARPA, KLH@MIT-MC.ARPA, Rudy.Nedved@CMU-CS-A.ARPA In-Reply-To: Message from "David C. Plummer " of Sat 18 Jun 83 11:19:00-PDT Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) David - The problem with TCPSIM and TOPS-20's TCP implementation is not an "implementation eeficiency", nor is it a problem with TCP itself. An implementation deficiency requires an implementation and it's implied that the implementation is finished. The present TOPS-20 TCP is an interim implementation that was for a while mistaken as a final product by certain individuals. Sites such as Score which are multi-homed or dare to use non-ARPANET networks (and therefore are "not supported") see ample evidence of this -- Score crashes two or three times daily due to bugs in the TCP code. For he non-TOPS-20 people receiving this, the problem is, briefly: most TOPS-20 I/O is expressed in byte-stream form. The system calls on TOPS-20 to do TCP, however, are more segment or record oriented. Consequently, a good deal of the work of segmenting and buffering has to be done by the user process. To work around this problem, there is a package called TCPSIM which is intended to simulate traditional TOPS-20 I/O. This package, unfortunately, has problems. Another package exists called TCPIO which, in oome ways, is better. Whether TOPS-20 TCP will be finalized by rewriting it or by hacking the current code into final form remains to be seen. DEC claims to have implemented byte-stream I/O in their TCP, so with any luck both TCPSIM and TCPIO will be obsolete soon. Now, if only Multinet worked better... -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061818140000> Return-path: Received: from MIT-MC by SRI-NIC via DDN; 18 Jun 83 19:13:19-PDT Date: 18 June 1983 22:14 EDT From: David C. Plummer Subject: Re: Possible ISIB TCP bug To: MRC @ SU-SCORE cc: DCP @ MIT-MC, KLH @ MIT-MC, JTW @ MIT-MC, tcp-ip @ SRI-NIC, Rudy.Nedved @ CMU-CS-A Indeed, TCPSIM appears broken in the context of the current implementation of TCP for TOPS-20. Some comments: I find it a fundamental design flaw that it was not implemented as byte streams to begin with. TCP is defined (last I looked) as a byte stream ans has certain out of band signals (e.g., push and urgent) that can be detected, if necessary, by interrupts. Also, last I looked, there is no provision in TCP to transmit a "record" from one end of a connection to the other without layering a record format on top of the byte stream. Urgent and push are not sufficient since they may be merged. I certainly hope DEC's implementation implements BIN, BOUT, SIN, SOUT, etc on TCP JFNs and has MTOPRs (or whatever) to do the special things. If not, I would hope somebody (or group) would do it so we no longer have the need for TCPSIM and TCPIO. I assume nobody has because of the rumors about DEC's implementation. If you have had specific experiences with Multinet, JTW@MC (actually MIT-SPEECH) and I would like to hear about them. MIT also has an unofficial network (i.e., CHAOS) which currently fits into the monitor on the side of everything else. JTW would love to use Multinet to make things coexist better, especially with TCP/IP. Any known pitfalls would be appreciated. (They needn't go to tcp-ip@sri-nic.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983061818300000> Return-path: Received: from CMU-CS-A by SRI-NIC via DDN; 18 Jun 83 19:35:51-PDT Date: 18 June 1983 2230-EDT From: Rudy.Nedved@CMU-CS-A To: David C. Plummer Subject: Re: Possible ISIB TCP bug CC: MRC@SU-SCORE, DCP@MIT-MC, KLH@MIT-MC, JTW@MIT-MC, tcp-ip@SRI-NIC, Rudy.Nedved@CMU-CS-A In-Reply-To: "David C. Plummer's message of 18 Jun 83 21:14-EST" Message-Id: <18Jun83.223019.2@CMU-CS-A> CMU has a mutli-homed TOPS-20 machine like SU-Score...one side is ARPANET and the other side is 3MB Ethernet. We would like to hear about problems and solutions that people have had or are having...why not send the information to either TOPS-20@SU-Score or TCP-IP-TOPS20 (If such a list exists)?? Thanks, -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062004120000> Date: 20 Jun 1983 1112-PDT From: Henry W. Miller Subject: Re: TCP & Gateway Pinging To: scohn at BBN-UNIX, lieberman at OFFICE-1, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, dball at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip, tcp-ip-tops20 at SRI-NIC, tops-20 at SU-SCORE cc: Miller In-Reply-To: Your message of 20-Jun-83 1337-PDT Steve, Thank you for your deductions on this. I believe that you will find all or most of the TOPS20 and TENEX sites on the network exhibiting this behavior, since we are running variants of the same code. However, the pinging algorithim should be sufficiently similar in all the implementations to exhibit the same bad manners. The exceptions, as far as I can see are those hosts who have edited entries out of their gateway tables. As far as I know, 37 seconds is the standard inter-ping interval. From conversations with Dave Mills and Mike Brescia, this interval is way too short, and results with the poor gateways being flooded by probes at a high rate. This congests them as well, and hampers communications with other nets. The value of PINGT0 in the monitor should be raised to a higher value. We are currently using about a 1 minute interval, and may raise that if the results warrant it. There are many other things that the code may be doing wrong, but more research is needed. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062009372100> Return-path: Received: from BBNY by SRI-NIC via DDN; 20 Jun 83 10:47:04-PDT Date: 20 Jun 1983 13:37:21 EDT (Monday) From: Steven Cohn Subject: TCP & Gateway Pinging To: lieberman@office-1, tharris@ddn1, jmayersohn@bbn-unix, ddnsr@BBN-UNIX, nmimno@bbn-unix, dball@office-2, snelson@office-1, bhitson@bbn-unix, tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score Cc: scohn@BBN-UNIX In the course of studying the long delays and other problems experienced by users of the TYMSHARE-43 Office machines 1,2,3, and 7, some undesirable aspects of the TCP implementation at TYMSHARE were uncoveed. We have not yet examined the rest of the IMPs on the ARPANET to determine if other hosts are suffering from the same disease, but have reason to suspect TENEX and TOPS-20 TCP implementations. TYMSHARE's TCP running on OFFICE-1 and OFFICE-2 had built into it a clumsy approach to maintaining a table on the status of internet gateways. Generally it is unnecessary to communicate with a gateway unless one has traffic destined for that gateway, however, both hosts were regularly "pinging", or exchanging single messages, with each of 23 gateways, at the interval of 37 seconds. This is unnecessary for TYMSHARE as none of its users accesses the ARPANET through a gateway. It also may have contributed some of the degradation of service that they have observed. This last point has not yet been demonstrated, but as I explain below, there is good reason to suspect this. Here is the scenario. TYMSHARE-43 is a c/30 IMP running 4305. This provides for 56 end-to-end connections. TYMSHAR has 4 real hosts which, during one of my 5-minute measurements, sent substantial numbers of messages to 15 different hosts on the ARPANET. However, as their implementation of TCP, combined with its interaction with 1822, uses the handling type field, each of these logical connections may result in several subnetwork connections. (This results from a misinterpretation of the implementation specifications in BBN Report 1822 on the interconnection of a host and IMP. We are presently considering what the right policy on this matter should be. Handling type should generally be set to zero. If messages are submitted on a single host-to-host connection with different handling types then a separate connection will be set up for each type. We have observed as many as 5 different subnetwork connections between a pair of hosts. This is undesirable for two reasons. First, since messages in the same stream will be sent on different connections, the IMPs will not deliver them in order so that the TCP will have to reorder them; messages on the same connection are always delivered in correct order. Second, having more connections open drains the resources of the IMP. This can be quite serious, as I explain below. Furthermore, it is not at all clear that there are any benefits to maintaining multiple connections.) Here's the problem. Two of the hosts on TYMSHARE-43 ping each of the 23 gateways every 37 seconds. (CUMSTATS, after much scrutiny, exposed this.) These possibly also have variable handling type. Thus this configuration can easily consume the available connection resources in the IMP which means that each time either of the hosts pings a gateway it will probably need to set up a new connection. (EESTATS over a 1-hour period showed that the IMP was resetting its transmit blocks once every 1.07 seconds, on average.) Assuming a new connection is required for each ICMP ping of a gateway, then each host is blocked every 37/23 = 1.6 seconds for as long as it takes to set up a connection. (When the ping message is submitted the interface blocks until a message number is obtained. Since there is no existing connection a connection must be established before obtaining a message number and queuing the message.) Measured roundttrip times for messages originating at TYMSHARE-43 (using CUMSTATS) range between 440 and over 600 ms, averaged over 1-hour periods. Minute-by-minute fluctuations presumably result in higher values at times. If we assume a 600 ms round-trip time then it takes at least 600 ms to set up a connection to a gateway and dispatch the ping. During this time nothing else can be submitted to the net by that host. Thus, using the above values, the two host would each be blocked 600 ms out of each 1.6 seconds or almost 40 % of the time. If the ICMP pings are bunched this could lead to higher blockage rates for particular intervals. This can have at least two adverse effects. First, it will certainly impact host throughput if its interface is blocked 40 % of the time on useless persuits, at least from TYMSHARE's perspective. Second, it cannot be useful to the gateways to be pinged this often by however many hosts on the ARPANET happen to be running this code. (Incidentally, we will soon run measurements to try to identify any other culprits.) When I explained this all to Robert Lieberman at TYMSHARE he discovered, via some softwarepeople at SRI, that the timer in the TCP code which controlled this gateway pinging could be easily adjusted and since his hosts do not talk to gateways he set the timer to 280 minutes, effectively disabling the pinging so that we can observe the effect on performance. Our hope is that this will yield improved service for the STLA-61 users of TYMSHARE hosts. Basically this approach to the gateways is inadequate and must be replaced. Just setting the timers is not an adequate solution, although useful immediately. It is not known if this contention for connections is degrading service for other hosts on the network. However, the mechanism explained above may very well be impacting your network performance without being obvious. It happens, for example, that this mechanism does not produce any kind of trap that would signal a problem to network operators because, while the host may be blocked much of the time, it is not blocked for an extended period e.g. 3 seconds. I would appreciate hearing about any other cases, suspected or proven, where connection contention causes degraded service. Remember, the ARPANET is NOT just a datagram network. Regards, Steve Cohn ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062019000000> Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 21 Jun 83 20:02:00 PDT Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 21 Jun 83 21:51 EDT Sender: Mike Muuss From: TCP-IP@brl To: TCP-IP@brl Date: 21 June 1983 00:00 EST Subject: TCP-IP Digest, Vol 2 #10 TCP/IP Digest Tuesday, 21 June 1983 Volume 2 : Issue 10 Today's Topics: Deadbeat Hosts Dropped from Distribution Looking for TCP/IP for an IBM 4341 (VM/370) Connecting an IBM to UNIBUS devices (like Ethernet)! Sources of TCP/IP Implementation for 68000 systesm Spooled FTP Comments && Comments on TCP/IP for VMS Further Details on the ARPANET/MILNET Split ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- Date: Mon, 20 Jun 83 21:32:03 EDT From: Mike Muuss (TCP-IP Digest) To: tcp-ip@BRL-VGR Subject: Deadbeat hosts The following addresses have been deleted from the subscription list of the TCP Digest. Neither BRL-VGR nor BRL was able to get through for a period of 14 days; these hosts probably still have the TOPS-20 TCP bug. If anybody can help out these hosts, please try. Best, -Mike George @ Afsc-Hq Dreifu @ Wharton-10 King @ Afsc-Hq HAGAN @ Wharton-10 Perilli @ Afsc-Hq LITWA @ Wharton-10 PACE @ Afsc-Sd JARONSON @ Nlm-Mcs Furuta @ Washington Joe @ Washington ------------------------------ Date: 16 Jun 1983 07:57:21-PDT From: bierma@nprdc To: tcp-ip@sri-nic Subject: looking for a TCP/IP implementation for a IBM 4341. I am trying to set up a full service communications link between my VAX and an IBM 4341 that is about 400 feet away in another building. The 4341 is running VM/370 and the VAX is running 4.1 UNIX (with BBN TCP/IP). Ideally I am looking for an implementation of TCP/IP that runs under VM/370 and network hardware that is compatible with both the VAX and the 4341 (ethernet?). When I asked the IBM rep her answer was "What's TCP/IP?". Oh, Well so much for "No. 1". --Larry Bierma ------------------------------ Date: Thu, 16 Jun 83 15:07:00 CDT From: Paul.Milazzo Subject: TCP/IP for VM/370 To: tcp-ip@brl It seems we have acquired yet another "strange" machine at Rice. Does anyone know of a TCP/IP implementation for CMS under VM/SP on an IBM 4341? If so, how can I obtain a copy, and what network interfaces does it support? Paul Milazzo Dept. of Mathematical Sciences Rice University, Houston, TX ------------------------------ Date: 16 Jun 1983 1815-PDT Subject: TCP for an IBM 4341 From: Dan Whelan To: bierma@nprdc, braden@usc-isi, tcp-ip@brl We at Caltech are also concerned about TCP for a 4341 since IBM is upstairs right now installing one. We have a systems programmer who is interested in implementing TCP/IP under VM/CMS. Of course, we would rather port an exisiting implementation. We plan to connect our 4341 to our local Ethernet through its UNIBUS. Thats right, our 4341 has a UNIBUS. It appears IBM is now manufacturing a device called a DACU which is an IBM PC with a UNIBUS that attaches to a channel. Like the others, we'd welcome any suggestions. Dan Whelan Our machine is just being installed now, but not all of the hardware is here yet (including the DACU). I'll have more to add when we've played around with it. My understanding is that the unit sells for 12-13K. ------------------------------ Date: 15 Jun 1983 9:43:40 EDT (Wednesday) From: John Robinson Subject: 68000 TCP/IP To: ram.arizona@rand-relay Cc: schantz@bbncd, tcp-ip@brl, jr@bbncd BBN is building a 68000 TCP/IP in the Distributed Operating System project on government funding. Inquire of Rick Schantz (SCHANTZ@BBN). /jr ------------------------------ Date: 15 June 1983 18:08:58-PDT (Wednesday) From: nowicki%Shasta@su-score Subject: TCP/IP on Micros? To: ram.Arizona@rand-relay Cc: tcp-ip@brl The Network Graphics Project at Stanford, now called the Partitionable Computer Systems project, has developed an implementation of the IP/TCP protocols. It is structured as an "internet server" within the V distributed system. Processes anywhere in the system (on the same or different workstation) may send it standard V messages using the V I/O protocol. The objects manipulated are either raw IP sockets or TCP connections. Its major use is virtual terminal communication from graphics workstations through telnet. It has been tested with the BBN Vax/Unix, Berkeley 4.1c Unix, and BBN TOPS-20 implementations of TCP. The internet server is portable with the rest of the V-System, since it is all written in C. Currently the V-System runs on five different 68000 systems based on the SUN CPU board, and is in the process of being ported to the VAX. The internet server is mostly the work of Marvin Theimer, network address mmt@SU-HNV (or mmt%Diablo@Score). It is 37K bytes of object code + 7K data including libraries, and about 5000 lines of C source code. The V-System is being licensed by the Stanford Office of Technology Licensing, 415-497-0651. -- Bill ------------------------------ Date: 15 Jun 1983 9:24:48 EDT (Wednesday) From: John Robinson Subject: Spooled FTP To: jim@uw-beaver Cc: tcp-ip@brl, bbn-tcp@bbn-unix, jr@bbncd Certainly in the Unix environment one gets almost all the way there with a combination of shell scripts and at(1). The only troublesome aspect is how to deal with deferring login at the remote site. Also, FTP may not in fact return error codes to the shell if the destination is unreachable (some do, some don't). Using mail (e.g. smtp) to send files isn't too bad a choice. One could add a control line (instead of or in addition to a normal mail header), and queue the incoming message in a special directory where a daemon scans the inbox from time to time and breaks the files apart again. Giving this daemon root priveleges avoids the login issue, but introduces security holes if it isn't careful (ought to setuid and setgid before delivering the file). Probably want this daemon to have a private file system to avoid filling up /usr when something goes wrong. /jr ------------------------------ From: joseph sventek Date: Wednesday, 20 Apr 83 08:41:31 PST Subject: TCP/IP for VMS We are currently running Compion's Access-X product (Access-T which can be interfaced to your own link level) with no problems. I have written a driver interfacing the IP layer to the Proteon PRONET 10-Mbit ring interface. As a result, we have telnet and ftp connection to our 4.1A UNIX host. I have also interfaced the software tools mail delivery system to use TCP circuits to support SMTP between the hosts, thus providing a coherent mail system. The user-interface utilities for that mail system are sndmsg and msg clones. As far as performance, I don't think anyone should expect blinding speed from Compion's TCP/IP implementation, due to the modularity employed in their software. TCP service is provided by an ACP servicing qio requests to a pseudo-device. IP service is provided by another ACP servicing requests to another pseudo-device. The IP layer simply queues up multiple read and write requests to the backend device driver. As a result, characters typed to user telnet when the remote host is providing the character echo result in 6 process context switches per packet (which may be single characters). Other user protocols, such as ftp and smtp, which are more block at a time oriented perform better, but still suffer 6 context switches per request/response pair. While this architecture may not be the bottleneck when communicating with the ARPANET, it is definitely the bottleneck when communicating over a high-speed local net. We have experienced none of the system-crashing bugs described above, as I have been informed by Compion personnel that most of the outstanding bugs were fixed in the Access-T 1.6 release, with which we share the user and server utilities. Our experience has been extremely positive, not only with the software, but with the Compion personnel who aided us in our attempts to be the first user site to link to our own network link level. It is an extremely easy way to get up to speed on TCP/IP on VMS. Joe Sventek j @ LBL-CSAM ------------------------------ Date: 17 Jun 1983 2012-PDT From: NIC@sri-nic Subject: FURTHER DETAILS ON THE ARPANET/MILNET SPLIT [ This message is an excerpt from DDN Newsletter 27, concerning the MILNET/EXPNET split. For more information, contact . -Mike ] Introduction As previously discussed in DDN Newsletter 26, the existing ARPANET will soon be split into two separate networks - the experimental ARPANET and the operational MILNET. Hosts on the two networks will intercommunicate via mail bridges, using the internet gateway mechanisms to pass mail traffic between hosts on the two networks. The mail bridges will, on a controlled basis, provide full internet gateway services for MILNET hosts that request it. The Logical Split Because it takes a large amount of time and effort to physically split a network in a coherent manner, the ARPANET will initially, on 4 October 1983, be logically partitioned by the use of existing mechanisms in the IMPs to enforce segregation of hosts and TACs into separate communities of interest. Each community of interest (COI) becomes a virtual network, i.e., hosts (including TACS) in the same community can fully interoperate as is currently the case, while hosts in different communities cannot directly intercommunicate. This, in effect, transforms the ARPANET into an Internet in which the MILNET will assume a new class A network number, network 26, while the ARPANET remains network 10. (Details of the host renumbering procedures will be covered in a later newsletter from the Network Information Center (NIC).) Intercommunication between the MILNET and ARPANET is via mail bridges which use standard internet protocols and mechanisms to pass data between hosts in the two networks. This is why the conversion from NCP to TCP/IP is so important; any host with a fully working TCP/IP implementation (including ICMP, the host-gateway protocol), should see no loss in service because of the split. However, hosts using incomplete TCP/IP implementations (those that do not include ICMP as a part of IP, or have no provision for using gateways) will be restricted to communicating with other TCP/IP hosts in the same network. In particular, this means that they will not be able to send (or receive) mail traffic through the bridges to hosts in the other network. THERE CAN BE NO EXEMPTIONS TO THE SPLIT!! Unlike the NCP-to-TCP conversion which is still underway for a few hosts, once the split occurs, there is nothing that can be done to allow a host with an incomplete TCP/IP to fully intercommunicate with the other network other than helping them to convert to a fully working TCP/IP as soon as possible. Future DDN Newsletters will discuss in greater detail how the split affects the users and host software maintainers, and how the split will be tested before it is finally implemented in October. The Physical Split Concurrent with the logical split the network is being physically split as well. Many new trunks are being added to support each network, and a number of trunks will eventually be removed once replacement trunks have been installed. The first quarter of CY 1984 has been established as the goal for completion of the physical split, but this is dependent upon delivery of new circuits from the TELCOs, some of which have very long lead times (over a year in some cases). To complete the physical split, hosts and terminals which are homed on the wrong IMP or TAC must be rehomed. In some cases, a new IMP on the proper network will be used; in other cases, a host may need to use HDH (the HDLC-based replacement for VDH) in order to gain access to its network via a remote IMP. In either case, the host must change its network address, and the TAC users of these hosts must be made aware of the change. Both host and terminal rehoming will be kept to the absolute minimum possible. ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062019560000> Return-path: Received: from OFFICE-2 by SRI-NIC via DDN; 21 Jun 83 03:01:42-PDT Date: 21-Jun-83 02:56 PDT From: RLL.TYM@OFFICE-2 Subject: Warning, TCP-4 problems To: tharris@ddn1, jmayersohn@bbn-unix, ddnsr@BBN-UNIX To: nmimno@bbn-unix, DAB2.GVT@OFFICE-2, snelson@office-1 To: bhitson@bbn-unix, tcp-ip@brl, tcp-ip@sri-nic To: tcp-ip-tops20@sri-nic, tops-20@su-score Cc: scohn@BBN-UNIX Message-ID: <[OFFICE-2]TYM-RLL-2N485> For a good explanation of the problems see SCOHN's msg of 20 jun 83. This message is to make it clear that at least two problems exist in the TOPS20, TENEX TCP code that is based on the BBN implementation. 1) the frequency of 'pinging' has caused excessive delays and heavy net loads for our local IMP. Our brief experiments show that whatever the interval is, when the process wakes up and begins to 'ping' the several gateways, all hell breaks loose and the host/imp are effectively down until this process completes. The most noticeable symptom is the sudden slowness for a minute or so. However, the most annoying is the fact that this process in some way (yet unknown) can disrupt the other connections to our hosts with the result of user jobs that disconnect in funny ways leaving 'hung' jobs on the host. With a PING interval of 37 seconds (the common standard), the situation is far worse. We have gone the full way and will just NOOP the entire process of pinging. When a proper solution is found, we will re-implement the pinging process. 2) This version of the BBN TCP code uses connections in an inefficient manner as was stated by Steve Cohn. Also we agree with Steve that this code has a 'clumsy' approach to maintaining internet gateway data. Since we run as vanilla as possible implementation of the TCP code to be as compatible as possible with the TOPS20 sites, we will wait until there is some general agreement on how to design the 'ping' process before installing it. Since BBN is not supporting this code, we will continue to work closely with SRI, ISI, Stanford, etc. in solving these common problems. Robert ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062021002500> Return-path: Received: from SU-SCORE by SRI-NIC via DDN; 21 Jun 83 03:58:46-PDT Date: Tue 21 Jun 83 04:00:25-PDT From: Mark Crispin Subject: Re: Warning, TCP-4 problems To: RLL.TYM@OFFICE-2.ARPA cc: tharris@DDN1.ARPA, jmayersohn@BBN-UNIX.ARPA, ddnsr@BBN-UNIX.ARPA, nmimno@BBN-UNIX.ARPA, DAB2.GVT@OFFICE-2.ARPA, snelson@OFFICE-1.ARPA, bhitson@BBN-UNIX.ARPA, tcp-ip@BRL.ARPA, tcp-ip@SRI-NIC.ARPA, tcp-ip-tops20@SRI-NIC.ARPA, tops-20@SU-SCORE.ARPA, scohn@BBN-UNIX.ARPA In-Reply-To: Message from "RLL.TYM@OFFICE-2" of Tue 21 Jun 83 02:56:00-PDT Postal-Address: 72 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) One suggestion - Do not run the NIC-supplied INTERNET.GATEWAYS file!! This is not made obvious to sites (I certainly was unaware of it), but it is an important axiom. The problem is that the NIC gateways file has all the gateways. You really don't want all the gateways; instead, you want a few "prime" gateways that are your primary contacts for IP datagrams leaving ARPANET. You probally also want a few other selected "always-up" (these don't get pinged) and "dumb" gateways (e.g. for nets you know you are going to talk to all the time). The reason you don't need all the gateways is that ICMP to the prime gateways will take care of fixing up your routing table to suit your needs dynamically as those needs happen. ICMP is always going to be better than any file the NIC could provide. I've talked to several individuals who've been involved with this stuff for years, and they ll concur: if you're on the East coast, run BBN's INTERNET.GATEWAYS; if you're on the West coast, run ISI's. Otherwise, look at both and figure out for yourself what looks best for your needs. Use the NIC's only as a reference source of gateways you might want to add. Don't actually run it. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062102450000> Return-path: Received: from USC-ISIF by SRI-NIC via DDN; 21 Jun 83 09:48:37-PDT Date: 21 Jun 1983 0945-PDT From: POSTEL at USC-ISIF Subject: Re: Warning, TCP-4 problems To: HEDRICK at RUTGERS, MRC at SU-SCORE cc: RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, cc: ddnsr at BBN-UNIX, nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, cc: snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, cc: tcp-ip at NIC, tcp-ip-tops20 at NIC, tops-20 at SU-SCORE, cc: scohn at BBN-UNIX, POSTEL at USC-ISIF In response to the message sent 21 Jun 83 11:34:32 EDT from HEDRICK@RUTERS +-------------------------------------------------------+ | | | It is not necessary for any host to ping any gateway. | | | +-------------------------------------------------------+ All a host has to have is a short list of fairly reliable gateways. The host also keeps a dynamicly built table of (destination-network,gateway-to-use) pairs. When the host has oo send a datagram it first checks to see if the destination network is in the dynamic table. If it is then it uses the indicated gateway. If the destination network is not in the dynamic table, then the host choose one of the gateways from the short list (randomly if it wants) and makes a new entry in the dynamic table for that new pair. If a host sends a datagram to a destination network through the "wrong" gateway, that gateway will (in addition to forwarding the datagram anyway) send back to the host a ICMP Redirect Control Message indicating the correct gateway. The host on receiving an ICMP redirect message should update the dynamic table entry to show the correct gateway for that destination network. The entries in the dynamic table should be aged and deleted after a fairly long time (say, an hour). The entries should also be deleted at once if there if is any indication that the gateway has died (e.g., an ARPANET 1822 "host dead" is returned). --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062102590000> Return-path: Received: from USC-ISIB by SRI-NIC via DDN; 21 Jun 83 10:06:34-PDT Date: 21 Jun 1983 0959-PDT Sender: JGOLDBERGER at USC-ISIB Subject: Of gateways and pinging From: Joel Goldberger To: HEDRICK at RUTGERS Cc: MRC at SU-SCORE, RLL.TYM at OFFICE-2, tharris at DDN1 Cc: jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX Cc: nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2 Cc: snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL Cc: tcp-ip at SRI-NIC, tcp-ip-tops20 at SRI-NIC Cc: tops-20 at SU-SCORE, scohn at BBN-UNIX Message-ID: <[USC-ISIB]21-Jun-83 09:59:42.JGOLDBEGER> Mark's comments on this subject are essentially correct, but it's clear that there is some confusion. PRIME gateways are a small subset of gateways that engage in GGP (Gateway Gateway Protocol) amongst themselves to maintain up to date routing tables. At some interval they announce to each other what networks they are connected to and how far (in hops) they are from all networks that they know. I'm not sure what their known set of networks is. The way things are supposed to work is that if a host needs to talk to a particular network and doesn't know the gateway to use it sends the message to any PRIME gateway. If that gateway knows of another gateway that is closer it sends an ICMP re-direct packet back to the host. TOPS-20 uses two different methods to PING gateways; PRIME gateways are sent ICMP Echo packets, which they return as ICMP Echo Reply packets. Dumb gateways (which don't speak ICMP) are PINGed with ICMP Echo-Reply packets "reverse-addressed", that is the packet is addressed to the host taat is pinging; since the packet isn't for the gateway that received it, it simply sends it back out. ALWAYS-UP and HOST gateways are not PINGed at all. Since non-PRIME gateways don't get involved in the GGP routing table update game one needs to include them in the tables if one wants to talk to hosts on the network that they serve. I hope this removes some of the mystery surrounding this subject. - Joel Goldberger - ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062105160000> Date: 21 Jun 1983 1216-PDT From: ROODE at SRI-NIC (David Roode) Subject: Re: Warning, TCP-4 problems To: HEDRICK at RUTGERS, MRC at SU-SCORE cc: RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, cc: nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, cc: tcp-ip at BRL, tcp-ip, tcp-ip-tops20 at SRI-NIC, tops-20 at SU-SCORE, cc: sscohn at BBN-UNIX Location: EJ296 Phone: (415) 859-2774 In-Reply-To: Your message of 21-Jun-83 1134-PDT Two more questions: 1) Does or Does NOT the TOPS-20 TCP's ICMP processes redirect messages? 2) IS there a program that anyone has that will printout the current status of the monitor's gateway table? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062106080000> Date: 21 Jun 1983 1308-PDT From: Henry W. Miller Subject: Re: Removal To: brown at MITRE, tcp-ip cc: Miller In-Reply-To: Your message of 21-Jun-83 1123-PDT Deb, Your name hase been removed. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062107232700> Return-path: Received: from MITRE by SRI-NIC via DDN; 21 Jun 83 08:27:43-PDT Date: 21 Jun 1983 11:23:27 EDT (Tuesday) From: Deborah Brown Subject: Removal To: tcp-ip@sri-nic Please remove my name from the tcp-ip distribution list. Thanks, Deb Brown deb@mitre brown@mitre ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062107343200> Return-path: Received: from RUTGERS by SRI-NIC via DDN; 21 Jun 83 08:37:18-PDT Date: 21 Jun 83 11:34:32 EDT From: Dir LCSR Comp Facility Subject: Re: Warning, TCP-4 problems To: MRC@SU-SCORE.ARPA cc: RLL.TYM@OFFICE-2.ARPA, tharris@DDN1.ARPA, jmayersohn@BBN-UNIX.ARPA, ddnsr@BBN-UNIX.ARPA, nmimno@BBN-UNIX.ARPA, DAB2.GVT@OFFICE-2.ARPA, snelson@OFFICE-1.ARPA, bhitson@BBN-UNIX.ARPA, tcp-ip@BRL.ARPA, tcp-ip@SRI-NIC.ARPA, tcp-ip-tops20@SRI-NIC.ARPA, tops-20@SU-SCORE.ARPA, scohn@BBN-UNIX.ARPA In-Reply-To: Message from "Mark Crispin " of 21 Jun 83 07:00:25 EDT It would help me (and I suspect also other people on this list) if someone would describe in a bit more detail the method in which we hear about gateways that are not listed in our internet.gateways file. I would like to be able to talk to any internet-addressable host. I would not like to spend all of my time pinging. If I list only the prime gateways, will I still be able to talk through any gateway? If so, then why does anyone list anything other than the prime gateways? Also, a previous message said that prime gateways are safe because they don't get pinged. It also implied, but did not say, that this was true of DUMB gateways also. Is it? Would anything be gained if we listed all of the gateways from the NIC file, but changed the ones that get pinged (I am still not clear on which those are) to be listed as dumb? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062109530000> Date: 21 Jun 1983 1653-PDT From: Henry W. Miller Subject: Re: Warning, TCP-4 problems To: ROODE, HEDRICK at RUTGERS, MRC at SU-SCORE cc: RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip, tcp-ip-tops20 at SRI-NIC, tops-20 at SU-SCORE, sscohn at BBN-UNIX, Miller In-Reply-To: Your message of 21-Jun-83 1216-PDT Yes, it does, but only redirect net, not redirect host. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062115400000> Return-path: Received: from BBNA by SRI-NIC via DDN; 21 Jun 83 16:46:42-PDT Date: 21 Jun 1983 1940-EDT Sender: CLYNN at BBNA Subject: Re: Warning, TCP-4 problems From: CLYNN at BBNA To: RLL.TYM at OFFICE-2 Cc: tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX Cc: nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2 Cc: snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL Cc: tcp-ip at SRI-NIC, tcp-ip-tops20 at SRI-NIC Cc: tops-20 at SU-SCORE, scohn at BBN-UNIX Message-ID: <[BBNA]21-Jun-83 19:40:55.CLYNN> In-Reply-To: <[OFFICE-2]TYM-RLL-2N485> Recent measurements and messages indicate that a clarification of the use and contents of the INTERNET.GATEWAYS file is needed and that some TOPS20/TENEX hosts may still have a bug in their network driver which is degrading network performance. First, the bug: The end of the IMPHDR routine (1822DV.MAC) should be: LOAD T3,NBBSZ,(T2) ; Get size SUBI T3,.NBHHL ; (Pseudo and real) header words ASH T3,2+3 ; Make into bits CAILE T3,^D1008-1 ; Uncontrolled flow must be single packet MOVX T1,STY%FC ; Too big, must use Normal flow-controlled STOR T1,IHSTY,(T2) ; Message sub-type RET ; And return If there is an IDIVI T3,^D1008 STOR T3,IHHTY,(T2) please remove it. In theory, gateways do not have to be pinged; a generic internet gateway server whose internet logical name is coded into each host could supply that host with the internet address of a gateway to use (try) when the route to a destination network is not known. Until such a service is readily, reliably available, the TOPS20 and TENEX hosts use a site-dependent initialization file, named INTERNET.GATEWAYS, to provide the address of a gateway to try when the route to a destination is not known. There is no need for a host to know about all of the gateways; the gateway system and the ICMP protocol should make it possible for a host to reach any "official" internet address, if it is at all possible. The INTERNET.GATEWAYS file should contain one or two (fairly reliable) "PRIME" gateways on each network to which the TOPS20 or TENEX is directly connected. Briefly, a PRIME gateway is one of the "back-bone" gateways which knows now to route a packet to one of the reachable networks, and will send ICMP redirect messages when appropriate. For reasons of performance (some of which have been described in other messages), it is best if sites do not all use the same gateway(s). A "nearby" prime gateway should be the first entry in the file, and a "backup" should follow. Entries should not be included simply because the site has frequent communications with a particular net. One can make a reliability argument that the backup should be on the other side of the continent to try and minimize the possibility that both are down at the same time (due to a failure or maintenance). A better solution (until the "gateway server" arrives) would be to have a backup file and to teach the operator(s) when and how to dynamically install it. Before one starts changing the values of the default network parameters, make sure the consequences are well understood (and please inform the operator what sorts of "performance problems" the users may consequently report). Most of the timeouts, etc. are associated with robustness; the longer the time constants, the longer the associated outage will be when something fails. If a gateway listed in the routing cache goes down then communication with the related network will not be possible until the route is timed-out; setting the timeout of the routing cache to a large number can result in many problem reports. Setting it too short will cause packets to be sent to the prime gateway more frequently. [One recent incident: "Users at B cannot communicate with Site D (anywhere else is ok, though)" -- an ICMP redirect caused an entry to be placed into the routing cache, and that gateway had subsequently failed; the routing cache was set to time out in six hours. By the time the problem had been identified, there was only one hour to go ...] If the ping interval is lengthened, the loss of a gateway will not be noticed for a period about four times as long. During the interval, attempts to use the gateway (which are "hidden" from the user) will fail. If pinging is disabled, and the first prime gateway listed in INTERNET.GATEWAYS goes down, the host will only be able to communicate with directly connected networks and networks which are still in the routing cache. If your host is only connected directly to the ARPANET, then you need not read further. Complications arise when the host must be able to deal with "unofficial" entities -- hidden nets or hosts, local area networks, home-brew gateways, etc. When the host tries to find a route to a network, it first checks the routing cache. If there is a functioning interface to the desired network, it is used, secondly, if a pair is found, the gateway is used as the destination for the packet. If no entry is found, [the gateways listed in INTERNET.GATEWAYS (which are "up") are examined (in the order specified in the INTERNET.GATEWAYS file) to see if one is listed as being able to reach the desired net, if so, it is used, otherwise,] the first PRIME gateway in the file (which is "up") will be tried. If an ICMP Redirect Net message is received, the pair will be entered into the routing cache. The TOPS20/TENEX TCP-IP implementation is designed to operate in the internet environment, not just the ARPANET; in fact, it is not necessary that the host even be connected to the ARPANET (thus it cannot rely on ARPANET/1822-specific mechanisms such as "host dead"; there is no corresponding mechanism in ethernet, for example). The bracketed clause in the paragraph above is intended to allow a site's liaison to both override the routing supplied by the internet gateways (for administrative purposes, for example), and to allow the host to use hidden or "unofficial" gateways, etc. between networks with which the host must communicate, or which form the site's local area network. If such is not the case, there probably should not be an entry in the gateway file; if there is an entry in the file (which isn't being pinged) and the gateway fails, communications with the associated nets will be blocked. The following descriptions of non-PRIME gateways is included for completeness, but use of such gateways is probably limited to sites which have to communicate via local gateway implementations that do not "conform to the official behavior" expected of a PRIME gateway. PRIME gateways speak Internet Control Message Protocol, and will turn an ICMP ECHO packet into an ECHO-REPLY; they know how to forward packets to reachable networks, and will send ICMP Redirect messages when appropriate. (E.g. the "backbone" gateways.) They are pinged to monitor when they are up and down. DUMB gateways do not speak ICMP and thus will only forward packets. These are pinged with ECHO-REPLIES instead of ECHO packets. ALWAYS-UP gateways will not answer pings at all due to strange implementations which, for example, prohibit reflecting packets back into the net from which they came. They are assumed to always be up; if they go down, you have a black hole. (E.g. Two IMPs on different networks which have ports which are wired together.) HOST gateways are hosts which are capable of routing packets which they receive; they should not be burdened with forwarding packets since they did not originate them, but they can be used in an emergency. (E.g. TOPS20s [BBN or current DEC software] connected to more than one (inter)network can be used to pass packets between those (inter)networks.) Hopefully, this has answered more questions than it raises; if questions remain, send me a note. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062119000000> Return-Path: Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 21 Jun 83 21:24:34 PDT Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 21 Jun 83 22:30 EDT Sender: Mike Muuss From: TCP-IP@brl To: TCP-IP@brl Date: 22 June 1983 00:00 EST Subject: TCP-IP Digest, Vol 2 #11 TCP/IP Digest Wednesday, 22 June 1983 Volume 2 : Issue 11 Today's Topic: TOPS-20/TENEX TCP/IP Implementations, and Pinging ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- From: Mike Muuss Subject: Special Issue on TOPS-20/TENEX TCP/IP Implementations, and Pinging This issue is entirely devoted to discussion of the TOPS-20/TENEX IP routing mechanism, which uses InterNet Control Message Protocol "Echo" (ICMP/ECHO) packets to determine the Up/Down status of various Gateways. (I have removed most of the lengthy message headers to improve readability). -Mike ------------------------------ Date: 20 Jun 1983 13:37:21 EDT (Monday) From: Steven Cohn Subject: TCP & Gateway Pinging In the course of studying the long delays and other problems experienced by users of the TYMSHARE-[IMP]43 Office machines 1,2,3, and 7, some undesirable aspects of the TCP implementation at TYMSHARE were uncovered. We have not yet examined the rest of the IMPs on the ARPANET to determine if other hosts are suffering from the same disease, but have reason to suspect TENEX and TOPS-20 TCP implementations. TYMSHARE's TCP running on OFFICE-1 and OFFICE-2 had built into it a clumsy approach to maintaining a table on the status of internet gateways. Generally it is unnecessary to communicate with a gateway unless one has traffic destined for that gateway, however, both hosts were regularly "pinging", or exchanging single messages, with each of 23 gateways, at the interval of 37 seconds. This is unnecessary for TYMSHARE as none of its users accesses the ARPANET through a gateway. It also may have contributed some of the degradation of service that they have observed. This last point has not yet been demonstrated, but as I explain below, there is good reason to suspect this. Here is the scenario. TYMSHARE-43 is a C/30 IMP running 4305. This provides for 56 end-to-end connections. TYMSHARE has 4 real hosts which, during one of my 5-minute measurements, sent substantial numbers of messages to 15 different hosts on the ARPANET. However, as their implementation of TCP, combined with its interaction with 1822, uses the handling type field, each of these logical connections may result in several subnetwork connections. (This results from a misinterpretation of the implementation specifications in BBN Report 1822 on the interconnection of a host and IMP. We are presently considering what the right policy on this matter should be. Handling type should generally be set to zero. If messages are submitted on a single host-to-host connection with different handling types then a separate connection will be set up for each type. We have observed as many as 5 different subnetwork connections between a pair of hosts. This is undesirable for two reasons. First, since messages in the same stream will be sent on different connections, the IMPs will not deliver them in order so that the TCP will have to reorder them; messages on the same connection are always delivered in correct order. Second, having more connections open drains the resources of the IMP. This can be quite serious, as I explain below. Furthermore, it is not at all clear that there are any benefits to maintaining multiple connections.) Here's the problem. Two of the hosts on TYMSHARE-43 ping each of the 23 gateways every 37 seconds. (CUMSTATS, after much scrutiny, exposed this.) These possibly also have variable handling type. Thus this configuration can easily consume the available connection resources in the IMP which means that each time either of the hosts pings a gateway it will probably need to set up a new connection. (EESTATS over a 1-hour period showed that the IMP was resetting its transmit blocks once every 1.07 seconds, on average.) Assuming a new connection is required for each ICMP ping of a gateway, then each host is blocked every 37/23 = 1.6 seconds for as long as it takes to set up a connection. (When the ping message is submitted the interface blocks until a message number is obtained. Since there is no existing connection a connection must be established before obtaining a message number and queuing the message.) Measured round-trip times for messages originating at TYMSHARE-43 (using CUMSTATS) range between 440 and over 600 ms, averaged over 1-hour periods. Minute-by-minute fluctuations presumably result in higher values at times. If we assume a 600 ms round-trip time then it takes at least 600 ms to set up a connection to a gateway and dispatch the ping. During this time nothing else can be submitted to the net by that host. Thus, using the above values, the two host would each be blocked 600 ms out of each 1.6 seconds or almost 40 % of the time. If the ICMP pings are bunched this could lead to higher blockage rates for particular intervals. This can have at least two adverse effects. First, it will certainly impact host throughput if its interface is blocked 40 % of the time on useless persuits, at least from TYMSHARE's perspective. Second, it cannot be useful to the gateways to be pinged this often by however many hosts on the ARPANET happen to be running this code. (Incidentally, we will soon run measurements to try to identify any other culprits.) When I explained this all to Robert Lieberman at TYMSHARE he discovered, via some software people at SRI, that the timer in the TCP code which controlled this gateway pinging could be easily adjusted and since his hosts do not talk to gateways he set the timer to 280 minutes, effectively disabling the pinging so that we can observe the effect on performance. Our hope is that this will yield improved service for the STLA-[IMP]61 users of TYMSHARE hosts. Basically this approach to the gateways is inadequate and must be replaced. Just setting the timers is not an adequate solution, although useful immediately. It is not known if this contention for connections is degrading service for other hosts on the network. However, the mechanism explained above may very well be impacting your network performance without being obvious. It happens, for example, that this mechanism does not produce any kind of trap that would signal a problem to network operators because, while the host may be blocked much of the time, it is not blocked for an extended period e.g. 3 seconds. I would appreciate hearing about any other cases, suspected or proven, where connection contention causes degraded service. Remember, the ARPANET is NOT just a datagram network. Regards, Steve Cohn ------------------------------ Date: 20 Jun 1983 1112-PDT From: Henry W. Miller Subject: Re: TCP & Gateway Pinging Steve, Thank you for your deductions on this. I believe that you will find all or most of the TOPS20 and TENEX sites on the network exhibiting this behavior, since we are running variants of the same code. However, the pinging algorithim should be sufficiently similar in all the implementations to exhibit the same bad manners. The exceptions, as far as I can see are those hosts who have edited entries out of their gateway tables. As far as I know, 37 seconds is the standard inter-ping interval. From conversations with Dave Mills and Mike Brescia, this interval is way too short, and results with the poor gateways being flooded by probes at a high rate. This congests them as well, and hampers communications with other nets. The value of PINGT0 in the monitor should be raised to a higher value. We are currently using about a 1 minute interval, and may raise that if the results warrant it. There are many other things that the code may be doing wrong, but more research is needed. -HWM ------------------------------ Date: 21-Jun-83 02:56 PDT From: RLL.TYM@office-2 Subject: Warning, TCP-4 problems This message is to make it clear that at least two problems exist in the TOPS20, TENEX TCP code that is based on the BBN implementation. 1) The frequency of 'pinging' has caused excessive delays and heavy net loads for our local IMP. Our brief experiments show that whatever the interval is, when the process wakes up and begins to 'ping' the several gateways, all hell breaks loose and the host/imp are effectively down until this process completes. The most noticeable symptom is the sudden slowness for a minute or so. However, the most annoying is the fact that this process in some way (yet unknown) can disrupt the other connections to our hosts with the result of user jobs that disconnect in funny ways leaving 'hung' jobs on the host. With a PING interval of 37 seconds (the common standard), the situation is far worse. We have gone the full way and will just NOOP the entire process of pinging. When a proper solution is found, we will re-implement the pinging process. 2) This version of the BBN TCP code uses connections in an inefficient manner as was stated by Steve Cohn. Also we agree with Steve that this code has a 'clumsy' approach to maintaining internet gateway data. Since we run as vanilla as possible implementation of the TCP code to be as compatible as possible with the TOPS20 sites, we will wait until there is some general agreement on how to design the 'ping' process before installing it. Since BBN is not supporting this code, we will continue to work closely with SRI, ISI, Stanford, etc. in solving these common problems. Robert ------------------------------ Date: Tue 21 Jun 83 04:00:25-PDT From: Mark Crispin Subject: Re: Warning, TCP-4 problems One suggestion - Do not run the NIC-supplied INTERNET.GATEWAYS file!! This is not made obvious to sites (I certainly was unaware of it), but it is an important axiom. The problem is that the NIC gateways file has all the gateways. You really don't want all the gateways; instead, you want a few "prime" gateways that are your primary contacts for IP datagrams leaving ARPANET. You probably also want a few other selected "always-up" (these don't get pinged) and "dumb" gateways (e.g. for nets you know you are going to talk to all the time). The reason you don't need all the gateways is that ICMP to the prime gateways will take care of fixing up your routing table to suit your needs dynamically as those needs happen. ICMP is always going to be better than any file the NIC could provide. I've talked to several individuals who've been involved with this stuff for years, and they all concur: if you're on the East coast, run BBN's INTERNET.GATEWAYS; if you're on the West coast, run ISI's. Otherwise, look at both and figure out for yourself what looks best for your needs. Use the NIC's only as a reference source of gateways you might want to add. Don't actually run it. -- Mark -- ------------------------------ Date: 21 Jun 83 11:34:32 EDT From: Dir LCSR Comp Facility Subject: Re: Warning, TCP-4 problems It would help me (and I suspect also other people on this list) if someone would describe in a bit more detail the method in which we hear about gateways that are not listed in our internet.gateways file. I would like to be able to talk to any internet-addressable host. I would not like to spend all of my time pinging. If I list only the prime gateways, will I still be able to talk through any gateway? If so, then why does anyone list anything other than the prime gateways? Also, a previous message said that prime gateways are safe because they don't get pinged. It also implied, but did not say, that this was true of DUMB gateways also. Is it? Would anything be gained if we listed all of the gateways from the NIC file, but changed the ones that get pinged (I am still not clear on which those are) to be listed as dumb? ------------------------------ Date: 21 Jun 1983 0945-PDT From: POSTEL@usc-isif Subject: Re: Warning, TCP-4 problems +-------------------------------------------------------+ | | | It is not necessary for any host to ping any gateway. | | | +-------------------------------------------------------+ All a host has to have is a short list of fairly reliable gateways. The host also keeps a dynamicly built table of (destination-network,gateway-to-use) pairs. When the host has oo send a datagram it first checks to see if the destination network is in the dynamic table. If it is then it uses the indicated gateway. If the destination network is not in the dynamic table, then the host choose one of the gateways from the short list (randomly if it wants) and makes a new entry in the dynamic table for that new pair. If a host sends a datagram to a destination network through the "wrong" gateway, that gateway will (in addition to forwarding the datagram anyway) send back to the host a ICMP Redirect Control Message indicating the correct gateway. The host on receiving an ICMP redirect message should update the dynamic table entry to show the correct gateway for that destination network. The entries in the dynamic table should be aged and deleted after a fairly long time (say, an hour). The entries should also be deleted at once if there if is any indication that the gateway has died (e.g., an ARPANET 1822 "host dead" is returned). --jon. ------------------------------ Date: 21 Jun 1983 0959-PDT Subject: Of gateways and pinging From: Joel Goldberger Mark's comments on this subject are essentially correct, but it's clear that there is some confusion. PRIME gateways are a small subset of gateways that engage in GGP (Gateway Gateway Protocol) amongst themselves to maintain up to date routing tables. At some interval they announce to each other what networks they are connected to and how far (in hops) they are from all networks that they know. I'm not sure what their known set of networks is. The way things are supposed to work is that if a host needs to talk to a particular network and doesn't know the gateway to use it sends the message to any PRIME gateway. If that gateway knows of another gateway that is closer it sends an ICMP re-direct packet back to the host. TOPS-20 uses two different methods to PING gateways; PRIME gateways are sent ICMP Echo packets, which they return as ICMP Echo Reply packets. Dumb gateways (which don't speak ICMP) are PINGed with ICMP Echo-Reply packets "reverse-addressed", that is the packet is addressed to the host that is pinging; since the packet isn't for the gateway that received it, it simply sends it back out. ALWAYS-UP and HOST gateways are not PINGed at all. Since non-PRIME gateways don't get involved in the GGP routing table update game one needs to include them in the tables if one wants to talk to hosts on the network that they serve. I hope this removes some of the mystery surrounding this subject. - Joel Goldberger - ------------------------------ Date: 21 Jun 1983 1940-EDT Sender: CLYNN@bbna Subject: Re: Warning, TCP-4 problems From: CLYNN@bbna Recent measurements and messages indicate that a clarification of the use and contents of the INTERNET.GATEWAYS file is needed and that some TOPS20/TENEX hosts may still have a bug in their network driver which is degrading network performance. First, the bug: The end of the IMPHDR routine (1822DV.MAC) should be: LOAD T3,NBBSZ,(T2) ; Get size SUBI T3,.NBHHL ; (Pseudo and real) header words ASH T3,2+3 ; Make into bits CAILE T3,^D1008-1 ; Uncontrolled flow must be single packet MOVX T1,STY%FC ; Too big, must use Normal flow-controlled STOR T1,IHSTY,(T2) ; Message sub-type RET ; And return If there is an IDIVI T3,^D1008 STOR T3,IHHTY,(T2) please remove it. In theory, gateways do not have to be pinged; a generic internet gateway server whose internet logical name is coded into each host could supply that host with the internet address of a gateway to use (try) when the route to a destination network is not known. Until such a service is readily, reliably available, the TOPS20 and TENEX hosts use a site-dependent initialization file, named INTERNET.GATEWAYS, to provide the address of a gateway to try when the route to a destination is not known. There is no need for a host to know about all of the gateways; the gateway system and the ICMP protocol should make it possible for a host to reach any "official" internet address, if it is at all possible. The INTERNET.GATEWAYS file should contain one or two (fairly reliable) "PRIME" gateways on each network to which the TOPS20 or TENEX is directly connected. Briefly, a PRIME gateway is one of the "back-bone" gateways which knows now to route a packet to one of the reachable networks, and will send ICMP redirect messages when appropriate. For reasons of performance (some of which have been described in other messages), it is best if sites do not all use the same gateway(s). A "nearby" prime gateway should be the first entry in the file, and a "backup" should follow. Entries should not be included simply because the site has frequent communications with a particular net. One can make a reliability argument that the backup should be on the other side of the continent to try and minimize the possibility that both are down at the same time (due to a failure or maintenance). A better solution (until the "gateway server" arrives) would be to have a backup file and to teach the operator(s) when and how to dynamically install it. Before one starts changing the values of the default network parameters, make sure the consequences are well understood (and please inform the operator what sorts of "performance problems" the users may consequently report). Most of the timeouts, etc. are associated with robustness; the longer the time constants, the longer the associated outage will be when something fails. If a gateway listed in the routing cache goes down then communication with the related network will not be possible until the route is timed-out; setting the timeout of the routing cache to a large number can result in many problem reports. Setting it too short will cause packets to be sent to the prime gateway more frequently. [One recent incident: "Users at B cannot communicate with Site D (anywhere else is ok, though)" -- an ICMP redirect caused an entry to be placed into the routing cache, and that gateway had subsequently failed; the routing cache was set to time out in six hours. By the time the problem had been identified, there was only one hour to go ...] If the ping interval is lengthened, the loss of a gateway will not be noticed for a period about four times as long. During the interval, attempts to use the gateway (which are "hidden" from the user) will fail. If pinging is disabled, and the first prime gateway listed in INTERNET.GATEWAYS goes down, the host will only be able to communicate with directly connected networks and networks which are still in the routing cache. If your host is only connected directly to the ARPANET, then you need not read further. Complications arise when the host must be able to deal with "unofficial" entities -- hidden nets or hosts, local area networks, home-brew gateways, etc. When the host tries to find a route to a network, it first checks the routing cache. If there is a functioning interface to the desired network, it is used, secondly, if a pair is found, the gateway is used as the destination for the packet. If no entry is found, [the gateways listed in INTERNET.GATEWAYS (which are "up") are examined (in the order specified in the INTERNET.GATEWAYS file) to see if one is listed as being able to reach the desired net, if so, it is used, otherwise,] the first PRIME gateway in the file (which is "up") will be tried. If an ICMP Redirect Net message is received, the pair will be entered into the routing cache. The TOPS20/TENEX TCP-IP implementation is designed to operate in the internet environment, not just the ARPANET; in fact, it is not necessary that the host even be connected to the ARPANET (thus it cannot rely on ARPANET/1822-specific mechanisms such as "host dead"; there is no corresponding mechanism in ethernet, for example). The bracketed clause in the paragraph above is intended to allow a site's liaison to both override the routing supplied by the internet gateways (for administrative purposes, for example), and to allow the host to use hidden or "unofficial" gateways, etc. between networks with which the host must communicate, or which form the site's local area network. If such is not the case, there probably should not be an entry in the gateway file; if there is an entry in the file (which isn't being pinged) and the gateway fails, communications with the associated nets will be blocked. The following descriptions of non-PRIME gateways is included for completeness, but use of such gateways is probably limited to sites which have to communicate via local gateway implementations that do not "conform to the official behavior" expected of a PRIME gateway. PRIME gateways speak Internet Control Message Protocol, and will turn an ICMP ECHO packet into an ECHO-REPLY; they know how to forward packets to reachable networks, and will send ICMP Redirect messages when appropriate. (E.g. the "backbone" gateways.) They are pinged to monitor when they are up and down. DUMB gateways do not speak ICMP and thus will only forward packets. These are pinged with ECHO-REPLIES instead of ECHO packets. ALWAYS-UP gateways will not answer pings at all due to strange implementations which, for example, prohibit reflecting packets back into the net from which they came. They are assumed to always be up; if they go down, you have a black hole. (E.g. Two IMPs on different networks which have ports which are wired together.) HOST gateways are hosts which are capable of routing packets which they receive; they should not be burdened with forwarding packets since they did not originate them, but they can be used in an emergency. (E.g. TOPS20s [BBN or current DEC software] connected to more than one (inter)network can be used to pass packets between those (inter)networks.) Hopefully, this has answered more questions than it raises; if questions remain, send me a note. Charlie ------------------------------ Date: 21 Jun 1983 1216-PDT From: David Roode Subject: Re: Warning, TCP-4 problems Two more questions: 1) Does or Does NOT the TOPS-20 TCP's ICMP processes redirect messages? 2) IS there a program that anyone has that will printout the current status of the monitor's gateway table? ------------------------------ Date: 21 Jun 1983 1653-PDT From: Henry W. Miller Subject: Re: Warning, TCP-4 problems Yes, it does, but only redirect net, not redirect host. -HWM ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062119090000> Return-path: Received: from SRI-CSL by SRI-NIC via DDN; 22 Jun 83 02:04:13-PDT Date: 22 Jun 1983 0209-PDT Sender: GEOFF at SRI-CSL Subject: Gateways- When should I ping, When should I purge, Who should I have? From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff at SRI-CSL To: POSTEL at USC-ISIF, HEDRICK at RUTGERS, MRC at SU-SCORE To: RLL.TYM at OFFICE-2, tharris at DDN1 To: jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX To: nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2 To: snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL To: tcp-ip at NIC, tcp-ip-tops20 at NIC, tops-20 at SU-SCORE To: scohn at BBN-UNIX Message-ID: <[SRI-CSL]22-Jun-83 02:09:08.GEOFF> So far we have heard that pinging gateways in a hosts gateway cache every 37 seconds is too often and that very likely every TENEX and TOPS-20 site on the ARPANET is currently doing this. We had a suggestion that it might not be necessary to ping gateways at all. However, it was also suggested pinging gateways periodically might be a good idea. It was suggested that entries in a hosts dynamic gateway table should be aged and deleted after about an hours time. A number of informed parties suggested that each site configure the contents of their INTERNET.GATEWAYS file very carefully and some very helpful guidelines for choosing the initial contents of your INTERNET.GATEWAYS file was given. What I would like to see explored, discussed and hopefully resolved by this group is: 1) What is the ideal interval with which to PING and under what circumstances should I PING? 2) What is the ideal time a gateway entry should remain in a given hosts gateway table before it is aged and flushed? I think how one should configure the contents of their initial INTERNET.GATEWAYS file was pretty well explained by Charlie Lynn, but I still have not heard anything concrete enough on the subject of when to PING and when to purge to make me dash to my TENEX sources and stick the code in. Could we hear from other operating system wizards on how FUZZBALLS, TAC's, UNIX, Multics, VMS, IBM hosts, TIU's and so forth have done it and from the Internet Holy Water Sprinklers on what the ideal values would be? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062120290000> Date: 22 Jun 1983 0329-PDT From: Henry W. Miller Subject: Re: Gateways- When should I ping, When should I purge, Who should I have? To: Geoff at SRI-CSL, POSTEL at USC-ISIF, HEDRICK at RUTGERS, MRC at SU-SCORE, RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip, tcp-ip-tops20 at SRI-NIC, tops-20 at SU-SCORE, scohn at BBN-UNIX cc: Miller In-Reply-To: Your message of 22-Jun-83 0209-PDT Ok, at the risk of starting a new mail deluge... (we just recovered from the last...) 1) Jon sez that it is not necessary to ping; that ICMP redirects will handle it. OK, seems reasonable, depending on your net traffic. Knowing a probable path, and trying it first, and recovering from it in case of error seems more efficient than probing J. Random Prime Gateway, hoping for a win. (This is why I'm in favor of rich gateway tables; it gives you more initial options.) 2) If you choose to ping, to keep up with the state of the network, 37 seconds is clearly too short of a period to get a snapshot of the net. A couple of un-ACKED probes could lead one to believe that a gate is down, when in fact, it might not be. If pinging is desired, then an interval that is suffcently long should be used, say 5-10 minutes. (Personal opinion: A ping from a host coming back on the air COULD/SHOULD be interpreted as an "I'm Alive" message. The gateways, in their infinte wisdom, could spread the good news across the networks, so the various hosts could update their routing tables. Likewise, the hosts should be able to poll the gateway of their dreams on occaision and receive, in return, the latest routing poop. A maxi ping, fer surre, but would help eliminate senseless probings...) 3) Updating routing tables: again, depending upon your internet needs, 30 minutes at the max. (Smallest interval...) The current default, I believe is 6 hours. 4) Another thot: put a timer block in for each gateway: when to ping next. This would allow pinging on a selective basis. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062200442000> Return-path: Received: from NWC-387B by SRI-NIC via DDN; 22 Jun 83 07:42:43-PDT Date: Wed, 22 Jun 83 07:44:20 PDT From: estell at nwc-387b Subject: Request for Removal from mailing list To: TCP-IP at SRI-NIC Cc: Mike at BRL The TCP-IP mailing list seems to be for those who IMPLEMENT TCP-IP; i.e., those who will be on the ARPANET (vice DDN) after the split. I have enjoyed much of the traffic on this list; but I suspect that (considering my job) I should no longer get it. I still get (and want) the TCP-IP Digest from Mike Muuss at BRL. Therefore, please remove the following names from the TCP-IP list: Estell@NWC-387B and NWC@ECLB ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062201540000> Return-path: Received: from LLL-MFE by SRI-NIC via DDN; 22 Jun 83 08:54:09-PDT Date: Wed, 22 Jun 83 08:54 PDT From: Howard@LLL-MFE.ARPA Subject: Request for removal from mailing list To: tcp-ip@sri-nic.arpa Please remove the following name from the TCP-IP list: HOWARD@LLL-MFE. Thanks, Barry Howard ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062204320000> Return-path: Received: from USC-ISIB by SRI-NIC via DDN; 22 Jun 83 11:35:08-PDT Date: 22 Jun 1983 1132-PDT Subject: Re: Warning, TCP-4 problems From: Craig Milo Rogers To: ROODE@SRI-NIC (David Roode), HEDRICK@RUTGERS, MRC@SU-SCORE cc: RLL.TYM@OFFICE-2, tharris@DDN1, jmayersohn@BBN-UNIX, ddnsr@BBN-UNIX, nmimno@BBN-UNIX, DAB2.GVT@OFFICE-2, snelson@OFFICE-1, bhitson@BBN-UNIX, tcp-ip@BRL, tcp-ip@SRI-NIC, tcp-ip-tops20@SRI-NIC, tops-20@SU-SCORE, sscohn@BBN-UNIX In-Reply-To: Your message of 21 Jun 1983 1216-PDT The programs IGGSTS.EXE and IGSSTS.EXE on ISIA,B,D-F will print TOPS20's Ping table and network routing table, respectively. (The names are holdovers from the GGP days). However, I don't expect these programs to work outside ISI, because they use an ISI-specific (I think) JSYS to map monitor pages (GTMPG). The sources are in BLISS-10. There are help files in . You need the Wheel privelege to run the programs. Craig Milo Rogers ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062205085500> Return-path: Received: from BBN-VAX by SRI-NIC via DDN; 22 Jun 83 06:24:21-PDT Date: 22 Jun 1983 9:08:55 EDT (Wednesday) From: Dennis Rockwell Subject: Re: Gateways- When should I ping, When should I purge, Who should I have? In-Reply-to: Your message of 22 Jun 1983 0209-PDT To: Geoff@SRI-CSL Cc: POSTEL@USC-ISIF, HEDRICK at RUTGERS, MRC at SU-SCORE, RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip at NIC, tcp-ip-tops20 at NIC, tops-20 at SU-SCORE, scohn at BBN-UNIX BBN UNIX hosts ping all gateways that are currently in use (defined as having an open connection which has as its local-net destination a gateway) constantly, at a rate of once every few seconds. We have thought about fancy schemes involving only pinging when TCP has to retransmit, but this leaves users of non-TCP services out in the cold. The rapid rate of pinging is for detection of a dead first-hop gateway. Unless one assumes an 1822 net, there is very likely no feedback as to whether a packet is delivered or not (as was previously noted, ethernet in particular has no such feedback). Since we only ping active gateways, our hosts' gateway table contains all the gateways we can find out about that are connected to whatever local net(s) we are connected to. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062206040000> Return-path: Received: from SRI-TSC by SRI-NIC via DDN; 22 Jun 83 13:10:48-PDT Date: 22 Jun 1983 at 1304-PDT To: tcp-ip@Sri-Nic Subject: remove me from tcp-ip mailing list From: aguilar@Sri-Tsc please do it at once. Thanks Lorenzo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062206510000> Date: 22 Jun 1983 1351-PDT From: Henry W. Miller Subject: Re: Request for Removal from mailing list To: estell at NWC-387B, TCP-IP cc: Mike at BRL, Miller In-Reply-To: Your message of 22-Jun-83 0751-PDT OK, will remove the names from the list. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062206520000> Date: 22 Jun 1983 1352-PDT From: Henry W. Miller Subject: Re: Request for removal from mailing list To: Howard at LLL-MFE, tcp-ip cc: Miller In-Reply-To: Your message of 22-Jun-83 0928-PDT OK, Barry, I'll remove it. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062206580000> Return-path: Mail-From: ROODE created at 22-Jun-83 13:58:11 Date: 22 Jun 1983 1358-PDT From: ROODE at SRI-NIC (David Roode) Subject: use of TCP-IP-REQUEST To: TCP-IP at SRI-NIC Location: EJ296 Phone: (415) 859-2774 As will nearly every large mailing list, there exists a TCP-IP-REQUEST at SRI-NIC to handle any corrections, deletions or other business matters for TCP-IP@SRI-NIC without generating huge volumes of mail. Please use it! ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062210103200> Return-path: Received: from BBNQ by SRI-NIC via DDN; 22 Jun 83 11:09:17-PDT Date: 22 Jun 1983 14:10:32 EDT (Wednesday) From: Douglas Steele Subject: request removal from tcp-ip To: tcp-ip@sri-nic Cc: steele@BBN-UNIX Please remove me from the tcp-ip mailing list. Thanks, Doug ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062301575000> Return-path: Received: from SUMEX-AIM by SRI-NIC via DDN; 23 Jun 83 09:02:41-PDT Date: Thu 23 Jun 83 08:57:50-PDT From: Suzanne Johnson Subject: ibm tcp/ip To: tcp-ip@SRI-NIC.ARPA It turns out that if you give your IBM rep VERY specific information on WHO and WHERE within IBM the tcp/ip work goes on, they can follow up for you. The tcp/ip work is evidently being done by IBM's Federal Systems Division in Gaithersburg, Maryland. The person doing the work is Doug McKay. Our rep was able to confirm this, given the above info. Since he is somewhat up-to-date on status, you might have your rep contact our IBM rep. His name is Waymon Lee, and phone # is 415-855-0519. Let us know what you find out. Suzanne Johnson ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062303000000> Date: 23 Jun 1983 1000-PDT From: Francine Perillo Subject: Re: ibm tcp/ip To: JOHNSON at SUMEX-AIM, tcp-ip cc: PERILLO In-Reply-To: Your message of 23-Jun-83 0926-PDT You might also ask the Network Information Center for info on TCP/IP implementations. We have a lot of vendors calling us and we've been keeping track of what is out there. Try us! -Francine Perillo /NIC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062306090000> Return-path: Received: from USC-ISI by SRI-NIC via DDN; 23 Jun 83 17:36:17-PDT Date: 23 Jun 1983 1309-PDT From: DELEOT at USC-ISI Subject: removal To: tcp-ip at SRI-NIC cc: deleot at USC-ISI pls remoove the following fron the tcp-ip list: deleot at isia thanks, chuck deleot ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062308270000> Return-path: Received: from SRI-TSC by SRI-NIC via DDN; 23 Jun 83 17:36:22-PDT Date: 23 Jun 1983 at 1527-PDT To: Suzanne Johnson cc: tcp-ip at SRI-NIC.ARPA Subject: Re: ibm tcp/ip In-reply-to: Your message of Thu 23 Jun 83 08:57:50-PDT. From: dan at SRI-TSC Doug McKay is indeed working on TCP/IP for the Series I. He is porting the SRI TCP/IP for PDP11/44's (which is itself a port of the 4.1b BSD VAX UNIX TCP/IP). It was my understanding that it is being integrated into the version of UNIX they have running on the Series I and whatever other IBM systems are running UNIX. I don't know if his group is also working on TCP/IP for non-unix operating systems, but I got the impression from talking to him that they were not. -Dan Chernikoff (dan@sri-tsc) SRI International ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062408040000> Return-path: Received: from USC-ISIE by SRI-NIC via DDN; 24 Jun 83 15:07:02-PDT Date: 24 Jun 1983 1504-PDT Subject: REMOVE FROM MAILING LIST PLS From: Gary Poock To: TCP-IP@SRI-NIC cc: POOCK@USC-ISIE POSTAL-ADDRESS: GARY K. POOCK, CODE 55PK, NPS, MONTEREY,CA 93940 Phone: (Home) 408-484-1892 (NPS office) 408-646-2636 AV 878-2636 PLEASE REMOVE POOCK@ISIE FROM THE TCP-IP MAILING LIST PLEASE THANKS GARY ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062517170000> Return-path: Received: from MIT-MC by SRI-NIC via DDN; 25 Jun 83 18:21:41-PDT Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 25-Jun-83 21:21:50-EDT Date: Saturday, 25 June 1983, 21:17-EDT From: David A. Moon Subject: Mail to tcp-ip instead of tcp-ip-request To: tcp-ip-request@SRI-NIC Remailed-date: 26 Jun 1983 0249-PDT Remailed-from: Henry W. Miller Remailed-to: tcp-ip Do you have batch jobs at SRI-NIC? May I suggest that a suitable punishment for people who send mail to tcp-ip (rather than tcp-ip-request) asking to be removed from the list is set up a batch job that sends them, once an hour twenty four hours a day, a 50-line message explaining the xxx-request policy. It would shut off automatically when any incoming message to tcp-ip-request was received from the offending user (or perhaps anyone at his host). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062702210000> Return-path: Received: from OFFICE-7 by SRI-NIC via DDN; 27 Jun 83 09:28:29-PDT Date: 27 Jun 1983 0921-PDT From: Brunner@OFFICE-7 Subject: Removal from Mailing List To: TCP-IP@SRI-NIC cc: J.Tugman:, RTS:, Brunner Since I no longer am at my former job with the TAC responsibility, I request that you remove me from all mailing lists regarding information on the TAC or the ARPANET. THANKS, Linda Brunner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062707450000> Date: 27 Jun 1983 1445-PDT From: Henry W. Miller Subject: Re: Removal from Mailing List To: Brunner at OFFICE-7, TCP-IP cc: Miller In-Reply-To: Your message of 27-Jun-83 0921-PDT Ok, will do. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983062919000000> Return-Path: Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 30 Jun 83 09:50:10 PDT Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 30 Jun 83 7:17 EDT Sender: Mike Muuss From: TCP-IP@brl To: TCP-IP@brl Date: 30 June 1983 00:00 EST Subject: TCP-IP Digest, Vol 2 #12 TCP/IP Digest Thursday, 30 June 1983 Volume 2 : Issue 12 Today's Topics: IBM VM TCP/IP Implementation Now Exists Contacts within IBM for TCP/IP Information Hooking IBMs to an Ethernet? Gateways: When should I ping, When should I purge, Who should I have? Program to print TOPS20's Ping Table Security Problem with Mail? Probably not. ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- Date: 22 Jun 1983 13:22:04-CDT From: L.H. Landweber Reply-to: ibm-project@uwisc To: tcp-ip@brl Subject: IBM VM TCP/IP IMPLEMENTATION TCP/IP IBM VM IMPLEMENTATION We are implementating of the Internet protocols (FTP/SMTP/Telnet/TCP/IP) for IBM VM Systems under contract with IBM. The TCP and IP have been running for some time now under VM/SP on an IBM 4331 at Wisconsin and we are currently putting the finishing touches on the higher-level protocols. In addition, a software interface between IP and an X.25 implementation running on a Series/1 (RPS operating system) has been completed. The complete package will enable CSNET IBM VM hosts to connect to the Darpa Internet via Telenet. The 4300 software is written almost entirely in Pascal, with a small amount of assembler-language support. Some assembler code running on the Series/1 interfaces with the X.25 code, which is a standard IBM product. Standard IBM released software is used throughout (i.e., no modified or unreleased system software has been employed). The software will be ready for initial distribution to test sites in mid-July. We hope to have production versions available by the end of August. Distribution will be controlled by IBM. We encourage interested parties to contact: Mr. Carl VanWinter IBM Corporation Rochester, MN 507-286-3378 to express an interest or request information on distribution plans. ADDITIONAL DETAILS TCP/IP runs in a separate disconnected virtual machine. Similarly, SMTP, server FTP, and server Telnet each occupies a dedicated virtual machine. User FTP and user Telnet run within a user's virtual machine under CMS. Communication between virtual machines is done through the IBM Virtual Machine Communication Facility (VMCF). A detailed preliminary design document is available by contacting one of the individuals listed below. (Some details have changed since it was written, but it is still mostly accurate.) Over the Summer we expect to implement a Pronet driver to enable our IP/TCP to use the PRONET 10 megabit/sec token ring LAN. The hardware interface will be via a DACU (Device Access Control Unit) provided by IBM. The DACU enables connection of UNIBUS devices to an IBM channel. We expect other university groups to provide a driver for Ethernet. We estimate that each of these projects will take 2-4 man-months to complete. Direct connection to a C/30 IMP will require implementation of a software driver in conjunction with a suitable hardware interface (e.g., DACU--LH/DH or Series/1--HDH). For further technical information contact: David DeWitt, Larry Landweber, or Marvin Solomon Computer Science Department University of Wisconsin 1210 W. Dayton St. Madison, WI 53706 608-262-1204 ibm-project@uwisc ------------------------------ Date: Thu 23 Jun 83 09:08:37-PDT From: Suzanne Johnson Subject: tcp/ip ibm info To: tcp-ip@BRL.ARPA It turns out that if you give your IBM rep VERY specific information on WHO and WHERE within IBM the tcp/ip work goes on, they can follow up for you. The tcp/ip work is evidently being done by IBM's Federal Systems Division in Gaithersburg, Maryland. The person doing the work is Doug McKay. Our rep was able to confirm this, given the above info. Since he is somewhat up-to-date on status, you might have your rep contact our IBM rep. His name is Waymon Lee, and phone # is 415-855-0519. Let us know what you find out. Suzanne Johnson ------------------------------ Date: 23 Jun 1983 at 1527-PDT From: dan@sri-tsc To: Suzanne Johnson cc: tcp-ip@brl Subject: Re: ibm tcp/ip Doug McKay is indeed working on TCP/IP for the Series I. He is porting the SRI TCP/IP for PDP11/44's (which is itself a port of the 4.1b BSD VAX UNIX TCP/IP). It was my understanding that it is being integrated into the version of UNIX they have running on the Series I and whatever other IBM systems are running UNIX. I don't know if his group is also working on TCP/IP for non-unix operating systems, but I got the impression from talking to him that they were not. -Dan Chernikoff (dan@sri-tsc) SRI International ------------------------------ Date: 23 Jun 1983 0:57-EDT From: Lee.Moore@Rochester.ARPA Subject: Re: TCP-IP Digest, Vol 2 #11 To: tcp-ip@brl-vgr.ARPA Origin: Filter-Queen RE: hooking IBM's to an ethernet I recently got a glossy brochure describing an IBM channel interface for ethernet from ACC. Does anybody know anything about this? =lee ------------------------------ Date: 22 Jun 1983 0209-PDT Sender: GEOFF@sri-csl Subject: Gateways- When should I ping, When should I purge, Who should I have? From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff@sri-csl To: POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score To: snelson@office-1, bhitson@bbn-unix, tcp-ip@brl So far we have heard that pinging gateways in a hosts gateway cache every 37 seconds is too often and that very likely every TENEX and TOPS-20 site on the ARPANET is currently doing this. We had a suggestion that it might not be necessary to ping gateways at all. However, it was also suggested pinging gateways periodically might be a good idea. It was suggested that entries in a hosts dynamic gateway table should be aged and deleted after about an hours time. A number of informed parties suggested that each site configure the contents of their INTERNET.GATEWAYS file very carefully and some very helpful guidelines for choosing the initial contents of your INTERNET.GATEWAYS file was given. What I would like to see explored, discussed and hopefully resolved by this group is: 1) What is the ideal interval with which to PING and under what circumstances should I PING? 2) What is the ideal time a gateway entry should remain in a given hosts gateway table before it is aged and flushed? I think how one should configure the contents of their initial INTERNET.GATEWAYS file was pretty well explained by Charlie Lynn, but I still have not heard anything concrete enough on the subject of when to PING and when to purge to make me dash to my TENEX sources and stick the code in. Could we hear from other operating system wizards on how FUZZBALLS, TAC's, UNIX, Multics, VMS, IBM hosts, TIU's and so forth have done it and from the Internet Holy Water Sprinklers on what the ideal values would be? ------------------------------ Date: 22 Jun 1983 0329-PDT From: Henry W. Miller Subject: Re: Gateways- When should I ping, When should I purge, Who should I have? To: Geoff@sri-csl, POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score, tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score cc: Miller@sri-nic 1) Jon sez that it is not necessary to ping; that ICMP redirects will handle it. OK, seems reasonable, depending on your net traffic. Knowing a probable path, and trying it first, and recovering from it in case of error seems more efficient than probing J. Random Prime Gateway, hoping for a win. (This is why I'm in favor of rich gateway tables; it gives you more initial options.) 2) If you choose to ping, to keep up with the state of the network, 37 seconds is clearly too short of a period to get a snapshot of the net. A couple of un-ACKED probes could lead one to believe that a gate is down, when in fact, it might not be. If pinging is desired, then an interval that is suffcently long should be used, say 5-10 minutes. (Personal opinion: A ping from a host coming back on the air COULD/SHOULD be interpreted as an "I'm Alive" message. The gateways, in their infinte wisdom, could spread the good news across the networks, so the various hosts could update their routing tables. Likewise, the hosts should be able to poll the gateway of their dreams on occaision and receive, in return, the latest routing poop. A maxi ping, fer surre, but would help eliminate senseless probings...) 3) Updating routing tables: again, depending upon your internet needs, 30 minutes at the max. (Smallest interval...) The current default, I believe is 6 hours. 4) Another thot: put a timer block in for each gateway: when to ping next. This would allow pinging on a selective basis. -HWM ------------------------------ Date: 22 Jun 1983 9:08:55 EDT (Wednesday) From: Dennis Rockwell Subject: Re: Gateways- When should I ping, When should I purge, Who should I have? To: Geoff@sri-csl Cc: POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score, RLL.TYM@office-2, DAB2.GVT@office-2, snelson@office-1, bhitson@bbn-unix, tcp-ip@brl BBN UNIX hosts ping all gateways that are currently in use (defined as having an open connection which has as its local-net destination a gateway) constantly, at a rate of once every few seconds. We have thought about fancy schemes involving only pinging when TCP has to retransmit, but this leaves users of non-TCP services out in the cold. The rapid rate of pinging is for detection of a dead first-hop gateway. Unless one assumes an 1822 net, there is very likely no feedback as to whether a packet is delivered or not (as was previously noted, ethernet in particular has no such feedback). Since we only ping active gateways, our hosts' gateway table contains all the gateways we can find out about that are connected to whatever local net(s) we are connected to. ------------------------------ Date: 22 Jun 1983 1433-EDT From: Geoffrey H. Cooper Subject: RE: Sending Pings to Gateways To: TCP-IP@brl cc: clynn@bbnc, geof@mit-xx CLYNN's message describing the way in which TOPS-20 uses its list of internet gateways brings up a more general problem with ICMP. As mentioned by Postel (in the last digest), every host implementation of internet routing maintains a cache of pairs, and a list of "prime" internet gateways. When a packet is routed the Internet implementation first searches the cache for an appropriate gateway to use. If this search fails, the packet is sent to a "default intelligent (prime) gateway" which will send a redirect back to the host IF A BETTER GATEWAY EXISTS FOR THAT NET, so that subsequent packets to the same net will hit the host's cache. Note that the prime gateway can not be relied upon to send a packet back (this is a necessary part of the way internet routing works, since otherwise a prime gateway would have to send back a redirect to itself for EVERY packet it forwards). The question that arises is to which of the default gateways that are known to the host should a "defaulted" packet be sent? The answer is, of course, to the least-loaded, working (up), closest default gateway. Unfortunately, none of those attributes is determinable by the host. If the host is on the Arpanet, it would be possible to make use of the arpanet's "host dead" messages to determine that a particular prime gateway doesn't seem to be working (either because it is too busy or crashed). Thus, it would be possible to order the prime gateways that a host knows about in order of "usefulness to the host" (or perhaps closeness on the network is the best static measure to use). The best gateway (earliest on the list) is always used, and the network status messages are used to declare that gateway's entry temporarily invalid when packets sent to it result in "host dead" messages. If the host is on a network other than the Arpanet, the problem is more severe, since the network will generally not take the responsibility to tell the host that a packet it sent was not received by the gateway to which it was sent (the Ethernet is the best example of such a network). If all packets are sent by default to a single "best" gateway and that gateway is down, then all the packets will fall into a "black hole" and a section of the internet will become inaccessible to the host. One way to deal with this situation is what is done by Tops-20: Explicitly and regularly find out what prime gateways are up, and always send your packets to the best prime gateway that is up. The last issue of the digest described some of the problems with this approach. Another approach is to use the telephone company's ''linefinder'' algorithm: Keep the N prime gateways that a host knows about in an ordered table, and cycle through the table (i.e., always use the ''next'' gateway after the one that you last used). The host maintains no information on the state of the prime gateways in its tables. Some packets will indeed be sent to the "black hole" of a crashed prime gateway; higher level protocols can be counted upon to retransmit these packets, and will hit other gateways on the retransmissions. One advantage of this scheme is that it ``load shares'' the burden of sending redirects among all of the prime gateways that a host knows about, rather than placing undue burden on one particular gateway that it considers to be the "best." Another advantage is that it leaves a host implementation open to the add the identities of new prime gateways to its tables. Consider the following algorithm: when a host receives a redirect to a gateway, it place a ``dubious'' entry for that gateway into its prime gateway table. The entry is dubious because the host knows that the gateway exists, but does not know if it is a prime gateway. A count is kept of the number of times a packet is sent to that gateway. If, say, five packets are sent to the gateway, and no redirect is ever seen from it, then the gateway is deleted from the host's prime gateway table. If a redirect is seen from the gateway in question, the gateway's entry may be upgraded from "dubious" to "certain." In this way, a host can slowly accumulate information about the gateways that are of most use to it in the internet. Although I am biased (since the above scheme is of my own design), I believe that the idea of cycling through the list of known gateways is the "way to go." The advantages I see are, once more: 1. Solves "black hole" disease 2. Shares the "redirect" load among many gateways 3. Allows a host to dynamically learn about new prime gateways - Geof Cooper MIT ------------------------------ Date: 22 Jun 1983 1132-PDT Subject: Re: Warning, TCP-4 problems From: Craig Milo Rogers To: David Roode , HEDRICK@rutgers, MRC@su-score cc: RLL.TYM@office-2, tharris@ddn1, jmayersohn@bbn-unix, ddnsr@bbn-unix, tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score The programs IGGSTS.EXE and IGWSTS.EXE on ISIA,B,D-F will print TOPS20's Ping table and network routing table, respectively. (The names are holdovers from the GGP days). However, I don't expect these programs to work outside ISI, because they use an ISI-specific (I think) JSYS to map monitor pages (GTMPG). The sources are in BLISS-10. There are help files in . You need the Wheel privelege to run the programs. Craig Milo Rogers ------------------------------ Date: Tue, 28 Jun 83 21:45:37 EDT From: Ron Natalie To: tcp-ip@brl-bmd, unix-wizards@brl-bmd cc: msggroup@brl-bmd Subject: Security Problem? I have noticed that many sites have taken the precaution of having their login programs (and their FTP servers) not make a distinction between an invalid user name and an invalid password. The reasoning behind this is that if a user could tell, he could sit there hacking a user name until he got a valid one and then start hacking its password. While trying to figure out a user name that I had written down rather illegibly, I found this is a rather effective deterrent to those guessing at user name. Until I got the following idea. I connected to the site's SMTP server and did the following: 220 HOST-OF-HOSTS SERVER SMTP HELO HACKER 250 HOST-OF-HOSTS MAIL FROM: 250 OK RCPT TO: 550 We have no "ROT" here. RCPT TO: 250 Recipient accepted. Since most machines have mailboxes that are the same as the valid login names, this may prove an effective way of hacking the names. In addition, the easiest way to get user names at valid hosts is to just subscribe to one of the busy mailing lists and use the ones of those sending mail. -Ron ------------------------------ Date: 29 Jun 1983 09:10-PDT Sender: GEOFF@sri-csl Subject: Re: Security Problem? From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff@sri-csl To: ron@brl-bmd Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd Cc: msggroup@brl-bmd A real easy way of "hacking names" on a host is to just connect up with TELNET and do a SYSTAT or FINGER. Big Deal. A gourmet "name hacker" would use the NIC's informative "WHOIS" Server. Just give the name of your favorite host preceded with a star `*' (i.e. try `*brl' for example) and a nicely formatted list, replete with full name, initials(nic id), mailbox and phone number will promptly be displayed. Happy Hacking. ------------------------------ Date: Wednesday, 29 Jun 1983 12:41-PDT To: Ron Natalie Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd, msggroup@brl-bmd Subject: Re: Security Problem? From: greep@su-dsn Other tactics include looking in the Arpanet directory or just trying common names. In addition, many Unix sites have a "who" login that runs the "who" or "finger" program, and most tops-20 sites let you run "finger" or "systat" without being logged in. In fact, you can (at least with some dec-20's) run finger with a null argument and get a list of every user (not just those logged in). It is generally agreed that keeping user names secret is not a reasonable thing to do -- that's what passwords are for. ------------------------------ Date: Tue 28 Jun 83 23:17:08-PDT From: Mark Crispin Subject: Re: Security Problem? To: ron@BRL-BMD.ARPA cc: tcp-ip@BRL-BMD.ARPA, unix-wizards@BRL-BMD.ARPA, msggroup@BRL-BMD.ARPA One thing you could do would be to not validate mailboxes in the SMTP server, but that only delays the error message unless you "black hole" mail to invalid mailboxes. It's a trade-off between security and friendliness. ------------------------------ Date: 28 Jun 1983 2357-PDT Subject: Re: Security Problem? From: Einar Stefferud To: ron@brl-bmd Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd Cc: msggroup@brl-bmd [ Comments to MSGGROUP readers deleted here -Mike ] Rather than trying to shut down the ability to extract login names from mail servers, I think attention should be focused on other security techniques. Like, making the penalty higher for failing to login correctly, and making the user start over at the beginning of the whole process when an error occurs before completion. One thing to do is force a delay following any failure, like an extra 5 or 10 seconds, which slows down the hacking rate to less than 6 tries per minute. Then, I think that too many failures in a row should cause a disconnect, which further slows down serious password hackers. Seems to me that it is too easy to put obstacles in the way to let ourselves get sidetracked into trying to conceal names. Whither goest the whole idea of name-servers if we try to close the mail gap? So, lets just chase this issue back to the other lists, unless a more genuine mail connection can be conjured up. Cheers - Stef ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [587%40brl-bmd.UUCP] <1983063004362500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: TCP-IP%brl@brl-bmd.UUCP Newsgroups: fa.tcp-ip Subject: TCP-IP Digest, Vol 2 #12 Message-ID: <587@brl-bmd.UUCP> Date: Thu, 30-Jun-83 08:36:25 EDT Article-I.D.: brl-bmd.587 Posted: Thu Jun 30 08:36:25 1983 Date-Received: Thu, 7-Jul-83 21:09:18 EDT Lines: 489 TCP/IP Digest Thursday, 30 June 1983 Volume 2 : Issue 12 Today's Topics: IBM VM TCP/IP Implementation Now Exists Contacts within IBM for TCP/IP Information Hooking IBMs to an Ethernet? Gateways: When should I ping, When should I purge, Who should I have? Program to print TOPS20's Ping Table Security Problem with Mail? Probably not. ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- Date: 22 Jun 1983 13:22:04-CDT From: L.H. Landweber Reply-to: ibm-project@uwisc To: tcp-ip@brl Subject: IBM VM TCP/IP IMPLEMENTATION TCP/IP IBM VM IMPLEMENTATION We are implementating of the Internet protocols (FTP/SMTP/Telnet/TCP/IP) for IBM VM Systems under contract with IBM. The TCP and IP have been running for some time now under VM/SP on an IBM 4331 at Wisconsin and we are currently putting the finishing touches on the higher-level protocols. In addition, a software interface between IP and an X.25 implementation running on a Series/1 (RPS operating system) has been completed. The complete package will enable CSNET IBM VM hosts to connect to the Darpa Internet via Telenet. The 4300 software is written almost entirely in Pascal, with a small amount of assembler-language support. Some assembler code running on the Series/1 interfaces with the X.25 code, which is a standard IBM product. Standard IBM released software is used throughout (i.e., no modified or unreleased system software has been employed). The software will be ready for initial distribution to test sites in mid-July. We hope to have production versions available by the end of August. Distribution will be controlled by IBM. We encourage interested parties to contact: Mr. Carl VanWinter IBM Corporation Rochester, MN 507-286-3378 to express an interest or request information on distribution plans. ADDITIONAL DETAILS TCP/IP runs in a separate disconnected virtual machine. Similarly, SMTP, server FTP, and server Telnet each occupies a dedicated virtual machine. User FTP and user Telnet run within a user's virtual machine under CMS. Communication between virtual machines is done through the IBM Virtual Machine Communication Facility (VMCF). A detailed preliminary design document is available by contacting one of the individuals listed below. (Some details have changed since it was written, but it is still mostly accurate.) Over the Summer we expect to implement a Pronet driver to enable our IP/TCP to use the PRONET 10 megabit/sec token ring LAN. The hardware interface will be via a DACU (Device Access Control Unit) provided by IBM. The DACU enables connection of UNIBUS devices to an IBM channel. We expect other university groups to provide a driver for Ethernet. We estimate that each of these projects will take 2-4 man-months to complete. Direct connection to a C/30 IMP will require implementation of a software driver in conjunction with a suitable hardware interface (e.g., DACU--LH/DH or Series/1--HDH). For further technical information contact: David DeWitt, Larry Landweber, or Marvin Solomon Computer Science Department University of Wisconsin 1210 W. Dayton St. Madison, WI 53706 608-262-1204 ibm-project@uwisc ------------------------------ Date: Thu 23 Jun 83 09:08:37-PDT From: Suzanne Johnson Subject: tcp/ip ibm info To: tcp-ip@BRL.ARPA It turns out that if you give your IBM rep VERY specific information on WHO and WHERE within IBM the tcp/ip work goes on, they can follow up for you. The tcp/ip work is evidently being done by IBM's Federal Systems Division in Gaithersburg, Maryland. The person doing the work is Doug McKay. Our rep was able to confirm this, given the above info. Since he is somewhat up-to-date on status, you might have your rep contact our IBM rep. His name is Waymon Lee, and phone # is 415-855-0519. Let us know what you find out. Suzanne Johnson ------------------------------ Date: 23 Jun 1983 at 1527-PDT From: dan@sri-tsc To: Suzanne Johnson cc: tcp-ip@brl Subject: Re: ibm tcp/ip Doug McKay is indeed working on TCP/IP for the Series I. He is porting the SRI TCP/IP for PDP11/44's (which is itself a port of the 4.1b BSD VAX UNIX TCP/IP). It was my understanding that it is being integrated into the version of UNIX they have running on the Series I and whatever other IBM systems are running UNIX. I don't know if his group is also working on TCP/IP for non-unix operating systems, but I got the impression from talking to him that they were not. -Dan Chernikoff (dan@sri-tsc) SRI International ------------------------------ Date: 23 Jun 1983 0:57-EDT From: Lee.Moore@Rochester.ARPA Subject: Re: TCP-IP Digest, Vol 2 #11 To: tcp-ip@brl-vgr.ARPA Origin: Filter-Queen RE: hooking IBM's to an ethernet I recently got a glossy brochure describing an IBM channel interface for ethernet from ACC. Does anybody know anything about this? =lee ------------------------------ Date: 22 Jun 1983 0209-PDT Sender: GEOFF@sri-csl Subject: Gateways- When should I ping, When should I purge, Who should I have? From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff@sri-csl To: POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score To: snelson@office-1, bhitson@bbn-unix, tcp-ip@brl So far we have heard that pinging gateways in a hosts gateway cache every 37 seconds is too often and that very likely every TENEX and TOPS-20 site on the ARPANET is currently doing this. We had a suggestion that it might not be necessary to ping gateways at all. However, it was also suggested pinging gateways periodically might be a good idea. It was suggested that entries in a hosts dynamic gateway table should be aged and deleted after about an hours time. A number of informed parties suggested that each site configure the contents of their INTERNET.GATEWAYS file very carefully and some very helpful guidelines for choosing the initial contents of your INTERNET.GATEWAYS file was given. What I would like to see explored, discussed and hopefully resolved by this group is: 1) What is the ideal interval with which to PING and under what circumstances should I PING? 2) What is the ideal time a gateway entry should remain in a given hosts gateway table before it is aged and flushed? I think how one should configure the contents of their initial INTERNET.GATEWAYS file was pretty well explained by Charlie Lynn, but I still have not heard anything concrete enough on the subject of when to PING and when to purge to make me dash to my TENEX sources and stick the code in. Could we hear from other operating system wizards on how FUZZBALLS, TAC's, UNIX, Multics, VMS, IBM hosts, TIU's and so forth have done it and from the Internet Holy Water Sprinklers on what the ideal values would be? ------------------------------ Date: 22 Jun 1983 0329-PDT From: Henry W. Miller Subject: Re: Gateways- When should I ping, When should I purge, Who should I have? To: Geoff@sri-csl, POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score, tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score cc: Miller@sri-nic 1) Jon sez that it is not necessary to ping; that ICMP redirects will handle it. OK, seems reasonable, depending on your net traffic. Knowing a probable path, and trying it first, and recovering from it in case of error seems more efficient than probing J. Random Prime Gateway, hoping for a win. (This is why I'm in favor of rich gateway tables; it gives you more initial options.) 2) If you choose to ping, to keep up with the state of the network, 37 seconds is clearly too short of a period to get a snapshot of the net. A couple of un-ACKED probes could lead one to believe that a gate is down, when in fact, it might not be. If pinging is desired, then an interval that is suffcently long should be used, say 5-10 minutes. (Personal opinion: A ping from a host coming back on the air COULD/SHOULD be interpreted as an "I'm Alive" message. The gateways, in their infinte wisdom, could spread the good news across the networks, so the various hosts could update their routing tables. Likewise, the hosts should be able to poll the gateway of their dreams on occaision and receive, in return, the latest routing poop. A maxi ping, fer surre, but would help eliminate senseless probings...) 3) Updating routing tables: again, depending upon your internet needs, 30 minutes at the max. (Smallest interval...) The current default, I believe is 6 hours. 4) Another thot: put a timer block in for each gateway: when to ping next. This would allow pinging on a selective basis. -HWM ------------------------------ Date: 22 Jun 1983 9:08:55 EDT (Wednesday) From: Dennis Rockwell Subject: Re: Gateways- When should I ping, When should I purge, Who should I have? To: Geoff@sri-csl Cc: POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score, RLL.TYM@office-2, DAB2.GVT@office-2, snelson@office-1, bhitson@bbn-unix, tcp-ip@brl BBN UNIX hosts ping all gateways that are currently in use (defined as having an open connection which has as its local-net destination a gateway) constantly, at a rate of once every few seconds. We have thought about fancy schemes involving only pinging when TCP has to retransmit, but this leaves users of non-TCP services out in the cold. The rapid rate of pinging is for detection of a dead first-hop gateway. Unless one assumes an 1822 net, there is very likely no feedback as to whether a packet is delivered or not (as was previously noted, ethernet in particular has no such feedback). Since we only ping active gateways, our hosts' gateway table contains all the gateways we can find out about that are connected to whatever local net(s) we are connected to. ------------------------------ Date: 22 Jun 1983 1433-EDT From: Geoffrey H. Cooper Subject: RE: Sending Pings to Gateways To: TCP-IP@brl cc: clynn@bbnc, geof@mit-xx CLYNN's message describing the way in which TOPS-20 uses its list of internet gateways brings up a more general problem with ICMP. As mentioned by Postel (in the last digest), every host implementation of internet routing maintains a cache of pairs, and a list of "prime" internet gateways. When a packet is routed the Internet implementation first searches the cache for an appropriate gateway to use. If this search fails, the packet is sent to a "default intelligent (prime) gateway" which will send a redirect back to the host IF A BETTER GATEWAY EXISTS FOR THAT NET, so that subsequent packets to the same net will hit the host's cache. Note that the prime gateway can not be relied upon to send a packet back (this is a necessary part of the way internet routing works, since otherwise a prime gateway would have to send back a redirect to itself for EVERY packet it forwards). The question that arises is to which of the default gateways that are known to the host should a "defaulted" packet be sent? The answer is, of course, to the least-loaded, working (up), closest default gateway. Unfortunately, none of those attributes is determinable by the host. If the host is on the Arpanet, it would be possible to make use of the arpanet's "host dead" messages to determine that a particular prime gateway doesn't seem to be working (either because it is too busy or crashed). Thus, it would be possible to order the prime gateways that a host knows about in order of "usefulness to the host" (or perhaps closeness on the network is the best static measure to use). The best gateway (earliest on the list) is always used, and the network status messages are used to declare that gateway's entry temporarily invalid when packets sent to it result in "host dead" messages. If the host is on a network other than the Arpanet, the problem is more severe, since the network will generally not take the responsibility to tell the host that a packet it sent was not received by the gateway to which it was sent (the Ethernet is the best example of such a network). If all packets are sent by default to a single "best" gateway and that gateway is down, then all the packets will fall into a "black hole" and a section of the internet will become inaccessible to the host. One way to deal with this situation is what is done by Tops-20: Explicitly and regularly find out what prime gateways are up, and always send your packets to the best prime gateway that is up. The last issue of the digest described some of the problems with this approach. Another approach is to use the telephone company's ''linefinder'' algorithm: Keep the N prime gateways that a host knows about in an ordered table, and cycle through the table (i.e., always use the ''next'' gateway after the one that you last used). The host maintains no information on the state of the prime gateways in its tables. Some packets will indeed be sent to the "black hole" of a crashed prime gateway; higher level protocols can be counted upon to retransmit these packets, and will hit other gateways on the retransmissions. One advantage of this scheme is that it ``load shares'' the burden of sending redirects among all of the prime gateways that a host knows about, rather than placing undue burden on one particular gateway that it considers to be the "best." Another advantage is that it leaves a host implementation open to the add the identities of new prime gateways to its tables. Consider the following algorithm: when a host receives a redirect to a gateway, it place a ``dubious'' entry for that gateway into its prime gateway table. The entry is dubious because the host knows that the gateway exists, but does not know if it is a prime gateway. A count is kept of the number of times a packet is sent to that gateway. If, say, five packets are sent to the gateway, and no redirect is ever seen from it, then the gateway is deleted from the host's prime gateway table. If a redirect is seen from the gateway in question, the gateway's entry may be upgraded from "dubious" to "certain." In this way, a host can slowly accumulate information about the gateways that are of most use to it in the internet. Although I am biased (since the above scheme is of my own design), I believe that the idea of cycling through the list of known gateways is the "way to go." The advantages I see are, once more: 1. Solves "black hole" disease 2. Shares the "redirect" load among many gateways 3. Allows a host to dynamically learn about new prime gateways - Geof Cooper MIT ------------------------------ Date: 22 Jun 1983 1132-PDT Subject: Re: Warning, TCP-4 problems From: Craig Milo Rogers To: David Roode , HEDRICK@rutgers, MRC@su-score cc: RLL.TYM@office-2, tharris@ddn1, jmayersohn@bbn-unix, ddnsr@bbn-unix, tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score The programs IGGSTS.EXE and IGWSTS.EXE on ISIA,B,D-F will print TOPS20's Ping table and network routing table, respectively. (The names are holdovers from the GGP days). However, I don't expect these programs to work outside ISI, because they use an ISI-specific (I think) JSYS to map monitor pages (GTMPG). The sources are in BLISS-10. There are help files in . You need the Wheel privelege to run the programs. Craig Milo Rogers ------------------------------ Date: Tue, 28 Jun 83 21:45:37 EDT From: Ron Natalie To: tcp-ip@brl-bmd, unix-wizards@brl-bmd cc: msggroup@brl-bmd Subject: Security Problem? I have noticed that many sites have taken the precaution of having their login programs (and their FTP servers) not make a distinction between an invalid user name and an invalid password. The reasoning behind this is that if a user could tell, he could sit there hacking a user name until he got a valid one and then start hacking its password. While trying to figure out a user name that I had written down rather illegibly, I found this is a rather effective deterrent to those guessing at user name. Until I got the following idea. I connected to the site's SMTP server and did the following: 220 HOST-OF-HOSTS SERVER SMTP HELO HACKER 250 HOST-OF-HOSTS MAIL FROM: 250 OK RCPT TO: 550 We have no "ROT" here. RCPT TO: 250 Recipient accepted. Since most machines have mailboxes that are the same as the valid login names, this may prove an effective way of hacking the names. In addition, the easiest way to get user names at valid hosts is to just subscribe to one of the busy mailing lists and use the ones of those sending mail. -Ron ------------------------------ Date: 29 Jun 1983 09:10-PDT Sender: GEOFF@sri-csl Subject: Re: Security Problem? From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff@sri-csl To: ron@brl-bmd Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd Cc: msggroup@brl-bmd A real easy way of "hacking names" on a host is to just connect up with TELNET and do a SYSTAT or FINGER. Big Deal. A gourmet "name hacker" would use the NIC's informative "WHOIS" Server. Just give the name of your favorite host preceded with a star `*' (i.e. try `*brl' for example) and a nicely formatted list, replete with full name, initials(nic id), mailbox and phone number will promptly be displayed. Happy Hacking. ------------------------------ Date: Wednesday, 29 Jun 1983 12:41-PDT To: Ron Natalie Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd, msggroup@brl-bmd Subject: Re: Security Problem? From: greep@su-dsn Other tactics include looking in the Arpanet directory or just trying common names. In addition, many Unix sites have a "who" login that runs the "who" or "finger" program, and most tops-20 sites let you run "finger" or "systat" without being logged in. In fact, you can (at least with some dec-20's) run finger with a null argument and get a list of every user (not just those logged in). It is generally agreed that keeping user names secret is not a reasonable thing to do -- that's what passwords are for. ------------------------------ Date: Tue 28 Jun 83 23:17:08-PDT From: Mark Crispin Subject: Re: Security Problem? To: ron@BRL-BMD.ARPA cc: tcp-ip@BRL-BMD.ARPA, unix-wizards@BRL-BMD.ARPA, msggroup@BRL-BMD.ARPA One thing you could do would be to not validate mailboxes in the SMTP server, but that only delays the error message unless you "black hole" mail to invalid mailboxes. It's a trade-off between security and friendliness. ------------------------------ Date: 28 Jun 1983 2357-PDT Subject: Re: Security Problem? From: Einar Stefferud To: ron@brl-bmd Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd Cc: msggroup@brl-bmd [ Comments to MSGGROUP readers deleted here -Mike ] Rather than trying to shut down the ability to extract login names from mail servers, I think attention should be focused on other security techniques. Like, making the penalty higher for failing to login correctly, and making the user start over at the beginning of the whole process when an error occurs before completion. One thing to do is force a delay following any failure, like an extra 5 or 10 seconds, which slows down the hacking rate to less than 6 tries per minute. Then, I think that too many failures in a row should cause a disconnect, which further slows down serious password hackers. Seems to me that it is too easy to put obstacles in the way to let ourselves get sidetracked into trying to conceal names. Whither goest the whole idea of name-servers if we try to close the mail gap? So, lets just chase this issue back to the other lists, unless a more genuine mail connection can be conjured up. Cheers - Stef ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END----