When I buy A storage plan on HiDrive or Dropbox there are no egress frees. But higher monthly cost. But the higher monthly cost paid the internal egress fees due to the normal user never use all the orders space
Yeah but Iâm not offering hidrive or Dropbox⌠Storjlabs might decide to something like that but they have to think about their backend. If they pay snos for egress, it could still be a loss for them if customers download a lot and if they donât pay the snos for egress then, even though technically egress is free, it could quickly overload their backend, the upload bandwidth of nodes, which nobody will upgrade if it doesnât generate my income.
Storj is not really meant to be the end user tool so much as the place where you, as a company, build a Dropbox like tool. And then you can decide to offer storage at a fixed price and control the egress traffic. Dropbox and such donât allow you to use your data to serve the public. You canât upload a file and offer it to thousands of people to download. Theyâll shut you down if you try to get around it, as excess egress would be noticed. You get some daily input/output but they also tend to throttle that if itâs used too much on like systems. Many offer some kind of compression scheme that makes the upload/download process take longer as well. Depends on provider.
Storj is about using your data, either to build your own storage tool, or to connect it to a website or many other projects. You can, of course, use it for storage of your data. But, as you mentioned, there are cheaper alternative tools if you just want to do personal storage.
8 Likes
This discussion happens all the time on this forum but people donât take it on board.
2 Likes
its true this point gets raised a lot. I think if we look at it objectively, that means 2 things:
1.) there is a strong impulse to use a decentralized platform for personal storage thatâs easy and UI-friendly (and the customer in that scenario is not super technical, just a regular person
2.) we would be thrilled to see someone come along and build that on top of DCS, and get huge success while we helpfully provide the best, solidly secure, storage layer aorund 
3.) theres an opportunity for us to be even more clear about where DCS sits in that lasagna of layers. We do express this but it never hurts to overexplain. we can loo into some ways to make that more apparent and obvious
Was that three points instead of two? LOL dont worry about itâŚ
In all seriousness, thanks for the feedback. We are always searching out ways to make our offerings more loveable, usable and better to use.
1 Like
True, but I never said it was unlimited. I said it automatically increases with the upgrades of connections.
But the question is, are we there yet? Storj needs data on its platform. If that means that - maybe for a limited time - there is no charge for egress I would not mind if that is the price to make the platform more popular and fill my disks quicker. From the current state of the platform Iâd not be losing much.
Of course not. Egress isnât free. Weâre talking about a hypothetical situation where it is. With current pricing I expect nodes will be able to hold up. Which is probably why Storj Labs chose it to begin with.
Iâm not saying it canât be cheaper. There is probably some magical price that hits the exact right balance between being cheap enough to make good use of available bandwidth, but not enough to saturate it. 0 is almost never that value though.
With Cloudflareâs R2 announcement of free egress, this discussion seems interesting again.
Storjâs current stats show ingress is much higher than egress. So it would appear that at least the current set of customers and future customers like them are not going to use lots of egress even if itâs free. Backup and archive users for example would fall into this category.
Free egress may attract new kinds of customers with applications that do take advantage of free egress, and they could potentially cause egress load problems. Some have posted that they wouldnât upgrade their connection to handle higher egress loads, which is understandable if theyâre not getting paid to do it. But another way to address this would be to autoscale popular files or segments on demand, ie, distribute them over more nodes to spread out the egress load and charge for the extra storage. To be fair, it should autoscale back to the standard number of nodes if the file or segment is not popular the next month. This is sort of like Wasabiâs model of free egress up to a limit (for them, the amount of data you store), but instead of kicking users off, Storj adapts to their egress needs and charges a little extra.
Another possibility for customers that donât want to pay extra for autoscaling to get higher performance (autoscaling is the default behavior) is to offer âbest effortâ egress, an option customers could select to save costs if they donât care about download performance. Backup downloads to reorganize data are an example of this. To implement it, track download performance of nodes and intentionally select slower nodes that normally have their download canceled. Iâm simplifying here because a node could be fast for one download request and slow for another, so maybe it has to be measured as part of auditing, or maybe it already is.
A third option could be pre-scaling: the customer knows they are going to download the data a lot and they want it spread across more nodes immediately when the file is uploaded to avoid a delay that may occur before the file is autoscaled. This could also be used as an indicator to Storj to autoscale the file sooner than normal if it exceeds limits above the pre-scale replication factor. The nice thing about erasure coding is that the file doesnât have to be replicated completely: it can have its download capacity increased by 50% if thatâs all it needs.
When making decisions about when to scale out, ie, charge customers extra, I think itâs important to take some history into account too. If Iâve been sending backup data to Storj for a year, and only download data occasionally to optimize backup storage, then I have to download it all because a disk crashed, my egress for the month will be much higher than normal, but still low for the year; itâs an unusual egress event and I wouldnât want to get a big bill for it. But using the backup to load new VMs every day, sure, charge extra.
1 Like
I that case you probably donât want your data on slow nodes but on the fastest ones to get your data back to a working state.
The problem with current way of repair aka creating pieces of data I see is that ârepairâ really costs money for the servers and bandwidth who do the job.
But it would be cool if node would be able to do repair and auto scale pieces, similar to the graceful exit when pieces are moved directly between nodes. (On the other hand, why would a SNO who had the luck to store pieces of a popular file want the pieces to be distributed further?)
I wonder if pricing with more tiers would be a thing? So that 2 TB of egress cost the customer less per GB than 1 TB and not double the amount. Or 100 TB of storage less that 2 TB (also per GB or TB or whatever).
Since nodes are randomly selected, my data is likely stored on both fast and slow nodes. A normal download selects faster nodes by canceling the 10 slowest nodes. So that mechanism (or even better, picking known-fast nodes) could be used for restores, while the slow nodes are used for maintenance (Iâd have to indicate this somehow on the download request.)
This is described in the Storj Whitepaper V3
However it will not be free for the customers - their files would have more storage nodes than usual, and SNO should be paid.
So you would intentionally select nodes that are already struggling to fulfill download requests for more downloads? That would only increase the chances of them choking completely. Itâs also an incentive to run a slow node as it would get you more egress.
The weird part is that this would all be to intentionally make the customer experience worse on a network that was built to ensure a good experience for all customers and all data. And on top of that, it doesnât save Storj Labs any money to do this. The same amount of repair would still need to happen, possibly even more as slow nodes might also just be the ones which are less reliable and offline more often.
You could of course differentiate payouts to node operators as well. But that would make income a lot less predictable. And you would need to somehow explain why one node gets more money than the other for the same egress.
The dynamic scaling option and even pre-scaling are interesting though and indeed already discussed in the whitepaper.
While this is true, with dynamic scaling this would really only happen when a file gets a lot of egress. The current setup would only really run into issues if the same file (segment) is downloaded by multiple people at the same time. This means there is so much egress on those files that the cost of storage pales in comparison to egress costs. I would argue itâs better to keep the cost structure simple for the customer and not charge extra for the storage for dynamic scaling. This allows the pricing structure to also be similar to CDNâs which only charge for bandwidth too.
Pre-scaling is a different story though, thatâs the customer saying: âHey, I need more availability from the first moment and I want this level of availability to be there at all timesâ. That should come with the additional storage costs as well since there is no guarantee that there will be enough egress to compensate.
I just meant because of your quote:
Iâm making some assumptions:
- Cloudflare deploys R2 with a storage cost of 1.5 cents/GB and no egress charges. Per-operation charges are 80% of S3 (thatâs what theyâve set as a target). These charges are fairly insignificant.
- Storj charges .4 cents/GB for storage and .7 cents/GB for egress
- Any customer needing high egress will make R2 their primary reference, gradually migrating off services with egress charges with âcopy to R2 on object referenceâ, perhaps keeping their old provider as a backup
- Other storage services will drastically reduce their egress charges (most likely IMO) or accept the loss of their high egress customers
Because of the storage price difference, Storj is still a better deal for backups IMO. But for content delivery, it will have a very hard time competing with R2. It depends on the ratio of storage to egress: if that tilts toward storage, Storj is a better deal. If it tilts toward egress, R2 wins. So for SNOs, I think egress being a payday like it is now will not continue, but thatâs just my opinion.
Intentionally selecting slow nodes: yep! Iâm making another assumption here that there are nodes that are inherently slower compared to other nodes, maybe because of the hardware used. The current system optimizes uploads and downloads relative to the point of upload or download. Thatâs clever, but there are always tradeoffs:
- 115 nodes are selected for upload but only 80 will win. The 35 slower nodes have wasted their time.
- If my goal is to distribute data similarly to the Storj network distribution to optimize worldwide downloads, long-tail cancellation on upload thwarts that by giving preference to faster nodes, either because the node uses faster hardware, has higher ingress bandwidth, or is âcloserâ in the network sense to the point of upload (lower latency). To achieve more even distribution, long-tail cancellation should be avoided on upload and repair.
- on download, 39 nodes are selected and the first 29 are used, with 10 wasting their time. A node might be inherently slow because it uses slower hardware, has slow egress bandwidth (I have 1Mbit/s for example), or is located on a remote island.
Slow but reliable nodes are still very useful for the Storj network to satisfy the durability and availability numbers. If there was a way to request downloads from slower nodes (best effort download w/o extra cost), it would let them actually contribute to lowering egress loads on better-performing nodes where fast egress is required, ie, content delivery, without wasting their resources trying to compete with fast nodes in situations they canât possibly win. This might also help with the node churn issue. I donât think there is an incentive to have a slow node, especially if egress payouts are reduced or eliminated to compete with R2.
1 Like
I found very interesting this analyses and I would add two comments. These are not about the conclusion, just about two small items:
AFAIK they donât waste time but will be paid for the fragment which is downloaded. (eg. if download is cancelled after 50%, the 50% will be paidâŚ)
If both the fast and slow machines are evenly distributed, this is not the case. This is true only if there are significant slower machines, therefore the fast machines are not evenly distributed.
Good to know that canceled nodes get paid. But from a high-level vantage point, the work they did and the tokens paid still seem wasted because these didnât result in storing a piece (upload) or generating a segment (download).
Thatâs a good point. There are different factors making nodes fast or slow, and all of them combined determine whether a node is canceled during upload or download. My assumption is that network proximity to the upload or download origin plays a big part, so if I am in the US and doing an upload, it seems more likely that US nodes will be selected. But I donât have facts to back that up. My ping time to us1.storj.io is 3x faster than my ping time to eu1.storj.io, but I donât know how much of a role a difference like that makes for a piece upload or download. It could be that a fast node in China can accept an upload faster than a slow node in the US, but it seems âcloserâ nodes would win more often.
Not so simple. If you have use a compute service, RDS, Redis, ElasticSearch, etc. in AWS, you will not migrate most of your storages (databases, backups and storage for EC2). You can only move insignificant amount of data and will pay for egress from AWS.
For the typical cloud-oriented company It could be applied only to static websites, and again, then you will pay for Cloudflare service to host them, but it will be disconnected from remained infra, like RDS, Redis or even k8s with own services. There is also Route53 and ACM (free certificates) and many other.
The other providers are unlikely would change anything I believe. Their juicy customers already locked-in.
No, they will be selected across the globe randomly - one node from /24 of public IP for each segment, 110 for uploads and 39 for downloads. Due the long tail cancelation your pieces likely will end on fastest nodes, mostly around you, but not all, some will be far away. See the map for AWS_CLI_Onboarding.mp4 | Storj
1 Like
yes, but there will be very few experts in this field in the future. In the days when 100 tb ssd disks will cost 100 dollars, we will be the 1st in this race. itâs not really a race to the bottom
Race to the bottom in terms of earnings. If someone sells 1 TB for a $1. The next guy will sell it for .50cents, the next guy will sell it for .25cents. And it will go down and down because storage itself increases in capacity faster than bandwidth grows. Bandwidth is more finite and is the most expensive cost. Your drives last month after month. Bandwidth, you pay for it every month. So, SNOâs want to be paid for their bandwidth usage. Storage itself is going to be close to free. You need âsomeâ cost to prevent people from storing the entire Internet on their personal cloud drive.
The nice thing, and probably the best thing, about Storj is that because it uses pieces of files stored on hundreds of nodes, and potentially thousands, it allows a customer to scale their bandwidth as large as they need. Something other storage providers would struggle to provide and many of those that can do it have it at a price point that is painful.
So, storage alone is a race to the bottom on price. Bandwidth, especially at scale, is the value. Take that away, and nobody is going to make money at this. Not unless they start charging crazy high fees for IOPS. HahaâŚ
2 Likes
Amazon has responded before Cloudflare R2 is even released:
100GB/mo free egress is also 3x more than Backblaze B2âs 1GB free egress daily allowance, and more flexible since itâs for the month rather than daily.
I wonder if this is actually true or if we have just been trained to believe it is true by the large storage and *aaS vendors. Bandwidth in a data center is symmetric, so having free ingress and paid egress doesnât make a lot of sense, other than to lock in customers once their data is stored.