W3C home > Mailing lists > Public > public-interledger@w3.org > November 2015

failures during the preparation phase (universal mode)

From: Xavier Vas <xavier@tr80.com>
Date: Mon, 23 Nov 2015 10:24:28 +0000
To: public-interledger@w3.org
Message-ID: <5652E949.1000507@tr80.com>

I'd like some clarification on the preparation phase in universal mode.
I assume a connector can, when receiving a preparation message from a
previous connector, deny performing the escrow on its outgoing ledger
and instead pass an error message back, or just let the escrow timeout
on its incoming ledger expire. Either way, this will percolate back to
the payment originator and the payment has failed its preparation phase.

Reasons for failing to execute the escrow on behalf of a connector could
be technical problems etc. but most likely, I assume, not having enough
funds at its disposal to execute the escrow. This can happen in spite of
a confirmation during the proposal phase, as confirming funds to be
available does not mean setting aside said funds for a later
transaction. It can at best be a good guess that involves parameters
such as funds available, rate of transactions processed, typical delays
between proposal and preparation phases and -- most importantly --
likelihood of customers actually following up a proposal with an actual
transaction, because they can propose several paths and only execute
one, if even, e.g. the one with the lowest fees.

The latter I guess would be like airline passengers booking seats on
several flights and only showing up for one at best. Airlines compensate
for this behavior by overbooking their flights, which then in turn may
lead to booked passengers being turned down. Booking a seat is the
proposal phase and showing up the preparation phase of the transaction.

Either way, if a payment fails during the preparation phase, what then?
The originator will initiate another preparation phase with the same
connectors? Or another proposal? Or find different connectors? I guess
all the options are open. The next attempt could also, conceivably, fail
again then.

IMHO that makes the preparation phase a phase of trial and error, much
like -- presumably -- the proposal and preceding path finding phases. If
so, why bother differentiating between these? Where is the necessity for
a more complex multi-phase protocol? Complexity killed the cat as they
say so its necessity should be well-reasoned.


Received on Monday, 23 November 2015 11:13:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 November 2015 11:13:14 UTC