bitswap in large populations

[dvc94ch]

In the book algorithmic game theory by nissan on page 595 it says:

Of course, there is no guarantee that two peers will engage in multiple transactions with each other in their lifetimes. Even if they do, there is no guarantee that they will do so with a proper reversal of client and server roles to facilitate reciprocity or retaliation. In a large dynamic population with random matching of players, the probability of repeat interactions between players may be too small to cast an effective “shadow of the future,” and free-riding might prevail. Figure 23.1, taken from a simulation study of a p2p file-sharing game (Feldman et al., 2004), illustrates the inability of a reciprocative strategy to scale to large populations.

since you can't see the figure: a large population means a 120 peers in this case. so it seems like bitswap is ineffective. the reason why bittorrent works is because it forces repeat interactions inside a swarm.

[dvc94ch]

actually bitswap is only a mechanism, the criticism only applies to the tit for tat strategy using a private history. There is nothing preventing it from being used with a shared history (on a dht or blockchain). after reading about all these hard and unsolved problems in p2p systems, [0] turns out to actually have some solutions.

• [0] Robust Incentive Techniques for Peer-to-Peer Networks

[dvc94ch]

Can someone move this issue to ipfs/notes? People in the rust-ipfs riot have an interest in a public discussion after I mentioned it. @daviddias

[daviddias]

@dvc94ch done :)

[dvc94ch]

This may be controversial but I think it's an argument for the opinion that a p2p file system should be built on a p2p db and not the other way. Like to hear other opinions and reasoning. (This is obviously just pushing the problem to a lower layer, but you may humor me in this thought experiment)

[RubenKelevra]

I guess this is more an issue in clusters, not in IPFS itself since most nodes will never touch each other since they are interested in completely different parts of the network.

In a cluster we have an agreed set of data which needs to be split between the nodes, to be hold with redundancies in the network.

Since we know the cluster members and know the data-cids, we can calculate which node should hold which data in a probabilistic way.

So if the cluster-service asks the ipfs client to fetch a cid, it could hint where it expects that this stuff is stored, to avoid going to the DHT and going through a "ask anybody" bitswap operation.

There's a ticket for this: https://github.com/ipfs/ipfs-cluster/issues/1058

[dvc94ch]

A cluster requires a trust within the cluster, I was talking about the idea that ipfs can incentivize nodes that have for example a Wikipedia page cached locally help reduce the bandwidth of the network by serving it to close peers or in the local lan. Without proper incentives anyone can patch an altruistic ipfs implementation to not provide the blocks that are stored locally.