|
|
ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for February 1986 (123 messages, 66342 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 86 02:07:01 EST From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU> To: tcp-ip@SRI-NIC.ARPA Subject: TOP (ISO) addressing
Apparently a few people on this group are interested in the ISO protocols. At least there has been enough interest to post some of the standards as RFC's (for which I am grateful). So I hope there may be someone who can answer a question: I have been looking at the specifications for TOP. (For those who don't know what this is, this is the most likely candidate among the ISO protocols for a replacement to TCP/IP in the environment where most of us use it. ISO is a large family of protocols. It provides alternatives at many steps, and leaves a number of things unspecified. MAP and TOP are specifications that make choices where choices are needed, and that fill in the unspecified details. MAP is intended for manufacturing, whereas TOP is intended for the office or research environment. MAP and TOP are really a family, and make similar choices where there is no specific reason to do otherwise.) If I undestand all of the verbiage correctly (and the probability is high that I do not), it looks like TOP is likely to run out of address space. As I read the spec, an address contains two major parts: a two-byte subnetwork number and a variable component which for most of us will turn out to be the host's Ethernet address. It seems to me that 16 bits is not very much for the subnetwork number. As I understand it, the subnetwork number will have to be globally unique (i.e. no other subnetwork in the world can have the same subnetwork number). Even if that is not said in the spec, it seems clear that it is going to have to be the case if we are going to allow for the possibility that subnetworks will communicate with each other over common-carrier X.25 networks or the Arpanet. Furthermore, it is said that routing through gateways is to be based entirely on the subnetwok number. This seems to imply that places like Rutgers that are class B Internet sites will need to use a separate TOP subnetwork number for each of our internal subnets. So in practice, it seems like we are going to need roughly one subnetwork number for every Ethernet that runs TOP. I find it hard to believe that 16 bits will be enough. Does anyone see an error in this argument? -------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 86 09:43:00 PST From: " To: "hedrick" <hedrick@rutgers> Cc: tcp-ip@sri-nic Subject: RE: TOP (ISO) addressing
> Apparently a few people on this group are interested in the ISO
> protocols. At least there has been enough interest to post some
> of the standards as RFC's (for which I am grateful). So I hope
> there may be someone who can answer a question:
>
> I have been looking at the specifications for TOP.
[deleted text]
> If I undestand all of the
> verbiage correctly (and the probability is high that I do not),
> it looks like TOP is likely to run out of address space. As I
> read the spec, an address contains two major parts: a two-byte
> subnetwork number and a variable component which for most of us
> will turn out to be the host's Ethernet address. It seems to
> me that 16 bits is not very much for the subnetwork number.
> As I understand it, the subnetwork number will have to be
> globally unique (i.e. no other subnetwork in the world can
> have the same subnetwork number). Even if that is not said in
> the spec, it seems clear that it is going to have to be the
> case if we are going to allow for the possibility that subnetworks
> will communicate with each other over common-carrier X.25 networks
> or the Arpanet. Furthermore, it is said that routing through
> gateways is to be based entirely on the subnetwok number. This
> seems to imply that places like Rutgers that are class B
> Internet sites will need to use a separate TOP subnetwork number
> for each of our internal subnets. So in practice, it seems
> like we are going to need roughly one subnetwork number for
> every Ethernet that runs TOP. I find it hard to believe that
> 16 bits will be enough.
The Top spec is very early in its development (at V1.0). TOP
is intended to interoperate with MAP at the Network, Transport
and Session layers. For interoperation at the Network layer,
both MAP and TOP will have to use the same addressing formats.
The MAP 2.1 spec calls out three Network address formats allowed
by the ISO address rules. One of these formats has a CCITT
administered Initial Domain Identifier (IDI), and the other two
formats are for locally administered addresses. The address
format in the V1.0 TOP spec is not compatible with any of these.
The TOP spec appears to call out the address format that was
chosen for the Autofact show and I believe is also the NBS OSINET
format. Also, routing protocols are not currently defined.
Routing and congestion control will be absolutely necessary
before ISO protocols could be used in the DoD community.
MAP 3.0 is supposed to include network routing and management
protocols.
There is a recently established distribution list for ISO protocol
discussion: <iso@acc-sb-unix.arpa>.
<Art@ACC.ARPA>
------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 Feb 86 16:17:59 EST From: jas@proteon.arpa To: tcp-ip@sri-nic.arpa Subject: 802.2 SAP for ARP
I'm trying to get an extended (48 bit) one. We'll see how I do. I'll report next week. John Shriver -------
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Tue 4 Feb 86 22:43:09-PST From: Mark Crispin <Crispin@SUMEX-AIM.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: DOWN WITH DUMB GATEWAYS!
Right now, the core gateways claim that FORDNET (128.5) is
unreachable. However, FORD-SCF1 is sending SYN's at SUMEX's SMTP
server at an alarming rate, tying it up so that very little mail
is coming through. Either some dumb gateway is forwarding these
packets from FORDNET, or the DCN-GATEWAY is doing so without telling
the EGP world about it.
Somebody please stop FORD-SCF1 and/or the gateway.
By the way, I think it is very antisocial of a mailer to
repeatedly SYN a port for hours. It ought to take no for an answer
and go to sleep for a bit before trying again.
-------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 86 10:06:00 PST From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Subject: RE: iso-request@acc-sb-unix
My appologies to anyone who failed attempting to send to <iso-request@acc-sb-unix.arpa> wishing to get on the ISO mailing. Iso-request should now work properly (It ends up coming to me anyhow). <Art@ACC.ARPA> ------
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Wed, 5 Feb 86 08:18:38 EST From: Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: TCP-IP@SRI-NIC.ARPA, TCP-IP-RELAY@SRI-NIC.ARPA Subject: DOWN WITH DUMB GATEWAYS!
I see lots of similar things (routing) since the core gateway egp tables got full. What I see happening from lots of hosts is that I receive datagrams (mostly SYNs or UDP Domain requests to our domain server) to which I respond. The responses bounce at the gateway since it does not find the entry in the egp table and sends an ICMP net unreachable back to me. The frequent retransmissions are a different problem which also showed up in a much elevated way since the egp problem appeared since I get the data but the response is not able to get back. We could use this situation as a tool to find lots of flakey implementation because the retransmission problems are much more easily visible.
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Wed, 5 Feb 86 11:45:11 est From: Nathaniel Mishkin <apollo!mishkin@uw-beaver.arpa> To: apollo!tcp-ip@sri-nic.arpa Subject: 4.2bsd UDP/IP Bug?
For reasons that don't bear explanation, I recently had to look through
the 4.2bsd "tftp" server and client code. I saw some strange things
that led me to wonder how UDP works under 4.2 and how it's supposed to
work.
I saw that once the server gets a "request" packet on the "tftp" well-known
port, it forks. The child continues to read on the same file descriptor
(port). The parent goes back to the top of its listen loop, creates
a new socket, and binds its end to the "tftp" well-known port again.
According to my understand of how UDP is supposed to work, if the
implementation is correct, then "tftp" could never work since both the
parent and the child would be reading packets from the same port -- it
would be random which were gotten by the parent and which were gotten
by the child. The apparent reason things work on 4.2 is because the
kernel demultiplexes incoming UDP packets based on BOTH the packet's
local AND foreign port. If I understand the UDP/IP spec, this is a bug
-- you're supposed to demultiplex incoming packets by looking ONLY at
the local port.
Do I misunderstand UDP? Is 4.2 broken? Is 4.3 fixed? Please respond
to me since I'm not on this list.
-- Nat Mishkin
Apollo Computer Inc.
{wangins,yale,uw-beaver}!apollo!mishkin
apollo!mishkin@UW-BEAVER.ARPA
-------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 1986 12:02:57 EST From: MILLS@USC-ISID.ARPA To: Crispin@SUMEX-AIM.ARPA, TCP-IP@SRI-NIC.ARPA Cc: MILLS@USC-ISID.ARPA Subject: Re: DOWN WITH DUMB GATEWAYS!
In response to the message sent Tue 4 Feb 86 22:43:09-PST from Crispin@SUMEX-AIM.ARPA Mark, No, you have it wrong. FORDnet is being actively asserted as up via EGP from DCN-GATEWAY, which it in fact really is. You are seeing IDMP Destination Unreachable messages returned from FORDnet host FORD1, since the particular subnet used by the offending host appears down at that host, which is in fact a subnet gateway. The infrastructure supporting connectivity to the offending host is presently working correctly; however, your comments re the host itself are well taken. Please direct your comments to John Nagle (jbn@ford-wdl1.arpa), who is the responsible person for those Ford Aerospace hosts. Dave -------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed, 5 Feb 86 15:06:14 EST From: Ron Natalie <ron@BRL.ARPA> To: Hans-Werner_Braun%UMich-MTS.Mailnet@mit-multics.arpa Cc: TCP-IP@sri-nic.arpa, TCP-IP-RELAY@sri-nic.arpa Subject: Re: DOWN WITH DUMB GATEWAYS!
I wouldn't quite blame the non-core gateways for this. It is hardly there fault that the core-IGP doesn't work. Currently EGP is in a state that you have to very carefully meter how you deal with the core, e.g. you have to watch which core-EGP speaker you load your routing table with, you've always had to discard entries for your own networks, etc... -Ron
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Wed, 5 Feb 86 19:27:45 -0200 From: mcvax!imag!pierre@seismo.CSS.GOV (Pierre L. LAFORGUE) To: info-vax@sri-kl.ARPA, tcp-ip@sri-nic.ARPA Subject: Submission about TCP/IP under VMS
May you think appropriate to post this in your moderated newsgroups? Thank you very much in advance, if possible. To insert a VAX/VMS on an Ethernet linking heterogeneous Unix computers, and later Microvaxes/VMS, we are looking for a TCP-IP software running under DEC/VMS, and supporting possibly NFS. We received no response from Wollongong, but a proposition from GEC-Software (132-135 Long Acre LONDON WC2E9AH G.B. , Tel 01-2407171) which offers TCP-IP and a gateway with DECNET named "Dbridge". As I saw somebody seeking vendors of TCP-IP, this information should be usefull to him. My questions are : 1- Is there anyone who experienced the TCP-IP/VMS of GEC-Software ? Is it possible to use all of the application level Unix stuff with it, as rlogin, rwho, from Unix and from VMS ? 2- Does anybody know a source for NFS/VMS ? Thank you very much to answer to: pierre@imag.UUCP (or ...!seismo!mcvax!vmucnam!imag!pierre)
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 1986 00:18:35 EST From: MILLS@USC-ISID.ARPA To: ron@BRL.ARPA, Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA Cc: TCP-IP@SRI-NIC.ARPA, TCP-IP-RELAY@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA Subject: Re: DOWN WITH DUMB GATEWAYS!
In response to the message sent Wed, 5 Feb 86 15:06:14 EST from ron@BRL.ARPA Ron, Careful peruse of RFC-904 should reveal an EGP stalwart should in fact report every network directly reachable from its own autonomous system, which includes the net common with the core gateway. With that bit, you should not be surprised if said core gateway hands your net back to you. In fact, DCN-GATEWAY peers with up to three core gateways and an odd-lot non-core gateway or two sometimes, but with unspectacular consequences. Turns out, if you believe EGP hop counts sent by core gateways (i.e. from the same system) hop counts can be compared and all except the lowest discarded. This, however, is an unadvertised feature the existence of which could probably be inferred from the tortuous history of this protocol and the personality of its developers. What else can be said, except stay tuned for more formal proposals in this area that might even legitimize this inference. You did not hear me say these words. Dave -------
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 05-Feb-86 20:50:22-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Conversations with an Ethernet watcher
Folks, Further to my recent note and the previous notes from Mark and Hans-Werver. I watched packets wade through our DCnet Etherswamp and found alligators still munching. Briefly, that swamp includes gateways to ARPANET (56K bps), UMICHnet (9.6K bps) and FORDnet (9.6K bps), as well as a raft of other swamp creatures. Thus, I can see all packets flying between DCnet gateways and in some cases the subnet gateways on FORDnet and UMICHnet. The hosts lurking on the subnets include 3COM, 4.3bsd, Wollongong, Sun, fuzzball and even more bizarre creatures scattered all over the country. The subnets are connected mostly by multiple 9.6K bps lines and fuzzball gateways, which run a dynamic routing algorithm that functions both at the net and subnet level. As you might expect, we take moderate to severe congestion hits when things break or when hosts on any of the nets misbehave, which seems fairly often these days. Mark and Hans-Werner report only the tip of the swampberg, to phrase a coin. Following is a quick summary of my Etherwatch, captured in the interval between curiousity and eyestrain and intended not so much as a specific problem report as a generic speculation on what might be happening in other ponds. 1. Congestive collapse. When things get really bad the fuzzball routing algorithm will occasionally declare a line down, which can activate a secondary path, but only after a period of hold-down and possibly non-reciprocal connectivity (we call these "one-wire feeds" after a term used in the radio/TV broadcast community). When this happens transient black holes and ICMP error messages can originate at the strangest places. 2. Black holes. Not all subnet gateways subscribe to the fuzzball routing algorithm; in particular, some FORDnet subnet gateways. The fuzzballs thus cannot determine reachability and do not generate ICMP error messages. Unfortunately, this situation now holds (since Mark's complaint) for all FORDnet subnets except 128.5.0. Mark will henceforth get no error messages at all when Ford Aerospace gateways or lines west of Dearborn are blitzed. 3. Disregarding error reports. I see what appears to be almost universal disregard for ICMP error messages. Certainly Unix and TOPS-20 users remain blissfully ignorant of these things, which many gateways, including the core gateways and fuzzballs, take some pain to get right. Thus, the casual user has no hard evidence to beat up the system or net maintainers. 4. Mismatched routing dynamics. EGP dynamics are very slow compared with most IGP dynamics, including the fuzzballs. Thus, nets on the business side of our EGP gateway, for example, can flap up and down with the effect that EGP advertisements may disagree with the actual routes delivered. Our own warranty has a clause relieving liability during transient periods up to several minutes. 5. Hidden gateways. There is a lot of subnet plumbing in our waterworks, some of it rather leaky (in the best and most common tradition). Thus, ICMP error messages can originate at a subnet gateway or even a host without implying problems further up the pipe. Unless the recipient of such an error message is aware of the subnet configuration, it might mistakenly assume the primary (net) gateway is broken. 6. Protocol problems. Certain hosts tapping our plumbing make rather good random-noise/congestion generators (not our DCnet hosts, of course). I watched Wollongong 128.5.0.9 generate between 1.5 and 5 ACKs for every TCP data segment just now. I also saw 4.3bsd(?) 128.5.33.1 and 10.2.0.78 get into ACK-ACK fights. Host 10.2.0.78 apparently has a bunch (3) of hung TCP connections sending something every few seconds but ignoring what appear to be valid reset segments from 128.5.33.1. The 128.5.32.1 and 128.5.33.1 hosts advertise, probably unwisely, windows of 2048 and 4096 octets respectively, which is much larger than necessary (two to four seconds at 9.6K bps) and almost guarantees gateway congestion. Almost every initial-connection attempt involves at least two and up to five retransmissions at intervals much less than the estimated roundtrip delay. 7. Fairness abusers. Why do some hosts (10.2.0.78, among others) open multiple parallel SMTP connections to the same host? This might represent a misguided attempt to "optimize" the delivery delay, but certainly makes the congestion problems that much worse. There are two such connections right now between 10.2.0.78 and 128.5.32.1 and three between 10.2.0.78 and 128.5.33.1. No wonder our poor fuzzthings get eaten by the alligators. 8. Tinygrams and jumbograms. Occasionally I see connections across the net with probably unwise selection of maximum segment size MSS, with a particularily uncomfortable choice of 1024. This guarantees fragmentation at least once somewhere on the path and usually twice, as well as clogs reassembly resources in congested weather. Smaller values less than the ARPANET maximum (906-odd) are much more appropriate. In fact, gains in efficiency on many paths with MSS greater than 576 are lost due to congestion, itself due to lower buffer-space utilization. At the other end of the spectrum, vast spasms of tinygrams (usually character-at-a-time TELNET) continue to flood the swamps, in spite of well-documented fixes for this. Dave -------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 Feb 86 05:31:19 pst From: Earl Craighill <ejc%sri-gemini@sri-tsc> To: iso-request@acc-sb-unix Cc: "tcp-ip" <tcp-ip@sri-nic> Subject: RE: iso-request@acc-sb-unix
Art- Please put me on the iso mailing list. The safest address to use is Craighill@sri-kl. Thanx Earl
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 1986 8:39:25 EST (Thursday) From: T. Michael Louden (MS W422) <louden@mitre-gateway.arpa> To: ron@brl Cc: tcp-ip@sri-nic Subject: Re: DOWN WITH DUMB GATEWAYS!
Maybe the solution to much of the EGP related problems it to have BBN upgrade the core to meet the EGP specs., the problem where the core says that it is the route to your network strikes me as a dangerous bug that can easily result in a black hole in the INTERNET. The less serious problems of incomplete status fields on error messages and not peering with gateways that are not directly connected should also be fixed. I have heard suggestions that the Butterfly gateways should be used to replace the current 11/23s. I am concerned that the code in these will be no better since it comes from the same place.
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 1986 10:12:41 EST (Thursday) From: T. Michael Louden (MS W422) <louden@mitre-gateway.arpa> To: mills@dcn6 Cc: tcp-ip@sri-nic, louden@mitre-gateway.arpa Subject: Re: DOWN WITH DUMB GATEWAYS!
Dave, Your net is not directly reachable from the core autonomous system since your gateway is not part of the core autonomous system. The core must us your gateway to reach your net. Thus I do not understand your comments. Mike
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 Feb 86 11:03:12 est From: swb@devvax.tn.cornell.edu (Scott Brim) To: tcp-ip@sri-nic.arpa Subject: Tektronix VMS
We have heard that someone has adopted Tektronix's VMS TCP/IP software
and is "fixing it up" (as is it doesn't know about gateways, for
example). We've also heard, less reliably, that it is someone at CMU.
We're VERY interested and would like to get in touch with anyone who is
working on this.
Thanks -- Scott
-----
Scott Brim swb@devvax.tn.cornell.edu
Cornell University Theory Center {decvax,ihnp4,cmcl2,vax135}!cornell!swb
607-256-8686 swb@cornella.bitnet
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Thu, 06 Feb 86 10:11:59 EDT From: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU (Bob Dixon) To: TCP-IP@SRI-NIC.ARPA Subject: GEC Software
A telephone call to London revealed that the VMS tcp-ip software mentioned
here recently by Pierre is in fact the Wollongong software, exported to
England. They refer all US inquiries to Wollongong. Th
However, I am still interested in the DECnet gateway called Dbridge.
Does anyone have info about that, and is it really a "gatweay" ?
Bob Dixon
Ohio State University
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 1986 11:31:28 EST (Thu) From: Dan Hoey <hoey@nrl-aic.ARPA> To: mills@dcn6.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: Conversations with an Ethernet watcher
Date: 05-Feb-86 20:50:22-UT
From: mills@dcn6.arpa
...
7. Fairness abusers. Why do some hosts (10.2.0.78, among others) open
multiple parallel SMTP connections to the same host?
Maybe for the same reason they open multiple TELNET connections--when
a user wants to send a message, I see no reason why the system must
queue it until any current traffic to the destination host is past.
Certainly the ability to queue is useful, but hardly required.
Of course, it could just be that they restarted after giving up on a
catatonic SMTP connection, and they couldn't wake up the corpse enough
to kill it.
Dan Hoey
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 86 14:52:00 PST From: <art@acc.arpa> To: "ts0400%ohstvma.bitnet" <ts0400%ohstvma.bitnet@wiscvm> Cc: tcp-ip@sri-nic Subject: DBridge
> A telephone call to London revealed that the VMS tcp-ip software mentioned > here recently by Pierre is in fact the Wollongong software, exported to > England. They refer all US inquiries to Wollongong. Th > > However, I am still interested in the DECnet gateway called Dbridge. > Does anyone have info about that, and is it really a "gatweay" ? DBridge is part of the Wollongong package. This is a VMS process which opens a Decnet circuit to another DBridge process across the Decnet. The DBridge process uses a raw socket to pass IP datagrams to/from the local TCP/IP kernel and forward them across the Decnet. This allows a TCP/IP network to be layered on top of a Decnet. If one of the TCP/IP nodes is connected to a real IP network, it can route IP datagrams to/from that network. Art@ACC.ARPA ------
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 Feb 86 14:09 EDT From: Chris Johnson <JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA> To: tcp-ip@sri-nic.arpa, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: Mystic words and phrases.
Hi.
All languages have a set of common words which most people use in
every day speech. Then there are various subset for technical fields.
Networking is no exception to this. Because or in spite of much use of
certain phrases there also arises abbreviated forms and shortcuts. I'm
usually the first to admit that my ignorance is rife. In this case it's
about time I got some enlightenment. The two specialized terms I am
currently having trouble with are:
1) EGP and
2) fuzzball
I think I understand them from much context hunting but am not sure. I
don't have ARPA network stuff here and was wondering if someone out
there in the big wide universe would enlighten me as to the true meaning
of these terms. Please remember that not everyone who listens to this
list is always in tune. It would be nice if now and then and
abbreviation was expanded.
Thank you.
peace,
Chris Johnson
johnson@northeastern (CSNet)
johnson%northeastern@csnet-relay (ARPAnet)
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 Feb 86 17:44:58 EST From: jas@proteon.arpa To: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU (Bob Dixon) Cc: tcp-ip@sri-nic.arpa Subject: Re: GEC Software
DBridge is not a protocol translator. It is a facility to tranport IP packets over the DECnet transport facilities. What you get in ISO layers is TCP 7 6 5 4 3 TCP 2 (IP) DECnet 4 3 2 DECnet 1 Thus you get to use the web of DECnet point-to-point facilities and long-haul stuff to move IP packets around. Same idea as IP over X.25. John Shriver Proteon -------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 1986 18:35:33 EST From: MILLS@USC-ISID.ARPA To: louden@MITRE-GATEWAY.ARPA, ron@BRL.ARPA Cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA Subject: Re: DOWN WITH DUMB GATEWAYS!
In response to the message sent 6 Feb 1986 8:39:25 EST (Thursday) from louden@mitre-gateway.arpa Mike, In BBN's defense, remember that the LSI-11 gateways were evolved way beyond reasonable conjecture from the first design, include protocol support (EGP and VAN) unanticipated in the original design and are deployed in much greater numbers of gateways and networks than are reasonable with this design. The Buttergates were evolved precisely in response to many of the existing problems and, assuming money to pay for them is found, should eventually overtake the LSI-11s. The presence of apparent routing loops in updates received from the core system is an expected consequence of the intrinsic GGP routing protocol used in the LSI-11 gateways for the last seven years. This protocol, as well as other similar protocols based on min-hop algorithms can for form transient loops when various nets bob up and down and the hop-count fields are "counted to infinity." The problem has been long recognized and has nothing intrinsically to do with EGP or even the particular implementation, but is an intrinsic problem with min-hop algorithms. The SPF algorithm developed for the ARPANET and adapted for the Buttergates should make these loops much less likely. You might speculate on what might happen if we did not have EGP and peered GGP directly with the core instead. Before we had EGP there was this incident that became enshrined in legend and called the Great Commando Raid. Someday either Mike Brescia or I will include that chuckle in our memoirs. The circumstances were funny enough and won't be repeated here; however, the result was a new packet type, called the Kiss of Death (KOD) packet, that killed the recipient, but not before forwarding the packet to the next victim. Dave -------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 06-Feb-86 15:21:41-UT From: mills@dcn6.arpa To: T.MichaelLouden(MSW422)<louden@mitre-gateway.arpa>, mills@dcn6, tcp-ip@sri-nic Subject: Re: DOWN WITH DUMB GATEWAYS!
Mike, Oop, you are absolutely right. My intent was to point out that ARPANET itself is legitimate to advertise on the part of both the core and non-core gateways sharing it. While RFC-904 specifies what a non-core gateway must do, there is no specification on what a core gateway must do; therefore, we can't beat up those villans for sending your net back to you. A reasonable sketch of a core- gateway specification might conclude that is, indeed, broken. My foo-paw was a thlip of the thongue. Dave -------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Thu 6 Feb 86 23:54:44-PST From: Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: [jbn@Ford-wdl1.ARPA (John B. Nagle): FORD-SCF1 now under control]
Another varmint bites the dust. Thanks JBN!!!
---------------
Return-Path: <@SUMEX-AIM,@SU-SCORE.ARPA:jbn@Ford-wdl1.ARPA>
Received: from SU-SCORE.ARPA by SUMEX-AIM.ARPA with TCP; Thu 6 Feb 86 14:04:19-PST
Received: from FORD-WDL1.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Feb 86 13:46:26-PST
Received: by FORD-WDL1.ARPA (5.15/5.9)
id AA17695; Thu, 6 Feb 86 13:51:59 PST
Date: Thu, 6 Feb 86 13:51:59 PST
From: jbn@Ford-wdl1.ARPA (John B. Nagle)
Message-Id: <8602062151.AA17695@FORD-WDL1.ARPA>
To: MRC@su-score.arpa
Subject: FORD-SCF1 now under control
The mailer misbehavior at FORD-SCF1 has been taken care of. That
machine had been accidentally set up with the Berkeley trailer kludge enabled,
but the other end of the synchronous link was not set up for trailers,
so little packets got through but big packets didn't. We've also changed
the mailer retry interval from 1 minute to 30 minutes. This should fix
the problem.
John Nagle
-------
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Fri 7 Feb 86 00:07:50-MST From: Mark Crispin <MRC@SIMTEL20.ARPA> To: mills@DCN6.ARPA Cc: hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Conversations with an Ethernet watcher
Add my voice to the clamor -- it is a bug or misfeature that Berkeley Unix has multiple simultaneous SMTP streams to the same host. SMTP is a batching type process and overall mailer throughput is more important than the small gains some messages may gain from multiple streams. It really nailed SUMEX badly that the nastygrams that hit its SMTP server came from a Berkeley Unix SMTP mailer. I tried opening multiple listeners (a listener just negotiates SYNs then hands the connection off to the server... normally a very fast task) and the damn host just went and grabbed the new listener! -------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 06-Feb-86 19:33:37-UT From: mills@dcn6.arpa To: DanHoey<hoey@nrl-aic.ARPA>, mills@dcn6.ARPA, tcp-ip@sri-nic.ARPA Subject: Re: Conversations with an Ethernet watcher
Dan, I will respond with the voice of Jack Haverty, longtime and intrepid Internet Engineer. If you really need to open n simultaneous connections, each with full complement of windows, buffers and whatnot, then we must provide sufficient buffering at all transit points for the aggregate of all such connections, even if only infrequently used. However, a little care in the engineering of the client software can result in major savings in total system cost. The multiple- connection scenario I reported yesterday persisted for most of the day, from which I infer either an unlikely multiplicity of users patiently waiting for many messages to barge through the swamps or the existance of multiple mailer daemons. The former are obviously patience-limited, so I don't worry overmuch about them; however, I do worry about the latter. Jack, who is usually more conservative than I, might toss off the following on an envelope while waiting for an airplane. The two 2048-octet windows on one machine and three 4096-octet windows on the other require up to 16K for buffering on transit systems. If comfortably tucked in 576-octet packets (536 data octets), something like 30 packets could be wandering around our gateway. A conservative might also observe from my observations that multiple ACKs are sometimes returned from the destination that an additional number (we'll call it 30) might be soaked up for traffic toward the source. However, those packets have to live in real buffer space, which with most hardware and software require a contiguous region of at least the MTU for the net, in the Ethernet case 1500 octets. Thus, our underpowered fuzzthing would have to cough up 60 1500-octet buffers, or 90K of memory just for those two hosts. See RFC-970 for an even less palatable scenario. The little dears only have about a fifth of that in the present configuration, from which Jack would conclude we should either pull the plug or convert to X.25. While Jack and I do kid each other mercilessly, you have to admit he has a point. The Internet Engineer cum Protocol Cop is seldom seen in these parts. Dave -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Fri, 7 Feb 86 8:41:00 EST From: Alex McKenzie <mckenzie@BBNH.ARPA> To: tcp-ip@sri-nic.arpa Subject: DEC "LANBridge 100"
Someone recently asked about the "Dbridge" and someone else answered that it was a piece of software. I don't know about that, but thought I'd add that there is a new DEC product called the "LANBridge 100" which is intended to interconnect two Ethernets. It learns (or can be told, I think) what Ethernet addresses are on its side "A". If it sees any Ethernet frames on the Ethernet on side A whose addresses aren't on this list, it copies the frames to the Ethernet on its side B. If it sees any Ethernet frames on side B whose addresses ARE in the list, it copies these to the Ethernet on side A. Thus, it is at ISO level 2, unlike an Ethernet repeater (a level 1 device) or an IP gateway (a level 3 device). I thought it might be possible that this device was intended in the question about the "Dbridge".
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri, 07 Feb 86 12:00:53 EDT From: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU (Bob Dixon) To: IBM-NETS%BITNIC.BITNET@WISCVM.WISC.EDU , TCP-IP@SRI-NIC.ARPA Subject: Ethernet/T1 bridges
We have need for devices that will interconnect distant (few miles) ethernets via T1 links, and which have enough intelligence to send only the needed traffic. All protocols must pass transparently. We have heard that Vitalink makes such a box, but have been unable to get any details as yet. Also Applitek can do this, but it takes 2 boxes in series at each end, which doubles the cost. Does anyone know of other options? Another alternative is to use something like the DEC Lan bridge for the intelligence, and then some simpler box for just Ethernet/T1 connection. But we have been unable to locate such a box. Anyone know of any?
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 1986 13:03:30 EST From: MILLS@USC-ISID.ARPA To: JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA, tcp-ip@SRI-NIC.ARPA Cc: MILLS@USC-ISID.ARPA Subject: Re: Mystic words and phrases.
In response to the message sent Thu, 6 Feb 86 14:09 EDT from JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA Chris, You're right, and I apologize for thinking everybody has a psionic tap on the Old Boy Network (resisting heroically the urge to pun that one). EGP stands for the Exterior Gateway Protocol, which is used to exchange information between gateways and is described in RFC-904. As for the fuzzballs, he bleats sheepishly, they are a bunch of frisky PDP11-compatible workstations used by some of us to develop, test and evaluate new protocols and nets. See for reference "The Empire Strikes Back," in which "fuzzball" is mentioned in the dialog. In point of fact, the fuzz predate the movie. Dave -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Sat, 8 Feb 1986 00:21 MST From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA> To: TCP-IP@SRI-NIC.ARPA Cc: WANCHO@SIMTEL20.ARPA Subject: TCP/IP via X.25 connection to DDN
Please tell me I'm wrong... Last I heard, if a site runs TCP/IP through an X.25 interface to an IMP, it can talk only to other X.25 sites. Is this (still) true? --Frank
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Sat, 8 Feb 86 23:52:15 cst From: rick@ngp.UTEXAS.EDU (Rick Watson) To: TCP-IP@SRI-NIC.ARPA, TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU Cc: rick@ngp.UTEXAS.EDU Subject: Re: GEC Software
Dbridge is a Wollongong product that allows you to transport IP packets over a DECnet connection. It connects 2 hosts running (Wollongong) TCP/IP. It uses DECnet for the transport layer. It does no gatewaying between DECnet and TCP/IP. The DEC Lan Bridge 100 is an ethernet level gateway. It also does no protocol translation. DEC's DECnet for Ultrix is supposed to do some kind of DECnet to TCP gatewaying, but I don't know what yet. I have this software on order, so I'll let you know what it does when I get it. Rick Watson University of Texas Computation Center arpa: rick@ngp.UTEXAS.EDU rick@ngp.ARPA uucp: ...seismo!ut-sally!ut-ngp!rick rick@ut-ngp.UUCP bitnet: ccaw001@utadnx phone: 512/471-3241
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Sat, 8 Feb 1986 23:07 EST From: "David D. Story" <FTD%MIT-OZ @ MC.LCS.MIT.EDU> To: Chris Johnson <JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Mystic words and phrases.
1) Electronic Graphics Printer 2) IBM selectric style ball (letter quality) or 1) A sixth sense that always means trouble. 2) A spitball but with Newsprint.
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 1986 12:34-EST From: CERF@USC-ISI.ARPA To: WANCHO@SIMTEL20.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: TCP/IP via X.25 connection to DDN
Frank, Last I hear, BBN had succeeded in figuring out how to make the X.25 interfaces and the 1822 interfaces interoperate - whether this code is in the operational network, however, I am not sure about. I hope you are wrong but your statement was, at one time in the past, true, and may still be. Vint Cerf
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 1986 19:23:52 EST From: CLAUSEN@USC-ISID.ARPA To: TCP-IP@SRI-NIC.ARPA Cc: clausen%UKans@CSNET-RELAY.ARPA Subject: hello
Folks, I want to use a Microvax as a "front-end" for our 750 running Unix B4.2 and one of the ACC interfaces. Do you know of anybody who has a Microvax (q-bus!) with an ACC interface and 4.2 with the IP/TCP software running? --Horst
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Sun 9 Feb 86 20:53:26-EST From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU> To: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU, IBM-NETS%BITNIC.BITNET@WISCVM.WISC.EDU, TCP-IP@SRI-NIC.ARPA Cc: JNC@XX.LCS.MIT.EDU Subject: Re: Ethernet/T1 bridges
I will point out to everyone (once again) that bridges have
severe technical disadvantages, especially in a system which is intended
to be connected to the main internet. Now, you should take my words
with a grain of salt, because I have a financial interest in seeing
people use routers (aka 'IP gateways') instead of filtering digital
repeaters ('bridges'), but I was saying this for years before I got
involved with a product.
I don't want to conduct a technical discussion on this (large)
mailing list; if you don't believe me, retrieve (via anonymous FTP)
the file <JNC>BRIDGES.TXT from MIT-XX; it contains an earlier
discussion on this issue. See <JNC>BRIDGES.LOSE for an example of
a user of bridges losing big.
Noel
-------
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 86 21:09 EST From: Corrigan @ DDN1.ARPA To: WANCHO @ simtel20.arpa Cc: TCP-IP @ sri-nic.arpa, WANCHO @ simtel20.arpa Subject: Re: TCP/IP via X.25 connection to DDN
Interoperation of TCP/IP users using 1822 and X.25 interfaces is first supported in Packet Switch release 6.0. We are currently fielding this release as required (namely at nodes with x.25 subscribers) in the MILNET. We will be fielding it as the standard release in the MILNET in the next few months. We will also field it in the ARPANET as soon as possible. The holdup there is upgrading all the switches to the C-30e configuration. This should also be completed in the next few months. Mike Corrigan Technical Manager DDN
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 09 Feb 86 22:27:29 EST (Sun) From: Frederick E Serr <fserr@BBNCC5.ARPA> To: "Frank J. Wancho" <WANCHO@simtel20.ARPA> Cc: TCP-IP@sri-nic.ARPA Subject: Re: TCP/IP via X.25 connection to DDN
Interoperability between X.25 and 1822 hosts is implemented in Release 6 of the PSN software. Unfortunately, the ARPANET is still running the equivalent of PSN Release 4. The hardware on the network is currently being upgraded to allow installation of PSN 5. I don't know the official schedule, but I would guess that PSN 5 will go in sometime in March, and you won't see PSN 6 until a couple of months after that. Until that time, hosts with X.25 interfaces on the ARPANET cannot talk to 1822 hosts. --Fred
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 86 08:23:00 PST From: <gary@acc.arpa> To: "wancho" <wancho@simtel20> Cc: tcp-ip@sri-nic Subject: TCP/IP via X.25
Frank, The X.25 connection you mentioned in your 8 February message describes, what is known as "Basic Mode" DDN X.25. Although TCP/IP is used for such things as data integrity, 'Basic Mode' service provides communication only between a X.25 DTE and other X.25 DTE's. Specifically, only a X.25 Host can communicate with another X.25 Host on the DDN. As DCA has mandated that all host be interoperable with each other another form of X.25 has been devised which is called "Standard Mode". This is to allow hosts which have been previously connected to the net, either with 1822 or 1822-J (HDH) connections, to communicate with X.25 hosts. TCP/IP is used as the upper-level protocols to provide continuity and full interoperablity. As you may or may not know, DCA is in the process of qualifying various vendors implementations of the DDN X.25 specification. It is important for user evaluation to determine if the vendor has a fully qualified product in accordance with the test scenarios of the DDN X.25 Standard Service for achieving full interoperability. For additional information contact the NIC and request the circular entitled: "Defense Data Network X.25 Host Interface Specification, December 1983. Sincerely, Gary Krall ------
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Mon, 10 Feb 86 06:58:24 est From: rsparbe@nswc-wo.ARPA To: tcp-ip@sri-nic Subject: Inter operable X.25
Could someone tell me if the problem I am having with sending mail to one site could be related to the HDH/X.25 inter operability issue. We run a HDH and 1822 hosts. The other sites have X.25 connections. We cannot send mail to each other. I know there could be many different problems, but is it possible the problem relates to the release 5.0 software running on the net not allowing HDH/X.25 inter operability? Please answer direct to me at rsparbe@nswc-wo. Thanks Bob
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 1986 1111-PST (Monday) From: Barry Leiner <leiner@RIACS.ARPA> To: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA> Cc: WANCHO@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: TCP/IP via X.25 connection to DDN
Someone from DDN or BBN should respond directly, but let me state what I believe to be the case. There are two types of X.25 interface to the Milnet/DDN. The first, which was put in place first, was called Basic (for some obscure reason) and the second called Standard. Not sure if those are still the names. The Basic interface is an X.25 end to end service, and was put in place to support hosts that talk only X.25. This is supposed to be a "temporary" interface, as all hosts are eventually supposed to use TCP/IP. The STandard interface is an X.25 interface to the DDN, on top of which hosts are to run TCP/IP. My understanding is that, for this interface, X.25 is terminated in the local imp, and therefore should be interoperable with other local interfaces, in particular 1822. Barry ----------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Mon, 10 Feb 86 09:57:38 EDT From: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU (Bob Dixon) To: RICK@NGP.UTEXAS.EDU Cc: TCP-IP@SRI-NIC.ARPA , TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU Subject: Re: GEC Software
Thanks for the info, Rick. The word I got from DEC regarding Ultrix (after intense questionning) is that it supports tcp/ip and DECnet, but does not provide any gateway function. We urged them to provide such a gateway and even offered to contract with them to do so, but they said there is not enough market for it, and it is contrary to company policy. Their policy is to offer token support to tcp/ip via selling things like Wollongong and Ultrix, but to expend no real effort on tcp/ip. Instead they are aiming for migtation to future ISO standards, bypassing tcp/ip. If you get any word to the contrary, I'd be anxious to hear it.
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 1986 17:14:37 PST From: Dan Lynch <LYNCH@USC-ISIB.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: LYNCH@USC-ISIB.ARPA Subject: SXecurity and Precedence Options
Does anyone know of any implementations of those options? I realize that the "nodes" "IMPS" in such a network would also have to properly implement those options (or support them somehow). Dan -------
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 1986 18:04-PST From: STJOHNS@SRI-NIC.ARPA To: LYNCH@USC-ISIB.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: SXecurity and Precedence Options
Please note: There is a revised version of the IP security option. The IP option as detailed in the IP RFC and the IP MIL STD is "officially" defunct. To answer your question, the only implementation I know of which uses any form of security option is at the 1ISG at the Pentagon on their Multics systems. Contact Housley%his-phoenix-multics@cisl-service-multics.arpa for details. Mike
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 86 08:20:00 PST From: <gary@acc.arpa> To: "clausen" <clausen@usc-isid> Cc: tcp-ip@sri-nic Subject: uVAX interface
Horst, ACC's interface for a uVAX, termed the ACP 5250, is being shipped to our beta-site this week. We are anticipating DDN qualification for standard mode operation within the next 2-3 weeks. The first implementation will support a VMS device driver which will be integrated into the Internet TCP/IP package. We are anticipating that support will follow in fairly short order for Wollongong's package, 4.2 and 4.3, and Ultrix. A good lead time for ordering purposes would be 60 days ARO, to allow for the above to take place. Hope this helps. Gary Krall ------
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 1986 08:09:31 CST From: DDN-REQT@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: DDN-REQT@GUNTER-ADAM.ARPA, DDN-REQT@GUNTER-ADAM.ARPA Subject: Removal from mailing list
Please remove DDN-REQT@GUNTER-ADAM FROfrom the tcp-ip mailing list. thanks, Link Verstegen -------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 1986 12:11:39 EST From: PADLIPSKY@USC-ISI.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Tails and Dogs
Feeling that I owe myself one indulgence for not flaming about
the recent rash of unexpanded alien acronyms ("TOP" and [shudder]
"MAP"), I fear I've got to risk taking on Dave Mills (and perhaps
the spirit of Jack Haverty, though I hope and trust not) on what
I take to be a rather pernicious implication: Loath as I am to
be cruel to fuzzballs--not only on cruelty to animals grounds but
also out of respect for their/their person's ability to bite back--
and with some trepidation that I've misconstrued the relevant
cryptomillsisms, if Dave really thinks there should be limitations
imposed on logical constructs ("connections," whether SMTP or other)
to cater to the shortcomings of physical constructs (gateways,
whether fuzzy or other), then he seems to be to be letting the tail
wag the dog.
In the first place, aren't gateways fundamentally supposed to be
"receive and forward" devices? If so, what's the fuss about
consuming their buffers? In the second place, if line speeds
preclude rapid enough forwarding after receipt, isn't this a
"virtual comm subnet" problem of the "congestion control" kind?
If so, why should it be solved by imposing constraints on Hosts
other than through an appropriate, real, called-for for years
congestion control mechanism? In other words, the Hosts should worry
about how many connections they need/want and how much data they
can accept over them, and "the net" (all flavors of gateway and
all flavors of comm subnet) should worry about getting bits from
Host to Host. (And if some Hosts "abuse" the net by demanding
character-at-a-time traffic, let 'em--but charge by the kilo-
packet, not the mega-bit.)
In those thrilling days of yesteryear, Multics caused the TIPs to
crash by sending out full-ALL-field's-worths-of-one-bits in NCP's
flow control mechanism (something about they couldn't afford the
table space, assumed nobody would ever send a full allocation,
wound up clobbering the adjacent field...): I played along then,
in the spirit of "all pioneers together," and made the NCP send
small enough ALLs for them to handle, even though Multics was
perfectly happy to accept however many bits it was--but that was
some 15 years ago! "Great Wheel of Reincarnation" notwithstanding,
can't we solve the problems where the problems are yet?
cheers, map
P.S. In my longhand draft of this, I was going to take issue with
the notion that 2 or 4 K "octet" windows are too large, but it
seems like gilding the ragweed compared to the more abstract issue
of rendering unto the Hosts that which is the Hosts' and unto the
net that which is the net's. It's not just an issue of whether
SMTP should be barred from using multiple TCP connections, though.
(To the same Host, of course; presumably even the greatest friend
of fuzzies wouldn't argue that we should force mail through "post
office" sorts of things over single connections with small windows
just to ease the strain on the gateways, when many Hosts are involved.)
Windows are and should be, in my humble but dogmatic opinion, Host
artifacts which pertain to Host-Host flow control; employing them
in lieu of a congestion control mechanism at least violates Layering
and at best is a bad hack.
P.P.S. Apologies for any cryptomapisms herein, it's just that even
if I were up to a fully-"tutorial" treatment--which I'm not--it
doesn't seem worthwhile to burden everybody with all those bytes,
however many connections they go over and however small the windows
are thought to have to be.
-------
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 86 13:36 EST From: Rudy.Nedved@A.CS.CMU.EDU To: PADLIPSKY@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Tails and Dogs
I have yet to hear a solid definition that is not disputed by someone for the terms "gateway", "router", "repeater" and "bridge". I don't believe a gateway simply forwards packets nor do I believe the software in a gateway can be simply stated in a paragraph or less of writing. This is based on CMU's and the ARPA Internet's crazy internet and the myriad of different pieces and functions (everything from 1200 async lines to x.25 virtual circuit lines to satellite links to multichannel broadband networks). Anyhow, the issue is not a congestion one. If you look out your window during rush hour, can you imagine some kinda of congestion control mechanism that will gracefully deal with the problem? I can't but trying to stagger network connections is a big help just like some companies encourage or command employees to show up at different times to help rush hour traffic. Of course, to certain degree rush hour traffic is impossible to solve, just like around CMU we have rush hour printing and mail time at 430 (everyone is trying to do last minute work they put off all day) and then people wonder why their mail has not arrived by 5pm. The concept that a mail delivery system creates a process and connection for each recipient or each host at the same time has got to be a burden on the local system if the mail list is huge. At some point it has to queue things or disaster will strike. Of course I agree that the gateways should shutdown a connection if attempts to limit the load fail since that may be the only way to encourage software builders and maintainers to not abuse resources. Anyone who does not practice software engineering or "using current resources with an eye toward the future" and instead practices the "infinite resource" design concept is going to make the users real sorry (of course the guy has left by then and is doing a research project in another company). -Rudy
-----------[000047][next][prev][last][first]----------------------------------------------------
Date: 11 FEB 86 16:18:06
From: {ATE.R/CHESTNUT}ONTYME@OFFICE-1
To: tcp-ip@sri-nic
Subject: Heterogeneous netAt our location we are planning to (finally) install Ethernet which will connect several machines: 2 vintage VAX-750, a MicroVAX-II, a TI-Explorer, several SUN systems, as well as a few assorted IBM-PC/XT and ATs. We would like to be able to access files on other machines, print on the few laser printers (on the MicroVAX and one SUN), and support remote log-in as much as possible. We are currently gathering information from various vendors but would appreciate any words of wisdom or benefits of experience from the rest of the world. How can the various joys of NFS, TELNET, DECNET, not to mention naked TCP IP be combined? Any responses by phone will also be appreciated: (408) 446-6553 Ron Chestnut
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 86 03:21:23 PST (Wed) From: gds@sri-spam To: tcp-ip@sri-nic.ARPA Subject: 4.2bsd routing strategy for multihomed host
I had a vax running 4.2bsd BBN TCP/IP on our local ethernet, however recently it has acquired an ACC and is attached to an IMP also. Well, today I was looking at our routing tables and playing around with opening connections from other hosts on other networks, and was wondering if my current routing strategy is correct. Since my vax was only on an ethernet, my /etc/gateways file reflects all the other networks as being relative to our arpanet-ethernet gateway. I took a look on another vax (lll-crg) to see what its routing tables and /etc/gateways file look like, and they list all the networks and their associated gateways. It looked to me as if all the reachable networks were in their routing tables also. What I did was to make the arpanet half of the arpanet-ethernet gateway my default gateway, so that when I don't know how to get somewhere directly, I get a redirect from the arpanet-half telling me where to go. I don't have very many entries in my routing tables (perhaps that is because a lot of sites don't connect to us). At any rate, I was wondering if my strategy is correct. To me, it seems that if I can use a smart gateway to tell me where to go, it saves me the trouble of knowing what all the gateways to the reachable networks are. However I am not sure about the side-effects of using a smart gateway -- I have pinged out my gateway on numerous occasions, plus our IMP (107) occasionally goes out of service and needs to be reloaded. For the record, the vax is sri-joyce, usually on 192.5.38.2, and temporarily on 10.2.0.107. --gregbo
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 1986 07:28:23 CST From: DDN-REQT@GUNTER-ADAM.ARPA To: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA> Cc: TCP-IP@SRI-NIC.ARPA, DDN-REQT@GUNTER-ADAM.ARPA Subject: Re: TCP/IP via X.25 connection to DDN
You'rree NOT wrongf! However, PSN Release 6.0 will allow X.25 /w/TCP-IP to talk to 1822 w/TCP-IP. I don't have a schedule for release of 6.0. Regards Darrel B. -------
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 86 19:49:34 EST (Wed) From: "Thomas Narten" <narten@Purdue.EDU> To: gds@sri-spam.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: 4.2bsd routing strategy for multihomed host
We also have one connection to the Internet, but we have several local nets as well. We have a dedicated gateway (taliesyn) that is connected to an ARPANET IMP. We run routed on all our machines, our /etc/gateways are set up so that the ONLY entry in it is for a default route to taliesyn. We do this only for all machines that are on the SAME LAN as taliesyn. All other machines have an empty /etc/gateway's file. They pick up a default route through one of the machines on the same network as taliesyn. The nice thing about this is that there are no static routes. The default route (which you might say is static) is only used as a last resort. If taliesyn is down, the route is bogus, but you are cut off from the Internet so it doesn't matter. The other routes that get exchanged are for the local nets of which there aren't that many. Thomas ----------
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Thu 13 Feb 86 01:37:30-MST From: Jay Lepreau <Lepreau@UTAH-20.ARPA> To: mills@DCN6.ARPA Cc: hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Conversations with an Ethernet watcher
Re multiple SMTP connections: what do you want, a hung connection to one host "forever" to prevent any further connections to that host? Personally, I don't. To further abuse the highway analogy-- if I send a car out to deliver something and it doesn't arrive, it could be caught in rush hour traffic but it could also have had an accident. -------
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Thu, 13 Feb 86 3:29:11 EST From: Ron Natalie <ron@BRL.ARPA> To: tcp-ip@sri-nic.ARPA Subject: IPTO-FACTO
Does anyone know why the IPTO gateway on ARPANET is sending ICMP redirects to my MILNET hosts? -Ron
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 1986 05:14-EST From: CERF@USC-ISI.ARPA To: PADLIPSKY@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Tails and Dogs
One of the wonderful things about layered architectures is that they have a tendency to result in resource allocation problems in each layer. Generally, the solution to the resource allocation problem at one layer (congestion control, flow control, Receiver not Ready ....) does nothing for the resource allocation problem at some other layer. As a consequence, we seem to relearn now and then that we have to invent resource allocation strategies for each layer to use to protect its resources. The methods may vary from layer to layer, of course, depending on the functionality of the layer, the freedom it may have to discard information (or lack of freedom to do so), etc. The best example I can think of is in a packet net - there may be end to end flow control above the network layer (e.g TCP) and flow control on the access link (e.g. HDLC), but the network needs internal (end/end) flow control to avoid lockups and store/forward congestion control to deal with trunking/tandem resource limits. The biggest challenge in communication system design is recognizing all these various limitations and figuring out a constellation of resource allocation strategies which are consistent and which can yield high performance. Usually, this requires that one look at the problem at all (or at least, several) layers at once and not focus solely on one layer and hope that solving its problems will solve all of them - it will simply move the place where congestion occurs to someplace else... like a balloon filled with water; you squeeze here and it pops out there. Vint
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 1986 05:25-EST From: CERF@USC-ISI.ARPA To: CLAUSEN@USC-ISID.ARPA Cc: TCP-IP@SRI-NIC.ARPA, clausen%UKans@CSNET-RELAY.ARPA Subject: Re: hello
Horst, I see you got a fairly positive answer already on your question - nice having all those hundreds of people to query! Glad to see you back on the net. How is Kansas? Sigrid sends her best regards. Vint
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Thu, 13 Feb 86 18:50:54 -0800 From: karels@monet.berkeley.edu (Mike Karels) To: mills@dcn6.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: Conversations with an Ethernet watcher
Dave, I was most tempted to flames by your first message in this series, but restrained myself to see what other reactions would be. Fortunately, others have beaten me to the punch. Concerning the Unix mailer (sendmail), though, I'd like to add an informational point. The major reason that multiple connections are made to a single destination host is that mail is not queued separately for each host. I have long wanted it to do so, and I believe that the program's author now agrees. My reasons have more to do with serializing the work when a major mail node has been down or unreachable than with easing the task of the gateways. If ucbvax is down for a day, innumerable connections are received from everywhere as soon as it comes up. Only by cutting off new connections when the machine overloads can it avoid disaster. However, the amount of work required to change sendmail's way of doing business is nontrivial, and I don't know who will take on such a problem. Mike
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 86 14:48:00 PST From: <gary@acc.arpa> To: "sutter" <sutter@ohio-state> Cc: blumenthal@bbn-unix,tcp-ip@sri-nic Subject: HP 3000 support
Bob, You need to speak with Steve Blumenthal at BBN. They have an implementation for the HP 3000, that handles TCP/IP, user and server Telnet, user FTP, and unfortunately no SMTP support. It uses a INP as the interface to the network which will support either 1822 or HDH. Hope that helps, Gary Krall ------
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 1986 17:07:30 PST From: MOCKAPETRIS@USC-ISIB.ARPA To: mills@DCN6.ARPA, Lepreau@UTAH-20.ARPA, hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA Cc: MOCKAPETRIS@USC-ISIB.ARPA Subject: Re: Conversations with an Ethernet watcher
In response to the message sent 13-Feb-86 19:38:33-UT from mills@dcn6.arpa Dave, At ISI we run a TOPS-20 mail receiver that uses separate subprocesses to receive mail on multiple simultaneous connections. The number of subprocesses is limited to 5, and a status program displays the number of subprocesses active plus the max which were ever needed simultaneously. Typical behavior is 0-3 subprocesses with open connections at any time, and it's a rare day which never sees a need for all 5. paul -------
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Thu, 13 Feb 86 15:02:18 est From: Bob Sutterfield <sutter@ohio-state.ARPA> To: net.dcom@ohio-state.ARPA, net.lan@ohio-state.ARPA, net.mail@ohio-state.ARPA, net.wanted@ohio-state.ARPA, tcp-ip@sri-nic.arpa Subject: TCP/IP for HP-3000
We need to connect a VMS VAX (of which I am the System Manager) with a Hewlett-Packard 3000 series machine (of which the System Manager has no net access). Minimal service level will be dial-up mail, though the rest would be nice, too. It seems that our best bet will be to run TCP/IP on both. I've run QUERY on sri-nic and seen that there are several hosts listed as being HP-3000s. However, in "sri-nic:<netinfo>tcp-ip-implementations.txt" there is no mention of a TCP/IP implementation for the HP-3000. Where do I try next? Any other ideas? Thanks for your help... ----- Human: Bob Sutterfield Mail: sutter@osu-eddie.UUCP sutterfield-r%osu-20@osu-eddie.UUCP or: sutter@ohio-state.ARPA sutterfield-r%osu-20@ohio-state.ARPA
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Thu, 13 Feb 86 19:10:11 EST From: Mike Muuss <mike@BRL.ARPA> To: mills@dcn6.arpa Cc: JayLepreau <Lepreau@utah-20.arpa>, mills@dcn6.arpa, hoey@nrl-aic.arpa, tcp-ip@sri-nic.arpa Subject: Network Mail Observations
BRL machines processes lots of mail, and so does the CSNET-Relay, but with different patterns of usage. The busier BRL machines handle 200-1000 messages/day, but with an average of like 200 recipients/message, some local, many not. (Statistics here are aproximate, from memory from the last time I looked, half a year ago). To handle incoming mail, we permit two simultaneous SMTP servers; this seems fine. To handle outgoing mail, our busier machines run from 3 to 5 deliver processes. There are (strict) timeouts on all parts of the SMTP dialog (different timeouts at different stages), so that none of the delivery processes "hang up" for very long. This may have the occasional side effect of "ganging up" on some recipient host. If that host is also implementing a policy of limiting the number of inbound connections, then this can't ever get too bad. From hours of watching the SMTP dialogs (in a spare window), it seems to me that a lot of delivery time is spent engaged in the back-and-forth validation of the recipient addresses, one at a time. With the majority of our messages going to several people at any given site, and the very long round-trip times through the core during the daytime (RTT from MILNET in Maryland to ARPANET in California runs 3-12 seconds in the daytime), this is a non-trivial factor. For people at the end of low-bandwidth pipelines, the transmission of the data portion of the message tends to take most of the time. (We require a recipient host to accept data at a minimum rate of about 300 baud plus a constant, or we timeout the transmission). Overall, we feel that our mail system is pretty well balanced, and represents a significant, but reasonable, load on our systems. (If anybody cares, we run MMDF II and IIb on 4.2 and 4.3beta UNIX systems). The single biggest improvement for our mail traffic would probably come from better core gateway performance (jab jab). The next biggest improvement would come from additional bandwidth on our IMP (more trunks). And speaking of which, I heard a rumor that a recent (last 3-4 months) change to the IMPs changed the behavior of the IMPs w.r.t. traffic originating at the IMP -vs- through traffic. (To more strongly favor through traffic). On the face of it, this is probably the right thing to do for overall system optimization. However, we noticed a SERIOUS loss of available bandwidth, a loss which seems to have only partly been restored. Am I dreaming? Best, -Mike
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 86 22:44 PST From: Jeff Makey <Makey@LOGICON.ARPA> To: TCP-IP@SRI-NIC.ARPA Cc: Makey@LOGICON.ARPA Subject: Choosing a gateway
There are quite a few gateways between the ARPANET and the MILNET.
What is a good strategy for choosing a gateway between two nets when
more than one exists? It seems to me that some relevant factors are:
(1) whether a gateway is up at the moment I want to use it;
(2) how heavily a gateway is loaded; and
(3) the distance (in terms of IMP hops) from my host to a gateway.
How can my TCP/IP daemon evaluate these factors? Is there an RFC or
some other available documentation that will answer these questions?
:: Jeff Makey
Makey@LOGICON.ARPA
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 13-Feb-86 19:38:33-UT From: mills@dcn6.arpa To: JayLepreau<Lepreau@UTAH-20.ARPA>, mills@DCN6.ARPA, hoey@NRL-AIC.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Conversations with an Ethernet watcher
Jay, I don't want to prolong the agony more than the issue justifies, so subsequent bickering should probably be restricted between us. However, to your point: Each of your SMTP connections - one or more - should have a user timeout in any case, so that your concern more properly is represented by the question whether more than a single such connection can deliver the throughput required in the face of occasional (likely) temporary hangups. It's not hard to generate an engineering answer to this question, given the expected (or measured) incidence of hangup, timeout interval and so forth. Next, you compute the network bandwidth necessary to accomplish all the successful and not-so-successful transactions, then construct a requirements analysis, then procure the necessary bucks. When the last step fails you go back and try to make what you can afford work the best way it can, which was the point of my memo. I would be tickled pink to participate in an exercise designed to explore the scenario space of our present mail system. Can you (or anyone) at some "busy" site provide data on the number of SMTP agents active at any time, retransmission parameters, failure messages and all that stuff? Ed Cain of the Testing Task Force has been stirring that pot as well. I have rather extensive logs on our fuzzies, but the volume of mail traffic is underwhelming. Dave -------
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 86 10:32:01 PST (Fri) From: Milo S. Medin (NASA ARC Code ED) <medin@orion.ARPA> To: mills@dcn6.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: Killing time
Very interesting Dave. I've got a few SUN's lying around, feel free to send the data to me, or point me to it on dcn9 (my account there still works). Thanks, Milo
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 86 10:46:17 PST (Fri) From: Milo S. Medin (NASA ARC Code ED) <medin@orion.ARPA> To: "Milo S. Medin" (NASA ARC Code ED) <medin@orion.ARPA> Cc: mills@dcn6.arpa, tcp-ip@sri-nic.arpa Subject: Re: Killing time
Sorry folks, hit the wrong type of reply, and it was too late to stop it when I realized what happened... Milo
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 14-Feb-86 04:48:45-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Re: Confessions of an Ethernet watcher
Mike, Mike and Paul, I'm finding this exchange highly informative, although it was certainly not my intent in starting this off to provoke flames or even warm gases. Whether any of us realized it or not, thorughout the spectrum from the TOPS-20s to the scruffy fuzzballs, we are building real networks, even if the nodes are mailer and femailer entities and the links are flaky transport-level connections. You guys and others here have raised issues of congestion, routing, flow control and fairness, not to mention multicasting and alternate-route fallback. Wonderful! This scenario is being studied by the Testing Task Force, chaired by Ed Cain of DCEC. Ed has been clamoring for hard data, which from your and my watches is available only by holographing our eyeballs. More reports like yours would be warmly welcomed. Especially useful are reports on mean aggregate traffic per day and per busiest hour, as well as typical and maximum simultaneous transport connections (for mailer and femailer separately). Of particular interest would be the strategy used in response to errors: requeueing interval and priority, dependency on type of error and position in the protocols stack. Hard data on the incidences of such errors, such as might be captured in the system log file, would be invaluable. It would also be useful to have a sketch of the queueing discipline, connection-service discipline and fairness principles, as well as a description of any special mechanisms for congestion and flow controls. I'm not sure I want to volunteer to manage the collection and distribution of such a trove, but I would be glad to tickle the discussion and contribute what interesting data I can collect. It is my view, as expressed in several fora, that the effort to collect this kind of information and construct an appropriate network-mail model is a legitimate research area which should be funded accordingly. Dave -------
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Fri, 14 Feb 86 10:27:28 EST From: Ron Natalie <ron@BRL.ARPA> To: CERF@usc-isi.arpa Cc: PADLIPSKY@usc-isi.arpa, tcp-ip@sri-nic.arpa Subject: Re: Tails and Dogs
CERF: One of the wonderful things about layered architectures is that they have a tendency to result in resource allocation problems in each layer. Layered Architectures are like Onions. They're smelly and make you cry a lot. -Ron
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 14-Feb-86 07:37:08-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Killing time
Folks, It has been about six months since the series of experiments on Internet clock synchronization reported in RFC-756 et seq, so I thought you might enjoy a capsule description of a recent repeat of some of them. Some fascinating (at least to a slightly fractured bunch of us) phenomena seem to be oozing from the data which might have to wait detailed archeological excavation; however, some tidbits sticking from the murk are relishable in this note. The experiments involved sending datagrams between intrepid fuzzball DCN6 to each and every one of the 2135 hosts listed in the latest NIC file HOSTS.TXT. Three protocols were used, one with ICMP Timestamp messages, a second with the TIME protocol based on UDP and the third with the new NTP protocol, also based on UDP. Four messages in each of the three protocols were sent to each host and each reply recorded and processed to produce an offset estimate representing the difference, in milliseconds, between the clock at the target machine and the clock at DCN6. The DCN6 clock is synchronized using local-net protocols to within a few milliseconds of a WWVB radio clock, so for the purposes here its clock can be considered a reference standard. Before describinb the results of the experiments themselves, it might be of interest (says he coyly) to reflect on the health of the Internet innards in which these datagrams were digested. The following menus summarize the metabolic products of the three-course meal, which took over 24 hours and 25000 datagrams to swallow. ICMP Timestamp, UDP/NTP and UDP/TIME volleys were sent to each host one after the other, so that accurate comparisons could be made between them. If at least one valid reply was received for a protocol, the volley was recorded as successful; while, if not, the last received error message (if available) or "no response" was recorded. 2135 ICMP timestamp request sent 722 ICMP timestamp valid reply 72 ICMP invalid timestamp reply (marked unknown or invalid time) 170 ICMP host unreachable 111 ICMP net unreachable 11 ICMP time exceeded (probably a loop) 4 Local host down 1215 No response 2135 UDP/TIME request sent 229 UDP/TIME valid reply 4 UDP invalid packet format (echo host swapped ports) 161 ICMP host unreachable 114 ICMP net unreachable 433 ICMP port unreachable (TIME not implemented) 42 ICMP protocol unreachable (UDP not implemented) 11 ICMP time exceeded (probably a loop) 4 Local host down 1137 No response 2135 UDP/NTP request sent 24 UDP/NTP valid reply 178 ICMP host unreachable 115 ICMP net unreachable 521 ICMP port unreachable (NTP not implemented) 42 ICMP protocol unreachable (UDP not implemented) 10 ICMP time exceeded (probably a loop) 4 Local host down 1241 No response The most disturbing feature of the above is the astonishing incidence of black holes (no response). The scarred old warriors among us hate these things passionately, since they often result in long hours of snoop when something breaks. A little prying revealed that some number of these were the result of dropping an otherwise valid reply due to IP or UDP format or checksum problems at the sender. These provoke more deja vu than surprise, since similar bugs have been reported and re-reported in famous implementations for years. One inspired felon even returned all ICMP error messages with a runt ICMP header too short by four octets. I did manage to explain all the ICMP-time-exceeded and local-host-down complaints (except one) as originating in our swamp. Turning now to the valid sample population, it is apparent that the discipline of the truth-timetellers is somewhat better than last time - only one host was found nearly exactly one day off (sic) and two were found with blatently nonsense ICMP times. Taking just the 139 hosts (298 total replies) with samples from two or more of the three protocols, for example, reveals the following summary: Host Address ICMP NTP UDP Notes ------------------------------------------------------------------------- DCN6.ARPA [128.4.0.6] 0 -48 612 DCN-WWVB.ARPA [128.4.0.15] 1 -466 WWVB echo ETAM-ECHO.ARP [4.0.0.62] -3 105 -199 IP echo ISI-ECHO.ARPA [10.1.254.27] -6 26 -22 IP echo DCN5.ARPA [128.4.0.5] 7 -20 -168 DCN1.ARPA [128.4.0.1] -8 -35 -162 DCN8.ARPA [128.4.0.8] -21 -29 -514 GW.UMICH.EDU [35.1.1.1] -48 -7 -219 TANUM-ECHO.AR [4.0.0.64] -48 3528 -3718 IP echo WWV.UMICH.EDU [35.1.1.17] -58 -627 WWV echo FORD1.ARPA [128.5.0.1] 62 -6 -16 DCN-WWV.ARPA [128.4.0.14] -75 -11 WWV echo UMD1.UMD.EDU [128.8.0.1] 100 55 360 SATNET-ECHO.A [4.0.0.40] 277 180 703 IP echo GOONHILLY-ECH [4.0.0.63] 294 141 -3021 IP echo XYZZY.UMICH.E [35.1.1.3] -321 -315 -578 RAISTING-ECHO [4.0.0.77] 479 -12 -4821 IP echo ORNL-MSR.ARPA [26.3.0.41] 497 -915 STC.ARPA [128.16.9.9] -665 3 -2858 IP echo SALLY.UTEXAS. [10.2.0.62] -1478 -2542 AMES.ARPA [26.0.0.16] -1490 -1294 -1408 IPTO-FAX.ARPA [192.5.18.51] -1975 -2119 -1882 IPTO-ECHO.ARP [192.5.18.52] -2000 -627 UDP echo ORION.ARPA [192.12.49.2] 2074 914 1314 USC-OBERON.AR [10.0.0.121] 2484 932 ROCHESTER.ARP [10.0.0.15] 3633 2500 SCORPIO.THINK [192.5.104.195] 5196 4395 C.CS.UIUC.EDU [192.5.69.3] 5242 4568 MIT-MULTICS.A [10.0.0.6] -6606 -7651 BRAND.USC.EDU [192.5.10.61] 7887 6792 DWORKIN.USC.E [192.5.10.64] 8516 7306 GRANITE.ARPA [128.45.0.101] -10023 -10790 A.CS.UIUC.EDU [10.3.0.37] -10373 -10988 ICSC.UCI.EDU [192.5.19.3] 10414 9654 ICSD.UCI.EDU [192.5.19.4] 11184 12025 NETWOLF.UMD.E [128.8.1.13] -11498 -12204 COLUMBIA.EDU [10.3.0.89] -11868 -14486 NYU-CSD2.ARPA [192.5.15.132] -14138 -14036 DOCKMASTER.AR [26.0.0.57] -15842 -17585 DCN9.ARPA [128.4.0.9] -16860 -16866 -17677 NOSC-GUPPY.AR [128.49.0.3] -17211 -17908 TRANTOR.UMD.E [128.8.0.14] 17922 17938 16846 HI-MULTICS.AR [10.1.0.94] 21274 20242 TB.CC.CMU.EDU [128.2.253.34] 22848 24304 SU-SAFE.ARPA [36.44.0.193] 25114 25908 PATCH.ARPA [26.6.0.2] -26211 -27396 BBNCC5.ARPA [128.89.0.88] -27836 -32280 ATRP.MIT.EDU [18.85.0.3] 30453 29554 NPRDC-PACIFIC [192.5.65.2] -31432 -32233 TF.CC.CMU.EDU [128.2.253.38] 33023 34611 GARFIELD.COLU [128.59.16.2] -36358 -35630 TC.CC.CMU.EDU [128.2.253.35] 39542 40695 USGS2-MULTICS [26.0.0.69] -45500 -46397 B.CS.UIUC.EDU [192.5.69.2] -51185 -52065 CU-ARPA.CS.CO [10.3.0.96] -54810 -55610 ICSE.UCI.EDU [192.5.19.5] -58193 -59623 USC-ISIC.ARPA [10.0.0.52] -59430 -59212 TD.CC.CMU.EDU [128.2.253.36] 59699 60560 NPRDC.ARPA [26.3.0.3] 67029 64915 UCI.EDU [192.5.19.1] -70709 -71224 CIP3.UCI.EDU [192.5.19.8] -74679 -76161 SU-AIMVAX.ARP [36.45.0.193] 84666 83903 NYU-ACF5.ARPA [192.5.15.13] -88445 -91559 MERLIN.PURDUE [192.5.48.3] 88691 87860 MITRE-BEDFORD [26.3.0.66] 90742 90366 NS2.CS.UCL.AC [128.16.5.2] 97395 96411 MEDIA-LAB.ARP [18.85.0.2] 100189 99256 TE.CC.CMU.EDU [128.2.253.37] 107915 108221 CIP4.UCI.EDU [192.5.19.11] -109144 -109610 BLAYS.PURDUE. [128.10.2.7] 123395 119781 FAS.RI.CMU.ED [128.2.254.138] -129306 -130533 CAD.CS.CMU.ED [128.2.254.133] -134145 -135394 THEORY.CS.CMU [128.2.254.182] -137348 -138211 GANDALF.CS.CM [128.2.254.140] -139830 -140677 CIVE.RI.CMU.E [128.2.254.177] -139857 -140732 H.CS.CMU.EDU [128.2.254.156] -140138 -141135 SAM.CS.CMU.ED [128.2.254.181] -140886 -141504 K.CS.CMU.EDU [128.2.254.137] -143272 -144436 SENSOR.RI.CMU [128.2.254.147] -144797 -145883 SPEECH1.CS.CM [128.2.254.145] -145322 -146576 ME.RI.CMU.EDU [128.2.254.142] -145774 -146565 CIP.UCI.EDU [192.5.19.6] -146244 -146019 NYU-ACF2.ARPA [192.5.15.9] 146843 145399 C.CS.CMU.EDU [10.3.0.14] 149915 150837 IUS1.CS.CMU.E [128.2.254.128] -150642 -151298 VI.RI.CMU.EDU [128.2.254.158] -150781 -151567 SPICE.CS.CMU. [128.2.254.139] -151411 -152188 ARM.RI.CMU.ED [128.2.254.151] -152310 -153136 MAPS.CS.CMU.E [128.2.254.184] -152825 -153692 ISL1.RI.CMU.E [128.2.254.143] -154190 -155976 ML.RI.CMU.EDU [128.2.254.178] -155618 -156754 IUS2.CS.CMU.E [128.2.254.176] -157583 -158408 A.SEI.CMU.EDU [128.2.254.131] -158382 -159449 SU-MOJAVE.ARP [36.10.0.14] -162822 -163537 SPEECH2.CS.CM [128.2.254.179] -165127 -166118 SU-SONOMA.ARP [36.20.0.99] -167543 -167882 PT.CS.CMU.EDU [128.2.254.155] -198025 -198966 MITRE.ARPA [26.0.0.17] 201594 200484 NYU.ARPA [26.0.0.58] 207805 207160 SU-ARGUS.ARPA [36.9.0.10] -216438 -216367 ROVER.RI.CMU. [128.2.254.157] -218641 -219583 MIT-HERA.ARPA [18.58.0.3] -226707 -227641 MIT-APOLLO.AR [18.58.0.10] -233509 -234152 SU-HELENS.ARP [36.2.0.5] 241465 240527 MIT-DEMETER.A [18.58.0.4] -265113 -266357 MIT-APHRODITE [18.58.0.12] -265862 -266957 MIT-CASTOR.AR [18.71.0.5] -267411 -268406 MIT-ATLAS.ARP [18.58.0.15] -268763 -269762 MIT-HELEN.ARP [18.71.0.11] -269498 -270900 MIT-HECTOR.AR [18.71.0.13] -275008 -275890 MIT-THESEUS.A [18.71.0.2] -280386 -281468 MIT-ARTEMIS.A [18.58.0.11] -282770 -283816 MIT-ORPHEUS.A [18.71.0.4] -286828 -287853 MIT-MENELAUS. [18.71.0.17] -294194 -294229 SU-FUJI.ARPA [36.2.0.9] 295277 294896 MIT-JASON.ARP [18.71.0.7] -296300 -297382 MICRO.UDEL.ED [192.5.39.4] 297334 296792 MIT-PRIAM.ARP [18.71.0.14] -300702 -301975 MIT-PARIS.ARP [18.71.0.12] -301652 -302932 ATHENA.MIT.ED [18.58.0.1] -301792 -303244 MIT-ODYSSEUS. [18.71.0.15] -303007 -304354 MIT-ZEUS.ARPA [18.58.0.2] -305836 -307120 MIT-HERACLES. [18.71.0.3] -309782 -310816 RADC-MULTICS. [26.0.0.18] -313852 -314576 MIT-POSEIDON. [18.58.0.6] -321949 -322546 DEWEY.UDEL.ED [192.5.39.2] 322621 322913 SU-COYOTE.ARP [36.18.0.215] -322956 -323303 BBNG.ARPA [192.1.2.67] -331109 -331111 UW-KRAKATOA.A [192.5.8.45] -333876 -334815 MIT-AGAMEMNON [18.71.0.16] -341461 -342518 NYU-ACF4.ARPA [192.5.15.133] -419460 -420123 CIP2.UCI.EDU [192.5.19.7] -435654 -435619 SU-LINDY.ARPA [36.9.0.11] -449513 -448490 VLSI.CS.CMU.E [128.2.254.129] -480627 -481678 NYU-CSD1.ARPA [192.5.15.131] -715648 -717005 SU-PESCADERO. [36.8.0.8] -751799 -751814 AMES-ATLAS.AR [192.12.49.50] -792499 -793442 S1-A.ARPA [26.1.0.95] 114428000 -773226 SU-AI.ARPA [10.0.0.11] 115126000 -76368 Notes WWVB echo Synchronized to WWVB radio; swaps addresses and ports WWV echo Synchronized to WWV radio; swaps addresses and ports GOES echo Synchronized to GOES satellite; swaps addresses and ports UDP echo Swaps addresses and ports IP echo Swaps addresses If anybody is interested in further details, raw data or pretty pics to light up your Sun, please tinkle me directly. Dave -------
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 1986 12:41:47 EST From: PADLIPSKY@USC-ISI.ARPA To: CERF@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Tails and Dogs
In response to your message sent 13 Feb 1986 05:14-EST Vint-- Always good to hear from you, especially on the present topic, and even more especially since it lets me avoid being churlish (which would have been the case had I had to answer the other response independently; now I can merely observe that I'm sure you agree that in the context of the TCP-IP "bulletin board" Gateways must be IP Gateways unless otherwise specified and connections must be TCP connections U.O.S. and hence Gateways can't drop connections, without being explicitly rude to "Rudy.Nedved" [if I remember aright], and I might even go so far as to imagine you'd agree that it's at best peculiar to enter a discussion with a declaration that you don't believe the terms being discussed can be defined). [Well, I never said it would let me avoid being a little snide, but good grief, this isn't SF-Lovers! I mean, I'll apologize if he was being facetious about undefinability --though the business about Gateways dropping connections certainly suggests that he's not using our definitions--but it really is annoying, and rather insulting, to get a message that in essence says Since I don't know what you're talking about, you can't know what you're talking about. (That's probably more than the incident's worth--but you should have seen my longhand draft of a day or two ago.)] At any rate, subject to a little interpretation of the last paragraph I find myself in complete agreement with your comments-- particularly the second paragraph, which I take to be an elegant statement of what I was trying to say in the first place. The real question, in my mind, anyway, is what's meant by "looking at" the layers severally. Consider the (I think treacherous) analogy to staggered work hours and traffic congestion: what if somebody said Gee, that works so well that not only will we make it mandatory, we'll also send traffic cops into the buildings and have them turn off the elevators and lock the stairwells so those damn commuters can't flood our scarce street resources? Not only bad safety engineering practice, but really dubious on Constitutional grounds, yes? Well, isn't it even more dubious on Layering grounds to HAVE TO use fewer TCP connections or HAVE TO send out fewer datagrams (in the full awareness some will have to be retransmitted)? That is, it's perfectly licit to expect the Hosts to use the net intelligently, but when push comes to shove the net's there for the Hosts' benefit, not conversely, so the net has no business "demanding" the Hosts' lay off--except, of course, by giving the Gateways-part-of-the-net an analogue to the IMPs' ability to keep the ready line down (or whatever the equivalent is in HDLC/LAP B/whatever). And strong though my feelings are against arguing with the inventors of things about what the things are for, if you of all people support the use of TCP windows for something other than Host-Host flow control, well, let's step into the nearest time machine and go back around a dozen years and talk about what's wrong will NCP ALL again. Another way of attempting to express my concern is that while I have considerable sympathy (and even empathy) for people who are trying to split logs with toy hatchets because nobody will give them real ones, and will even buy whatever wood they can generate for me, I don't think they've got any business telling me I shouldn't look for somebody with a chain saw if I need more wood to keep the house warm enough to live in. I'm not asking for "infinite resources," just appropriate technology. But that's probably what your last paragraph meant anyway... and I daresay Dave wouldn't really let the cops lock the stairwells, even if I'm not so sure what he'd do with the elevators.... cheers, map -------
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 1986 14:11:39 EST From: PADLIPSKY@USC-ISI.ARPA To: CERF@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Tails and Dogs
In response to your message sent 13 Feb 1986 05:14-EST Ooops. Realized while suffering through lunch (dental anguish, not worse than usual provender) that I should have said give the Gateways an APPROPRIATE analogue to the ready line, since if Source Quenches and (or?) Redirects worked I'm confident Dave wouldn't have (inadvertantly?) gotten me started on this tack. And, since a new msg came in just now: I'll defer to your rejoinder in re Onions...unless you can't come up with anything better than IF you know how to deal with them, onions CAN be a tearless way of adding indispensible flavor to certain recipes. re-cheers, map -------
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 86 18:03:52 GMT From: Brian Goodmon <goodmon%encore.uucp@BRL.ARPA> Subject: The LAN's Prayer
Rwhod who art in /etc, well-known be thy port; thy packets come, thy protocol be done, in user space as it is in kernel. Give us this day our daily dump, and forgive us our bugs as we forgive those who submit SPR's against them. Lead us not into address resolution, and deliver us from ISO. For thine is the transport and the session and the physical forever, EOF.
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 1986 23:30-EST From: CERF@USC-ISI.ARPA To: sutter@OHIO-STATE.ARPA Cc: net.dcom@OHIO-STATE.ARPA, net.lan@OHIO-STATE.ARPA net.mail@OHIO-STATE.ARPA, net.wanted@OHIO-STATE.ARPA tcp-ip@SRI-NIC.ARPA Subject: Re: TCP/IP for HP-3000
BBN did a TCP/IP for HP3000. Also, I believe HP is doing one as well, although I don't think it is in product form as yet. Vint Cerf
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 14-Feb-86 21:48:34-UT From: mills@dcn6.arpa To: MiloS.Medin(NASAARCCodeED)<medin@orion.ARPA>, mills@dcn6.arpa, tcp-ip@sri-nic.arpa, Re:Killingtime@DCN6.ARPA Subject: Re: Killing time
Milo, Snarf *.BIT on DCN1, ANONYMOUS, GUEST, then light up your Sun with screenload. Dave -------
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Sat, 15 Feb 86 09:08:53 EST From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU> To: tcp-ip@SRI-NIC.ARPA Subject: comments about Bridge Communication's IP bridge.
I have two ethernets *almost* connected by a 56KB line. Almost because I have the V.35 connectors staring into space waiting for me to decide what bridge/gateway to buy. The Bridge Inc box is an attractive off-the-shelf hardware combination of 68000/ETHERNET-BOARD/SERIAL-BOARD/FLOPPY-BOOT-DISK if anything else. What experiences have people had (if any) with their IP bridging software. Does anyone have their own software for the box? -gjc
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 1986 09:58-EST From: CERF@USC-ISI.ARPA To: PADLIPSKY@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Tails and Dogs
Mike, There was an old joke once about crossing an onion with a donkey and getting a piece of ass that brought tears to your eyes. I suppose one might say the same thing about crossing architectures with onions, although I am not sure what the connotations are. I was not advocating that the TCP level of flow control be used, somehow, to protect the network - just the opposite. The point is that the network (lower) layer must have mechanisms to protect its resources DESPITE the presence of the higher level end/end flow control. This does NOT, however, mean that one should design systems by deliberately being blind to how things work. John Nagle's recent RFC's and Dave Mills' work on tiny pipes/flow control algorithms are manifestations of the Jack Haverty school of engineering: "the smarter you are about the environment, the better you can tune the system to give optimum performance." The hard line to draw or engineering judgement to make is when to deliberately ignore specific information or not rely on it to achieve greater generality, but probably at the cost of poorer performance. Much of the initial INTERNET design deliberately took the latter approach in the interest of bringing an experimental facility into being from which we could learn in what ways it made sense to be "smart." Hope this makes my point a bit more clearly. Vint
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 16-Feb-86 22:10:23-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Incestuous clockwatching
Folks, I have had several messages of the general form "Why didn't my host show up in your list of clock respondents?" If said host did not respond to at least two of the three protocols: ICMP Timestamp, UDP/NTP or UDP/TIME, it was intentionally not included. In almost all cases those hosts that responded with UDP/NTP or UDP/TIME responded also to ICMP Timestamp. Accordingly, for those of you who are interested, I have put up the file TIME.TXT on DCN1 (ANONYMOUS/GUEST) containing all the IMCP Timestamp responses ordered by (apparent) subnet. Examination of the data in that file, by the way, suggests some revealing insights. The intent of the experiment that produced the file was to determine to what extent local nets tend to cluster closely around the "wrong" time, presumably due to incestuous clockwatching. In some local nets this tendency is readily apparent, with almost all hosts eagerly tracking some tens of seconds or minutes off with maybe a few broken or defiant exceptions. This has interesting implications for the design of synchronization algorithms such as suggested in RFC-956, since a large local net could in principle "take over" the world of clocks with the wrong time. Interestingly enough, however, the clustering algorithm of RFC-956 was fed the entire data base collected in last wwek's experiment, but it still came up with the "real" time to within a few millisceonds. For the crew working on NTP implementations, the following list of known reference hosts and clocks is as follows, along with the unsmoothed offset (milliseconds) measured with respect to DCN6 just to give you some idea of the accuracies that can be expected. The best accuracies are normally obtained with ICMP Timestamp (I), with UDP/NTP (N) next and UDP/TIME (U) last. The hosts marked * are corrected to agree to zero offset relative to radio time, but only with ICMP Timestamp. The offsets shown are almost completely dominated by network-delay dispersion, except for UDP/TIME, which has an inherent precision of one second. P Host Name Address Offset -------------------------------------- I GW.UMICH.EDU [35.1.1.1] -30 N GW.UMICH.EDU [35.1.1.1] -152 U GW.UMICH.EDU [35.1.1.1] -118 I UMICH-WWV.UMI [35.1.1.17] 58 * I DCN1.ARPA [128.4.0.1] -9 N DCN1.ARPA [128.4.0.1] 8 U DCN1.ARPA [128.4.0.1] -73 I DCN-WWV.ARPA [128.4.0.14] -14 * I DCN-WWVB.ARPA [128.4.0.15] -60 * I FORD1.ARPA [128.5.0.1] 49 N FORD1.ARPA [128.5.0.1] 40 U FORD1.ARPA [128.5.0.1] -167 I FORD-GOES.ARP [128.5.0.19] 36 * I UMD1.UMD.EDU [128.8.0.1] -183 N UMD1.UMD.EDU [128.8.0.1] -81 U UMD1.UMD.EDU [128.8.0.1] 656 I UMD-WWVB.UMD. [128.8.0.4] 174 * Dave -------
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 86 10:51:21 EST (Mon) From: Mike Brescia <brescia@BBNCCV.ARPA> To: Ron Natalie <ron@brl.ARPA> Cc: tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA Subject: Re: IPTO-FACTO
Does anyone know why the IPTO gateway on ARPANET is sending ICMP redirects
to my MILNET hosts?
Ron,
There were three separate factors which conspired together (&&) to cause the
newly installed IPTO butterfly gateway to send you (and others) redirects.
1. the redirect code did not include the test that the IP source of the packet
must be on the same net as the gateway's input interface to permit a
redirect to be sent.
2. the butterfly gateway includes minimal GGP code to advertize its own
connected net (ARPA-LAN, 192.5.18, in this case) to those 'core' gateways
which ask.
3. the butterfly gateway was plugged in to replace an lsi-11 'core' gateway,
but the plug transfer was done too fast (5 seconds rather than 5 minutes)
for the other core gateways to notice the fact that a core gateway had gone
away.
Because of (3), the core gateways did not get any new information from
IPTO which would have only listed the ARPA-LAN net. This meant that when some
nets went down, a route was mistakenly thought to exist through IPTO.
Because of (1), IPTO was sending redirects for these packets not only to
arpanet hosts, but also to hosts on milnet and other nets farther out.
On Thursday morning, about 1100 EST, the IPTO gateway was brought up after
being down for at least 10 minutes, forcing the core gateways to clear out the
extraneous information. Friday, the gateway was reloaded with the redirect
bug fixed.
Mike Brescia
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Tue 18 Feb 86 03:40:13-EST From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU> To: tcp-ip@SRI-NIC.ARPA, egp-people@BBN-UNIX.ARPA Cc: mit-ip-people@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU Subject: More EGP musical tables
OK, we have run out of a different kind of table resource in the EGP core gateways. (Yow, am I having *fun* yet?) This time, you don't even get to be a neighbour; there is no table space for new EGP neighbours. This happened to the MIT-AI-GW. It couldn't connect up to the two core EGP gateways it has been using for months. Since my EGP was refused by both of the core neighbours in its static 'toehold' table, it was completely out in the cold; it couldn't even try to shift to an alternate. (My EGP has all these heurisitics where you can set a 'minimum neighbour count' and it trys to keep that many neighbours around all the time by trying to peer with new neighbours its initial neighbours tell it about.) I called up the NOC, and they couldn't help, but I did get the info on which core gateways were running EGP; I tried them all, and after several failures found that the *last one* had room. Does anyone from BBN know why this suddenly happened? Are there just more EGP gateways out there, using up the table space? Was there an adverse effect from the release of the memory mapping software? If the table size cannot be increased, can EGP be put in more core gateways to spread the load? Whatever the reason, this is very disturbing, since hardwired 'bootstrap' information that has been good for months has effectively gone bad. Bad marks on the 'realiable service' front. Noel -------
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Tue 18 Feb 86 12:39:51-PST From: "ARAM BOORNAZIAN" <aboornazian@bbnv1.ARPA> To: "tcp-ip" <tcp-ip@sri-nic.ARPA> Subject: Cerf and Natalie continued
There is a class of tools that make a job possible. The Layered Architecture is in that class. Aram ------
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 1986 10:45:24 EST From: PADLIPSKY@USC-ISI.ARPA To: CERF@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Tails and Dogs
In response to your message sent 15 Feb 1986 09:58-EST Hi-- Mulishly ignoring the opening presented by your first paragraph, I'll merely observe that it's getting uncanny how your second paragraphs make just the points I want to. In the interests of getting on, I choose to infer from your third paragraph that I must have been wrong in thinking Dave WAS implicitly advocating Bad Things in the msg that started me off, and hence will couch my lance until somebody shoves another windmill into my path. (Rosinante and I are both getting on enough that it no longer seems worthwhile to cross roads for windmills, however attractive, but it's certainly beyond our scope to go around 'em if they're right there--to end with just a bit of horsing around, as it were.) cheers, map P.S. It might be a purist's point, but I do hope everybody remembers that OPTIMALITY DIFFERS ACCORDING TO CONTEXT -------
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 86 14:10:00 PST From: <gary@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Subject: Logical addressing
Does anyone know if the IMPs on the network currently support logical addressing for X.25 options? In the DDN X.25 Interface Specification a reference is made to the "Logical Addressing Facility", and that implementation of DDN logical addressing by a host is optional. If a host elected to implement this option would the IMP software support this, and does PSN 6.0 already have this implemented? Gary Krall ------
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 1986 13:10:25 EST From: MILLS@USC-ISID.ARPA To: PADLIPSKY@USC-ISI.ARPA, CERF@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA Subject: Re: Tails and Dogs
In response to the message sent 18 Feb 1986 10:45:24 EST from PADLIPSKY@USC-ISI.ARPA Good Lord, what have I done? It started with a few wayward packets and now we have windmills, horses, bad puns and Bad Things. May the Bird of Paradise redundancy all over your floor. Having had the first word, can I have the last and can this be it? -------
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 86 18:00:40 EST (Tue) From: Stan Ames <sra@mitre-bedford.ARPA> To: tcp-ip@sri-nic.ARPA, sra@mitre-bedford.ARPA Subject: rlogin support for non unix hosts
We are currently performing an independant assessment of the WIS program. One of the issues raised is whether commercial equipment could be used to solve the WIS requirements. One of the requirements of WIS is a single login. A potential solution is to use the rlogin capability found on most Unix hosts. Does anyone know whether this command is to be found in network implementations for machines other than Unix. Specifically does rlogin exist for IBM mainframes or VAXs running VMS. Thanks Stan Ames sra at mitre-bedford
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Wed, 19 Feb 86 10:56:36 EST From: Joel B Levin <levin@bbncc2.ARPA> To: tcp-ip@sri-nic.arpa Cc: levin@bbncc2.arpa Subject: Logical Addressing
In answer to Gary Krall's query of 18 February: PSN 5.0 and PSN 6.0 fully support logical addressing as described in BBN report 5476, the DDN X.25 Interface Specification. Use of this facility is by arrangement with the administrators of the network. Joel B. Levin