DRI: @Mikel Cortes (discord handle: @Cortze#0649)

✅ Project Completed

Read the final report:

network-measurements/rfm17-provider-record-liveness.md at master · protocol/network-measurements

Background Context

< GH issues, or Slack threads, or Discord conversations, etc. >

network-measurements/RFMs.md at master · protocol/network-measurements

Project Doc and Progress Updates

➡️  ➡️ Work on this project has been carried out here: Provider Record Liveness


Provider records are replicated in the system to k=20 peers and are re-provided after 12hrs in the hope that, despite network churn, at least one of them will be alive to provide the record throughout the 12hr interval. However, we have not tested whether provider records indeed stay alive for 12hrs. In addition, we have found that the network has very high churn rate (at times in the order of 50% per hour).

Back of the envelope calculation suggests that with this rate of churn all 20 peers are likely to have gone offline after only 6hrs. In turn, this suggests that records might be unreachable for ~6hrs, which should be considered unacceptable. Of course, peers do not only leave, but also come back — our results suggest that the interarrival time is of similar levels as the churn rate — so it is likely that records become available again.

Despite the above argumentation, the network seems to work fine (although there have been reports of content being unreachable), so there are three things that might be happening:

<aside> 🔥 Impact: It is unacceptable to have unreachable content in the system just a few hours after it is published. If our hypothesis is correct, then we need to revisit these parameters and get them right, as they affect much of the performance of the system.