ietf-asrg
[Top] [All Lists]

Re: [Asrg] About that e-postage draft [POSTAGE]

2009-02-23 07:18:56
Bill Cole <asrg3(_at_)billmail(_dot_)scconsult(_dot_)com> wrote:

... The problem is that logically you need a third intermediate state
that will last for the RTT of the network connection to the redeeming
client, and that state will defer the decision for other attempts to
redeem the stamp.

   We're getting a fair ways from the POSTAGE spec into the BANKING
spec (not yet written), or actually beyond it, since it deals with
customer interface, not internals.

   However, while you're welcome to implement your "bank" that way,
I'd pretty strongly advise against even trying to maintain distributed
state. The state of the token can be simply "redeemed" whether the
presenting customer _ever_ learns about it.

   The customer really doesn't care about the state of the token. They
care whether their account has been credited the appropriate amount.
And they don't care about which microsecond that credit happens in --
they'd be happy waiting tens of seconds.

A legitimate stamp needs to have 3 possible states in the server's map: 
redeemed, unredeemed, and pending acknowledgment of redemption. If the 
server only has two states for a stamp, then it would end up with one
of two flaws by design:

1. If the stamp is marked as redeemed when a successful redemption
   attempt completes on the server, it is possible that the success
   will not be successfully communicated to the client. If the client
   then retries the redemption, it will fail.

   As it should, IMHO. It's just as abusive for the receiving SMTP
server to multiply redeem tokens as for the sending SMTP client to
send multiple copies of the same token.

   (Obviously, the customer interface with the bank should consider
how to work around communications failures; but a simple retry is a
particularly bad way to do so.)

2. If the stamp is left as unredeemed while waiting for the client
   ack of success, stamp "reuse" becomes a question of how many
   redemption decisions can be made per client RTT.

   RTT, alas, is a variable. :^( An abusive customer could draw it out
way beyond reason.

I suspect that the "solution" that will be chosen if anyone tries to
create a real e-postage system instead of hand-waving about it will
be to open it to lost packet damage as the cost of scalability.

   That is a business decision. (More exactly, to what extent the "bank"
tries to adjust for packet loss is a business decision.)

Network latency with clients becomes irrelevant if the server assumes
that its redemption messages are always delivered.

   Yes, and it may be the case for many "banks" that standard TCP is
considered sufficiently "reliable".

That allows for a lot of optimization. Once in a while a stamp that
should work will fail to do so, and if such a system ever gets into
the real world I'm sure its users will be shocked at how much higher
the real-world failures are than in their tests...

   No doubt some will be...

--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg