|
|
ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for October 1986 (131 messages, 66331 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/10.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 05:59:33 EDT From: raklein@MITRE.ARPA (Richard A. Klein) To: mod.protocols.tcp-ip Subject: Re: Do we need another protocol?
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
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Wed 1 Oct 86 12:41:40-EDT From: Dennis G. Perry <PERRY@VAX.DARPA.MIL> To: tcp-ip@SRI-NIC.ARPA Cc: perry@VAX.DARPA.MIL Subject: Congestion in the Arpanet
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 <mayersoh@cc5.bbn.com>
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
-------
-------
-------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 13:40:45 EDT From: bzs@BU-CS.BU.EDU (Barry Shein) To: mod.protocols.tcp-ip Subject: Do we need another protocol?
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...
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 14:12:53 EDT From: bzs@BU-CS.BU.EDU (Barry Shein) To: mod.protocols.tcp-ip Subject: Peace fullness.
> 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
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 15:36:40 EDT From: ROMKEY@XX.LCS.MIT.EDU (John Romkey) To: mod.protocols.tcp-ip Subject: Re: MIT pcip and 3com board
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 -------
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Wed, 01 Oct 86 18:40 PDT From: Todd Booth 213-825-1933 <CSDCTGB@UCLA-CCN.ARPA> To: Submit to TCP/IP <tcp-ip@sri-nic.arpa> Subject: Re: Implementation list
> Shouldn't this (in theory) be part of the NIC's > tcpip-implementations.txt, John Romkey <ROMKEY@xx.lcs.mit.EDU> > file? The file has been renamed Netinfo:vendors-guide.doc -todd
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 15:51:00 EDT From: SRA@XX.LCS.MIT.EDU (Rob Austein) To: mod.protocols.tcp-ip Subject: SMTP, 2600, and the security of mail
Date: Monday, 29 September 1986 18:17-EDT
From: Stu Grossman <GROSSMAN@Sierra.Stanford.EDU>
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.
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 16:00:00 EDT From: SRA@XX.LCS.MIT.EDU (Rob Austein) To: mod.protocols.tcp-ip Subject: SMTP, 2600, and the security of mail
Date: Tuesday, 30 September 1986 13:29-EDT
From: The lost Bostonian <gds@spam.istc.sri.com>
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
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 16:18:00 EDT From: jrodrig@EDN-VAX.ARPA (Jose Rodriguez) To: mod.protocols.tcp-ip Subject: Sun NFS RFC
And if there are changes to it, what would happen to all those implementations? RFC?, ya... Jose jrodrig@edn-vax
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 19:23:49 EDT From: mike@BRL.ARPA (Mike Muuss) To: mod.protocols.tcp-ip Subject: Re: Why is the ARPANet in such bad shape these days?
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
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 19:55:50 EDT From: GROSSMAN@SIERRA.STANFORD.EDU (Stu Grossman) To: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail
> 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.
-------
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Wed, 1-Oct-86 21:40:00 EDT From: CSDCTGB@UCLA-CCN.ARPA (Todd Booth 213-825-1933) To: mod.protocols.tcp-ip Subject: Re: Implementation list
> Shouldn't this (in theory) be part of the NIC's > tcpip-implementations.txt, John Romkey <ROMKEY@xx.lcs.mit.EDU> > file? The file has been renamed Netinfo:vendors-guide.doc -todd
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1986 1047-PDT (Thursday) From: Bill Croft <croft@safe.stanford.edu> 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
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
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Thu, 02 Oct 86 10:35:54 EST From: "Thomas Narten" <narten@purdue.edu> To: amdcad!phil@decwrl.DEC.COM (Phil Ngai) Cc: tcp-ip@sri-nic.ARPA Subject: Re: MIT pcip and 3com board
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 ----------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Oct-86 11:33:44 EDT From: GOWER@D.ISI.EDU (Neil E. Gower) To: mod.protocols.tcp-ip Subject: Re: Congestion in the Arpanet
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 -------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1986 11:33:44 EDT From: Neil E. Gower <GOWER@D.ISI.EDU> To: Dennis G. Perry <PERRY@VAX.DARPA.MIL> Cc: tcp-ip@SRI-NIC.ARPA, GOWER@D.ISI.EDU Subject: Re: Congestion in the Arpanet
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 -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Thu 2 Oct 86 12:38:35-EDT From: Dennis G. Perry <PERRY@VAX.DARPA.MIL> To: GOWER@D.ISI.EDU Cc: PERRY@VAX.DARPA.MIL, tcp-ip@SRI-NIC.ARPA, perry@VAX.DARPA.MIL Subject: Re: Congestion in the Arpanet
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 -------
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Oct-86 17:59:44 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: Re: MIT pcip and 3com board
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
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Oct-86 18:02:59 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: more .. Re: MIT pcip and 3com board
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
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Thu, 2-Oct-86 18:30:49 EDT From: leong@andrew.cmu.edu (John Leong) To: mod.protocols.tcp-ip Subject: Re: Ethernet carrier sense during transmit
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.
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Oct 86 19:38:37 EDT From: Jim Rees <apollo!rees@EDDIE.MIT.EDU> To: tcp-ip@sri-nic.arpa Subject: Re: SMTP, 2600, and the security of mail
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.
-------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1986 23:15-PDT From: Steve Deering <deering@pescadero.stanford.edu> To: tcp-ip@sri-nic.ARPA Subject: IP source routing questions
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
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Oct-86 00:02:20 EDT From: GLM@IPGUNIV.BITNET To: mod.protocols.tcp-ip Subject: booking TCP-IP mailing list
I wuould like to be registered in the TCP-IP mailing list.
Sincerely
Gianfranco Galmacci
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Oct 86 00:14:06 edt From: jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen) 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
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Fri 3 Oct 86 01:48:28-EDT From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU> To: hedrick@TOPAZ.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA Cc: JNC@XX.LCS.MIT.EDU Subject: Re: odd routings
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 -------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Fri, 03 Oct 86 09:38:59 -0700 From: Marshall Rose <mrose@nrtc-gremlin> To: Barry Shein <bzs@bu-cs.bu.EDU> Cc: WANCHO@simtel20.ARPA, TCP-IP@sri-nic.ARPA Subject: Re: Do we need another protocol?
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
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 1986 08:19:29 PDT From: Dan Lynch <LYNCH@B.ISI.EDU> To: munnari!moncskermit.oz!john@SEISMO.CSS.GOV (John Carey) Cc: tcp-ip@SRI-NIC.ARPA, LYNCH@B.ISI.EDU Subject: Re: TCP/IP for Burroughs
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 -------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Oct-86 10:05:19 EDT From: tmallory@ccv.bbn.com To: mod.protocols.tcp-ip Subject: New gateway software installed
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 -------
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Fri, 3-Oct-86 11:19:29 EDT From: LYNCH@B.ISI.EDU (Dan Lynch) To: mod.protocols.tcp-ip Subject: Re: TCP/IP for Burroughs
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 -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 1986 1430-PDT (Friday) From: Barbara J. Pease <bjp%ulana@mitre-bedford.ARPA> 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
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Fri, 03 Oct 86 15:48 PDT From: Todd Booth 213-825-1933 <CSDCTGB@UCLA-CCN.ARPA> To: Submit to TCP/IP <tcp-ip@sri-nic.arpa> Cc: munnari!moncskermit.oz!john@seismo.CSS.GOV(John Carey) Subject: RE: TCP/IP for Burroughs
> 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
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Oct 86 17:14:43 edt From: gr@bnl.ARPA (George Rabinowitz) 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
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Oct 86 20:20:37 pdt From: amdcad!phil@decwrl.DEC.COM (Phil Ngai) To: @po3.andrew.cmu.edu:leong@andrew.cmu.edu Cc: charlie@decwrl.DEC.COM, rpw3@decwrl.DEC.COM, tcp-ip@sri-nic.ARPA Subject: Re: Ethernet carrier sense during transmit
> "..... 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
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Oct 86 10:14:21 EDT From: jqj@gvax.cs.cornell.edu (J Q Johnson) To: arpa.tcp-ip Subject: Re: Congestion in the Arpanet
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)?
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Sun, 5-Oct-86 11:13:42 EDT From: olson@TCGOULD.TN.CORNELL.EDU (olson) To: mod.protocols.tcp-ip Subject: Re: Peace fullness.
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
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Mon, 6-Oct-86 02:22:17 EDT From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) To: mod.protocols.tcp-ip Subject: telnet synch
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 <URGENT PTR> ^ 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.
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 1986 1230-PDT (Monday) From: Bill Croft <croft@safe.stanford.edu> To: tcp-ip@sri-nic.ARPA Cc: ehrlich%psuvax1.bitnet@WISCVM.WISC.EDU Subject: re: BOOTP daemon for BSD 4.x
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
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Mon, 6-Oct-86 15:30:00 EDT From: croft@safe.stanford.edu (Bill Croft) To: mod.protocols.tcp-ip Subject: re: BOOTP daemon for BSD 4.x
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
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Tue, 07 Oct 86 08:40 PDT From: Todd Booth 213-825-1933 <CSDCTGB@UCLA-CCN.ARPA> To: Submit to TCP/IP <tcp-ip@sri-nic.arpa> Cc: Vivian Neou - Coordinator of TCP-IP <vivian@sri-nic.arpa> Subject: Protocol of Submissions
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
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Tue, 7-Oct-86 08:57:08 EDT From: mckenzie@J.BBN.COM (Alex McKenzie) To: mod.protocols.tcp-ip 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
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Oct 86 8:57:08 EDT From: Alex McKenzie <mckenzie@j.bbn.com> To: J Q Johnson <jqj@gvax.cs.cornell.edu> 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
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Tue, 7-Oct-86 09:11:00 EDT From: Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM (Benson I. Margulies) To: mod.protocols.tcp-ip Subject: Re: Peace fullness.
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.
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Tue, 7-Oct-86 10:58:23 EDT From: markl@jhereg.lcs.mit.edu To: mod.protocols.tcp-ip Subject: Re: IP source routing questions
> > 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:<NULL> 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..."
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Tue, 7-Oct-86 11:35:47 EDT From: mckee@MITRE.ARPA To: mod.protocols.tcp-ip Subject: Re: Peace fullness.
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
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Tue, 7-Oct-86 11:40:00 EDT From: CSDCTGB@UCLA-CCN.ARPA (Todd Booth 213-825-1933) To: mod.protocols.tcp-ip Subject: Protocol of Submissions
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
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Tue, 7-Oct-86 12:39:55 EDT From: brescia@CCV.BBN.COM (Mike Brescia) To: mod.protocols.tcp-ip Subject: Re: IP source routing questions
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
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 07 Oct 86 12:39:55 EDT (Tue) From: Mike Brescia <brescia@ccv.bbn.com> To: Steve Deering <deering@pescadero.stanford.edu> Cc: tcp-ip@sri-nic.ARPA Subject: Re: IP source routing questions
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
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Wed, 8-Oct-86 00:56:00 EDT From: phil@amdcad.UUCP To: mod.protocols.tcp-ip Subject: testing
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
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Wed 8 Oct 86 07:13:37-EDT From: Dennis G. Perry <PERRY@VAX.DARPA.MIL> To: tcp-ip@SRI-NIC.ARPA, steve@BRL.ARPA Cc: perry@VAX.DARPA.MIL Subject: [Jeff Mayersohn <mayersoh@cc5.bbn.com>: more on arpanet]
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 <mayersoh@cc5.bbn.com>
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.
-------
-------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1986 12:19-EDT From: CLYNN@A.BBN.COM To: deering@PESCADERO.STANFORD.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: IP source routing questions
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
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Wed, 8-Oct-86 12:29:37 EDT From: ddp@ANDREW.CMU.EDU (Drew Daniel Perkins) To: mod.protocols.tcp-ip Subject: IP on 802.5
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
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Wed, 8-Oct-86 14:36:27 EDT From: ron@BRL.ARPA (Ron Natalie) To: mod.protocols.tcp-ip Subject: Re: Peace fullness.
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
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Thu, 9-Oct-86 05:42:42 EDT From: bjp@MITRE-BEDFORD.ARPA To: mod.protocols.tcp-ip 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
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Thu, 9-Oct-86 11:38:37 EDT From: minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU To: mod.protocols.tcp-ip Subject: Re: telnet synch
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 <URGENT PTR> ^ 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
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Thu, 9-Oct-86 11:39:47 EDT From: tcp-ip-RELAY@SRI-NIC.ARPA (William Morgart) To: mod.protocols.tcp-ip Subject: IP source routing questions
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
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 1986 17:01-PDT From: STJOHNS@SRI-NIC.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Re: IP source routing questions
*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:<STJOHNS>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
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Thu, 9-Oct-86 14:03:12 EDT From: mwm@cuuxb.UUCP To: mod.protocols.tcp-ip Subject: Netnews in your mailbox
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.
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Thu, 9-Oct-86 15:55:07 EDT From: brescia@CCV.BBN.COM (Mike Brescia) To: mod.protocols.tcp-ip Subject: Re: IP source routing questions
(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
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 09 Oct 86 15:55:07 EDT (Thu) From: Mike Brescia <brescia@ccv.bbn.com> To: tcp-ip@sri-nic.ARPA Subject: Re: IP source routing questions
(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
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Oct 86 19:45 PDT From: Provan@LLL-MFE.ARPA To: tcp-ip@sri-nic.arpa Subject: re: IP source routing questions
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.
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Thu, 9-Oct-86 20:58:51 EDT From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) To: mod.protocols.tcp-ip Subject: telnet synch
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
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Thu, 9-Oct-86 22:45:00 EDT From: Provan@LLL-MFE.ARPA To: mod.protocols.tcp-ip Subject: re: IP source routing questions
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.
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Fri, 10-Oct-86 00:53:56 EDT From: OLE@SRI-NIC.ARPA (Ole Jorgen Jacobsen) To: mod.protocols.tcp-ip Subject: MIL-STD Problems
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 -------
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 1986 06:02-EDT From: CERF@A.ISI.EDU To: CLYNN@BBNA.ARPA Cc: deering@PESCADERO.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: IP source routing questions
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
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Sat, 11-Oct-86 21:07:47 EDT From: dave@dlb.UUCP To: mod.protocols.tcp-ip Subject: Wanted: members for panel discussion on tcp-ip and sna
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
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1986 14:48:11 PDT From: POSTEL@B.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: Source Routing
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 "<INTERNET-NOTEBOOK>SRC-RTE.DRAFT". The current MIL-STD-1777 is wrong about some of the details of the IP Source Route Options. --jon. -------
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1986 15:50:45 PDT From: POSTEL@B.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: RFCs & MIL-STDs
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. -------
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1986 16:26:38 PDT From: POSTEL@B.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: IP on 802
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 ***
-------
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Sun, 12-Oct-86 17:48:11 EDT From: POSTEL@B.ISI.EDU To: mod.protocols.tcp-ip Subject: Source Routing
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 "<INTERNET-NOTEBOOK>SRC-RTE.DRAFT". The current MIL-STD-1777 is wrong about some of the details of the IP Source Route Options. --jon. -------
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Sun, 12-Oct-86 18:50:45 EDT From: POSTEL@B.ISI.EDU To: mod.protocols.tcp-ip Subject: RFCs & MIL-STDs
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. -------
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Sun, 12-Oct-86 19:26:38 EDT From: POSTEL@B.ISI.EDU To: mod.protocols.tcp-ip Subject: IP on 802
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 ***
-------
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Mon, 13-Oct-86 06:57:34 EDT From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) To: mod.protocols.tcp-ip Subject: communications analyzers for IP??
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
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Mon, 13-Oct-86 17:38:03 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: re: BOOTP daemon for BSD 4.x
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
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 1986 16:02-PDT From: William "Chops" Westfield <BillW@SU-SCORE.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, steve@BRL.ARPA Subject: Re: [Jeff Mayersohn <mayersoh@cc5.bbn.com>: more on arpanet]
Could the large amount of domain traffic on the stanford and SRI-NIC IMPS be responsible for their execeptionally poor performance? BillW
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Tue, 14-Oct-86 13:25:00 EDT From: BEAME@MCMASTER.BITNET To: mod.protocols.tcp-ip Subject: Ultirx TCP/IP problems ?
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 "<CR>"
* 27183 43 18 4096 2 56.00 ; Ultrix echos "<CR><LF>"
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 <CR>
* 20271 43 18 4096 2 10.40 ; Ultrix echos <CR><LF>
43 20273 18 512 0 10.40 ; Pc ack of <CR><LF>
* 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
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Oct 86 13:25 EDT From: <BEAME%MCMASTER.BITNET