Subnet Management - 5kdm2 (Application)

This topic is intended to capture Subnet Management activities over time for the 5kdm2 subnet, providing a place to ask questions and make observations about the management of this subnet.

At the time of creating this topic the current subnet configuration is as follows:

Expand
{
  "version": 44291,
  "records": [
    {
      "key": "subnet_record_5kdm2-62fc6-fwnja-hutkz-ycsnm-4z33i-woh43-4cenu-ev7mi-gii6t-4ae",
      "version": 44291,
      "value": {
        "membership": [
          "ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae",
          "zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae",
          "vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae",
          "srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe",
          "bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe",
          "zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe",
          "oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe",
          "ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe",
          "jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae",
          "wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe",
          "tyofn-r6bgb-5a533-2vptk-hgl47-xz3se-ssxyd-ws4i4-o7c4x-5zczx-gqe",
          "tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae",
          "bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe"
        ],
        "nodes": {},
        "max_ingress_bytes_per_message": 2097152,
        "max_ingress_messages_per_block": 1000,
        "max_block_payload_size": 4194304,
        "unit_delay_millis": 1000,
        "initial_notary_delay_millis": 600,
        "replica_version_id": "a3831c87440df4821b435050c8a8fcb3745d86f6",
        "dkg_interval_length": 499,
        "start_as_nns": false,
        "subnet_type": "verified_application",
        "features": {
          "canister_sandboxing": false,
          "http_requests": true,
          "sev_enabled": false
        },
        "max_number_of_canisters": 120000,
        "ssh_readonly_access": [],
        "ssh_backup_access": [],
        "ecdsa_config": null,
        "chain_key_config": null
      }
    }
  ]
}
2 Likes

Thereā€™s an open proposal for changing subnet membership - Proposal: 131403 - ICP Dashboard (internetcomputer.org). This information is presented below:

  • red marker represents a removed node
  • green marker represents an added node
  • highlighted patches represent the country a node sits within

Table
Country Data Center Owner Node Provider Node
--- Germany Munich (mu1) q.beyond Staking Facilities tyofn-r6bgb-5a533-2vptk-hgl47-xz3se-ssxyd-ws4i4-o7c4x-5zczx-gqe
+++ Korea (the Republic of) Seoul 2 (kr2) Gasan Web3game pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe
Canada Fremont (fm1) Hurricane Electric 1G bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe
Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae
Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae
India Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae
India Panvel 2 (pl2) Yotta Krishna Enterprises srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe
Israel Tel Aviv 1 (tv1) Interhost GeoNodes LLC vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae
Japan Tokyo 3 (ty3) Equinix Starbase oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe
Romania Bucharest (bu1) M247 Iancu Aurel bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe
Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe
Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe
United States of America (the) Dallas (dl1) Flexential 87m Neuron, LLC ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe
South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae

The removed node is replaced with a node based in South Korea. This looks positive for decentralisation. Iā€™ve verified that this node is currently unassigned.

The proposal mentions that his change is needed due to the Munich (mu1) data centre being due for decommissioning. I have some questions about this which Iā€™ve asked on another topic.

2 Likes

Thereā€™s an open proposal for removing a node from this subnet (along with 2 other subnets - uzr34 (II) and tdb26 (NNS))

I intend to take a closer look later today after work. But for now hereā€™s some contextual info for interested voters.

Map Description
  • Red marker represents a removed node (transparent center for overlap visibility)
  • Blue marker represents an unchanged node
  • Highlighted patches represent the country the above nodes sit within
  • 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 - plenty of nodes that the removed node could have been swapped with if this were a ā€˜Change Subnet Membershipā€™ proposal)

Table
Continent Country Data Center Owner Node Provider Node Status
--- Asia India Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae DOWN
Europe Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae UP
Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae UP
Asia India Panvel 2 (pl2) Yotta Krishna Enterprises srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe UP
Asia Israel Tel Aviv 1 (tv1) Interhost GeoNodes LLC vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae UP
Asia Japan Tokyo 3 (ty3) Equinix Starbase oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe UP
Asia Korea (the Republic of) Seoul 2 (kr2) Gasan Web3game pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe UP
Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe UP
Americas United States of America (the) Dallas (dl1) Flexential 87m Neuron, LLC ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe UP
Americas United States of America (the) Fremont (fm1) Hurricane Electric 1G bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe UP
Africa South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae UP

Iā€™ve rejected this proposal for numerous reasons. TLDR: It doesnā€™t actually fix anything, and is unjustified in violating the target IC topology, even if itā€™s temporary (thereā€™s insufficient information provided in the summary to explain why theyā€™ve proposed this removal in this way):

