Path: utzoo!mnetor!uunet!husc6!bu-cs!kwe From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Packet Accounting (long) Message-ID: <21853@bu-cs.BU.EDU> Date: 20 Apr 88 20:24:14 GMT Organization: Boston Univ. Information Tech. Dept. Lines: 118 Keywords: accounting chargeback policy I have some further comments on the per packet accounting policy issue. I have excerpted comments from Vint Cerf, Jack Haverty, and Barry Shein in my rather longish reply. ----------------------------------------------------------------- From CERF@A.ISI.EDU Sun Apr 17 12:06:31 1988 Kent, Your flames seem a bit excessive (but I suppose that's a tautology...). Given. I am beginning to think that flames on lists like tcp-ip are out-of-date and that I should never flame on a list with an audience as large and diverse as this list. This reply is an effort to douse the flame and sound like a reasonable person. The issue of accounting becomes more significant as the services rendered become less research/experimental and more like commodities. Telephone services such as the Federal Telephone System run by the GSA are cost-allocated in accordance with usage and one doesn't find it odd to pay for telephone calls on the basis of time and distance. Well, distance is an historical rationale for charging. I subscribed at one time to Satellite Business Systems' long-distance service. They charged a rate that was distance insensitive, arguing that since it was satellite service, distance was not a true cost basis. On the other hand, time is still an obvious resource in a switched circuit network. There is no technical reason to do it one way or the other. You pick a method that your customers and auditors will find acceptable. My basic argument is that chargeback is isolated from network technology, except as used in arguments of equitability and fairness. The parameters for packet nets may be different than for telephone voice service (maybe no distance charges). The important thing for the parties involved is to be able to demonstrate that there is a reasonable sharing of costs. One attractive thing about basing charges on usage is that as total usage goes up, it may be possible to make capital investments to increase capacity in a way that doesn't specifically require that all parties make an agreement to acquire more equipment - the service provider can buy it on the basis of increased usage and spread the cost in a reasonably equitable fashion. Equity seems to be a key concept here. Of course, equity depends on the perception of those involved and implies that the rationale is understandable and "natural". The idea of using ramping usage charges as a capitalization tool had not occurred to me; it is an idea with merit. From haverty@CCV.BBN.COM Sun Apr 17 18:55:17 1988 Vint et al, In addition to these 'engineering' kinds of decisions, the network must make 'marketing' decisions. For example, it might price a new service "unfairly" low, in order to encourage clients to upgrade (maybe mail should be cheaper if one uses the full domain server system?). There are also costs associated with "marketing", such as advertising (NIC management bulletins?) As far as charging algorithms go, that is the province of the hypothetical marketing department - how do I price my product. In the context of the current mail discussion, I think it is best to assume that somehow all of the costs must be recovered by charges, including costs for investments for the future. The real question is how to use a pricing policy to encourage the desired behavior. I think your point about looking at chargeback as a marketing issue is particularly apropo. I think that puts the best light on the subject. Your argument begs the question, though, of "Will the charges from my external network vendor [the Internet] unduly constrict or restrict my ability to implement my own internal chargeback policy?" It should not. There is a difference, in my thinking, between the actual installation and recurring cost structure of something like a LAN and an artificial recovery model like a per-packet charge. Actual costs to install and maintain a LAN are fixed on a per-network and per-node basis rather than a per-packet basis. Of course, you can use either model to recover cost, but my point is that per-network, per-node is more natural and much easier to administer. I argue that the bean-counters should not be allowed to extend an improper model to LAN cost recovery. We should try to get them to accept another model, by arguing in their own financial or marketing terms. This assumes that we stay ahead of user bandwidth need and that there is always sufficient (I would recommend excessive) amounts of bandwidth, so that the question of scarce resources is not involved in the LAN model. If your Ethernet backbone is limited, go to FDDI, but don't adopt a new and restrictive cost model just to get through a temporary phase of technology transition. Is this whole issue of chargeback merely a temporary phase? Once we have "unlimited" bandwidth again, will the arguments for chargeback evaporate or will we be left with an obsolete legacy to overcome when wide area networks are as open as today's local area networks? Don't hamstring the technology of tomorrow with an inadequate policy today. Another way to put this is to say, let's decouple the WAN chargeback from the LAN chargeback issue. Both costs need recovery, but with different models. From: bzs@BU-CS.BU.EDU (Barry Shein) At the very least it would be interesting to hear what the goals are that people expect to accomplish with their proposed chargeback models, it's nice to have explicit goals and see if the models actually achieve them. --------------------------------------------------- Seems we have some goals already: o complete cost recovery o simple recovery formula o "natural" and "understandable" algorithm for cost recovery o equitable allocation of costs across our client base o capital recovery/generation for investment in new technology o decoupling between WAN cost recovery model and LAN cost recovery model I hope this helps forward the discussion. Kent England, Boston University