Add an RFC for a echo/ping mechanism

[justmoon]

We'd like to:

• Be able to quickly check if our ILP connection is working (ping a host)
• Monitor our ILP instance (by pinging other instances regularly)
• Monitor someone else's ILP instance (by pinging it from various locations)

In order to take into account the liquidity, latency and cost in both directions, the ping should be an end-to-end payment both ways.

I threw together a quick strawman for an echo protocol analogous to ICMP's Echo Request/Response.

[BobWay]

Looks good to me.

[michielbdejong]

I'm not sure if I like this proposal, on two levels:

1. On a per-connector level, it requires connectors to treat quote requests differently if they contain the string 'echo' (they need to always use remote quoting, even if they have a curve for a prefix), and
2. On an end-to-end level, it requires receivers to
   2a) implement ILQP, and to
   2b) act differently in response to an unfulfillable ping payment than they would to an unfulfillable non-ping payment

This seems to add a lot of complexity to our otherwise very simple protocol. An alternative proposal (the one connectorland already uses, actually):

If Alice wants to ping Bob, she establishes an out-of-band communication channel with Bob, a trustline over that, and then sends a small payment to g.bob.newtrustline.alice. She can then send a "ping" payment to herself which tests her connection to Bob.

[justmoon]

On a per-connector level, it requires connectors to treat quote requests differently if they contain the string 'echo' (they need to always use remote quoting, even if they have a curve for a prefix), and

Good point. Obviously, that's a no-go. But you could easily fix it by making echo. the first part of the ILP address. The connector already has different behaviors based on different address prefixes.

On an end-to-end level, it requires receivers to

The receiver isn't required to implement anything if they don't want to offer echo functionality. Many hosts on the Internet respond to pings, but some choose not to. Either behavior is perfectly legitimate. But if someone does want to offer ping functionality, there should be a standard way to do it.

2a) implement ILQP, and to

The ilp module already implements ILQP. Generally, I would expect that ILP modules will contain both sender and receiver functionality. In the case they don't, receivers don't have to implement echo functionality.

2b) act differently in response to an unfulfillable ping payment than they would to an unfulfillable non-ping payment

Again, only if they want to implement pinging.

If Alice wants to ping Bob, she establishes an out-of-band communication channel with Bob, a trustline over that, and then sends a small payment to g.bob.newtrustline.alice. She can then send a "ping" payment to herself which tests her connection to Bob.

This involves a lot more complexity than the protocol described in this RFC. First, we need to define the "out-of-band communication" used to create the trustline and the format of the messages exchanged that way. Then we also need a way to tear down the channel after I've done the ping.

Your proposal also only tests a payment from Bob -> Alice, not from Alice -> Bob.

The user experience I'm looking for is similar to ping 8.8.8.8 in the IP world: There is a tab in ILP Kit Advanced UI where I can type in an ILP address and it'll test both directions of payment.

[michielbdejong]

ok, so how about running a 'ping' account on a ledger, which will send a 'pong' payment for each amount you pay to it? then it's all at the highest layer. could even be on top of spsp.

[justmoon]

ok, so how about running a 'ping' account on a ledger

Then it wouldn't be trivial to figure out the ping address for a given ILP address... Think of how many times you've tried to debug why two machines couldn't talk to each other and went "Hmm, try pinging me..."

I think it's also a good idea for the ping to be low-level. You might use a ping to narrow down a problem you're having. If you're trying to debug "my SPSP payments aren't working", but your ping relies on SPSP, it doesn't really narrow down the problem. You want that "Oh, ping is working, so it must be an SPSP issue" or "Oh, ping is not working, so it must be an ILP issue" effect.

I spent some more time thinking about it today and realized that the connector changes are only needed for the quoting part and we can probably live without quoting just by choosing to ping using some default amount. We need to choose a max cost that we're willing to tolerate anyway.

That also means that we don't need a weird special address, we can ping any ILP address, we just put ECHO [uuid] [return address] in the data field. And that also means that the added complexity for the receiver is next to nothing.

[justmoon]

Updated the RFC using the new simplified flow.

With this new flow, the only proposed changes to the implementation are:

• Add sender feature to send PING payments given an amount and a destination ILP address
• Add receiver feature to respond to incoming prepared PING payments by preparing an outgoing PONG payment and relay errors that occur during the return trip

One possible change we may want to discuss: In the current flow, the receiver doesn't quote. This was done to minimize the burden on the receiver, but it does mean that the sender always pays the maximum. Might be ok if payments are pretty cheap and you can successfully ping with a very small amount (think fraction of a cent.) The alternative is to have the receiver quote by source amount before responding to the ping. The downside is that it's more work for the recipient and if quoting is slow it also means that the payment is on hold for a relatively long time.

[michielbdejong]

only receivers, right? senders and connectors don't have to do anything?

[michielbdejong]

and only if they want to join "destinations that are known to support the protocol described in this document" as mentioned at the end?

[justmoon]

Yes to all three questions.

This is raising some interesting questions though around how separate the sender, connector and receiver functions are. Our ilp module already includes sender and receiver and I don't see a strong reason why it shouldn't also include a connector the same way that IP stacks usually include a connector. It wouldn't add a whole lot to the size of the module as @sharafian's minimalistic connector is proving (and as you would expect.)

[michielbdejong]

instead of "wish to use", "wish to be monitored by" would maybe be more accurate. If it is the monitoree itself who wants to measure its reachability, then we could assume there is out-of-band communication between the monitoree and the monitoring service, and so they could just send test payments in both directions without the need to do roundtrip pingpong.

[michielbdejong]

ok, I think this protocol would be useful in the situation where
a) Alice sometimes acts as a sender
b) Alice is addressable as a receiver
c) there is no out-of-band communication between Alice and Monitor
d) Monitor wants to know if Alice would be able to pay Monitor, should she want to
e) Alice is willing to be monitored by Monitor (that's the same for internet ping)
f) the monitoring service is relatively convinced that Alice's receiver function is working

If all of the above are true, then it makes sense for Monitor to send a PING payment to Alice, as an in-network way to inform her that she should initiate a PONG payment.

So the PING prepare phase is really an in-network way for the Monitor to tell Alice "please send me a test payment", and the PONG prepare (not the PING prepare) is the actual test. I usually think of the PING as the thing that tests, not the PONG. So maybe better terms than 'PING' and 'PONG' would be 'PLEASE PING' and 'PING', respectively. The fulfillment of the 'PING', which goes from Monitor to Alice, is then what I would think of as the 'PONG'

If Alice and Monitor had out-of-band communication, then Monitor could just tell Alice "hey, can you send me a test payment for a tiny amount?" - this is actually what we do a lot in the Luxembourg office, and it's very useful. :)

For this to work usefully, we should implement the 'forwarded by' list in rejection messages, IIRC, we specified that but didn't implement it yet. The Monitor could then see if the test payment made it past Alice or not. If Alice does not implement this protocol, then the Monitor will see that Alice rejected the payment with an error message indicating she doesn't know how to fulfill the payment's condition. That way, not all ILP nodes have to implement this protocol, only the ones that want to be pingable.

So having said all that, I think this could be a useful optional addition on top of ILP! :)

[adrianhopebailie]

What condition and expiry are used?

[adrianhopebailie]

Does the mirror ever fulfill the transfer?

[justmoon]

It passes on the fulfillment that it receives from the return path. Will clarify in the text.

[emschwartz]

@justmoon what's the status of this?

[justmoon]

Will update this once the current discussions about quoting (#309, #312) are settled.

[justmoon]

Closing while we're waiting for other protocol decisions to settle.