Expand for more details
  • This proposal doesnā€™t fix the problem of an offline node. Instead itā€™s removing it from the subnet for some unexplained / unjustified reason (unjustified because itā€™s not transactionally replacing the node with a good one)
  • ā€˜Remove node from subnetā€™ proposals are for shrinking subnets (this isnā€™t and shouldnā€™t be the intention here). ā€˜Change Subnet Membershipā€™ proposals are for fixing bad nodes in a subnet (by transactionally swapping them out for good nodes) - which is the proposal type that should have been proposed, and that this proposal should (in my opinion) be superseded by (after rejecting).
  • This proposal has a very poor summary (historically these types of proposals have provided much more information in the summary, such as the affected subnets, and the precise set of steps are are planned to follow the proposal). Ever since the ā€˜Change Subnet Membershipā€™ proposal type was implemented, ā€˜Remove node from subnetā€™ proposals have become more or less a thing of the past (at least in this sort of scenario).
    • The proposal does not clearly state what the next steps would be (which IPv6 and IPv4 enabled nodes would be deployed as a next step?)
    • Why isnā€™t this being done transactionally under one proposal per subnet (why is it justifiable to ask the community to vote the subnet into a state that violates the formal target topology?)
  • Accepting this proposal would leave the 3 affected subnets in a state that is in violation of the formally voted in target IC topology (and in even further violation of the topology that is likely to soon be proposed - 34 nodes instead of 28 on the II subnet)
  • Thereā€™s only one other Subnet Management proposal proposed by this neuron historically, and it was also worthy of rejection in my opinion (currently that proposal is still open).

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:

  • CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)
  • WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)

See below thread for further discussion regarding the above:

Thereā€™s currently a new open ā€˜Change Subnet Membershipā€™ proposal for this subnet.


Proposal 132143

TLDR: Iā€™ve rejected this proposal as it does not solve the offline node issue, and the payload parameters appear to contains errors.

  • Note that node vwsvq is included in both the nodes removed and nodes added parameters of the payload. Swapping nodes is supposed to be a transactional operation (I wouldnā€™t be surprised if this would fail to execute).
  • The other node swap in this proposal is taking the opportunity to improve subnet decentralisation (given thereā€™s already a need for a proposal). 1 of the two nodes in the USA is proposed to be replaced with one node in Singapore. This increases the country coefficient (ā€¦ but it was already within the acceptable range, and other subnets are in much more need of decentralisation).

My suggestion would be to reject this proposal and resubmit one that solves the offline node problem, and raise other proposals to address the subnets that are currently violating the target IC topology before looking to improve the topology of subnets that are not formally in need of it (unless itā€™s a strategic move to help free up nodes that are needed by other subnets - but this should be clearly explained).

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) ā†’

Smallest Distance Average Distance Largest Distance
EXISTING 3.534 km 7115.008 km 16955.201 km
PROPOSED 3.534 km 6874.501 km (-3.4%) 16955.201 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). :-1:

Subnet characteristic counts ā†’

Continents Countries Data Centers Owners Node Providers
EXISTING 4 10 13 13 13
PROPOSED 4 11 (+9.1%) 13 13 13

This proposal slightly improves decentralisation in terms of jurisdiction diversity. :+1:

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) ā†’

Continent Country Data Center Owner Node Provider
EXISTING 5 2 1 1 1
PROPOSED 6 (+20%) 2 1 1 1

See here for acceptable limits ā†’ Motion 125549 (note that these are due for a slight revision)

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
Continent Country Data Center Owner Node Provider Node Status
--- Asia Israel Tel Aviv 1 (tv1) Interhost GeoNodes LLC vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae DOWN
--- Americas United States of America (the) Dallas (dl1) Flexential 87m Neuron, LLC ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe UP
+++ Asia Israel Tel Aviv 1 (tv1) Interhost GeoNodes LLC vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae DOWN
+++ Asia Singapore Singapore 3 (sg3) Racks Central OneSixtyTwo Digital Capital t6ads-xnmvp-nwrkg-vytby-wrqj7-5ddqe-h5a7h-jjmpa-snv7j-3pqqz-iae UNASSIGNED
Europe Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae UP
Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae UP
Asia India Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae UP
Asia India Panvel 2 (pl2) Yotta Krishna Enterprises srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe UP
Asia Japan Tokyo 3 (ty3) Equinix Starbase oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe UP
Asia Korea (the Republic of) Seoul 2 (kr2) Gasan Web3game pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe UP
Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe UP
Americas United States of America (the) Fremont (fm1) Hurricane Electric 1G bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe UP
Africa South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae UP

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:

  • CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)

  • WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)

Proposal 132180

