This is effectively a 10x increase on subnet-to-subnet calls relative to the current pricing model. The scaling pattern for applications on the IC requires subnet-to-subnet calls.
For reference, the way Quark was designed, according to the suggested scaling patterns, this would translate to a 10x increase in overhead. The IC is an actor based system. Messaging must be cheap.
Aside: We decided not to ship Quark out of fear something like this could happen. And, a lack of critical tooling (reporting, logging).
-
What was the line of thinking with the existing pricing model? Following this change, are you sure ingress messages are priced accurately?
-
Developers need to understand better why this is presently causing issues. Or, at least how this could cause issues in the future. Are canisters maliciously saturating this memory pool today?
-
A potential unintended consequence of this I see if punishing applications for “working” in periods of high load. What is the max time a message will wait in the outbox? Do you have plans to provide mechanisms to canisters to introspect on the current load level? For example, consider how this could be used by a larger project to stifle competition from a much smaller project.
-
Similarly, how can developers expect this pricing to scale on different subnets.
I won’t be following up here. But, this is a huge change I couldn’t ignore. I hope this creates come curiosity in the community and the conversations continues.
David, I hope the foundation treats you to a nice dinner for drawing the short stick on this one 
.