RE: failures during the preparation phase (universal mode)

The model of each node providing a bid for total cost to get required amount to the destination seems to work logically. The node has the incentive to find the cheapest route from self to destination, as that maximises their own possible profit while still minimising the senders costs, so aligning incentives

This can allow nodes with spare capacity/escrow to outbid those that are currently more heavily committed, while not needing the sender to have detailed knowledge of the possible routes. So It feels easier to scale.

As a buyer of the services of a node, I would also want some measure of current quality of service from that node as well as absolute price, to help me choose which of several bidding nodes to take. Not sure if the “Quality Of Service” is an appropriate term here, but the measure would allow me to make the trade-off between low cost and likely delivery quality. Sometimes cheapest is not always what I want.

Without the quality measure I become vulnerable to a node bidding low cost, but not actually providing a reliable service, so I end up with a failure to transmit and need to seek another route after I get my escrowed payment back.

From: Evan Schwartz [mailto:evan@ripple.com]
Sent: 15 March 2016 16:52
To: Jehan Tremback <jehan.tremback@gmail.com>
Cc: Stefan Thomas <stefan@ripple.com>; Xavier Vas <xavier@tr80.com>; Interledger Community Group <public-interledger@w3.org>
Subject: Re: failures during the preparation phase (universal mode)

As you point out, routing could be handled by each successive node, though I would see two potential issues with that approach.

First, when the sender constructs the full path, they know whether they want a fixed source or destination amount and can quote it accordingly. If they are instead going to pass off the request to the next intermediary, and let's say they wanted a fixed destination amount, how would they determine the source amount? It might work if each node could also provide a quote of how much it would cost to route the payment, but I'm not sure how much better this would be than the current setup. Definitely worth discussing more though.

The second, somewhat related, issue that will come up with payment routing but not IP packet routing is that of fees. If each node takes some kind of fee there's a strong incentive to get payments to flow through you. If the sender is picking the path, they obviously have an incentive to find the best path possible. The other nodes will have an interest in having the sender (or receiver) pay as much as possible. Anybody have ideas about how to do the node-by-node routing such that it still gives the sender the best deal?

On Fri, Mar 11, 2016 at 12:16 PM, Jehan Tremback <jehan.tremback@gmail.com<mailto:jehan.tremback@gmail.com>> wrote:
> 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<mailto: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<mailto: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







--
Evan Schwartz | Software Architect | Ripple
[ripple.com]<http://ripple.com>