Thanks for the insight, this should be discussed with the PNI then.
Great then you can do the math and calculate which are those odds. The fact that you ran hundreds of nodes in Paris does not tell us anything, there are 20K nodes in the network and the CP wont care if your node is in Paris or Frankfurt as long as they have less than 150 ms latency.
We are aware that traffic shifts.
Lots have changed in the last year.
If the token was still 3 u$d, we would not be proposing this.
If the PNI wouldn’t be trying to reduce costs, we would not be proposing this.
If the V0 had enough support so node-runners could haply run their business, we would not be proposing this.
Nobody wants to drop support, ideally we would be buying hardware everyday and expanding to new regions, but that’s not the landscape today. If it wasn’t for the community (mainly node-runners) V0 would have probably crashed. I believe that this is what we need to re-group and make it to V1. We need to focus on maintaining V0 and help on V1. The node-running race can take a brake.
That is already happening, less than 10% of the nodes are local in US-West. You can get the odds of being in a session of one of your nodes in us-west.
The bottom line is that this proposal does not reduce costs in any significant way. The regions cost a few hundred dollars each per month to spin up before they receive traffic. It will significantly affect service. The fact that no one on the team has raised this to Arthur is disturbing.
They are wrong. Spinning up a new region costs around $500 per month with the minimum level of Elasticache. Nothing else costs money in a region (aside from minor costs like VPC creation) until it receives traffic.
All this proposal does is shuffle the costs of traffic to another region.
I don’t believe this is true. The Gateway system already uses AWS Global Accelerator which has hundreds of PoPs and keeps the traffic on the internal AWS network as soon as it reaches one of those points.
Your example in your second post is incorrect. Because the user near AP-NE-2 has to travel with their request over the public internet to AP-SE-1, nothing is gained. You’ve changed what part of the request travels over the public internet, but there is still the same amount of public internet being used.
There is no logical way that reducing the number of Gateways will reduce end-user latency. I suspect we will see this effect in action as the other Gateways are shut down.
I understand that once in AWS the traffic between regions will move through the AWS Global Backbone and it is not the same as public internet (and the reason why pings are lower in the data matrix). The amount of public internet being used is different, the example is quite clear about that.
@RawthiL would you mind sharing your analysis (assuming you have done so) of how eg 20 vs 3 would play out in terms of QoS in v1, where things like setting location are enabled?
I’m not sure exactly what you mean by “in terms of V1”.
If you say want to know how would QoS be in a network were the relays are only served by local node, then I cannot tell.
Today it would be really difficult to know where are nodes located and in which geozones would they be staked in V1. In a perfect world, only local nodes would be staked in each geozone, resulting in better QoS, but this cannot be enforced and non-local nodes could also be staked in any geozone. This will reduce the QoS to values that are at the limits of the MinimumTestScoreThreshold.
Also, I think that V1 wont have 20 geozones, so the routing problem presented here will be present within each geozone in V1, as more than one gateway will exist in each geozone.
We’re going to continue as is, but may not get down to 3 regions. Plan is to go slowly - spin one down, monitor latency and cost, and make a decision to continue.
Alex did believe there were some regions that could be spun down, but not as many as we believed.
Our Team has been focused heavily on the Portal v2 work and QoS over any regional reductions. We have found cost savings in other areas for the time being that are satisfactory and have put this initiative on hold.
I can provide more information as we get back to this workload around methodology, key metrics, etc.
You are not going to retire any portal then?
Not even those that are really close? Like keep us-west-1 close us-west-2 or keep eu-west-1 close eu-west-2/eu-west-3 or keep us-east-1 close us-east-2.
QoS? are you planning to change the Cherry Picker process? is there any place I can follow this?
We will re-evaluate our approach to regions and any reductions after we are at a comfortable position with the development of Portal V2.
No changes to the V1 Cherrypicker will be made. When we release the Portal V2 we will be sure to clearly document and explain the QoS Module that has been implemented.
They are both elements of the Pocket Portal which is separate and distinct from the actions of the Pocket Protocol (v0). The Pocket Portal is essentially an application layer on top of the Pocket Protocol.
The “Cherrypicker” (which is a polarizing name) is part of the current Portal (v1) logic. We are currently in development on the Portal V2 which is focused on implementing numerous Quality of Service guarantees that will operate at the application level.
