Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/7/84; site ucbvax.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!wjh12!genrad!decvax!decwrl!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: pinging and networking
Message-ID: <2618@ucbvax.ARPA>
Date: Wed, 17-Oct-84 15:28:54 EDT
Article-I.D.: ucbvax.2618
Posted: Wed Oct 17 15:28:54 1984
Date-Received: Sat, 20-Oct-84 06:47:09 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 78

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.

-Rudy