Document the ping protocol

[adrianhopebailie]

Document the ping protocol as implemented in interledgerjs/ilp-connector

[dora-gt]

I'll do this next.

[dora-gt]

I could almost understand by reading echo.ts, but I could not find the module that actually sends requests.
Is this used from somewhere?
Could you give me some references that send requests?

[dora-gt]

I found that moneyd-gui used it. So I'll look into it.

[sappenin]

The ping protocol is in-use in the JS Connector - we should keep this issue open, or else overtly indicate that the ping protocol should not be spec'd.

[sappenin]

Bumping to keep this open a bit longer...

[adrianhopebailie]

As discussed on the community call on Wed 14 November there are some concerns about the protocol currently implemented in moneyd-gui and ilp-connector.

@emschwartz and @sappenin please feel free to expand on this.
@justmoon and @sharafian your input also welcome as the implementors of these two componenets.

The high level flow for that protocol is as follows:
Assuming Alice (ILP Address: g.alice) is sending a Ping to Bob (ILP Address: g.bob).

1. Alice generates a new random 32 byte value to use as a fulfilment (F) and generates the corresponding condition (C).
2. Alice constructs an ILP Prepare packet addressed to g.bob with:
   • a non-zero amount of her choice
   • an appropriate expiry (quite long as it must allow for two round trips along the route)
   • the condition C
   • a data payload consisting of
     • the ascii encoded text string "ECHOECHOECHOECHO"
     • the byte `0x00
     • A return address (g.alice) as an OER encoded, variable length IA5 string (same as encoding used in the packet header)
3. Alice sends this packet out on the network
4. On receiving this packet, Bob (a connector) identifies that it is a Ping by the fact that it is addressed directly to his connector address (i.e. it has no tx or child suffix) and by the fact that the byte following the "ECHOECHOECHOECHO" prefix in the payload is 0x00.
5. Bob DOES NOT immediately send an ILP Fulfill. Instead Bob creates a new ILP Prepare addressed to the address parsed from the payload with:
   • an amount equal to the amount received in the ILP Prepare
   • an expiry that is marginally smaller than the expiry on the ILP Prepare
   • the same condition C
   • a data payload consisting of
     • the ascii encoded text string "ECHOECHOECHOECHO"
     • the byte `0x01
6. Bob sends this packet out on the network.
7. On receiving this packet, Alice identifies that it is a Pong by the fact that it is addressed to the address she used in the Ping.
8. Alice fulfills the packet using the fulfilment she generated at the beginning: F
9. On receiving the ILP Fulfill from Alice, Bob also fulfills the original Ping from Alice using the same fulfillment.

Observations:

1. This protocol results in money being spent by both Alice and Bob.
2. If Alice sends too much Bob can claim some by sending the Pong with less and hoping Alice will still fulfill the Pong.
3. It's not clear how Alice could differentiate a Pong from other packets right now as she uses her address with no additional suffix.

Other discussions on the call

1. Do we need a simpler "heartbeat" protocol that is just between peers to allow the ILP module on each peer to ensure that packets are routable. I.e. Not only is there an available data transport but the connectors are in a state to be able to route packets.
2. Would an authenticated ping protocol be a better way to go (at the transport layer). (Public middle-boxes like connectors can be contacted securely by sending the payload encrypted with their public key. i.e. You can still ping connectors directly)

[justmoon]

Just going to leave this here: #232

That was a PR to add an RFC for the ping protocol, although that PR describes an earlier version of the protocol, so @adrianhopebailie's description is more accurate/up-to-date. Still, anyone working on docs for the ping protocol may find it useful to read this for context.

[justmoon]

It's not clear how Alice could differentiate a Pong from other packets right now as she uses her address with no additional suffix.

That's just an implementation detail/bug. The intent is that Alice would choose a unique address that is only used for a particular pinging session.

Remember the model is IP, so we think of moneyd as the stuff that would be built into OSes some day. When a piece of software like a ping tool spins up, moneyd will assign a unique address to it. In the case of a ping tool it will then use that unique address as its return address.

If Alice sends too much Bob can claim some by sending the Pong with less and hoping Alice will still fulfill the Pong.

I don't see that as an issue. If Bob sends back a lesser amount, that's no different than if there was simply high friction/fees between Alice and Bob. In many real-world scenarios, the cost of looking like your ILP connectivity is poor is going to vastly outweigh any money you might make from pings. Imagine if a popular connector started doing this: They might make $0.0001 from pings but nobody would want to peer with them because it looks like their connectivity is trash, so they'd quickly go out of business.

In our experience, pings have been used in production mostly to test/debug the routing protocol and to monitor uptime of ILP connectors. You can and should use amounts that are miniscule.

[emschwartz]

@justmoon Are you worried about this being used in DDoS attacks at all? Because the source address isn't authenticated or checked at all, an attacker could get a lot of other nodes on the network to simultaneously send packets to a single target. The amount of data they'd be sending isn't that big so there wouldn't be the amplification problem, but it still seems potentially problematic.

One argument against this being a problem is that it would be easy to filter out and drop these packets if you're getting too many of them at once (but you need good infrastructure that's capable of doing that quickly for a ton of packets received in quick succession).

[sappenin]

One observation I've had about what we call "ILP Ping" is that it seems to be designed to be analagous to the Ping we all know and love.

What's interesting here is it that while that protocol (ICMP Ping) employs a "ping" and a "pong" packet, this seems to be more of a result of using ICMP more than anything else (in other words, the ICMP Echo Reply packet feels more like a "response" as opposed to a new request, despite what's actually going on in ICMP).

The reason I bring that up is that I think it would be useful for us to distinguish between an ILP Ping protocol and an ILP Echo protocol.

Here's how I see the distinction:

Ping Protocol

• Option1: Sender sends a Prepare packet with a tiny amount of value, and measures the time it takes to receive a Fulfillment.
• Option2: Sender sends an unfulfillable Prepare packet, and measures the time it takes to receive a rejection.
• Rationale: Measure the time it takes to send value in one direction via ILP; Determine if a sending node has payment connectivity to a given destination.

Echo Protocol

• Functionality: See description above by @adrianhopebailie.
• Rationale: Measure the time it takes to send value in both directions via ILP; Determine if a sending node has bidirectional (send+receive) connectivity to a given destination.

Any objections to formally defining both protocols as orthogonal things?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.

[adrianhopebailie]

This issue was moved to https://forum.interledger.org/t/document-the-ping-protocol/279