WWB.MDC@OFFICE-1.ARPA (Bill Barns) (04/12/88)
This is a multifaceted question, and I am asking "What do vendors have", "what do vendors think of doing this", "what is going on with protocol standards in this area, if anything", and "what philosophy of approach, design, policy, etc., should apply", with regard to the following issue: In the not too distant future, there will be a direct cost associated with usage of MILNET, charged on a per-packet basis. There is some perception that the same will be true of the operational Defense Research Internet, though I know of no official statements to this effect. Whatever the case, the relevant point is that there will apparently be a specific charge which will become part of the cost base for contract pricing on certain common types of contracts. Those of you who are familiar with the arcana of government contracting will appreciate that these figures are auditable by various authorities, a fact which has a large number of serious implications. Some people here see it as a problem that the use of a LAN and gateway to MILNET (or any net with similar charging algorithm) would result in a cost to the sponsor which, from the government side, cannot be allocated to specific projects, because the charging information will be generated on a per-port basis. This is bad because a significant number of projects nowadays, and especially in the pipeline, are generating connectivity and data communication requirements of this type. Thus there is a concern that if the traditional management approach (more or less dictated by audit considerations) is employed, it might be necessary to have one physical interconnection for each contract. I trust it is not necessary to explain in complete detail why this is bad. A large defense contractor (like this one) might end up having to have tens or hundreds or thousands of interconnections. Remember that there is also to be a per-port charge, not to mention all the RFS, TSR, NCR, NCD, etc., paperwork that would have to be done. On the other hand, shared gateways are much cheaper. But at present it is not evident that there is a way of allocating cost for shared gateways which would be satisfactory to the government auditors. The port used by the gateway would have to be paid for by one service component, including charges attributable to other programs which might be contracted with other components, or may be subject to different allowable pricing and cost recovery rules. The perceived bottom line here is that there is an implicit requirement for packet-level accounting of IP traffic, and ultimately ISO IP traffic likewise, through such a multiple-use interface. It isn't obvious to me how this can be solved completely right without protocol alterations, probably at the IP level - an accounting code IP option. But I think that is politically infeasible. The existing protocols can be left intact if the accounting is done on the basis of source and destination IP addresses, and I think this may be an adequate solution. However, this still requires some protocol development, as well as implementation work. I imagine such an accounting scheme working in the following manner. The IP router servicing the government network interconnection would extract source/destination (depending on direction) IP addresses and keep packet counts and perhaps other counts tabulated on this basis. At some interval it transmits these values to some configuration determined place or places where a long-term accounting database is maintained. This transmission would be formatted according to some protocol yet to be specified. The target host of the transmission runs some server software which receives these transmissions and stores them in an accounting database, from which reports are developed as needed. So, many questions suggest themselves: Is anyone already doing this? Is any vendor already selling IP gateways that provide such functionality, using this or any other design? Is any vendor willing to volunteer to implement some simple scheme of this sort? Is my design concept valid? Does anyone have a better one? Has anyone ever developed or published suitable protocols in the TCP/IP framework for communicating the accounting data? ISO CLNS/GOSIP? Has anyone gone through this issue with DCAA, local DCAS people, or other such authorities, and what did they say? (etc.) All sorts of relevant comments are solicited. Thanks, Bill Barns / McDonnell Douglas / Internet: WWB.MDC@OFFICE-1.ARPA
pogran@CCQ.BBN.COM (Ken Pogran) (04/13/88)
Bill, Regarding packet-level accounting, and the auditability of shared gateway connections, etc.: There's an alternative approach, that I heard suggested by a (technically-oriented, not contract or financial) Government official. That is to consider the cost of the network attachment to be part of the corporation's infrastructure or overhead -- an indirect cost -- like any utility. That actually seems like a pretty good idea. After all, an indirect cost is one that you incur that benefits a number of contracts, and is such that you can't reasonably allocate it directly among those contracts. Electricity typically fits that bill; some companies allocate phone service to contracts, while some consider it an indirect cost; ditto with postage. So it's probably not unreasonable to consider the cost of being attached to the Internet an indirect cost that you bear in order to be "in the business". (I'm sure all of our contracts and legal people would have opinions on this; I'll bet they mostly don't read TCP-IP though!) Ken Pogran
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (04/13/88)
In article <MDC-WWB-DH962@OFFICE-1> WWB.MDC@OFFICE-1.ARPA (Bill Barns) writes: >requirements of this type. Thus there is a concern that if the traditional >management approach (more or less dictated by audit considerations) is >employed, it might be necessary to have one physical interconnection for each >contract. > [...] >On the other hand, shared gateways are much cheaper. But at present it is not >evident that there is a way of allocating cost for shared gateways which would >be satisfactory to the government auditors. The port used by the gateway would >have to be paid for by one service component, including charges attributable to >other programs which might be contracted with other components, or may be >subject to different allowable pricing and cost recovery rules. > >The perceived bottom line here is that there is an implicit requirement for >packet-level accounting of IP traffic, and ultimately ISO IP traffic likewise, >through such a multiple-use interface. I don't agree with the premise that government accounting requires separate physical connections per contract. I assume that we are speaking of separate departments within your company, each of which has one or more separate contracts with separate charging, either fixed price or cost plus. You say that the auditors require per-packet charging to fairly allocate costs. Do they require each dept to pay a separate rent or to install separate phone systems or to buy their own furniture and pencils? They do not. Network costs could be set up as an overhead charge. Links to outside networks like the internet are flat rate and this cost could be allocated to each dept based on a formula. The only trick if there is one is the formula, but every organization has a formula for allocating basic telephone service with cost-per-message added on as needed [long distance billing, for example]. So long as your formula approximately distributes actual costs to all departments and only recovers actual costs and a share of other overhead, it should be acceptable to auditors. If MILnet goes to packet charging, and I don't see how they can do it, those costs could still be approximately redistributed according to a formula based on number of nodes, type of nodes, etc. [flame on] There is absolutely no reason that network access charges should be packet based. It makes no sense on a local area network like Ethernet and no sense in a packet internet. Users will not understand the charges (as well as contract auditors) and you won't be able to justify them. "Well, let's see your diskless workstation used 45k NFS packets last month." "What do you mean, all I did was read netnews!" Local area networks do not cost you on a per-packet basis and you don't need to recover on a per-packet basis. Per packet only works on (virtual) terminal networks, networks of the past. [flame off] Kent England, Boston University
david@ms.uky.edu (David Herron -- One of the vertebrae) (04/14/88)
In article <21618@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > [flame on] There is absolutely no reason that network access >charges should be packet based. It makes no sense on a local area >network like Ethernet and no sense in a packet internet. Users will >not understand the charges (as well as contract auditors) and you >won't be able to justify them. "Well, let's see your diskless >workstation used 45k NFS packets last month." "What do you mean, all >I did was read netnews!" > > Local area networks do not cost you on a per-packet basis and >you don't need to recover on a per-packet basis. Per packet only >works on (virtual) terminal networks, networks of the past. [flame >off] I can't believe I'm about to argue for the grey suits, but here it is. It costs a certain amount of money to install/maintain an ethernet. Ethernet's have a certain maximum number of packets they can pass over a period of time. That ratio gives you a first guess at the cost per packet. The same holds true for some phone line which is being rented from the phone company which gives you 9600bps or 56k or t1 or whatever. That phone line costs x, you can do at most y through the line, so x/y gives you a cost per packet. The place where it's more obvious is a net that DOES charge per packet, like I understand X.25 nets do. As was pointed out rather eloquently from a gentleman in Australia, a charge per packet gives a different style of protocol than not having the charge. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- I don't have a Blue bone in my body!
bzs@BU-CS.BU.EDU (Barry Shein) (04/15/88)
Yes, but the problem is that those network elements cost the same amount if you don't use them. I dunno, there's something wrong with these cost accounting arguments, but I can't quite put my finger on it. Maybe that's it, you can't ever reclaim the unused capacity of a network, all idle time is lost forever, so why charge someone simply for making it not idle? Something like that. Back to the 1040... -Barry Shein, Boston University
tsmith@USNA.MIL ("Tim G. Smith", Mechanical) (04/15/88)
Kent England, Boston University writes < You say that the auditors require per-packet charging to < fairly allocate costs. Do they require each dept to pay a separate < rent or to install separate phone systems or to buy their own < furniture and pencils? They do not. That depends who you work for. < If MILnet goes to packet charging, and I don't see how they < can do it, those costs could still be approximately redistributed < according to a formula based on number of nodes, type of nodes, etc. Talk to the bean counters- it is not a case of IF, it is a case of WHEN. I also think it will be an administrative nightmare to handle the billing but that is not my problem. < [flame on] There is absolutely no reason that network access < charges should be packet based. It makes no sense on a local area < network like Ethernet and no sense in a packet internet. I tend to disagree- the gateways and the point to point links are running at higher and higher capacity. Some folks only use the MILnet to get and send small amounts of mail. Others use to FTP humongous files around and get news. Everyone bitches when the response times spiral and everyone gets hurt by it. I think everyone would like to see increased network bandwith. What should be done to raise the money to expand the network? Should the folks who use the network only sparingly have to bear the cost of the people who use the net heavily? < Users will not understand the charges (as well as contract < auditors) and you won't be able to justify them. "Well, let's see < your diskless workstation used 45k NFS packets last month." "What < do you mean, all I did was read netnews!" Well I guess we will have to do some educating. < Network costs could be set up as an overhead charge. Links to < outside networks like the internet are flat rate and this cost could < be allocated to each dept based on a formula. The only trick if there < is one is the formula, but every organization has a formula for < allocating basic telephone service with cost-per-message added on as < needed [long distance billing, for example]. So long as your formula < approximately distributes actual costs to all departments and only < recovers actual costs and a share of other overhead, it should be < acceptable to auditors. Yes there will be problems but that is life- chock full of problems. I would rather see a flat rate for internal (ie localy owned) network traffic. An analogy is trucks on toll roads. Do trucks pay more than motorcycles to use the road? Yes- because the maintenance the road will require for each truck that uses it is significantly greater than the maintenance required by a motorcycle using the road. (Tell me is your long distance bill on your telephone flat rate?) < Local area networks do not cost you on a per-packet basis and < you don't need to recover on a per-packet basis. Per packet only < works on (virtual) terminal networks, networks of the past. [flame < off] Sure they do. If you want to know the cost per packet of the network you take the cost of the network (hardware, phone lines, maintenance) divided by the total number of packets using it. That gives the cost per packet. I think we all need to remember that the Internet is a research project (a successful one it appears)- that is why its cost has been subsidized so heavily. We all have to face the fact that we are using the Internet just like we use telephones, mail, and other tools essential to our work. If we want to keep the service we are going to have to pay for it. If we don't want to pay for it then I suppose that we can all go back to using whatever we used before there was an Internet. Before I get flamed to death just let me say... I am not looking forward to the impending switch to per packet charges. I would rather see the flat rate continued. But if per packet charging will result in better service than so be it. I also can understand the reasoning that went into the decision to make the change. I think we all are going to have to simply learn to live with it. Tim Smith E-Mail :<tsmith@usna.mil> US mail:Tim Smith CADIG mailstop: 11G US Naval Academy Annapolis, MD 21402
philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) (04/15/88)
I remember being told once by a telco person that 80% of the toll collected on long lines was just to pay for the accounting process itself (this was in the days when they sent the armoured truck to pick up the AMA tapes). I don't know how much this has changed. I can easily see a significant amount of gateway resources (bandwidth, memory, CPU) being eaten up just by accounting, which would mean getting a more expensive box... so you would pay more to get what you get now. For this reason, I think the flat-rate charge is a good idea (but then I also favour rate-of-return over price-capping). -Philip
wbe@bbn.com (Winston B Edmond) (04/16/88)
Barry Shein writes: > >Yes, but the problem is that those network elements cost the same >amount if you don't use them. > >I dunno, there's something wrong with these cost accounting arguments, >but I can't quite put my finger on it. > >Maybe that's it, you can't ever reclaim the unused capacity of a >network, all idle time is lost forever, so why charge someone simply >for making it not idle? Something like that. Back to the 1040... Indeed. The best charging scheme will probably be like the phone, electricity, and other utility bills: a basic charge for providing service at some level plus additional charges depending on usage and time of day (expected network loading). The problem is that in order to do the "depending on usage" part, one must implement per packet accounting, even if some usage is covered by the monthly flat rate. -WBE
tsudik@MALIBU.USC.EDU (Gene Tsudik) (04/17/88)
Alternatively, a "best" charging scheme could be like the payphone scheme used in some European countries. There you pay for some fixed number of minutes and get a card (sorta like a debit card) and then you use it over time. One could simularly have a scheme where a machine (organization) buys X megabytes of data and uses it over time thus minimizing the extraneous traffic associated with accounting packet needed per connection. The scheme of course would have to be a little more complex than that. Per connection charges should also be available but discouraged. Gene Tsudik
Mills@UDEL.EDU (04/17/88)
Gene, You have discovered the Farecard used in the Washington Metro Underground (tube). You should ask a Washington dweller how well the Farecard dispensing machines work. Dave
CERF@A.ISI.EDU (04/17/88)
Kent, Your flames seem a bit excessive (but I suppose that's a tautology...). In networks like the Internet there are components such as the gateways, wide area network switches, and shared trunks whose costs could reasonably be allocated on the basis of usage. When multiple administrations (such as DOE, DOD, NSF, HHS, etc.) share facilities, it is important to be able to demonstrate that costs are related to services rendered (used) in some fashion. The reason is that each agency quite properly could be asked by Congress, for instance, to show that it obtained its fair share of the facility (based on what it paid for). One might, as you suggest, some up with a formula for sharing some of the fixed cost of the network (a sort of base price you pay to be connected to the system at all). 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. 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. I'm no longer with the government, so I certainly can't speak for the agencies involved, but I'm extrapolating from experiences I had at DARPA from 1976-82 when questions about access to ARPANET and sharing of costs were considered. 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. I'm not saying you couldn't do it on the basis of ports or nodes - the ARPANET did it that way for years - but thenit seemed to me a little harder to distribute the cost of adding a larger scale packet switch somewhere. In any case, the present focus on accounting is, in my view, important and valid and we should work to help the government folks find reasonable ways to implement it. Vint
ittai@VX2.GBA.NYU.EDU (Ittai Hershman) (04/18/88)
Perhaps this should go to RISKS instead :-) When I was down at the TCP/IP Interoperability Conference in December, I found a few hours to go into town and meet a friend for lunch. I have a farecard I keep in my wallet which I use whenever I'm in DC -- miraculously it still worked. Well my friend decided to drag me to a State Dept press conference and I went through some metal detector. When I got back to the Metro station to return to Arlington, I discovered the farecard would not work (my Am Ex card was fine, and the farecard was readable in the station office's computer, but not by the turnstile). Maybe it was just a fluke, since I'm sure many State Dept employees ride the Metro, or maybe they have lead-lined wallets... Anyway, the discussion of farecards on the TCP-IP list was just too hard to pass up. -Ittai
haverty@CCV.BBN.COM (04/18/88)
Vint et al, One way we have found useful to think about accounting and charging in networks is to think of the network as a business. It has customers today, and offers a set of services to those customers with some charging policy ($0.45 an "ounce"?). In order to deliver those services it needs to acquire capital assets (lines, switches, satellites), and provide operations services (operators, field service, administrators). It can make a business decision between providing the services to its customers by use of its own assets (e.g., buy a satellite) or by use of services obtained from somewhere else (e.g., use dial-up trunks to provide service). At any point in time, the charter of the business is to provide the services to its clients at least cost, and to allocate those costs across the clients. Here's where it gets sticky. Clients' needs change, as new technology is introduced (e.g., 3D color workstations), and available communications technology changes as well as technology advances (fiber, etc.). Thus in order to stay in business, the network must plan to invest in new technologies, and must make smart business decisions about what to do and when in order to keep costs low, and remain competitive in the "marketplace". 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?) The point is that there is a large body of science and practice with elements such as depreciation, revenue, IR&D, etc which allows someone to place the network management into a business context. The real question is the one which the CEO of this hypothetical business has to answer - what is my business plan, how will I market my services, what should I invest in to remain competitive, etc. In the government network context, one should probably add the constraint that the network be non-profit, because of the limited competition and 'infrastructure' nature of the network. 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. Perhaps triple charges for any host failing to obey a quench? As someone else pointed out, this is a real hot topic right now, and in fact I think it is a not insignificant flaw in the research activities that the methodology for 'chargeback' was not developed as part of the network architecture from day one. No one has 'the right answer' as far as I can see. Are there any MBAs or business school students who need a good meaty research area out there????? Jack
Mills@UDEL.EDU (04/18/88)
Ittai, Well, in nine years Farecard machines munched not my oxide, but did munch the printer ribbons so I seldom knew how much money was left. I learned the trick of running an unreadable card through the machine anyway. If it spit the card back out, there was more than $2 on it. If it kept it there was less and you could get the card back by cancelling the transaction. The above trick is not well known and may rescue one of you someday. Try putting a Farecard through a credit-card reader. With this I promise to shut up. Dave
bzs@BU-CS.BU.EDU (Barry Shein) (04/18/88)
>Are there any MBAs or business school students who need a good meaty >research area out there????? > >Jack I agree wholeheartedly. As much as people like to tell themselves they understand the issues I honestly think this is the kind of thing for which professionals exist who can perhaps raise the level of the discussion beyond "is not" -- "is too". There are several models to look at (utility, infrastructure etc.) Just wandering around the machine room with a meter and wondering where to stick it is not the obvious answer. There are good reasons, for example, that you are not charged for every use of the road you drive on to go to the corner grocer but instead the costs are built into a larger structure. 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. -Barry Shein, Boston University
mckee@MITRE.ARPA (H. Craig McKee) (04/18/88)
>The problem is that in order to do the >"depending on usage" part, one must implement per packet accounting, >even if some usage is covered by the monthly flat rate. > -WBE The "per packet accounting" load could be limited by using sampling techniques, like the US Postal Service does when allocating costs to government departments. Regards - Craig
CSYSMAS@OAC.UCLA.EDU (Michael Stein) (04/19/88)
> The "per packet accounting" load could be limited by using sampling > techniques, like the US Postal Service does when allocating costs > to government departments. Regards - Craig Is the overhead of counting packets really that high? I would assume that any IP router would have a "total" packet counter included in its overhead (1 counter). How much overhead would be added to count packets to each "interface" on the router (may already exist) and then "bill" each interface for it's count of packets? This doesn't divide the counts by host (IP address), possibly the hosts could be trusted to do that. (You would know the total). Hosts need accounting anyway, so that they can charge the packets back to the actual user anyway (assuming multiuser host).
ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) (04/23/88)
There is lots of good economics research on how to price for services which are mostly based on fixed capital investments. Consider local phone service: you need a wire from your house to the local telephone central office whether you make one call or many calls. On the other hand, the computer which sets up calls grows in proportion to the number of calls made, while the cost of the switch matrix is proportional to total length of all calls. Inter-office trunk requirements depend upon the volume of calling minutes in the peak hour. Thus optimal local phone prices should probably have some component which is based on connection cost (to cover the local loop), some component based on call frequency, and some component based on call minutes. Moreover, these rates should be different in peak hours than in off peak hours, because only peak hour traffic stimulates the need for more trunks. Using pricing to shift usage from peak to off peak hours reduces the peak trunk requirements. Long distance telephone rates already make use of this simple fact. Computer service bureaus have long since learned these theories and have implemented them in their pricing policies. Two particularly good articles are: Mitchell, Bridger M., "Economic Issues in Usage Sensitive Pricing," The RAND Corporation P-6530, 1980, and Park, Rolla Edward, and Bridger Mitchell, "Optimal Peak-Load Pricing for Local Telephone Calls," RAND, R-3404-1-RC, March 1987. A more accessible article is: Mitchell, "Optimal Pricing of Local Telephone Service," American Economic Review, Sept, 1978, and