North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: 95th Percentile again (was RE: C&W Peering Problem?)

  • From: Joe Abley
  • Date: Sun Jun 03 00:32:03 2001

On Sun, Jun 03, 2001 at 12:04:03AM -0400, Richard A. Steenbergen wrote:
> On Sat, 2 Jun 2001, Joe Abley wrote:
> 
> > > No matter how you stack it, if you miss a rate sample there is no way to
> > > go back and get the data again. You either discard it and lose the ability
> > > to bill the customer for it (which demands high availability polling
> > > systems), or you make up a number and hope the customer doesn't notice.
> > 
> > No -- there is no need to do that. You don't need a sample for every
> > single five-minute interval during the month to produce a meaningful
> > 95%ile measurement for the month; you just need a representative
> > sample population. You increase the chances of your sample population
> > being representative if you consider lots of samples, but dropping one
> > or two does not mean you lose revenue.
> 
> Actually you gain revenue if you drop samples below the 95th percentile
> mark, since you are forcing the cutoff point higher by reducing the number
> of samples.

Right. So, dropping samples != dropping revenue.

> I think your argument is in favor of 95th percentile vs an accurate
> average, not rate vs amount samples. If for some reason you lose a sample
> with an average system, your revenue goes down, whereas if you lose a
> sample in 95th percentile you're more likely not to make it go down much.

Not really. For any averaging function you care to apply to the sample
population, there will be some samples that tend to increase the result,
and some that tend to decrease the result. Whether or not the billable
value goes up or down depends on the sample that was dropped, on the
remaining samples, and on the averaging function being used.

I don't see how you can say in general that losing a sample "with an
average system" makes revenue go down.

You can certainly speculate about particular "averaging" functions being
more likely to increase or decrease given random loss from a particular
sample distribution, but that wasn't what we were talking about (we were
talking about rate vs. volume).

> But this is completely circumvented by polling the amount instead of
> polling the rate. Measurements in amount are always better then
> measurements by rate.

Always?

> If you have some horribly ghetto hack that makes you
> count the packets yourself and you have the possibility of missing
> samples, it may not be completely better then 95th percentile, but this is
> a seperate issue.

Except in this case, maybe :)

> > > Volume polling does not suffer from this problem.
> > 
> > It does, if you don't have per-customer interface counters. You need
> > to count every packet using some other method, and if you can't count
> > packets, you can't bill for them.
> 
> I'd say the real problem is with the vendor. Fortunantly most people have
> counters.

Suppose you are selling transit to several customers across a switch
operated by someone else (an exchange operator, for example), such that
the traffic for several customers is carried by a single interface on
your router. Suppose direct interconnects are not practical, and suppose
you have no access to any counters that may be available on the switch.

The options are: (1) do not sell to these customers, or (2) find some
way to sell to these customers by counting packets yourself. Option (1)
presents a far more consistent opportunity to decrease potential revenue
than does option (2).

I do not believe this is a particularly far-fetched scenario: hence I
think this is not simply a vendor problem.


Joe