Questioning commercial cost usage of nCDN, Tuna etc

Applications
,
#1

I would like to discuss the motivation for costing on the NKN commercial services. In my opinion, the cost of Tuna and nCDN are far too high for regular usage. They are directly cost comparative to using existing HIGHEND commercial VPN / Proxy or CDN products that have large costly infrastructures, employees and SLA’s to uphold. The suite of NKN commercial products are built on the backs of other peoples internet and infrastructure. This alone should be an enormous cost savings.

You should take a note from the Helium (HNT) team when running a competitive cost analysis in the market. We can easily see the benefit to tracking our vehicles and assets over helium because the cost of that (including hardware if we had to cover holes in the network coverage) is a HUGE savings in comparable commercial solutions (GPS over Cell Infrastructure etc) easily 10x savings in the first year alone.

However, how can someone build a viable commercial solution ontop of nCDN or even use it @ $6/1TB
Commercial nCDN providers with guaranteed SLA’s built into existing distributed datacenter infrastructures are $8/TB from azure are similar from AWS and there are many smaller players offering much cheaper solutions.

I would like to start a public conversation about the viability building a commercial solution on top of, or utilizing NKN and discuss how its almost immediately cost prohibitive to do so.

2 Likes
#2

Good post, I was under the impression nkns solutions were dirt cheap and was kinda surprised that adoption wasnt reflecting that. I thought perhaps the services are just not mature/performant enough. I know its a lack of DYOR on my behalf but these kinds of enterprise services I have little affinity with in general.

Its surprising me to say the least that these nkn services are not much cheaper than centralised solutions for the exact reasons you provide, this would in turn explain why there is little to no adoption outside of hard deals between NKN and other companies (chinamobile ie.)

1 Like
#3

If Tuna or nCDN were to allow configuration of the home user to dictate what they want to sell their bandwidth/space for

Configuration option example nCDN (written in plain english):
Bandwidth available per month to sell: 300GB
Cost per GB (sold using NKN nanopay): $0.01/GB
Space on hdd: to dedicate to CDN storage: 10GB

Configuration option example tuna proxy exit node:
Bandwidth available per month to sell: 1000GB
Cost per GB (sold using NKN nanopay): $0.001/GB

then a user configuring their tuna entry node could say be:
Cost per GB (maximum amount willing to pay on exit node): $0.01/GB
that way the exit node can look for nodes that are that price or cheaper and use them directly. This would allow alot of home miners with unlimited data packages or lower data users to see benefits from mining aside from lottery rewards by utilizing

also if this were the case you would have to add some fine print that says the cost of bandwidth applies to tuna exit and CND traffic only. NKN relays and mining bandwidth are a part of the mining process and will not gain proceeds from bandwidth used but will gain you tickets in the “mining lottery”.

1 Like
#4

I think the price can be adjusted lower in short term to spur wider adoption. And in the future when smart contract is supported, it can be negotiated by the users and miners.

First of all, data pricing needs to reflect the value of service. e.g. CDN eats tons of data and has to be dirt cheap. On the other hand, nConnect and TUNA are services that can be priced higher.

$6/TB is not bad pricing for cloud nodes, considering that DO node costs $5/month which includes 1TB data. But I agree with you, that home miners can set the price much lower to attract usage, since they have a fixed cost and (almost) unlimited bandwidth. Then there will be clear pros/cons for cloud nodes versus home nodes, and each can thrive on its unique traffic mix.

As a short-term intermediate solution, we need to provide miners the GUI or Portal to configure their pricing, as well as a recommended default pricing that is relatively dynamic and in line with supply/demand.

#5

I like that it is a future plan to allow the suppliers to dictate.

I think we are in agreement with that, but pricing it the same as a large cloud provider with SLA’s is both unrealistic and also unusable.

The best way to add true distributed value to the network will be to allow the home users selling their potentially cheap home services to undercut the cloud mining rigs. it would allow true potential passive income on service that would otherwise go unused. Give the home miners a leg up.

#6

My pricing suggestions:

Both nCDN and Tuna and others unrelated to the relaying of nkn internal node traffic. should be opt in, not randomly turned on with nkn-commercial occasionally, possibly with a parameter in config.json.

