What does 95th %tile mean?

Sat Apr 21 04:52:14 UTC 2001


> On Thu, Apr 19, 2001 at 05:18:02PM -0700, David Schwartz wrote:

> So did you calculate, how much you are losing. It's less than 1%
> of a 1% of
> all flows. That means you catch up more than 99.99% of all flows.
> Not that bad.
> Furthermore NetFlow gives you the ability to offer value added (billing)
> services to your customers. For example ...

> >   368351628 flows exported in 12278484 udp datagrams
> >   33838 flows failed due to lack of export packet
> >   269989 export packets were dropped enqueuing for the RP
> >   108825 export packets were dropped due to IPC rate limiting

	I get 3% loss. (26989+108825)*100/12278484 = 3%

> > 	Billing based upon total bytes transferred tends to create similar
> > problems. Do you bill based upon bytes transferred per day? Per
> > month? If
> > so, it's still statistical sampling if you have some amount of 'paid
> > bandwidth'.
> >
> > 	And you can't collect this data from interfaces because
> > interface rates
> > include local traffic, which (for example) grossly overbills
> > customers with
> > newsfeeds.
> >
>
> ... you may easily deduct News traffic from being billed. BTW: tell me
> how
> do you exclude News Traffic if you count the 95th %ile?

	Our NetFlow accounting ignores the news flows as it ignores all local
flows. We 'smear' each flow over the time period in the flow packet
(start/end) as if its bytes were smoothly distributed over that time
interval. We configure our routers to flush active flows every five minutes,
rather than the default of 30, so the maximum time error is of the same
order of magnitude as the sampling interval.

	We disclose this method to our customers, and they understand that it is
statistical sampling. We also offer them a 'throttling' alternative that
guarantees them either that they won't pay for any excess or that their
excess will be capped at some particular dollar amount.

> Billing based upon total bytes transferred is IMHO verfy fair and
> attractive
> from the point of a customer's view and tends to be a nightmare
> from an ISP's
> pespective especially if you don't just count bytes but are looking at
> the IP-addresses involved.

	With a flat 'per byte' rate? I'm not sure how attractive people would find
that. Plus, that costs the ISP the oppurtunit to charge people for bandwidth
that they're not using (because we had to provide it to them anyway, in case
they nedeed it).

> Maybe a mixture of byte-counting and portspeed would give a fair billing
> model. BTW that's also the model you pay power for in Germany.
> Arnold Nipper / nIPper consulting          mailto:arnold at nipper.de

	You can do that. A DS3 costs X dollars per months plus Y dollars per
gigabyte transferred (or Y per inbound gigabyte and Z per outbound gigabyte
if necessarry).

	The 'problem' with that is a customer that alternates between 45Mbs and
0Mbps is charged the same as a customer that usees 22.5Mbps all the time,
despite the very different costs to support them.

	You can fix all these problems by making the scheme more complex and thus
(arguably) fairer. But my experience has been that customers tend to want
simplicity. I do agree that you don't get much simpler than port cost plus
byte cost.

	DS