Subject: RE: Every time ..., was Re: General formula

From: Alan Lloyd <[email-masked]>
Date: Fri, 4 Jun 1999 10:46:36 +1000

Thanks - comments in line.

> -----Original Message-----
> From:	David Chia 
> Sent:	Thursday, June 03, 1999 4:01 PM
> To:	[email-masked]
> Subject:	Re: Every time ..., was Re: General formula
> 
> > 
> > Ed - this is all too hard for me ... I cannot even predict how long
> my
> > wife will be on the phone tonight or the number of times my mobile
> will
> > drop out when using it (hands free of course) in the car.
> > 
> > As to certificate usage and lifetime - theory is useful - but
> practice
> > makes perfect. 
> > 
> > What is the lifetime of a Bus or Train ticket... It depends on the
> > attitude and hunger of the damn machines that read them...QED
> > 
> 
> You seem to have missed the point. 
	That some times happens when the point is hard to see or there
is no purpose for hitting it.

> The aim is not to predict 'exactly'
> the life time of any 'particular' certificate.  The exercise is to
> determine if collectively the phenomon exibits predictable behaviour
> and to estimate the 'expected' or the statistical maximum likelihood
> value (together with the standard error of estimation if possible) so
> that cost can be evaluated and alternatives can be compared.
	I understand that - and being involved with this stuff for the
last 100 years or so - I will always state that a looking at a data
structure in isolation is a very limited exercise. I often present to
companies  - and one line I use is that a certificate represents a
currency (within a domain) and it is verified through the use of
directory services. A currency has a lifetime according to treasury
policy.. but and instance of the currency has a lifetime that is
affected by use and application. 
	Eg. an Australian $ note (being plastic) does not last long if
hot water is poured on it.

	Ie.- its makes little sense to talk about the theory treasurey
policy when in real life - lifetime is a usage issue. 
	I have pointed out that the maths associated with the validity
of a certificate is theory. And that, in operational systems, a
certficate being valid or not - in order to deliver customer services -
is a small part of the picture. So any theoretical formula without its
application is  just theory.

> When I buy hardware I usually also check the mean time between failure
> value beside cost and warrantee.
> 
	The MTBF of my car is 3 years - however when I break it -
operationally - is costs me heaps or its lifetime is shortened.
	 MTTR and Cost of repair is also useful - Shall we discuss
Integrated Logistics Support systems and Life Cycle Costs ?

	I hope this helps and regards alan

> David Chia, RMIT University

---

From: Andrew Probert <[email-masked]>
Date: Fri, 4 Jun 1999 10:56:55 +1000

Two bobs worth ..

Erlang calculations have been tablulated to give people an easy lookup for
telephony calculations.  Given a presented load in seconds, and a number of
lines, what is the percentage of calls that will get a busy signal?

It works, given 3 factors you can lookup any way you like.

However for this, or any capacity planning exercise, real-world data and
assumptions are input to the model.  

Erlang tables require the user to input their assumptions on presented load
(an average) and number of lines avaliable to derive busy.  Alternatively
how much busy time they can tolerate, for a given load to derive a minimum
number of lines.

I'm all for a model, please send me the Excel spreadsheet implementation
when its complete.  

However, I think the real world of certs is too complex.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> From:	Ed Gerck [SMTP:[email-masked]]
> Sent:	Friday, June 04, 1999 6:09 AM
> To:	Ben Laurie
> Cc:	Alan Lloyd; Bob Blakley; Graham Klyne; PKIX
> Ben Laurie wrote:
> > Ed Gerck wrote:
> > > This also means that if you call someone and it is busy, you could
> call
> > > right afterwards (just add the round-trip total delay time -- say, 5
> sec)
> > > and your sucess rate should be the same as if you would wait some
> > > minutes (as people normally do).
> > >
> > > The reason in both cases is simple -- since phone statistics is given
> by
> > > a Poison distribution and you don't know when the conversation
> actually
> > > *started*, its end does not depend on the duration of your
> observation.
> >
> > I don't believe this for a moment. To take an extreme example, if people
> > make, on average, 1 phone call a year, with a mean duration of 1 minute,
> > then it is intuitively obvious that if I wait a day after they are busy,
> > I have an almost 100% chance that they won't be busy,
> 
> Ben Laurie:
> 
> Is this how people really use the phone where you live? Is this "phone
> statistics"? C'mon, give me a break-- and realize that the statistics of
> your "extreme example" (what an understatement) is not even given by
> a Poisson pdf.
> 
> > whereas 5 seconds
> > later the chances are noticably less than 100%. Of course, I believe the
> > second statement, but the first is not a consequence of it, IMNSHO.
> >
> > You're just making this stuff up as you go along, aren't you?
> 
> You remind me of a guy that drowned in a lake that had just one inch
> of water depth, on average. Just too bad he did not realize it was an
> average, though. Or, even, what an average was.
> 
> Since phone traffic statistic is hardly on-topic here, I might help you
> off
> list if you consider this important for your understanding of certificate
> lifetimes.
> 
> And, Ben, next time you don't understand something, just ask and say what
> part of my text you did not understand. You don't need to become
> aggressive
> in order to receive my reply.
> 
> Cheers,
> 
> Ed Gerck
>