I’m thinking of a mechanism where a SNO could mark their nodes in different /24 subnets as still backed by the same hardware. Consider a following scenario.
A SNO has their primary location with lots of storage at home, with a consumer-grade ISP with average consumer-grade network bandwidth. Good enough for current traffic, definitelly a bottleneck for peaks like two months ago.
That SNO might also have a capability to set up secondary storage at a different location, within a separate network, but with not as much storage. This way, their cumulative bandwidth is better. Yet, the SNO has an intent of migrating nodes from the secondary location to the primary one (either by physically transporting drives, or by network during off-peak hours). Node migration is a risk to the Storj network though, as it collocates data that was put with assumption of uncorrelated failures.
The SNO would like therefore to make sure the network knows of the intent and is allowed by T&C to do so on a regular basis.
I am actually sort of in this situation: I have access to some company servers in decent collocation, where I could store few hundreds of gigabytes, maybe even terabytes of data… not permanently though. If I could set up a node there to capture peak hours (when my home ISP cannot handle all the traffic), and then transfer data to permanent storage later, this would effectively serve as community-maintained surge nodes.
I think the issue with this is that you are looking at a scenario of fast ingress and low egress, like what was tested with this one customer recently. However, many customers interested in Storj (Some multi petabyte ones in various stages of onboarding) have needs for egress. Storing a lot of data behind a single residential line will swamp it if it has a lot of pieces being requested. Then you’ll want to move the most commonly accessed files to your high bandwidth location, etc. It is all customer specific situations. I would just try and put nodes where you have stable bandwidth and power and allow the network to grow and utilize it as needed by customers. If Storj Labs has specific needs from SNO’s it will be communicated like how it was recently so there are no surprises.
Whatever Satellites do: they can’t trust a single bit of info coming from SNOs. They need to test node availability for themselves, and audit for themselves, and measure speeds for themselves: and make every decision based on that info they gathered.
A node can have flags promising to be online, or to donate to charities, or volunteer at a homeless shelter, or that they aren’t part of a group of nodes sharing common storage… or that they are… and Satellites can’t make decisions on any of it. Even a graceful-exit flag is just a suggestion and courtesy: as the node could really go permanently offline 10 minutes after setting it. Can’t trust anything a remote piece of open-source software tells you from the other side of the Internet.
TL;DR; I see the value in marking nodes as you describe; but Satellites can never trust that it’s true.
In theory a sno could implement this with some kind of tiered file system completely transparent to storj. However, I don’t think it is worth the effort.
This particular customer had a need for a lot of ingress from many different locations at specifix times of day. Adding additional nodes is basically was a precaution in the event current node owners coulsnt handle the load. We can see that most node operators are running multiple nodes behind single household Internet, and are just using VPN/VPS to mask it. We determined that there may not be enough bandwidth overall so had to potentially add surge nodes to handle any fallout. But since they went to Select, it was no longer necessary. Other customers will not likely have such high demand at specific hours that could tax the network. But, it is also possible that this customer eventually comes over to the public side, if efforts to get the public side SOC compliant works out. As it is more ideal for Storj Labs to have customers use the public network.
Which is not what I’m proposing. My offer was to provide means to spread ingress bandwidth peaks, something that cheating SNOs can’t do with just a VPN.
But I get it—your response effectively means to me that you do not have this need now anymore. That’s a clear answer. Thank you!
I dont think currently we do. It is also pretty niche. The vast majority ot SNO’s dont have similar access to the setup that you do. But perhaps in the future it will be something we are in need of. Storj Labs talks to a lot of companies and is in various states of testing and onboarding them. What is true today may be different tomorrow. So, never say never.
