Thanks for this proposal @Sat, and great question @timk11 regarding the status of that node flip-flopping. I’d been intending on setting up an app that frequently polls node state in order to provide an easy way of visualising node status history. I wasn’t actually aware that we already have this sort of report (and more) with the Node Provider Rewards dashboard that Sat has highlight. This is great! 
I’d be interested to learn more about who maintains this dashboard (I see it’s controlled by principal - 32kwa-eibir-hat2o-kyhfc-u5msq-xr4w4-newoz-qpzxj-ohovv-u7zgt-qqe). @Sat can I ask who this controller is, or what team this principal represents?
The circumstances around this proposal are actually super interesting 
Here are the block rate metrics for a randomly selected node in this subnet (as an exemplar point of reference) - jj7si
Note the 100% success rate, and that the block rate significantly increased at the start of September, as a direct result of this prior proposal (reducing notarization delay) → Subnet Management - 6pbhf (Application) - Governance / NNS proposal discussions - Internet Computer Developer Forum (dfinity.org)
Here are the block rate metrics for the node that keeps falling into a degraded state →
We can see that it was already failing to keep up 100% with the existing block rate (prior to September). Interestingly the performance of this node in absolute terms has actually improved since the start of September (on average). However, in relative terms (relative to the increased total number of block), this node’s performance now borders on being considered degraded.
It might be worth looking out for nodes like this when decreasing the notarization delay on critical system subnets (which I suspect will happen soon).
@Sat, out of interest, can I ask what the exact criteria are for when a node status is considered to switch from UP to DEGRADED? Presumably the proportion of failed blocks needs to cross some limit?
Now that the preamble is out of the way, the ‘degraded’ node in Korea is being replaced with an ‘up’ node in Israel 
I’ve voted to adopt
There’s a slight reduction in the average distance between nodes if this proposal passes, but that seems fine (particularly given that it’s not a metric directly considered by the IC target topology). All other decentralisation metrics appear unaltered by this proposal.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
|
Smallest Distance |
Average Distance |
Largest Distance |
| EXISTING |
117.012 km |
6915.788 km |
17244.636 km |
| PROPOSED |
117.012 km |
6591.406 km (-4.7%) |
17244.636 km |
This proposal slightly reduces decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical reduction in localised disaster resilience). 
Subnet characteristic counts →
|
Continents |
Countries |
Data Centers |
Owners |
Node Providers |
| EXISTING |
4 |
13 |
13 |
13 |
13 |
| PROPOSED |
4 |
13 |
13 |
13 |
13 |
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
|
Continent |
Country |
Data Center |
Owner |
Node Provider |
| EXISTING |
7 |
1 |
1 |
1 |
1 |
| PROPOSED |
7 |
1 |
1 |
1 |
1 |
See here for acceptable limits → Motion 132136
The above subnet information is illustrated below, followed by a node reference table:
Map Description
- Red marker represents a removed node (transparent center for overlap visibility)
- Green marker represents an added node
- Blue marker represents an unchanged node
- Highlighted patches represent the country the above nodes sit within (red if the country is removed, green if added, otherwise grey)
- Light grey markers with yellow borders are examples of unassigned nodes that would be viable candidates for joining the subnet according to formal decentralisation coefficients (so this proposal can be viewed in the context of alternative solutions that are not being used)
Table
Known Neurons to follow if you're too busy to keep on top of things like this
If you found this analysis helpful and would like to follow the vote of the LORIMER known neuron in the future, consider configuring LORIMER as a followee for the Subnet Management topic.
Other good neurons to follow:
-
Synapse (follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)
-
CodeGov (actively reviews and votes on Subnet Management proposals, and is well informed on numerous other technical topics)
-
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
