Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bbn!bbn.com!wbe
From: wbe@bbn.com (Winston B Edmond)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: packet charging (the EFT model?)
Message-ID: <23792@bbn.COM>
Date: 22 Apr 88 18:10:40 GMT
References: <8804220957.AA26052@ucbvax.Berkeley.EDU>
Sender: news@bbn.COM
Reply-To: wbe@BBN.COM (Winston B Edmond)
Organization: BBN Laboratories Incorporated, Cambridge, MA
Lines: 29

Michael Stein writes:
>Instead of a "WILL/WONT PAY" protocol (which only works on
>connections) how about something else:
>
>Suppose that it was possible to send packets containing "money"?

This sounds like a good, general solution.  If I understand it right, billing
by the network ALWAYS go to the sender of the packet, but the "money"
transferred becomes a promise to pay from one host to another.  Thus, at the
end of the month, the host administrator will get a bill for network
services, pays the bill, and has X dollars in Accounts Receivable from other
hosts sending "money", and Y dollars in Accounts Payable the host has
promised to send to other hosts.

You will need to figure out how to say "I'll pay up to D dollars", since the
cost of a message may well depend on the Internet path it takes between the
hosts.  It may also be difficult to "make change", since the price of the
packets to return money may cost more than the amount to be refunded.

However, if you want the end-of-the-month bill from the networks to directly
reflect the "money" exchanged, then I caution again that the final exchange
of money or billing charges should be between the billed client and the
billing entity (the network) in order to prevent counterfeiting, empty
promises, and even ordinary billing errors.  This means the protocol for
paying wouldn't a high level protocol like IP, but an enhancement to the
network level protocols.

The Automatic Teller networks have solved this kind of reliable money
transfer, so perhaps we don't need to reinvent everything.
 -WBE