Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an RFC for a echo/ping mechanism #232

Closed
wants to merge 3 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions 0000-echo-protocol/0000-echo-protocol.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
# Echo Protocol

## Introduction

In order to monitor the health of an internetworked system, it is often useful to be able to send test messages. However, not every participant of the system will have multiple points of access to test between or, if they do, they may want to test additional routes.

In the Internet system, a mechanism is provided for sending a message to an arbitary host and receiving a response back. This mechanism is coloquially known as a "ping" and allows users to test their connectivity against countless Internet hosts. We would like to provide a similar mechanism for Interledger.

## Scope

It is already possible to test end-to-end connectivity in Interledger using the quoting mechanism. By requesting a quote, we can check if there is theoretically liquidity between our own account and the destination account. However, this does not prove the liquidity is actually available and it does not say anything about the availability of liquidity in the opposite direction. The Interledger Echo Protocol is designed to be able to fully exercise liquidity in both directions.

The echo protocol is designed to test uptime, latency and cost. It is not designed to debug routing issues and does not provide additional diagnostic information about the state of routing. That use case would be better served by a separate traceroute mechanism.

All Interledger implementations should implement the echo service, unless they have a specific reason not to, such as security or privacy concerns.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


## Terminology

* The **Client** is the Interledger implementation initiating the echo request.
* The **Mirror** is the Interledger implementation responding to the echo request.
* **Source amount** is the amount debited from the sender of an ILP payment.
* **Destination amount** is the amount credited to the recipient of an ILP payment.

## Protocol

1. The Client requests a quote by source amount using the following details:
- Source amount: A small amount considered (by the Client) to be sufficient for a round trip
- Destination ILP address: Mirror's ILP address
2. Upon receiving a quote response, the Client sends a payment using the following details:
- Source amount: The same source amount as in step 1
- Destination amount: The quoted destination amount from the quote response
- Destination ILP address: Mirror's ILP address
- Data: The string `PING` followed by a newline character (a 0x0A byte), followed by a UUID in canonical textual representation, followed by another newline character, followed by the Client's ILP address.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What condition and expiry are used?

Example:
```
PING
0c009642-f64c-45c7-b9e8-a57c95a60556
example.myledger.test
```
3. Upon receiving the prepared transfer, the Mirror initiates a payment using the following details:
- Source amount: Same as the incoming destination amount
- Destination amount: 0
- Destination ILP address: Client's ILP address (taken from the data field of the incoming payment)
- Data: The string `PONG` followed by a newline character (a 0x0A byte), followed by the UUID taken from the incoming payment's data field.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the mirror ever fulfill the transfer?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Example:
```
PONG
0c009642-f64c-45c7-b9e8-a57c95a60556
```
4. Upon receiving the prepared transfer, the Client fulfills it. From here, the payment completes normally.

If an error occurs between steps 3 and 4, the Mirror should relay the error by rejecting the incoming transfer the same way a connector would when relaying an error.

## Recommended Uses

Participants of the Interledger network may use this mechanism to test their own connectivity by sending pings to one or more destinations that are known to support the protocol described in this document.

A monitoring service that is testing the availability of different ILP connectors may send pings to these connectors from various sources. Connectors that wish to use this monitoring service must support the protocol described in this document.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.