Go-ipfs: Path to landing Bitswap PoC

[dirkmc]

We're currently working on a proof-of-concept for Bitswap to improve performance by disseminating information about how blocks are distributed amongst peers. This issue outlines the remaining steps required to complete it:

• [x] Complete PoC code review
• [ ] Close out remaining issues:
  
  
  
  • [x] [Timeout Management](https://github.com/ipfs/go-bitswap/issues/244)
  
  
  • [x] [Debounce wants](https://github.com/ipfs/go-bitswap/issues/245)
  
  
  • [x] [Prune peers from Session if they stop sending blocks](https://github.com/ipfs/go-bitswap/issues/257)
  
  
  • [x] [Session should broadcast when all peers are removed](https://github.com/ipfs/go-bitswap/issues/259)
  
  
  • [x] [Simulate DONT_HAVE when peer doesn't respond to want-block (new peers)](https://github.com/ipfs/go-bitswap/pull/284)
  
  
  • [ ] [Docs + Code cleanup](https://github.com/ipfs/go-bitswap/issues/246)
  
  
• [x] Create proposal for testground test suite
• [x] Implement testground test suite
  
  
  
  • [x] Measure Performance (compare with master) https://github.com/ipfs/testground/pull/345
  
  
  • [x] Version compatibility https://github.com/ipfs/testground/issues/435
  
  
  • [x] Fuzz Test Plan https://github.com/ipfs/testground/issues/427
  
  
  • [x] Seed Selection https://github.com/ipfs/testground/issues/436
  
  

After landing PoC:

• [ ] implement server side of PoC in Javascript (HAVE / DONT_HAVE messages)
  https://github.com/ipfs/js-ipfs-bitswap/pull/211
• [ ] tackle rate limiting

[dirkmc]

Performance comparison of master vs proof-of-concept

We collected performance data comparing Bitswap master against the proof-of-concept branch using a testground test suite.

In particular we are interested in comparing

• time to fetch at different latency / bandwidth, for varying numbers of leeches and seeds
• number of duplicate blocks fetched

5ms latency, variable bandwidth: 1 seed, 2 seeds, 4 seeds

These graphs are for 1 leech fetching from 1, 2 and 4 seeds with 5ms latency and 10MB, 20MB, 40MB, 160MB and 1024MB bandwidth.

For high bandwidth:

• the PoC gets better performance with more seeds whereas master gets worse performance with more seeds
• the PoC performs much better than master

For low bandwidth:

• the PoC and master both get better performance with more seeds
• the PoC performs somewhat better than master

5ms latency, variable bandwidth: 3 leeches fetching from 3 seeds

These graphs are for 3 leeches downloading simultaneously from 3 seeds. It seems like at any bandwidth the results are similar:

• PoC is faster, particularly for higher bandwidth / file size
• PoC results seem to be more consistent (points are less scattered)

Duplicate blocks - 5ms latency, variable bandwidth: 1 seed, 2 seeds, 4 seeds

These graphs show the number of duplicate blocks received by the leech for 1, 2 and 4 seeds.
Note that in the case of 1 leech / 1 seed, there will be no duplicates.
The points are highly scattered, but the results are generally as expected:

• For the PoC there are rarely any duplicates, at any bandwidth
• For master there are more duplicates when there are more seeds, and at lower bandwidths

100ms latency / variable bandwidth: 1 seed, 2 seeds, 4 seeds

These results for variable bandwidths with 100ms latency are similar to those with 5ms latency above.

[momack2]

OMG SHIP IT! (@hinshun - some pretty graphs to show off validating all the great work)

[jbenet]

Fantastic perf improvements! Great graphs! 🎉🎆❤️🚀

[bertrandfalguiere]

Holy ship! 🚀

[dirkmc]

Shout out to @Stebalien with whom we came up with the design ideas, and who reviewed the 9,000 line PR, @hinshun who created the test environment to validate the initial proof-of-concept and to the testground team ❤️

[obo20]

This is amazing. Great work all around. We're super excited to see this make it to production.

[whyrusleeping]

Fantastic! This is great stuff @dirkmc :)

[dirkmc]

🎉