How does IPFS based solution solve the uplink/downlink asymmetry problem

From @syang on Wed Mar 30 2016 02:10:55 GMT+0000 (UTC)

Having file stored in a central service like S3 plus using CDN properly, we can get the durability (by S3) and performance/latency issue solved (by CDN), and by the way, with CDN the network bandwidth usage is significantly reduce as CDN will cache the hot data on the edge (and who cares the cold data anyway). I would like to hear someone give a fair comparison here – because an entirely new storage paradigm needs to be significantly better than the existing system to really get meaningful traction.

IPFS based storage solution does seem to provide the conceptual benefit, as most decentralized solutions sounds at the very beginning. However, other than inertias created by the above ‘good enough’ solution that every major service is using and designed upon, I see another big problem to store data on the last mile devices, and that is the asymmetry of uplink/downlink bandwidth. Mike Chamber (the last comment in this thread) described it, and I’d really like to hear people’s response to that.

Thanks,
Sean


Copied from original issue: https://github.com/ipfs/faq/issues/104

From @RichardLitt on Thu Mar 31 2016 18:37:46 GMT+0000 (UTC)

Thanks Sean! This is a great question. @jbenet - can you pen a response to this?

From @jbenet on Fri Apr 01 2016 05:55:42 GMT+0000 (UTC)

> I would like to hear someone give a fair comparison here – because an entirely new storage paradigm needs to be significantly better than the existing system to really get meaningful traction.

@syang a proper answer would take many pages. Please watch the first half of https://www.youtube.com/watch?v=HUVmypx9HGI to understand the problems we’re solving. Distribution perf is only one. IPFS does many important things the cloud infrastructure of today just cannot.

I see another big problem to store data on the last mile devices, and that is the asymmetry of uplink/downlink bandwidth.

This is a temporary problem. The uplink/downlink asymmetry is due to carriers allocating the bandwidth that way, not a physical difference. If there is true high demand for strong uplinks at the edges that can reduce ISP peering costs, over time ISPs will adjust. Also, local mesh networks do not have this problem-- particularly when you uplink them directly at a datacenter, avoiding the bandwidth of last mile ISPs

From @Kubuxu on Fri Apr 01 2016 06:25:24 GMT+0000 (UTC)

They disparity of between down link and uplink is caused by need of current market.
The cable has given bandwidth, it might be a telephone cable, a coax or a fibre it doesn’t matter. This cable is what IPS use to connect end points to their backbone.

This bandwidth is combined bandwidth so it defines sum of upload and download. In most cases consumer level service will require more download than upload that is why asymmetric standards were introduced (ADSL) where cable bandwidth is split into mostly download and a bit of upload (normal user prefers 38 Mbit download and 2Mbit upload over 20/20 split).

This doesn’t mean that IPFS can be useful now, imagine an apartment building were the most limited bandwidth is between the building and a backbone network. In this building users could use IPFS and communicate with LAN speeds. This would also offload the limited bandwidth connection buy using it much more efficiently, as IPFS would use data that is avalible in the high speed apartment building network over downloading it from data center.

From @erm3nda on Sat Apr 02 2016 02:50:54 GMT+0000 (UTC)

Assymetry is up to the connection. You can’t make faster a slow uplink using software.
In the case that you host “cache” of your requested website, you’ll not download it in the real term, just loading from yourself.

Loading cached content faster than using network is not safe unless you mix your network with tor or something like that.

If you finally use the network to retrieve even your cached files, there’s no bandwich save at all, but better than be flaged as the owner of a certain bad files.

From @shuoy on Thu May 26 2016 19:00:10 GMT+0000 (UTC)

Have we answer the concerns/issues that @erm3nda raised? If not, can we reopen this topic?