Fri, 15 Apr 88 8:08:42 EST
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
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
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
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
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
US mail:Tim Smith
CADIG mailstop: 11G
US Naval Academy
Annapolis, MD 21402
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:55 GMT