RE: 95th Percentile = Lame

[James Thomason <james () divide org>]

On Sun, 3 Jun 2001, David Schwartz wrote:

>       Why doesn't UPS just figure out the average cost of sending a package and
> charge that for every package? The answer is obvious, it won't encourage
> customers to make best use of existing capabilities and will encourage those
> people whose packages cost above average to use UPS and those whose packages
> cost below average to use other carriers. Billing based upon this type of
> statistical sampling is awful.

Lol!  Exactly!  Billing on statistical sampling IS awful, isn't it!?

Why not instead, figure out what your EXACT costs are for a particular
transaction, and bill based on that?  

FYI:  UPS does look at a series of statistical samples to determine its
      package shipping costs from/to particular sources/destinations. 

> > Do bits have value?
>
>       Value and cost are not the same thing. Providers don't bill based upon
>       value.

Not saying they are, but this was slightly out of context. Providers
SHOULD bill on value AND cost.  They can't today. 

>       Yes, there are free bits. My network traffic at off-peak time could triple
> and it wouldn't cost me an extra penny. Triple my traffic on-peak and either
> my performance would fall to unacceptable levels, my bandwidth costs would
> go up, I'd have to provision new circuits and upgrade hardware, or all of
> these things.

I see exactly what you mean here, and I agree.  But, in fact those
off-peak bits DO cost you money, just no more than what you have already
budgeted. 

>       Providers could try to use a very simple way to bill, like total bits, but
> accept that it won't correlate well with the actual cost to provide the
> service, or providers could do a very good job of figuring out exactly how
> much each bit costs them, but the billing method will be complex and will be
> based upon factors beyond your control such as whether your peak times
> happen to align with other customers peak times.

I think that technical solutions could be implemented to reduce the impact
of "provisioning for peaks".  The cost may even be the same. 

I agree that you, nor the customer, would have a great degree of control
over the market.  You WOULD however, be able to set cost/quality
threshholds in an ideal world. 

>       In other words, those who move cheaper bits should pay to subsidize those
> who move more expensive bits? Airmail and ground should be the same price so
> those who pick the least expensive possible delivery they can live with
> subsidize those who want everything sent the fastest possible way?

Not at all.  I think you are trying to speak of quality characteristics in
what is a commodity environment.  The bandwidth I receive in my cage at
Exodus does not differ from that of the cage next to me.  I think that
cost should be "fair" for the level of service I receive. 

>       Rational, efficient use of existing resources should be encouraged. Those
> who smooth out their load or move bulk transfers to off-peak times should be
> rewarded. If you want to tap into the lucractive VPN market, it helps if you
> can discount traffic between your own customers -- that way if you get the
> New York branch of FOO, you have leverage to get the San Francisco branch.
>
>       Ideally, the price should match as closely as possible the actual cost to
> provide the service. You can make exceptions to keep the billing scheme
> comprehensible. As a practical matter, it is simply amazing how well 95%
> billing matches the actual costs associated with providing a circuit. I have
> found no better method that doesn't start to become incomprehensible.

If you have any data in this area you can share with me I would be most
appreciative (everyone!).  

>       We've been talking about having 'half-price' times where your traffic is
> halved before going into the 95 percentile algorithm. We'd have a server
> that would tell you which times were half-price and we'd guarantee at least
> two such hours a day. Customers who do automated bulk data transfers could
> code to query this server and find the best times to move their data. But
> this tends to fall under the 'too complicated' or 'too much work for too
> little effect' category.

I do not actually think this is incredibly complicated.  The long distance
companies do it. But you know exactly what your per-minute rate is.  Easy
to quantify. :) 


>       DS