TLDR: Iā€™ve adopted this proposal. Two dead nodes replaced with two up nodes :+1:This also has the side-effect of a slight increase in decentralisation in terms of average geographic distance between nodes and country diversity :cherries:

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) ā†’

Smallest Distance Average Distance Largest Distance
EXISTING 3.534 km 7115.008 km 16955.201 km
PROPOSED 3.534 km 7231.464 km (+1.6%) 16955.201 km

This proposal slightly increases decentralisation, considered purely in terms of geographic distance (and therefore thereā€™s a slight theoretical increase in localised disaster resilience). :+1:

Subnet characteristic counts ā†’

Continents Countries Data Centers Owners Node Providers
EXISTING 4 10 13 13 13
PROPOSED 4 11 (+9.1%) 13 13 13

This proposal slightly improves decentralisation in terms of jurisdiction diversity. :+1:

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) ā†’

Continent Country Data Center Owner Node Provider
EXISTING 5 2 1 1 1
PROPOSED 6 (+20%) 2 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
Continent Country Data Center Owner Node Provider Node Status
--- Asia India Colombo 1 (cm1) OrionStellar Geodd Pvt Ltd zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae DOWN
--- Asia Israel Tel Aviv 1 (tv1) Interhost GeoNodes LLC vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae DOWN
+++ Asia China HongKong 1 (hk1) Unicom Wancloud limited fpjx3-tfebc-csio2-hxi4u-7jomj-p4c4q-b66xe-ngut6-yi63x-keuhl-6ae UNASSIGNED
+++ Europe Spain Barcelona 1 (es1) Adam Carbon Twelve uao44-6xaz7-xmjyv-wxzqn-fawuf-hpz34-d7ea4-2ft3d-znzye-k246e-cqe UNASSIGNED
Europe Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae UP
Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae UP
Asia India Panvel 2 (pl2) Yotta Krishna Enterprises srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe UP
Asia Japan Tokyo 3 (ty3) Equinix Starbase oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe UP
Asia Korea (the Republic of) Seoul 2 (kr2) Gasan Web3game pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe UP
Europe Romania Bucharest (bu1) M247 Iancu Aurel bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe UP
Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe UP
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe UP
Americas United States of America (the) Dallas (dl1) Flexential 87m Neuron, LLC ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe UP
Americas United States of America (the) Fremont (fm1) Hurricane Electric 1G bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe UP
Africa South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae UP

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:

  • CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)

  • WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)

1 Like

DFINITY will submit an NNS proposal today to reduce the notarization delay on the subnet, 5kdm2, similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread).

2 Likes

Voted to adopt proposal 133072. The initial_notary_delay_millis is set to 300 and the subnet_id is correct.

1 Like

Voted to adopt proposal 134038, as the reasoning is sound and the proposal description matches the payload.

This proposal is intended to replace a dead node, pzv3b, which node appears as ā€œStatus: Offlineā€ on the dashboard. As seen in the proposal (which I verified using the DRE tool), the proposed change leaves the target topology within the requirements and improves decentralisation with respect to country.

3 Likes

Proposal 134038

TLDR: Iā€™ve adopted this proposal. An offline node in South Korea and a US node thatā€™s currently up replaced with unassigned nodes in Singapore and Belgium. Note that although the US node is currently up, the proposal replaces it to improve decentralisation metrics.


Initially it appeared to me that the country coefficient is not improved as suggested by the proposal. The map and stats below are based on IP address geolocation that I now release is inconsistent with what the IC has on record for this node. The node appeared to me to be in Canada, but on further investigation just now I see that the true location is more likely to be the US.

Assuming the node is located in the US (and not Canada), then I agree that decentralisation is improved by this proposal in terms of country limits. Iā€™ll look into improving my tooling when I get a chance.

@sat, @SvenF, are you aware of any plans to implement a means of IC protocol + device level geolocation, to help verify the current location of a node (rather than trusting a third party service)?

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) ā†’

Smallest Distance Average Distance Largest Distance
EXISTING 0 km 7116.246 km 14698.952 km
PROPOSED 0 km 6519.78 km (-8.4%) 15062.77 km (+2.5%)

This proposal slightly reduces decentralisation, considered purely in terms of geographic distance (and therefore thereā€™s a slight theoretical reduction in localised disaster resilience). :-1:

Subnet characteristic counts ā†’

