Thanks for the question @Lorimer. Latency-based routing via API boundary nodes (BNs) hasn’t been disabled by default. In fact, this feature (API BNs dynamic discovery and routing) hasn’t yet been introduced into the agent-rs. It currently only exists in the IC repo. We are working on the PR to add this feature to the agent too. Afterwards, we indeed plan to modify the default construction of the agent and set latency-based routing as the default. Routing via a predefined (static) set of API BNs would of course remain possible via e.g. RoundRobin routing.
Could you explain the scenarios where this would be undesirable
Frankly, I envision very few scenarios where latency-based routing could be undesirable for the user. Potentially for improving load balancing (e.g. if the closest nodes are heavily loaded) or if the user has some geo constraints.
If there’s a need to display changes that cancel themselves out, what would you think about presenting those changes like this (crossed out, with the reversion commit underneath) →
Thanks for the extra info @nikolay.komarevskiy, it’s much appreciated. It sounds like I may have misunderstood what this commit is doing. It’s specifying a --disable-latency-routing flag on boundary node service start up.
Frankly, I envision very few scenarios where latency-based routing could be undesirable for the user
Me too. This is why I was confused to see a flag that appears to disable latency based routing. I’m afraid this commit is still lost on me. Would you be able to clarify the behavioural change (if any) that will result from this commit?
Now I understood the source of Your confusion. The flag --disable-latency-routing refers to a different (recently added) routing strategy performed by the boundary node itself. Namely, how a boundary node selects a replica node for routing an update call to it. Currently, the boundary node randomly selects a replica node from all the subnet nodes. Recently, we introduced an alternative routing strategy, where a replica node is selected randomly, but out of f + 1 closest nodes (f - fault tolerance factor). This naturally reduces the average latency for update calls, while still maintaining some load balancing between replica nodes. This feature will be enabled in the future.
Reviewers for the CodeGov project have completed reviews of these two replica updates and voted to adopt.
Proposal ID: 131054
Vote: ADOPT
Full report on OpenChat
Proposal ID: 131055
Vote: ADOPT
Full report on OpenChat
At the time of this comment on the forum there are still 2 days left in the voting period, which means there is still plenty of time for others to review the proposals and vote independently.
We had several very good reviews of the Release Notes on these proposals by @Zane, @cyberowl, @ZackDS, @massimoalbarello, @ilbert, @hpeebles and @Lorimer. The IC-OS Verification was also performed by @tiago89. I recommend folks take a look and see the excellent work that was performed on these reviews by the entire CodeGov team. Feel free to comment here or in the thread of each respective proposal in our community on OpenChat if you have any questions or suggestions about these reviews.
Below is the text and a link to a post from one of our reviewers @Lorimer for proposal 131055. This post is significant because it describes why he voted to reject this proposal even though the CodeGov neuron overall voted to Adopt. I think he has a good point and it is appropriate to have a high standard regarding the accuracy of the proposal the Summary for IC-OS Version Election proposals since these are the proposals where major changes to the IC replica start.
"Build successful and hashes generated on my machine match (CDN and local build), and the GuestOS hash matches the proposal payload.
Voted to reject, due to what I consider to be an inaccurate proposal summary (happy to be alone on this). Issue raised on the forum.
This sort of thing seems to be a recurring problem, and while I don’t believe this specific proposal in isolation represents a danger to the IC, I think collectively these sorts of proposals undermine the integrity of IC proposal history. I think the clarity and validity of a proposal summary is very important (if a proposal summary can be validated by a number of reviewers, then other more casual reviewers can have confidence in what the proposal summary claims and do not necessarily need to dig beneath the surface). Ultimately, I think accurate proposal summaries is something we should be requiring rather than preferring."
Also relevant and related to the same issue is a description of how this affected another of our reviewers @ZackDS.
"The usual “has the new storage layer disabled” applies but no idea why they listed commit 0d2b3965c in the summary. This reverts another commit 5388a13 that should have been listed as well if it was this important to keep track. Checked step by step that the reverted change actually matches exactly the changes done before for the switch, not sure what was the issue given the short period of time between them, probably some issues in testing. The other reverts have shared info on the issues leading to them.
The main commented parts As “to be enabled when we switch to compiler_sandbox” are the create_execution_state_with_compiler_sandbox function that executes canister code in a sandboxed environment. It prepares the execution state, retrieves a sandbox process for isolation, and converts the canister module (source code) into a Wasm binary for execution.
And open_wasm function that implements a caching strategy to optimize Wasm binary opening and compilation within a sandboxed execution environment. It leverages both an embedder cache and a compilation cache to avoid redundant work. The function also tracks various metrics to monitor performance and potential error scenarios."
One day before the NNS proposal was submitted, a forum thread was created by a DFINITY Foundation employee regarding the revising Elected GuestOS versions. The proposal itself was also created by a trusted neuron (for me), so I approved proposal 131054 manually. Not every NNS participant has the time to review EVERY proposal by hand if they aren’t paid directly for it. Information on how I currently votes is presented in this proposal. @dfxjesse probably read it, maybe decided he agreed with my flexible approach and that’s why he following me.
As you say @Lorimer it can be concluded that for network security I could track your neuron. However I chose someone else. That is what decentralization is all about, we have free choice of who we follow and how we vote. If you want me to report to you and check every proposal independently you have to pay me for it.
Hey @krzysztofzelazko, thanks for being honest and confirming that you didn’t verify the build. Thanks for also confirming that you’re happy with how you voted and that you may do this sort of thing again at some point.
It’s all useful info that I think deserves a bigger and deeper community discussion at some point
I didn’t verify this recently executed proposal, because someone else did it on my behalf. It’s good to do everything yourself, but sometimes when we have an experienced person, it’s just worth trusting them. Overall option of following other neurons is based on trusting the other participant. I have never publicly declared that I personally check the image of each new version of the IC replica. You are a member of CodeGov.org, so you receive financial support for your work. Your neuron is public, so I checked it and in some areas it also follows the experts from DFINITY. The only thing that can be discussed here is who is indirectly funded by the DFINITY Foundation and votes indirectly on its “decentralized” behalf and who is not.
I independently verify the proposals of Governance, SNS & Neurons’ Fund, and several other technical ones related to network administration and I am not sponsored by anyone.
Are you referring to the proposer of the proposal? That’s not what build verification is about.
Also, there is a big difference between following a neuron, and going out of your way to manually accept a proposal (blindly) before the community has had a chance to perform due diligence and voice concerns.
For now, it looks like a small pilot program run by the Foundation, which I’ll probably sign up for, but with the help of a local ICP Hub manager, so I won’t be doing it alone. I hope that the final solution will be fully decentralized and that we’ll both be funded by our community, rather than DFINITY or reviewing proposals for community only for charity.
I admit that I like reviewing network administration categories myself (like proposals of add/remove new DC/NP/NO, setting node rewards, subnet management, Governance, and SNS & Neurons’ Fund etc.), but having to review multiple commits in-depth, verifying the build, checking code quality without compensation makes me prefer listening to someone else than doing it myself.
Do you mind sharing who reviewed the proposal? I’m interested in knowing who’s who among people who verify proposals. Do they share their identity, proposal topics, and review strategy publicly? It’s ok if you don’t want to share or they are not willing to share. I’m just curious for now, but may some day want to know another good neuron to follow on certain topics. I’m always happy to support people who actively review and vote on technical topics.
Nobody did that’s the whole point @lorimer was making. It wasn’t available for anyone outside Dfinity the time he cast the vote. Also he couldn’t run a git diff with documentation in front of him so just leave him alone. He is a DJ and it’s fine, even if votes by flipping a coin it doesn’t matter. Be blessed.
Bro, I simply trusted a DFINITY employee on this matter. I never declared that I would check IC OS proposals on my own (when I registered the neuron it wasn’t even that separated by topics and quite difficult). I monitor other proposal topics on my own. The proposal for a new IC replica version itself contained information about the changes and generally looked legit. I don’t think that’s a bad thing, as most of the community currently follows their voting. Everyone here trusts someone if they follow other neurons.
Just like your neuron CodeGov.org in a few others, which I actively monitor.
But the proposal was at the very start of review process. DFINITY hadn’t even voted on it yet. There are plenty of examples where they reject their own proposals. I’m not sure what you mean.
