North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: 95th Percentile = Lame
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 > >
|