Continents Countries Data Centers Owners Node Providers Node Operator
EXISTING 4 12 13 13 13 13
PROPOSED 4 12 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 Node Operator
EXISTING 6 2 1 1 1 1
PROPOSED 7 (+16.67%) 2 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
Continent Country Data Center Owner Node Provider Node Operator Node Status Performance
--- Asia Korea (the Republic of) Seoul 2 (kr2) Gasan Web3game 5dwhe pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe DOWN :bar_chart:
--- Americas United States of America (the) Dallas (dl1) Flexential 87m Neuron, LLC sambh ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe UP :bar_chart:
+++ Europe Belgium Seoul 3 (kr1) KT Pindar Technology Limited iubpe ttjeo-6vece-x2hpb-lzmdg-b2fwl-7osa4-r5vb6-n4dyc-ocg5r-rztx2-eqe UNASSIGNED :bar_chart:
+++ Asia Singapore Singapore (sg1) Telin OneSixtyTwo Digital Capital d4bin ihoip-fmbnl-mm4fa-pu7hu-2sbx2-mzl2f-tgzje-unnjg-bgcac-3apmo-gqe UNASSIGNED :bar_chart:
Americas Canada Fremont (fm1) Hurricane Electric 1G mlh5i bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe UP :bar_chart:
Europe Switzerland Geneva (ge1) HighDC Archery Blockchain SCSp yngfj tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae UP :bar_chart:
Europe Switzerland Zurich 4 (zh4) Nine.Ch Tomahawk.vc paxme jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae UP :bar_chart:
Asia China HongKong 1 (hk1) Unicom Wancloud limited z6cfb fpjx3-tfebc-csio2-hxi4u-7jomj-p4c4q-b66xe-ngut6-yi63x-keuhl-6ae UP :bar_chart:
Europe Spain Barcelona 1 (es1) Adam Carbon Twelve gyzti uao44-6xaz7-xmjyv-wxzqn-fawuf-hpz34-d7ea4-2ft3d-znzye-k246e-cqe UP :bar_chart:
Asia India Panvel 2 (pl2) Yotta Krishna Enterprises 7rw6b srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe UP :bar_chart:
Asia Japan Tokyo 3 (ty3) Equinix Starbase a5glg oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe UP :bar_chart:
Europe Romania Bucharest (bu1) M247 Iancu Aurel c5ssg bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe UP :bar_chart:
Europe Slovenia Ljubljana (lj1) Posita.si Fractal Labs AG gl27f wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe UP :bar_chart:
Europe Sweden Stockholm 1 (sh1) Digital Realty DFINITY Operations SA lgp6d zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe UP :bar_chart:
Africa South Africa Gauteng 2 (jb2) Africa Data Centres Honeycomb Capital (Pty) Ltd 3bohy ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae UP :bar_chart:

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.

Another good neuron to follow is 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)

2 Likes

Sounds like you already have some specific approach in mind @Lorimer ?
There is an ongoing activity to start showing geoip info, but we first have to make sure geoip info is actually reliable.

1 Like

Hey @Lorimer I also see different geo locations using different ip lookup tools, will ask the networking people have a look at it. The node is indeed in the US, and like @sat indicates, there is an ongoing activity for a geo-lookup using triangulation.

1 Like

No concrete idea - I canā€™t think of something that couldnā€™t be spoofed. But Iā€™ve not spent any great deal of time considering this.

Perhaps it would be more practical to mandate that nodes use ISPs that allow for better public IP address precision and accuracy?

Sounds good, thanks. Iā€™d be interested to follow progress on that idea. Is there a public thread anywhere yet to follow it?

1 Like

Voted to adopt proposal 134038. The proposal replaces two nodes from subnet 5kdm2:
Removed Nodes:

  • pzv3b, Dashboard Status Offline
  • ugqji, Dashboard Status Online, replacement improves decentralization on the Country metric (reduces number of nodes in the US from 2 to 1)

Added Nodes: ihoip and ttjeo.
The proposal was verified using the DRE tool to verify the metrics stated and that they were in line with the target topology requirements.

1 Like

Voted to adopt proposal #134038.

The proposal is correct in that it replaces offline dead node from Seoul2 pzv3b , and healthy Dallas node ugqji to improve decentralization.
The added nodes are from Singapore ihoip along with ttjeo from Seoul3.

1 Like

Hi @Lorimer not yet, this topic was actually discussed in the Technical Working Group for Node Providers and is being started up. Will make sure that a thread is added shortly on this.

1 Like

Hi @Lorimer the networking team has taken a look into it, and from what they can see, the IPs are part of the 2001:470::/32 AS6939, which is registered in ARIN in US.

On the other hand, ip2location.io appears to have Canada in its database which might be an old registration. Maybe before the prefix 2001:470:1::/48 was actually in Canada. We dropped a note to the provider. IPv6 data coverage is typically less mature than IPv4 data so geolocation providers may lack complete accuracy here. All the more reason to work on triangulation as discussed above!

2 Likes

Thanks a lot for following up on this @SvenF, and for the extra info. Iā€™m looking forward to hearing more about the planned path forward. Sounds promising

1 Like