Ping Protocol: Discussion, Necessity, and Design

Protocol Design
1

There have been various discussions around, and attempts at standardizing, a “ping” or “echo” protocol in Interleder, whereby a given node can monitor the health (uptime, latency, cost, etc) of its existing connections and payment paths.

In the Internet system, ICMP echo request and response packets are used together to verify connectivity (colloquially known as a “pinging” a host). In Interledger, we perhaps need a similar system, but there are a number of questions that still deserve further discussion, including whether or not such functionality even needs specifying.

Prior Discussion

  1. RFC Issue #443: Document the Ping Protocol (open issue)
  2. PR #232: An RFC for a Ping/Echo Mechanism (Closed PR)

Loose Definitions

  • Path Connectivity: Can I send a prepare packet from myself to ILP address X?
  • Path Latency: How long does it take for my prepare packet to reach ILP address X?
  • Path Response Time: How long does it take for the response to make it back to me?
  • Path Cost: If I send 10 units to ILP Address X, how much makes it there?
  • Uni-directional: I send a Prepare packet, and expect a Fulfill/Reject.
  • Bi-directional: I send a Prepare packet. In response, the receiver does the same. We each send a corresponding Fulfill/Reject response, perhaps in an ordered fashion.
  • Heartbeat/Ping: Uni-directional only (see definition above).
  • Echo: Bi-directional (see definition above).

Outstanding General Questions

  1. What should the goals and non-goals be here?
  2. Should the protocol be uni-directional (i.e., “heartbeat”/“ping”) or bi-directional(i.e., “echo”)? In other words, should the protocol involve a mirror payment that allows a sender to glean data about both directions of a payment-path?
  3. If we decide there should be two protocols, should there be one RFC that defines both, or should there be two RFCs?

Heartbeat/Ping/ Protocol Questions

  1. What should the goals and non-goals be here?
  2. Is such a protocol even necessary, or do the existing prepare+fulfill/reject system suffice?
  3. Should the response-data to a unidirectional ping request contain anything more than what was in the request-data? For example, ICMP mandates that an ICMP echo response “…must include the exact payload received in the request.”
  4. Should the protocol rely upon a known condition/fulfillment pair, or an unfulfillable condition?
  5. Should the protocol measure just connectivity, response-time, or should it measure connectivity, response-time and latency?
  6. Should the protocol measure path cost?
  7. For collecting cost information, should this be an application concern that is performed using STREAM so that the Interledger layer doesn’t have to embed path-fx-pricing information into an ILP packet (Ping protocol), or else glean this information by inference (Echo Protocol)?
  8. Should a node be able to PING any address on the Interledger, or should this protocol be limited to Interledger hosts/node addresses? For example, the current implementation in the Javascript Connector only allows for ping requests at a HOST level.
  9. 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. If so, what should the address and packets contain?

Echo Protocol Questions

  1. What should the goals and non-goals be here?
  2. Are there security and/or information-leakage concerns if a Connector want to support echo, but is compelled to make a “mirror payment” back to the sender?
1 Like
2

The following is a straw man proposal to separate these concepts into three (four?) protocols with the following properties:

  1. HealthCheck: Send ILP Prepare packets on Link X addressed to peer.health. This should be informatively standardized here.
  2. Ping: Link-level protocol that uses a known Condition/Fulfillment pair and a special ILP address to identify itself. When responding with a Fulfill, targets always include any data that was in the original Prepare request (not the case on a Reject).
  3. Quoting: Use STREAM with very small payments.
  4. Bidirectional Connectivity: Use Echo Protocol[1].

To this end, a Connector can accomplish the following using any of the above protocols:

  1. Link Uptime (Continuously measure uptime on a specific Link/Plugin): Use HealthCheck or Ping.
  2. Link Response Time (Continuously measure response-time on a specific Link/Plugin): Use Ping to peer.ping.
  3. Routability (Determine routability to g.xyz on a particular Link): Use the routing table + CCP.
  4. Debug CCP(Debug CCP routability to g.xyz on a particular Link): Use Ping to g.xyz
  5. Costing(Check path-pricing[1] to g.xyz on a Link X): Use STREAM, send all packets on Link X.

APPENDIX [1]: Echo Protocol: Necessary? Problematic?
In general, I like the intent of the Echo Protocol (PR and outline) because it allows a Connector to establish bidirectional connectivity to a remote ILP address.

However, it’s unclear whether this kind of functionality is actually something a Connector would utilize outside of debugging CCP (it seems like all other goals could be accomplished using other mechanisms in this post).

Additionally, in its current form, the Echo protocol has a few attributes that make me question it:

  1. Mixed Concerns: The ECHO protocol mixes “connectivity/health-checking” with “route costing”, which are potentially related, but ultimately orthogonal, concerns. They should be separated if possible.

  2. Special Packet Treatment: The protocol requires a Connector to apply special treatment to certain Prepare packets, complicating Connector implementations.

  3. Special Response Flow: Due to the flow of the protocol, the Connector needs to hold an otherwise fulfillable packet until it detects a corresponding incoming packet from the target node. Aside from complicating the request/response matching, it also introduces potentially odd delay periods, which likely interferes with a source Connector’s ability to perform response-time tracking.

  4. Potential FX Info Leakage: The protocol exposes bi-directional FX rates that a particular target node may not want to expose to every other network participant. For example, imagine two payment paths A->B->C and C->B->A. If A send an echo request to C, A will be able to discover the FX pricing that C has with B, and potentially use that against B when negotiating its own rates. It should be possible for C to participate in any sort of connectivity-checking protocol without exposing it’s own costs.

1 Like