Both should have a configuration parameter to turn it off after a specific amount of traffic has passed for either service - user definable in config.json.

  1. nCDN should have a minimum requirement of an additional 10-20G SSD/or equivalent specifically for nCDN available storage (this is a requirement of being able to mine the associated bandwidth not direct compensation for storage, larger availability would make you chances greater that the files you’re hosting may be used more often resulting in traffic compensation)
    nCDN should be compensated @ ~1 nkn per 100 Gigabytes of uploaded actual nCDN bandwidth (not related files being transferred to the storage for future usage or management proof of availability checks but actual nCDN usage)

  2. Tuna would/could be along the same lines: ~1 nkn per 100 Gigabytes of actual exit node throughput compensated with the nanopayment on a per Megabyte basis ( 0.00001nkn / Megabyte | 0.01 nkn / Gigabyte | 1nkn / 100 Gigabytes )
    Tuna should also not allow an entry node to pass traffic if it knows it can’t pay for the traffic (0 or low balance wallet should cause a user identifiable error of some type)

I think these prices would allow for both larger adoption of the services, larger rewards to the community and as the value of NKN rises, it would automatically compensate miners appropriately and ultimately the market will eventually define the price of the token by what users are willing to pay for the enhanced services.

3 Likes
#7

All good suggestions!

This is exactly how tuna works now (except that price is in unit of NKN/MB). But we need to find a way to make it easier to configure inside nkn-commercial.

Both nCDN and Tuna and others unrelated to the relaying of nkn internal node traffic. should be opt in, not randomly turned on with nkn-commercial occasionally, possibly with a parameter in config.json.

There are already parameters that can turn if off in config.json. For example:

{"tuna-exit": {"disable": true}}

But we probably need a more consistent way that can control all the behaviors including pricing. It’s not the top priority though as tuna users are not many compared to providers now, but it’s definitely in plan.

Both should have a configuration parameter to turn it off after a specific amount of traffic has passed for either service - user definable in config.json.

That could be useful in some case, although it would require some fundamental change and add some persistent data usage mechanism and database.

Tuna should also not allow an entry node to pass traffic if it knows it can’t pay for the traffic (0 or low balance wallet should cause a user identifiable error of some type)

We have the plan to do that, but probably later. Currently zero balance wallet is convenient for user to start testing.

#8

Thanks for your time @yilun, I know you’re a busy guy!

If there are parameters to turn it off, there should be parameters to turn it on.
I have some nodes with limited bandwidth, but I also have quite a few with unlimited bandwidth (as I’m sure many other miners do as well) Would be nice to be able to dictate to the network which I’d like to use as tuna exit nodes.

I’ve also rethought my stance on nCDN - I’m not sure NKN should be in the data storage business at all. I think NKN should remain focused on its core anonymous internal relays and entrance and exit proxy nodes. After reviewing other products like StorJ, Filecoin and IPFS, they might be better suited for the content delivery market. I could see a partnering opportunity with them to create some obfusticated file storage anonymity which might be useful and profitable for both parties. Maybe a future joint miner proposition?

#9

It has always been my view that NKN should focus on the networking domain, while partner with ipfs/filecoin/storj for storage. nCDN caching might be a special case, which does not need global consistent storage and suitable for NKN nodes.

1 Like
#10

If there are parameters to turn it off, there should be parameters to turn it on.

Opt-in might work if there is a way for user to know what kind of services there are. But currently there is no such way yet, so miners will never have a chance to know what they are missing unless the services are running already.

We try to make nkn-commercial as automatic as possible for most people (especially beginners). So opt-in or opt-out might eventually depends on whether most people want to have it on or off. Ideally we want the default config to work for 99% miners, and the rest 1% can get what they want through config.

#11

I think you are underestimating the technical competency of your userbase. Yeah there are alot of rookies, but there are also ALOT more skilled miners in the space you never hear from.

Services like Fast deploy from NKNx and All-in-one from no112358 account for probably 40-60% of the current installs. Having them as options/questions during the creation of the fast deploy script or menu items in the all-in-one would easily gain a large usership to allow clean transparency and the inclusion of the opt-in commercial components would also gain the individual components recognition simply because of the question. right now I bet a high percentage of the current miners don’t know what Tuna or nCDN are? but if they were configuring a fast deploy or asked the question in the all-in-one script and it asked them if they wanted a chance to earn more revenue by opting in to these services, you would get a higher adoption rate and alot more awareness of what the products are and how to better utilize them.

Also adding them as a configuration option in the future, and having them show in nstatus.org, nknx dashboard, nWatch and nMonitor would instantly make people aware of then new “opt-in options”.
I would also bet that actual core usage of the services will also increase just based on all these new miners finding out about it and discussing the possibilities and utilization of such things.

2 Likes
#12

Oh yeah I definitely agree! For the future plan I agree with you. For now we haven’t spent much effort working on this because basically nknd is the only mature service on nkn commercial currently. tuna is in alpha stage, so we only push it to a few percent nodes. But in the future we definitely want it to run on every node with opt-in/opt-out choice. Same for future services.

2 Likes
#13

