[comp.protocols.tcp-ip] billing for use

awaldfog@wellfleet.com (Asher Waldfogel) (02/02/90)

	
>I believe that by introducing billing, all mass distribution lists
>will become large "question" boards with no answers.  We will have
>effectively killed off the vast amount of cooperation that goes on
>daily over the Internet.
	
>OK.  So we can't bill the sender.  How about the receipant paying?
>How easy would it then be for some hostile user/host to send a couple
>of gigabytes of information to your host, just so that you got billed
>for it?
	
>I don't believe we can bill by sender or by receiver.  Anyone who
>tries it is just asking for trouble.  If one must recapture costs,
>then use the example given by someone else in this list and impose
>a yearly tax for Internet connection, whether you use it or not.
	
>Hank Nussbacher
>ILAN - Israeli Academic Network

I agree that with the current model of unmoderated lists, it is hard
to adopt a billing policy under which experts answer questions.  But 
I think that magazine subscription is just about the right model for
mailing lists.  I subscribe to the list, and pay for everything that is
sent to me.  I may even pay a subscription which pays for a list editor,
whose responsibility is to keep multi-megabyte diatribes and irrelevant
contributions off the list.  I might also choose to subscribe to an
unmoderated list, and take my chances, or to subscribe to all messages 
shorter than some preset length - with the option to retrieve those messages
later (at my cost) from some archive.

Does this inhibit the exchange of information?  Possibly.  But it might also 
encourage someone to edit and publish old list contributions, which could
answer a large fraction of questions sent in to the list.

I think that intuitively we all agree that the initiator of a message 
transaction bears some responsibility for the costs of fulfilling it -
Vint's "commons" problem - we just need some consensus about who the
initiator really is.  For lists is it the sender or the subscriber?  And
if it is the subscriber, we need some way to bill reverse charges.

Asher Waldfogel

ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) (02/20/90)

One of the positive benefits of billing for use is that it provides an incentivefor users to invest in conservation.  The problem is similar to the problem
of apartment renters for whom energy costs are bundled:  they have no incentive
to close their windows, or turn down their thermostat.

Consider for example FTP of large files.  The published FTP spec has provisions
for a checkpointing procedure so that an FTP can be restarted if the
connection breaks, thus saving retransmission from the beginning of a large
tar file.  Yet virtually no FTP implementations in use today use this
facility.  If users were charged per packet, they could cost justify spending
money on a commercial implementation of FTP which did implement checkpointing.
Our campus LAN doesn't bill for usage, and one user was found backing up
a 10 MB file--in its entirety--to a server every few seconds.  If there were
a charge for usage, he would have spent the few hours
it would have taken to write a procedure
for saving incremental changes rather than the entire file.  Without usage
charges, there was no incentive to spend five minutes on the problem.

I agree with Alex that we must first decide what POLICY we want to have
and then design a pricing strategy accordingly.  I believe, however, that
one element of such a policy must be to provide an incentive for users
to spend effort|dollars on software which is conserving of network resources
when such expenditures are cheaper than adding to network capacity.


Marvin Sirbu
CMU

emv@math.lsa.umich.edu (Edward Vielmetti) (02/20/90)

In article <UZs3N1200ioEM8f4Ma@andrew.cmu.edu> ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) writes:

   One of the positive benefits of billing for use is that it provides
   an incentive for users to invest in conservation.  The problem is
   similar to the problem of apartment renters for whom energy costs
   are bundled: they have no incentive to close their windows, or turn
   down their thermostat.

One of the problems associated with billing for use is that is
provides incentives to circumvent billing procedures, thus generating
possible non-optimal behavior.  Consider a tax on anonymous FTP
transactions; users will either find a way to make their anonymous
FTPs look like something else (run an FTP daemon on the SUPDUP port,
or hide it up in some un-numbered port) or turn to heavier use of
mail-based servers and clog up already jammed mail queues.  Similarly,
a tax on TCP services will induce people to use UDP even when it might
be sub-optimal for use on their particular network.

When you start to bill for use on a per-packet or per-connection
basis, the Law of Unintended Consequences is bound to strike.  
If you have naive or uneducated users, solve their inefficient
use of the network through education, not a tax on their foolishness.

--Ed

