edits for stable providers methodology

yiannisbot · web-flow · commit c2da192a7a4c · 2023-06-22T15:35:13.000+03:00
diff --git a/content.en/websites/gen.template b/content.en/websites/gen.template
@@ -45,11 +45,13 @@ It is important to note that the resulting metrics are artificial composites and
 
 {{< plotly json="../../plots/latest/website-trend-providers-|| .Website ||.json" height="350px" >}}
 
-One of the primary reasons why a website (CID) might not be available over Kubo is that there are no providers for the content. This graph showcases the unique providing peers as identified by distinct [PeerIDs](https://docs.libp2p.io/concepts/fundamentals/peers/#peer-id) discovered throughout a specific day in the IPFS DHT. We look up the IPNS record for the website which gives us the current CID of the website's content. Then, we look up all provider records in the IPFS DHT and record the distinct PeerIDs of the providing peers. Finally, we try to connect to all the discovered peers, and based on the outcome, classify them as:
+One of the primary reasons why a website (CID) might not be available over Kubo is that there are no providers for the content. This graph shows the unique providing peers as identified by distinct [PeerIDs](https://docs.libp2p.io/concepts/fundamentals/peers/#peer-id) discovered throughout a specific day in the IPFS DHT.
+
+We look up the IPNS record for the website every six hours (four times a day) from seven geographically different vantage points, which gives us the current CID of the website's content. Then, we look up all provider records in the IPFS DHT and record the distinct PeerIDs of the providing peers. Finally, we try to connect to all the discovered peers, and based on the outcome, classify them as:
 
 - `Unreachable`: The peer remained unreachable during the entire day. We weren't able to connect to it a single time, which might happen if providers advertise a [provider record](https://docs.ipfs.tech/concepts/dht/#distributed-hash-tables-dhts) and then leave the network (go offline), leaving a stale record behind.
 - `Reachable Relayed`: The providing peer solely advertised [relay multiaddresses](https://docs.libp2p.io/concepts/nat/circuit-relay/), meaning we could only establish a connection to it through a proxying peer. Proxying peers act as intermediaries, facilitating the connection between our monitoring system and the providing peer. It is important to note that this scenario has performance implications, as relaying introduces additional latency and potential bottlenecks _at the connection setup level_. Once the connection is set up, the actual data transfer takes place directly between the two peers, so there is no performance implication during that stage. It is also worth noting that where a "Reachable Relayed" peer is counted, the original providing peer has been reached and it was not only the proxying peer that our probes reached.
-- `Reachable Non-Relayed` represents peers that were publicly reachable and usually offer the best performance.
+- `Reachable Non-Relayed`: The providing peer was found online and was publicly and directly reachable (we could establish a connection) at least once during the day. Reachable and Non-Relayed peers usually offer the best performance.
 
 In order for a website (or CID more in general) to be available and accessible in the network, there needs to be at least one “Reachable Provider”. Obviously, the more the “Reachable Providers”, the “healthier” the content will be. This is because the content is more resilient to peer churn (i.e., some of the providers leaving the network) and is also available from more locations, which likely means faster retrieval.
 
@@ -60,9 +62,11 @@ Deployments are determined by monitoring the CIDs found within the websites' IPN
 
 {{< plotly json="../../plots/latest/website-trend-hosters-|| .Website ||.json" height="250px" >}}
 
-For the above graph, we obtained the PeerIDs from two hosting providers/pinning services: [Protocol Labs' IPFS Websites Collab-Cluster](https://collab.ipfscluster.io/) and [Fleek](https://fleek.co). We monitor how many of their PeerIDs appear in the list of peers providing the website to the DHT on a daily basis. We gather the list of providing peers every six hours from seven different vantage points with two different Kubo versions (see [Tiros](/tools/tiros)), and aggregate the distinct peers we have found. Then we count the number of peerIDs that belong to either Fleek or PL's Collab-Cluster. We monitor six PeerIDs for Fleek and seven PeerIDs for PL's Collab-Cluster ([source](https://github.com/plprobelab/website/blob/main/config/plotdefs-website/website-trend-hosters.yaml#L8)). The sum of both bars should always be less than or equal to the number of `Reachable Non-Relayed` peers in the previous graph.
+For the above graph, we obtained the PeerIDs from two hosting providers/pinning services: [Protocol Labs' IPFS Websites Collab-Cluster](https://collab.ipfscluster.io/) and [Fleek](https://fleek.co). We monitor how many of their PeerIDs appear in the list of peers providing the website to the DHT on a daily basis.
+
+We gather the list of all providing peers every six hours from seven different vantage points with two different Kubo versions (see [Tiros](/tools/tiros)), and aggregate the distinct peers we have found. Then we count the number of peerIDs that belong to either Fleek or PL's Collab-Cluster. We monitor six PeerIDs for Fleek and seven PeerIDs for PL's Collab-Cluster ([source](https://github.com/plprobelab/website/blob/main/config/plotdefs-website/website-trend-hosters.yaml#L8)). The number of PeerIDs from either Fleek or PL's Collab-Cluster that were found online and reachable at least once is present in the above graph. The sum of both bars should always be less than or equal to the number of `Reachable Non-Relayed` peers in the previous graph.
 
-More importantly, if both bars (for Fleek and the PL Cluster) are at zero, then this very likely means that the website has no stable providers on the IPFS DHT.
+More importantly, if both bars (for Fleek and the PL Collab-Cluster) are at zero, which should not normally be the case, then this means that availability of the website over the IPFS DHT depends entirely on other peers providing it. In this case, it is likely that the website might end up having no stable providers on the IPFS DHT.
 
 ### IPFS Retrieval Errors {#website-trend-retrieval-errors-|| .Anchor ||-kubo}
 
@@ -165,4 +169,4 @@ TTI measures the time it takes for a web page to become fully interactive and re
 | **Needs Improvement** | The value was larger than the `good` but smaller than the `poor` threshold (see [Metrics](#metrics)) |
 | **Poor**              | The value was larger than the `poor` threshold (see [Metrics](#metrics))                             |
 | **Undefined**         | We could not gather the metric because of internal measurement errors (our fault)                    |
-| **Fatal**             | We could not gather the metric because we could not retrieve the website at all                      |
+| **Fatal**             | We could not gather the metric because we could not retrieve the website at all                      |
