“Thoughts on Scaling Interledger Connectors” by Evan Schwartz

[KarmaCoverage]

https://link.medium.com/aZuMXj7lIT

Interesting

[Lamberth]

Great article as always from Evan

[Silenos]

More discussion regarding this topic in the Interledger mailing list: https://lists.w3.org/Archives/Public/public-interledger/2019Jan/0003.html

[KarmaCoverage]

1 hour ago, Silenos said:

More discussion regarding this topic in the Interledger mailing list: https://lists.w3.org/Archives/Public/public-interledger/2019Jan/0003.html

If anyone can share thoughts on this, that would be great...

Quote

The one aspect of WebSockets that may be hurting performance is the masking which means that payloads need to be pre-processed before being sent. That said, it's a very efficient algorithm so we'd need to test it to be sure it's an issue.

A concern I have with the cluster of stateless connectors is the latency you'll introduce if the connector must do a balance check against a DB for each packet. This can be optimised to a point but in reality the most efficient way to do this will be to ensure the stickiness at the load balancer routes packets from the same peer to the same connector. Not sure this will be useful in a scenario where both peers are routing high volumes of packets

It is interesting to see where various functions are falling.

Quote

That said, I think decoupling the messaging from the clearing and settlement (FYI: forwarding ILP packets isn't clearing, clearing involves reconciliation and netting, but that's a different issue) will be a huge improvement to the architecture.

I'm guessing (may be totally wrong?) that a Connector/ILSP can "clear or net" flows internally (just like an exchange can do for client trade which they can match) and then only send the non-netted payment flows on down the payment path.

Edited January 23, 2019 by KarmaCoverage

[jn_r]

Here are some thoughts / 2 cts:

3 hours ago, KarmaCoverage said:

a Connector/ILSP can "clear or net" flows internally (just like an exchange can do for client trade which they can match) and then only send the non-netted payment flows on down the payment path

A connector serves its clients (which can be original ILP senders or other ILP connectors) by accepting their payment and forward the payment (route) to the next connector. All the clients have a relationship with the connector, i.e. an 'account'. If for example the relationship is based on an XRP payment channel, then the account can be pseudonymous, but at least it is known and kept for as long as the relationship lasts. The accounts can also be implemented in other ways, e.g. as some sort of debit/credit system.

ILP example flow: Coil browser -> Coil connector -> Strata connector -> xrptipbot 'moneyd' connector -> xrptipbot-ledger account (payment pointer)

The Coil connection from your browser to a coil ILP connector is not based on XRP payment channel, but on the credit you have at the connector - as you are a known client from Coil (with 5$ monthly subscription).

The next ILP hops in a coil payment are from Coil to Strata and from Strata to xrptipbot, his 'moneyd' node. Both hops based on XRP payment channels

Then a final ILP delivery (not XRP payment channel) is made to your account at xrptipbot-ledger. (you receive an IOU, not XRP .. you can withdraw to XRPledger if you want)

I am imagining the process of accepting/validating one or more XRP payment channel packages to be called the 'clearing/netting' of that particular payment and when you want to make it definitive in the payment-channel or on-ledger, you 'settle'. The clearing/settlement for the payment from coil-browser to coil-ILP-connector is very different. As is the clearing/settlement from xrptipbot moneyd to your xrptipbot-ledger-account. 

Maybe interesting to read more on XRP payment channel setup and so called 'mini-accounts' here: https://github.com/interledgerjs/ilp-plugin-xrp-asym-server

3 hours ago, KarmaCoverage said:

WebSockets

The connection between ILP client and ILP connector. The client communicates the intended ILP package (the 'prepare') to connector and waits for the 'fullfill' answer. If received, then the payment is processed (clearing/settlement) and at his turn the client sends the 'fullfill' back to its own client (if any), etc. This repeated for many micro-payment packages. In a websocket connection, the connection is kept alive for processing multiple messages

The point being made is that keeping every connection alive (stateful) for its duration in a bi-directional websocket is apparently a more heavy load than compared to an architecture using stateless http sessions: stateless sessions can be scaled horizontally with existing (cloud) techniques. The ILP communication without the 'non ILP'-clearing/settlement can be done stateless; clearing and settlement (everything that is not ILP) can be done separate and maybe at more convenient intervals. Passing the clearing/settlement to a separate engine, the managing of account balances to a database system, the whole process would become more lean and scalable.

[KarmaCoverage]

@jn_r thank you!

I'm going to have to read that a few times, but I think I followed, and it is sort of what I thought I was understanding.