Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!OAC.UCLA.EDU!csysmas
From: csysmas@OAC.UCLA.EDU (Michael Stein)
Newsgroups: comp.protocols.tcp-ip
Subject: packet charging (the EFT model?)
Message-ID: <8804220957.AA26052@ucbvax.Berkeley.EDU>
Date: 21 Apr 88 13:36:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 35

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 might be the IP level equivalent of "reverse charges" (since
IP packets aren't related like traffic on a connection).

The idea is that the "network" charges for packets sent (not
new), but will also allow a packet to transfer "money" from the
sender to the target  This could show up as a charge on the bill
to the sender and a "refund" on the bill of the target.

Thus a UDP request to a name server should contain the money
for the reply (or else it's likely there won't be a reply).

It is clearly possible to build a "reverse charge" connection
level protocol on top of this by having one side request
(demand?) "money" to continue.

Note however that much more is possible:

  o either side could pay the whole cost or they could
    split it in any way

  o this also works for 3 (or more) party traffic (it's possible
    to receive "money" and send it out to someone else).

  o this also works across time, I can send payment now for
    something you will do later (time to renew your subscription
    to TCP-IP?)

  o since "money" is general, other net-wide resources could
    also be handled

This can't be practical, can it?