packet charging (the EFT model?)

Michael Stein (csysmas@UCLA-CCN.ARPA)
Thu, 21 Apr 88 06:36 PDT

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?

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:56 GMT