@yilun @zbruceli
Is there an updated milestones and benchmarks that signify timelines on a cost adjustment? My current usecase is held up by the current cost projections. The current pricing on TUNA doesnt allow me to have the margins required to create a sustainable, let alone profitable VPN product.

#14

Just for information, what kind of price are you expecting?

#15

Hoping to get close to the pricing I stated above:

~1 nkn per 100 Gigabytes of actual exit node throughput compensated with the nanopayment on a per Megabyte basis ( 0.00001nkn / Megabyte | 0.01 nkn / Gigabyte | 1nkn / 100 Gigabytes )

Whatever the nanopayment scale is based on is a non issue, (per kb or mb) my numbers above were just an example. the amount per GB is the more important factor to begin gaining real traffic and users.

#16

Right now for DO and Linode, it is $5 per month for 1TB.

So 10 NKN / TB or 0.01 NKN/GB might be on the edge of profitable.

1 Like
#17

Again you are comparing centralized cloud servers limited and expensive bandwidth costs to the costs of the token. this again brings back my point of separating tuna (or exit node relays) as a configurable parameter for this free market purpose.

  1. Allow the user to set a configurable option to turn it on as an exit relay node (for extra profits, not just mining)

  2. Allow the user to set the price of bandwidth (sell x amount of TB for X amount of nkn)

  3. Allow the entry node user/service to utilize cheapest available bandwidth first and pay no more than x nkn per TB

Then you have a usable market driven entry/exit relay setup that lets the market decide the price
This will benefit those home nodes that are in unlimited bandwidth situations who will be able to capitalize where they might not be receiving the most mining rewards due to slightly higher ping times comparatively to the cloud nodes.

#18

~1 nkn per 100 Gigabytes of actual exit node throughput compensated with the nanopayment on a per Megabyte basis ( 0.00001nkn / Megabyte | 0.01 nkn / Gigabyte | 1nkn / 100 Gigabytes )

0.01 NKN/GB (~ $0.004/GB) is way too low even for decentralized applications. Check out Orchid, a decentralized VPN, the price is about $0.06/GB, similar to the default tuna price now, and lower than top VPS like AWS/GCP/Azure.

This will benefit those home nodes that are in unlimited bandwidth situations who will be able to capitalize where they might not be receiving the most mining rewards due to slightly higher ping times comparatively to the cloud nodes.

There is no such thing called unlimited bandwidth :slight_smile: Actually if a home user uses significantly more bandwidth than a threshold (say, a few TB per month), ISP will find you. If a home user serves 100GB bandwidth through tuna and can only get 1NKN, I don’t think he will be happy, at least I won’t.

this again brings back my point of separating tuna (or exit node relays) as a configurable parameter for this free market purpose.

As I said earlier, it will. Actually it is already configurable now. One can change the value in config.exit.json to change the price. We just need to make it easier for most people to do it.

1 Like
#19

I’m amazed that you guys have come this far while utilizing a “status quo” attitude like this. Being disruptive allows freemarket decisions to dictate pricing. comparing your product to other commercial ones will always put you in their world. I beg you to please break away from that thinking or NKN will always be a follower.

You are making alot of assumptions about other peoples service plans and profits. There absolutely are unlimited data plans, I work for a provider that culturally enforces unlimited data and honesty in advertising. Sure some larger providers employ techniques like throttling etc. but again you are making assumptions for users who might be happy to give there bandwidth away at a chance to enter the crypto game. This is why freemarket methods will cause disruption and prevail.

This is great to hear! what version was it enabled in? and does the entry node allow for a price it would like to pay? or max price / MB that is will allow?

Again, im not trying to be confrontational or argumentative @yilun . I’m just trying to help make NKN the best service it can be. I know that what you do is amazing and you’re obviously a complete genius at mathematics. But always remember that on a world scale, some commodities are much cheaper in other places and freemarkets will allow fair pricing overall regardless of geo-locations.

1 Like
#20

Being disruptive allows freemarket decisions to dictate pricing. comparing your product to other commercial ones will always put you in their world. I beg you to please break away from that thinking or NKN will always be a follower.

Haha we don’t typically compare with other centralized approach, but Orchid is a bit different since it’s also a blockchain-based decentralized project and our community often ask us to compare with it :joy:

But to be clear, the current default price is never intended to “match” any other solutions or project, and we also don’t think it’s the price it should be in the future. The only reason we use the current price is because we don’t want any miner to lose money by running tuna, so we set it to be higher than VPS bandwidth cost.

This is great to hear! what version was it enabled in? and does the entry node allow for a price it would like to pay? or max price / MB that is will allow?

It is enabled in all tuna version. The service provider side will be able to set the price, and user side will be able to choose the max acceptable price it would like to pay, which will be used to filter providers.

2 Likes