mckenzie@LABS-N.BBN.COM (Alex McKenzie) (04/18/88)
Jack and Barry have both said it right; a charging mechanism (tariff) is more than the rules for collecting money - it is also the concrete specification of a policy (and the only policy statement that really counts). Policies can be made to encourage or discourage connection to a network, encourage or discourage use of a network, or favor some classes of users over others. A proposed tariff has to be examined to see whether it supports or contradicts other "statements" of policy. For example, when DCA took over the ARPANET from ARPA in the mid-70's they adopted a "per-port" tariff because it was simple and predictable. The instantaneous response of the user community was the invention of a class of devices called "port expanders" which had no logical justification other than local cost minimization under the tariff, with a negative side-effect of making troubleshooting harder. Those are the kinds of effects which the folks formulating a tariff must be sensitive to. For every proposed tariff someone should ask, "If I had to pay according to this tariff, what would I do to minimize my own cost?" If we don't like the answer, the tariff should not be implemented. Alex
CERF@A.ISI.EDU (04/18/88)
Alex, I disagree with your assertion that the port expander was motivated by the per-port tariff on DDN/ARPANET. In fact, it was motivated by the fact that an IMP could only support 4 host ports at the time and we needed more connections but could not afford to pay for an entire IMP (the cost per port for a 4 port IMP was high; now IMPs can support many more ports at less cost per port). Vint
CERF@A.ISI.EDU (04/18/88)
Addendum: It was CAPITAL cost, not operational cost, that motivated the port expander, in case it wasn't clear in my earlier response. Vint
WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") (04/19/88)
Last year I sent out a message outlining the pitfalls and problems with the per-packet chargeback algorithm to be levied on the MILNET hosts and gateways. No response at that time. Since then, the ARPANET Lives message came out, hinting at the imposition of similar charges for ARPANET hosts, followed recently by Bill Barnes' query. That combination must have triggered a sympathetic reaction. Let me point out several points to ponder: 1. Unlike the ARPANET, the MILNET backbone users have been offered not one single carrot/reason for the charges, such as the promise of an improved, high-speed backbone. The ONLY reason is to divide the EXISTING cost of the MILNET backbone among the services based on the usage by each service. (Service means Army, Navy, Air Force, etc.) 2. The mods to the PSN software have been in-place for over a year with delayed monthly charge reports being produced as a paper exercise only to check for accuracy and format. All that is required at this point to implement the scheme is the declaration of the date on which the paper charges become real. It would then be up to each service to pay the bills, possibly going back to charge each facility connected to the backbone - the reports are supplied at that level. I suspect that the effort to change the rates charged would be trivial as that would be a post-processing change. But, the effort required to change the underlying traffic collection algorithm would certainly be non-trivial at this point. 3. The algorithm itself is flawed (in my opinion): it is based on charges only for outgoing packets, and TAC access (including connect time, not just packet charges - in BOTH directions). That severely penalizes hosts which act as mailing list distribution points, those which offer anonymous ftp access, and those which allow telnet access, particularly from TACs. 4. Geoff is right. Given the rates and charging algorithm, we will find expedient solutions: shut down our mailing list redistributions, disallow all ftp and telnet access, including outgoing ftp and telnet, and move off the backbone... To answer Bill's query: the network applications programs on the hosts connected directly or indirectly to the corporate gateway(s) would have to tag each outgoing packet with a cost center code which is then counted and stripped at the gateway(s) prior to entering the backbone. I know it's absurd, but that is the "correct" method to keep the bean counters happy. --Frank
david@elroy.Jpl.Nasa.Gov (David Robinson) (04/20/88)
In article <WANCHO.12391659408.BABYL@SIMTEL20.ARPA>, WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") writes: > 3. The algorithm itself is flawed (in my opinion): it is based on > charges only for outgoing packets, and TAC access (including connect > time, not just packet charges - in BOTH directions). That severely > penalizes hosts which act as mailing list distribution points, those > which offer anonymous ftp access, and those which allow telnet access, > particularly from TACs. This offers interesting accounting problems for sites that serve as a gateway for other organizations and networks. The number of networks that are gatewayed through a particular organization is growing. How will NSFnet and CSnet handle the chargebacks to their users? Same for Bitnet mail relays. I can see the unfortunate situations where these other networks shut off external Mail and FTP access to the Internet. Also how does one charge back between Arpanet and Milnet? Will the long hinted seperation of the nets by the mailbridges be put into effect? -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway!