----MESSAGE-BEGIN---- [8609301256.AA17280%40mitre.ARPA] <1986100101593300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: raklein@MITRE.ARPA (Richard A. Klein) Newsgroups: mod.protocols.tcp-ip Subject: Re: Do we need another protocol? Message-ID: <8609301256.AA17280@mitre.ARPA> Date: Wed, 1-Oct-86 05:59:33 EDT Article-I.D.: mitre.8609301256.AA17280 Posted: Wed Oct 1 05:59:33 1986 Date-Received: Fri, 3-Oct-86 00:32:28 EDT References: <8609291632.AA00161@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 25 Approved: tcp-ip@sri-nic.arpa I'm getting tired of listening to people pontificating DoD policy. The reason why that particular organization in the U. S. Army did not choose the MIL-STD protocol suite (TCP/IP) is because they are not well informed on the existance and benefits of the DoD protocol suite. In addition, the U. S. Army organization in charge of developing standards is not well informed and has been remiss in general with regard to getting standards out to the rest of the Army. JTC3A's lack of progress in developing protocol standards for tactical applications for all of DoD has further hampered the standardization effort. But the real crux of the matter is that WE are responsible, as consultants, engineers, researchers, etc., for insuring the recommended use of the DoD MIL-STDs when appropriate. I'm currently supporting the Army's effort to "go ISO." This means that they want a "militarized" ISO protocol suite right-a-way, and they don't want to be bothered by an intermediate standard such as TCP/IP (?!). Some how or the other, we will make the best effort to direct them towards the right standards for the right times. I have found that the most convincing arguments are demonstrations to the sponsor of the real benefits of using TCP/IP now, ISO later, when it is tested and proven. By the way, watching the bureaucrats yell policy at each other has proven to us, without a doubt, that it won't get you anywhere. Richard ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100108414000> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Wed 1 Oct 86 09:46:07-PDT Received: by vax.darpa.mil (4.12/4.7) id AA01322; Wed, 1 Oct 86 12:41:49 edt Date: Wed 1 Oct 86 12:41:40-EDT From: Dennis G. Perry Subject: Congestion in the Arpanet To: tcp-ip@SRI-NIC.ARPA Cc: perry@VAX.DARPA.MIL Message-Id: There has been quite a bit of conjecture on what is happening in the Internet and what are the reasons for the performance that people are seeing. I have been trying to understand these issues myself and asked BBN to provide me with some information. Attached is some of that information. I hope it raises other questions and answers a few. dennis --------------- ----- Forwarded message # 1: Received: from cc5.bbn.com by .J.BBN.COM id a021878; 30 Sep 86 23:35 EDT To: jburke@cc5.bbn.com, mlevandowski@cc5.bbn.com, rgrenier@cc5.bbn.com, sblumenthal@cc5.bbn.com, mckenzie@cc5.bbn.com, pogran@cc5.bbn.com To: prishivalko@cc5.bbn.com, dperry@vax.darpa.mil cc: mayersoh@cc5.bbn.com, jwiggins@cc5.bbn.com, cgreenleaf@cc5.bbn.com, mprimak@cc5.bbn.com, fserr@cc5.bbn.com, scohn@cc5.bbn.com, hinden@cc5.bbn.com Subject: arpanet congestion Date: 30 Sep 86 23:16:58 EDT (Tue) From: Jeff Mayersohn For the last month, a large number of PSNs in the Arpanet have been reporting symptoms of congestion to the network monitoring center. These reports, or "traps," have been accompanied by an increasing number of user complaints. In order to deal with the problem of network congestion, we have been pursuing a number of avenues at BBNCC. This note summarizes the current state of our investigations and makes a number of specific recommendations. First, a little background. The Arpanet topology is largely unchanged since the physical split of the Arpanet into the Arpanet and Milnet in 1984. The topology of the post-physical-split Arpanet was actually designed from data which was collected before the earlier logical split of the two networks. In the past year, the network has shown a significant increase in traffic. A five-day average of network traffic showed an internode traffic rate of 140 Kbps in June of 1985 and an internode traffic rate of 230 Kbps in March of 1986. (The traffic growth had, in fact, leveled off over the summer of 1986 but we suspect that traffic has grown even more since the start of the academic year.) The network has recently been redesigned to accommodate NSF hosts, but these new resources have not yet been added to the network. Marianne Gardner has observed some very interesting trends in the statistics that we have collected recently. First, a very small percentage of host pairs account for a very large percentage of the network traffic. More than 80% of network traffic is contributed by 600 host pairs (out of 2596 communicating pairs). Some 60% of the traffic is contributed by 100 pairs. Second, gateway traffic dominates network traffic. 86% of Arpanet traffic has a gateway as either the source of destination. 52% of network traffic is between gateways. Our immediate focus over the last few weeks has been to concentrate on topological modelling in order to recommend a small number of changes which would bring network resource usage to acceptable levels. This modelling was based upon the peak hour traffic in late June, the last month during which a global network statistics collection was performed. The measured June traffic was increased by 50%. This number was based upon the recent growth in network traffic and the ratio of the peak hour traffic to the peak minute traffic. The assumption is probably conservative, which is good. The modelling work was done by Peg Primak, whose report is contained in the following. As of June, 1986, the Arpanet contained 47 nodes and 63 links. Two of these nodes have since been retired (SAC2 and USC) but were retained in the current model with all USC traffic re-routed to node 121. Our routing model shows single hour maximum link utilization of 75% (on UWisc-Roch) and maximum node utilization of 69%. Even with the UWisc-Purdue link restored, the maximum link utilization is still 72% and the maximum node utilization is 69%. (The Wisconsin to Purdue link was temporarily removed from the network a while ago.) To alleviate the worst of these problems, we considered adding a link from MIT77 to SRI51. The addition of this link reduces maximum link utilization to 58% (on the new link), with only two other links having utilizations over 50% (53% and 51%). Node utilization remains unchanged. The network diameter is reduced from 10 to 9 by the addition of this link. As these results show, a link between MIT77 and SRI51 would substantially improve Arpanet performance, and would become one of the most heavily utilized links in the network. Node utilization is quite heavy on several nodes. Normal utilization over seven minute intervals seems to be between 30% and 60% for all of the following nodes: ISI27, UCLA, RCC5, and UWISC. With the MIT-SRI link added, SRI51 will join this group. Measurement data show that each of these nodes experiences times of very heavy utilization (15 minute averages of 60% to 70%, 7 minute averages of 87%). Based on the June data, either nodes should be added at these sites or the five nodes at these sites should be upgraded to C/300s. We assume that the addition of trunk bandwidth will take a while. There are a number of other actions which we would like to take. First, TAC 113 should be installed immediately in the Arpanet. This provides for two changes that should reduce congestion. First, the release bundles more characters into single packets, thereby reducing the number of bits and packets required to send a given unit of Telnet data. TAC 113 also modifies the TCP retransmission timers. We probably get the wrong kind of feedback when the network slows down. If data is delayed due to network congestion, we suspect that this gives rise to TCP retransmissions which exacerbate the original problem. Bob Hinden of our gateway group tells me that, in the next two weeks, we will conduct an experiment which will make the Wideband Network look more favorable to the internet routing in the Butterfly gateways. This will cause some gateway-to-gateway traffic to move from the Arpanet to the Wideband Network. We have observed that, when network links get heavily saturated, the network routing algorithm becomes a bit too dynamic, trying to find excess capacity which does not exist. The effect of the resulting oscillations in network routing sometimes works to the detriment of network performance. There is a simple fix to this, i.e., we can easily make all three cross-country paths look equivalent to the routing algorithm. This results in the proper sort of load-sharing. There is still the possibility that we are running short of end-to-end resources. We are currently measuring the utilization of these resources to see whether this is the case. If we are short of these resources, there may be easy remedies to this in the PSN software. Our efforts over the last few weeks have concentrated on the modelling work. We have not had the opportunity to accumulate or study global network statistics collection in order to understand what has changed in the last month. John Wiggins and Clive Greenleaf have begun this collection today. Simple questions which should be answered are: 1) where has traffic increased? 2) are gateways using the network differently? 3) are we seeing large amounts of internet control traffic as we have in the past? 3) would the addition of mailbridges improve the situation? 5) should homings of hosts to mailbridges be changed? In summary, we should pursue the following: 1) A link from MIT to SRI51 should be added. 2) Node capacity should be added at ISI27, UWISC, RCC5, UCLA, SRI51 3) The planned addition of resources should be accelerated. 4) TAC 113 should be installed. 5) The network parameters should be adjused in order to result in more even sharing of the cross-country bandwidth, should statistics confirm that routing oscillations are occurring. 6) The Wideband Network experiment should be conducted as soon as possible. 7) Additional statistics should be collected in order to shed light on the underlying causes of the congestion. We will let results be known as soon as we have them. 8) The Purdue to Wisconsin link should be restored asap. ----- End of forwarded messages ------- ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610011740.AA28707%40bu-cs.bu.edu] <1986100109404500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: mod.protocols.tcp-ip Subject: Do we need another protocol? Message-ID: <8610011740.AA28707@bu-cs.bu.edu> Date: Wed, 1-Oct-86 13:40:45 EDT Article-I.D.: bu-cs.8610011740.AA28707 Posted: Wed Oct 1 13:40:45 1986 Date-Received: Fri, 3-Oct-86 09:17:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 55 Approved: tcp-ip@sri-nic.arpa Re: record-level access in TCP This has come up before as being seriously lacking in other contexts. It may be a can of worms due to the nature of heterogeneous networks, usually the person calling for it is thinking of just THEIR record level access (eg. VMS/RMS.) My usual reaction is that this problem has not been adequately solved for magnetic tapes across heterogeneous systems so I suspect there is a nut there to crack, it's not like tape users never thought of it. Even if OpenNet gets you this service to another OpenNet/Intel310 host, I doubt it helps you much with a PDS file on the MVS system down the hall. It just solves the easy, short term problem. I would suggest the community start looking hard at how far NFS/RPC/XDR from SUN (and, as we all know, being adopted as a layered protocol on TCP/UDP/IP by almost every major computer vendor) can be used to solve the problem. It's not really 'record' level access, the question is better put as: "How in general can I create a network I/O stream which, rather than bytes, uses an arbitrary structured data type, with a file offset calculation, as a unit of transfer?" Perhaps just semantics but I think it brings one a little closer to understanding why something like XDR/RPC already addresses this problem to a large extent and working from that base, where weaknesses are perceived, might be the most profitable route to a solution (lord I sound pedantic, sorry...) Essentially (for those who haven't looked at the SUN protocols) one sits down (they have already) and defines a network representation for various primitive types (eg. byte order and format of integers). Then a method for constructing arbitrary data types out of those as n-tuples. Then a protocol for exchanging what you have in mind (as a trivial example exchanging a fortran format string would be close) and finally a remote procedure call protocol for specifying various remote operations. To stave off the flood of "XYZ system has been doing that for years", yes, we know, but XYZ system is not licensable on our machines, is it? The XDR/RPC protocols (protocols != code) are in the public domain. And yes, I don't think it would be a good idea to put this into FTP until this layer is defined. At some later date it might be clear how these mechanisms can best be utilized in an extension to FTP for some subset, but I doubt FTP is designed to support such generality. -Barry Shein, Boston University P.S. I have no economic interests in any of this, if I did I'd probably be rich and out spending my money instead of typing this stuff in... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610011812.AA29036%40bu-cs.bu.edu] <1986100110125300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: mod.protocols.tcp-ip Subject: Peace fullness. Message-ID: <8610011812.AA29036@bu-cs.bu.edu> Date: Wed, 1-Oct-86 14:12:53 EDT Article-I.D.: bu-cs.8610011812.AA29036 Posted: Wed Oct 1 14:12:53 1986 Date-Received: Tue, 7-Oct-86 07:56:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa > As a developer it IS my responcibility to produce a product that my >clients desire and to develop new features and approches. > > I have done just that, but I am afraid to market it. Why ? Because the >Universities will produce a public (or very cheap) version and have their >name behind it! All my time, effort and MONEY will be wasted. I am not sure this is the right list to address this issue although I am not sure what the right list is. Apologies in advance. Your problem is ubiquitous to the software industry. It's caused by a conception of software as merchandise, a comfortable conceptualization in an economy that by and large likes to break things down into such catagories. Unfortunately, software does not fit that paradigm very well as you have discovered. It is closer to a service than a product. Recordings and books have various similarities, but in general a song by a particular artist is not easily replaced by a very similar song by a very similar artist, so copyright is effective. That is, software is too easy to duplicate and its function is fairly specific, thus my TCP program that I give away for free may very well wipe out your TCP program that you sell. I doubt too many people would like to have a recording of something that sounds a lot like me singing what might be a Michael Jackson song, or a story I've written very much in the style of Ernest Hemmingway (there is a contest however...) If one accepts the problem rather than fights it, one might come to the conclusion that the software should be sold for a nominal fee and the real product would be continuing support as a subscription. This most Universities have little interest in providing. It's probably not a bad business either tho perhaps not as trivial as sitting down, writing a program, selling a zillion copies and then never incurring another cost except that of copying floppies and mailing them out. You might actually have to work for a living! It's no wonder that racket has a few weaknesses although I don't doubt it would be (and has been) massively profitable. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12243387581.48.ROMKEY%40XX.LCS.MIT.EDU] <1986100111364000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ROMKEY@XX.LCS.MIT.EDU (John Romkey) Newsgroups: mod.protocols.tcp-ip Subject: Re: MIT pcip and 3com board Message-ID: <12243387581.48.ROMKEY@XX.LCS.MIT.EDU> Date: Wed, 1-Oct-86 15:36:40 EDT Article-I.D.: XX.12243387581.48.ROMKEY Posted: Wed Oct 1 15:36:40 1986 Date-Received: Fri, 3-Oct-86 08:08:08 EDT References: <8609301713.AA15763@amdcad.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa If the 3C501 is connected to the ether via a DELNI the VAX has an Interlan transceiver, you will probably have problems. I've heard reports from a number of places that 3COM cards connected to DELNIs can't reliably talk to a number of vendors transceivers. (these are only *rumors*, mind you...) The problem is supposed to be that the ethernet chip used on the 3C501 doesn't grok heartbeat, and you can't get DELNIs not to do heartbeat. - john ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100111400000> Received: from UCLA-CCN.ARPA by SRI-NIC.ARPA with TCP; Wed 1 Oct 86 18:41:06-PDT Date: Wed, 01 Oct 86 18:40 PDT To: Submit to TCP/IP From: Todd Booth 213-825-1933 Subject: Re: Implementation list > Shouldn't this (in theory) be part of the NIC's > tcpip-implementations.txt, John Romkey > file? The file has been renamed Netinfo:vendors-guide.doc -todd ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12243390211.BABYL%40XX.LCS.MIT.EDU] <1986100111510000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: SRA@XX.LCS.MIT.EDU (Rob Austein) Newsgroups: mod.protocols.tcp-ip Subject: SMTP, 2600, and the security of mail Message-ID: Date: Wed, 1-Oct-86 15:51:00 EDT Article-I.D.: XX.SRA.12243390211.BABYL Posted: Wed Oct 1 15:51:00 1986 Date-Received: Fri, 3-Oct-86 07:27:34 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Date: Monday, 29 September 1986 18:17-EDT From: Stu Grossman You could (marginally) increase the security of SMTP traffic by having SMTP servers only accept connections from a 'privileged' remote socket. Bad idea. Nobody has ever agreed on what a "priviledged port" is. Berkeley has used that concept for some of their net code (I'm thinking of LPD in particular). It doesn't add any security when talking to TOPS-20 or ITS, it's just a pain in the butt because I can't let the TCP software do the local port multiplexing for me. This whole discussion seems pretty pointless, since everybody accepts the need for mail relays and you can't ever possibly verify what happened on the other side of the mail relay. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12243391985.BABYL%40XX.LCS.MIT.EDU] <1986100112000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: SRA@XX.LCS.MIT.EDU (Rob Austein) Newsgroups: mod.protocols.tcp-ip Subject: SMTP, 2600, and the security of mail Message-ID: Date: Wed, 1-Oct-86 16:00:00 EDT Article-I.D.: XX.SRA.12243391985.BABYL Posted: Wed Oct 1 16:00:00 1986 Date-Received: Fri, 3-Oct-86 07:24:41 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Date: Tuesday, 30 September 1986 13:29-EDT From: The lost Bostonian To: header-people@mc.lcs.mit.edu, tcp-ip@sri-nic.arpa If it is true that all IP implementations enable a server program to determine the IP address of its peer, then the HELO command, and its response could be eliminated, which would save us a few bytes. You are assuming that it is always possible to translate addresses to names and vice versa. Unfortunately, there are some people out in the world running domain nameservers who are totally clueless about what they are doing, and there are others who have the misfortune to be stuck behind a losing gateway or otherwise be unreachable much of the time. Do you really want to make it impossible to receive mail from some host because a third party is broken? Or have to put numeric addresses into the Recieved headers? The answer is to fix the silly net, not throw away features to save two IP packets. --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610030715.AA13668%40ucbvax.Berkeley.EDU] <1986100112180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jrodrig@EDN-VAX.ARPA (Jose Rodriguez) Newsgroups: mod.protocols.tcp-ip Subject: Sun NFS RFC Message-ID: <8610030715.AA13668@ucbvax.Berkeley.EDU> Date: Wed, 1-Oct-86 16:18:00 EDT Article-I.D.: ucbvax.8610030715.AA13668 Posted: Wed Oct 1 16:18:00 1986 Date-Received: Fri, 3-Oct-86 08:07:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa And if there are changes to it, what would happen to all those implementations? RFC?, ya... Jose jrodrig@edn-vax ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610011923.aa07356%40SEM.BRL.ARPA] <1986100115234900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: Why is the ARPANet in such bad shape these days? Message-ID: <8610011923.aa07356@SEM.BRL.ARPA> Date: Wed, 1-Oct-86 19:23:49 EDT Article-I.D.: SEM.8610011923.aa07356 Posted: Wed Oct 1 19:23:49 1986 Date-Received: Fri, 3-Oct-86 08:08:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Many sites with really large sets of LANS (including MIT and BRL) run dedicated IP gateways as their attachment to the IMPs. In these cases, all traffic on those IMP ports is either user traffic or EGP. BRL-GATEWAY and BRL-GATEWAY2 are pretty high up as the largest source of packets on the MILNET, today. When our Cray-XMP48 comes online on 2-November, I expect our MILNET trunks to melt. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12243434761.41.GROSSMAN%40Sierra.Stanford.EDU] <1986100115555000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: GROSSMAN@SIERRA.STANFORD.EDU (Stu Grossman) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <12243434761.41.GROSSMAN@Sierra.Stanford.EDU> Date: Wed, 1-Oct-86 19:55:50 EDT Article-I.D.: Sierra.12243434761.41.GROSSMAN Posted: Wed Oct 1 19:55:50 1986 Date-Received: Fri, 3-Oct-86 08:10:17 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa > You could (marginally) ... That's why I said "marginally". Yes, LPD has this problem, but it's not so simple. LPD can be told to accept print requests only from certain hosts. So now you have to: 1) successfully imitate another host, and 2) declare yourself as the appropriate port type So that you can send bogus print requests to an lpd. Yes, the 'privileged' port number stuff in LPD is quite naive. However, as long as point 1 (above) is quite difficult to do, LPD can be pretty safe from bogus print requests. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610030926.AA16902%40ucbvax.Berkeley.EDU] <1986100117400000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CSDCTGB@UCLA-CCN.ARPA (Todd Booth 213-825-1933) Newsgroups: mod.protocols.tcp-ip Subject: Re: Implementation list Message-ID: <8610030926.AA16902@ucbvax.Berkeley.EDU> Date: Wed, 1-Oct-86 21:40:00 EDT Article-I.D.: ucbvax.8610030926.AA16902 Posted: Wed Oct 1 21:40:00 1986 Date-Received: Fri, 3-Oct-86 09:18:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa > Shouldn't this (in theory) be part of the NIC's > tcpip-implementations.txt, John Romkey > file? The file has been renamed Netinfo:vendors-guide.doc -todd ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100203470000> Received: from safe.stanford.edu by SRI-NIC.ARPA with TCP; Thu 2 Oct 86 11:00:02-PDT Received: by safe.stanford.edu with Sendmail; Thu, 2 Oct 86 10:47:51 pdt Date: 2 Oct 1986 1047-PDT (Thursday) From: Bill Croft To: ehrlich%psuvax1.bitnet@WISCVM.WISC.EDU Cc: tcp-ip@sri-nic.ARPA, info-vax@brl.ARPA, croft@safe.stanford.edu Subject: Re: BOOTP daemon for BSD 4.x In-Reply-To: ehrlich%psuvax1.bitnet@WISCVM.WISC.EDU / Tue, 30 Sep 86 17:56:15 edt. Client and server implementations of BOOTP (Bootstrap Protocol, RFC 951) are available via anonymous ftp from host safe.stanford.edu, in the files: pub/bootp.client.shar pub/bootp.server.shar Both implementations are in C, the server code for 4.2 BSD, the client code resides in PROM in our campus gateways/tips (multibus 68000 systems). The client autoconfigures for a number of different ethernet board manufacturers (3COM, Interlan, Xerox). The BOOTP protocol is defined such that clients can boot themselves even when: (1) the client is on an ether segment without a boot server host. (2) the client doesnt yet know its own IP address. --Bill Croft, Stanford Univ., CSLI ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100205355400> Received: from gwen.cs.purdue.edu by SRI-NIC.ARPA with TCP; Thu 2 Oct 86 08:36:30-PDT From: "Thomas Narten" Message-Id: <8610021536.AA02407@gwen.cs.purdue.edu> Received: by gwen.cs.purdue.edu; Thu, 2 Oct 86 10:36:00 EST To: amdcad!phil@decwrl.DEC.COM (Phil Ngai) Cc: tcp-ip@sri-nic.ARPA Subject: Re: MIT pcip and 3com board In-Reply-To: Your message of Tue, 30 Sep 86 10:13:20 PDT. <8609301713.AA15763@amdcad.UUCP> Date: Thu, 02 Oct 86 10:35:54 EST This is probably not the problem, but.... We recently discovered that the implementation of ARP under pcip is not quite the same as that on other machines, such as 4.2/4.3 Unix. The ARP we were running under 4.2 on our VAXes came from Sun; we were not running the vanilla 4.2, so I can't say what 4.2 ARP does. When pcip recieves an ARP packet, the first thing it does is check the target protocol address against its own. If they do not match, the packet is tossed without further processing. 4.3 Unix on the other hand, checks first to see if the sender protocol address in the reply packet matches an entry in its ARP cache. If it does, it updates the entry. In our case, we had a machine that sent ARP replies, using the same addresses in the sender and target fields. On Unix machines, this worked. Unix would add an entry (marked incomplete) for the Internet address it wanted, send out an ARP request, and the machine would answer. Even though the ARP reply that was received did not have the requesting machines address in the target fields, the entry was correctly installed. The pcip machine in the other hand would toss the reply, thinking it was not the reply is was looking for. Thomas ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610031636.AA00904%40ucbvax] <1986100207334400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: GOWER@D.ISI.EDU (Neil E. Gower) Newsgroups: mod.protocols.tcp-ip Subject: Re: Congestion in the Arpanet Message-ID: <8610031636.AA00904@ucbvax> Date: Thu, 2-Oct-86 11:33:44 EDT Article-I.D.: ucbvax.8610031636.AA00904 Posted: Thu Oct 2 11:33:44 1986 Date-Received: Sat, 4-Oct-86 07:06:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Dennis, thanks for the copy of BBNs progress and plan of attack. We are having trouble understanding why the busiest nodes are not in the middle of the cross-country paths (SAC, TEXAS and COLLINS (ours)). Or at the entrances to those paths. The only one of the four mentioned by BBN, which seems to fit the "cross-country bottleneck" is UWISC. There also seems to be no explanation why a PSN cannot give reasonable response between two of its own nodes. We see just as poor (or worse) service between equipment in the same room here as we do between here and D.ISI.EDU (ISI27). Maybe its because our packets are going to ISI27 or somewhere else first. It does seem that all four of the PSNs mentioned are in areas where heavy (not necessarily cross-country) traffic would occur. This would indicate problems in the areas of shortages of packet buffers and/or virtual circuits and/or slowness in setting up virtual circuits. I agree that we have an ONION of problems, but wouldn't it make sense to resolve the ones that are "localized" to one PSN first? Regards, Neil Gower ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100207334401> Received: from D.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 2 Oct 86 08:35:56-PDT Date: 2 Oct 1986 11:33:44 EDT Subject: Re: Congestion in the Arpanet From: Neil E. Gower To: Dennis G. Perry cc: tcp-ip@SRI-NIC.ARPA, GOWER@D.ISI.EDU In-Reply-To: Dennis, thanks for the copy of BBNs progress and plan of attack. We are having trouble understanding why the busiest nodes are not in the middle of the cross-country paths (SAC, TEXAS and COLLINS (ours)). Or at the entrances to those paths. The only one of the four mentioned by BBN, which seems to fit the "cross-country bottleneck" is UWISC. There also seems to be no explanation why a PSN cannot give reasonable response between two of its own nodes. We see just as poor (or worse) service between equipment in the same room here as we do between here and D.ISI.EDU (ISI27). Maybe its because our packets are going to ISI27 or somewhere else first. It does seem that all four of the PSNs mentioned are in areas where heavy (not necessarily cross-country) traffic would occur. This would indicate problems in the areas of shortages of packet buffers and/or virtual circuits and/or slowness in setting up virtual circuits. I agree that we have an ONION of problems, but wouldn't it make sense to resolve the ones that are "localized" to one PSN first? Regards, Neil Gower ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100208383500> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Thu 2 Oct 86 09:41:59-PDT Received: by vax.darpa.mil (4.12/4.7) id AA06120; Thu, 2 Oct 86 12:38:42 edt Date: Thu 2 Oct 86 12:38:35-EDT From: Dennis G. Perry Subject: Re: Congestion in the Arpanet To: GOWER@D.ISI.EDU Cc: PERRY@VAX.DARPA.MIL, tcp-ip@SRI-NIC.ARPA, perry@VAX.DARPA.MIL Message-Id: In-Reply-To: Message from "Neil E. Gower " of 2 Oct 1986 11:33:44 EDT Niel, one reason collins may not be as saturated is that you seem to be more isolated and in a multihop link across the country. The only direct E-W link is USC-DARPA. The E-W link involving Collins starts at SRI2-Collins-Texas-Bragg-Dcec20. The other E-W link is UCLA-Texas-Bragg-DCEC20. The third E-W link is LBL-Utah-SAC-Uwisc- Uroch-RCC5. So I would assume the NE bound traffic would prefer the Norther route, and Mid-Atlantic bound traffice would prefer the direct route. As to why PSNs have problems between two of its own hosts, I have no idea, but have asked the question. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.V3.10.leong.0.leong.157.0%40andrew.cmu.edu] <1986100213594400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: MIT pcip and 3com board Message-ID: Date: Thu, 2-Oct-86 17:59:44 EDT Article-I.D.: andrew.MS.V3.10.leong.0.leong.157.0 Posted: Thu Oct 2 17:59:44 1986 Date-Received: Tue, 7-Oct-86 07:59:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa I have no experience with the newer 3COM short dumb card. However, with the full length card, we have experience similar odd and flaky behaviour quite a while back (It work with some machine but not others). The problem turns out to be incompactibility between our transciever and the card. Most of our transciver are the Ethernet Rev 1 varitey. The 3COM card uses the SEEQ DQ8023 transceiver chip and is, by default, 802.3 variety. According to the SEEQ engineering sheet, one can select the SEEQ chip to work as Rev 1 mode by grounding PIN 10 (notch to your left : bottom set of pins : wire the first and last pins togther). We did that to all our 3COM board and the problem went away. We suggested to 3COM that they should provide a jumper but I don't think they have done anything. But, there again, that may not be your problem ..... John Leong leong@andrew.cmu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.V3.10.leong.0.leong.157.1%40andrew.cmu.edu] <1986100214025900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: more .. Re: MIT pcip and 3com board Message-ID: Date: Thu, 2-Oct-86 18:02:59 EDT Article-I.D.: andrew.MS.V3.10.leong.0.leong.157.1 Posted: Thu Oct 2 18:02:59 1986 Date-Received: Wed, 8-Oct-86 03:40:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa More .... By the way, we have the same problem with the NI1010A. Again, you have to set the transciever chip on that board to match the Ethernet Rev of your actual transceiver. Otherwise, you can get flaky behaviour. John Leong leong@andrew.cmu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.V3.10.leong.0.leong.168.0%40andrew.cmu.edu] <1986100214304900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong@andrew.cmu.edu (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: Ethernet carrier sense during transmit Message-ID: Date: Thu, 2-Oct-86 18:30:49 EDT Article-I.D.: andrew.MS.V3.10.leong.0.leong.168.0 Posted: Thu Oct 2 18:30:49 1986 Date-Received: Wed, 8-Oct-86 03:42:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Re : "..... Ethernet assumes a certain maximum transceiver cable length and a certain minimum signal propagation velocity .... The Codenoll system alters the parameters which permit the monitoring of carrier. As such, calling it "Ethernet" or "Ethernet compatible" could be misleading and could cause network failures which are hard to diagnose such as your case. ...... " I am curious as to how the Remote LANBridge function in conjunction with the DEC remote repeater. Does the AMD chip inside the LANbridge, pointing to the direction of the long fibre link, programmed to carry out the CarrierSenseTest ? Furthermore, it is my contention that doing a CarrierSenseTest is probably a good thing but the timing is questionable bearing in mind that the 50 meter transciever cable distance is really a function of DC power attenuation between the controller an the transceiver. If the tranceiver is locally powered, that distance limitation would not have applied. The only relevant number will then be the 51.2 microseconds (512 bits) slot time. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100215383700> Received: from EDDIE (MIT-EDDIE.ARPA) by SRI-NIC.ARPA with TCP; Fri 3 Oct 86 09:20:16-PDT Received: by EDDIE (5.31/4.7) id AA05684; Fri, 3 Oct 86 12:19:30 EDT Message-Id: <8610031619.AA05684@EDDIE> Received: by apollo.uucp; Thu, 2 Oct 86 19:30:23 edt From: Jim Rees Date: Thu, 2 Oct 86 19:38:37 EDT Subject: Re: SMTP, 2600, and the security of mail To: tcp-ip@sri-nic.arpa You could (marginally) increase the security of SMTP traffic by having SMTP servers only accept connections from a 'privileged' remote socket. This doesn't increase security, it decreases it. It fools the system administrator into thinking that there is such a thing as a "privileged remote socket", when in fact there isn't, and it makes it necessary for the guy who is writing and debugging an smtp client to get superuser privileges on those machines that do implement 'privileged' local ports. Like the "communications privacy act", "privileged ports" are a sham that just fool people into thinking things are secure when they aren't. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100216150000> Received: from pescadero.stanford.edu by SRI-NIC.ARPA with TCP; Thu 2 Oct 86 23:31:29-PDT Received: by pescadero.stanford.edu with Sendmail; Thu, 2 Oct 86 23:31:33 pdt Date: 2 Oct 1986 23:15-PDT From: Steve Deering Subject: IP source routing questions To: tcp-ip@sri-nic.ARPA Message-Id: <86/10/02 2315.440@pescadero.stanford.edu> After looking through a couple of IP specs and a couple of IP implementations, I still have a shaky understanding of how source routing works. Assuming host A wants to send a datagram to host D, source-routed through gateways B and C, host A gate B gate C host D +------+ +------+ +------+ +------+ | | | | | | | | | A1|-------->|B1 B2|-------->|C2 C3|-------->|D3 | | | net 1 | | net 2 | | net 3 | | +------+ +------+ +------+ +------+ where A1, B1, B2, etc. are IP addresses. I think that the upper layer protocol in host A should pass the following IP header values to the IP layer: source:A1 destination:B1 route:B1,C2,D3 offset:4 where offset is the value of the third byte of the source route option. Then I expect the datagram to contain the following values when it is transmitted: on net 1: source:A1 destination:B1 route:A1,C2,D3 offset:8 on net 2: source:A1 destination:C2 route:A1,B2,D3 offset:12 on net 3: source:A1 destination:D3 route:A1,B2,C3 offset:16 Is this right? Perhaps the source address changes at each hop? Or the destination address remains constant? Or there should only be two addresses in the route option? Or the offset values should be 4 less? Methinks the specs could be clearer on this. Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610030050.AA07816%40ucbvax.Berkeley.EDU] <1986100220022000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: GLM@IPGUNIV.BITNET Newsgroups: mod.protocols.tcp-ip Subject: booking TCP-IP mailing list Message-ID: <8610030050.AA07816@ucbvax.Berkeley.EDU> Date: Fri, 3-Oct-86 00:02:20 EDT Article-I.D.: ucbvax.8610030050.AA07816 Posted: Fri Oct 3 00:02:20 1986 Date-Received: Fri, 3-Oct-86 07:48:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa I wuould like to be registered in the TCP-IP mailing list. Sincerely Gianfranco Galmacci ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100220140600> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 2 Oct 86 21:12:13-PDT Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Fri, 3 Oct 86 00:14:06 edt Date: Fri, 3 Oct 86 00:14:06 edt From: jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen) Message-Id: <8610030414.AA11940@BORAX.LCS.MIT.EDU> To: tcp-ip@sri-nic.arpa Subject: TCP/IP for HP-UX on HP9000s I have heard of this, but one of my contacts says that her HP salesman can only offer her a networking package running on Ethernet which isn't TCP/IP now, but will become TCP/IP later. My own initial attempts to find out via HP salespeople haven't produced anything yet. I am interested in 1) Part numbers and descriptions of HP networking offerings for the 9000 under HP-UX and otherwise, and 2) discussion of how the offerings are/aren't TCP/IP. Replies to the address below, and I will summarize to the list if requested. jbvb@ai.ai.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100221482800> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 2 Oct 86 22:47:59-PDT Date: Fri 3 Oct 86 01:48:28-EDT From: "J. Noel Chiappa" Subject: Re: odd routings To: hedrick@TOPAZ.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <8609280848.AA26039@topaz.rutgers.edu> Message-ID: <12243761101.35.JNC@XX.LCS.MIT.EDU> I have a few quick comments on some recent messages; I'm going to be a good citizen and package them togther in one reply! 1) The extra hop problem in EGP. (Enter broken record mode.) I've explained this several times, but let me try again quickly. This is a problem with *GGP* (NOT EGP), the routing protocol run between the core gateways. It was designed before EGP, and thus does not interoperate correctly with it. If MIT has core gateway A as an EGP peer, and Rutgers has a peer core gateway B, then there is no way (using GGP) for A to inform B that to get to MIT it can go direct; both B and all its clients (e.g. Rutgers) think they have to go through A. This is the cause of the funny routes with routes to CMU, MIT, etc. Your gateway is just fine, and it's not EGP's fault either. (Leave broken record mode.) The extra hop problem will only be solved when GGP is retired; i.e. when the PDP11 core gateways are replaced by Butterflys, probably. The extra hops probably are a significant gratuitous strain on the system. B) Ping wars between gateways might be causing problems if BBN never installed the patch to add more connection blocks (don't worry if you know what this is), but if that patch is in it shouldn't be a problem. Can anyone from BBN clue us in? I saw a note in a recent message from BBN which talked about installing a 'performance improvement' patch to help with the recent problems; are they referring to the increased number of connections blocks? If not, what? C) "Mail's the culprit." One thought at MIT was that mail was responsible for the bulk of our outgoing traffic. Measurements of a day's traffic indicated that SMTP accounted for 35% of the packets and only 27% of the data through the gateway. (These numbers do not count all traffic from the MIT complex, since some of our biggest timesharing machines are on the ARPANet directly, and these figures count only traffic from the MIT net. The traffic mix on the timesharing hosts might include more mail, which would bias the whole figure.) Still, these numbers are a long way from indicting Mail as the culprit in the congestion. Does anyone else have any numbers on traffic breakdown by types? Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100221585900> Received: from NRTC-GREMLIN.NORTHROP.COM by SRI-NIC.ARPA with TCP; Fri 3 Oct 86 09:40:45-PDT Received: from nrtc-gremlin by NRTC-GREMLIN.NORTHROP.COM id a004412; 3 Oct 86 9:39 PDT To: Barry Shein cc: WANCHO@simtel20.ARPA, TCP-IP@sri-nic.ARPA reply-to: tcp-ip@sri-nic.ARPA Subject: Re: Do we need another protocol? In-reply-to: Your message of Wed, 01 Oct 86 13:40:45 -0400. <8610011740.AA28707@bu-cs.bu.edu> Date: Fri, 03 Oct 86 09:38:59 -0700 Message-ID: <4408.528741539@nrtc-gremlin.northrop.com> From: Marshall Rose Well, the XDR/RPC isn't the only public-domain one around. The ISO/CCITT people have ASN.1 (similar to XDR) and ROS (simlar to RPC) which do roughly the same thing (but differently of course). ASN.1 stands for abstract syntax notation, and ROS stands for remote operations. My (limited) understanding of XDR/RPC indicates that ASN.1 and ROS are somewhat more general, though both get the same thing done. As you'd expect, since I give away ISODE (an ISO development environment for TCP) for free, I'm biased towards the ISO approach. The big win, regardless of the brand of universal-data-exchange-format you use is that we can finally get away from the $1.10 netascii approach for client-server interactions that we've seen for the last 10 years. The second big win, which is only now getting attention is that we are now a step closer generate program fragments from the data representation specifications. I know that in the current/next release of NFS, this capability exists. In ISODE, there's a yacc spin-off called pepy, which reads your instrumented formal spec and writes a code fragment that parses the ASN.1 structures into your own internal-form. I've used pepy on four projects now, and each time it was a major, major win. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100301192900> Received: from B.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 3 Oct 86 08:19:43-PDT Date: 3 Oct 1986 08:19:29 PDT Subject: Re: TCP/IP for Burroughs From: Dan Lynch To: munnari!moncskermit.oz!john@SEISMO.CSS.GOV (John Carey) cc: tcp-ip@SRI-NIC.ARPA, LYNCH@B.ISI.EDU In-Reply-To: <8610010647.AA04073@seismo.CSS.GOV> John, You should contact Joe Gibson at 703-847-2305 for info on Burroughs TCP/IP. He is the program manager for them (SDC) on this. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610031432.AA10781%40vax.darpa.mil] <1986100306051900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tmallory@ccv.bbn.com Newsgroups: mod.protocols.tcp-ip Subject: New gateway software installed Message-ID: <8610031432.AA10781@vax.darpa.mil> Date: Fri, 3-Oct-86 10:05:19 EDT Article-I.D.: vax.8610031432.AA10781 Posted: Fri Oct 3 10:05:19 1986 Date-Received: Wed, 8-Oct-86 04:11:20 EDT Sender: wolfe@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa The seven gateways between the Arpanet and the Milnet were loaded with version 1008.1 software yesterday afternoon(10/2). The most important change is the increase from 150 to 300 in the number of networks handled by the routing module. Several other changes were made to improve the behavior of the gateways in the face of severe network congestion. The 300-network software is (has been) running in all of the EGP servers. Tracy Mallory BBNCC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610071051.AA01700%40ucbvax.Berkeley.EDU] <1986100307192900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: LYNCH@B.ISI.EDU (Dan Lynch) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP for Burroughs Message-ID: <8610071051.AA01700@ucbvax.Berkeley.EDU> Date: Fri, 3-Oct-86 11:19:29 EDT Article-I.D.: ucbvax.8610071051.AA01700 Posted: Fri Oct 3 11:19:29 1986 Date-Received: Wed, 8-Oct-86 03:40:58 EDT References: <8610010647.AA04073@seismo.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa John, You should contact Joe Gibson at 703-847-2305 for info on Burroughs TCP/IP. He is the program manager for them (SDC) on this. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100307300000> Received: from mitre-bedford.ARPA by SRI-NIC.ARPA with TCP; Fri 3 Oct 86 11:31:11-PDT Organization: The MITRE Corp., Bedford, MA Received: by ulana.MENET (4.12/4.7) id AA09821; Fri, 3 Oct 86 14:30:29 pdt From: Barbara J. Pease Posted-Date: 3 Oct 1986 1430-PDT (Friday) Message-Id: <8610032130.AA09821@ulana.MENET> Date: 3 Oct 1986 1430-PDT (Friday) To: tcp-ip@sri-nic.ARPA Cc: bjp@mitre-bedford.ARPA Subject: New version of the ULANA Specifications This noice is to announce that a new version of the ULANA Specifications has been released and now is available at the ulana ftp site. address: mitre-b-ulana.arpa user: guest password: anonymous pathname: /usr/mitre/guest/ulana.specs Any comments about the specifications should be mailed to: ulana@mitre-bedford.arpa General correspondence should be mailed to: bjp@mitre-bedford.arpa bj Pease ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100308480000> Received: from UCLA-CCN.ARPA by SRI-NIC.ARPA with TCP; Fri 3 Oct 86 16:07:42-PDT Date: Fri, 03 Oct 86 15:48 PDT To: Submit to TCP/IP From: Todd Booth 213-825-1933 Subject: RE: TCP/IP for Burroughs cc: munnari!moncskermit.oz!john@seismo.CSS.GOV(John Carey) > Does anyone know of a TCP/IP implementation for the B7800? I don't think so. At least I didn't find it in the dataset, sri-nic netinfo:vendors-guide.doc For anyone who would like to know what other files are available (and has FTP) the index is kept as netinfo:00netinfo-index.txt -todd ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100313144300> Received: from BNL.ARPA by SRI-NIC.ARPA with TCP; Fri 3 Oct 86 14:12:04-PDT Received: by BNL.ARPA; Fri, 3 Oct 86 17:14:43 edt Date: Fri, 3 Oct 86 17:14:43 edt From: gr@bnl.ARPA (George Rabinowitz) Message-Id: <8610032114.AA03981@BNL.ARPA> To: tcp-ip@sri-nic.ARPA Subject: TCP-IP mailing list I would like to be registered in the TCP-IP mailing list. Sincerely George Rabinowitz ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100313203700> Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Fri 3 Oct 86 22:46:29-PDT Received: by decwrl.dec.com (5.54.2/4.7.34) id AA02955; Fri, 3 Oct 86 22:48:36 PDT Received: by amdcad.UUCP (4.12/4.7) id AA15078; Fri, 3 Oct 86 20:20:37 pdt Date: Fri, 3 Oct 86 20:20:37 pdt From: amdcad!phil@decwrl.DEC.COM (Phil Ngai) Message-Id: <8610040320.AA15078@amdcad.UUCP> To: @po3.andrew.cmu.edu:leong@andrew.cmu.edu Subject: Re: Ethernet carrier sense during transmit Cc: charlie@decwrl.DEC.COM, rpw3@decwrl.DEC.COM, tcp-ip@sri-nic.ARPA > "..... Ethernet assumes a certain maximum transceiver cable length and a > certain minimum signal propagation velocity .... The Codenoll system alters > the parameters which permit the monitoring of carrier. As such, calling it > "Ethernet" or "Ethernet compatible" could be misleading and could cause > network failures which are hard to diagnose such as your case. ...... " > > I am curious as to how the Remote LANBridge function in conjunction with the > DEC remote repeater. Does the AMD chip inside the LANbridge, pointing to the > direction of the long fibre link, programmed to carry out the > CarrierSenseTest ? First a disclaimer. I do not represent the company in this forum. I am only stating an opinion based on my understanding of networks. Further more, I do not know how the DEC LAN Bridge 100 operates. The LANCE data sheet says it wants to see carrier during a transmission. If it ever sees a loss of carrier, it will set a status bit, bit 11 (LCAR) in Transmit Message Descriptor 3 (TMD3). It will continue to transmit the whole packet until done. This seems similar to its handling of SQE. (lack of SQE sets a bit in a register but does nothing else.) Conditions are detected and available for interrogation by software but as little of the protocol is enforced by hardware as possible, where this does not put an undue burden on software. DEC probably just ignores LCAR on the LANCE which drives the fiber interface. By the way, I heard a very clever use of the LANCE. In a bridge, it would be fair to get more of the bandwidth than a normal station gets. You can disable the retry on a LANCE and implement your own truncated binary backoff with shorter time constants in software. > Furthermore, it is my contention that doing a CarrierSenseTest is probably a > good thing but the timing is questionable bearing in mind that the 50 meter > transciever cable distance is really a function of DC power attenuation > between the controller an the transceiver. If the tranceiver is locally > powered, that distance limitation would not have applied. The only relevant > number will then be the 51.2 microseconds (512 bits) slot time. Yes, there are many ways to break the Ethernet configuration rules and (temporarily) get away with it. Actually, the 50 meter transceiver cable distance is due to both DC and AC signal attenuation. The AC signal attenuation is, in fact, a more severe requirement. Belden 9891: DC resistance 10 MHz attenuation 9.3 ohm/1000feet 2.1 dB/100 feet Ethernet spec: 4 ohms max 3 dB max Allowed length: 4000/9.3 = 3/2.1 = 430 feet roundtrip = 143 feet 215 feet (ignoring connector resistance) 50 meters is 164 feet. But I digress. The point is, given two incompatible implementations, I would side with the one that didn't break any rules, at least with regard to whether it should be called Ethernet or 802.3. I am also against the philosophy of "as long as it's less than a slot time you can do anything you feel like". In a large network where personnel come and go, it is very likely that a shortcut taken in one area will be forgotten and badly burn someone (many people?) somewhere down the line. It's all very nice to document what you did but I think there was a reason DIX came up with the configuration rules in the first place. Otherwise, they could just have said "here, don't violate the slot time and have fun". But they knew it would be much less error prone to establish some simple, conservative configuration rules. It's very easy to poke holes in them. They were designed to be conservative. And I think in a network where downtime affects the entire computing community, erring on the side of too much safety margin is worth it. It's true that standards retard the advancement of the state of the art. As a system engineer, I am more concerned with connectivity than an occasional local optimization, particularly if it means the whole network is affected or threatened. This is even more true with the advent of devices like the LAN Bridge 100 which allow full Ethernet speed over extended geographic distances. There's no longer any excuse to cheat the specs to get an extra 500 meters or whatever. Phil Ngai ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100406142100> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Sat 4 Oct 86 07:12:26-PDT Received: by cu-arpa.cs.cornell.edu (5.45/4.30) id AA00217; Sat, 4 Oct 86 10:14:21 EDT Date: Sat, 4 Oct 86 10:14:21 EDT From: jqj@gvax.cs.cornell.edu (J Q Johnson) Message-Id: <8610041414.AA25034@gvax.cs.cornell.edu> Received: by gvax.cs.cornell.edu (5.45/4.30) id AA25034; Sat, 4 Oct 86 10:14:21 EDT Newsgroups: arpa.tcp-ip Subject: Re: Congestion in the Arpanet Summary: Expires: References: <3878@cornell.UUCP> Sender: Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson) Followup-To: Distribution: Organization: Cornell Univ. CS Dept. Ithaca NY Keywords: Apparently-To: tcp-ip@sri-nic.arpa Has anyone done any modelling of the likely effect of the new NSF sites and of NSFnet on ARPAnet traffic/performance? Offhand, I would expect that the changes (supercomputers with scientists all over the country using telnet or tn3270 to get to them by ARPAnet, many more NSF-supported hosts, and a new alternative backbone) are likely to have massive effects on ARPAnet traffic patterns. It would be nice to know that someone had given some thought before the fact to the potential effects! Similarly, has anyone modelled the effect of widearea and wideband regional nets such as the planned NY-wide 1Mbit network (NYSERNET)? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610051513.AA02710%40tcgould.tn.cornell.edu] <1986100507134200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: olson@TCGOULD.TN.CORNELL.EDU (olson) Newsgroups: mod.protocols.tcp-ip Subject: Re: Peace fullness. Message-ID: <8610051513.AA02710@tcgould.tn.cornell.edu> Date: Sun, 5-Oct-86 11:13:42 EDT Article-I.D.: tcgould.8610051513.AA02710 Posted: Sun Oct 5 11:13:42 1986 Date-Received: Wed, 8-Oct-86 03:43:16 EDT References: <8609280050.AA11782@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: batcomputer!olson@cu-arpa.cs.cornell.edu (olson) Organization: Theory Center, Cornell University, Ithaca NY Lines: 54 Approved: tcp-ip@sri-nic.arpa In article <8609280050.AA11782@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes: > > > Speeking as the president of one of those companies out there trying >to make a living by selling TCP/IP code for PC's ... > > I ask you, what would you do if you wanted to sell such a product. >(Remember were a very small company) > > - Carl Beame, > President > Beame & Whiteside Software Ltd. > 259 Fiddler's Green Rd. > Ancaster, Ontario, Canada. I'd sell it for a LOW price if at all possible. You see i'm not going to get tcp/ip for the pc's around my department at $1000 a shot or even $500 hundred a shot. I'd rather go to the campus computing people and ask them to do the campus a favor and write something. At ~ $100 I might consider a commercial product. But (I hear you say) I might as well give it away. Well, If it is good you will probably sell a lot of them at the lower price. Also you can make money off of service. (not fixing broken software) Things like helping a group figure out what they need, hardware and software. That is a service you can charge for. But (I hear you say) We are small, we can't serve all our customers that way. Don't try. Let other service groups grow up to help people network (hopefully your software will be good enough for them to recomend) You can probably make a living off the people in your area by this sort of service as well as get ideas for new products from the problems you solve for them. If you write up very good documents on how to deal with these problems you could sell them (text book level pricing) and if you really have it together and can make your ideas clear and correct you can set up a service franchise. (Hello, you have our software, you are in L.A. what part? Okay, lets see, we have a service franchise at ... Why don't talk to them first as they will be able to devote more time to your problem. If you have trouble with them please call back.) The franchizee will report to you all problems they encounter with your software, and you will support them with solutions. You set standard for the franchice and in return for being certified they pay you money. This way you get all the feed back you would if all your customers called you directly without the problems of providing support once the problem has been solved. (Damn, there I go again, giving away my best ideas. But can you see it "Hey Ma, Dad, I need a job should I try for a fast food joint or a fast code joint." (so give me credit for the idea)) This way you can make a living with out having to become a corporate monster. Todd Olson ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610060622.AA08503%40topaz.rutgers.edu] <1986100522221700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: telnet synch Message-ID: <8610060622.AA08503@topaz.rutgers.edu> Date: Mon, 6-Oct-86 02:22:17 EDT Article-I.D.: topaz.8610060622.AA08503 Posted: Mon Oct 6 02:22:17 1986 Date-Received: Wed, 8-Oct-86 03:54:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 57 Approved: tcp-ip@sri-nic.arpa Almost all of our terminals are now connected to terminal servers running telnet, instead of directly to computers. I am getting tired of typing ^O or ^C and having many screens full of data come out. The obvious fix is to implement the Telnet synch option. I have done so, more or less, and the improvement is quite welcome. However the description in RFC 854 leaves me feeling unsure of whether I have done things right. My interpretation of the spec is that when the host machine wants to clear its output buffer, it should send IAC DM, with the urgent pointer set to point to the DM. 1) Am I correct that the only thing to be sent is IAC, DM? The description of synch makes it sound like two separate things are sent: one out of band and the other in the normal data stream. After reading the description of urgent data about 5 times, I have finally concluded that this the wrong conception of how urgent data works, and that in fact only the IAC, DM is sent. 2) I find the whole concept of urgent data slightly odd. Both the telnet spec and the Unix implementation imply that urgent is some sort of out of band data, that manages to arrive out of order, going ahead of any normal data. It looks to me like this isn't quite the case. Rather there is a bit that says, "go into urgent mode". It seems like nobody really cares exactly when (i.e. at which byte) you go into urgent mode. Then there is a pointer that tells you the end of the urgent data, at which point you go out of urgent mode. 4.2 seems to have a different view of the world. They pull the last byte of urgent data out of the normal byte stream and call it out of band data. It's not clear whether this is quite what TCP had in mind. 3) The telnet spec further confuses things by saying that DM should be transmitted as the only octet in an urgent message. The problem is that this seems to ignore the necessity for an IAC. Anyway, from all of this, I conclude that synch should be implemented as follows: When I type a ^O, put out an IAC, DM, and set the urgent pointer so that the DM is the last byte of urgent data (the only byte as far as Unix is concerned). The way 4.2 works (at least on the Pyramid), the moment I set the urgent pointer, all packets get the urgent flag set until the point where the DM has been sent. This seems to be right. What makes me suspicious of this is the 4.2 telnet seems to get confused by it. Telnet doesn't set up for the URGENT signal. So the final urgent byte, the DM, is simply removed from the input stream by the kernel. The result is mildly odd. When I type ^O, the host ends up echoing ^O back at me. So the last few bytes of the data stream are IAC DM ^ O. Since the DM is pulled out by the kernel, Unix sees IAC ^, which is of course a bogus telnet command, and prints only the O. If I understand what is going on properly, what I am sending is right, and it is the combination of 4.2 and 4.2 telnet that is wrong. Has anybody followed me to this point? Do I seem to be making sense? Fortunately, our two kinds of terminal servers (Bridge CS/100's and Cisco ASM's) both seem to do the right thing. It's *so* nice to have ^C and ^O work again. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100605300000> Received: from safe.stanford.edu by SRI-NIC.ARPA with TCP; Mon 6 Oct 86 12:37:55-PDT Received: by safe.stanford.edu with Sendmail; Mon, 6 Oct 86 12:30:07 pdt Date: 6 Oct 1986 1230-PDT (Monday) From: Bill Croft To: tcp-ip@sri-nic.ARPA Cc: ehrlich%psuvax1.bitnet@WISCVM.WISC.EDU Reply-To: croft@sumex-aim.arpa Subject: re: BOOTP daemon for BSD 4.x In-Reply-To: ehrlich%psuvax1.bitnet@WISCVM.WISC.EDU / Tue, 30 Sep 86 17:56:15 edt. Client and server implementations of BOOTP (Bootstrap Protocol, RFC 951) are available via anonymous ftp from host safe.stanford.edu, in the files: pub/bootp.client.shar pub/bootp.server.shar Both implementations are in C, the server code for 4.2 BSD, the client code resides in PROM in our campus gateways/tips (multibus 68000 systems). The client autoconfigures for a number of different ethernet board manufacturers (3COM, Interlan, ...). The BOOTP protocol is defined such that clients can boot themselves even when: (1) the client is on an ether segment without a boot server host. (2) the client doesnt yet know its own IP address. --Bill Croft, Stanford Univ. ------- End of Forwarded Message ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610072320.AA11039%40ucbvax.Berkeley.EDU] <1986100611300000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: croft@safe.stanford.edu (Bill Croft) Newsgroups: mod.protocols.tcp-ip Subject: re: BOOTP daemon for BSD 4.x Message-ID: <8610072320.AA11039@ucbvax.Berkeley.EDU> Date: Mon, 6-Oct-86 15:30:00 EDT Article-I.D.: ucbvax.8610072320.AA11039 Posted: Mon Oct 6 15:30:00 1986 Date-Received: Wed, 8-Oct-86 04:23:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: croft@sumex-aim.arpa Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Client and server implementations of BOOTP (Bootstrap Protocol, RFC 951) are available via anonymous ftp from host safe.stanford.edu, in the files: pub/bootp.client.shar pub/bootp.server.shar Both implementations are in C, the server code for 4.2 BSD, the client code resides in PROM in our campus gateways/tips (multibus 68000 systems). The client autoconfigures for a number of different ethernet board manufacturers (3COM, Interlan, ...). The BOOTP protocol is defined such that clients can boot themselves even when: (1) the client is on an ether segment without a boot server host. (2) the client doesnt yet know its own IP address. --Bill Croft, Stanford Univ. ------- End of Forwarded Message ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100701400000> Received: from UCLA-CCN.ARPA by SRI-NIC.ARPA with TCP; Tue 7 Oct 86 08:39:13-PDT Date: Tue, 07 Oct 86 08:40 PDT To: Submit to TCP/IP From: Todd Booth 213-825-1933 Subject: Protocol of Submissions Cc: Vivian Neou - Coordinator of TCP-IP It's time to settle this "commercial vs university" issue. > From: mckee@mitre.ARPA > > I object to moving the discussion of commercial vs university > requirements off of tcp-ip. Then you may wish to send a message to the coordinator of the Digest who intended this digest for the following purpose: "To announce new and expanded services in a timely manner.", according to their advertising in SRI-NIC Netinfo:Interest-Groups-2.txt > The tcp-ip community needs to at least understand, and hopefully > accomodate, the contending views of public and private > organizations. You may be right, but if the main-stream of the group doesn't want to hear about, so be it. The digest wasn't intended to act as a big brother. If you are so interested in this topic, you should be *happy* to start your own digest. (I've set up PC-Token-Ring Digest and can give you a hand.) You may get some interest on your topic regarding products other than tcp-ip. > The discussion should continue on tcp-ip. > H. Craig McKee The next message on "commercial vs university" should be from a volunteer to help with the digest. (If anyone really cares so much that they would help.) Of course, the TCP-IP coordinator can overrule me if I have mis- interpreted the protocol discussion. -todd / UCLA Data Comm ps. CASE CLOSED ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610071819.AA07108%40ucbvax.Berkeley.EDU] <1986100704570800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mckenzie@J.BBN.COM (Alex McKenzie) Newsgroups: mod.protocols.tcp-ip Subject: Modelling of NSF sites on ARPANET Message-ID: <8610071819.AA07108@ucbvax.Berkeley.EDU> Date: Tue, 7-Oct-86 08:57:08 EDT Article-I.D.: ucbvax.8610071819.AA07108 Posted: Tue Oct 7 08:57:08 1986 Date-Received: Wed, 8-Oct-86 04:08:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa The DDN Program Management Office (PMO) is responsible for management decisions regarding the ARPANET. It is my understanding that the DDN PMO assigned the task of analyzing the performance of the ARPANET with the addition of NSF sites to the Defense Communications Engineering Center (DCEC). It is my understanding that DCEC uses the same network analysis tools and models which were used to manage the ARPANET configuration at the time of its rapid growth in the early to mid 70s. The statements above are second-hand or farther - I do not have first-hand knowledge, except that I know BBN was not assigned this analysis task. Perhaps someone from the DDN PMO can tell us all more. Alex McKenzie BBN Labs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100704570801> Received: from J.BBN.COM by SRI-NIC.ARPA with TCP; Tue 7 Oct 86 06:05:26-PDT Date: Tue, 7 Oct 86 8:57:08 EDT From: Alex McKenzie To: J Q Johnson cc: tcp-ip@sri-nic.ARPA Subject: Modelling of NSF sites on ARPANET The DDN Program Management Office (PMO) is responsible for management decisions regarding the ARPANET. It is my understanding that the DDN PMO assigned the task of analyzing the performance of the ARPANET with the addition of NSF sites to the Defense Communications Engineering Center (DCEC). It is my understanding that DCEC uses the same network analysis tools and models which were used to manage the ARPANET configuration at the time of its rapid growth in the early to mid 70s. The statements above are second-hand or farther - I do not have first-hand knowledge, except that I know BBN was not assigned this analysis task. Perhaps someone from the DDN PMO can tell us all more. Alex McKenzie BBN Labs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [861007091108.9.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986100705110000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM (Benson I. Margulies) Newsgroups: mod.protocols.tcp-ip Subject: Re: Peace fullness. Message-ID: <861007091108.9.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Tue, 7-Oct-86 09:11:00 EDT Article-I.D.: REDWING.861007091108.9.MARGULIES Posted: Tue Oct 7 09:11:00 1986 Date-Received: Wed, 8-Oct-86 17:54:19 EDT References: <8610051513.AA02710@tcgould.tn.cornell.edu> Sender: broome@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa Date: Sun, 5 Oct 86 11:13:42 EDT From: olson@tcgould.tn.cornell.edu (olson) In article <8609280050.AA11782@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes: > > > Speeking as the president of one of those companies out there trying >to make a living by selling TCP/IP code for PC's ... > > I ask you, what would you do if you wanted to sell such a product. >(Remember were a very small company) > > - Carl Beame, > President > Beame & Whiteside Software Ltd. > 259 Fiddler's Green Rd. > Ancaster, Ontario, Canada. In the same spirit of free-enterprise that drives Mr. Beame, I don't see why we should all be giving him @i(free) advice. Other people have made quite comfortable livings commercializing things that were born in Universities (um, for example, Symbolics), why is he any different? If he is unconvinced of the pofitability of PC IP/TCP, let him go do something else. Someone else will turn up with a different idea. If he's trying to imply that @i(no one) will ever turn out a commercial product as long as university freebies exist, he's just plain wrong. Go ask wollagong. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610071458.AA09007%40JHEREG.LCS.MIT.EDU] <1986100706582300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: markl@jhereg.lcs.mit.edu Newsgroups: mod.protocols.tcp-ip Subject: Re: IP source routing questions Message-ID: <8610071458.AA09007@JHEREG.LCS.MIT.EDU> Date: Tue, 7-Oct-86 10:58:23 EDT Article-I.D.: JHEREG.8610071458.AA09007 Posted: Tue Oct 7 10:58:23 1986 Date-Received: Wed, 8-Oct-86 18:01:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 73 Approved: tcp-ip@sri-nic.arpa > > host A gate B gate C host D > +------+ +------+ +------+ +------+ > | | | | | | | | > | A1|-------->|B1 B2|-------->|C2 C3|-------->|D3 | > | | net 1 | | net 2 | | net 3 | | > +------+ +------+ +------+ +------+ > >where A1, B1, B2, etc. are IP addresses. I think that the upper layer >protocol in host A should pass the following IP header values to the >IP layer: > source:A1 destination:B1 route:B1,C2,D3 offset:4 I know how you feel about the source routing spec [I had to implement it for our NETBLT IP protocol -- a bit of a headache...]. Indeed, the offset at start is 4, however the route is not quite as you specify it. The source host is A1 and the destination host B1; the initial route is C2,D3. on host A: source:A1 destination:B1 route:C2,D3 offset:4 at gate B: source:A1 destination:C2 route:B2,D3 offset:8 at gate C: source:A1 destination:D3 route:B2,C3 offset:12 The source host's IP address never changes; the only addresses that change are the intermediate addresses and the destination address. The idea behind replacing the source route addresses with the recorded route addresses is that the IP packet doesn't change size when it passes through a gateway. It also preovides the destination host with an (albeit reversed) route back to the source host. The offset pointer tells each gateway where to insert its recorded route address. When the packet arrives, the destination host flips the route around, removes the first hop on the route and makes it the destination, and adds the final destination host as the last hop on the route. It also resets the offset value to 4. Host D3 goes through the following machinations before sending a packet back to A1: source route flipped, offset set to 4: source:D3 destination: route:C3,B2 offset:4 first hop removed and made destination: source:D3 destination:C3 route:B2 offset:4 final destination added to route: source:D3 destination:C3 route:B2,A1 offset:4 This is the packet that is sent out. Hope this was of some help (and that I got it right :-) MarkL Internet: markl@jhereg.lcs.mit.edu MIT Laboratory for Computer Science Distributed Systems Group ---------- "...the MGA 1600 Mk-II: Precision sports motoring in the MG racing tradition..." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610061422.AA06081%40mitre.ARPA] <1986100707354700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mckee@MITRE.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Peace fullness. Message-ID: <8610061422.AA06081@mitre.ARPA> Date: Tue, 7-Oct-86 11:35:47 EDT Article-I.D.: mitre.8610061422.AA06081 Posted: Tue Oct 7 11:35:47 1986 Date-Received: Wed, 8-Oct-86 03:57:17 EDT References: <860930145053.3.JAMES@GREEN-GRASS.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 8 Approved: tcp-ip@sri-nic.arpa I object to moving the discussion of commercial vs university requirements off of tcp-ip. The tcp-ip community needs to at least understand, and hopefully accomodate, the contending views of public and private organizations. The discussion should continue on tcp-ip. H. Craig McKee ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610081819.AA00623%40ucbvax.Berkeley.EDU] <1986100707400000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CSDCTGB@UCLA-CCN.ARPA (Todd Booth 213-825-1933) Newsgroups: mod.protocols.tcp-ip Subject: Protocol of Submissions Message-ID: <8610081819.AA00623@ucbvax.Berkeley.EDU> Date: Tue, 7-Oct-86 11:40:00 EDT Article-I.D.: ucbvax.8610081819.AA00623 Posted: Tue Oct 7 11:40:00 1986 Date-Received: Wed, 8-Oct-86 17:58:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa It's time to settle this "commercial vs university" issue. > From: mckee@mitre.ARPA > > I object to moving the discussion of commercial vs university > requirements off of tcp-ip. Then you may wish to send a message to the coordinator of the Digest who intended this digest for the following purpose: "To announce new and expanded services in a timely manner.", according to their advertising in SRI-NIC Netinfo:Interest-Groups-2.txt > The tcp-ip community needs to at least understand, and hopefully > accomodate, the contending views of public and private > organizations. You may be right, but if the main-stream of the group doesn't want to hear about, so be it. The digest wasn't intended to act as a big brother. If you are so interested in this topic, you should be *happy* to start your own digest. (I've set up PC-Token-Ring Digest and can give you a hand.) You may get some interest on your topic regarding products other than tcp-ip. > The discussion should continue on tcp-ip. > H. Craig McKee The next message on "commercial vs university" should be from a volunteer to help with the digest. (If anyone really cares so much that they would help.) Of course, the TCP-IP coordinator can overrule me if I have mis- interpreted the protocol discussion. -todd / UCLA Data Comm ps. CASE CLOSED ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610091126.AA09239%40ucbvax.Berkeley.EDU] <1986100708395500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: brescia@CCV.BBN.COM (Mike Brescia) Newsgroups: mod.protocols.tcp-ip Subject: Re: IP source routing questions Message-ID: <8610091126.AA09239@ucbvax.Berkeley.EDU> Date: Tue, 7-Oct-86 12:39:55 EDT Article-I.D.: ucbvax.8610091126.AA09239 Posted: Tue Oct 7 12:39:55 1986 Date-Received: Thu, 9-Oct-86 20:46:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 47 Approved: tcp-ip@sri-nic.arpa Steve, The following points are important: - the IP source field remains constant, so that the higher level protocol can ignore the recorded route - the IP destination field reflects the current goal, and not the ultimate destination, until the source route has been consumed - the offset includes the first 3 bytes and is zero-based. "... the smallest legal value for the pointer is 4." host A gate B gate C host D +------+ +------+ +------+ +------+ | | | | | | | | | A1|-------->|B1 B2|-------->|C2 C3|-------->|D3 | | | net 1 | | net 2 | | net 3 | | +------+ +------+ +------+ +------+ (..host..) source:A1 destination:B1 route:B1,C2,D3 offset:4 on net 1: source:A1 destination:B1 route:A1,C2,D3 offset:8 on net 2: source:A1 destination:C2 route:A1,B2,D3 offset:12 on net 3: source:A1 destination:D3 route:A1,B2,C3 offset:16 What you show is the way TOPS20 has implemented it, where host A has put a record of its outgoing interface into the packet. The unix implementations do not do this, and the source route option only has 2 hops. Here is an example of unix flavor source routed packet, with an octal dump of the packet on the way out of teh source host, and another on receipt at the destination (the same host in this case). Note also the extra pad (1) option. A1=10.2.0.82 B1=10.2.0.5 B2=128.89.0.5 C2=128.89.0.4 C3=10.3.0.82 D3=10.2.0.82 Outgoing packet: 110 0 0 54 0 0 100 0 31 24 263 53 12 2 0 122 12 2 0 5 1 203 13 4 200 131 0 4 12 2 0 122 1 226 0 0 0 0 0 305 147 244 226 0 Incoming packet: 110 0 0 54 0 0 100 0 27 24 264 324 12 2 0 122 12 2 0 122 1 203 13 14 200 131 0 5 12 3 0 122 1 226 0 0 0 0 0 305 147 244 226 0 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100708395501> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Tue 7 Oct 86 09:40:32-PDT To: Steve Deering cc: tcp-ip@sri-nic.ARPA Subject: Re: IP source routing questions In-reply-to: Your message of 2 Oct 1986 23:15-PDT. <86/10/02 2315.440@pescadero.stanford.edu> Date: 07 Oct 86 12:39:55 EDT (Tue) From: Mike Brescia Steve, The following points are important: - the IP source field remains constant, so that the higher level protocol can ignore the recorded route - the IP destination field reflects the current goal, and not the ultimate destination, until the source route has been consumed - the offset includes the first 3 bytes and is zero-based. "... the smallest legal value for the pointer is 4." host A gate B gate C host D +------+ +------+ +------+ +------+ | | | | | | | | | A1|-------->|B1 B2|-------->|C2 C3|-------->|D3 | | | net 1 | | net 2 | | net 3 | | +------+ +------+ +------+ +------+ (..host..) source:A1 destination:B1 route:B1,C2,D3 offset:4 on net 1: source:A1 destination:B1 route:A1,C2,D3 offset:8 on net 2: source:A1 destination:C2 route:A1,B2,D3 offset:12 on net 3: source:A1 destination:D3 route:A1,B2,C3 offset:16 What you show is the way TOPS20 has implemented it, where host A has put a record of its outgoing interface into the packet. The unix implementations do not do this, and the source route option only has 2 hops. Here is an example of unix flavor source routed packet, with an octal dump of the packet on the way out of teh source host, and another on receipt at the destination (the same host in this case). Note also the extra pad (1) option. A1=10.2.0.82 B1=10.2.0.5 B2=128.89.0.5 C2=128.89.0.4 C3=10.3.0.82 D3=10.2.0.82 Outgoing packet: 110 0 0 54 0 0 100 0 31 24 263 53 12 2 0 122 12 2 0 5 1 203 13 4 200 131 0 4 12 2 0 122 1 226 0 0 0 0 0 305 147 244 226 0 Incoming packet: 110 0 0 54 0 0 100 0 27 24 264 324 12 2 0 122 12 2 0 122 1 203 13 14 200 131 0 5 12 3 0 122 1 226 0 0 0 0 0 305 147 244 226 0 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13287%40amdcad.UUCP] <1986100720560000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: phil@amdcad.UUCP Newsgroups: mod.protocols.tcp-ip Subject: testing Message-ID: <13287@amdcad.UUCP> Date: Wed, 8-Oct-86 00:56:00 EDT Article-I.D.: amdcad.13287 Posted: Wed Oct 8 00:56:00 1986 Date-Received: Wed, 8-Oct-86 08:12:15 EDT Organization: AMDCAD, Sunnyvale, CA Lines: 19 Approved: phil@amdcad.UUCP Recently, I became aware that by following "proper" procedures for posting into ARPAnet mailing lists, my articles were processed in such a way as to never make it into the USENET side of the world. It appears that these problems will be with us until the release and installation of the long awaited 2.11 aka 2.10.3 netnews. In the meantime I am going to cheat and bypass the "proper" procedure. I do not know if this method will get into the ARPAnet. If it does not, I will have to send my articles out twice. If you are receiving this note via an ARPAnet mailing list, could you please let me know so I can avoid duplications? Thanks. -- DIP stands for DECnet-DOS Installation Procedure. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100803133700> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Wed 8 Oct 86 04:16:15-PDT Received: by vax.darpa.mil (4.12/4.7) id AA02224; Wed, 8 Oct 86 07:13:43 edt Date: Wed 8 Oct 86 07:13:37-EDT From: Dennis G. Perry Subject: [Jeff Mayersohn : more on arpanet] To: tcp-ip@SRI-NIC.ARPA, steve@BRL.ARPA Cc: perry@VAX.DARPA.MIL Message-Id: In-Reply-To: Message from "CERF@A.ISI.EDU" of 7 Operry The latest in the ongoing saga, or "How to train a neglected child to behave properly" dennis --------------- Received: from CC5.BBN.COM by vax.darpa.mil (4.12/4.7) id AA29722; Wed, 8 Oct 86 01:45:47 edt Message-Id: <8610080545.AA29722@vax.darpa.mil> To: prishivalko@ddn1.ARPA, grindle@ddn1.ARPA, leonard@ddn1.ARPA, arpanetmgr@ddn1.ARPA To: perry@vax.darpa.mil, blumenthal@cc5.bbn.com, hinden@cc5.bbn.com, mckenzie@cc5.bbn.com, pogran@cc5.bbn.com To: jburke@cc5.bbn.com, bartlett@cc5.bbn.com Cc: mayersoh@cc5.bbn.com, jwiggins@cc5.bbn.com, cgreenleaf@cc5.bbn.com, rpyle@cc5.bbn.com, fserr@cc5.bbn.com Subject: more on arpanet Date: 08 Oct 86 01:34:20 EDT (Wed) From: Jeff Mayersohn I wanted to bring everyone up to date on the progress of our investigation into Arpanet congestion. There has been one major "discovery" made during the last week. Apparently, in the middle of August, the line between the two USC packet switches, which used to be a stub, was placed into the main cross-country path. The problem is that this line, which connects two endpoints on the USC campus, is apparently running at 19.2 kbps. This change to the network topology is like closing a lane on Storrow Drive during rush hour. It congests both the main artery and the roads which feed it. This is undoubtedly a major contributor to the cross-country congestion that we are seeing; the line should have its capacity increased at once. This piece of information has been communicated by Bob Steele, here at BBNCC, to the Arpanet manager at DCA. In the past few weeks, it has been observed that some of the links on the major cross-country paths have been bouncing up and down. We believe this is due to a known problem in the microcode; the Arpanet has not been running the most current microcode release. The newer release is in the process of being installed. TAC 113, which contains several efficiencies, is also in the process of being installed. Jeff Burke tells me that these upgrades will be finished within the week. Tracy Mallory and Bob Hinden tell me that a new release of the mailbridge was installed in the network and changes have been made to the routing tables in the Butterfly gateways which cause some traffic to favor the Wideband Network over the Arpanet. John Wiggins and Clive Greenleaf have made a number of measurements on the Arpanet and have made a number of parameter changes in the packet switch software. First, it was observed that routing updates were being generated at very close to the maximum frequency, a sure sign that routing is thrashing in its attempt to deal with congestion. Changes were made to line parameters to stabilize routing by reporting more or less equivalent delays on the three cross-country paths. It was expected that this would reduce the pointless movement of traffic from one trunk to another. In addition, it was observed that there were end-to-end resource shortages in a number of packet switches. John modified a parameter which reduces the amount of time that a source packet switch can hold on to resources that it has reserved in a destination packet switch. The hope is that this would alleviate some of the contention for end-to-end resources. The changes described in the last paragraph and (I believe) the installation of the new mailbridge release were made on October 2. Measurements made by Wiggins and Greenleaf on October 3 suggest that the changes had a positive effect. Traffic in the network increased by about 30% (from October 2 to October 3) during the peak period and round trip delays were halved. The major symptoms of congestion persisted, however. There are two other observations to be made. There appears to have been a change in some of the characteristics of the network traffic recently. In particular, we have observed an increase in the distance between communicating hosts from an average of 2.75 in June to 3.54 in October. This is worth looking into. Second, some of the mail on TCP-IP questions why cross-country subnetwork congestion should affect traffic between, say, Stanford and SRI. Clive Greenleaf has looked into this and has produced the following explanation. In order to send a message between a pair of packet switches, resources are used in both the source and destination. What is happening is that the long delays across the network are causing these resources to be held for long periods of time. The fact that these resources are so occupied is affecting all other traffic to and from a given switch, even if that traffic is to or from adjacent switches, or local to the switch. The Stanford IMP, which seems to send traffic to a large number of remote destinations, and the SRI IMP appear to be major victims of this phenomenon. Anyway, here's where we stand: 1) The USC line should be upgraded asap. 2) The microcode release which should eliminate the flapping of key lines is being installed. 3) The TAC release which should reduce TCP retransmissions and network overhead is being installed. 4) We are making store-and-forward statistics measurements to identify all subnetwork bottlenecks. 5) We will produce a complete host traffic matrix in order to determine how the network traffic has changed and to determine whether any hosts are exhibiting antisocial behavior. 6) The topological changes recommended in my previous message should be made. Recall that the network was showing symptoms of congestion in June, before the USC line was thrown into the cross-country path. 7) We intend to produce a new set of recommended assignments of hosts to mailbridges and may recommend the addition of mailbridges when this analysis is complete. ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100808190000> Received: from A.BBN.COM by SRI-NIC.ARPA with TCP; Wed 8 Oct 86 09:23:33-PDT Date: 8 Oct 1986 12:19-EDT Sender: CLYNN@A.BBN.COM Subject: Re: IP source routing questions From: CLYNN@A.BBN.COM To: deering@PESCADERO.STANFORD.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.BBN.COM] 8-Oct-86 12:19:13.CLYNN> In-Reply-To: <86/10/02 2315.440@pescadero.stanford.edu> Steve, The source routing that you have described is much better than that in the second message (from MarkL). The latter ignores the fact that a host (A) may be multiply homed, either to a single net or to multiple nets, and thus may not provide the destination host (D) with sufficient information to be able to return a datagram to the soure host (A) by inverting the route (as described in the second message). In fact it is most likely to fail just when it is most needed -- when one of A's interfaces/network+gateway has failed. For example, consider the case where A has two interfaces, A1 and A2, to your net 1 and net 2. A TCP connection between A and D should use A2 as the ADDRESS representation for A's NAME since it is one network closer to D. Thus the source would be A2 and the destination D3. If A's interface to net 2 should fail, the failure should be reported to the higher layers, e.g., IP and the IP routing algorithm would select the other interface, A1, to send the packet. This won't "work" since the return packets have A2 as the destination and that path is non-functioning. This is where a "robust" host implementation would like to use a source route to specify that (return) packets to A2 should be source routed via A1. The implementation that you describe can do this because the record route option has the IP address of the host interface which was used to send the packet; the other implementation will fail because it does not. Note that in the above it is assumed that a system receiving a source routed packet will invert the route and use it for outgoing packets. Note also that it is not something that would "properly" be done at the IP level, but at a higher level such as TCP or UPD, automatically unless a higher level protocol/application has specified something to the contrary. This "robustness" requirement is not described anywhere in the IP/TCP/xxx protocol specifications. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.V3.10.ddp.0.lancaster.471.0%40andrew.cmu.edu] <1986100808293700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ddp@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: mod.protocols.tcp-ip Subject: IP on 802.5 Message-ID: Date: Wed, 8-Oct-86 12:29:37 EDT Article-I.D.: andrew.MS.V3.10.ddp.0.lancaster.471.0 Posted: Wed Oct 8 12:29:37 1986 Date-Received: Thu, 9-Oct-86 20:54:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa It's been a while since the last message about this, so I thought I'd bring it back up. Last we heard, John posted his proposed standard using a new field in 802.2 called the SNAP. Does anyone know if anything has happened towards getting official numbers for this yet? I see more and more tokenring's being deployed with various bogus schemes while this issue remains unresolved. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610081436.aa00920%40SEM.BRL.ARPA] <1986100810362700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ron@BRL.ARPA (Ron Natalie) Newsgroups: mod.protocols.tcp-ip Subject: Re: Peace fullness. Message-ID: <8610081436.aa00920@SEM.BRL.ARPA> Date: Wed, 8-Oct-86 14:36:27 EDT Article-I.D.: SEM.8610081436.aa00920 Posted: Wed Oct 8 14:36:27 1986 Date-Received: Thu, 9-Oct-86 20:56:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Wollengong is a commercialization of University research. Their code is all based on the original Berkeley implementations. Not to say that they didn't do a lot of work to get it to run in hostile environments like VMS and System V. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610071611.AA25611%40mitre-bedford.ARPA] <1986100901424200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: bjp@MITRE-BEDFORD.ARPA Newsgroups: mod.protocols.tcp-ip Subject: New Version of the Ulana Specifications Message-ID: <8610071611.AA25611@mitre-bedford.ARPA> Date: Thu, 9-Oct-86 05:42:42 EDT Article-I.D.: mitre-be.8610071611.AA25611 Posted: Thu Oct 9 05:42:42 1986 Date-Received: Thu, 9-Oct-86 20:34:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 33 Approved: tcp-ip@sri-nic.arpa This noice is to announce that a new version of the ULANA Specifications has been released and now is available at the ulana ftp site. address: mitre-b-ulana.arpa user: guest password: anonymous pathname: /usr/mitre/guest/ulana.specs Any comments about the specifications should be mailed to: ulana@mitre-bedford.arpa General correspondence should be mailed to: bjp@mitre-bedford.arpa bj Pease ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610091539.AA19103%40opal.Berkeley.Edu] <1986100907383700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: telnet synch Message-ID: <8610091539.AA19103@opal.Berkeley.Edu> Date: Thu, 9-Oct-86 11:38:37 EDT Article-I.D.: opal.8610091539.AA19103 Posted: Thu Oct 9 11:38:37 1986 Date-Received: Thu, 9-Oct-86 21:02:16 EDT References: <8610060622.AA08503@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 81 Approved: tcp-ip@sri-nic.arpa Charles, 1) Am I correct that the only thing to be sent is IAC, DM? The description of synch makes it sound like two separate things are sent: one out of band and the other in the normal data stream. After reading the description of urgent data about 5 times, I have finally concluded that this the wrong conception of how urgent data works, and that in fact only the IAC, DM is sent. Yes, you only send IAC, DM. You should note, by the way, that BSD systems have the TCP RFC concept of what the urgent pointer is (one byte PAST the last byte of urgent data), when the "official protocols RFC" (and the MIL-STD) have changed the definition to point at the LAST byte of urgent data (a rather strange definition, given what TCP ack numbers are). 2) I find the whole concept of urgent data slightly odd. Both the telnet spec and the Unix implementation imply that urgent is some sort of out of band data, that manages to arrive out of order, going ahead of any normal data. It looks to me like this isn't quite the case. Rather there is a bit that says, "go into urgent mode". It seems like nobody really cares exactly when (i.e. at which byte) you go into urgent mode. Then there is a pointer that tells you the end of the urgent data, at which point you go out of urgent mode. 4.2 seems to have a different view of the world. They pull the last byte of urgent data out of the normal byte stream and call it out of band data. It's not clear whether this is quite what TCP had in mind. Urgent IS out of band data; the only thing is that the out of band data is only 1 bit worth: "there is an urgent condition present in the data flow". BSD took the "out of band" approach, and actually tried to identify an out-of-band BYTE. This is unreliable, and 4.3 allows a socket option (SO_OOBINLINE) to remove this concept (for incoming data). 3) The telnet spec further confuses things by saying that DM should be transmitted as the only octet in an urgent message. The problem is that this seems to ignore the necessity for an IAC. The reason for this is, probably, the confusion about which byte is the urgent byte. What they are saying is "transmit IAC normally, then transmit DM urgently, then transmit whatever else you want normally" (ie: two or three seperate calls to "tcp_send"). Anyway, from all of this, I conclude that synch should be implemented as follows: When I type a ^O, put out an IAC, DM, and set the urgent pointer so that the DM is the last byte of urgent data (the only byte as far as Unix is concerned). The way 4.2 works (at least on the Pyramid), the moment I set the urgent pointer, all packets get the urgent flag set until the point where the DM has been sent. This seems to be right. Because of the confusion about which byte is urgent, because of BSD being one number too high, because of the TELNET spec's algorithm for when to LEAVE synch mode, the thing to do is to send the IAC as urgent (MSG_OOB?), then the DM as normal. Thus, the receiver will either see the urgent mode go away after receiving the IAC, or after the DM (the former if the receiver is a BSD system, the latter if the receiver is some other, MIL-STD conforming, system). What makes me suspicious of this is the 4.2 telnet seems to get confused by it. Telnet doesn't set up for the URGENT signal. So the final urgent byte, the DM, is simply removed from the input stream by the kernel. The result is mildly odd. When I type ^O, the host ends up echoing ^O back at me. So the last few bytes of the data stream are IAC DM ^ O. Since the DM is pulled out by the kernel, Unix sees IAC ^, which is of course a bogus telnet command, and prints only the O. If I understand what is going on properly, what I am sending is right, and it is the combination of 4.2 and 4.2 telnet that is wrong. Has anybody followed me to this point? Do I seem to be making sense? This is fixed in the 4.3 server (and client). Fortunately, our two kinds of terminal servers (Bridge CS/100's and Cisco ASM's) both seem to do the right thing. It's *so* nice to have ^C and ^O work again. Summary: look in the 4.3 telnet server and client code; implement SO_OOBINLINE in your kernels. Greg Minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610091539.AA16270%40mitre-gateway.arpa] <1986100907394700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip-RELAY@SRI-NIC.ARPA (William Morgart) Newsgroups: mod.protocols.tcp-ip Subject: IP source routing questions Message-ID: <8610091539.AA16270@mitre-gateway.arpa> Date: Thu, 9-Oct-86 11:39:47 EDT Article-I.D.: mitre-ga.8610091539.AA16270 Posted: Thu Oct 9 11:39:47 1986 Date-Received: Thu, 9-Oct-86 21:03:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa After reading the previous messages on IP routing options I thought I'd mention a few problems with those messages. All of the problems are caused by the differences between RFC791, The DARPA Internet Protocol Specification, and MILSTD-1777, The DoD Military Standard Internet Protocol. The earlier messages stated that the destnation address in the IP header is changed at intermedate gateways that are in the source route list. This is only true if the IPs are implemented according to the RFC. If the IP was implemented following the MILSTD, it will not change the header. This is a little gotcha that must be watched since an implementation meant for the DoD world of MILNET will be required to meet the MILSTD and not the RFC. Another gotcha also relating to options processing is what options are copied on fragmentation. In the RFC the "Loose Source and Record Route" option is specified as being copied while in the MILSTD it isn't copied. Even the MILSTD is confused on this point since it defines the most significant bit of the option to be the copy flag and the option type for LSRR is 0131 (octal) though the text in the MILSTD specifies that LSRR isn't copied. Next, the security option as specified in both the RFC and the MILSTD has been superseded by a new security option developed by the IPSO Working Group in early 1985. A document describing the new option should be available for DCA or DDN. Finally, a comment for thought: since DoD via DARPA is paying for the ARPANET and MILNET plus requiring that MILNET use the MILSTD verison of IP, the ARPANET side of the world should think about using the MILSTD version also. If this doesn't happen the two sides won't be able to interoperate. Bill Morgart bmorgart@mitre-gateway.arpa Phone: (703) 883-6554 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100910010000> Mail-From: STJOHNS created at 9-Oct-86 17:03:32 Date: 9 Oct 1986 17:01-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: IP source routing questions From: STJOHNS@SRI-NIC.ARPA To: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA] 9-Oct-86 17:01:39.STJOHNS> In-Reply-To: <8610091539.AA16270@mitre-gateway.arpa> *sigh* Speaking as one of those people who gets to fight the protocol battles at the DDN PMO (ever hear of Capt Don Quixote), the MIL STDs are suppoosed to mirror the RFC's. The places where they don't mirror the RFC's are errors and should be reported as such. *sigh* The MIL STDs have a page at the back that can be used to report these errors. You don't even have to put a stamp on them. It may take a while, but eventually revised MIL STDs will be issued. Until then, use both the MIL STDs and the RFCs to implement and ask questions here if they differ. Also, I've been trying to find time to issue the revised IP Security Option as an RFC, but no luck. I am making it available for anonymous FTP from the NIC under the path "PS:IPSO.TXT". As far as the status of the IPSO goes, it has been sent to the printers and should be available SOON from Navy Pubs. The version I am making available should be the same as the one available from Navy Pubs with the slim possibility of minor changes. Mike StJohns, tilter at windmills ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610091803.AA13594%40ucbvax.Berkeley.EDU] <1986100910031200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mwm@cuuxb.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Netnews in your mailbox Message-ID: <8610091803.AA13594@ucbvax.Berkeley.EDU> Date: Thu, 9-Oct-86 14:03:12 EDT Article-I.D.: ucbvax.8610091803.AA13594 Posted: Thu Oct 9 14:03:12 1986 Date-Received: Thu, 9-Oct-86 22:19:31 EDT References: <8609302105.AA05950@cbosgd.ATT.COM> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: cuuxb!mwm@ucbvax.Berkeley.EDU (Marc W. Mengel) Organization: AT&T-IS, Software Support, Lisle IL Lines: 19 Approved: tcp-ip@sri-nic.arpa Summary: mh-6.1 will do it, with minor hacks In article <8609302105.AA05950@cbosgd.ATT.COM> mark@cbosgd.att.com (Mark Horton) writes: >>My host spends >>90% of it's time on the ARPAnet sending and receiving INFO-THIS, and INFO-THAT. >>Also, I have multiple users receiving the same message from INFO-WHATEVER >>as separate TCP connections to my host. > >If the ARPANET mailing lists do turn out to be the cause of the problem, >I'd like to suggest a possible solution: Netnews. ... >The major problems with using netnews on the ARPA Internet have >historically been ... >(2) Many users prefer to keep their mail and news lumped together >in their mailbox. Recent versions of the MH mail handler allow you to read news with your mail program(s); most easily under 4.xBSD with symbolic links from your mail directory into news directory's. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610100147.AA20932%40ucbvax.Berkeley.EDU] <1986100911550700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: brescia@CCV.BBN.COM (Mike Brescia) Newsgroups: mod.protocols.tcp-ip Subject: Re: IP source routing questions Message-ID: <8610100147.AA20932@ucbvax.Berkeley.EDU> Date: Thu, 9-Oct-86 15:55:07 EDT Article-I.D.: ucbvax.8610100147.AA20932 Posted: Thu Oct 9 15:55:07 1986 Date-Received: Fri, 10-Oct-86 07:20:25 EDT References: <8610091539.AA16270@mitre-gateway.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa (from bmogart@mitre) All of the problems are caused by the differences between RFC791, The DARPA Internet Protocol Specification, and MILSTD-1777, The DoD Military Standard Internet Protocol. My understanding of mil-std-1777 was that it recast the darpa IP spec in mil-std terminology. I thought that there was no intent to change the spec, or cause disinteroperability. I would be interested in hearing if anyone has implemented the mil-std spec /in vacuo/ and expected that implementation to talk to any existing host, or pass packets through any existing gateway. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100911550701> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 9 Oct 86 12:56:09-PDT To: tcp-ip@sri-nic.ARPA Subject: Re: IP source routing questions In-reply-to: Your message of Thu, 9 Oct 86 11:39:47 EDT. <8610091539.AA16270@mitre-gateway.arpa> Date: 09 Oct 86 15:55:07 EDT (Thu) From: Mike Brescia (from bmogart@mitre) All of the problems are caused by the differences between RFC791, The DARPA Internet Protocol Specification, and MILSTD-1777, The DoD Military Standard Internet Protocol. My understanding of mil-std-1777 was that it recast the darpa IP spec in mil-std terminology. I thought that there was no intent to change the spec, or cause disinteroperability. I would be interested in hearing if anyone has implemented the mil-std spec /in vacuo/ and expected that implementation to talk to any existing host, or pass packets through any existing gateway. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986100912450000> Received: from LLL-MFE.ARPA by SRI-NIC.ARPA with TCP; Thu 9 Oct 86 20:44:33-PDT Date: Thu, 9 Oct 86 19:45 PDT From: Provan@LLL-MFE.ARPA Subject: re: IP source routing questions To: tcp-ip@sri-nic.arpa there is an errata sheet on the Milspec for IP which corrects exactly these problems. unfortunately, i don't remember where it is or even whether it's been officially released. since there are bugs in the Milspec that appear to me to prevent actually implementing it, i don't think there's too much worry about someone implementing it in a vacuum. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610100058.AA13743%40devvax.tn.cornell.edu] <1986100916585100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) Newsgroups: mod.protocols.tcp-ip Subject: telnet synch Message-ID: <8610100058.AA13743@devvax.tn.cornell.edu> Date: Thu, 9-Oct-86 20:58:51 EDT Article-I.D.: devvax.8610100058.AA13743 Posted: Thu Oct 9 20:58:51 1986 Date-Received: Sat, 11-Oct-86 11:19:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Fortunately, our two kinds of terminal servers (Bridge CS/100's and Cisco ASM's) both seem to do the right thing. It's *so* nice to have ^C and ^O work again. Does anyone know if Encore Annexes [seem to] do the right thing? Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610111403.AA23313%40ucbvax.Berkeley.EDU] <1986100918450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Provan@LLL-MFE.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: IP source routing questions Message-ID: <8610111403.AA23313@ucbvax.Berkeley.EDU> Date: Thu, 9-Oct-86 22:45:00 EDT Article-I.D.: ucbvax.8610111403.AA23313 Posted: Thu Oct 9 22:45:00 1986 Date-Received: Sat, 11-Oct-86 14:33:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa there is an errata sheet on the Milspec for IP which corrects exactly these problems. unfortunately, i don't remember where it is or even whether it's been officially released. since there are bugs in the Milspec that appear to me to prevent actually implementing it, i don't think there's too much worry about someone implementing it in a vacuum. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12245586182.12.OLE%40SRI-NIC.ARPA] <1986100920535600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen) Newsgroups: mod.protocols.tcp-ip Subject: MIL-STD Problems Message-ID: <12245586182.12.OLE@SRI-NIC.ARPA> Date: Fri, 10-Oct-86 00:53:56 EDT Article-I.D.: SRI-NIC.12245586182.12.OLE Posted: Fri Oct 10 00:53:56 1986 Date-Received: Sat, 11-Oct-86 14:34:11 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa RFC's 963 and 964 by Sidhu list problems (errors?) in the MIL-STD specs for IP and TCP. Avaiable from you-know-where. Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101002020000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 10 Oct 86 03:04:38-PDT Date: 10 Oct 1986 06:02-EDT Sender: CERF@A.ISI.EDU Subject: Re: IP source routing questions From: CERF@A.ISI.EDU To: CLYNN@BBNA.ARPA Cc: deering@PESCADERO.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]10-Oct-86 06:02:24.CERF> In-Reply-To: <[A.BBN.COM] 8-Oct-86 12:19:13.CLYNN> Charlie, For the case in point where a packet for a TCP connection is re-routed to arrive at a host on a distinct interface from the one the connection originally was formed upon, how would the TCP layer properly map to the correct connection, considering that the apparent destination address in the IP would have changed from A1 to A2 - or do you leave the A1 in place to aid TCP demuxing but source route to A2 (a change in the interpretation of the source routing function att the IP level, I think). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610120107.AA00503%40amdahl] <1986101117074700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: dave@dlb.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Wanted: members for panel discussion on tcp-ip and sna Message-ID: <8610120107.AA00503@amdahl> Date: Sat, 11-Oct-86 21:07:47 EDT Article-I.D.: amdahl.8610120107.AA00503 Posted: Sat Oct 11 21:07:47 1986 Date-Received: Sun, 12-Oct-86 06:51:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa I'll be chairing a panel discussion at /usr/group's UNIFORUM in Washington DC in January, 1987; topic is tcp-ip vs sna. I'm looking for speakers who can attend the conference and speak for 10-20 minutes. The abstract for the panel session is: This session will compare Transmission Control Protocol / Internet Protocol (TCP/IP) and System Network Architecture (SNA) networking for the UNIX community -- specifically, basic capabilities of the two networks and common applications in commercial networks. It will also address the potential for (and value of) co-existence of the two protocols, gateways between them and advanced network capabilities, including PC-to-mainframe communications. The session is scheduled for 22 Jan 87, 14:00 to 15:30 EST. If you know of someone who might be interested in speaking, please have them contact me as soon as possible. -- Dave Buck (408)972-2825 dave@dlb.BUCK.COM, {amdahl,sun}!dlb.UUCP!dave D.L.Buck&Assoc.,Inc. 6920 Santa Teresa Blvd. San Jose, Calif.95119 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101207481100> Received: from B.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 12 Oct 86 14:51:43-PDT Date: 12 Oct 1986 14:48:11 PDT From: POSTEL@B.ISI.EDU Subject: Source Routing To: tcp-ip@SRI-NIC.ARPA Hi. I have a draft RFC on the IP Source Routing Option. If you are interested in reviewing it please copy it via FTP from "B.ISI.EDU". The FTP pathname is "SRC-RTE.DRAFT". The current MIL-STD-1777 is wrong about some of the details of the IP Source Route Options. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101208504500> Received: from B.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 12 Oct 86 15:51:56-PDT Date: 12 Oct 1986 15:50:45 PDT From: POSTEL@B.ISI.EDU Subject: RFCs & MIL-STDs To: tcp-ip@SRI-NIC.ARPA Hi. It is the intention that the RFC specifications and the MIL-STD specifications describe exactly the same protocols. In principle, an implementation based solely on the RFCs should interoperate with an implementation based solely on the MIL-STDs. In practice, every implementer should make use of both the RFC documents and the MIL-STD documents. The notion that the RFCs apply to ARPANET, and the MIL-STDs to MILNET is wrong. If an implementer thinks there is a difference in what is required between the RFCs and the MIL-STDs that difference should be reported to DCA and the IAB and be resolved. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101209263800> Received: from B.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 12 Oct 86 16:32:13-PDT Date: 12 Oct 1986 16:26:38 PDT From: POSTEL@B.ISI.EDU Subject: IP on 802 To: tcp-ip@SRI-NIC.ARPA Well, i haven't got an RFC out yet, but the procedure described in the following memo should be used anyway. There is a small and ever decreasing possibility that the values of K1 and K2 may be different than indicated below, so consider the possibility of having them changable in your implementation. In the mean time please go ahead and use this encapsulation format for doing IP and ARP (and other things) on 802 nets, using K1=170, and K2=0. The IEEE likes to talk about bytes in little endian order so they say K1 is 01010101. The ARPA protocols have everything in big endian order so that K1 becomes 10101010 binary or AA hex or 170 decimal. This value is pretty definite. The value of K2 is somewhat less certain, but no evidience to the contrary has surfaced yet. --jon. *** begin *** Date: 29 Aug 1986 19:27:12 PDT From: POSTEL@B.ISI.EDU Subject: How to IP & ARP on 802 Nets To: tcp-ip@SRI-NIC.ARPA Hello. At an ad hoc special session on "IEEE 802 Networks and ARP" held during the recent TCP Vendors Workshop, an approach to a consistent way to sent DOD-IP datagrams and other IP related protocols on 802 networks was developed. Due to some evolution of the IEEE 802.2 standards and the need to provide for a standard way to do additional DOD-IP related protocols (such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the following new policy is being proposed, which will replace the current policy (see page 26 of RFC-960 and RFC-948). The proposal is for DDN and ARPA-Internet community to use IEEE 802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the SNAP with an organization code indicating that the following 16 bits specify the Ethertype code (where IP = 2048 (0800 hex), see page 27 of RFC-960). ...--------+--------+--------+ MAC Header| Length | 802.{3/4/5} MAC Header ...--------+--------+--------+ +--------+--------+--------+ | Dsap=K1| Ssap=K1| control| 802.2 SAP Header +--------+--------+--------+ +--------+--------+---------+--------+--------+ |protocol id or org code =K2| Ether Type | 802.2 SNAP Header +--------+--------+---------+--------+--------+ The values of K1 and K2 must be assigned by the IEEE. We believe there is already assigned a value of K1 that indicates that the 5-octet SNAP header follows. We can use this value. There may be a value of K2 that is already assigned that indicates that the last two octets of the SNAP header holds the EtherType. If so we may be able to use this value. This remains to be explored. The EtherTypes are assigned by Xerox (as always). The total length of the SAP Header and the SNAP header is 8-octets, making the 802.2 protocol overhead come out on a nice octet boundary. If we can not quickly resolve the issue of the values for K1 and K2, we will push for the assignment of a sap value (a K1 value) to indicate "IP related protocols" and do our own multiplexing (much like that proposed above). In any case, we will not create incompatible interpretations of headers already in use on 802 networks. *** end *** ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610122336.AA11278%40ucbvax.Berkeley.EDU] <1986101213481100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: POSTEL@B.ISI.EDU Newsgroups: mod.protocols.tcp-ip Subject: Source Routing Message-ID: <8610122336.AA11278@ucbvax.Berkeley.EDU> Date: Sun, 12-Oct-86 17:48:11 EDT Article-I.D.: ucbvax.8610122336.AA11278 Posted: Sun Oct 12 17:48:11 1986 Date-Received: Sun, 12-Oct-86 21:32:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Hi. I have a draft RFC on the IP Source Routing Option. If you are interested in reviewing it please copy it via FTP from "B.ISI.EDU". The FTP pathname is "SRC-RTE.DRAFT". The current MIL-STD-1777 is wrong about some of the details of the IP Source Route Options. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610130034.AA11873%40ucbvax.Berkeley.EDU] <1986101214504500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: POSTEL@B.ISI.EDU Newsgroups: mod.protocols.tcp-ip Subject: RFCs & MIL-STDs Message-ID: <8610130034.AA11873@ucbvax.Berkeley.EDU> Date: Sun, 12-Oct-86 18:50:45 EDT Article-I.D.: ucbvax.8610130034.AA11873 Posted: Sun Oct 12 18:50:45 1986 Date-Received: Sun, 12-Oct-86 22:32:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Hi. It is the intention that the RFC specifications and the MIL-STD specifications describe exactly the same protocols. In principle, an implementation based solely on the RFCs should interoperate with an implementation based solely on the MIL-STDs. In practice, every implementer should make use of both the RFC documents and the MIL-STD documents. The notion that the RFCs apply to ARPANET, and the MIL-STDs to MILNET is wrong. If an implementer thinks there is a difference in what is required between the RFCs and the MIL-STDs that difference should be reported to DCA and the IAB and be resolved. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610130135.AA12408%40ucbvax.Berkeley.EDU] <1986101215263800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: POSTEL@B.ISI.EDU Newsgroups: mod.protocols.tcp-ip Subject: IP on 802 Message-ID: <8610130135.AA12408@ucbvax.Berkeley.EDU> Date: Sun, 12-Oct-86 19:26:38 EDT Article-I.D.: ucbvax.8610130135.AA12408 Posted: Sun Oct 12 19:26:38 1986 Date-Received: Mon, 13-Oct-86 02:50:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 83 Approved: tcp-ip@sri-nic.arpa Well, i haven't got an RFC out yet, but the procedure described in the following memo should be used anyway. There is a small and ever decreasing possibility that the values of K1 and K2 may be different than indicated below, so consider the possibility of having them changable in your implementation. In the mean time please go ahead and use this encapsulation format for doing IP and ARP (and other things) on 802 nets, using K1=170, and K2=0. The IEEE likes to talk about bytes in little endian order so they say K1 is 01010101. The ARPA protocols have everything in big endian order so that K1 becomes 10101010 binary or AA hex or 170 decimal. This value is pretty definite. The value of K2 is somewhat less certain, but no evidience to the contrary has surfaced yet. --jon. *** begin *** Date: 29 Aug 1986 19:27:12 PDT From: POSTEL@B.ISI.EDU Subject: How to IP & ARP on 802 Nets To: tcp-ip@SRI-NIC.ARPA Hello. At an ad hoc special session on "IEEE 802 Networks and ARP" held during the recent TCP Vendors Workshop, an approach to a consistent way to sent DOD-IP datagrams and other IP related protocols on 802 networks was developed. Due to some evolution of the IEEE 802.2 standards and the need to provide for a standard way to do additional DOD-IP related protocols (such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the following new policy is being proposed, which will replace the current policy (see page 26 of RFC-960 and RFC-948). The proposal is for DDN and ARPA-Internet community to use IEEE 802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the SNAP with an organization code indicating that the following 16 bits specify the Ethertype code (where IP = 2048 (0800 hex), see page 27 of RFC-960). ...--------+--------+--------+ MAC Header| Length | 802.{3/4/5} MAC Header ...--------+--------+--------+ +--------+--------+--------+ | Dsap=K1| Ssap=K1| control| 802.2 SAP Header +--------+--------+--------+ +--------+--------+---------+--------+--------+ |protocol id or org code =K2| Ether Type | 802.2 SNAP Header +--------+--------+---------+--------+--------+ The values of K1 and K2 must be assigned by the IEEE. We believe there is already assigned a value of K1 that indicates that the 5-octet SNAP header follows. We can use this value. There may be a value of K2 that is already assigned that indicates that the last two octets of the SNAP header holds the EtherType. If so we may be able to use this value. This remains to be explored. The EtherTypes are assigned by Xerox (as always). The total length of the SAP Header and the SNAP header is 8-octets, making the 802.2 protocol overhead come out on a nice octet boundary. If we can not quickly resolve the issue of the values for K1 and K2, we will push for the assignment of a sap value (a K1 value) to indicate "IP related protocols" and do our own multiplexing (much like that proposed above). In any case, we will not create incompatible interpretations of headers already in use on 802 networks. *** end *** ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610131057.AA23538%40devvax.tn.cornell.edu] <1986101302573400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) Newsgroups: mod.protocols.tcp-ip Subject: communications analyzers for IP?? Message-ID: <8610131057.AA23538@devvax.tn.cornell.edu> Date: Mon, 13-Oct-86 06:57:34 EDT Article-I.D.: devvax.8610131057.AA23538 Posted: Mon Oct 13 06:57:34 1986 Date-Received: Mon, 13-Oct-86 19:12:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Has anyone programmed up a communications analyzer (protocol analyzer, "datascope") to understand IP and overlying protocols? I hope so, but doubt it, so my next question: could people recommend programmable communications analyzers? We have ended up running IP over asynch, synchronous DDCMP and HDLC lines, at speeds from 9.6Kbps to T1. At times a scope which understood IP/TCP/UDP would be tremendously helpful. Please reply directly (not everyone will be interested). I'll summarize for those who would like it. Thanks ... Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.V3.10.leong.0.leong.190.0%40andrew.cmu.edu] <1986101313380300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: re: BOOTP daemon for BSD 4.x Message-ID: Date: Mon, 13-Oct-86 17:38:03 EDT Article-I.D.: andrew.MS.V3.10.leong.0.leong.190.0 Posted: Mon Oct 13 17:38:03 1986 Date-Received: Mon, 13-Oct-86 23:27:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa I am real glad that Bill Croft have made the BootP client and server software available to the public domain. I think it is a very interesting package especially for those who has a lot of PC's around running the MIT PCIP. Since the IP addresses of those machines are associated with floppies which get duplicated regularly by people who don't really know what IP addresses are never mind about "CUSTOM NETDEV" and such ultiliites. The risk of having duplicated IP addresses and subnet address inconsistency due to "wandering" floppy can be very significant. BootP essentially allows one to have a better (not perfect) control to IP address allocation and usage. John Leong ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101409020000> Received: from Score.Stanford.EDU by SRI-NIC.ARPA with TCP; Wed 15 Oct 86 02:55:46-PDT Date: 14 Oct 1986 16:02-PDT Sender: BILLW@SU-SCORE.ARPA Subject: Re: [Jeff Mayersohn : more on arpanet] From: William "Chops" Westfield Cc: tcp-ip@SRI-NIC.ARPA, steve@BRL.ARPA Message-ID: <[SU-SCORE.ARPA]14-Oct-86 16:02:05.BILLW> In-Reply-To: Could the large amount of domain traffic on the stanford and SRI-NIC IMPS be responsible for their execeptionally poor performance? BillW ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610150836.AA02351%40ucbvax.Berkeley.EDU] <1986101409250000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: BEAME@MCMASTER.BITNET Newsgroups: mod.protocols.tcp-ip Subject: Ultirx TCP/IP problems ? Message-ID: <8610150836.AA02351@ucbvax.Berkeley.EDU> Date: Tue, 14-Oct-86 13:25:00 EDT Article-I.D.: ucbvax.8610150836.AA02351 Posted: Tue Oct 14 13:25:00 1986 Date-Received: Thu, 16-Oct-86 07:42:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 47 Approved: tcp-ip@sri-nic.arpa Well Ultrix fans, I am having problems with Ultrix TCP/IP TELNET. Here is a list of packets as seen by the PC. The packets preceeded with a "*" are from the Ultrix machine. I am attempting to cat the file /etc/rc . The first table the Pc's window is 82, while the second table the window is set to 512. The seq and ack are the low word of seq and ack displayed in deciaml. The flag is display if hex. The #char is decimal, and time is in seconds with 1/10 sec ticks. PC Window = 82 who seq ack flag wind. #char time in seconds ----------------------------------------------------- 41 27182 18 82 1 55.70 ; Pc sends last "c" of "cat rc" * 27182 42 18 4096 1 55.70 ; Ultrix echos "c" 42 27183 18 82 0 55.70 ; Pc acks 42 27183 18 82 1 55.90 ; Pc sends "" * 27183 43 18 4096 2 56.00 ; Ultrix echos "" 43 27185 18 82 0 56.00 ; Pc acks * 27185 43 10 4096 82 01.20 ; Utrix sends text 5.2 sec. later 43 27267 18 82 0 01.20 * 27267 43 10 4096 82 06.20 43 27349 18 82 0 06.20 ... PC Window = 512 who seq ack flag wind. #char time ------------------------------------------- 41 20270 18 512 1 10.00 ; Pc enter last "c" in "cat rc" * 20270 42 18 4096 1 10.00 ; Ultrix echo of "c" 42 20271 18 512 0 10.00 ; Ack of echo 42 20271 18 512 1 10.30 ; Pc send of * 20271 43 18 4096 2 10.40 ; Ultrix echos 43 20273 18 512 0 10.40 ; Pc ack of * 20785 43 14 4096 0 20.00 ; Ultrix resets the connection 43 20273 18 512 0 23.00 * 20273 0 04 4096 0 23.00 Any comments and solutions, except using another PC version are welcome. Please send responces to me and I will summerize the results back to the list. - thanks Carl Beame BEAME@MCMASTER.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101409250001> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Tue 14 Oct 86 23:28:14-PDT Received: from (BEAME)MCMASTER.BITNET by WISCVM.WISC.EDU on 10/14/86 at 12:47:45 CDT Date: Tue, 14 Oct 86 13:25 EDT From: Subject: Ultirx TCP/IP problems ? To: tcp-ip@SRI-NIC.ARPA X-Original-To: tcp-ip@SRI-NIC.ARPA, BEAME Well Ultrix fans, I am having problems with Ultrix TCP/IP TELNET. Here is a list of packets as seen by the PC. The packets preceeded with a "*" are from the Ultrix machine. I am attempting to cat the file /etc/rc . The first table the Pc's window is 82, while the second table the window is set to 512. The seq and ack are the low word of seq and ack displayed in deciaml. The flag is display if hex. The #char is decimal, and time is in seconds with 1/10 sec ticks. PC Window = 82 who seq ack flag wind. #char time in seconds ----------------------------------------------------- 41 27182 18 82 1 55.70 ; Pc sends last "c" of "cat rc" * 27182 42 18 4096 1 55.70 ; Ultrix echos "c" 42 27183 18 82 0 55.70 ; Pc acks 42 27183 18 82 1 55.90 ; Pc sends "" * 27183 43 18 4096 2 56.00 ; Ultrix echos "" 43 27185 18 82 0 56.00 ; Pc acks * 27185 43 10 4096 82 01.20 ; Utrix sends text 5.2 sec. later 43 27267 18 82 0 01.20 * 27267 43 10 4096 82 06.20 43 27349 18 82 0 06.20 ... PC Window = 512 who seq ack flag wind. #char time ------------------------------------------- 41 20270 18 512 1 10.00 ; Pc enter last "c" in "cat rc" * 20270 42 18 4096 1 10.00 ; Ultrix echo of "c" 42 20271 18 512 0 10.00 ; Ack of echo 42 20271 18 512 1 10.30 ; Pc send of * 20271 43 18 4096 2 10.40 ; Ultrix echos 43 20273 18 512 0 10.40 ; Pc ack of * 20785 43 14 4096 0 20.00 ; Ultrix resets the connection 43 20273 18 512 0 23.00 * 20273 0 04 4096 0 23.00 Any comments and solutions, except using another PC version are welcome. Please send responces to me and I will summerize the results back to the list. - thanks Carl Beame BEAME@MCMASTER.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610142350.AA26988%40jade.Berkeley.Edu] <1986101415423500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: $JCH@CLVM.BITNET (Jeffrey C Honig) Newsgroups: mod.protocols.tcp-ip Subject: DDN X.25 Message-ID: <8610142350.AA26988@jade.Berkeley.Edu> Date: Tue, 14-Oct-86 19:42:35 EDT Article-I.D.: jade.8610142350.AA26988 Posted: Tue Oct 14 19:42:35 1986 Date-Received: Wed, 15-Oct-86 00:42:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I've been informed that DDN X.25 does not currently work in PSN 6.0 but will be fixed in PSN 6.1. Is that correct? When is PSN 6.1 supposed to be installed? Thanks Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101502232900> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Wed 15 Oct 86 05:27:00-PDT Received: from (GAYE)FRSAC11.BITNET by WISCVM.WISC.EDU on 10/15/86 at 07:26:36 CDT Date: Wed, 15 Oct 86 13:23:29 ZONE To: TCP-IP@SRI-NIC.ARPA From: GAYE%FRSAC11.BITNET@WISCVM.WISC.EDU Subject: TCP-IP MAILING LIST Hi. I would like to be registered in the tcp-ip mailing list. Sincerely Gerard Gaye gaye%frsac11@wiscvm.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610151513.AA06841%40ucbvax.Berkeley.EDU] <1986101507150200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GAYE@FRSAC11.BITNET Newsgroups: mod.protocols.tcp-ip Subject: TCP-IP MAILING LIST Message-ID: <8610151513.AA06841@ucbvax.Berkeley.EDU> Date: Wed, 15-Oct-86 11:15:02 EDT Article-I.D.: ucbvax.8610151513.AA06841 Posted: Wed Oct 15 11:15:02 1986 Date-Received: Wed, 15-Oct-86 20:44:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Hi. I would like to be registered in the tcp-ip mailing list. Sincerely Gerard Gaye gaye%frsac11@wiscvm.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101507530000> Received: from A.BBN.COM by SRI-NIC.ARPA with TCP; Wed 15 Oct 86 08:55:17-PDT Date: 15 Oct 1986 11:53-EDT Sender: CLYNN@A.BBN.COM Subject: Re: IP source routing questions From: CLYNN@A.BBN.COM To: CERF@A.ISI.EDU Cc: deering@PESCADERO.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.BBN.COM]15-Oct-86 11:53:11.CLYNN> In-Reply-To: <[A.ISI.EDU]10-Oct-86 06:02:24.CERF> Vint, This has become a rather long message, but a brief answer to your questions is that all of the routing takes place in the IP layer; as far as TCP is concerned, nothing is different (except that TCP should be notified that IP options were received); thus TCP has no difficulty mapping the datagram to the proper connection. I do not think that I have a different interpretation of the source routing option; I do think that before the routing options can be specified so that they provide maximum functionality one has to consider several factors which are not usually mentioned. 1) One is that it is highly desirable for an ultimate destination IP entity that receives a source routed datagram to be able to construct a return source route. This requires that the IP addresses of the interfaces over which a datagram was sent, by the originating IP entity and each intermediate entity in the source route, be available to the ultimate destination. 2) Another is the "name" vs "address" problem and how it is handled in the DARPA Protocol Suite: the (TCP) pseudo-header. This means, for example, that the "name" which TCP chooses to use to identify the ends of a connection, and are "specified" in the pseudo-header, must be communicated from the source to the ultimate destination. This information is normally (and nobody has suggested changing it) carried in the IP "Source Address" and "Destination Address" fields (of the datagram delivered to the TCP in the ultimate destination). 3) The "catch-22" is that originating entity may be multi-homed. This means that the "address" (interface) which the IP routing algorithms use to send a (TCP) datagram may not be the same as the "address" (name) TCP selected (or was given by a higher level application) to identify the connection. Consequently the IP "Source Address" field cannot (always) be used for the sending interface address, it has to be communicated elsewhere -- in the source route option's Route Data area. The critical point for obtaining the maximal functionality from source routing is that there must be room in the source route option for the originating IP entity (host or gateway) to insert the address it uses to actually send the datagram; the IP Source Identifier (aka Address) field cannot be used for this purpose due to its significance at higher protocol levels. Discussions of "what should be passed to IP", for example as the "destination" and "source route", so that it can construct an IP Source Route Option are essentially "local implementation" issues, which may vary from operating system to operating system. (Although portability of application software would suggest that all implementations use the same method; but user interfaces are not currently part of the IP/TCP specs.) What an IP datagram on a network should look like is specified in the specs. host A gate B gate C host D +------+ +------+ +------+ +------+ | | | | net 2 | | | | | A1|---------|B1 B2|----+----|C2 C3|---------|D3 | | A2 | net 1 | | | | | net 3 | D4 | +------+ +------+ | +------+ +------+ | | | +-------------------------+ 4) Consider the above topology and a TCP connection between A and D which, for whatever reason, TCP has "named" by A2 and D3. A datagram from A to D on nets 2 and 3 would contain IP Source Address A2 and IP Destination Address D3; return datagrams would have IP Source Address D3 and IP Destination Address A2. Normal Internet routing would get datagrams to their destination. 5) Next consider the case where a source route is used to explicitly route the datagrams via C. (The contents of IP datagram on the nets is left as an exercise to the reader.) 6) Now consider the case where the source route specifies B(1) instead of C(2). Is it the case that the only difference between 5) and 6) is that C2 has been replaced by B1 and C3 by B2? It shouldn't be -- there should be an A1 in case 6) but not in 5). From the above discussion, the TCP datagram from A to D on net 1 should contain IP Source Address A2 IP Destination Address B1 LSR Option Type 131 Length "11" Pointer "8" Route Data A1,->D3 On nets 2 and 3 it would be IP Source Address A2 IP Destination Address D3 LSR Option Type 131 Length "11" Pointer "12" Route Data A1,B2,-> When the Route Data is inverted to form a return route note that a final entry for the ultimate destination (A2) must be inserted. A datagram from D to A on nets 3 and 2 would have IP Source Address D3 IP Destination Address B2 LSR Option Type 131 Length "15" Pointer "8" Route Data D3,->A1,A2 On net 1 IP Source Address D3 IP Destination Address A1 LSR Option Type 131 Length "15" Pointer "12" Route Data D3,B1,->A2 What should A do with this? (Consider what is should do if the "A2" were "Zn".) EVERY IP Entity (no distinction between gateways and hosts) processes routing options in the way specified in RFC 791, pg 19, first paragraphs: "If the address in the destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and the pointer is increased by four. The recorded route address is the internet module's own internat address as known in the environment into which this datagram is being forwarded." The "easy" part gets IP Source Address D3 IP Destination Address A2 LSR Option Type 131 Length "15" Pointer "16" Route Data D3,B1,?,-> The question mark has to be filled in and the datagram sent to A2. What should appear where the question mark is shown is probably a "local implementation" decision; most operating systems have some capability to support TCP connections between processes within the host, even if there is no functioning network interface or even if no physical network connection exists. The os can do several things, the only requirements are that it be consistent, that any "applications" understand what it does, and that no "funnny addresses" end up being "interpreted" in the wrong context. There is much more that could be discussed if there is sufficient interest. Does anyone have a different solution to the "Source Interface Address" problem. Is the additional robustness worth the cost? Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610152204.AA01488%40ucbvax.Berkeley.EDU] <1986101508402100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ahill@CC7.BBN.COM ("Alan R. Hill") Newsgroups: mod.protocols.tcp-ip Subject: Re: DDN X.25 Message-ID: <8610152204.AA01488@ucbvax.Berkeley.EDU> Date: Wed, 15-Oct-86 12:40:21 EDT Article-I.D.: ucbvax.8610152204.AA01488 Posted: Wed Oct 15 12:40:21 1986 Date-Received: Wed, 15-Oct-86 23:57:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Jeff, I can assure you that DDN Basic and DDN Standard X.25 work in PSN 6.0. Also, there is no version of the PSN called 6.1. The next version of the PSN is 7.0 and it is expected to be deployed in the ARPANET in the next few months. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101508402101> Received: from cc7.bbn.com by SRI-NIC.ARPA with TCP; Wed 15 Oct 86 09:45:38-PDT Date: Wed, 15 Oct 86 12:40:21 EDT From: "Alan R. Hill" Subject: Re: DDN X.25 In-Reply-To: Your message of Tue, 14 Oct 86 19:42:35 EDT To: tcp-ip@sri-nic.arpa Jeff, I can assure you that DDN Basic and DDN Standard X.25 work in PSN 6.0. Also, there is no version of the PSN called 6.1. The next version of the PSN is 7.0 and it is expected to be deployed in the ARPANET in the next few months. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610160146.AA05667%40ucbvax.Berkeley.EDU] <1986101510000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET Newsgroups: mod.protocols.tcp-ip Subject: re: Ultrix TCP/IP problems Message-ID: <8610160146.AA05667@ucbvax.Berkeley.EDU> Date: Wed, 15-Oct-86 14:00:00 EDT Article-I.D.: ucbvax.8610160146.AA05667 Posted: Wed Oct 15 14:00:00 1986 Date-Received: Thu, 16-Oct-86 02:09:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa HELP ! What is ethernet protocol 1001h and why is my Ultrix Vax using it to send TELNET data? During a regular TELNET TCP/IP session from my PC (Window size of 512) to the VAX (Window size of 4096) I attempt to "cat" a large file, the Vax starts sending packets of protocol type 1001h which seems to be of the form: dest address source address type data [ 6 bytes ] [ 6 bytes ] [1001h] [512 bytes data] [44 bytes ?] My uVAX and PC are on the same local ethernet, no gateways. - Carl Beame ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101510000001> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Wed 15 Oct 86 16:40:54-PDT Received: from (BEAME)MCMASTER.BITNET by WISCVM.WISC.EDU on 10/15/86 at 13:25:40 CDT Date: Wed, 15 Oct 86 14:00 EDT From: Subject: re: Ultrix TCP/IP problems To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, BEAME HELP ! What is ethernet protocol 1001h and why is my Ultrix Vax using it to send TELNET data? During a regular TELNET TCP/IP session from my PC (Window size of 512) to the VAX (Window size of 4096) I attempt to "cat" a large file, the Vax starts sending packets of protocol type 1001h which seems to be of the form: dest address source address type data [ 6 bytes ] [ 6 bytes ] [1001h] [512 bytes data] [44 bytes ?] My uVAX and PC are on the same local ethernet, no gateways. - Carl Beame ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610152105.AA03738%40saturn.uplherc.uucp] <1986101513052300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jr@saturn.UUCP (J.R. Westmoreland) Newsgroups: mod.protocols.tcp-ip Subject: Info needed on PCIP Message-ID: <8610152105.AA03738@saturn.uplherc.uucp> Date: Wed, 15-Oct-86 17:05:23 EDT Article-I.D.: saturn.8610152105.AA03738 Posted: Wed Oct 15 17:05:23 1986 Date-Received: Thu, 16-Oct-86 00:05:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I would like some information on PCIP. I would like to know if it is a publicly available package or if it is for slae.If it is for sale I would like to know the cost. Also, I would like to know where the package can be obtained. Thanks, J. R. Westmoreland Utah Power & Light Company Salt Lake City, Utah ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101601500000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 16 Oct 86 02:59:32-PDT Date: 16 Oct 1986 05:50-EDT Sender: CERF@A.ISI.EDU Subject: Re: IP source routing questions From: CERF@A.ISI.EDU To: CLYNN@BBNA.ARPA Cc: deering@PESCADERO.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]16-Oct-86 05:50:55.CERF> In-Reply-To: <[A.BBN.COM]15-Oct-86 11:53:11.CLYNN> Charlie, thanks for the tutorial! The critical item for the case of multi-homed hosts, is that the IP address be constant, regardless of which port the host sends/receives messages. This is because TCP binds connections to IP source/destination addresses. Not all networks can provide logical addressing and this motivates concepts of logical addressing at the IP level to compensate. It was for that reason that I asked my question. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610161328.AA15526%40ucbvax.Berkeley.EDU] <1986101602132500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HANK@BARILVM.BITNET (Henry Nussbacher) Newsgroups: mod.protocols.tcp-ip Subject: Looking for Tcp/Ip Implementations for Intel System 310/330/380 Message-ID: <8610161328.AA15526@ucbvax.Berkeley.EDU> Date: Thu, 16-Oct-86 06:13:25 EDT Article-I.D.: ucbvax.8610161328.AA15526 Posted: Thu Oct 16 06:13:25 1986 Date-Received: Thu, 16-Oct-86 21:57:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Henry Nussbacher Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa I am looking for information about Tcp/Ip implementations for Intel 310, 330,380. I have an April 86 version of the TCP-IP Implementors Guide and there is no mention of Intel in there. I am not on either of these lists so please send replies directly to me. Please specify as much information as possible, i.e. cost, ordering information, system dependencies, etc. Many thanks, Henry Nussbacher ----MESSAGE-END---- ----MESSAGE-BEGIN---- [861016-135805-4966%40Xerox] <1986101612570800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: "Robert_S._Printis.osbunorth"@XEROX.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: Ultrix TCP/IP problems Message-ID: <861016-135805-4966@Xerox> Date: Thu, 16-Oct-86 16:57:08 EDT Article-I.D.: Xerox.861016-135805-4966 Posted: Thu Oct 16 16:57:08 1986 Date-Received: Fri, 17-Oct-86 20:57:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Looks like you have been bitten by the "illegal" Ethernet packet type that Berkelely used for the so-called "trailer" protocol. I believe that they confiscated the numbers that I assigned for "experimental" use and used them in a product. (At one time I assigned Ethernet host numbers) Anyone using the version on Unix that has the trailers feature will notice these packet types from time to time. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986101615432500> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Thu 16 Oct 86 03:24:34-PDT Received: from (MAILER)BARILVM.BITNET by WISCVM.WISC.EDU on 10/16/86 at 05:23:29 CDT Received: by BARILVM (Mailer X1.23b) id 5463; Thu, 16 Oct 86 12:22:24 O Date: Thu, 16 Oct 86 12:13:25 O From: Henry Nussbacher Subject: Looking for Tcp/Ip Implementations for Intel System 310/330/380 To: tcp-ip@sri-nic.arpa cc: info-xenix310@simtel20.arpa Reply-To: Henry Nussbacher I am looking for information about Tcp/Ip implementations for Intel 310, 330,380. I have an April 86 version of the TCP-IP Implementors Guide and there is no mention of Intel in there. I am not on either of these lists so please send replies directly to me. Please specify as much information as possible, i.e. cost, ordering information, system dependencies, etc. Many thanks, Henry Nussbacher ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610162345.AA28478%40lll-crg.ARPA] <1986101615453200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bandy@LLL-CRG.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Yes, this is real. This was as of noon PDT today Message-ID: <8610162345.AA28478@lll-crg.ARPA> Date: Thu, 16-Oct-86 19:45:32 EDT Article-I.D.: lll-crg.8610162345.AA28478 Posted: Thu Oct 16 19:45:32 1986 Date-Received: Fri, 17-Oct-86 21:01:01 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa ping seismo.css.gov 64 bytes from xc00c8d19: icmp_seq=1. time=180630. ms 64 bytes from xc00c8d19: icmp_seq=2. time=179690. ms 64 bytes from xc00c8d19: icmp_seq=5. time=176690. ms 64 bytes from xc00c8d19: icmp_seq=6. time=175690. ms ^? ----seismo.css.gov PING Statistics---- 16 packets transmitted, 4 packets received, 75% packet loss round-trip (ms) min/avg/max = 175690/178175/180630 Yow! Something is definitely messed up somewhere!!! andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610171533.AA26390%40csv.rpi.edu] <1986101707331200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@CSV.RPI.EDU (Martin Schoffstall) Newsgroups: mod.protocols.tcp-ip Subject: Root NameServers on the East Coast Message-ID: <8610171533.AA26390@csv.rpi.edu> Date: Fri, 17-Oct-86 11:33:12 EDT Article-I.D.: csv.8610171533.AA26390 Posted: Fri Oct 17 11:33:12 1986 Date-Received: Sat, 18-Oct-86 00:36:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa I don't know if that has been talked about before but given the current state of the Arpanet wouldn't it be rational to have a root server on the East Coast? marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610171903.AA19329%40Godot.Think.COM] <1986101711032200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nesheim@THINK.COM (Bill Nesheim) Newsgroups: mod.protocols.tcp-ip Subject: Re: Ultrix TCP/IP problems Message-ID: <8610171903.AA19329@Godot.Think.COM> Date: Fri, 17-Oct-86 15:03:22 EDT Article-I.D.: Godot.8610171903.AA19329 Posted: Fri Oct 17 15:03:22 1986 Date-Received: Sat, 18-Oct-86 00:52:48 EDT References: <861016-135805-4966@Xerox> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Note that REAL 4.3bsd unix will only use the trailer packet type if it is talking to another 4.3bsd machine: it now does trailer negotiation via ARP. In other words, your PC's won't ever see them. Bill Nesheim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610190224.AA16906%40topaz.rutgers.edu] <1986101818244600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hedrick@topaz.rutgers.edu (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: DECnet over IP? Message-ID: <8610190224.AA16906@topaz.rutgers.edu> Date: Sat, 18-Oct-86 22:24:46 EDT Article-I.D.: topaz.8610190224.AA16906 Posted: Sat Oct 18 22:24:46 1986 Date-Received: Sun, 19-Oct-86 04:14:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa We are in the process of building a campus network for Rutgers. For fairly obvious reasons (at least I hope they are obvious to readers of this group), it is primarily IP based. I am finding it an increasing pain in the neck to provide for VMS users who want us to support DECnet among their machines. I understand their desire, since VMS has DECnet very well integrated. But it seems nearly impossible to support DECnet in a gateway, even when the gateway has been built to support PUP, XNS, IP, Chaos, and every other conceivable protocol. Anyway, it strikes me that the obvious solution would be to run DECnet on top of IP. I can even think of a way to do it. But I don't have enough time at the moment to implement it. Has anybody done this? [The way I would do it is to write a device driver that pretended to be a multi-line synchronous line controller. Inside it, there would be a table that associated one IP address with each supposed synchronous line. The driver would simply stick the right IP header in front of each message and send it out the Ethernet interface. This sounds like something a competent VMS hacker could do in a week, though I've been involved in enough things like this to know how misleading that can be.] I would probably be willing to pay, if somebody would like to do it for us. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610200027.aa00914%40SEM.BRL.ARPA] <1986101920274600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ron@BRL.ARPA (Ron Natalie) Newsgroups: mod.protocols.tcp-ip Subject: Re: Root NameServers on the East Coast Message-ID: <8610200027.aa00914@SEM.BRL.ARPA> Date: Mon, 20-Oct-86 00:27:46 EDT Article-I.D.: SEM.8610200027.aa00914 Posted: Mon Oct 20 00:27:46 1986 Date-Received: Mon, 20-Oct-86 03:57:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa I was just at the DOMAIN server committee at the Internet Engineering Task Force at SRI last week. There will be nameservers appearing on both the EAST COAST and on MILNET very soon. -ROn ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610200558.AA07303%40ucbarpa.Berkeley.EDU] <1986101921585800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) Newsgroups: mod.protocols.tcp-ip Subject: summary? Message-ID: <8610200558.AA07303@ucbarpa.Berkeley.EDU> Date: Mon, 20-Oct-86 01:58:58 EDT Article-I.D.: ucbarpa.8610200558.AA07303 Posted: Mon Oct 20 01:58:58 1986 Date-Received: Mon, 20-Oct-86 04:57:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Now that the IETF meeting is over, how about some info from those who were there on the relevant issues (separately, of course) to these lists? Thanks. /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102001190000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Mon 20 Oct 86 09:19:20-PDT Date: 20 Oct 86 09:19:00 PST From: Subject: DECnet over IP To: "tcp-ip" Reply-To: You might want to talk with the folks at Wollongong. They have a package called 'D-Bridge' which allows TCP/IP packets to be "team submitted" via DECnet circuits. This combined with their shared Deuna option might be an interim solution. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610201931.AA01124%40ucbvax.Berkeley.EDU] <1986102009190000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: gary@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: DECnet over IP Message-ID: <8610201931.AA01124@ucbvax.Berkeley.EDU> Date: Mon, 20-Oct-86 13:19:00 EDT Article-I.D.: ucbvax.8610201931.AA01124 Posted: Mon Oct 20 13:19:00 1986 Date-Received: Mon, 20-Oct-86 21:43:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa You might want to talk with the folks at Wollongong. They have a package called 'D-Bridge' which allows TCP/IP packets to be "team submitted" via DECnet circuits. This combined with their shared Deuna option might be an interim solution. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610211105.AA18760%40ucbvax.Berkeley.EDU] <1986102013145600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ospwd@emory.CSNET (Peter Day {EUCC}) Newsgroups: mod.protocols.tcp-ip Subject: TELNET 3270 for PC/IP Message-ID: <8610211105.AA18760@ucbvax.Berkeley.EDU> Date: Mon, 20-Oct-86 17:14:56 EDT Article-I.D.: ucbvax.8610211105.AA18760 Posted: Mon Oct 20 17:14:56 1986 Date-Received: Wed, 22-Oct-86 03:48:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Keywords: telnet 3270 PCIP Approved: tcp-ip@sri-nic.arpa Does anyone know of an implementation of TCP/IP for the IBM-PC that has a TELNET with 3270 emulation? I am aware that the University of Maryland intends to add such a facility to the MIT PC/IP, but I am looking for something that would be available in the next (say) 4 months. Please reply directly to me. Thanks, Peter W. Day CSNET: ospwd@emory ARPA: ospwd%emory.csnet@csnet-relay.arpa UUCP: { akgua, gatech }!emoryu1!ospwd BITNET: ospwd@emoryu1 USPS: Computing Center, Emory University, Atlanta, GA 30322 PHONE: 404/727-7678 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102013145601> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Tue 21 Oct 86 01:41:04-PDT Received: from emory by csnet-relay.csnet id ad01014; 21 Oct 86 3:05 EDT Received: by emory.eu (5.51/5.7) id AA25852; Mon, 20 Oct 86 17:14:56 EDT Date: Mon, 20 Oct 86 17:14:56 EDT From: Peter Day {EUCC} Subject: TELNET 3270 for PC/IP Newsgroups: mod.protocols.tcp-ip To: tcp-ip@SRI-NIC.ARPA Keywords: telnet 3270 PCIP Does anyone know of an implementation of TCP/IP for the IBM-PC that has a TELNET with 3270 emulation? I am aware that the University of Maryland intends to add such a facility to the MIT PC/IP, but I am looking for something that would be available in the next (say) 4 months. Please reply directly to me. Thanks, Peter W. Day CSNET: ospwd@emory ARPA: ospwd%emory.csnet@csnet-relay.arpa UUCP: { akgua, gatech }!emoryu1!ospwd BITNET: ospwd@emoryu1 USPS: Computing Center, Emory University, Atlanta, GA 30322 PHONE: 404/727-7678 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610210339.AA22559@svax.cs.cornell.edu] <1986102019392000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: bromley@SVAX.CS.CORNELL.EDU (Mark Bromley) Newsgroups: mod.protocols.tcp-ip Subject: NFILE server BSD4.3?? Message-ID: <8610210339.AA22559@svax.cs.cornell.edu> Date: Mon, 20-Oct-86 23:39:20 EDT Article-I.D.: svax.8610210339.AA22559 Posted: Mon Oct 20 23:39:20 1986 Date-Received: Tue, 21-Oct-86 18:20:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Does anyone have an NFILE (the latest Symbolics file protocol) server for BSD 4.3? Thanks. Mark Bromley bromley@svax.cs.cornell.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102105420000> Received: from MARLBORO.DEC.COM by SRI-NIC.ARPA with TCP; Tue 21 Oct 86 06:42:03-PDT Date: 21 Oct 1986 0942-EDT From: Kevin Paetzold To: Bill Nesheim , "Robert_S._Printis.osbunorth"@xerox.com cc: BEAME%MCMASTER.BITNET@wiscvm.wisc.edu, tcp-ip@sri-nic.ARPA, nesheim@godot telephone: 617-460-2203 Subject: Re: Ultrix TCP/IP problems Message-ID: <"MS11(5206)+GLXLIB5(0)" 12248566025.19.126.4407 at MARLBORO.DEC.COM> References: Message from Bill Nesheim of 17-Oct-86 2125-EDT In-reply-to: <8610171903.AA19329@Godot.Think.COM> However 4.2 BSD would send trailer encapsulated packets to any other station unless it was disabled. TOPS-20 has a detecting mechanism for this where it will issue a BUGINF if it receives a trailer encapsulated packet (on any of the trailer encapsulated protocol types). The detecting mechanism is probably not a bad idea for other implementations until trailer encapsulated packets are not around anymore. -------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12248578606.66.JNC%40XX.LCS.MIT.EDU] <1986102106514900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: summary? Message-ID: <12248578606.66.JNC@XX.LCS.MIT.EDU> Date: Tue, 21-Oct-86 10:51:49 EDT Article-I.D.: XX.12248578606.66.JNC Posted: Tue Oct 21 10:51:49 1986 Date-Received: Wed, 22-Oct-86 06:11:58 EDT References: <8610200558.AA07303@ucbarpa.Berkeley.EDU> Sender: root@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 105 Approved: tcp-ip@sri-nic.arpa Here's a brief summary, but remember that these are my personal memories, and are not official and may contain errors. I also hope I'm not offending anyone by writing this up before the official scribe gets to it; if so I apologise. There were three main topics of discussion; ISO transition, Domain Name transition, and EGP. These were discussed in the three separate workshops; I can report on the last in detail, but did not attend the first two. I will give my understanding of what happened in the first two, but it may contain errors. We also heard a report of the state of the ARPANet, but it doesn't contain much that hasn't already been posted to TCP-IP. The ISO transition scheme is looking at ways to start introducing ISO traffic into the system. As I understand it, the general theory is that they will upgrade the routers (IP gateways) to handle ISOgrams as well as IPgrams and run the two protocols side by side; there are also plans for service-level protocol converting gateways for things as mail. There is also an extant spec for using Dod IP addresses in ISOgrams (the ISO addressing architecture is pretty kitchen sink style, and why assign new numbers when we already have perfectly good numbers). The Domain Name transition is coming along pretty well. There are several steps seen as needing to happen; the last non-domain style names need to be flushed from HOSTS.TXT, and the MILNET needs to transition toward use of domain names (at the moment they all use HOSTS.TXT, and if you send mail from a host which is not in HOSTS.TXT to the MILNET they can't reply). Once everyone is using the domain system we can flush HOSTS.TXT. Some issues which were discussed were the need to provide more root servers on the East coast and also root servers on MILNET (to keep the security concious people happy). Also, it is proving difficult for the NIC to build a tree walker that automatically constructs HOSTS.TXT by walking the name tree since lots of people don't support zone transfer. As far as EGP goes, discussion centered around two main topics. One was that the updates are nearing overflow; the entire routing table is sent in a single packet, and as the net gets larger that will overflow. The other was that the current topology restrictions in EGP (you aren't suuposed to have Autonomous Systems in cycles (loops), or more than one AS away from the Core) are crippling. The first was solved by designing an update mechanism where the table is sent slowly, in smaller packets spead out evenly. This has the added advantage of not causing a big processing disturbance when you get this massive table that you have to parse. Everyone who reviewed this thought that it was a good mechanism, and it is close enough to existing algorithms and solving a sufficently simple problem that it was felt that it could be implemented with the assurance that it will work. The problem is that the people who were studying the cycle problem decided that to really fix that right, they needed to switch to a different routing algorithm, which would demand entirely different data in the updates. However, that is a sufficiently complex problem (and algorithm) that it was felt that extensive review, analysis and simulation were needed before the solution was felt to be solid. Such an effort would consume some months, and was thus not amenable to doing on the spot in the committee. This presented a problem, and caused a heated discussion. It was argued that the cycle restrictions were so onerous, that as soon as a solution had been designed it should be implemented right away. The timeframe for that was felt to be a year or two (allowing for design, review, simulation to prove correct functioning, implementation and deplyment). It was further argued that the update size restriction is not that onerous; the updates would not be larger than the MTU of most nets (e.g. ARPANet) for at least a year, and even after that they could be handled by use of IP fragmentation. That being the case, it was felt that diverting effort into an intermediate standard that did not solve the most pressing problem was not a wise move. It was counterargued that if the new design effort failed, we would have failed to solve the one problem we did agree on a solution for, and it would be too late at that point to attempt a crash deployment (due to release schedules, etc). The following compromise was sort of agreed on, after much blood over the transom. A spec will be written for the interim EGP; this will be an official IP spec. BBN will move to get it in the next core gateway release. However, the older version of EGP will be continue to be supported, and it will not be mandatory to implement the new version. In addition, a small number of mandatory upward compatible changes to the existing spec were agreed on to a) make version numbers useful, and b) allow version negotiation. These will all be available for comment in an RFC, to be followed by changes to the EGP RFC. At the same time, a group of interested parties will start work on the followon protocol (FGP), with a target of 6 months to a year to begin deploying it. The proposal will be available for review, but will not be an official spec. Should it prove good enough, it may be adopted as a spec, but that is not guaranteed. Should it be adopted, it would not be necessary to implement the interim standard; users could skip straight from the old one to the new one. This group is private, but will make every effort to consult people on requirements as well as to get reviews of the design. FGP will retain the basic EGP model; groups of gateways called TAS's (transit autonomous systems) will be hooked via FGP, but can run any protocol of their own devising between themselves. The FGP routing algorithm will be based on the existing SPF algorithm done by BBN for the IMPs, and will provide support for cycles, and if possible, TOS and multi-path routing. A means was devised to phase it in gradually; groups of TAS's running it will appear as a single AS using the existing EGP, and will need to be hooked directly to the existing Core. However, within the limits of that AS (which might eventually expand to contain most of the Internet) the new rules will apply. As far as my memory goes, that was about it, although I will admit that I was mostly preoccupied with the EGP thing. I may have missed other topics; if so, would knowledgeable people please comment? Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102114120000> Received: from wharton-10.ARPA by SRI-NIC.ARPA with TCP; Tue 21 Oct 86 15:14:49-PDT Date: 21 Oct 86 18:12:00 EDT From: "G. B. Reilly" Subject: Anyone have ULTRIX v1.2 talking to a PSN using ACC 6250 To: "tcp-ip" Reply-To: "G. B. Reilly" using X.25 BASIC service? ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610220010.AA04063%40BORAX.LCS.MIT.EDU] <1986102115100600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen) Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP on 802.3 now??? Message-ID: <8610220010.AA04063@BORAX.LCS.MIT.EDU> Date: Tue, 21-Oct-86 20:10:06 EST Article-I.D.: BORAX.8610220010.AA04063 Posted: Tue Oct 21 20:10:06 1986 Date-Received: Tue, 28-Oct-86 23:22:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa A week ago, I encountered a strange situation: A contact informed me that his Gould MPX-32 needed to know our Ethernet address (in its host table) in order to communicate; How did he set the corresponding info in our host table? Further investigation revealed that the Gould product has a mode where it sends IP packets using 802.3 packet formats, without ARP. Luckily for us, this mode can be changed back to what they call Ethernet 1.0 by re-strapping the board and changing a configuration command in the startup file. The Gould support people say that the transceiver also has to be replaced (did some lines in the cable actually get re-defined?), but experiment indicates this isn't necessary, at least on a small Ether. Of course, I was mildly amazed to see anyone actually going this far in honor of the guy from the corporate standards committee with the clipboard and the checklist, but I've seen sillier... Posting this primarily to inform the world that the swamp has gained a new kind of mud. jbvb@ai.ai.mit.edu FTP Software Inc. (617) 864-1711 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102200440000> Mail-From: STJOHNS created at 22-Oct-86 07:47:32 Date: 22 Oct 1986 07:44-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: DDN X.25 From: STJOHNS@SRI-NIC.ARPA To: $jch%clvm.bitnet%violet.berkeley.edu@UCBVAX.BERKELEY.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]22-Oct-86 07:44:36.STJOHNS> In-Reply-To: <8610142350.AA26988@jade.Berkeley.Edu> Who informed you that PSN 6 doesn't work? How doesn't it work? *sigh* PSN 6 had some minor bugs with X.25 when it came up, but as far as I know patches to fix all of them have been fielded. There is no such thing as PSN release 6.1. The next release of the PSN software is PSN 7 which is due out the first quarter of next year. Mike StJohns, DDN PMO ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610290125.AA05604%40ucbvax.berkeley.edu] <1986102206115300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cassel@DEWEY.UDEL.EDU (Boots Cassel) Newsgroups: mod.protocols.tcp-ip Subject: network monitors Message-ID: <8610290125.AA05604@ucbvax.berkeley.edu> Date: Wed, 22-Oct-86 11:11:53 EST Article-I.D.: ucbvax.8610290125.AA05604 Posted: Wed Oct 22 11:11:53 1986 Date-Received: Wed, 29-Oct-86 02:48:06 EST Sender: jordan@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa I am interested in information about and experiences with network monitors and measurement devices. I am aware of the following products. If any one knows of others I should know about, or has comments on these, I would be grateful. Commercial Products: Exelan Nutcracker and LANalyzer CMC LANscan HP LAN Protocol Analyzer Research work: ILMON by Lewis Barnett Mondow by Mike Minnich at Delaware The ONR Measurement Center at Delaware Feldmeier's work at MIT Pointers would be appreciated. I will share the information with others if there is interest. Boots Cassel cassel@dewey.udel.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102207115300> Received: from Dewey.UDEL.EDU by SRI-NIC.ARPA with TCP; Wed 22 Oct 86 08:35:52-PDT Date: Wed, 22 Oct 86 11:11:53 EDT From: Boots Cassel To: tcp-ip@dewey.udel.EDU cc: cassel@dewey.udel.EDU Subject: network monitors I am interested in information about and experiences with network monitors and measurement devices. I am aware of the following products. If any one knows of others I should know about, or has comments on these, I would be grateful. Commercial Products: Exelan Nutcracker and LANalyzer CMC LANscan HP LAN Protocol Analyzer Research work: ILMON by Lewis Barnett Mondow by Mike Minnich at Delaware The ONR Measurement Center at Delaware Feldmeier's work at MIT Pointers would be appreciated. I will share the information with others if there is interest. Boots Cassel cassel@dewey.udel.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102210145400> Received: from monet.Berkeley.EDU ([128.32.130.6]) by SRI-NIC.ARPA with TCP; Wed 22 Oct 86 17:13:52-PDT Received: by monet.Berkeley.EDU (5.53/1.17) id AA04440; Wed, 22 Oct 86 17:14:58 PDT From: karels@monet.Berkeley.EDU (Mike Karels) Message-Id: <8610230014.AA04440@monet.Berkeley.EDU> To: tcp-ip@sri-nic.arpa Cc: 4bsd-bugs@ucbarpa.Berkeley.EDU, net-bugs-4bsd@ucbvax.Berkeley.EDU Subject: 4.3BSD network bug (#1, tcp_output) Date: Wed, 22 Oct 86 17:14:54 PDT Index: sys/netinet/tcp_output.c 4.3BSD FIX This is the first of a set of three bug reports with fixes for the network in 4.3BSD. All 4.3 sites should install the modifications described in these reports. The bug described in this report is the most serious, as it can cause unnoticed loss of data. Description: The final change in the send code in TCP in 4.3 was made incorrectly. In tcp_output (/sys/netinet/tcp_output.c), the output packet flags are chosen before the packet length is adjusted to reflect the maximum segment size. Under some cirsumstances, this results in sending a FIN with a packet which is not the last data packet. This is most often noticed when the connection implements a one-way transfer of data and the sender closes while the data is still draining. Fix: Move the lines in tcp_output that look up the flags to be sent to a location after the final length adjustment, as follows: *** /nbsd/sys/netinet/tcp_output.c Thu Jun 5 00:31:36 1986 --- tcp_output.c Wed Aug 20 09:31:34 1986 *************** *** 5,7 **** * ! * @(#)tcp_output.c 7.1 (Berkeley) 6/5/86 */ --- 5,7 ---- * ! * @(#)tcp_output.c 7.2 (Berkeley) 8/20/86 */ *************** *** 82,85 **** flags = tcp_outflags[tp->t_state]; - if (SEQ_LT(tp->snd_nxt + len, tp->snd_una + so->so_snd.sb_cc)) - flags &= ~TH_FIN; --- 82,83 ---- *************** *** 118,119 **** --- 116,119 ---- } + if (SEQ_LT(tp->snd_nxt + len, tp->snd_una + so->so_snd.sb_cc)) + flags &= ~TH_FIN; win = sbspace(&so->so_rcv); ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102210174800> Received: from monet.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed 22 Oct 86 17:16:49-PDT Received: by monet.Berkeley.EDU (5.53/1.17) id AA04477; Wed, 22 Oct 86 17:17:50 PDT From: karels@monet.Berkeley.EDU (Mike Karels) Message-Id: <8610230017.AA04477@monet.Berkeley.EDU> To: tcp-ip@sri-nic.arpa Cc: 4bsd-bugs@ucbarpa.Berkeley.EDU, net-bugs-4bsd@ucbvax.Berkeley.EDU Subject: 4.3BSD network bug (#3, MCLGET/mbuf.h) Date: Wed, 22 Oct 86 17:17:48 PDT Index: sys/h/mbuf.h 4.3BSD FIX This is the last of a set of 3 bug reports with fixes for the network in 4.3BSD. All 4.3 sites should install the modifications described in these reports. Although rare, the bug described in this report may cause unexplained crashes or random failures. Description: The macros for addition of page clusters to mbufs were revised in 4.3BSD. A new macro, MCLGET, is called to add a single page cluster to an mbuf. If there are no free clusters, the macro calls m_clalloc to attempt to create a new cluster. Unfortunately, the MCLGET macro does not run at high priority, but m_clalloc may only be called from splimp to block reentrance of the memory allocation routines. The call to m_clalloc should be made from MCLALLOC, which does run at high priority. Fix: In the file /sys/h/mbuf.h, move the test of mclfree and call to m_clalloc from the MCLGET macro to the MCLALLOC macro, as shown by the following diffs: *** mbuf.h.old Thu Sep 11 06:07:29 1986 --- mbuf.h Thu Sep 11 06:20:07 1986 *************** *** 5,7 **** * ! * @(#)mbuf.h 7.1 (Berkeley) 6/4/86 */ --- 5,7 ---- * ! * @(#)mbuf.h 7.3 (Berkeley) 9/11/86 */ *************** *** 97,98 **** --- 97,100 ---- { int ms = splimp(); \ + if (mclfree == 0) \ + (void)m_clalloc((i), MPG_CLUSTERS, M_DONTWAIT); \ if ((m)=mclfree) \ *************** *** 105,108 **** { struct mbuf *p; \ - if (mclfree == 0) \ - (void)m_clalloc(1, MPG_CLUSTERS, M_DONTWAIT); \ MCLALLOC(p, 1); \ --- 107,108 ---- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102306110000> Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Thu 23 Oct 86 07:50:27-PDT Date: Thu, 23 Oct 86 10:11 EDT From: WIBR@MIT-MULTICS.ARPA Subject: Mailing List To: tcp-ip@SRI-NIC.ARPA Message-ID: <861023141126.429061@MIT-MULTICS.ARPA> Please remove WIBR from your tcp-ip relay list. Thank you. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610232131.AA02072%40ogle.sunuk.uucp] <1986102312311000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kluger@ogle.UUCP (Larry Kluger Sun Europe) Newsgroups: mod.protocols.tcp-ip Subject: CCITT G703 interface Message-ID: <8610232131.AA02072@ogle.sunuk.uucp> Date: Thu, 23-Oct-86 17:31:10 EST Article-I.D.: ogle.8610232131.AA02072 Posted: Thu Oct 23 17:31:10 1986 Date-Received: Wed, 29-Oct-86 08:50:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Hi, I want to link two Ethernets for IP connectivity that are about 15 km (~10 miles) apart in West Germany. The West German PTT is offering a CCITT G703 link between the two sites. The interface is at 2 Mbps. Do you know of an IP router or MAC level bridge that has a G703 interface? Information or pointers would be appreciated. Thanks, Larry Kluger Sun Microsystems Europe lkluger@sun.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102623534600> Mail-From: VIVIAN created at 3-Nov-86 00:42:40 Received: from LOKI.BBN.COM by SRI-NIC.ARPA with TCP; Mon 27 Oct 86 05:12:31-PST To: tcp-ip@sri-nic.arpa Subject: Setting Initial Round-trip time Date: Mon, 27 Oct 86 08:13:46 -0500 From: Craig Partridge I'm working on an implementation of RDP and am trying to find ways to improve the round-trip time estimates. The timeout algorithm is the same as TCP's with the values suggested in RFC 889, but I've noticed that choosing the wrong initial value for the estimated round trip time can have a severe impact on throughput if the total number of packets is relatively small and the link is lossy. I'd like to improve that performance by choosing better initial values. This isn't something I know very much about so I'm soliciting advice. How do other people choose the initial value to put into the round trip estimate equations? What mechanisms do you recommend or strongly discourage or disparage? Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610290632.AA05428%40topaz.rutgers.edu] <1986102820322000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: network monitors Message-ID: <8610290632.AA05428@topaz.rutgers.edu> Date: Wed, 29-Oct-86 01:32:20 EST Article-I.D.: topaz.8610290632.AA05428 Posted: Wed Oct 29 01:32:20 1986 Date-Received: Tue, 4-Nov-86 05:01:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa We find the most generally useful network monitor to be a Sun. Traffic is good for general watching, and etherfind for looking at individual packets. For many purposes an IBM PC with the MIT public-domain netwatch is quite useful. It just shows you packets, with some limited ability to select based on source, dest, etc. We understand that the HP Ethernet monitor will be really great when the next software release comes out, but for the moment it's useful only when you really want to look at the bits (and want to make sure you aren't dropping any packets in a high-speed network). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610241315.AA19273%40mitre.ARPA] <1986102904355800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: mod.protocols.tcp-ip Subject: Secure LAN File Server Message-ID: <8610241315.AA19273@mitre.ARPA> Date: Wed, 29-Oct-86 09:35:58 EST Article-I.D.: mitre.8610241315.AA19273 Posted: Wed Oct 29 09:35:58 1986 Date-Received: Wed, 29-Oct-86 22:16:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 22 Approved: tcp-ip@sri-nic.arpa From the October, 1986 issue of SIGNAL: ---------------------------------------- The National Security Agency (NSA) has signed a Memorandum of Understanding to acquire a Secure LAN File Server that will provide high grade encryption support for a variety of file storage devices. The secure file server, being developed by Simpact Associates, Inc., as part of its participation in NSA's Commercial COMSEC Endorsement Program, will allow users with classified applications to file data on conventional storage devices. Because the information is encrypted before it is stored, the storage device does not have to be Tempest treated, and users need not remove the medium and store it in a secure safe when it is not in use. Elimination of these restrictions allows users to configure their systems from a wide range of commercially available, high performance, high density file storage devices. Future related products, when used with a computer that has an accredited secure operating system, will provide multilevel file security. The first of this new family of file servers will address the government's large installed base of Wang Laboratories, Inc., computers. Deliveries are scheduled to start in late 1987. Commercial availability of the Secure LAN File Server is contingent on final NSA endorsement. ---------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610241824.AA22489%40mitre.ARPA] <1986102908093200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: mod.protocols.tcp-ip Subject: Re: The NIC and FTPing host tables Message-ID: <8610241824.AA22489@mitre.ARPA> Date: Wed, 29-Oct-86 13:09:32 EST Article-I.D.: mitre.8610241824.AA22489 Posted: Wed Oct 29 13:09:32 1986 Date-Received: Thu, 30-Oct-86 06:44:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 38 Approved: tcp-ip@sri-nic.arpa Bob Knight Back on 25 Feb 86 you noted a large FTP load when new host tables were released. The responses seemed to concentrate on what might be done with the host tables. A more fundamental issue is the behavior of FTP servers. I suggest that network performance would be improved if FTP were revised as follows: 1. FTP should reject a request for a non-local transfer if "M" incomming or "N" outgoing jobs are already in progress. Rationale: When you permit many concurrent FTP jobs long connection times are necessary and everyone gets slow service. Long connection times increase the probability that equipment failure or a transitory glitch will cause the connection to be aborted. In the absence of a restart marker the user will have to start from the beginning of the file. I estimate that sites with a single 56 Kbps PSN circuit should limit concurrent FTP jobs to two incomming and two outgoing. Once rejected, what's a user to do, sit around and harass the FTP server? I suggest: 2. The FTP rejection message should allow the user to queue the request for later execution. Rationale: FTP jobs are not urgent. So long as the user knows the job will eventually be completed, it doesn't matter if it takes several hours. Clark, Mills, and Nagle, among others, have offered good advice on techniques to improve the performance of TCP and avoid network congestion. The unstated, perhaps obvious, objective follows from Queuing Theory: Never drive any path through the network at more than 70% of capacity. Being able to reject a request will smooth the FTP load and should improve network throughput. Being able to queue jobs will maintain the operational utility of FTP. H. Craig McKee ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610292012.AA20495%40ucbvax.berkeley.edu] <1986102913041700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@loki.bbn.com (Craig Partridge) Newsgroups: mod.protocols.tcp-ip Subject: Setting Initial Round-trip time Message-ID: <8610292012.AA20495@ucbvax.berkeley.edu> Date: Wed, 29-Oct-86 18:04:17 EST Article-I.D.: ucbvax.8610292012.AA20495 Posted: Wed Oct 29 18:04:17 1986 Date-Received: Thu, 30-Oct-86 06:26:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa I'm working on an implementation of RDP and am trying to find ways to improve the round-trip time estimates. The timeout algorithm is the same as TCP's with the values suggested in RFC 889, but I've noticed that choosing the wrong initial value for the estimated round trip time can have a severe impact on throughput if the total number of packets is relatively small and the link is lossy. I'd like to improve that performance by choosing better initial values. This isn't something I know very much about so I'm soliciting advice. How do other people choose the initial value to put into the round trip estimate equations? What mechanisms do you recommend or strongly discourage or disparage? Craig Partridge CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986102913420000> Mail-From: VIVIAN created at 3-Nov-86 01:03:05 Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 29 Oct 86 15:43:05-PST Date: 29 Oct 1986 18:42-EST Sender: CERF@A.ISI.EDU Subject: IP on DECNET From: CERF@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]29-Oct-86 18:42:03.CERF> I probed and got the following back: Date: Wed Oct 29, 1986 2:17 pm EDT Subject: DECNET over IP Vint, the following (included) message came as a response from a software specialist in another district through a rather contorted chain of mail messages. This kind of an architectural mish-mash would be kind of strange. However, you could do it. To make sense, the IP layer would have to function in the same capacity as X.25 in DNA. There would have to be DLM (Data Link Mapping) code added in DECnet-VAX to support DECnet circuits providel cy this new IP service. I can't think of any other way to do it. Even so the DLM would have to be more intelligent than the one currently implemented for X.25 since X.25 provides a connection- oriented service and IP does not. DNA is of course Digital Network Architecture. Most people seemed to think it would take a lot longer than a week! I wonder if this will get any easier as Digital migrates DNA to OSI.... (I don't know anything about IP!) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610301807.AA06703%40ucbvax.berkeley.edu] <1986103004360200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ahill@CC7.BBN.COM ("Alan R. Hill") Newsgroups: mod.protocols.tcp-ip Subject: re: X.25 Standard service on ARPANET Message-ID: <8610301807.AA06703@ucbvax.berkeley.edu> Date: Thu, 30-Oct-86 09:36:02 EST Article-I.D.: ucbvax.8610301807.AA06703 Posted: Thu Oct 30 09:36:02 1986 Date-Received: Fri, 31-Oct-86 02:06:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa There are hosts on the ARPANET that have successfully interchanged TCP/IP data between X.25 sources and 1822 destinations. The hosts that I am aware of use ACC interfaces. Initial attempts to communicate failed because the hosts were not enabled to cross host access control boundaries established in the subnet. This was corrected earlier this week and tests following the change were considered sucessful. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [861030130016.1.JAMES%40GREEN-GRASS.LCS.MIT.EDU] <1986103008000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: james@ZERMATT.LCS.MIT.EDU ("James William O'Toole, Jr.") Newsgroups: mod.protocols.tcp-ip Subject: Re: Setting Initial Round-trip time Message-ID: <861030130016.1.JAMES@GREEN-GRASS.LCS.MIT.EDU> Date: Thu, 30-Oct-86 13:00:00 EST Article-I.D.: GREEN-GR.861030130016.1.JAMES Posted: Thu Oct 30 13:00:00 1986 Date-Received: Fri, 31-Oct-86 02:12:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Date: 30 Oct 1986 04:24-EST From: CERF@A.ISI.EDU Subject: Re: Setting Initial Round-trip time A background process might try to gather data - but this would by like pinging everyone just in case you might want to talk with them - leads to predictable disaster. A background process could more easily maintain a cache of round trip time data measured from recent traffic. Connections from a given host are probably concentrated on certain destinations, so you ought to be able to do much better than pinging. Of course, you still need to know which measurements to take and how to use them. Mean and variance of round trip time on a per host basis, with recent data more heavily weighted, perhaps? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610301944.AA00735%40sluggo.wseng.sun.com.com] <1986103009445700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM (Bill Melohn) Newsgroups: mod.protocols.tcp-ip Subject: re: X.25 Standard service on ARPANET Message-ID: <8610301944.AA00735@sluggo.wseng.sun.com.com> Date: Thu, 30-Oct-86 14:44:57 EST Article-I.D.: sluggo.8610301944.AA00735 Posted: Thu Oct 30 14:44:57 1986 Date-Received: Fri, 31-Oct-86 03:32:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa There is another implementation that I am aware of that is doing Standard Services X.25 to an ARPAnet IMP (oops, PSN). It too talks successfully with other 1822 systems, and does NOT use an ACC board. Sun has announced DDN support (including X.25 Standard and Basic) as a product, so "contact your local Sun sales rep for more information." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610302111.AA04782%40braden.isi.edu] <1986103011110900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@isi.edu (Bob Braden) Newsgroups: mod.protocols.tcp-ip Subject: Re: Setting Initial Round-trip time Message-ID: <8610302111.AA04782@braden.isi.edu> Date: Thu, 30-Oct-86 16:11:09 EST Article-I.D.: braden.8610302111.AA04782 Posted: Thu Oct 30 16:11:09 1986 Date-Received: Fri, 31-Oct-86 13:28:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa Members of the END2END taskforce have also been worrying about your problem (setting an initial round-trip time). It is an important (but not usually critical) problem for connection-oriented protocols like TCP and RDP; it is more important and more difficult for a transaction- oriented transport protocol of the sort we have been stalking. As Vint says, a background process to gather data is a VERY bad idea. Nor do I think the hop count is at all useful as a predictor. However, it may not be a bad idea to maintain a cache of historical data about observed round trip times to hosts you have talked to recently. This may help in the case of a small "working set" of hosts you talk to. In the opposite case ... short transfers to a very large collection of randomly chosen hosts -- the answer may very well be that you cannot reasonably expect very good performance when nets are lossy, and should not waste time trying to obtain the impossible. And at system startup, before there is any historical data, you cannot do very well. Someone needs to think a little about the right way to maintain such a cache of historical RTT's per host, with respect to the way you maintain it (considering dispersion of observations), and how you use the data. Someone is going to say "You have to ask the gateways". Well, maybe, but that would seem to come some time after we are able to provide effective type-of-service routing over widely-diverse paths. Or maybe at the same time? Still, it wouldn't hurt for us to pose this requirement (an ICMP message from a host inquiring about the probable delays to a given Internet host) to Dave Mills' INARCH task force, and see what they can come up with. This requirement seems to go deep into the overall routing architecture of the Internet. Finally, our Internet Architect has a simple answer to your problem: don't use RDP, use NETBLT. NETBLT shares the principal advantages of RDP (packet-orientation and selective retransmission), but uses a different use of timers so that the RTT is not important. Of course, NETBLT has its own set of hard timer problems... Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12251035116.41.OLE%40SRI-NIC.ARPA] <1986103013455000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen) Newsgroups: mod.protocols.tcp-ip Subject: RFC Sets Message-ID: <12251035116.41.OLE@SRI-NIC.ARPA> Date: Thu, 30-Oct-86 18:45:50 EST Article-I.D.: SRI-NIC.12251035116.41.OLE Posted: Thu Oct 30 18:45:50 1986 Date-Received: Fri, 31-Oct-86 14:31:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 140 Approved: tcp-ip@sri-nic.arpa Hi, Many people have asked for a set of "most useful RFCs", so we have put together the following RFC sets, organized by topic. Please feel free to suggest changes to this list. RFCs which are marked with an asterisk (*) are NOT included in the 1985 DDN Protocol Handbook. MAJOR RFCs RFC-791 Internet Protocol (IP) RFC-792 Internet Control Message Protocol (ICMP) RFC-793 Transmission Control Protocol (TCP) RFC-768 User Datagram Protocol (UDP) RFC-854 Telnet Protocol (see also many Telnet Options in the RFC index) RFC-959 File Transfer Protocol (FTP) RFC-821 Simple Mail Transfer Protocol (SMTP) RFC-822 Standard for the Format of ARPA Internet Text Messages RFC-960 Assigned Numbers RFC-961 Official ARPA Internet Protocols MAIL RFCs RFC-821 Simple Mail Transfer Protocol (SMTP) RFC-822 Standard for the Format of ARPA Internet Text Messages RFC-886 * Proposed Standard for Message Header Munging RFC-915 * Network Mail Path Services RFC-934 * Proposed Standard for Message Encapsulation RFC-937 Post Office Protocol Version 2 RFC-974 * Mail Routing and the Domain System RFC-976 * UUCP Mail Interchange Format Standard RFC-987 * Mapping between X.400 and RFC 822 NAMING AND DOMAIN RFCs RFC-799 Internet Name Domains RFC-819 * Domain Naming Convention for Internet User Applications RFC-882 * Domain Names - Concepts and Facilities RFC-883 Domain Names - Implementation Specification RFC-920 * Domain Requirements RFC-921 * Domain Name System Implementation Schedule - Revised RFC-973 * Domain System Changes and Observations RFC-974 * Mail Routing and the Domain System RFC-952 Internet Host Table Specification RFC-953 Hostnames Server GATEWAY RFCs RFC-792 Internet Control Message Protocol (ICMP) RFC-823 The DARPA Internet Gateway (GGP) RFC-890 * Exterior Gateway Protocol Implementation Schedule RFC-904 Exterior Gateway Protocol Formal Specification (EGP) RFC-911 * EGP Gateway under Berkeley UNIX 4.2 RFC-975 * Autonomous Confederations RFC-985 * Requirements for Internet Gateways -- Draft LOCAL AREA and SUBNET RFCs RFC-894 A Standard for the Transmission of IP Datagrams over Ethernet Networks RFC-895 Standard for the Transmission of IP Datagrams over Experimental Ethernet Networks RFC-948 Two Methods for the Transmission of IP Datagrams over IEEE 802.3 Networks RFC-826 An Ethernet Address Resolution Protocol RFC-903 A Reverse Address Resolution Protocol RFC-925 * Multi-LAN Address Resolution Protocol RFC-917 * Internet Subnets RFC-940 * Toward an Internet Standard Scheme for Subnetting RFC-950 * Internet Standard Subnetting Procedure RFC-919 * Broadcasting Internet Datagrams RFC-922 * Broadcasting Internet Datagrams in the Presence of Subnets RFC-947 * Multi-network Broadcasting within the Internet RFC-966 * Host Groups: A Multicast Extension to the Internet Protocol RFC-988 * Host Extensions for IP Multicasting BACKGROUND RFCs IEN-48 The Catenet Model for Internetworking RFC-896 * Congestion Control in IP/TCP RFC-970 * On Packet Switches with Infinite Storage RFC-813 Window and Acknowledgement Strategy in TCP RFC-814 Name, Addresses, Ports, and Routes RFC-815 IP Datagram Reassembly Algorithms RFC-816 Fault Isolation and Recovery RFC-817 Modularity and Efficiency in Protocol Implementation RFC-871 * A Perspective on the ARPANET Reference Model RFC-872 * TCP-ON-A-LAN RFC-873 * The Illusion of Vendor Support RFC-874 * A Critique of X.25 RFC-980 * Protocol Documentation Order Information TOWARDS INTERNATIONAL STANDARDS RFC-905 * ISO Transport Protocol Specification RFC-942 * Transport Protocols for Department of Defense Data Networks RFC-939 * Executive Summary of the NRC Report on Transport Protocols for Department of Defense Data Networks RFC-945 * DoD Statement on the NRC Report RFC-983 * ISO Transport Services on Top of the TCP RFC-941 * Addendum to the Network Service Definition Covering Network Layer Addressing RFC-987 * Mapping between X.400 and RFC 822 RFC-926 * Protocol for Providing the Connectionless-Mode Network Services All RFCs are of course available via anonymous FTP from SRI-NIC.ARPA in the RFC: directory or you may contact us at: DDN Network Information Center SRI International, Room EJ291 333 Ravenswood Avenue Menlo Park, CA 94025 (800) 235-3155 or (415) 859-3695 NIC@SRI-NIC.ARPA Cheers, Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610310055.AA01124%40beno.CSS.GOV] <1986103014555200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: mod.protocols.tcp-ip Subject: Poor performance related to egp? Message-ID: <8610310055.AA01124@beno.CSS.GOV> Date: Thu, 30-Oct-86 19:55:52 EST Article-I.D.: beno.8610310055.AA01124 Posted: Thu Oct 30 19:55:52 1986 Date-Received: Fri, 31-Oct-86 14:49:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa I can't help but wonder if the poor internet performance is related to the HORRIBLE routes that egp says to use. I have seen improvements in round trip icmp echo times of 1000% by ignoring the route egp says to use and manually forcing a route into the system. In many cases, it is the difference between connecting at all and timing out. Todays horrible case has been routing to 128.96 (bellcore.com) through lbl-milnet-gw instead of the rational relay.cs.net. Other horrible routes have included rutgers through purdue instead of the direct rutgers arpanet host. Are the egp routes supposed to be reasonable? I'm not that familiar with the theory behind them, but in practice, the suck badly. When I can get a 10 to 1 performance improvement by hard coding specific routes to override egp, I wonder if this is part of the internet congestion problem. It seems like a major performance gain for everyone could be realized by having the egp core systems advertise rational routes. ---rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986103021520000> Mail-From: STJOHNS created at 31-Oct-86 05:53:38 Date: 31 Oct 1986 05:52-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Setting Initial Round-trip time From: STJOHNS@SRI-NIC.ARPA To: braden@VENERA.ISI.EDU Cc: craig@LOKI.BBN.COM, cerf@A.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]31-Oct-86 05:52:47.STJOHNS> In-Reply-To: <8610302111.AA04782@braden.isi.edu> Of course our Internet Architect who recommended NETBLT happens to be one of its authors. Hmmm.... Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986103101165500> Received: from braden.isi.edu by SRI-NIC.ARPA with TCP; Fri 31 Oct 86 09:23:47-PST Date: Fri, 31 Oct 86 09:16:55 PST From: Bob Braden Posted-Date: Fri, 31 Oct 86 09:16:55 PST Message-Id: <8610311716.AA00139@braden.isi.edu> Received: by braden.isi.edu (5.54/5.51) id AA00139; Fri, 31 Oct 86 09:16:55 PST To: CERF@a.isi.edu Subject: Re: Setting Initial Round-trip time Cc: braden@isi.edu, tcp-ip@sri-nic.arpa The problem with the cache is that a) you don't know if the values correspond to the routes your traffic is/will take. b) you may not have enough traffic to enough destinations to maintain statistically valid (fresh) delay information. It may be possible that things will be static enough that cache will actually work well most of the time, but if the internet exhibits significant statistical variation in delay/throughput, the cache may be not only misleading but downright harmful. Vint, Everything you say is true, but I fail to see how bad cache information will be more harmful than no information at all. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610301601.AA05796%40mitre.ARPA] <1986103101534900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: mod.protocols.tcp-ip Subject: Re: Setting Initial Round-trip time Message-ID: <8610301601.AA05796@mitre.ARPA> Date: Fri, 31-Oct-86 06:53:49 EST Article-I.D.: mitre.8610301601.AA05796 Posted: Fri Oct 31 06:53:49 1986 Date-Received: Sat, 1-Nov-86 03:12:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 10 Approved: tcp-ip@sri-nic.arpa You noted that the number of packets was small and the link was lossy. Is the link lossy because of congestion or because of noise? If the former (congestion) then the advice of John Nagle (RFC 896) is relevant. If the latter (noise) then more complex measures are needed; for example, a Session/Presentation layer Forward Error Correction procedure. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1575748%40UMich-MTS.Mailnet] <1986103104005200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Hans-Werner_Braun@UMich-MTS.MAILNET Newsgroups: mod.protocols.tcp-ip Subject: re: X.25 Standard service on ARPANET Message-ID: <1575748@UMich-MTS.Mailnet> Date: Fri, 31-Oct-86 09:00:52 EST Article-I.D.: UMich-MT.1575748 Posted: Fri Oct 31 09:00:52 1986 Date-Received: Sat, 1-Nov-86 04:56:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Yes, one of them is the operational gateway between the NSFnet and the Arpanet, because of which I had asked the question in the first place. Packets between the NSfnet and the Arpanet are now flowing in a more operational sense than before, even though there are some (non-IMP related) problems left, i.e., the IMP at PSC/CMU gets only the outgoing packets at this point of time, while the incoming packets are still traversing the slower DCNet/UMICH/USAN path. This will be fixed shortly, but as said, it's not IMP or X.25 interface related. The Standard-X.25 interface appears to be behaving fine, as it's getting packets almost all week already. -- Hans-Werner ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610311541.AA03071%40JHEREG.LCS.MIT.EDU] <1986103105413900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: markl@JHEREG.LCS.MIT.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Setting Initial Round-trip time Message-ID: <8610311541.AA03071@JHEREG.LCS.MIT.EDU> Date: Fri, 31-Oct-86 10:41:39 EST Article-I.D.: JHEREG.8610311541.AA03071 Posted: Fri Oct 31 10:41:39 1986 Date-Received: Mon, 3-Nov-86 20:20:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Don't use NETBLT. Not yet. NETBLT is an *experiment* in high-speed bulk data transfer. It works best over long-delay, high-bandwidth (i.e. satellite) networks, although it gives very good performance on othre networks as well. Although a proposed spec is available, we are actively discouraging people from implementing it until we decide whether or not the experiment works. We are currently testing NETBLT over the Wideband network with fairly good results, but a lot of work needs to be done tuning the spec before anyone can use NETBLT. Mark Internet: markl@jhereg.lcs.mit.edu MIT Laboratory for Computer Science Distributed Systems Group ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610311804.AA00167%40braden.isi.edu] <1986103108041900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU (Bob Braden) Newsgroups: mod.protocols.tcp-ip Subject: Re: Poor performance related to egp? Message-ID: <8610311804.AA00167@braden.isi.edu> Date: Fri, 31-Oct-86 13:04:19 EST Article-I.D.: braden.8610311804.AA00167 Posted: Fri Oct 31 13:04:19 1986 Date-Received: Mon, 3-Nov-86 19:19:15 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa The examples you cite of "horrible" EGP routing are probably due to the extra-hop problem in the core. Apparently we have not done an adequate job of information-spreading, if you are not aware of this problem. I seem to recall a blaze of messages on this very subject within the past 6 months, probably on the tcp-ip list. It began with a complaint almost identical to yours, and ended with a scholarly explanation of the extra-hop problem by Dave Mills. The extra-hop problem can at worst double the core traffic, and it is scheduled to go away when the Butterflies take over the core. I forget the exact predicted date from BBN, but rescue is in sight. As for performance, in some funny sense EGP is (deliberately) designed for poor performance, in the sense that it is intended to server as a firewall against misbehaviour by routing domains outside the core. It is true, as Mike StJohns says, that EGP is not a routing protocol; it is also true that this fact has led to serious restrictions in topology and therefore a crash effort is being mounted to replace EGP with a routing protocol, under the direction of the INENG and INARCH task forces. However, maybe we are asking too much of EGP. Perhaps we are trying to make it a technical fix for administrative problems. To avoid bad things like oscillations and routing loops in the face of the "diversity" (to use a nice word) of the Internet as a whole, EGP or whatever replaces it will always have to use long time constants and provide some sub-optimal routes. At the present time, the Internet is growing largely by accretion of new Autonomous Systems, and this must lead to some degradation as you cross boundaries. If we want better overall performance, we need to persuade these systems to aggregate into bigger systems, each run by centralized and professional Internet management, and each using a carefully-optimized IGP. I go into all this polemic, because lately I have been exposed to an awful lot of technological optimism (ask NASA about that!) about Internetting. I wish we could convince some of the new players in the Internet game that it takes great technical sophistication and wisdom to make this stuff work well. The Anarchy Model of Internetting, while theoretically feasible due to EGP, is not really a very wise way to go. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610311813.AA04616%40lbl-csam.arpa] <1986103108130100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: van@LBL-CSAM.ARPA (Van Jacobson) Newsgroups: mod.protocols.tcp-ip Subject: Re: Setting Initial Round-trip time Message-ID: <8610311813.AA04616@lbl-csam.arpa> Date: Fri, 31-Oct-86 13:13:01 EST Article-I.D.: lbl-csam.8610311813.AA04616 Posted: Fri Oct 31 13:13:01 1986 Date-Received: Mon, 3-Nov-86 19:47:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 54 Approved: tcp-ip@sri-nic.arpa I've got a little bit of hard data and a simple change that may improve things for 4.[23]bsd. About six months ago I instrumented our Internet gateway to record a timestamp, src & dst address and port and data & ack sequence numbers for each tcp packet. I reduced two days worth of this trace data and found . the distribution of number of data packets sent on a connection was roughly exponential with a mean of 4 (e.g., a lot of mail traffic). . between 7am and 5pm, PDT, the mean number of retransmissions per data packet was 8. The distribution was bi-modal, with traffic through the "mail bridges" in one lobe (with a mode of ~11) and all other traffic in the other lobe (a mode of ~2). Both lobes were approximately Poisson, possibly due to the long "learning time" of round trip timers on the connections. . For a particular connection, round trip times varied about an order of magnitude. Over all connections, round trip times varied three orders of magnitude. (With the large number of retransmissions, there is some ambiguity in which packets one uses to estimate RTT. I generally used the time from the first use of a sequence number to its first ack, with some ad hoc hackery to accomodate the 50% packet loss through the mail bridges. Given this ambiguity, the uncertainty in any RTT estimate is at least a factor of two.) . The next hop Internet gateway was strongly correlated with the RTT in the following sense: the average RTT of all packets through a gateway is within a factor of three of the average RTT of each connection through that gateway. It is not hard to convince yourself that no reasonable setting of the RTT initial value & filter constants is going to accomodate a factor of 1000 variation in four packets worth of learning time. I mentioned the problem to Mike O'Dell & he suggested using the kernel's routing entry to cache the RTT. I made up a kernel that kept an RTT in each route. When a TCP connection was opened, it initialized its RTT from the route. When the connection closed, its RTT was used to update the route's RTT with a weighted average Rt = A * Rt + (1-A) * Conn (the 4.3bsd kernel changes for all this amount to about 20 lines of C). I took 12 hours of trace data with the filter constant set to .5. The average number of retransmissions *for traffic that originated at the gateway* went down a factor of two (8 to 4). I was going to take more data and try tuning the connection and route filter constants. Unfortunately, some local political changes intervened and I can no longer make changes or take data on the gateway. However, the initial results were promising enough that I plan to try a similar scheme for machines that sit behind the gateway (i.e., construct pseudo-route entries to cache the RTT). - Van Jacobson, LBL ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12251267746.29.JNC%40XX.LCS.MIT.EDU] <1986103111034200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: Poor performance related to egp? Message-ID: <12251267746.29.JNC@XX.LCS.MIT.EDU> Date: Fri, 31-Oct-86 16:03:42 EST Article-I.D.: XX.12251267746.29.JNC Posted: Fri Oct 31 16:03:42 1986 Date-Received: Mon, 3-Nov-86 21:12:51 EST References: <8610310055.AA01124@beno.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa I seem to explain this every 2 months. The problem is not caused by EGP, which is telling you exactly what the gateway you are neighbours with is doing itself with packets to given destinations, but the routing protocol (GGP) which is used by the core gateways among themselves. It predates EGP, was not designed with the pattern of information flows that you see in EGP in mind, and is the cause of the problem. When GGP is replaced (which will probably be when the PDP11's are) the problem will magically disappear without any changes to EGP. For a more detailed explanation of the problem, look in the TCP-IP archive for a message I sent out at Thu 6 Mar 86 18:16:01-EST which goes into great detail. Just out of interest, were you on TCP-IP then? Noel ------- ----MESSAGE-END----