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

Roland Hedberg <Roland.Hedberg@rc.tudelft.nl> Fri, 12 November 1993 16:35 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07072; 12 Nov 93 11:35 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07068; 12 Nov 93 11:35 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa14252; 12 Nov 93 11:35 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.05789-0@haig.cs.ucl.ac.uk>; Fri, 12 Nov 1993 15:11:50 +0000
Received: from dorothy.rc.tudelft.nl by bells.cs.ucl.ac.uk with Internet SMTP id <g.12313-0@bells.cs.ucl.ac.uk>; Fri, 12 Nov 1993 15:11:38 +0000
Received: by dorothy.rc.tudelft.nl id AA19019 (5.65c8/IDA-1.4.2 for osi-ds@cs.ucl.ac.uk); Fri, 12 Nov 1993 16:11:05 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Roland Hedberg <Roland.Hedberg@rc.tudelft.nl>
Message-Id: <199311121511.AA19019@dorothy.rc.tudelft.nl>
Subject: Re: RE: A tool for getting information out of the Quipu logfiles
To: "K. Spanier" <spanier@zdv.uni-tuebingen.de>
Date: Fri, 12 Nov 1993 16:11:04 +0100 (MET)
Cc: osi-ds@cs.ucl.ac.uk, wg-nap@rare.nl, dsa-probing@zdv.uni-tuebingen.de
In-Reply-To: <9311111549.AA00355@melvin.zdv.uni-tuebingen.de> from "K. Spanier" at Nov 11, 93 04:49:15 pm
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1573

> 
> 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?

I used a very simplistic approach, I used the Quipu stats files.
No testing therefore, just the normal use of the directory.
But I used the stat files from 6 different DSAs ( 5 different countries )
in order to try to reduce the effects of continues bad connectivity between 
different country networks .

From the statsfile you can get a summary of all connections (successful
and nonsuccessful) that the DSA has tried to open to other DSAs, and 
that is what I have used.
As you say this does not diffrentiate between problems due to networking
problems from problems due to directory management, but what it does is
that it gives you the users point of view. 
Which in my eyes makes it a valid approach.

> 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 !!!

I agree, but if according to the logfiles from these 6 DSAs, they have not
been able to reach one special DSA for a whole month dispite the fact that they
each have tried up to 100 times, than I would lean towards blaiming the
DSA manager :-)

The motive behind this excercise was to get some discussion going around
service levels, and I am very pleased that people seem to care.

-- Roland