kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (04/21/88)
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
MRC@PANDA.PANDA.COM (Mark Crispin) (04/23/88)
Walt Haas' idea certainly makes the most amount of sense, provided
that the concept of a "VC" under IP can be clearly identified to the
accounting processes. It's a bit harder for UDP than TCP, but it still
can be done. It is important that only packets which are delivered to
the destination are charged. I won't worry about packets getting dropped
at a site's LAN -- if they have a too-high drop rate then it's their own
responsibility to fix their LAN/gateway!!!
This seems to be a reasonable model for a typical "service host":
. Telnet - accept collect calls (since the site is presumably already
billing the customer and network charges can be easily added to
the bill ala CompuServe, etc.)
. FTP - accept collect calls for login FTP. Create a *new* FTP service
for non-login (ANONYMOUS) FTP that does not accept collect calls.
. Mail - do not accept collect calls for ordinary mail. Create a *new*
mail service for bulk-distribution (mailing list, newsgroup,
etc.) mail which does accept collect calls.
The idea behind such a model is that the service host is charged
for network traffic only when those charges can be clearly passed on to
a customer of that service host. When an external agent is benefiting
from access to the service host (e.g. ANONYMOUS FTP) that agent foots
the bill. In mail, I follow the model of postal mail in that the sender
puts the stamp on the mail. The "bulk-distribution" service is sort of
a misnomer; a better name would be "collect mail". A site which doesn't
want such mail can simply not offer the service; of course such a site
may miss out on mailing lists, newsgroups, file transfer via mail, etc.
It would be up to the site to decide upon how to handle the charging.
One way would be to have a more limited list of recipients of collect
mail than for ordinary mail.
The technical problems in all of this are relatively straightforward:
1) the accounting mechanism must be in place and it must be clear to all
parties who is paying for the datagrams!! Some mechanism is needed to
handle those datagrams that don't neatly fit into a "VC" model.
2) FTP and Mail probably need to be split into two additional services.
I am also assuming that it must be clear to all concerned that
accounting begins and ends at the DDN. You won't be charged for packets
the DDN drops, but if your gateway drops lots of packets that's tough.
-- Mark --
-------