Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
Applying the current model of the telco transaction based settlement to the current end-user pricing model of the Internet is broken. There is a major disconnect between the two. When a standard telephone call is made one or the other end-user supplies revenue to the company/organization which supplies thier local service. Whereas in the Internet today, both sides pay for the privelege of having a full time open (or long-term part time open) connection to the network. These Internet end-users do not look anything like telephone end-users. Any attempt to apply the current telco model to the Internet model without significant rewriting of one or both will most likely be a taxation upon anyones sanity. There is another disconnect within the Internet that should (if it isn't already) be driving stong change that would most likely invalidate any hack that is developed on the current model. Whereas the cost of delivering packets outside of a small geographical area (call it the "Zero-mile" area) is based upon milage and bandwidth used. Currently in the US most bandwidth is sold at a flat price per Mbit. Whether or not it's billed upon usage or billed upon some predetermined level that the user cannot exceed. This constitues another disconnect between base cost of goods and revenues of sales. As the industry grows more mature, these need to be tied together, otherwise in the end, the end-user will be gouged in one manner or another, and the disconnect of COGS versus Revenues tends to lead toward artificial operating costs. -Chris
As much the "how to count bits" thread is entertaining, the reason why nobody's doing any path-based accounting in packet networks is quite trivial: It is not technically feasible. In other words, the computing resources necessary to perform such accounting (and to retain the accounting information for subsequent billing) by far exceed resources necessary to perform the actual service - transportation of the packets. Which squarely puts it beyond the reach of today's technology. Until someone comes up with a feasible way to do such accounting, the whole point of discussing the best economical model based on such detailed accounting is moot. --vadim
Vadim Antonov writes:
As much the "how to count bits" thread is entertaining, the reason why nobody's doing any path-based accounting in packet networks is quite trivial:
It is not technically feasible.
In other words, the computing resources necessary to perform such accounting (and to retain the accounting information for subsequent billing) by far exceed resources necessary to perform the actual service - transportation of the packets. Which squarely puts it beyond the reach of today's technology.
Until someone comes up with a feasible way to do such accounting, the whole point of discussing the best economical model based on such detailed accounting is moot.
I've been making this same argument in private mail to several people. We don't even have a reasonable model of the costs involved in accounting. If you add acounting into the system, how many people does that add to the staff to deal with billing disputes alone? How many people have to manage the accounting system? How many packets does an accounting system suck up from the network? How much CPU in the routers? Transaction costs -- the costs of doing a transaction -- are nontrivial. Lots of technical economics papers deal with the pervasive impact they have on day to day life. For instance, the reason we have corporations and not just loose agglomerations of contractors is thought to have a lot to do with transaction costs -- a corporation can pool resources without having to account for the costs and use of all of them, in a way that pools of cooperating contractors cannot, and thus can save a lot of money in accounting. (Outsourcing is said to thus be economical when activities are detached enough that the increase in efficiency is higher than the increased transaction costs.) The result of all of this appears to be what the market has done for the internet. If you offer someone lower cost service that is metered against more expensive unmetered service, they pick the latter, because it actually saves them a myriad of other costs, like the personel needed to figure out if the bill is fair each month. (Having seen the infrastructure many companies deploy to figure out if their telco bills are correct, I'll assure you it is neither pretty nor cheap.) People are willing to pay more to just avoid the transaction cost load. In addition to the fact that people have ignored the sheer weight of transaction costs, lots of fun ideas have been tossed around, from micropayments to automated settlement systems -- that involve technology no one actually has ever built to commercial standards, and which are in some cases not even available in research contexts. I have yet to see a truly deployable and economical micropayments system, for instance, as much fun as they are to discuss. The real fun associated with all such systems also comes in what happens when you deploy one and find that the money from the payments gets absorbed in billing errors, disputes, and such. The point I'm making, I suppose, is that all such systems aren't "frictionless". There is a reason all the customers like the model we have now. They'd rather pay $1000 a month and never have someone think about it again than $500 and need to go over the bill. Leave well enough alone, I say. Perry
Richard Irving wrote:
What about netflow ?
Vadim Antonov wrote:
It is not technically feasible.
You can do traffic analysis based on statistical sampling. Good luck doing _billing_ based on statistics. In any case, nobody was able to connect backbone flow traces for any significant amount of time. A typical Internet load on OC-3 would produce about 7000 fps, or 500 mil flows per day. Now, crunching that data to generate bills is going to be fun. I'm not saying this is impossible, but the infrastructure for doing so is going to cost at least an order of magnitude more than the non-accounting backbone. --vadim
participants (4)
-
Chris A. Icide -
Perry E. Metzger -
Richard Irving -
Vadim Antonov