RE: RE: A tool for getting information out of the Quipu logfiles

"K. Spanier" <spanier@zdv.uni-tuebingen.de> Thu, 11 November 1993 18:21 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06478; 11 Nov 93 13:21 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06474; 11 Nov 93 13:21 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa15201; 11 Nov 93 13:21 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.06151-0@haig.cs.ucl.ac.uk>; Thu, 11 Nov 1993 15:58:25 +0000
Via: uk.ac.nsfnet-relay; Thu, 11 Nov 1993 15:57:36 +0000
Received: from mailserv.zdv.uni-tuebingen.de by sun3.nsfnet-relay.ac.uk with Internet SMTP id <sg.12118-0@sun3.nsfnet-relay.ac.uk>; Thu, 11 Nov 1993 15:56:40 +0000
Received: from melvin.zdv.uni-tuebingen.de by mailserv.zdv.uni-tuebingen.de (4.1/ZDV-Uni-Tuebingen-1.0) id AA21456; Thu, 11 Nov 93 16:52:57 +0100
Received: by melvin.zdv.uni-tuebingen.de (4.1/ZDV-Uni-Tuebingen-1.0) id AA00373; Thu, 11 Nov 93 16:52:52 +0100
Date: Thu, 11 Nov 93 16:52:52 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "K. Spanier" <spanier@zdv.uni-tuebingen.de>
Message-Id: <9311111552.AA00373@melvin.zdv.uni-tuebingen.de>
To: osi-ds@cs.ucl.ac.uk
Subject: RE: RE: A tool for getting information out of the Quipu logfiles
X-Orig-Sender: zrnsk01@melvin.zdv.uni-tuebingen.de

OK,

I missed Rolands talk last week, so I would like to know what exactly
was done during testing. What do you mean when you say "the DSA was
not available"? Have you run more than a bind test? Which other factors
did you consider? Did you check for network availability?

The reason I ask is, that in Germany we had a workshop this week with a 
TOP "DSA probing". Here, results obtained with a modified version of Steve 
Titcombes PROBE tool were presented, which indicated that in case of failure 
NOT ONLY the DSA managers were to be blamed BUT ALSO network managers !!!

What was done?

Thomas Johannsen of Dresden Technical University and myself have introduced 
into PROBE a testing for network and OSI stack (i.e. imisc) reachability in 
case a DSA seems to be down for further analyzing the situation. Furtheron, 
we run the tests in sync and combined the results. A clear conclusion of these
tests was, that a "DSA unavailable" from one testsite does not mean "DSA
unavailable" from the other site! And in case of "DSA unavailable" roughly 
50 % of all cases could be pinned down to network unreachability of the host 
running the DSA!

Of course, I would not conclude from these results that there are no
DSAs which are NOT available. But, before I blame a DSA manager, I am
going to analyze the problem a bit further !!!

We have contacted Roland Hedberg in order to coordinate our efforts in
the field of DSA probing and he was very pleased to hear from our results.
We are going to continue the probing (of DE level DSAs ...) from more
than two sites in the next future and hope to collect enough data for
a better answer to the question "which DSA is available and which one not". 
For convenience of discussion with Roland we have set up a mailing list which 
is, of course, open for anyone interested in this field. The list is:

    dsa-probing@zdv.uni-tuebingen.de

Requests for subscription should be send to dsa-probing-request@...

Of course, our efforts are at the beginning and ideas for further expanding
our tool or integrating with others would be wellcome.

Regards,

Kurt Spanier



X.500: Kurt Spanier, Zentrum fuer Datenverarbeitung,
       Universitaet Tuebingen, DE