Re: failures during the preparation phase (universal mode)

> 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.

I'm guessing that the intention there is that the proposal phase is
initiated by the sender, while the prep phase is done one hop at a time?
This would seem to assume that the route will be determined by the sender.

Maybe I'm wrong, but are you recommending the nested transactions as a
substitute for the direct connection of the proposal phase?

Why not just eliminate the sender's knowledge of the entire route? Does the
sender know the entire route that a packet is going to take on the internet?

If there is going to be some kind of source routing in five bells that's
fine, but it seems weird to integrate it that deeply into Interledger, a
low-level transmission protocol.

Like this: Stefan escrows a payment to me on our ledger that I can only
redeem with some cryptographic condition. At this point, I want to know who
I need to escrow a payment to to get the fulfillment to that condition.

- With the current ILP proposal phase, I was sent the information on how to
get the fulfillment by the payment sender, who presumably knew the network
map and ran a pathfinding algorithm.

- With RPR <https://github.com/jtremback/reactive-payment-routing>, that
information is found during a routing phase, during which the receiver
sends out a routing message that floods the network.

- With some hypothetical BGP-like payment routing protocol, that
information would come from a routing table.

Are the last 2 routing methods possible with the ILP proposal phase? I
think not, maybe I'm wrong.

On Fri, Mar 11, 2016 at 11:24 AM, Stefan Thomas <stefan@ripple.com> wrote:

> > 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.
>
> Yes, these are all options.
>
> > 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.
>
> Great point. As you pointed out on IRC, the Nested Transfers [1] spec is
> essentially a realization of your idea here.
>
> [1]
> https://docs.google.com/document/d/1zTLQLBx0p6-Ds9Ki8nCaVBdXUK4mbJZDQOaz83n6VY8/edit
>
> On Mon, Nov 23, 2015 at 2:24 AM, Xavier Vas <xavier@tr80.com> wrote:
>
>> Hi,
>>
>> 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.
>>
>> Thanks
>>
>> Xav
>>
>>
>>
>>
>