info-vax@ucbvax.ARPA (10/17/84)
From: Rudy.Nedved@CMU-CS-A.ARPA
Hi. I am not on the list but a friend on mine just put his hands over
his head (see no evil, hear no evil, ...)
Anyhow. Let's get the record straight:
One of the techniques for figuring out if something is "there" in
the network world is by sending a packet to it that somehow gets
sent back to you. In some worlds this is called "echoing" and in
some worlds it is called "pinging". The latter term is more
orieneted to what people on the internet do to gateways and some hosts.
There are several problems with pinging:
1) if the bandwidth of the network is low and there are many hosts, if
everyone pings a gateway...the effect is a saturation of the gateway.
The gateway will send a packet out for every packet it handles. The
neccessary bandwidth is 2*N/ping-rate. Ping rates for some sites
is 37 seconds and for other sites is 2 minutes. The result is still
bad is you take 5000*2/120 (5000 hosts) and try to stuff those
packets over 50KBD links.
2) Pinging implies that you know the structure of the network and where
the relative locations of important resources. This in general is
impossible to know in a growing network enviroment with many groups
not even knowing where their own important resources are in their
networks.
3) Pinging by most people is a host oriented mechanism. In general,
that is a highly inefficient way of using the hosts bandwidth and it
has to be done (in order to be effective when you need it) all the time
independent of when you use the connections.
I must admit it is an effective debugging tool to use occasionaly but leaving
the debugging tool in place is bad news.
There is not A solution to solve the problems but there are a bunch of
guidelines that people seem to be using:
a) don't ping anything unless it is a gateway very close to you and it is
on a high bandwidth local area network. In some cases, you have to ping
LAN gateways....but this is usually stupid gateways talking to stupid
gateways....hosts don't ping or you get the saturation problem since
people will look at the code and say "hey it is a hi-speed link...let's
ping more".
Also you don't want to ping on some of the hi-speed LANs since
the hardware implements the same type of information...this is
true of token rings where the sender can tell if the receiver
got packet or not in a very short time.
b) Hide network topology in the concept of a subnet. CMU-Net structure
should not include ARPANET and vice versa. This means that SU-Net,
MIT land, CMU land, CU land and other networks don't know about the
internal structure of the whole picture. The gateways that are inside
these subnets...know about the down and up links and know about the
gateways that handle external networks...but that is it. The external
gateways are a bit more complex.
This area is still being developed and explored.
c) If a host wants to get some place, it should ask its friendly
neighborhood gateway. If the gateway is not friendly then use another
one or get it fixed or live with it. I have sympathy with people
that have to use these gateways and see that their not working but
people are working on them.
If you really don't like the way things are going then build your
own gateway. You will quickly find that things are not simple.
The last point is that if you start getting into the network business...
don't re-invent the wheel. Read the stuff Xerox has done and documented,
read the RFCs from the ARPANET folks on 1822, IP, TCP, UDP, GGP, EGP,
SMTP, FTP, SFTP and TELNET. Undestand the parts and the whole and also
check out what the rest of the world is doing...commerical and otherwise.
Look at the CCITT stuff...look at the NBS stuff...read mail from mailing
lists.
-Rudyinfo-vax@ucbvax.ARPA (10/18/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> The thing that bugs me is hosts that ping the gateway to see if it is still there, but don't really have any idea of what to do if it isn't. -Ron
info-vax@ucbvax.ARPA (10/18/84)
From: Rudy.Nedved@CMU-CS-A.ARPA don, You seemed to have missed several points in my message. Ron I assume is trying to "fix problems" with JPL-VLSI and other hosts. Either the hosts that he wants to talk to are ARPANET hosts or they are behind gateways. If the gateways are not routing correctly then they have to be fixed. If he has a lengthy routing table and does not use one or two well known gateways then he is going to have problems everytime the network configuration changes...I assume his system has ICMP implemented and that it interacts with his routing code. ======== The most important point is everyone is seeing the problems with the gateways at the moment and the BBN folks are working on the systems. I don't enjoy the fact that CMU-CS-A can't get to CMU-CS-B because the EGP gateway we are using dropped MILNET. People are working on it and no amount of pinging and testing is going to make things better for a host. The only short cut is to find find out what gateways are between you and the host you want to talk to and put the first one in the path in your table for that host. If that gateway goes down, your stcuck. If the network behind that gateway changes, your stuck. If someone badly needs network service then make your host multiaddressed and get a second connection to that network and avoid other people's gateways. -Rudy
info-vax@ucbvax.ARPA (10/18/84)
From: Provan@LLL-MFE.ARPA What Rudy is trying to say is that it's very bad to "ping" *regularly*. He's thinking of some unfriendly behavior that some TOPS-20 sites used to do. They used to send packets (as Rudy describes) to every gateway they knew of every minute or two. The load on the network was excessive and everyone got all upset about it. Since them this behavior has been stamped out (we hope). Now that those of you on Info-Vax that aren't on TCP-IP are up-to-date about what Rudy's so upset about, we can proceed with the discussion. It sounds like what Ron wants is a one shot program that either runs out to see if the route to Blat is really valid or see if all routes in some route table are valid. There are three possible mechanisms for this that I can think of off hand. The best if you want timings is ICMP echo messages aimed at the host you want to check. The easiest is to try to open a Telnet connection (if it fails, the route's probably not right). Now that we've calmed down the TCP-IP people, is there anything out there that will do the job? don CC: Rudy.Nedved@CMU-CS-A.ARPA, Info-vax@sri-kl.arpa