Suggested measures to reduce latency and improve ICP scalability

[levi]

@free

With your approach, if we have canister 1 on subnet A and canister 2 on subnet B, with canister A calling canister B once as part of handling an update call, latency jumps to at least 6 seconds (and likely more).

@free

So the increase in latency is about 5 seconds, not 1.5.

According to a conversation in another thread the increase in latency is 1.8 seconds since the recent lowering of the notarization delays:

@levi

@oggy

@levi

Another factor here is that the end-to-end ingress message end-user latency difference between calling a canister that calls another canister on the same subnet and calling a canister that calls another canister on a different subnet is much less of a difference (maybe around 3x max?).

IIRC, with the sync call endpoint, an ingress call takes around 1.2 seconds to get a response, and the median cross-subnet call is around 6 seconds (though this is largely due to the NNS having a slower finalization rate - otherwise it is indeed probably around 3 seconds).

Great, less than 2.5x. Looks like the recent reduction of notarization delays is working. And this is 2.5x in the context of the difference between 1.2 seconds and 3 seconds. The plan in the original post does not affect calls to the NNS subnet since they are already cross-subnet calls.

(I was surprised too.)

@free

While you may be happy with somewhat better DDoS protection at the cost of a 3x latency increase (from an already borderline base), most canister developers won’t be.

I just want to clarify for our readers the following cases where the latency will stay the same (will not change): Canister methods that don’t make any inter-canister calls, and canister methods that already make inter-canister calls to canisters on different subnets. Both of these will not change. The one specific case that will increase latency is canister-methods that are currently making inter-canister calls to other canisters on the same subnet, the latency of this case will increase by 1.8 seconds.

If most canister developers don’t want that, then that’s ok, as long as the different factors are being considered one way or the other.

@free

Leaving aside the 1.5 seconds (which is actually 5 seconds), randomly shuffling around canisters would not guarantee “no chance of a DDOS”. No single silver bullet would.

For random canister shuffling I was using it as a sample of a possible thing that the protocol can do. The main point is that the protocol (and not canister-developers) being in charge of where canisters live and how the canisters get spread out across subnets, is what puts the protocol in the best position that I know of, to be able to spread any kind of load (ddos or well-intended) throughout the subnets.

If there are other things we will be able to do later on to round-out the load balancing while still letting canister-developers choose their specific subnets, that could be the best option for sure.

I think it is great that compute-allocation exists now to be able to at least have an option. It’s something like $130 per month per canister for a compute allocation of 4. Works for a few canisters.

@free

Canisters on the same subnet can transfer more than 1GB between them every round.

Collectively yea good point, but on the public-subnets it’s not so easy for a single dapp to take advantage of that.

---

My purpose here is sharing my thoughts on a plan for scalability which contains the mechanics to handle any kind of scalability load (ddos or well-intended), and making it simpler for canister-controllers to scale their dapps.