bzs@world.std.com (Barry Shein) (02/20/90)

Well, I always say you can either bake more bread or organize bread
lines. I like to listen to the bread bakers myself.

I'm not sure simple conservationist ethics scale very well into the
computer biz. The wierd thing about networking (and computing in
general) is the stuff costs just as much whether it's being used or
not. Actually, it costs more if it's not being used, sorta the same
reasoning one would make about idle land to a farmer, lost opportunity
and all that.

I suppose if one postulates that there will never be enough so we may
as well make sure only the rich get fat. Let's face it, any charges
which are rational in the large will be a pittance to the wealthier
clients. That's why conservation has its limits, you can't charge
enough to stop the gluttonous without killing the starving.

The economics of networking are very subtle. But I do know one thing,
the BOCs don't increase charges soas to get everyone to simply use
less. It doesn't really work that way with infrastructure economics,
it just ain't that simple, or that depressing.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

jim@cs.strath.ac.uk (Jim Reid) (02/20/90)

In article <EMV.90Feb19161732@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>One of the problems associated with billing for use is that is
>provides incentives to circumvent billing procedures, thus generating
>possible non-optimal behavior.

Exactly. What about exchanging routing information? If somebody starts
throwing misdirected packets at me, why should I have to pay for
returning ICMP redirects? Likewise, if I'm running EGP or some other
routing protocol, why should I have to pay for the packets I send to
other sites to tell them what is reachable through me?

		Jim

ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) (02/21/90)

> The economics of networking are very subtle. But I do know one thing,
> the BOCs don't increase charges soas to get everyone to simply use
> less. It doesn't really work that way with infrastructure economics,
> it just ain't that simple, or that depressing.

I'm not advocating conservation for its own sake.  The key part of my
argument is the last sentence.

" I believe, however, that
one element of such a policy must be to provide an incentive for users
to spend effort|dollars on software which is conserving of network resources
when such expenditures are cheaper than adding to network capacity."

Additions to network capacity are not free.  To the extent that packet
conserving software allows costly expansion to be deferred, and the
software is less costly than the expansion, the software is to be
preferred.  True, off peak capacity has low marginal cost.  Conserving
capacity during off peak doesn't save much in plant expansion.  That's
why utilities with usage charges use peak load pricing.  They only need
to encourage conservation during peak hours, since it is peak hour use
which leads to the need for plant expansion.

Marvin Sirbu
 

dricejb@drilex.UUCP (Craig Jackson drilex1) (02/21/90)

In article <EMV.90Feb19161732@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>In article <UZs3N1200ioEM8f4Ma@andrew.cmu.edu> ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) writes:

>> [That billing for use encourages conservation of 'scarce' resources.]

>One of the problems associated with billing for use is that is
>provides incentives to circumvent billing procedures, thus generating
>possible non-optimal behavior.  Consider a tax on anonymous FTP
>transactions; users will either find a way to make their anonymous
>FTPs look like something else (run an FTP daemon on the SUPDUP port,
>or hide it up in some un-numbered port) or turn to heavier use of
>mail-based servers and clog up already jammed mail queues.  Similarly,
>a tax on TCP services will induce people to use UDP even when it might
>be sub-optimal for use on their particular network.

Any billing system will lead to efforts to circumvent it.  However, if
the billing system is fair and reasonably secure, *most people* will
work with it, instead of against.  In your TCP vs UDP case, it wouldn't
make sense to bill for data bytes transmitted over TCP differently than
data bytes transmitted over UDP.  However, attaching a cost penalty would
certainly discourage bad TCP implementations.

>When you start to bill for use on a per-packet or per-connection
>basis, the Law of Unintended Consequences is bound to strike.  
>If you have naive or uneducated users, solve their inefficient
>use of the network through education, not a tax on their foolishness.

The Law of Unintended Consequences will occur in any situation.  But
no amount of education will work if the incentives are all against it.
(Face it.  Everybody's had at least one subject that they studied only
because it was required.  When I say required, that means that there
was some penalty attached to not doing so.)

I think that the idea that 'It is immoral to bill for use on networks'
is an idea which keeps large-scale networks in the research/sugar-daddy
world.  I've been formulating some ideas on this--I'll try to post
something concrete soon.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}