North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: 95th Percentile = Lame
- From: James Thomason
- Date: Mon Jun 04 00:59:31 2001
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
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
> 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
> 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. :)