Looking Resilience and Packet Loss
We have two points in a payment where we may encounter “packet loss”:
- An intermediary connector is unable to deliver a fulfilment resulting in the sender and receiver having a different view of the total sent/received. (Possibly resolved in part by receipts?)
- The STREAM sender/receiver dies and has not recorded/reported the current total amount sent/received
We have, up to now, assumed that transport layer protocols help to solve for case 1 (at least from the perspective of the sender and receiver). It would be good to validate that assumption and consider the real financial impact of this case if an intermediary is processing a high volume of txs.
Case 2 speaks to the design of the interface applications have into the STREAM layer and what granularity is available to them in real-time of the total packets fulfilled. This impacts the accounting of both the sender and receiver.
However, we should give some thought to how an application resumes a payment if the STREAM connection is lost. Is this something to define in Open Payments?
A more high-level question to consider is: should ILP packets be thought of as payments?
On the one hand we have pursued the idea that packets should be so small that some packet loss is acceptable and that its not worth trying to account for every one. However, experience is telling us that few implementers are okay with that way of thinking and want to reconcile every packet to their settlement layer.